Unpacking DLLs

[nikola]

I didnt unpack dll but i unpacked some exes and i dont think methodology should defer significantly. IAT wasnt problem for my exes. Just had TL1 and TL3 if i recall correctly and cut rest invalid thunks.
It'd be nice if you can attach a small dll here. Tho i have an exam on next monday and a bad one so i probably wont be able to try that out soon

[TechLord]

nikola:
Unpacking vboxed exes is pretty straight-forward and quite mechanical...Since you yourself are saying that you've not unpacked dlls before, they are quite "involved, and complex", as one of the authors on the forum put it.

If you have tryout version of A*obe Phot* sho* CS or any of the recent ad*be tryout products, you can find at least one or two dll which are vboxed there.
Photosh*p CS has cooltype.dll for instance...( Admins : I hope I am not breaking any of the rules by naming the target since I am not giving any application-specific code here...Please correct me and the post if anything in the post is illegal... )
PEiD will very easily let you find the dlls which are packed.

The problem with not having a generic approach for the dlls, unlike for the
exes , for which we have several generic ones...Is that one dll is very easy to reverse while another takes a whole day...While yet another takes a full week to reverse and find the OEP...

For unpacking the exes ( and even the dlls ) the approach of using SICE with tracex and hydra is given by some of the authors on the net. But it doesn't seem to work very well for dlls though it is quite good for exes.
Moreover, SICE tends to give some stange problem with some programs with system-level drivers and hence, I use SICE only when necessary on an old machine devoted only for that purpose...
The IAT was never a problem for me also for exes, as you mentioned in the post.
It is not so for the dlls. Each dll gives a different problem...Though I'd managed to solve them...Taking a long time...
The ImpRec does a marvellous job and the remaining two imports which it leaves out are always the same and it takes hardly a few seconds to disassemble and find the two. On a fast comp, the IAT-finding for the exes is quite mechanical and takes not more than 15 mins at most. This is all true, of course, if you have the correct OEP...

This is where the problem boils down to ...We have to have a generic method to find the OEP for most if not all of the Vboxed dll also. Onec the OEP is known, then the job of course, becomes much easier...
Using the newer PEiD with the plugin gives the OEP of vboxed exe files correctly ( though I don't find it necessary to use it )...But it says it cannot create process to find OEP or something like that and fails when I give it a dll to find the oep for.

I also have a very bad exam on Monday ! Anyway I'd told you how to get the files...If you don't have access to the tryout versions, then please let me know and I'll mail them to you. It may not be as easy as you think to reverse them and give a generic approach...

Originally Posted by TechLord

nikola:
If you have tryout version of A*obe Phot* sho* CS or any of the recent ad*be tryout products, you can find at least one or two dll which are vboxed there.
Photosh*p CS has cooltype.dll for instance...( Admins : I hope I am not breaking any of the rules by naming the target since I am not giving any application-specific code here...Please correct me and the post if anything in the post is illegal... )
PEiD will very easily let you find the dlls which are packed.

Let simply stop Ollydbg on each new dll (Debugging options Events Break on new module). After VBOXTB is loaded set a hardware breakpoint to VBOXTB.070081B9 where OEP of DLL is copied to EAX. Remove Debugging options Events Break on new module and run. On VBOX trial dialog press Try. Ollydbg will stop on hardware breakpoint and show OEP of DLL.

VBOXTB is loaded to memory address 0A000000 (address may be different)

VBOXTB.0A0081B9 (Offset 81B9) MOV EAX, [ESI+14] (EAX = OEP DLL)
...
VBOXTB.0A0081CB PUSH [EBP+14]
VBOXTB.0A0081CE PUSH [EBP+10]
VBOXTB.0A0081D1 PUSH [EBP+0C]
VBOXTB.0A0081D4 (Offset 81D4) CALL EAX (EAX = OEP of DLL)


Another generic approach is setting a memory breakpoint to section .text of VBOXed DLL when Ollydbg stops after loading this DLL. First time the memory breakpoint (type memory on access) stops execution is when some bytes at OEP will be changed. Second time memory breakpoint stops due to execution of OEP (same approach as finding OEP of VBOXed exe files).


Both generic approaches needs still remaining trial days. If trial period is exeeded - no problem. Infos about remaining days are stored in a .LIC (shared folder in programs path \VBOX\Licenses, C:\os??????.BIN (? = numeric characters) and in registry HKEY_CLASSES_ROOT\CLSID\..., look for entries with no subtrees and only one registry entry @ = a long cryptic text string.

If You want to get exact registry entry and exact filename of .BIN You have to patch RUNDLL32.EXE at OEP with JMP OEP (EB FE). Ollydbg will stop at entry of RUNDLL32 when VBOX tries to load VBOXR.DLL. Patch RUNDLL32 back at OEP (E8 0A), set breakpoints at KERNEL32!GetFileAttributesA and ADVAPI32!RegOpenKeyA and run. Ollydbg will serve file name and registry entry.

How to reset trial period to original value:
Delete both RUNDLL processes (e.g. using Sysinternals ProcessExplorer 'Kill process tree'), delete registry entry and file .BIN. Finally remove .LIC and copy original .LIC (you have on HDD after install of program - don't forget to make backup) to destination. You can easily recognise original .LIC regarding date/time stamp, if equal with corresponding .PRF then it is original file. If not available reinstall programm and make backup of .LIC

Greets

Izak