Reverse engineering
Published installers are an attacker surface. Anyone who can download the app already has the program. Closed source does not hide how the client is shaped once those builds ship.
This page is that surface in product language: what reverse engineering recovers, what risk that creates for users, and what stayed hard. Narrative write-up: Reverse-engineering a closed-source Glitr build. Leftover catalog: Residual risk.
Scope
In scope: shipped clients people can download — Linux TUI, desktop .deb, Android APK, and web — plus this site’s public docs.
Out of scope as a secrecy claim: treating the closed messenger tree as something an installer cannot reveal. Open source remains a roadmap goal, not a current product claim.
Two vocabularies appear below. Do not mix them.
| Vocabulary | Words | Role |
|---|---|---|
| Product status | Documented / Mitigated / Partial / Open | Same four words as the rest of this folder |
| Investigation tags | observed / derived / inferred / unknown | How glitr-decompiled labels evidence in evidence/ |
A reconstruction is not an audit and not Glitr’s product source.
Adversary
| Adversary | Capability | In scope |
|---|---|---|
| Reverse engineer with public installers | Downloads builds, mines strings and embedded schema, unpacks APK/deb assets, mirrors docs, uses AI agents | Yes |
| Lookalike publisher | Ships a familiar chat UI that speaks a parallel dialect — or wraps malware in Glitr chrome | Yes — as residual social engineering |
| Deeper native analyst | Disassemblers / decompilers aimed at the same binaries | Yes in principle; the published research pass did not complete that path |
What that adversary can do without deeper native RE: recover mailbox layout, outer ciphertext field names, password-envelope parameters, crate-name maps, and a toy client that talks to itself.
What that pass did not establish: full decrypt of real Glitr messages with a reconstructed client (official ↔ recon). The inner recipient cascade stayed unknown.
Threats
| Threat | Status | Asset / impact | Notes |
|---|---|---|---|
| Closed source as secrecy | Open | Protocol shape, architecture names | Installers are public; hiding source is not hiding the program |
| Architecture / crate-map leakage | Documented | Module boundaries | Embedded debug paths and strings name crates across the stack |
| Mailbox schema leakage | Documented | Sealed vs host-visible folders | GraphQL SDL and folder rules fall out of the binary |
| Outer cascade wire recoverable | Partial | Ciphertext layout on git outbound | Field names and ML-KEM outer shape recovered; sealed mail still needs the unlock password |
| Password-envelope parameters recoverable | Partial | At-rest sealing | Argon2id / AES-GCM shape recovered; the secret is still the password |
| Inner recipient cascade (Signal / PQXDH / MLS) | Partial | Message plaintext via RE alone | Practical RE barrier in the published pass; not a permanent hardness claim |
| Recon ↔ recon interop | Documented | Parallel dialect | A reconstructed client can encrypt and decrypt with another copy of itself |
| Official ↔ recon full decrypt | Open | Break E2E to real peers via RE | Not established; do not treat RE as opening the messenger |
| Lookalike / malware-wrapped client | Open | User trust, credentials typed into a fake | Familiar UI does not require ratchet parity |
| Docs-mirror false confidence | Documented | Analyst / reader judgment | Copying this site into a tree inflates “completeness” without proving behavior |
| Cheaper keep-up with new builds | Open | Ongoing RE cost | Automating “ingest the new installer” may shrink the closed-source window |
| Supply-chain confusion | Partial | Which binary the user runs | Trojaned lookalike vs official CDN / service worker — see Platforms |
Password sealing and the recipient cascade remain separate jobs. Recovering how envelopes look is not the same as opening a mailbox without the password. Recovering the outer wrap is not the same as peeling the inner ratchet that unlocks real Glitr ciphertext.
What the decompile showed
Public research tree: positive-intentions/glitr-decompiled. Ledger: evidence/FINDINGS.md. Tags below are investigation tags, not product status words.
Artifacts
| Artifact | Tag | Depth |
|---|---|---|
Linux TUI (glitr-tui-linux) | observed | Richest oracle — strings, symbols, embedded GraphQL SDL |
Linux GUI (.deb) | observed | Unpacked assets (webview layout, isomorphic-git bundles) |
Android (.apk) | observed | Unpacked assets; full APK code RE deferred (no JADX in that environment) |
| Web build | observed | Digests and bundled surfaces; deep WASM inspect unsupported in that pass |
| Docs mirror | observed | Scraped glitr.io pages — documentation recovery, not implementation recovery |
Deep native decompile (Ghidra / Hopper) and JADX were unavailable for that run. See evidence/tooling-status.md in the research repo.
Schema
| Claim | Tag |
|---|---|
| Messaging schema v10 embedded in the TUI binary | observed (evidence/messaging.v10.graphql) |
| Public docs at the freeze still described an older version (v8) | observed |
| Sealed collections: contacts, inbox, sent, groups, protocol-sessions, group-protocol-sessions, file-transfers, profile-secrets | observed |
| Peer-visible: profile-public, outbound, readreceipts, signaling, devices | observed |
A freeze is a point in time. Live product and docs keep moving.
Crypto shape
| Layer | Tag | Reconstruction status |
|---|---|---|
| Password at rest (Argon2id 19 MiB, t=2, p=1 → AES-256-GCM) | observed | Shape matches official fixtures |
Hybrid v1 (wrappedKey / nonce / ciphertext) | observed | Implemented in the research tree |
| Cascade v3 outer (ML-KEM-1024 field names and sizes) | observed / derived | Emits official-shaped outbound JSON |
| Cascade inner (Signal / PQXDH / MLS bytes after outer peel) | unknown | Not recovered without deeper native analysis |
protocolBundles key names (signal, pqxdh, mlkemPublic, mlsKeyPackage) | observed | Encodings beyond names stayed unknown |
Interop
| Question | Answer | Tag |
|---|---|---|
| Recon ↔ recon decrypt? | Yes (fixtures/official-interop.sh) | observed |
| Official → recon full decrypt? | Not established | unknown |
| Recon → official full decrypt? | Not established | unknown |
| Live frame names / toy WebRTC lab? | Partial (recon ↔ recon) | observed |
| Tor / full TUI chrome / deep Android UI? | Deferred | unknown |
Looking Glitr-shaped is cheaper than being Glitr. The scary residual for users is a lookalike that is good enough to trick someone — not a perfect copy of the closed tree.
What this does not mean
- The research tree is not an independent security audit.
- A reconstruction is not the product — tests, formal-check scaffolding, Drive, Office, Local AI, and the multi-project split did not come back as shipping code from installers alone.
- Recovering outer wire and envelope parameters is not plaintext without the unlock password or session keys.
- Closed source did not stop reconnaissance. It also did not open the messenger to official peers in that pass.
Links
- Research reconstruction: positive-intentions/glitr-decompiled
- Ledger:
evidence/FINDINGS.md - Blog: Reverse-engineering a closed-source Glitr build
- Architecture
- Cryptography
- Platforms
- Residual risk
- Roadmap
Next leftover catalog: Residual risk.