Unpacking Dlls And Drivers With Ollydbg, Geffners blog
People often ask me how to unpack DLLs and drivers. A common assumption is that it is necessary to use OllyDbg's LOADDLL for unpacking DLLs and that a ring-0 debugger such as SoftICE or WinDbg is necessary for unpacking drivers. With a little tweaking, we can use regular OllyDbg to unpack packed DLLs and even many packed drivers.
I don't know about you, but I've always had problems with LOADDLL. Even though it's well documented in OllyDbg's help file (the source is even included in the help file), I'd rather not use it if I don't have to. So how can we load a DLL into OllyDbg so that we can unpack it like we would a normal EXE?
All that you need to do is set the IMAGE_FILE_DLL bit to zero in the Characteristics field of the PE's IMAGE_FILE_HEADER structure. You could use a hex editor to make this change, but it's easier with a PE editor like LordPE. Once this flag is zeroed out, you can load the "DLL" into OllyDbg and OllyDbg and the OS will interpret it as an EXE. You can then unpack it as you would an EXE (trace to the OEP, dump, fix the imports, etc.), and then set the IMAGE_FILE_DLL bit back to one in the unpacked file.
The only catch is that many unpacking stubs check to see if [EBP+0x0C] == 1 (does the fdwReason argument to DllMain equal DLL_PROCESS_ATTACH), and if it doesn't equal 1 then it won't continue to unpack itself. You can fix this problem by looking for this comparison and forcing a jump/no-jump or by manually pushing three DWORDs onto the stack (before executing the first instruction at the EP), the second of which should be 1.
We can use the same PE header patching trick for loading drivers into OllyDbg for unpacking purposes. By setting the Subsystem field to 2 (IMAGE_SUBSYSTEM_WINDOWS_GUI) in the PE's IMAGE_OPTIONAL_HEADER, OllyDbg and the OS will interpret the file as an EXE instead of as a driver. This allows us to trace through the unpacking stub until the code and data are unpacked, and we can dump the process when we find the OEP. Of course if the unpacking stub is trying to execute instructions/functions that need to be executed from ring-0 then we won't be able to unpack it like this. However, if the unpacking stub is just doing a lot of simple XORing to unpack the original code and data, then we should be able to use this trick to successfully unpack the driver with OllyDbg.
