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 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. It would help if there was a simple way to have the internal debugger breakpoint on the first instruction in a new program, started from the shell, so I don't have to debug the shell nor keyboard input, before the process starts.First off, you will need a DOSBox version that is compiled with the built-in debugger. Dosbox-x does not seem to have a way to start a program in the internal debugger I believe previous posts mentioned using the debug command in the DOS window for this, but that doesn't work in dosbox-x. One notable problem is if I use the run command, and there are no breakpoints nor anything to make it stop, there's no way to get the prompt back, and I have to restart dosobox-x for it. And I've encountered some issues with it. Still, I want to know - if possible - how to use the dosbox debugger for this. So far I'm browsing the CW code that's part of Open Watcom Emulation-wise, it runs Dune, Dune 2, and not much else right now. I'm part of a team who works on this project, in order to reverse-enginneer real-mode programs (which offers also a GDB server) : ĬauseWay extender MIGHT run with it. The source code of CauseWay extender is here:
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |