272
edits
Difference between revisions of "HOWTO-Reverse Engineering"
Jump to navigation
Jump to search
HOWTO-Reverse Engineering (view source)
Revision as of 01:09, 15 November 2017
, 01:09, 15 November 2017Added section for adding logging to Dosbox
Peterkohaut (talk | contribs) |
Dreammaster (talk | contribs) (Added section for adding logging to Dosbox) |
||
| Line 188: | Line 188: | ||
There's lot of areas you can proceed to delve in. Hopefully the suggestions above will help get you over the initial barrier of not being sure how to start, and assist you getting started in your efforts. | There's lot of areas you can proceed to delve in. Hopefully the suggestions above will help get you over the initial barrier of not being sure how to start, and assist you getting started in your efforts. | ||
== Extending/Logging DosBox == | |||
Sometimes you'll want to be able to compare the operation of the original in DosBox against your implementation in ScummVM. One of the easiest ways to do this is to set up debug(..) calls in ScummVM to output relevant information, and likewise hack the source code of DosBox to likewise output similar information in the equivalent method in the original. This way, you can compare the output of the two in any file comparison tool, like for example TortoiseGitMerge. To do this, the first step is for you to install and compile the DosBox source. You can find relevant guides on the DosBox website, and any help as needed in the Dosbox forums. | |||
Once you're able to compile the source, the next step is add in relevant debugging information when certain CS:IP locations are hit in the executable; if you've been reversing the game executable in IDA, you should be able to use it to figure out specific addresses for whatever method you're interested in. The appropriate place to add in logging information is in the CPU_Core_Normal_Run method's loop in core_normal.cpp. Here you can check for specific memory addresses having been reached, and output values from various registers. For example, considering the following example code fragment I once added: | |||
<pre> | |||
Bit32u segCS = SegValue(cs); | |||
if (segCS == 0x8a80) { | |||
Bit32u segIP = reg_eip; | |||
if (segIP == 0x2E9 || segIP == 0x307) | |||
fprintf(stderr, "-----------------------------\n"); | |||
else if (segIP == 0x3d0) { | |||
Bit16u ax = reg_eax; | |||
fprintf(stderr, "%.2x %.2x\n", ax & 0xff, ax >> 8); | |||
} | |||
} | |||
</pre> | |||
In this case, I was implementing the sound player from World of Xeen, and I needed to output the register/value pairs passed to a "write to adlib" method. So I added this fragment to print their values when the method was called, as well as an extra separator printed out whan the "playSound" method was called, to separate initialization writes that initialize the Adlib card from calls made after a sound effect call is made. | |||
When the changed Dosbox was compiled, I went to a command prompt. Presuming I'd changed the C drive to the Dosbox build directory, and the game in the current directory (on D drive), I used a command: | |||
<pre>c:dosbox 2> d:\temp\dosbox.txt</pre> | |||
The 2> causes a redirection of the stderr output to a file. Afterwards, I was able to compare the result with a similar output from ScummVM. With differences identified, I could set up a conditional breakpoint in ScummVM in the engine's adlib write method for the last call before wrong values started being written, and stepped through the code until I figured out what the engine was doing incorrectly. | |||
== Final Words == | == Final Words == | ||