Just to let you see what I just started working on... I've added a new function to my pointer too : a backtracer.
So now it's name is changed to NDS Pointer codes & Backtracer Tool v1.81alpha (bleh I hate version number, never know what to put in there !).
What is this backtracing about ? Well think of it like a 'break on read/write'. Except it won't break the game of course. It'll find all references to the address you'll select. Then you'll have to check them (using the TT, and looking at the assembly at these addresses), and see what's going on there... So yeah, assembly knowledge is mandatory !!!
For now it doesn't do much... But within some days (weeks ? :/) it'll be pretty much enhanced. And of course, it has a lot of limitations : for now it only does ARM searches. Also, it'll in no way find all the time all the opcodes that might read the address you entered. It'll only scan for the 'down' ldr r,=xxxxxxxx (for now, I'll change it to 'up and down' ldr).
Here is a small exemple for SM64DS US v1.1 :
1 - I made a full ram dump of a game, during a level. I know that for this game the lives value is stored at 0x02098930 (but a simple search with the TT would reveal that).
2 - So I use the tool's backtrace's tab, I select the ram dump I made and enter '02038930' into the 'address to backtrace' box.
3 - I click 'backtrace' once. The tool will list all the occurences of the address it found in the ram dump.
4 - I click it another time : this time, the tool will search for all the 'ldr r,=02098930h' it can find.
5 - Now I open the TT's assembly window, select ARM, and go to these (=the second set of) addresses the tool found...
After examining them and making some tests a bit (and that is the very tricky part : you MUST know a bit of asm to understand what's going on at these addresses), I found that the last address found by my tool was interessing :
020F3F44 : ldr r1,[r15,#$90]
This is the opcode reported by my tool. Ie. it loads 02098930 into r1
020F3F48 : mov r0,r10
020F3F4C : ldrsb r1,[r1,#$0]
This ldrsb loads the value at 02098930 (= the number of lives) in r1.
020F3F50 : mov r1,r1,lsl#16
020F3F54 : mov r1,r1,lsr#16
These lsl/lsr instructions are used to 'isolate' the value. This means at the second instruction, the games should have the real number of lives in r1. So, we can for exemple change the lsr with ldr r1,#$64 (this can be handy
), patch the game with this new opcode (020F3F54 E3A01064) and - fortunatly - this will give the player 99 lives.
Yeah, I know, my exemples suck because I always find code that have not much use (why do an asm hack when you could just do 02098930 00000064). And moreover, it appears that the asm at 020F3F44~54 is not always there (so it might be dangerous to blindly patch it)... Whatever :p
Also, if no matches are found for a particular address, try finding a pointer for the address you're looking for, and enter the address the pointer points to in the backtrace's tab (ie. the address in the 'Pointer Address Value', on the 'Pointer to ARDS's tab).
You download it at the bottom of this page