Unpacking DLLs

[nikola]

As for my first question here... Just now i was unpacking some ASPR and noticed "Pick DLL" button in ImpRec What a dumber Pick executable of dll, pick dll and there you have it I just wonder how none of you wankers told me this :P Keeping all easy ways to yourself

TechLord: I'm not really clear where you are having problem. Getting to DllMain? Getting IAT?

[TechLord]

nikola:
My main problem is in getting the OEP...

The way I proceed, as I said in one of my prev posts is by changing the characteristics of the dll to exe by subtracting 2000h from the characteristic in PE Editor.

Then I load it in Olly as an exe and try to step it using F7 and F8. Then I try to look for the OEP in the usual way - looking for any SUDDEN changes in the EIP ranges, any sudden jmp away from the decrypting code etc...
This tends to fail more often with Vbox than with other packers.

I sometimes try to load it in IDA Pro 4.7 and after a long and thorough search, I get the oep.

My request was whether someone succeeded in finding any easier way to unpack the vboxed dlls.

The search on the net, including the RCE fora, only succeeded in me understanding that the unpacking of the dll is "More involved and complex"...According some of the authors...

Even after I find the OEP, getting the imports with imprec frequently fails when I use ImpRec 1.6 Final...there are very few if any documents on the net explaining how to get the imports for the dll...The way I proceed is to create a small loading exe file for the dll and then try to get the imports through ImpRec...Any detailed Tutorial on unpacking at least a single vboxed dll is welcome...
I can provide plenty of vboxed dlls if you need them for preparing a rather rough sketch of the steps to take, if not a full-blown tut...

Thank you...

[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...

i been following this thread for some time and i been wondering about relocations.. is there a easy way of fixing them if so any help would be great

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

I'm trying to unpack a dll protected with asprotect but seens to have new stuff or trick because stripper 2.11 RC1 and RC2 don't work. Still in exe's files with the new asprotect show me

stripper v2.11 rc2..
(c) by syd, 2002-2004..

16:37:30 - open TagRename.exe..
TrialCleaner: one trial record was deleted..
16:37:42 - starting e:\archivos de programa\tagrename\tagrename.exe..
Victim ImageBase - 00400000
Victim EntryPoint - 00001000
16:37:49 - asprotect detected..
16:37:49 - loading modules..
16:37:53 - hooking modules..
0x01380000 - module kernel32.dll export hooked..
0x01390000 - module user32.dll export hooked..
0x013a0000 - module gdi32.dll export hooked..
0x013b0000 - module advapi32.dll export hooked..
0x013c0000 - module rpcrt4.dll export hooked..
0x013d0000 - module oleaut32.dll export hooked..
0x013e0000 - module msvcrt.dll export hooked..
0x013f0000 - module ole32.dll export hooked..
0x01400000 - module version.dll export hooked..
0x01410000 - module comctl32.dll export hooked..
0x01420000 - module shlwapi.dll export hooked..
0x01430000 - module imm32.dll export hooked..
0x01440000 - module winspool.drv export hooked..
0x01450000 - module shell32.dll export hooked..
0x01460000 - module wininet.dll export hooked..
0x01470000 - module crypt32.dll export hooked..
0x01480000 - module msasn1.dll export hooked..
0x01490000 - module comdlg32.dll export hooked..
0x014a0000 - module winmm.dll export hooked..
0x014b0000 - module sockspy.dll export hooked..
0x014c0000 - module wsock32.dll export hooked..
0x014d0000 - module ws2_32.dll export hooked..
0x014e0000 - module ws2help.dll export hooked..
0x014f0000 - module uxtheme.dll export hooked..
16:37:54 - error in finding last SEH, (drn == 0)..

and show me a messagebox

Error: 85

Well im unpacking a DLL file too but the darn thing won't run because of the relocation messed up I quess.

The DLL has an imagebase(checked in LordPE) of 10000000. However the dll gets loaded by the main app at base 019A0000. Because of no relocationtable some calls etc get messed up.. IS there any info/tut/app out to get this reltable fixed ? There is little alternative, except manually finding ALL adresses and adding them to a new table..