Text references are the best way to go about hacking debug menus.
Basically, if debug text exists, that is a good sign that it is used somewhere (but somehow disabled/inaccessible). Also, keep in mind that it may not always be simple ASCII text. Using a relative search is often a simple way to locate text which may not be encoded in the standard ASCII character set. Another thing to keep in mind when looking for debug text is that the menus may be written in a language other than English. Typically, Japanese is a big one.
So, now that you've located some debug text of some sort (it looks interesting to you) how do you go about the actual hack? Answer: cross-references. A "cross reference" is pretty much what it sounds like; a reference (usually a pointer) to the text, located in another section of the program. Find the pointer, and then find the code that looks up that pointer (assuming the pointer is a simple piece of data, rather than being explicitly "assembled" directly in code -- both are quite common).
From there, your most helpful tool is the debugger; back-trace the hell out of the code. That means, generally put, that you should locate cross-references to code [backwards] often several layers deep. For example, "call" or "jump" type instructions that lead to the code which accesses the debug text, and so on. A common technique is placing breakpoints at each of these places, until you actually find that one of those "call" instructions hits somewhere in the game. (It could be before the game starts up, during the title/options screens, in the pause screen, right in the middle of gameplay... pretty much anywhere.) When you find a nice "hit" -- start tracing forward. Notice any branches that skip over the other calls leading to the final routine.
If you find some offending branches, my suggestion is researching them closely; don't just reverse their effect and leave it at that! You might actually find something useful, like a button combination to unlock something never before seen.
All said, it does not really end there. I've seen cases where the cross-references only went back so far, and then completely dried up; there was absolutely no caller into the main "show the debug menu" function. At that point, you can safely start writing your own hook somewhere to show the debug menu when appropriate. Other times, the branches (mentioned above) simply checked a variable in memory which was never written anywhere; that's an easy one, just write the expected value with a simple code. At other times, the text was read early on but it was never shown. Instead, it could cached for use later, by storing it into some temporary memory. And in that case, you would be looking for cross-references to the cached area, and any reasons the program is not making better use of it.  The list goes on...
I suppose the general idea is just basic reverse engineering. Use anything available within the program as a guide to reach your goal.
|
