Log in

View Full Version : VOB ProtectCD V5


swoop
January 16th, 2004, 05:38
Hi,

does anyone has a tutorial or infos about this "new" version?
The only tut i can find is the old one done by r!sc and this
is a bit outdated

I only want to collect some informations before i start a
reverse session

swoop

disavowed
January 16th, 2004, 10:32
i know this is not what you were looking for (it's v3 instead of v5), but it's another essay other than the one by r!sc: http://216.239.39.104/search?q=cache:Q6rAKTOxnYUJ:rooy.webcindario.com/ECD/vob3.htm ("http://216.239.39.104/search?q=cache:Q6rAKTOxnYUJ:rooy.webcindario.com/ECD/vob3.htm")

maybe it will help a tiny drop

swoop
January 18th, 2004, 15:26
i know this one...well my spanish is not that good
but anyway thx

swoop

swoop
January 29th, 2004, 10:45
ok I had a deeper look into this protection, it seems ProtectCD v5 uses the fameous stolen byte technique. I have some trouble finding the oep or to be more precise the end
of the protection. I found something which could be the oep
but a bpm didn't work.
Does anyone have any experience with this new version?

Btw. the traget is Castle Strike.

swoop

nikolatesla20
January 29th, 2004, 16:13
Why don't you dump the proggie and attach to it the best IAT rebuilt you can. Even if you can't rebuild the entire import table you can usually rebuild enough of it to allow you to see where the normal startup code for most programs is.

Most programs start with GetVersion, or __set_app_type (for MFC apps), or VB starts with a "VB5!" string, and suchlike.

If you become more familiar with the startup code for most common compilers out there you should be able to find a very good guess at the correct OEP location using this method. (Rebuild IAT as best you can, dump program from memory, attach IAT with revirgin or ImpREC, disassemble and examine for typical entry codes).

If you suspect stolen bytes, once you've found the oep area, try just pointing the program entry point to the beginning of the oep area and forget about the stolen bytes. 90% of the time it will run fine anyway.

-nt20

ajron
February 1st, 2004, 16:53
Quote:
[Originally Posted by swoop]ok I had a deeper look into this protection, it seems ProtectCD v5 uses the fameous stolen byte technique. I have some trouble finding the oep or to be more precise the end
of the protection. I found something which could be the oep
but a bpm didn't work.
Does anyone have any experience with this new version?


Some months ago I had removed this protection from skijump2003, but unfortunately I hate to take notes . What I remember is (it's true for the win9x):

1. Protection create second instance with CreateProcess(), which is the right one. You can catch this by bpm GetVersion.

2. OEP has stolen bytes, but most of programs has standard stub at OEP

3. I found OEP with my favourite macro break = "bpr %1 %2 rw if(eip>=%1 && eip<=%2)" with %1 equal to imagebase and %2 below protection section. ProtectCD has some code to fool this (in 1 or 2 places - I don't remeber) which is executed in real program range, so you must skip this.

4. Protection use API redirection and emulation

5. Protection has anti-debug tricks which is no problem whith icedump . int 3 handler checks debug registers.

Maybe it is useful information or maybe not . I hope you can understand me, because I know that my english is horrible .

--
Pozdrawiam,
Ajron.

swoop
February 1st, 2004, 18:41
thx for the replies...
right now i have dumped the prog but i stuck in rebuilding the iat and
fixing the pe header.
this is what i have done so far:

1. bpm getversion
which pops up several times i clear this bp after the protection has
checked the cd
2. bpm createthread
at the first break on this function i returned immediately so the thread
wasn't started
3. used icedump's tracer to find oep at 0x6826CC
4. set a jmp eip ( proctedcd's antidumper thread isn't active now
5. dump the whole process with lordpe or any other dumper
6. try to fix iat with importrec
7. fixed some imports manually

so far so good...but if i try to load the fixed dump.exe e.g. in ollydbg
i directly jump into some kernel32 function (maybe getVersion)
the imagebase and ep are correct...
any ideas?

swoop
February 3rd, 2004, 15:39
doh
import tables weren't correct fixed that and now it's working...

anyway thanks for the hints