Reverse-engineering a closed-source Glitr build
Glitr does not publish the messenger’s source code, but it does ship installers people can download. A low-effort AI reverse-engineering pass on those builds showed how little that closed path hides.
Glitr is a private messenger. Chat runs on the device. Optionally a git repository the user owns becomes the mailbox. There is no Glitr account and no company inbox holding the thread.
The product path is still closed-source. An older iteration and the Signal handshake library are public; the messenger itself is not. That goes against the usual security advice. Open source is a goal, not a current claim — see the roadmap FAQ.
The question for this write-up is simple: if someone only has the published installers and the docs on this site, how far can they get — especially with help from an AI agent?
Why red-team a shipping client?
“Closed source” sounds like a secret. For a normal website backend, that can mean something. For an app that runs on the user’s phone or laptop, the user already has the program. Hiding the source is not the same as hiding how it works.
An older JavaScript iteration of this stack would have been easy for an AI to swallow. Moving to a more serious native stack was expected to raise the bar for a human. For an agent that can chew through installed apps, it did not feel like much of a bar.
The point of the exercise was also to clarify what “defense” still means. Not “nobody can read the code,” but: what does a fake lookalike get wrong, and how hard is it to keep up when new builds ship?
What was done
The pass used Cursor’s Auto agent (not the strongest paid model) and REA — a reverse-engineering helper tool. Inputs were a few Glitr installer builds (phone, desktop, web, and terminal) plus the public documentation.
The terminal build was the easiest way in: lots of readable clues inside the file, and one shared codebase that shows up across the other platforms.
There was no deep, expert-level take-apart with heavyweight disassembler tools. The point was low effort: what falls out when an agent is aimed at the shipped app and the docs for a few prompts.
What came out
The research workspace is public:
https://github.com/positive-intentions/glitr-decompiled
Treat it as a messy AI draft with a purpose. It dumps a lot of complexity into one folder. Real Glitr is many separate projects. The draft also misses a lot of the careful work kept for the product path — strong tests, formal-check scaffolding, demo galleries, Drive, document editing, Local AI, and more.
That gap is not huge for someone who knows what they are doing. The draft is also not maintained as a replacement for Glitr. Maintaining a public “fake Glitr” would undermine the closed path on purpose.
Below: what that draft actually recovered versus what only looked recovered — without publishing private source.
What it changes
- Once an app ships as installers people can download, closed source is a weak way to keep secrets.
- A reconstruction is not the product. Taste, tests, docs, and lots of small protocol details are most of the work. The recovered code is only a fraction.
- The scary case is not a perfect copy of the source. It is something that looks like Glitr and talks enough like it — or hides malware behind a familiar chat UI.
- Automating “ingest the new installer” may make it cheaper to keep up with releases. That may pull the open-source timeline forward. Client-side closed source was not expected to be this easy to undermine.
The code is still only part of a messenger. Clear docs, a threat model, and honest residual risk matter whether or not the source is public.
In one minute
The decompile is a research reconstruction: AI-assisted guesses from installer files and this website. It is not Glitr’s product source, and it is not an audit.
Think of two layers of wrapping on a parcel. Someone who only has the shipped app can often learn how the outer wrapping looks. Opening the inner locks that make real Glitr messages decrypt is much harder. Copying the brochure (the docs) into a folder can make a project look complete even when the factory is missing.
What was easy to recover
From the shipped app and public docs, a lot of the “shape” came back:
- How mailbox files are laid out (what folders exist, what is sealed vs visible to a host).
- How ciphertext looks on the outside — field names and sizes for the outer encryption wrap.
- How files on disk are locked with the connect password.
- Enough to build a toy client that talks to itself (two reconstructed mailboxes sending and reading each other’s outer-shaped messages).
That is useful reconnaissance. It is also the part a brochure and a few installers make cheap.
What stayed hard
Harder — or missing — in that pass:
- The inner encryption that makes a message decrypt with the real Glitr app (the full ratchet stack behind the outer wrap).
- The real product layout: many separate projects, not one messy folder.
- Bigger product surfaces such as Drive, document editing, and Local AI — named in docs or path strings, not reconstructed as working product code.
- The careful tests and formal-check scaffolding the docs talk about — mentioned on the website, not handed over by the installer.
So: looking Glitr-shaped is easier than being Glitr.
The docs trap
The research tree includes a copy of these docs. That is like photocopies of the brochure sitting next to a half-built engine. An AI that pastes documentation into stub code scores high on “sounds right” and can still fail to open a real Glitr message.
When judging a decompile, separate:
- Clues from the installer
- Behavior proven against real sample data
- Text copied from the website
Only (1) and (2) are reverse engineering. (3) is reading the manual.
Why that matters
- For a client app, closed source is a weak secrecy boundary once people can download the installers.
- A lookalike that speaks a parallel dialect can still trick users — familiar chat UI, wrong guts (or malware).
- Glitr is still not open source. Signal’s handshake library is public; the rest of the messenger is not. Open source remains a goal — roadmap.
Details for people who want the ledger
Everything below is for readers who want the tags and scorecard. Same facts as above; denser language.
How to read the tags
Every claim uses one of these:
| Tag | Meaning |
|---|---|
| Public | Anyone can check it from published installers, the glitr-decompiled evidence/ notes, public docs/galleries, or the decompile repo |
| Author | Checked against private product trees. Third parties cannot verify this without source |
| Unknown | Not established at this write-up’s fidelity (binary-level detail may still be open) |
The research repo’s own notes use observed / derived / inferred / unknown in evidence/FINDINGS.md — that stays the Public baseline. Author tags never quote private paths or code. This is not an audit and not a claim that the decompile is correct.
Scorecard
| Area | Recovered? | Tag |
|---|---|---|
| One-folder sketch of library names | Partial | Public + Author |
| Real multi-project product (galleries, formal checks, AI, office) | No | Author |
| Mailbox schema shape; sealed vs visible collections | Yes (one frozen build) | Public |
| Docs version vs that build | Docs lagged the installer (older docs vs newer schema in the binary) | Public |
| Newer features (e.g. Drive) after that freeze | Not in that installer snapshot | Author |
| Password wrapping on disk | Yes | Public |
| Outer encryption wrap (cascade v3 / ML-KEM-1024 shape) | Yes | Public |
| Inner encryption (Signal / PQXDH / MLS bytes) | No | Unknown (Public); product implements them (Author) |
| Toy client ↔ toy client decrypt | Yes | Public |
| Official Glitr ↔ reconstruction full decrypt | Not established | Public |
| Live chat frame names; toy WebRTC lab | Partial | Public |
| Tor / full terminal UI / Android UI | Deferred | Public |
| Formal-check + security-audit trees as code | Not recovered from installers | Public + Author |
| Docs copy making the tree look complete | Inflates confidence | Public |
Project shape
In plain terms: the draft is one big folder of library names; the real product is many separate projects.
Public. The reconstruction is one Cargo workspace (messaging API, crypto, db, git client pieces, and similar). Strings inside the terminal build also name other libraries, so an agent can sketch a product map from names alone. See the repo for the full list.
Author. Shipping Glitr is split across sibling projects (messaging, crypto, storage, live links, Tor, UI, Local AI, Drive/Office, and more). Names in a string dump are not the same as recovering demos, proof harnesses, or real boundaries.
False confidence. Seeing a library name in an installer is not recovering its tests or formal-check work.
Mailbox schema
In plain terms: the draft froze one build’s file layout; the live product has kept moving.
Public. From the terminal build’s schema extract, reconstruction treated messaging schema v10 as the source of truth. Public docs at the time still described an older version. Sealed vs host-visible folders are recoverable. Outer ciphertext field names matched official sample data.
Author. The live product and docs have continued (for example Drive and later schema versions). A freeze is a point in time — not the tip forever.
Encryption stack
In plain terms: outer wrap and disk password locking came back; the inner locks did not.
Public. Password-at-rest envelopes were rebuilt and tested against official samples. Cascade v3 outer wire shape (including ML-KEM-1024 sizes and field names) was recovered. Bundle key names are visible. Official inner Signal / PQXDH / MLS byte layout after peeling the outer wrap stayed unknown without deeper native analysis in that pass.
Author. The product implements the full recipient stack described in the public cryptography docs. Treating the inner payload as a shortcut format is not parity with the shipping ratchet.
Unknown. Exact inner encodings needed for official ↔ reconstruction decrypt of real messages.
Can the draft talk to real Glitr?
In plain terms: two toys can talk; talking to the real app was not shown.
Public. The research glitr-compat client can run two reconstructed mailboxes and decrypt both ways. Official → reconstruction and reconstruction → official full decrypt were not established. A small live-link lab exists for the toy side; Tor and full official live paths were deferred.
Author. That is the clone risk that matters: protocol-shaped without ratchet-compatible. A hostile lookalike can still social-engineer users — or wait until someone finishes the inner peel.
Platforms and product surfaces
In plain terms: the terminal installer leaked the most; big GUI features barely showed up as code.
Public. The Linux terminal build was the richest artifact. Web builds expose browser/WASM surfaces. Android stayed shallow without a full APK decompile tool in that environment. Tor and full terminal UI parity were deferred.
Author. Drive, Office editors, Local AI, and related GUI weight are real in the closed product and documented here; they are not “decompiled” just because names appear in a path list.
Missing weight and the docs copy
In plain terms: the brochure made the draft look heavier than the installer proved.
Public. The reconstruction does not ship formal-verification trees, an in-house security-audit folder, or the test density the docs describe. docs-mirror/ copies glitr.io into the tree — documentation recovery, not implementation recovery.
Author. That careful work exists in how the real project is built and explained. Recovering a folder name does not recover the discipline. AI drafts also prefer one repo; the multi-project split is intentional.
Bottom line (ledger)
Even without source: architecture names and mailbox layout leak; outer wrap and password envelopes are recoverable; a motivated agent can stand up a parallel client that talks to itself.
What stayed expensive: faithful inner encryption, the real multi-project surface, and keeping up as the private tip moves.
Closed source did not stop reconnaissance. It also did not open the messenger. Status remains: Signal handshake library public; the rest not — roadmap.
Links
- Research reconstruction: positive-intentions/glitr-decompiled
- Ledger file:
evidence/FINDINGS.mdin that repo - Reverse-engineering helper: REA
- Product: glitr.io, app.glitr.io
- How the pieces fit: Architecture
- Crypto story: Cryptography
- Open source FAQ: Roadmap
Teams that ship client apps can learn more by taking their own installers apart than from another argument about whether closed source is “dead.” Feedback welcome when the docs are unclear.