Difference between revisions of "HOWTO-Reverse Engineering"

Jump to navigation Jump to search
m
Mention IDA Free 5.0 must be run in Administrator mode.
m (Text replacement - "www.scummvm.org/frs/" to "downloads.scummvm.org/frs/")
m (Mention IDA Free 5.0 must be run in Administrator mode.)
 
(3 intermediate revisions by 3 users not shown)
Line 3: Line 3:


== Resources ==
== Resources ==
[https://downloads.scummvm.org/frs/extras/IDA/idafree50.exe IDA Freeware Version 5.0] - IDA is the preferred tool for disassembling old games from scratch. The most recent freeware version no longer supports disassembling DOS games, but this earlier version still supports it.
[https://downloads.scummvm.org/frs/extras/IDA/idafree50.exe IDA Freeware Version 5.0] - IDA is the preferred tool for disassembling old games from scratch. The most recent freeware version no longer supports disassembling DOS games, but this earlier version still supports it. Note: In more recent Windows versions, you will need to run it in Administrator mode, or it will error out on startup.
 
[https://ghidra-sre.org Ghidra] Ghidra is an open source alternative to IDA that can be used for disassembling old games. It is not as mature as IDA and is missing some features, but it has a nice decompiler.


[http://vogons.zetafleet.com/viewtopic.php?t=7323 DosBox Debugger]
[http://vogons.zetafleet.com/viewtopic.php?t=7323 DosBox Debugger]
The DosBox Debugger is an invaluable tool for running old DOS games, to monitor how the program executes, and what values are generated by the executing code.
The DosBox Debugger is an invaluable tool for running old DOS games, to monitor how the program executes, and what values are generated by the executing code.
[https://imhex.werwolv.net/ ImHex Open Source Hex Editor]
A powerful and flexible hex editor for all OSes and the Web.


[http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm XVI32 Hex File Viewer]
[http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm XVI32 Hex File Viewer]
Although IDA has a built in hex viewer for the executable itself, the XVI32 tool is useful for viewing the contents of all the other files that come with a game. There are many different freeware hex editors available, so any other can be used just as easily.
A very primitive hex editor compared to ImHex, but may be useful if you just need a quick and simple way to view a file's contents and make changes.


[http://www.ctyme.com/rbrown.htm Ralf Brown's Interrupt List]
[http://www.ctyme.com/rbrown.htm Ralf Brown's Interrupt List]
Line 173: Line 178:
==== The Hotspot list ====
==== The Hotspot list ====


In adventure games, hotspots are areas of the screen that has an interactable item. Moving the mouse over the area causes a description of the hotspot. Using a breakpoint in the write string method, I was able to see what the caller was. Then examining the caller to find out how the description came to be passed, I was able to figure out the structure of how the list of hotspots were stored in memory. This allowed me to create a Hotspot structure, and set up the array of hotspots in memory. From there I was able to go in two direcitons. Firstly, by identifying other methods that access the same hotspot list, then finding out which one set up the values, I was able to locate the hotspot laoding code, which was part of the overall scene loading code. With scene loading identified, I could look at the other files being accessed, and the structures being loaded, and get further ideas of what information each scene contains.
In adventure games, hotspots are areas of the screen that has an interactable item. Moving the mouse over the area causes a description of the hotspot. Using a breakpoint in the write string method, I was able to see what the caller was. Then examining the caller to find out how the description came to be passed, I was able to figure out the structure of how the list of hotspots were stored in memory. This allowed me to create a Hotspot structure, and set up the array of hotspots in memory. From there I was able to go in two direcitons. Firstly, by identifying other methods that access the same hotspot list, then finding out which one set up the values, I was able to locate the hotspot loading code, which was part of the overall scene loading code. With scene loading identified, I could look at the other files being accessed, and the structures being loaded, and get further ideas of what information each scene contains.


The other direction I was able to go in was hotspot interaction. By setting breakpoints in other methods that accessed the hotspot list and then trying to interact with a hotspot, I was able to identify the general method that handles actually doing item interactions. In this case, it turned out to use other fields of the Hotspot record, and then load a script and call it to be executed. Since I'd already identified the script execution method, it made it easier to realize that script data was being loaded, since it was immediately passed on to be executed.
The other direction I was able to go in was hotspot interaction. By setting breakpoints in other methods that accessed the hotspot list and then trying to interact with a hotspot, I was able to identify the general method that handles actually doing item interactions. In this case, it turned out to use other fields of the Hotspot record, and then load a script and call it to be executed. Since I'd already identified the script execution method, it made it easier to realize that script data was being loaded, since it was immediately passed on to be executed.
265

edits

Navigation menu