Research notebook / Reverse engineering / 02

Reverse engineering an unfamiliar binary

A method for moving from observed behavior into the implementation beneath it, without losing the evidence along the way.

By SeichsMethod noteReverse engineering
Blue engraved study of an ancient Greek temple and olive tree
Plate III / Beneath the surfaceObservation · Structure · Evidence

Reverse engineering starts with a simple question: what does this program actually do? The useful answer comes from observations that can be repeated, traced, and explained.

01 / Observation

Begin with behavior.

Start by recording the inputs, outputs, and visible state changes. Keep each observation separate from the explanation you think might account for it. That distinction makes it easier to change direction when the evidence disagrees with the first theory.

Record the exact build, environment, and test case before opening the disassembler. An observation tied to a specific binary is easier to revisit than a note that only says “it seems to happen sometimes.”

“The most useful clue is often the gap between what a program appears to promise and what it actually does.”
02 / Structure

Build a map.

Move from observed behavior into the binary’s structure. Identify the relevant functions, data paths, and trust boundaries, then connect each one to an observation. A small, accurate map is more useful than a large collection of unlabeled screenshots.

Blue engraving of an ancient marble relief with two figures

Keep the map small enough that every edge means something: a call that actually occurs, a value that actually flows, or a boundary the program actually crosses. Revisit the map whenever a new observation contradicts it.

03 / Assistance

Use AI carefully.

AI can help compare hypotheses, summarize unfamiliar code, or suggest where to look next. Each suggestion remains a lead until direct inspection and a repeatable test support it. The writeup should show that handoff clearly.

ObservationHypothesisInspectionVerification

That sequence gives readers a way to distinguish the tool’s contribution from the researcher’s conclusion.

04 / Record

Preserve the trail.

A strong conclusion includes the conditions under which it holds, the evidence that supports it, and the limits of what was tested. When a result changes after one variable changes, say so. That is often where the most interesting explanation begins.

A useful research record lets someone else trace the path from behavior to code and back again. It names what was examined, what remains unknown, and which claims still need a repeatable test.

← Back to all notes