Software you inherited, explained with evidence.

seven engagements, every claim cited

Agencies and operators inherit software they cannot read: a contractor’s app with no source, a vendor tool that touches client data, a site whose builder stopped answering. We analyze the shipped build itself, native, Electron, .NET, or a live page, and hand back a report in which every claim cites the evidence behind it and every gap is named as an unknown instead of guessed. Request a quote →

Seven engagements.

The shapes this work takes. Each one starts from the exact build you hand us and ends with a deliverable a client can act on without reading a decompiler.

  1. Rebuild an app nobody can maintain

    A working build, no source, a contractor long gone

    An obligation list: every rule the port must preserve, with evidence and a test; the design choices it may change; the unknowns the build alone cannot settle. Then the port, built against that list and checked claim by claim.

  2. Check that the source you were handed matches what ships

    Taking over an agency’s app before paying for maintenance

    Module by module: unchanged, modified, removed, or unknown, with digests. What is in the build that has no source in the repository.

  3. Find out what a vendor tool sends out

    Licensed software that touches client records

    The hosts the binary names, the hosts observed during a controlled run on a test installation, what the code does with data at rest, and what could not be determined. “Not observed” is never written as “never sends.”

  4. Explain your own site after the builder stopped answering

    A checkout rule or estimate nobody on staff can explain

    The browser-side rule with evidence, or the endpoint contract plus an explicit unknown for logic that lives on the server, and the next place to look.

  5. Find what changed when an update broke a workflow

    A vendor that says nothing changed

    Changed modules or functions between the two builds, runtime differences when both can be run with the same steps, and the hypotheses labeled as hypotheses. Co-change is not causality.

  6. Read the data a tool keeps for you

    Migrating off a tool that owns years of your records

    A format description in which each field is an observation (the schema the code writes) or an inference (what the code does with it), and a converter whose mapping cites the evidence.

  7. Accept a contractor’s rebuild

    Signing off on someone else’s rewrite

    Claim by claim: pass, fail, or unknown, with evidence on both sides, and the evidence bundle as the acceptance record you keep.

How the work is done.

The same discipline every time: route the artifact, state a hypothesis, probe with the smallest tool that tests it, sort the result into observed, inferred, or unknown, try to refute the conclusion, then write it down. The toolkit underneath, REA, is open source; the decision layer we run on top of it is open source on GitHub, so a reviewer can see how a report was produced.

  • The build file is never uploaded. Excerpts of it are.

    REA, an open-source reverse-engineering toolkit, runs on our machine against the exact file you hand over and binds every piece of evidence to that file’s digest. Strings, symbol names and decompiled excerpts are read by Claude and by Jev, a decision model from TypeSafe; the full list is under “What leaves the machine” below.

  • Every claim cites evidence.

    Observations carry an evidence ID and a locator. Inferences name the observations they rest on and what would refute them. What the evidence cannot establish is recorded as an unknown, with the probe that would settle it.

  • Static analysis never pretends to be runtime.

    Code that exists is not code that ran. “Sent”, “executed” and “contacted” appear only for behavior observed during a declared capture on a test installation you provide, and only for the window observed.

  • A fast decision model reads the long lists, so attention goes to the few that matter.

    A binary has thousands of strings and procedures. Jev ranks and classifies them in one request; Claude, running the toolkit, decompiles only what a hypothesis needs, and every conclusion is checked against its evidence before it is written down.

What you get.

Three things, in every engagement that reaches the end.

The report
Observations first, each with its evidence ID. Then inferences, each naming what it rests on. Then unknowns as questions, each with the probe that would answer it. Unknowns are a deliverable, not a failure: a client who knows what was not established can decide what to do about it.
The evidence bundle
A file holding the record behind every ID in the report. It can be re-opened in a later engagement, and when the vendor ships a new release it is the baseline the comparison runs against.
For a rebuild
The obligation list: behaviors the port must preserve, each with evidence and a verification method; design choices the port may change, stated; unknowns kept open rather than silently decided.

What we need in writing first.

Four lines in the engagement letter, before the first tool call.

Who holds the rights
You hold the rights to the software (an assignment from the contractor who built it, or work for hire by your own employees), your license permits analysis for interoperability or security review, or the vendor agreed in writing. When in doubt, your counsel decides, not us.
Which exact build
File name, version and SHA-256. Evidence is bound to the digest, so the report is about that build and no other.
Where captures may run
Staging rather than production, a test account, a machine or user account that can be wiped. A capture runs the program with the permissions it is given and is not a sandbox.
What leaves the machine
The build never does. Strings, symbol names, decompiled excerpts and the draft report are read by Claude (Anthropic) and by Jev (TypeSafe). If that is not acceptable, the engagement runs without the decision model and with whatever use of Claude your agreement allows.

What fits, and what does not.

  • Targets: macOS, Linux and Windows native binaries and app bundles, Electron and JavaScript bundles, .NET assemblies, archives and installers, and live websites or Electron apps reachable in a browser we can observe. Analysis runs on macOS or Linux, so a Windows app is analyzed statically and its runtime behavior comes from your own acceptance tests.
  • Entitlement: software you hold the rights to, software your license lets you analyze, or software whose vendor has agreed. We do not take engagements where that is unclear, and we do not extract credentials, cookies, or personal data to prove a point.
  • Pricing: quoted per engagement, after an inventory of the build: how many modules or procedures it has and how many separate questions you are asking. A request that spans several features is priced as several questions, not one.
  • Not this: analysis of a source repository you already have, which needs none of this; and Android packages, which we inventory as archives today and will take on fully when the toolkit does.

Send us the build and the question.

Tell us what the software is, who holds the rights to it, which build you have, and what you need from it. We come back with the inventory and a quote.

Request a quoteThe platform →