This is a brief tutorial giving the basic steps to unpack code using the OllyBonE plugin.
Basically OllyBonE consists of a Windows kernel driver that implements the page protection for arbitrary memory pages, and an OllyDbg plugin that communicates with the driver. When the protected page is accessed by the CPU for execution, the INT1 handler is called, returning control to OllyDbg.
The normal method of use is to load a packed program, making note of which section in the memory map will be executing when the unpacking is finished, then setting the break-on-execute flag for that section. This loads the kernel driver into memory and protects the desired physical memory pages from being executed. (Note that only one instance of OllyDbg can use the kernel driver at a time, if you try to load a second instance, you will get an error message "Kernel driver load returned status 5"). When the program is run, OllyDbg will (hopefully) break on the first instruction, which would be our original entry point (OEP).
This technique generally only works with packers that append their unpacking code as a stub section to the PE file, then restore the unpacked code into its original sections. In many cases, packers may employ anti-debugging tricks during the execution of the stub code, which must still be worked around. OllyBonE isn't going to work in all cases, but it can be a shortcut for quickly unpacking the most common packer code.
00400000 00001000 test 0 PE header Imag R RWE 00401000 00040000 test 0 UPX0 Imag R RWE 00441000 0002A000 test 0 UPX1 code Imag R RWE 0046B000 00001000 test 0 .rsrc data,imports Imag R RWEOur entrypoint in this program is at 0046A350, which is in the UPX1 section. If you've ever manually unpacked a UPX program before, you know that typically the stub code in UPX1 will unpack the real program code to the UPX0 section, before jumping to it at the bottom of the stub code. So, we select the UPX0 section in the memory map window, choose "Set break-on-execute", and then run the program by hitting the "play" button or F9.
OllyDbg then stops due to a single-step break at the OEP, the first instruction executed in the protected UPX0 section. We are unpacked and can now analyze the program or dump it using OllyDump.
00400000 00001000 test PE header Imag R RWE 00401000 00001000 test code Imag R RWE 00402000 00001000 test data Imag R RWE 00403000 00001000 test Imag R RWE 00404000 00001000 test Imag R RWE 00405000 00036000 test .data imports,relo Imag R RWE 0043B000 00001000 test .adata Imag R RWEThis is the same section we'll be running after the code is unpacked, so we can't simply set a break-on-execute here. Fortunately, ASProtect doesn't spend long in this section - there is a PUSH/CALL/RETN/RETN and then we jump to the unpacking stub in another section. So, hitting F7 four times brings us to a place where we can now right-click in the memory map, choose the first section after the PE header, and set break-on-execute.
But, depending on how the program was packed, there may be more in store for us. For example, ASProtect can perform a simple well-known anti-debugging trick, checking the value of the IsBeingDebugged variable in the PEB. Before we can successfully unpack the program, we'll have to bypass that check, either by toggling the value in the PEB manually, or by using a plugin that does it for us.
Once that's out of the way, we can run the program with F9. We land with an INT1 break in the first section, but we're not at the OEP yet. ASProtect has us executing a RETN call in the code section. Go back to the memory map and right-click on the section and choose "Remove break-on-execute" so that we can single-step and follow the return back to unpacking code. Once that is done, we can once again choose "Set break-on-execute" on the code section and hit F9. This time, when the program stops, we are at the OEP. Remember to remove the break-on-execute in order to step through the program for analysis.
You can change the DEP settings under:
Control Panel->System->Advanced->Performance->Settings->Data Execution Prevention.If that doesn't work, you may need to add
/noexecute=AlwaysOffto your Windows partition in boot.ini.
Of course, this makes your system more vulnerable to buffer overflow exploits, so using OllyBonE on production systems is not advised. OllyBonE will work under VMWare, so this may be a preferred method for its use. However, note that some packers actively refuse to run under virtual machines, so it may not be the best solution in every case.
OllyBonE isn't a magic-bullet unpacker for all cases, and certainly has its flaws. During the time that the program is running before the breakpoint is reached, the unpacking code can be doing anything, including detecting OllyBonE and subverting it, using the driver to even crash the system by execute-protecting random pages of memory. For now OllyBonE is more of a proof-of-concept than a finished program - keep that in mind as you use it.