Does MeshOS secretly upload your contacts when you send a photo?
TL;DR — no.
A licence-bypass seller claimed MeshOS secretly reads up to 2,048 contacts and 1,792 text messages when you send a photo, then uploads them. We pulled apart the real app without installing or running it. That claim is false by Android's own rules: the app never requests the permissions that would make contacts or messages readable, so the reads are impossible — and no such code exists in any form.
What is true: the app sends an encrypted photo upload to the developer's image server (contents beyond the photo unverified without a phone test), keeps an obfuscated 32-byte secret used by a single message-data function, and has MQTT machinery whose claimed broker and port appear nowhere. Details and limits below.
The claims, and what we found
| The claim | What we found | Confidence |
|---|---|---|
| "Reads up to 2,048 contacts and 1,792 SMS bodies" | False. The app never requests the Android permissions that would make contacts or SMS readable. Android blocks those reads at system level for undeclared apps — a query would fail outright. No contact- or SMS-reading code exists anywhere in the program, including every loophole we specifically hunted for. The numbers 2,048 and 1,792 don't appear in any form. | High — this is enforced by the operating system itself, not by our analysis |
| "Packs them into a 12-field encrypted blob and uploads it" | Not supported. No code produces such a structure. The upload that does exist is a single encrypted byte-blob of a photo, not a contact form. | High (independent of the first claim: the claimed packing code doesn't exist) |
| "Encrypts and POSTs to tiles.meshcore.co.uk/img" | True, with caveats. That address is in the app, and a photo upload path exists: it sends an encrypted binary body with a hard-coded key identifier. The encryption uses AES-GCM (a standard strong cipher). Whether the body contains only the photo needs a runtime test. | Mechanism confirmed; contents unknown (honest limit) |
| "Sends a second harvest upload alongside the photo" | Not supported. A second upload endpoint does exist — but it carries a text body tied to a map/coverage ID, consistent with the app's radio-coverage mapping feature, not personal data. The word "harvest" appears nowhere. | Moderate — reads as coverage telemetry; final confirmation needs a runtime look |
| "Has an MQTT kill switch at mqtt.meshcore.co.uk:8883" | False as stated. That hostname and port appear nowhere — not as text, as UTF-16, or as raw numbers in the program, in any of its three builds. The app does contain general MQTT software with a settings key, so its broker (if used) is configured at runtime. | High |
| "Uses a shared XOR mask 0xB3 across photo, contact and licence code" | Half true. The 0xB3 mask is real — exactly one function in the whole app uses it to decode a built-in 32-byte secret. But it is used from exactly one payload-checking function; it never touches the photo upload (which has its own key) and nothing contact- or SMS-shaped reaches it. | High on both halves |
How we can be sure about the contacts claim
This one is the clearest, because it's not a matter of reading the app's code carefully — it's how Android works. To read contacts or SMS, an app must declare those permissions in its manifest (the app's ID card) and be granted them. MeshOS declares neither. On modern Android, an undeclared permission can never be granted, so any attempt to read contacts or messages fails outright, by design.
We also checked the workarounds a sneaky app might use, and none exist in MeshOS: no accessibility services, no notification listeners, no "shared user ID" tricks, no downloading of extra code at runtime, no SMS-manager use, no native library that opens network sockets (except the standard Flutter engine). If a phone ran this app with a network monitor watching, the claimed harvest simply could not occur.
The photo upload — the honest caveat, in plain terms
When you send a photo, the app sends an encrypted bundle to the developer's image server. Here is what we know for certain: the address, the headers it sends (including a fixed app-identifier key baked into the app), and that it flags the content as GCM-encrypted. Here is what we cannot know statically: precisely what's inside the encryption. It is tagged as a photo-sized upload processed from the camera pipeline — everything points to "the photo, and only the photo" — but certainty needs a phone-based test that decrypts the payload (the key is baked in, so the test only needs an hour and a proxy tool).
Worth saying plainly: the upload is designed by the developer and the app identifies itself honestly in its headers. An encrypted upload of your photos to a mapping/telemetry server is still something you might reasonably want to know about — that's a fact worth the developer publishing, not a scandal. It is not the covert contacts-and-texts harvesting that was claimed.
Could the seller's evidence have been real?
The 0xB3 mask and the MQTT client library are in the app — someone looking at the binary without understanding it sees exactly those fingerprints and could spin the story we were asked to check. The licence system uses cryptographic key validation (which is why a licence-bypass seller has an interest in misreading it). The numbers don't lie, though: each individual claim dissolves under inspection, and the load-bearing one — contacts — is impossible by Android's own rules.
For the full technical evidence — commands, addresses, hashes, per-ABI scans, the reviewer corrections, and what a runtime test would need — see the full technical report (also available as Markdown).
Limitations of this analysis
- Static only: the app was never installed or executed; no meshcore server was contacted.
- The exact contents of the encrypted photo upload, and the runtime broker of the MQTT feature, cannot be determined from the binary alone.
- The analysis covers v1.0.31 (the claimed version) and was re-verified against v1.0.35 (current release) — both clean of the claimed indicators, and both signed with the same certificate.
- Three independent AI models reviewed this analysis; one reviewer correction (a scanner bug that briefly under-stated the 0xB3 finding) is documented in the report, as is the fix. We believe in showing our corrections, not hiding them.
Contact and rights
This is an independent, non-commercial analysis. We make no accusation about the developer's intent; where something is worth improving (an honest header describing the photo upload, or documentation of the telemetry endpoints), that's feedback the developer should feel free to respond to publicly. The claims tested are quoted from a public seller of licence-bypass tools; no paraphrase beyond the seller's own words is used. Errors and corrections: the analysis file documents its own revision history.