One technique that this doesn’t mention is comparing state of the system across time. If you frequently snapshot memory during normal gameplay and then, for ev

One technique that this doesn’t mention is comparing state of the system across time. If you frequently snapshot memory during normal gameplay and then, for every byte of memory, check whether it gets modified at all, you’ll probably spot many of those inline parameters to subroutines fairly easily, as small areas of memory that see updates inside a sea of static code, likely preceded by a RTS. If, in addition to looking whether things get modified, you look at what values they take and how they get modified, you likely can spot things such as the score (it’s a fairly safe bet that is stored as a multi-byte number in contiguous memory, either as BCD or binary) or number of lives left (gets decreased during gameplay) On current hardware, you probably can also add code that hunts for correlations between what happens on screen and what’s in memory. Those might help you to find a correlation between a memory location and the flight height of the chopper, for example. It likely also is possible to detect, say, the code for shooting by frequently sampling the program counter, comparing a set of samples from flying around without ever shooting with one of flying around while shooting constantly. Given today’s powerful hardware, there’s a lot of automaton that can be done on this. I can even envision using modern AI (“there’s a helicopter on screen. What memory locations seem to store its height and orientation?”) for reverse engineering 8-bit games.