Log in

View Full Version : Vbox 4.6.2 confusion


psy_gr
September 9th, 2004, 07:02
Hello, this is my first post here. Rest assured i have read and comprehented the rules. Warning to the reader: i am a newcomer to the REverse Engineering world. On to my question. There is an Adobe application that i have, which evidently, is protected by Vbox 4.6.2, and thus sports the usuall nag screen.

The version i have is a special, trial one, ie, has some extra features aside being a demo. But i also have the "regular" version, that i have paid for and own. So, investigating the possibility to simply swap the executables, i was faced with a Vbox nag screen when i executed the legal (read: not packed) .exe in the installation directory of the trial version.

My question, and i hope it doesn't sound naive, is, does Vbox only wrap the main executable, or a given set of dll files as well? When one attempts to unpack it, can he count on the numerous how-to guides? Or is there some caveat?

neviens
September 9th, 2004, 09:11
Adobe usually packs main executables + 1-2 libraries.
VBox can't be considered as difficult to unpack packer, usual tools
(Olly, ImportRec) will do a job.
Neviens.

psy_gr
September 9th, 2004, 10:42
Thanks for the reply. Another question, if i may. I've read some walkthroughs for defeating Vbox 4.6.2 used in Adobe applications, namelly for Photoshop 7.0.1. But this thread [ http://woodmann.net/forum/showthread.php?t=1506 ] got me thinking that an entire new method should be invoked on targets like InCopy. That is by the way the application that i am currently focusing on. Am i on the right track reading such texts?

neviens
September 10th, 2004, 02:27
Don't know about texts, but in short I usually do it in a following way:

1. Locate all protected executables and libraries with winhex (open folder),(must contain specified text (PREVIEW))

2. Find the OEPs from preliminary dumps of executables and libraries with IDA (compare, if necessary, with other exes)

3. Dump the executables stopped at OEP with OllyDebug (HW breakpoint, IsDebuugerPresent plugin necessary) with WinHex.

3a. If .dll, load it with little compiled helper exe, containing LoadLibrary function and stop it @OEP with SoftIce with jmp eip.

4. Clean up dumps (EP, RVA==Offset, Section attributes, etc, etc); locate IAT and a free space for IT for step 5

5. Rebuild imports with ImpRec (Trace Level3 (Trap Flag)), failed entries find from IDA dizasm listing.

As you can see, my main tool is IDA here, it's incredibly powerfull tool.
BTW, does anybody know, how to put a HW breakpoint in uninitialized memory (step 3a) in OllyDebug?
Neviens.

Eggi
September 10th, 2004, 07:39
Quote:
BTW, does anybody know, how to put a HW breakpoint in uninitialized memory (step 3a) in OllyDebug?


Let the program run and then set a hardware bp on the memory... restart and olly will save the bp and break . I hope that this is what you want .

neviens
September 10th, 2004, 08:19
>...restart and olly will save the bp and break...
>

Thanks, it works! It is possible to remove 3a. step now
Neviens, Sice man.

LetMeIn
September 28th, 2004, 20:29
neviens - could you elaborate on step two of your five step process for me?

First let me say that I am brand new to all of this and I'm a little slow, so bear with me. Following your process I think I have located the protected exe and libraries with Olly - they are the target app exe, vboxat, and vboxtb. I accomplished this by setting a breakpoint on FreeLibrary and then using the view -> memory. In the memory window, I scrolled to the bottom to find the above files with PREVIEW listed in the section column.

Q1: As a newbie, am I on the right track?

Q2: If I am, how do I go about making prelim dumps of these files to find the OEP?

Thanks,
LetMeIn

neviens
September 29th, 2004, 02:17
A1: The same goal you can reach with different tools, it's not necessary to
use winhex. You can drop a vboxat, vboxtb from your unpacking list- those
are protector dlls.
A2: I usualy do it with winhex's ram editor, but it's possible to use any
proc dumper (LordPE for example). Dump to file, set up all necessary
entries in pe header, set an entry point to 1000h, dizassemble with IDA with
appropriate signatures.
Neviens.

naides
September 29th, 2004, 14:49
A couple of points:

Psy-gr, you are putting too much info about the program you are reversing. . .
That is not healthy for you specially if you own a legal registered copy so they have your name in a DB.

If it is the program I am thinking, several dll and plug-in are Vboxed, so you need to take the time to locate them (PEiD would do it) and unpack them, which is slightly more involved than unpacking an .exe file

psy_gr
November 6th, 2004, 07:55
Quote:
[Originally Posted by naides]Psy-gr, you are putting too much info about the program you are reversing. . .
That is not healthy for you specially if you own a legal registered copy so they have your name in a DB.

If it is the program I am thinking, several dll and plug-in are Vboxed, so you need to take the time to locate them (PEiD would do it) and unpack them, which is slightly more involved than unpacking an .exe file

Thank you for the reply. I am aware of the risk involved, but i trust (and hope) that they will have bigger fish to fry than me. Also, i plan to continue this reversing process, so i might have to bug you with my questions, as they arise. Thank you for your valuable patience. Regards.

hobferret
November 7th, 2004, 06:42
Hey JMI

You are slipping up in your OLD AGE target is named in these posts

Regards

/hobferret

dELTA
November 7th, 2004, 06:50
There isn't any target-specific (i.e. non-generic) crack info in the thread, and then you can mention target names.

JMI
November 7th, 2004, 11:16
hobferret:

I am NOT "slipping" into old age. I "leapt" into old age some time ago, just can't remember when.

And, although I just hate to admit my friend dELTA is right about anything, as he stated, there is no "target specific" code or crack information, even though various targets using the protection system are mentioned. However, it would be BEST if the use of target names were very limited.

Regards,

psy_gr
November 7th, 2004, 13:46
Quote:
[Originally Posted by JMI]However, it would be BEST if the use of target names were very limited.

I understand. Thanks for the hint/tip. I will keep it in mind when posting any further inquiries conserning the actual "dirty work" i do. I appreciate the tight community, though i am sure i don't quite fit it with my extremelly limited knowledge in the RE field. Regards.

edit. As i wonder into this project, and contrary to what previous poster have said, it appears that only the main executable is actually packed. A thorough examination of the installation, and observation of readilly available "cracks" point to that direction. Have i been fooled?

hobferret
November 7th, 2004, 16:11
NO

/hobferret

psy_gr
November 8th, 2004, 10:21
So, i folowed your method hobferret, as documented in the PgMkr walkthrough. I was able to find the OEP, and after the JMP EBX that lead into the application, i made a dump with ollydump. The next step was to initilize imprec and point it to the running executable. I fed it the OEP, and it loaded the imports from the IAT. Now, there are several thunks (modules) that appear not valid, with pointers to vboxta.dll. I tried tracing them with either Hook (2) or Trap Flag (3), but to no avail. I have also set the timeout on (3) to 300 msec. To my understanding, only two of the imports should need manual intervention, but i am faced with 5 valid modules (thunks) out of 9, which means plenty of functions are not imported on the remaining 4 modules. Any suggestions?

hobferret
November 8th, 2004, 11:52
Try looking at this post

http://woodmann.net/forum/showthread.php?t=5673&page=4

/hobferret

psy_gr
November 8th, 2004, 12:36
I've read that post, along with any relative threads i managed to dig out using the local search feature. I cannot comprehend what i must do. Perhaps you could shed some light to my dead brains cells if we are talking upon a common base. So, i quote below the last thunk of the tree.

FThunk: 00005290 NbFunc: 00000015
1 00005290 vboxta.dll 0001
1 00005294 user32.dll 00C0 DrawTextW
1 00005298 vboxta.dll 0001
1 0000529C vboxta.dll 0001
1 000052A0 vboxta.dll 0001
1 000052A4 vboxta.dll 0001
1 000052A8 user32.dll 00EC GetActiveWindow
1 000052AC vboxta.dll 0001
1 000052B0 vboxta.dll 0001
1 000052B4 vboxta.dll 0001
1 000052B8 user32.dll 0282 SetWindowLongW
1 000052BC user32.dll 0170 GetWindowLongW
1 000052C0 user32.dll 029B SystemParametersInfoW
1 000052C4 user32.dll 0062 CreateWindowExW
1 000052C8 user32.dll 021A RegisterClassW
1 000052CC vboxta.dll 0001
1 000052D0 vboxta.dll 0001
1 000052D4 user32.dll 009A DestroyWindow
1 000052D8 vboxta.dll 0001
1 000052DC user32.dll 02AB TranslateMessage
1 000052E0 vboxta.dll 0001

I am aware that the problem lays at the vboxta.dll entries. How am i supposed to trace it in Olly though? In that thread, you mention:

>Remember what I said before get to the OEP in Olly then look for something
>like CALL DWORD PTR [ADDRESS]. Any unresolved can be stopped in this
>block and then traced to see where you end up!

Does that mean that i have to get back into the OEP in Olly, and then look for a pointer to which address? Assuming OEP is 00403B26 (00003B26 in imprec), with RVA 00005000 sized 000002E8. I hope i don't sound too dumb.

hobferret
November 8th, 2004, 14:50
OK then dumbo

Your first thunk is 1 00005290 vboxta.dll 0001 so you say

Get to the OEP then goto memory window and goto the address of this and set breakpoint memory on access (or execution) when it stops trace from there and you should end up in the right place in the dll. You just need to remember what it was

Then if you are still in trouble repeat this for all unresolved

¡con duras penas!

/hobferret

psy_gr
November 10th, 2004, 14:19
Hello. I am back again. I've done some progress, interestingly enough. I have rebuilded the IAT using Olly and Imprec, and attempted to fix the dump. Everything went fine. So, i double-click the resulted file, which to my surprise ran fine. But, at some point, as it was loading some application extension, the vbox nag came up once again.

So, i presume that the particular file is packed as well, besides the regular executable. The problem is, the file isn't a .dll module. It has an arbitrary extension, like this particular application usually does. I do understand that it is of valid PE format (obviously) but how would i go about unpacking it as well?

Thanks for your valuable contribution so far.

edit. Fortunatelly enough, i was able to copy that particular file from the legal retail copy i owned, and it worked flawlessly. I now have a fully operational copy of the program without any nag screens. But still, i would be interested in finding out how to completelly unwrap everything.

naides
November 10th, 2004, 18:18
Quote:
[Originally Posted by psy_gr]
edit. Fortunatelly enough, i was able to copy that particular file from the legal retail copy i owned,


Those are plug-in modules, which are .dll in disguise.

They have their wrinkles, but can be unpacked.
Watch and learn son:

1 you have the original one, unpacked, so look at the code pattern around the original entry point. If it is a different version, dissasembly other plugins and learn the code pattern.

2.That way you find the OEP. dump.

3. Also look at the IATs of not packed mods and/or original ubnpacked one. IMPREC gets lost detecting the IAT because it is located in some weird areas. you have two options: Reverse IMPREC, and learn how it decides where the IAT is located, then figure out a "correction factor" to manually input in inprec IAT begin box. The autosearch tends to fuck up.

4. Or learn to fix the IAT by hand without Imprec. Long, slow but etretaining, and instructive.

5. You need to wipe out the packed plugin module from the folders, because the program scans the Plugin folders, finds the packed mod and loads it even if you change the name.

6. PEID locates all the packed mods (at least in my app).

Have fun

hobferret
November 11th, 2004, 16:22
Quote:
[Originally Posted by psy_gr]So, i presume that the particular file is packed as well, besides the regular executable. The problem is, the file isn't a .dll module. It has an arbitrary extension, like this particular application usually does. I do understand that it is of valid PE format (obviously) but how would i go about unpacking it as well?


Hey this sounds interesting can you PM the target

/hobferret

psy_gr
November 12th, 2004, 04:56
Ok. A Private Message is on its way. Regards.

hobferret
November 12th, 2004, 06:19
psy_gr

That is an upgrade so I cant help with that coz I got nowt to upgrade!, read your PM for another approach.

Regards

/hobferret

psy_gr
November 12th, 2004, 09:17
Quote:
[Originally Posted by hobferret]That is an upgrade so I cant help with that coz I got nowt to upgrade!, read your PM for another approach.

Well, i can assure you that it is not an upgrade of some kind. It is the full program, version 3.0.1 (not mentioning program name there ) and it does not require any previous versions to be installed. I had it installed inside a virgin Virtual Machine, so i kinda have first hand experience. I've also send you a PM with something along the above lines. Regards.

hobferret
November 12th, 2004, 11:17
Hmm......

Well the site says it's an update for programXXXX, and it's 100MB. So you will have to wait a while mate

But I sort of promise I will have a look

/hobferret

psy_gr
November 12th, 2004, 13:48
Quote:
[Originally Posted by hobferret]Well the site says it's an update for programXXXX, and it's 100MB. So you will have to wait a while mate

Yes, indeed. The page title can be (is) a bit misleading i must admit. But fear not, this is the real thing. Ok, take your time. I'll lurk around for any progress you might be doing. Regards.

edit. @naides: Well, a thorough installation directory scan with peid only revealed the main executable to be protected. Somehow, the plugin was not flaged. But, something seemed fishy from the begining of the debugging session, since Olly was complaining about invalid pointers regarding the particular extension. And yes, obviously the plugin must be removed from the plugins folder, as it will get loaded automatically when the application gets initialized.

hobferret
November 14th, 2004, 05:15
Hi psy_gr

OK first look at what my friend nadies had to say in this thread

Then you say PEID only revealed the main EXE, well with a bit of thought you may have realised that you need to do a recursive scan, which will reveal all modules

You will find there is 1 more file packed with VB which can easily be resolved by renaming it to something PEID will recognise, when you find it load it into Olly and unpack it

It does seem that you have the IAT correct so just play with the remaining file which for some reason is called twice

/hobferret

psy_gr
November 14th, 2004, 11:22
Quote:
[Originally Posted by hobferret]Then you say PEID only revealed the main EXE, well with a bit of thought you may have realised that you need to do a recursive scan, which will reveal all modules

I don't understand what you are talking about here. What do you mean by "recursive scan"? PEID traversed the entire installation directory including plugin subfolders, etc. That module was not flaged.

Quote:
[Originally Posted by hobferret]You will find there is 1 more file packed with VB which can easily be resolved by renaming it to something PEID will recognise, when you find it load it into Olly and unpack it

But i do know which file is packed already! And why should i rename it to anything it order for PEID to pick it up? I thought it scaned files base on having valid PE structrure, not extension!

Quote:
[Originally Posted by hobferret]It does seem that you have the IAT correct so just play with the remaining file which for some reason is called twice.

Yes, i do have the IAT correct, since everything is working! And there is no file that gets called twice! Please re-read my posts.

hobferret
November 14th, 2004, 13:33
NO COMMENT

And there is a file that gets called twice - unless you have a different program - although I gotten hold of where you pointed me

BTW rename it to something that Olly will recognise not PEID, my mistake coz I am a thick bas**rd

Obviously I can't help you anymore coz you know everything

/hobferret - who is quite obviously thick

psy_gr
November 15th, 2004, 06:08
This was of academic nature anyway. If i pursue it further, i'll keep in mind the pointers givenin this thread, and perhaps post back my progress. Thanks for everyone's valuable contribution, and yours in particular. Sorry if i snaped and pissed you off in the end. My bad. I should have been more patient, since i am a newcomer after all. That said, add what you wish. Regards.