![]() ![]() 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 unpacked program should have been saved into the current directory now. ![]() 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. After a short time the debugger breaks again at the starting address 0100. 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. It uses a custom packer to compress the executable. 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. Running debug version of dosbox-0.73 on WinXP SP2.First off, you will need a DOSBox version that is compiled with the built-in debugger. Don't know if that's relevant to the BPLM problem. The target is running in 32-bit protected mode (DOS/4GW). But I want to scroll up and look at the few instructions before the bp, and it gets messed up. That made it much better and it seems to work properly if you just step through after hitting a bp. It makes no sense at all with core set to auto (presumably using the dynamic cpu) so I changed to normal as mentioned earlier in this thread. It's like the disassembler keeps changing it's mind about the alignment of instructions - if thats the right word. BPLM CAFEBABE+14.Ģ) As you scroll up and down the code, the disassembly keeps changing. So to get them to work I need to type eg. Two problems are occuring.ġ) Memory breakpoints (linear - BPLM) seemed to not be working and after a while I realised that the breakpoints were being set 0x14 bytes before the address specified (and before the address shown in the data view and in output of MEMBUMPBIN). I'm using the latest version posted in this thread. Hi, I am trying to use the dosbox debugger to have a bit poke around in an old game. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |