I would use basically the same set of tools, today.
I used IDA to annotate the dis-assembly of various files that I was interested in. I never did like IDA's run-time debugging interface. So, I used OllyDbg for most of my debugging. I liked OllyDbg because of the graphical nature of it all. But, I would also use WinDbg if I wanted to set breakpoints on unresolved symbols. I couldn't seem to get OllyDbg to do that. WinDbg is great if you're familiar with the more command-line approach.
I used Ethereal, now named Wireshark, for packet capture and inspection. You just have to get familiar with the filters to harness the power of it. I'd typically start by using netstat to see what ports were being used, and then I'd filter on those ports. A lot of my first protocol reverse engineering was really just pure brute force by staring at packet dumps of multiple log in attempts with all the cases (success, fail, etc) and just basically doing a manual diff process, noting the changes. Until I got better at using IDA and WinDbg, anyways.
For quick and dirty virtual mem scanning, I'd just use this tool called ArtMoney. It was an amazing tool because you could scan the memory for some data, bookmark offsets and then re-scan. Basically, you could build upon previous scans, allowing you to sieve results. Like, in StarCraft this was so easy because if you were trying to find a value that was increasing or decreasing, like supply income, you scan and scan again saying "show me only the results that went down since last scan." Then, scan again using those results but only show the ones that went up. Usually, after 3-4 sieve scans you'd be staring at your values. Then you just attach OllyDbg to the process, breakpoint on memory read or write to them, see where it breaks and step out a few function calls (because you'd usually land in some low level write function or loop event or something).
Lots of tools, but the key is just to use common sense. Think about what it's logically doing. Use your knowledge of game loops and stuff to determine what you're probably looking at or looking for. Always annotate the assembly code, even if at first it seems small and stupid. Over time those small notes add up and you'll end up with fully commented code. :P A lot can be researched by poking around in the files in the install directories, too.
Skywing|14 years ago
I used IDA to annotate the dis-assembly of various files that I was interested in. I never did like IDA's run-time debugging interface. So, I used OllyDbg for most of my debugging. I liked OllyDbg because of the graphical nature of it all. But, I would also use WinDbg if I wanted to set breakpoints on unresolved symbols. I couldn't seem to get OllyDbg to do that. WinDbg is great if you're familiar with the more command-line approach.
I used Ethereal, now named Wireshark, for packet capture and inspection. You just have to get familiar with the filters to harness the power of it. I'd typically start by using netstat to see what ports were being used, and then I'd filter on those ports. A lot of my first protocol reverse engineering was really just pure brute force by staring at packet dumps of multiple log in attempts with all the cases (success, fail, etc) and just basically doing a manual diff process, noting the changes. Until I got better at using IDA and WinDbg, anyways.
For quick and dirty virtual mem scanning, I'd just use this tool called ArtMoney. It was an amazing tool because you could scan the memory for some data, bookmark offsets and then re-scan. Basically, you could build upon previous scans, allowing you to sieve results. Like, in StarCraft this was so easy because if you were trying to find a value that was increasing or decreasing, like supply income, you scan and scan again saying "show me only the results that went down since last scan." Then, scan again using those results but only show the ones that went up. Usually, after 3-4 sieve scans you'd be staring at your values. Then you just attach OllyDbg to the process, breakpoint on memory read or write to them, see where it breaks and step out a few function calls (because you'd usually land in some low level write function or loop event or something).
Lots of tools, but the key is just to use common sense. Think about what it's logically doing. Use your knowledge of game loops and stuff to determine what you're probably looking at or looking for. Always annotate the assembly code, even if at first it seems small and stupid. Over time those small notes add up and you'll end up with fully commented code. :P A lot can be researched by poking around in the files in the install directories, too.
memoryfault|14 years ago