I'm attempting to reverse new securom protection.
What I found was the usual 3 calls to WriteProcessMemory / cd-rom activity / more (11) WriteProcMem's.
Stepping a little more after the last WriteProcMem I eventully came to a jmp eax to the original entrypoint.
I dumped the whole process by hand and fixed the e.p. and as expected the dumped exe crashed.
The crash was caused by a call EnterCriticalSection pointing to an object not previously initialized.
So I replaced some crap at the beginning of the code with a call InitializeCriticalSection.
The program crashed again...
This time it was caused by a page fault within the first call (securom placeholder for getversion).
So I ran the original exe again and dumped a few pages of securom memory.
Then I pasted them inside a new section into the dumped exe.
What I expected this time was a new crash...
So I stepped carefully within the first call (the usual securomized getversion) and...
GREAT!!! No more page faults. The securom routine ended up executing the "real" GetVersion call...
Unbelievable! I Stepped within a few other calls and the whole thing seemed to work quite right.
So I disabled b/points and let the proggie run.
"Mmmmmm... Hey, how mutch time does this f*cking game take to load??????"
[...]
What I found out is that the proggie just loops somewhere after the first 12/15 calls.
And here's where I got lost...((
Can anyone help?

Phanx a lot,
acab

what game are you working on ?

you need to rebuild the securom api calls in order
to completly remove securom.
in theory it's possible to dump/crack the securom
api handler ,but it sure is the wrong way.

as you probably noticed securom api calls always go through the SAME call

ie

call dword ptr [503972]

the return address on the stack tells the securom
code what api should be called

so what you do is:

search the text section for the ff25 ... (api call)
push the address of the next instruction (the ret address)
onto the stack then call the securom function (that you modifed
to return the real api in some register) and then create a
new iat.

just read r!scs tut on securom,it's much more detailed

or just use unsecurom or revirgin =)

1st of all let me say that I'm aware of your works against cd protections since a couple of years ago and I respect 'em!
So thanks master for your reply!!!!

>what game are you working on ?
Who wants 2 be millionaire (but dunno the correct english name)

>in theory it's possible to dump/crack the securom
>api handler ,but it sure is the wrong way.
I don't think there's a right and a wrong way to crack; there are just working and non working cracks. And mine is (still?) not working. This post is for those who are interested or can contribute to this different approach.


>as you probably noticed securom api calls always go through the SAME call
>call dword ptr [503972]
>the return address on the stack tells the securom
>code what api should be called
>so what you do is:
>search the text section for the ff25 ... (api call)
>push the address of the next instruction (the ret address)
>onto the stack then call the securom function (that you modifed
>to return the real api in some register) and then create a
>new iat.

Yes, I already knew this.

>or just use unsecurom or revirgin =)
Unsecurom just don't work. However if I wanted a ready made crack I'd have downloaded one from megagames or I'd have played this silly game from the raw-cloned cd.
What I'm interested in is the protection itself; is understanding why and where the dumped exe behave differently from the original one; is "decrypting" the table used by securom to get the original api address; is, as usual, having some fun with someone else code.

Thanks again,
acab

<This post is for those who are interested or can contribute to this different approach.>

that's how your post should have started...

ok let's see... i don't have any of my notes here.

as far as i remember the api handler has almost no subroutines and is pretty easy to understand. it takes the return address and computes the api address using some tables that rely on the
cd and crcs. so you dumped the securom code and the tables
and it works for some of the calls but not for all.

maybe the tables change on runtime (find out how)

oh, there's another possibility
sometimes the api handler doesnt return the right api
but a securom address (at random) add some code
to check whether returned addresses are within the cms section.

ok, you're right!

>oh, there's another possibility
>sometimes the api handler doesnt return the right api
>but a securom address (at random)

and you're right again!
sometime the handler returns the address of the handler itself instead of the api func address
when this happens inside the original exe, the handler returns the correct address the next time it's called, but the dumped exe doesn't behave the same way and just keeps on looping somewhere...
i'll check this.

THANKS a lot for your help!

oh, just another little question: inside the handler there's a strange short call i can't properly understand
this routine usually calls kernel32!ord0001 but it seems it can occasionally call DeviceIoCtrl instead
could you explain this?

Thanks again,
acab

<oh, just another little question: inside the handler there's a strange short call i can't properly understand
this routine usually calls kernel32!ord0001 but it seems it can occasionally call DeviceIoCtrl instead
could you explain this?>

i don't remember and i don't have a securom game
in this loose palace of excile...