Log in

View Full Version : Retrieving VBox'ed DLL - Any ideas?


zyn\ker
January 4th, 2001, 18:12
Hi y'all
I'm currently trying to unpack/uncrypt a program which is being protected by VBox 4.3. The steps described in the tutorial on +Tsehp's page are working fine to the point where I'm supposed to find the OEP in the jump to EBX. I hoped to find the address of the DllEntryProc there, but it seems that for DLLs these instructions aren't executed at all as they're being jumped over. The DLL isn't even completely decrypted at that point; it still goes on and on.
Has anybody found a way to quickly find the final JMP?

The Owl
January 5th, 2001, 05:30
for OEP: icedump/tracex
for dumping: icedump/hydra/unvbox.dll/pedump

a quick receipt just in case:

1. iceload -n vboxed.dll
2. run your exe, click 'Try' or whatever to pass by the nag
3. winice breaks as vboxed.dll!DllMain gets called for the first time
4. still in winice: /tracex <start VA of first section> <end VA of first section>
addresses can be fetched from map32 output
5. wait for first break, then you will have to issue another /tracex with a
slightly lower upper bound (no algo here, use zen to guess it, trying never
hurts)
6. 2nd break should normally be at the OEP, time to dump
7. /hydra unvbox.dll
8. /pedump <dll base VA> <RVA of DllMain> unvboxed.dll

if you want a cleaner dump, you'll have to edit the PE header in memory before
step 8. also, to have full relocs back, you have to spot it in the dump and adjust
the object directory entry appropriately.

zyn\ker
January 5th, 2001, 08:17
Thanks a lot for the quick and detailed answer!
But I still got some problems:
When I start the EXE, SoftIce pops into the DLL _before_ the "Trial bla-bla" window appears. The situation is the following:
I have an EXE which seems to be completely unencrypted/unpacked which imports a DLL (besides a few others of course). Before the code in the EXE is even sniffed upon, the OS Loader kicks in and executes the DllMain of the DLL (in the 'WeiJunLi' segment). There this DLL somehow loads one of the VBox DLLs and (now comes a bit speculation) this DLL creates a new process with the 'Trial' window and waits for its return. Now I have a locked up process(the EXE waiting for the packed DLL to return waiting for VBox) and VBox. When I click on 'Quit', the first process is not being resumed, but killed together with VBox. I can't click on 'Try', but have to do some tricks with 'Relicense', but this shouldn't have an effect on the rest of the program.
Just wanted to make sure we talk about the same version of VBox and have the same info-base.
I can't \tracex the DLL when it pops up before the 'Trial', as the process locks up then.
Even if it worked, I don't quite understand step 5; when I \tracex again after step 4, I should break on the very next instruction, as I'm still in (almost) the same range as in step 4 or did I miss something?
Thanks again for your reply.

tsehp
January 5th, 2001, 14:41
hi, send the program's url please, I'll check this out.

G-RoM
January 5th, 2001, 14:56
Execute the steps Owl told ya except the one regarding the TRY button (well not exactly but)... DLLMain_VBOX code is invoked before...

However u must bypass VBOX crap so when u traceX it, the try dialog box will appear, just click on continue and at the end u will popup back in SICE when tracex will have done its job. Then follow the pedump steps.

Cheers,

zyn\ker
January 6th, 2001, 05:24
Sorry for getting on your nerves, but it still doesn't work.
What I did is the following: I notified SoftIce about the DLL via IceLoad and started the program. SoftIce popped into WeiJunLi's DllMain where I executed a \tracex [lower bound of PREVIEW] [upper bound of PREVIEW]. After about 15 minutes it breaks somewhere at the upper levels of PREVIEW and everything looks not very DllMain-like, so I lower the upper bound of \tracex a bit. After a few more minutes the 'Trial'-box comes up and I do my thing to continue to the real program. After a while, SoftIce pops again, but I'm in the Export-Table and the function it jumps to doesn't look like the real DllMain at all. I ignored this and dumped the DLL with the UnVBox-Plugin, but the program crashes when I try the dumped dll.
The program I'm trying to unpack is Visual Slickedit (www.slickedit.com). Should anyone of you be so kind to take a look at it and show me my incompetence: The trial key is 2655693440-0600-WB0000-STD , so you don't need to enter a real e-mail address in the trial-form.

tsehp
January 6th, 2001, 08:03
ok, while waiting for a good soul to point me a way to download win98se, I'll take a look at it, good oppurtunity to test also the iat
rebuilder on this target, all you say seems strange. Normally vbox must return to the main app for it to be executed, it could create a lot of good/fake threads to trace, but one must be, maybe trying to bpx ResumeThread api or another, I'll report of what I found.
regards,

+Tsehp

The Owl
January 7th, 2001, 17:47
Quote:

Sorry for getting on your nerves, but it still doesn't work.


no problem, i took a look at it now myself and figured we have an issue indeed. it seems that the scanner finds only kernel32 imports, but nothing else - obviously not good as the rest won't get resolved, no wonder the dumped DLL crashes.

tsehp
January 7th, 2001, 20:17
at this point, I'll change my tool to resolve iat's from dll's, this was
designed from the start and should not be a problem. It allowed me
to rebuild every vbox dump I tested before and it should work also
for dll's, just check at the beta test topic, I'll notify when dll rebuild will be added.
Normally monday/tuesday evening (Owl, I promise you to work on what we said after
regards

The Owl
January 8th, 2001, 06:20
problem found&fixed. actually the other scanner (/option p a) does the job fine, it's just that the /option command was a bit screwed up - all works now, grab latest 6.022pre and test it.

tsehp
January 8th, 2001, 18:37
Quote:
G-RoM (01-05-2001 03:56):
Execute the steps Owl told ya except the one regarding the TRY button (well not exactly but)... DLLMain_VBOX code is invoked before...

However u must bypass VBOX crap so when u traceX it, the try dialog box will appear, just click on continue and at the end u will popup back in SICE when tracex will have done its job. Then follow the pedump steps.

Cheers,

Just after the nag, I putted a bpx getmodulehandleA, then a tracex
with low and hight vsapi rva, so normally the next popup is the OEP , because dllmain calls for vbox.

I did, landed at 0x1013513a after the try. Then dumped with icedump and procdump, just to be sure.

I resolved all imports with revirgin iat start : 1a17c8 length 6e4 with
the tracer,
putted the vsapi oep at 13513a, but when loading vs.exe, vsapi crashes at 100ad61b, doesn't seems to be because of a bad iat rebuild, but surely a bad guess of dll's OEP. any ideas ?
TIA

touchzen
January 9th, 2001, 01:37
The eop of the crack is: 0013513A
IF anyone want the crack to studywith, please let me know

tsehp
January 9th, 2001, 04:36
Ok it works finally with revirgin's latest version, see the beta test topic if you want to make a test with it.