Securom 7 Rebuild
 

Hey guys, I was fooling around with securom 7 for the past 2 days, and now I am kind of tired, kind of stumped, and have other Real Life things to attend to, so I thought I might pass this off to someone here and he could continue my work into gaining some insights about this protection.

Keep in mind that I am a self-acknowledged noob. A lot of the stuff I say here may or may not be correct. Please correct me if I am wrong, its always nice to learn something.

Before I forget, the target is Grand Theft Auto San Andreas 1.1

Oh, and one last thing before I start: I know that I can dump the heaps at the OEP, and fix the GetProcessId check, but there is no challenge in that, is there?

And one last thing. Pirates, fuck off. People who are going to use this to crack the game and distribute it illegally, fuck off. Protection developers, keep reading and pay attention :) Oh and if you want to learn something, keep reading. Needless to say, this is only for educational purposes, for fun, and for a way to pass time, not for any illegal shit.

Ok, so, let me get you up to date on what I have so far. First thing is to find the OEP. Pretty simple task with this protection. Grab your favorite debugger (for the purposes of this post, I used Olly), and start reading.

Securom 7 uses some pretty innovative AntiDebug, but nothing as vast as the Safedisc antidebug arsenal.

First thing it does is get the tick count with GetTickCount, and then it causes a gazillion exceptions. Since your debugger needs to process all these exceptions, it is naturally slowed down. After it causes all those exceptions, it uses GetTickCount to check if the time elapse was large. If it was -> Debugger detected.

To bypass this check you can either put a BP on GetTickCount(Securom doesn't check API's for 0xCC) and change EAX to 0 each time it is called, or just assemble a xor eax, eax; ret; at the beginning of the GetTickCount API

The second trick comes into play right after the large amount of exceptions. Its a simple call to NtQueryInformationProcess (also known as ZwQueryInformationProcess). To bypass it, I put a bp on ZwQueryInformationProcess, and kept running and looking at the top of the stack. This API gets called a lot by kernel32 and other standard dll's, but you will once see it getting called from a place with a much return lower address:

First of all, note the return buffer(0021217C). Press CTRL+F9 to let olly run until the ret, and then look at the buffer. You will notice that the DWORD there is -1, which means Olly is present. Just change it to 0, and you're fine. I don't know exactly how it uses ZwQueryInformationProcess to detect Olly, but I saw a post on Woodmann concerning it, and I will check it out.

Now, before you run the target, put a Memory Breakpoint on the code section. Now run the target, you will break once or twice, and then finally hit the OEP:

Now, the fun part about Securom is all the anti-dumps. They all revolve around a central routine that is heavily obfuscated and accesses the heaps, does CPUID to check if its running on the correct machine, checks PID of process to make sure its not a dump etc etc...

Now, I'll go through all the antidumps that I have found so far. The first one that is so blatantly easy to spot is all the JMP DWORD PTR's lying around. What securom does during the protection process is cut and paste some code from the code section, put it into a securom(or another location in the code) section, obfuscate it and do all kinds of other, nasty but cool things to it. After it redirects the code to a new spot, it puts a JMP DWORD PTR to the central securom routine at the place where the the original code was. The central securom routine then redirects it to the correct place.

Pretty simple, kind of like IAT redirection, except without the imports, eh? Lets take a look at one of the JMP DWORD PTR's:

Its takes us here:

And that takes us here to the central securom routine:

Lovely. Now, I have traced through the securom routine a lot, and here is an interesting thing I noticed: It always exits with a POPFD, POPAD, RET xx. A serious weakness, makes scanning for all the exit points quite simple. The exit point for the EIP redirection can be found here:

The retn 4 takes you to the correct place. Now, before we begin thinking up some code to fix this, I would just like to point out an interesting feature of the central securom procedure. Please go back to the original JMP DWORD PTR we were looking at:

How interesting. Its now pointing to the correct place. In the interest of speed, Securom overwrites on the fly pointers pointing to its own central routine with pointers to the correct place to go.

Another thing to note is that all JMP DWORD PTR's point to mini routines akin to these:

and

...all of which lead to the central securom routine. It makes life easier, telling apart Securom JMP DWORD PTR's from legit JMP DWORD PTR's inside the game.

I coded something on the fly to fix it, no comments since I wasn't expecting anyone to use it at the time. MASM to assemble etc etc...

Assemble this and inject it someplace, I always love the 00's under the header, but you can use VirtualAlloc also... Then replace:

with a JMP to wherever _retPoint is for you. Run the code (remember to untick INT3 in the exceptions part of Olly's debug options) and when it breaks at the INT 3, all the JMP DWORD PTR's in the code section should be resolved for you. Nice to see the first antidump gone.

The second antidump I noticed in passing. Its your pretty damn standard on-the-fly code decryption. Take a look:

the above jump will lead you to:

Now, put a Hardware BP on 014C4459, and run it, and you will see the code decrypt. Pretty cool, huh?

Now, the thing with this protection was when I first saw it, I didn't really have any way on the top of my mind on how to deal with it, so I coded a little something to push onto the stack the locations of all these encrypted code segments, and then I thought I would do them by hand. Heres the code:

Uhh, ugly code, hurts your eyes even if you never formally learned assembler. But, its gets the job done, that being that it puts on the stack a list containing the offsets of all the encrypted code segments. Of course, I got bored of doing it manually after the 4th routine, so I sat down and started thinking and tracing a little harder, and after a half hour came up with a valid automated solution. You see, the central securom routine always returns to the decrypted code from here:

However, it always writes that code back right before it jumps to it, so if you modify it in any way, it won't have any effect. Its hard to explain, so just assemble a EB FE in the above code sequence if you have time and watch what happens.

The trick however(there's always a trick) is that it always returns to the above code from this code:

and that is never overwritten, hence a nice place to redirect to our own injected code. Look at that nice fat 6 byte instruction at 00F00AD8. Man do I have an overpowering urge to overwrite it. Lets do just that. First, inject the following code where-ever you feel like it:

Note: I'm assuming that the stack is full of the offsets to the encrypted routines, that was pushed on by the previous code snippet I have you.

Now, replace:

With a jump to _ret_point_three. Run the code, when it breaks at the int 3 you will have lot of decrypted routines and a cleaner stack, thank god.

Ok, with that done, take a look at the next antidump:

extremely simple stuff. Securom replaced CALL xxxxxxxx with push _securomdata; call _centralroutine. Then all it does is fix the EIP to the correct routine. Pretty boring, there is only one catch, and that is if you are scanning for it, a lot of other antidumps are doing CALL fixed_1.00EFB6D0, so you need to take them into account also. Here is some code that I used to fix it, its ugly, but if you want to learn something try to understand it:

To get it to run, you need to replace the exit point of the central securom routine for EIP redirection:


with a jump to _good_return, and you need to replace the exit point's of the other antidumps (JMP DWORD redirection and instruction emulation) with JMPs to _ignore_return:

JMP dword exit point:

and instruction emulation exit:

Then, run the inject code, it will fix up all the redirected CALLs.

Now, this is the point I have halted at. I don't have the time for the next month or so, so lets see if anyone can continue in my stead. There are two other types of redirections I have noticed. The first (easy) is the import redirection:

[/code]
005D1A0B . 9C PUSHFD
005D1A0C . 817424 08 6996F12C XOR DWORD PTR SS:[ESP+8],2CF19669
005D1A14 . 9D POPFD
005D1A15 . 58 POP EAX
005D1A16 . 870424 XCHG DWORD PTR SS:[ESP],EAX
005D1A19 . EB FF JMP SHORT cracked1.005D1A1A
005D1A1B D0 DB D0
[/code]

As you can see, its got a slightly different byte pattern each time, which theoretically makes scanning harder. So, I have decided to blatantly steal Hoodlum's solution to this problem.

You will notice that all the import redirections push a pointer to the beginning of the text section right before they go to the Securom routine. These are pointers to the table of DWORDs at the beginning of the code section(you were probably wondering what they are for, now you know):

Simple brute force. Push each one, call the securom routine, get the correct import from the hooked exit point, replace the DWORD in the table with the pointer to the correct import in the IAT, and when you're finished, recode the securom routine to take the pointer to .text, retrieve the import from it, and then jmp to the import. Pretty simple, but hard to explain. I recommend you give the Hoodlum crack for Grand Theft Auto San Andreas 1.0 a quick glance to see what I mean.

Now, I'm not going to give you the code for the above, as I have yet to do it, still, its pretty simple, you shouldn't have any troubles. If that doesn't work then you can always scan for CALL EAX's perceded with PUSHFD's and PUSH xxxxxx's that push pointers to the beginning of .text. Do whatever you feel like doing.

The last protection has me kind of stumped, and in my opinion is what makes securom so sexy. It replaces single instructions with PUSH/CALLs to the central routine, where they are emulated. I've already figured out that it only emulates certain instructions, and I have a theoretical way of ID'ing each instruction, but its not anything solid enough to warrant me giving you details about. So, this is pretty much what I'm asking you to figure out.

Well, thats it for me. I know a lot of you have better things to do, but this post might help some noobies start on this protection, and the way you guys will criticise me will probably help me improve in some way. I'm pretty sure I'll figure out the single instruction emulation eventually, maybe I'll even update this post when I do. Until then,

you all take care :)

old old old.. did you actually check the version of the gta : sa 1.1 update?

you mean the vm?

thats compiler dependant, some compilers put a FARPROC array of va's at the start of the code section
and FF 25 to them from another block of code.. which allows them to make all api's used by the code
into E8 xx xx xx xx api calls... saving 1 byte per api call.. optimisation sort of...

NOT a securom feature

Hmmm, why does the original post smell of 'Sunbeam'!!?? ;)

have to admit, i did actually think the same grumpy...

Hiya guys,

yeah, I bothered to check the version, and I realize that this is fairly old, but hey, you never know. For example, look at Safedisc. A lot of the stuff written about MUPing safedisc 2.7 by Peex still applies to Safedisc 4.6, since they haven't really bothered to update several of their protection features. Also, I've taken a quick peak at the later versions (7.31+), nothing comprehensive mind you, but I think that the structure of securom looks more or less the same, just allocates a lot more memory regions and the exit point is a bit different. But like I said, that was just a cursory glance.

Well, since it performs more than one protection function, I'd just like to say that it would seem quite a bit incorrect to call it a VM. However, a VM is one of its many features (single instruction emulation), so I guess thats how the terms has come about.

I'll have to admit that I have no idea what a FARPROC array is, and will look into it, but from what I understand you are referring to JMP DWORD PTRs that point to an API in the IAT? And then there are Calls to those JMP DWORD PTRs, so instead of wasting 6 bytes on a call dword ptr[pointer to api in iat] (FF 15 xx xx xx xx), the compiler will generate a normal call (E8 xx xx xx xx), and thus waste less space in the final program?

I'm sorry to say, I highly doubt this, because all of the dword's that I have listed are pointers to the Securom section of the game. It is true that they might have originally been VA's pointing to the IAT, but now they have been replaced by securom pointers, and are used for the securom IAT redirection, thus something must be done about them.

And finally, about the Sunbeam comment, I was reading this forum when you were having that little chat with him, and I would just like to say I have never spoken to the chap, have never been on the same forum as him, etc etc... If you feel this information is useless, I am sorry to have bothered you and will remove my original post, and be out of your hair.

Now, 2 things to learn, FARPROC arrays and how NtQueryInformationProcess is used for debugger detection. I have some reading to do. Please, feel free to continue with the criticism, or tell me to fuck off. I wont be the least bit offended either way.

Oh, and in case you are wondering why I am using this nickname, it is because I think this type of information can get me into a sweet bit of legal trouble if I am ever caught. Also, I couldn't think of any fitting nickname while registering, so I just decided to go along with 'anonymous'.

farproc = api va.. at one stage those dwords were probablty api va's...
going to the securom section sure.. maybe to the securom iat?

oh you've got a fair bit more to learn than that... you've made progress sure, but you're coming across like you know all about the subject, then you change and admit you dont know bits...

why not research it fully, spend your time on it, then make a post.. that way its more useful to people later and less full of bullshit and second guessing..

i have to admit though your approach and style, are very similar to sunbeam.. and its clear im not the only one thinking that...

Very well, from now on all posts I make I will try to make as factually correct as possible, and not include any bullshit theories. I can for certain say that all the solutions that I have presented for all the protection options so far aside from the Import redirection and emulated instructions work on my machine.

Also, this post is more in the way of you guys helping me, and maybe even others in the process. Your criticism helps. I admit, I got the idea for writing this post after reading your comments to Sunbeam. You were a lot more critical of him than people would be to me if I posted this information on other cracker forums. All I would get is a 'Thank you'. Thats nice, but what information would I get? Nothing.

Also, for all those interested about the NtQueryInformationProcess check:
http://msdn2.microsoft.com/en-us/library/ms684280.aspx

Also, I think the Securom devs should look at that little red text on the top of the page ;)

Oh, and please don't assume that I know everything about this subject. Like I said in the original post, I don't, but I would be happy to learn :)

Oh, and about the Sunbeam comment, how can I prove to you that I am not Sunbeam?

you proved u werent sunbeam by actually going off and researching...
whats the little red text at the top of the page tho?

It says in red letters in the MSDN page that this API may not be used in future versions of windows. Thus, it could possibly lead to some compatibility problems in the future.

caki,

maybe you are right, maybe not.

The above GetProcAddress returns ZwQueryInformationProcess. However, if I force it to return 0, meaning the API was not found, the app obviously crashes because there is no test to see if the return value was correct.

Maybe the securom devs do a GetVersion to check if the OS supports ZwQueryInformationProcess?

yeh its an 'undocumented' api, but microsoft are usually backwardly compatible with their setups, and some of their code also uses these api's, so if they aren't really going to break their own programs :)..

look at the peb / teb blocks from 9x->xp, even on x64 platform, they are backwardly compatible, and only have new stuff added with each os build..

its like their documentation, often its quite wrong on some api's / structs / params... microsoft = do as we say... not as we do

Sorry, I was just curious since I was reading an article the other day in which some Microsoft spokesperson said they were considering to cut it out with the backwards compatibility, since its starting to limit the development of the OS. If that truly does come about, then I think a lot more people aside from the securom folks will have something to worry about.