Aletheia

Aletheia — Greek for un-concealment, revealing what a program hides — is a tool for reverse-engineering software: taking a finished, compiled program apart to understand how it works, even when you don't have its original source code. Security researchers use tools like this to study malware; engineers use them to make sense of systems nobody documented.

It's built on one idea that most tools in this space get wrong. The usual approach is like editing a document with no undo — when you rename something or make a guess about what a piece of code does, the old state is simply gone, and a wrong guess can be hard to walk back. Aletheia treats analysis the way Photoshop treats an image, or the way git treats a project's history: as a stack of layers you can add, hide, reorder, branch, and compare, with the original program always preserved underneath, untouched.

Analysis as layers you can peel back

The original program sits at the bottom as an untouchable base. Everything the tool works out on top of it — where the functions are, what to name them, what a chunk of data means, what happened while it ran — is added as its own layer. Because the layers stack in order, you can:

• hide a layer and instantly see the raw program underneath, without the interpretations;
• branch to explore two competing theories about the same code at once;
• compare two stacks to see exactly what a given step changed.

One feature falls out of this for free that other tools can't easily add: color every part of the program by which step figured it out — a heatmap showing where each conclusion came from and how confident the tool is in it. Analysis here isn't treated as certain; it's a best guess with a confidence attached, and the tool stays honest about that.

Everything is reproducible

Each analysis step is designed to be perfectly repeatable: give it the same inputs and it always produces the exact same result, with a unique fingerprint. That single property quietly powers four things that are usually built as separate, complicated systems:

• Speed — results are remembered, so flipping a setting only recomputes the parts that actually depend on it.
• Undo and branching — since nothing is ever overwritten, undo is instant, and exploring an alternative is as cheap as it is in git.
• Sharing — a piece of analysis can be handed to a teammate as something they can independently reproduce and verify, rather than take on faith.
• Teamwork at scale — heavy work can be split across many machines just by handing off the parts that aren't already done.

Because so much rides on that repeatability, a good chunk of the engine exists purely to defend it — automatically re-running steps to confirm they produce identical results before anything they output is trusted or shared.

Debugging malware without running it

Debuggers normally work by actually running a program and pausing it — which is exactly what you don't want to do with malware. Aletheia's main debugger instead uses a built-in, simulated processor that steps through the program's instructions without ever really executing them. There's no real process that could escape, and the same approach even runs safely inside a web browser. (A traditional "attach to a running program" mode exists too, for the cases where you do want the real thing.)

The elegant part: whatever the program is doing at the moment you pause it — where it is, what's in memory, the current values it's working with — becomes just another temporary layer on top of everything else. Every view updates to show that live state the same way it shows static analysis. Debugging isn't a separate mode you switch into; it's simply more layers. You can even scrub back through recorded history on a timeline.

One engine, many front doors

All of the actual analysis lives in a single shared core, and everything else is a thin shell around it — so there's no duplicated logic and no version that quietly behaves differently:

• a desktop app — the main way to use it;
• a command-line tool for automation and scripting;
• a team server for collaboration;
• an install-nothing browser playground for trying it out;
• a Python package for driving it from your own code.

There's also a hosted web version that runs the same engine walled off safely in the background, so a malicious file that manages to crash the analyzer can't take the website down with it. And no matter how large the program being examined — even huge files with millions of instructions — the interface only loads the slice you're looking at, so it stays fast and responsive.

Built to survive hostile input

The tool understands programs written for several different processor families — the Intel/AMD chips in most laptops, the ARM chips in phones, and RISC-V — all behind one consistent interface. Since its whole job is to pull apart files that are often deliberately malformed or malicious, one hard rule runs throughout: it must never crash, no matter what garbage it's handed. That rule is backed by heavy automated testing, including cross-checking its results against a well-known industry tool to catch any disagreement.

Where it stands

The core is working: it can load real-world programs, analyze their structure, run its own scripting and decompiler, and debug them with the built-in simulated processor. Ongoing work is about breadth — supporting more processor types, adding reporting and collaboration, splitting heavy jobs across machines, and the hosted web version. It's a solo project, developed with a consistent emphasis on reproducibility and testing throughout.

Gallery