Log in

View Full Version : Vbox 4.6.2 on Coreldraw 11 - LAME


Lbolt99
November 1st, 2002, 22:20
Hello,

Back from a several month hiatus, I am at work again on stuff and my most recent target is Coreldraw 11. The trial version is available from Corel's web site, which they seem to change around all the time. To save the hassle, just go to link removed after logging into their ftp site.

Alright, those of you around awhile remember Vbox 4.3 on Coreldraw 10 was a piece of cake. Well this one is too, except for a lame trick that Corel decided to throw into the mix.

Corel 11 works very similar to Corel 10 - there's a bunch of small .EXE files for the programs, basically just launchers, and a zillion .DLL files.

The new version of vbox doesn't do anything for corel because their launcher exe file only imports kernel32.dll. So just dump it as you would anything else, and rebuild with revirgin. My method was to break on getversion, and several lines up was the OEP: 401771, and dump with LordPE.

So there we have the exe stripped of Vbox. Now we try running it: whoa! The dumb vbox screen comes up again. So I tried renaming the vbox directory so it couldn't access the vbox dll files. Re-run Coreldraw, up pops a box "Couldn't access vbox files". bpx messagebox, it goes back to a process called "crlfrmwk100.dll". Turns out, they decided to put vbox on one of the startup dll files.

After a bunch of false leads trying to figure out the OEP of the crlfrmwk100.dll file, I tried a different method:
I looked at a couple of the other dll files, and noted one of the common asm statements near the oep. I went and dumped the free-running process of the crlfrmwk100.dll file, pulled it up in W32dasm, viola! A search for the string revealed what proved to be the correct OEP: 24B45823. So I put a bpm cs:24b45823, and dumped the dll file. At this point, the relocation needs correcting: its pointing to an area in the PREVIEW section, and needs to be changed back to where the .reloc section is. Nothing else needs to be done with the relocations cause it always seems to load into the base at 24AB0000. Also, fix the OEP: rva 95823. The import table is untouched! You don't even need to rebuild it.

So was the powerful and tough Vbox 4.6.2 good enough to protect Coreldraw11? No. And their little .dll idea didn't pan out either

nikolatesla20
November 1st, 2002, 22:49
Yeah, VBox is pretty darn easy, I unwrapped Flash MX in a day or two - took me longer only because Revirgin got some API's wrong and I had to trace them manually in SI.

Once again, it shows how much you can do with a dead listing, even when something is "protected". I use that technique on packed VB apps as well, since they push a "VB5!" string at their OEP. Just dump it and search for VB5! and you've found the OEP.

Here is another little trick I like to do sometimes: If you are having trouble locating the OEP.

1. Dump the file anyway, while its running. Who cares about initialized pointers, etc. We just want to look for OEP.

2. Rebuilt the IAT as much as you can. Don't bother rebuilding the WHOLE thing, just a basic single level trace is good enough just to get most of it.

3. Patch the IAT into the file, and correct your IAT VA and size, and correct any section characteristics so you can disasm it.

4. Open up the file in WinDASM, and try to find an API that is usually near the beginning of a program. (GetCOmmandline, or GetVersion, etc.) For MFC programs , it's usually __set_app_mode.

Just another way to skin the cat.

-nt20

salsa
November 2nd, 2002, 00:51
nikolatesla20,

Your method on aspr does not work! I followed your advice given in reply to my post "dump problem". I found the string with my hexeditor, checked the address with w32dasm on the dump I made whilst the prog was running and yes it is the address that should be pushed (the first instruction below ThunRTMain).

In fact, aspr loader gets the OEP and points the same address that the prog should return. However, this instruction is missing on the dump. On the previous version of the same VB prog (protected with the previous version of aspr) that push instruction was there. I think it safely resides somewhere inside aspr space now.

For your info

nikolatesla20
November 2nd, 2002, 02:32
Yes, salsa. Thanks for letting me know!

It's just because of the new Asprotect version, which copies some of the original code to itself now. Older versions never did so.

Plus not all protections are Asprotect So it works on those.

-nt20