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?

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.

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?

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.

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 .

>...restart and olly will save the bp and break...
>

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

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

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.

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

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.

Hey JMI

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

Regards

/hobferret

There isn't any target-specific (i.e. non-generic) crack info in the thread, and then you can mention target names.

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,

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?

NO

/hobferret

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?

Try looking at this post

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

/hobferret

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.

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

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.

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

Hey this sounds interesting can you PM the target

/hobferret

Ok. A Private Message is on its way. Regards.

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

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.

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

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.

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

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.


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!


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.

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

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.