← plain-English summary · source APK obtained from the developer's official release channel; app never executed; no servers contacted by this analysis. Encryption key identifiers are redacted here; they are recoverable from the APK by anyone holding it.

MeshOS v1.0.31 — Static Review of Public Claims

Reviewer: Andrew's Hermes agent (static only) · Date: 2026-11-07 Source: APK fetched from the developer's official download channel only. meshcore.co.uk/app/ links to https://github.com/andymux/meshos-releases/releases/tag/v1.0.31. Nothing was taken from meshoskey.com or any mirror. No keygens or licence bypasses were downloaded or examined. No meshcore.co.uk server was contacted.

Verdicts

1. Provenance

Commands: curl -sI https://meshcore.co.uk/ → HTTP 200 (Cloudflare); app page's official link fetched to artefacts/app-page.html; release catalog from the GitHub API saved to artefacts/releases.json; hashes in artefacts/apk-sha256.txt, artefacts/libapp-sha256-arm64.txt; apksigner verify --print-certs output in artefacts/apksigner-certs.txt.

2. Manifest (C1)

Full output: artefacts/aapt2-badging.txt and artefacts/aapt2-manifest.xml (tools/android-bt/android-14/aapt2 dump xmltree … --file AndroidManifest.xml).

All 26 declared permissions (uses-permission only, no custom dangerous grants beyond):

INTERNET, ACCESS_NETWORK_STATE, CHANGE_NETWORK_STATE, ACCESS_WIFI_STATE,
WRITE_EXTERNAL_STORAGE (maxSdkVersion=28), BLUETOOTH/BT_ADMIN (maxSdk 30),
BLUETOOTH_SCAN (neverForLocation), BLUETOOTH_CONNECT, BLUETOOTH_ADVERTISE,
ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, POST_NOTIFICATIONS,
FOREGROUND_SERVICE, FOREGROUND_SERVICE_CONNECTED_DEVICE, FOREGROUND_SERVICE_LOCATION,
androidx.car.app.MAP_TEMPLATES, androidx.car.app.ACCESS_SURFACE, WAKE_LOCK,
CAMERA, RECEIVE_BOOT_COMPLETED, SYSTEM_ALERT_WINDOW, RECORD_AUDIO, VIBRATE,
DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION, READ_EXTERNAL_STORAGE (maxSdkVersion=28)

Explicit check:

• READ_CONTACTS — not declared
• READ_SMS — not declared
• RECEIVE_SMS — not declared
• READ_CALL_LOG — not declared
• READ_MEDIA_IMAGES — not declared
• READ_EXTERNAL_STORAGE — declared but maxSdkVersion='28' only

<queries> element contains exactly: android.intent.action.PROCESS_TEXT, two android.intent.action.VIEW intents, and (visibility of) androidx.car.app.connection.provider — standard Flutter text-selection and car-app entries. No SMS/contacts package queries.

Declared content providers (all inside <application>): io.flutter.plugins.imagepicker.ImagePickerFileProvider (exported=false), dev.fluttercommunity.plus.share.ShareFileProvider (exported=false), com.google.mlkit.common.internal.MlKitInitProvider, plus plugin-internal providers. None expose SMS/contacts data.

Why C1 cannot work on Android (stated even though analysis continued): Runtime "dangerous" permission enforcement exists since API 23, and SMS providers have refused un-declared access since API 19; minSdk 24 post-dates both. An app that has not declared READ_CONTACTS/READ_SMS in its manifest can never be granted them; any ContentResolver.query("content://sms") or ContactsContract read throws SecurityException. Side channels were also checked and are absent:

• no <uses-permission-sdk-23>, no sharedUserId, no

NotificationListenerService and no AccessibilityService in the manifest;

• no use identified in the examined code for: SmsManager, NotificationListener,

AccessibilityService, DexClassLoader, InMemoryDexClassLoader, or app-directed System.load;

• the only ContentResolver data flows in Java are framework/plugin internals

(androidx FontsProvider, image-picker pick results) — no SMS/contacts URIs;

• inbound <intent-filter>s: only LAUNCHER/VIEW/GET_CONTENT text — no vCard or

contact-picker entry points, so no permission-free, user-mediated bulk route exists either.

3. Java/Kotlin layer (jadx 1.5.4)

Full decompile: ~/meshos-review/jadx-out/ (23 decompile errors, normal for Flutter apps).

Search across sources/ for content://sms, ContactsContract, READ_SMS, READ_CONTACTS, Telephony.Sms: zero hits. The only telephony reference is sources/D2/c.java:25 (Google Firebase performance telemetry, getSimOperator() for mcc_mnc), part of play-services' backend — not a device-data harvester.

Plugin registrations (io/flutter/plugins/GeneratedPluginRegistrant.java): audio_session, cryptography_flutter (dev.dint.cryptography_flutter.CryptographyFlutterPlugin), file_picker, flutter_blue_plus_android, flutter_local_notifications, flutter_plugin_android_lifecycle, gal, geolocator_android, image_picker_android, just_audio, mobile_scanner, network_info_plus, package_info_plus, path_provider_android, record_android, share_plus, url_launcher_android, usb_serial, webview_flutter_android.

No flutter_contacts, no contacts_service, no telephony, no another_telephony.

The developer's own Java classes are minimal and contain no upload/SMS/contact code: MainActivity.java (BLE permission plumbing), MeshForegroundService.java, BootReceiver.java (boot reschedule), car/MeshCarAppService.java (7 lines). No MethodChannel handler named companion/signing exists on the Java side; the string com.meshcore.companion/signing lives only in the Dart pool.

Raw grep output: artefacts/jadx-search.txt (single hit overall: the Firebase telephony.TelephonyManager import in sources/D2/c.java, described above).

4. Dart layer (blutter over libapp.so arm64)

Blutter output: ~/meshos-review/blutter-out/ (pp.txt = 2.2 MB object pool dump, asm/ = 1,312 disassembled Dart classes, objs.txt, blutter_frida.js). Tool build: tools/blutter-src with locally staged ICU/capstone (no system installs). Dart VM build log: artefacts/blutter2.log; run log: artefacts/blutter-run.log.

4.1 String/object-pool searches (pp.txt)

Complete list of HTTPS URLs in the Dart pool (no others exist):

https://meshcore.co.uk/fw/firmware.json
https://raw.githubusercontent.com/andymux/meshos-releases/main/version.json
https://store.meshcore.co.uk/products/meshos-for-android-license?…
https://store.meshcore.co.uk/products/meshos-meshcore-t-deck-license
https://tiles.meshcore.co.uk/
https://tiles.meshcore.co.uk/coverage.json
https://tiles.meshcore.co.uk/hm/upload
https://tiles.meshcore.co.uk/img
https://tiles.meshcore.co.uk/nodes.json
https://tiles.meshcore.co.uk/sat/{z}/{x}/{y}.png
https://tiles.meshcore.co.uk/{z}/{x}/{y}.png

4.2 Function identification and cross-references

blutter's own annotation pass misses several async closures, so pool loads were also located by direct instruction-encoding scan of .text (ADD PP,#page,lsl 12 + LDR [reg,#off], calibricated on a known annotation at 0x9b2520/0x9b2524). Script saved to artefacts/scan_pool_refs.py; r2 disassembly excerpts in artefacts/r2-img-ctx.txt, artefacts/r2-hm.txt, artefacts/r2-4e1270.txt.

Key load sites (address = .text virtual address; PP = x27):

The /img upload function (0x9c28f4, async continuation inside yGk.dart's Uint8List closure), reconstructed from r2 output (excerpt in artefacts/r2-img-ctx.txt):

0x9c2920  add x1, x27, 0x11, lsl 12
0x9c2924  ldr x1, [x1, 0x4f8]      ; "https://tiles.meshcore.co.uk/img"
0x9c292c  bl 0x2cdab0              ; wrap URL object
0x9c2944  … then four map-add calls (0x89b48c) building Map<String,String>:
          (pp+0x114d8 "X-MeshOS-Key", pp+0x114e0 "")
          (pp+0x114e8 "User-Agent",    pp+0x114f0 "MeshOS-App")
          (pp+0x11028 "Content-Type",  pp+0x1ab68 "application/octet-stream")
          (pp+0x1ab70 "X-MeshOS-Enc",  pp+0x1ab78 "gcm")
0x9c29b4  bl 0x4e1270              ; POST helper (async, "POST" method string at pp+0x11058)

So the /img upload:

• takes a Uint8List + int parameter (image bytes/length signature),
• sends it as application/octet-stream,
• stamps fixed headers X-MeshOS-Key:

(hard-coded 128-bit/32-hex app key), User-Agent: MeshOS-App, X-MeshOS-Enc: gcm.

This matches an encrypted binary image upload with declared GCM encryption and a fixed app-identifier key. It does not match a "12-field TLV" form submission: there is no multipart envelope, no field names besides the four header pairs above, and no TLV-related strings in the pool.

The /hm/upload function (0x98c6xx, dFk.dart) builds a Map<String,String> with (X-MeshOS-Key, [REDACTED]), (X-HM-Id, <runtime id>), (User-Agent, MeshOS-App), (Content-Type, text/plain) and a text/plain body — consistent with the MeshCore heatmap/coverage-map upload ("hm" = heatmap; the pool also carries coverage.json and UK town-name coverage labels). Excerpt: artefacts/r2-hm.txt.

Reachability from the photo-send path: the /img continuation is an async closure taking (dynamic, Uint8List, int) — its natural caller is the photo pipeline (image/jpeg codec functions feed Uint8List buffers). A static call graph could not be closed to the photo-send UI state machine (async continuations break blutter's call graph; no flat bl target and no pool closure object references the entry, i.e. it is reached via the Dart async machinery). So: plausible and shaped like a photo uploader, but not statically proven to be the photo-send upload.

Contacts/SMS feeding the upload: nothing. The upload closure's inputs are Uint8List (bytes) and an int. No pool object references contacts/SMS data structures.

Claimant's cited offsets/symbols: the task gave no exact offset list, only descriptions ("a URL to /img", "an MQTT endpoint", "an XOR loop"). Of the described items, the /img URL and AES-GCM usage do exist; mqtt.meshcore.co.uk:8883 does not; the "12-field TLV" and "contacts/SMS packing" have no corresponding artefact in the pool or code; the 0xB3 mask does exist as a key-derivation construct (see section 4.3).

4.3 XOR 0xB3 check (C5)

Initial scan found no XOR 0xB3 (EOR-immediate is impossible on ARM64 — 0xB3 is not a bitmask immediate — so the scan had to look for a materialised constant). The first version of this check used a wrong EOR-encoding mask and produced a false "CONTRADICTED"; a corrected scan finds the constant.

Corrected result — the XOR 0xB3 exists, exactly once.

ARM64 (apk/lib/arm64-v8a/libapp.so), disassembly in artefacts/r2-arm64-decode.txt:

0x0096beec  ldr   x0, [x26, 0x78]     ; THR
0x0096bef0  ldr   x0, [x0, 0x2320]    ; static field cache (is-initialised check)
0x0096befc  bl    0xa1a67c            ; allocate 0x40-byte object
0x0096bf08  add   x1, x27, 0x10, lsl 12
0x0096bf0c  ldr   x1, [x1, 0xe00]     ; [pp+0x10e00] List<int>(32) — the encoded blob
0x0096bf1c  cmp   x2, 0x20            ; loop 32 iterations
0x0096bf28  ldur  w3, [x16, 0xf]      ; element k (compressed Smi)
0x0096bf30  sbfx  x4, x3, 1, 0x1f     ; untag
0x0096bf3c  mov   x16, 0xb3           ; MOVZ x16, #0xB3  (0xd2801670)
0x0096bf40  eor   x3, x4, x16         ; EOR x3, x4, x16  (0xca100083)
0x0096bf48  strb  w3, [x4, 0x17]      ; store decoded byte
0x0096bf54  b     0x96bf10            ; loop
0x0096bf78  str   x2, [x0, 0x2320]    ; cache the derived 32-byte object, THR+0x2320

Pool source (blutter-out/pp.txt):

[pp+0x10e00] List<int>(32) [0x6c, 0x1e, 0xe9, 0xec, 0x86, 0xc7, 0xc6, 0x78, 0x9e,
0xe0, 0xd9, 0x07, 0x43, 0x6d, 0xd3, 0x96, 0x9e, 0x8c, 0x24, 0xc2, 0xe5, 0x44, 0xb5,
0xb0, 0xde, 0x14, 0x90, 0x6b, 0x8a, 0x83, 0xed, 0x18]

Decoded (element ^ 0xB3) = — 32 bytes of key-like material, cached in a Dart static field. The only reader found for that field is a getter at 0x96be88 (an undumped region; its surroundings reference dart:io proxy-configuration strings no_proxy/HTTP_PROXY), so downstream consumers of the derived value are not closed statically.

The x86_64 build contains the identical construct — xor rsi, 0xB3 at 0x9bc042 inside the same 32-iteration decode loop (artefacts/r2-x64-decode.txt); the second raw-byte "xor al, 0xB3" hit there is a false positive (a jmp rel32 displacement).

Consumer chain (follow-up scan, 2026-11-08): the decoded value is stored as Dart static late final zI nPa._nbe (obfuscated names; nPa is an abstract helper class in library vFk, zI is a crypto-object supertype whose concrete subclass iJ carries a (dynamic, int, List<int>) → int closure — a cipher-primitive signature). Access tracing (two-step pointer scan for the field-cache slot, plus direct-THR variant scan, plus object-pool xref) found the cluster pp+0x10de0–0x10e08 used only by the decode region 0x96be60–0x96c068: one writer (0x96bf78), one read-back (0x96beec), one field load (0x96bffc). The neighbouring object-store offsets 0x2318/0x2320/0x2328 are generic field/pool offsets used widely by unrelated closures — an initial scan mistake treated them as key readers; corrected.

Getter callers found: a flat BL scan of the whole .text shows the getter/validation region (0x4df9f0–0x4e0060) is called from exactly two sites, both inside [closure] void _kHg(dynamic, Uint8List) (wFk.dart, function start 0x4dd704). _kHg dispatches on bytes of its Uint8List argument (a byte-tagged envelope switch) and is the sole consumer of the XOR-derived key/validator. No photo, contact, or SMS-shaped data path reaches it; the /img photo upload uses a different, separately hard-coded key (X-MeshOS-Key header, section 4.2). The envelope format's meaning (licence code, signed message, or handshake blob) remains undetermined — but the "shared across photo, contact and licence code" claim collapses to "used from one byte-payload dispatcher." The validation text ("Invalid key (expected 128 hex characters)") belongs to this same cluster and may concern a different object or representation entirely.

Search coverage (revised):

• MOVZ w|x, #0xB3 anywhere in arm64 .text: exactly 1 (0x96bf3c, the loop above).
• MOV N/MOVZ/MOVK of Smi-tagged 0x166 or ports 0x4566 (8883) / 0xEBA (1883)

adjacent to an EOR: 0 hits (arm64 and x86_64).

• x86_64 xor r/m, imm with 0xB3: 1 real hit (the loop above) — the rest are

jump-displacement false positives.

• Pool Smi 179 / standalone 0x166: 0 hits (the only 0x166-matching lines are

elements of unrelated ≥512-entry int tables and blutter layout offsets).

• UTF-16LE (TwoByteString) mqtt.meshcore.co.uk in all three ABIs: 0 hits;

meshcore.co.uk (no scheme) UTF-16: 1 hit, inside the string "Checking meshcore.co.uk" context; 8883: 0 hits.

Fairness note on C5 (three independent model reviews — Claude Opus 5.5 in artefacts/opus-review.txt, a Codex-route second pass in artefacts/sol-review.txt (wording corrections, GO), and Gemini Argon in artefacts/gemini-review.txt (GO; recommended the C5 sharpening and the getter-caller scan, both actioned)): the reviewer's first EOR scan was methodologically weak and the initial CONTRADICTED verdict over-reached. The claimant's mask is real and embedded; what static analysis cannot establish is whether the derived constant is shared across the photo, contact and licence code paths. The photo upload carries its own separately hard-coded 16-byte key (X-MeshOS-Key header, section 4.2), and nothing contact-shaped consumes the derived 32-byte value in any reachable code. The nearby 128-hex validation text is not evidence of the derived value's purpose — it may concern a different object entirely.

Also — permission-model correction from the same review: runtime "dangerous" permission enforcement dates from API 23 (Android 6/2015); the SMS-provider change (no legacy READ_SMS-less access) dates from API 19 (KitKat). minSdk 24 post-dates both, so the C1 conclusion is unchanged, but the API history in an earlier draft was imprecise.

5. What static analysis cannot establish

• Whether the /img upload actually fires when a user sends a photo. The

continuation is async and reached via Dart's async machinery; the link to the photo-send UI path was not closable statically.

• The exact content of the POSTed body. Headers prove an encrypted binary upload;

whether the body is exactly the JPEG bytes, or bytes with anything additional appended, requires decryption at runtime (key [REDACTED — short form] is embedded, so it is recoverable) or a proxy capture.

• What /hm/upload carries. Body is built at runtime from a runtime id and is

text/plain; its semantics (coverage telemetry) are inferred, not proven.

• MQTT runtime behaviour. The mqtt_client machinery and meshos-topic-v1 exist,

but the broker address is not embedded — it must come from config/state at runtime (meshos_mqtt key, meshos_device_seen key). Static analysis cannot show where the broker string originates or whether any "kill" command is acted on.

• The exact meaning of the XOR-0xB3-derived 32-byte constant. Its single consumer

(dispatcher _kHg(dynamic, Uint8List), wFk.dart) is statically identified, but the semantics of the byte envelope it validates — licence code, signed message, or handshake — remain undetermined.

• Dynamic permission behaviour and any behaviour hidden behind code fetched at

runtime (none found statically: no dynamic code loading artefact in the dex or pool).

6. What a dynamic test would need to check

1. Network capture (mitm or packet capture, device with the app signed in):

• does sending a photo trigger POST https://tiles.meshcore.co.uk/img?
• body: exactly one blob? size = compressed JPEG? decrypt with key

(AES-256-GCM, nonce likely in-band) or just inspect entropy/structure.

• does /hm/upload fire at the same time? What does its text/plain body contain?
• any third endpoint contacted during photo send.

2. MQTT: instrument DNS/TCP traffic to see which broker the app connects to and what messages flow on meshos-topic-v1; check whether a remote message can alter app behaviour (kill switch) — needs a controlled broker + TLS interception or Frida hooking MqttServerClient.connect. 3. Frida hooks (device-instrumented, not in this review):

• HttpURLConnection/Dart HttpClient openUrl (all outgoing requests),
• the GCM encrypt calls of cryptography_flutter (plaintext in, ciphertext out),
• ContentResolver.query (assert none executes),
• the 0x9c28f4 continuation and its caller to settle the photo-path question.

7. Second-opinion review (Claude Opus 5.5) and additional checks run

An independent critique of the draft report by anthropic/claude-opus-5.5 (saved verbatim to artefacts/opus-review.txt) raised the points below; each was actioned:

Remaining Opus suggestions not actionable statically: Firebase google_app_id/project endpoint enumeration (the app's Firebase is performance telemetry only; D2/c.java) and source-vs-binary comparison (no public source found for v1.0.31). The signing-history check was subsequently completed (see the table above).

Second-reviewer verdict (Codex route): GO for a scoped static-analysis report after the wording corrections above; unresolved paths must remain explicitly unresolved. Explicitly not GO for any claim that shared-key reuse is established, that MQTT is absent as a capability, or that the app is generally safe.

8. Reproducibility

Tool paths and everything run:

• tools/jre21 (Temurin 21.0.9), tools/jadx 1.5.4, tools/apktool.jar 2.12.1,

tools/android-bt/android-14/{aapt2,apksigner} (build-tools 34.0.0), tools/blutter-src + built binary tools/blutter-src/bin/blutter_dartvm…, tools/r2 (radare2 6.2.6 built from source, wrapper tools/r2bin), libcapstone/libicu unpacked from Ubuntu .debs into tools/icu (no system install of any package — sudo is blocked in this container; everything is portable under ~/meshos-review/tools).

• Raw outputs: artefacts/ (badging, manifest tree, cert, release catalog, r2 and

blutter logs, pool-ref scanner scan_pool_refs.py, call-site dumps).

Appendix: notable pool strings near the upload path

[pp+0x114d8] String: "X-MeshOS-Key"
[pp+0x114e0] String: ""
[pp+0x114e8] String: "User-Agent"
[pp+0x114f0] String: "MeshOS-App"
[pp+0x114f8] String: "https://tiles.meshcore.co.uk/img"
[pp+0x11028] String: "Content-Type"
[pp+0x1ab68] String: "application/octet-stream"
[pp+0x1ab70] String: "X-MeshOS-Enc"
[pp+0x1ab78] String: "gcm"
[pp+0x15128] String: "https://tiles.meshcore.co.uk/hm/upload"
[pp+0x15130] String: "X-HM-Id"
[pp+0x12260] String: "meshos-topic-v1"
[pp+0x11608] String: "meshos_mqtt"