This unpacking method should work on DOS packers such as 624 and UPX. For my unpacking example, the DOS screen is now full of awesomeness: Run the renamed executable to see if the unpacking worked. You can use a hex-editor to remove zero-bytes at the end of the program. Your debugger window should look like this now: The last parameter of the command is the number of bytes to dump and can be adjusted for larger programs. The debugger window has contents for a moment, but then blanks itself. It builds fine, but when I try to run it, it creates two windows which are both not refreshed. The unpacked program should have been saved into the current directory now. I have just cloned the dosbox-staging main branch and configured it with the debugger enabled. Finally the execution stopped at OEP before the first instruction of the unpacked program executes.Įnter the command MEMDUMPBIN CS:IP 60000 and press Return. the seg:ofs of the code your sitting in the Dosbox Debugger - the code you want to reach in IDA -> calculate the linar offset of it with seg16+ofs > currentofs32. After a short time the debugger breaks again at the starting address 0100. i extended my Dosbox Staging version to print the loading-segment of the DOS exe, calculate the 32bit offset from that loadseg 16 loadofs32. Execute the current instruction with the F11 key and press F5 to continue the normal execution. This behaviour can be used as a quite easy method to unpack the packed executable now.Įnter the command BP CS:IP to set a breakpoint at the current instruction. After the unpacking is done, the stub jumps back to the address of the first executed instruction and starts the execution of the real program. As a result, the memory location will now contain the unpacked code with the Original Entry Point (OEP) of the real program. It then starts to unpack the data to the address space where to execution started. The normal DOS executable unpacking stub first copies itself plus the packed data to a higher memory location. Click into the Debugger window and press a key like Space to refresh the window. It seems like the DOSBox Debugger has a bug that causes the window to not refresh itself after trapping into the program. Enter DEBUG followed by the name of your executable that you want to unpack and press Return. Start DOSBox but do not run your targeted executable yet. I wanted to have the unpacked version of this intro and compare how the common DOS executable packer compress this file. DOS retains control over the execution of Debug, and Debug controls the execution of sample.exe. In this way, several programs are resident in memory at the same time. It uses a custom packer to compress the executable. If we could picture DOS memory after typing this command, we would see DOS loaded in the lowest area, debug.exe loaded above DOS, and the program sample.exe loaded above Debug. The unpacking target of my choice is Omniscent, one of the most impressive 4kb DOS intros that exist. If you are using Windows and don’t want to compile it yourself, you can grab the latest version of the DOSBox debugger from. First off, you will need a DOSBox version that is compiled with the built-in debugger.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |