The first task in reverse engineering is establishing which program is being examined. Keep the ROM hash, region, revision and processor module with every observation. Addresses in a report need a coordinate system: ROM offset, loaded ARM9 address, copied ARM9i address, or an address in a tool's rebased database. A bare eight-digit number is not enough. [1][2]
Build a trace
- Begin with an observable action or file byte, such as a frame change or a PPM header field.
- Locate the data reference or call chain in the correct executable image.
- Follow the actual branches and data providers. Give analyst labels to functions only after their effects are characterised.
- Record inputs, memory effects, outputs and call order. Include a boundary or malformed case.
- Repeat on another build before claiming cross-region behaviour. [1][2]
Use comparison carefully
Run a rewritten function and the original code with the same test inputs. Whole-memory comparisons are stronger than checking one return value, especially for parsers and document builders. Even thousands of matching cases do not prove all inputs match. Identify which original dependencies were retained in the comparison harness. [1]
Say what was tested
“Confirmed in US V2 ARM9 for these tested inputs” is more useful than “Flipnote Studio always does this”. State missing builds, untraced service calls and possible alternate paths. Another researcher can then reproduce the observation and extend it without having to guess what was actually tested. [1][2]