Engineering methods
Evidence-Based Reverse Engineering of Software Systems
Identify an artifact, distinguish observations from inferences and preserve a reproducible investigation. Start with a harmless local hashing example.
Begin with a question and an authorized artifact
Reverse engineering becomes easier to review when the question is narrow. “Which exported interface changed?” can be investigated more precisely than “What does this program do?” Define the artifact, the permission to inspect it and the observable result you want to explain. A public demonstration or an artifact you created is a useful starting point.
REI Reverse Engineer organizes this work around local artifacts and evidence. Its public documentation distinguishes bounded built-in inspection, external tool adapters and desktop preview features. That distinction matters: a named tool in a catalog is not proof that a tool is installed or that its output has been reviewed.
Preserve identity before interpreting content
A filename is not a stable artifact identifier. Preserve a cryptographic digest, size and the collection context before extracting facts. The following standard-library example uses a harmless synthetic file. Repeating it should produce the same digest; changing a byte should change the digest.
from pathlib import Path
import hashlib
artifact = Path('synthetic-interface.txt')
artifact.write_bytes(b'export: process_frame_v1\n')
digest = hashlib.sha256(artifact.read_bytes()).hexdigest()
assert len(digest) == 64
assert digest == hashlib.sha256(artifact.read_bytes()).hexdigest()
print(artifact.name, artifact.stat().st_size, digest)This demonstrates content identity. It is not a signed provenance statement, a malware verdict or proof of legal ownership. A reviewer still needs to understand how the artifact was obtained and what transformations occurred before analysis.
Separate observations from hypotheses
“The module imports a function named validate_packet” is an observation about structure. “Every packet is validated before storage” is a behavioral claim. The second statement needs control-flow evidence, a suitable runtime trace or another observation that connects the import to the relevant execution path.
Use explicit confidence labels. An observation should point to a byte range, symbol, parser output or trace. An inference should state the observations it depends on and its alternatives. Unknowns should remain visible. Filling a gap with a plausible narrative makes a report smoother but less useful.
Diff structure, then test the explanation
Version comparisons can reveal changed exports, imports, sections, resources or configuration defaults. Compare matching artifact identities and state which parser or adapter produced the comparison. A structural change is a clue, not automatically a regression or vulnerability.
Suppose a new version adds an audit interface. Plausible explanations include a new validation path, optional instrumentation or an unused compatibility layer. A defensible next step is a bounded experiment that distinguishes those alternatives. Keep the input corpus and expected behavior separate from the interpretation you want to test.
The public REI workbench includes reference fixtures and version-specific setup instructions. Use those instructions rather than assuming a desktop preview, external disassembler and CLI all have the same capability set.
Keep an investigation reproducible
Record the tool version, arguments, input digest and the relevant output. Avoid putting credentials, customer content or unrelated personal data into a shareable case bundle. A report can often preserve hashes, schemas and synthetic fixtures while withholding the original sensitive payload.
An AI assistant can help route tools, summarize evidence and propose a hypothesis. It cannot turn a missing trace into an observation. Require a source for every material assertion and verify quotations or extracted values against the actual artifact.
Review checklist and source
- Can another investigator identify the exact input artifact?
- Are built-in results distinct from optional adapter output?
- Does each behavioral claim have evidence beyond a symbol name?
- Are uncertainty and competing explanations preserved?
- Can the bounded experiment be repeated without private data?
Read the current REI Reverse Engineer source and verification notes. The REI Skills explorer provides related investigation guidance. Guidance and generated summaries still require verification against the artifact and the question being investigated.
Explore Rootcastle engineering tools → · Public profiles and publications
