Securom crack tutorial by Pedro First, a simple explanation about Securom. Securom is a cd-rom protection that can't be copied when you duplicate a cd. It's used by a lot of games, for the purpose of this tutorial I tried Conflict Freespace (english version), Grim Fandango (italian version) and Might and Magic VI (italian version). This is the first tutorial I write, so forgive me if I'm not clear or if my english is bad. I decided to write this tutorial because the generic Securom crack by Laxity doesn't work on the games I tried. I also found that part of Securom code is encrypted, and is decrypted by a key read from the cd. My aim is to let the protection decrypt itself, then put decrypted code into the executable and remove Securom cdrom check. Software you need: - Softice - Adump v1.0 by UCF: this is a Softice dumper, I found it at http://www.suddendischarge.com/Decompressors.html - Supcomp and Supwrite: I wrote these tools and they are included as C source code - Procdump32 v1.1 by UCF: this is a universal PE unpacker and is nedeed to unpack the main executable of Grim Fandango. You need it only if the game you are trying to crack is compressed by Petite. I found it at http://www.crackstore.com/tools.htm - A Hex Editor Supcomp and Supwrite can be compiled with any DOS C compiler. I personally use the great DJGPP 32 bit compiler that is free (http://www.delorie.com). There is no documentation for Supcomp and Supwrite: just run them with no parameters and you'll find what they do. First, let's look at the main executable. Conflict Freespace and Might and Magic VI are not packed, while Grim Fandango is packed with Petite. So the first thing we have to do is to unpack Grim Fandango's executable. Luckily it's quite easy if we use Procdump32, that has support for unpacking Petite compressed programs. Ok, let's start with the real cracking ;-) When we start these games, we see that they load something from disk and they simply exit (because we put a copy, not the original into the reader :-) Well, we can try to breakpoint the usual call SendDriverMessage, but nothing happens. Hmm, it seems Securom doesn't use the Windows API to access the cdrom. I spare you the effort of finding how the program accesses the cdrom: it uses INT 31 with AH=03 (DPMI 0.9+ - SIMULATE REAL MODE INTERRUPT) to call MSCDEX interrupt. Ok, let's step a bit after the breakpoint, we get into CMS32_95.DLL that is part of the protection, then we get to the main executable. Now if we search for some of the code bytes we see, we can't find them in the main executable file! Parts of the code are crypted, and they are decrypted when the program is run. How can the program modify itself during execution? By calling WriteProcessMemory. So we put a breakpoint on this call. We see that all these games call it at least three times, even if we didn't put the cdrom into the reader. So this decryption doesn't depend on the data on the original cdrom. This is just the code that makes the last decryption. In fact if we put the original cdrom into the reader, the API is called once more, and the decrypted code is correct, while if we put a copy into the reader, either WriteProcessMemory is not called the fourth time (bad copy, so the protection realizes it's false) or it is called but the decrypted code is garbage and the program realizes it's wrong and exits. So the fourth decryption DOES depend on the data read from the original cdrom. If we look at the API reference we see that when the breakpoint is activated on WriteProcessMemory we have: ESP+08: destination address ESP+0c: source address ESP+10: length of area to copy So, we might dump the code bytes after the decryption and substitute them into the main executable file. First we make a copy of the main executable called mm6_2.exe (for this purpose I use Might and Magic VI, but the others work the same way). It's important to use short file names, otherwise supcomp and supwrite won't work. The rule is: we execute the original mm6.exe to get decrypted code and we patch mm6_2.exe (don't run mm6_2.exe before it's completely patched or it will hang). Let's run Adump. With command "R" I see that the starting memory area for dumping is 0x83651000. Now let's run mm6.exe with breakpoint on WriteProcessMemory. Ok, I see that 0x5000 bytes are to be written, the source address is at 0xe80078 while the destination address is at 0x4ae000. So I copy the two areas (source and destination) into two different areas of dump memory: m 4ae000 l 5000 83651000 (original code) m e80078 l 5000 83661000 (decrypted code) I let the process end, I go to the dumper and I write the two areas of memory to two files. w c:\orig1.dat 5000 83651000 w c:\modif1.dat 5000 83661000 Now I open orig1.dat with a hex editor and I take the first 16 bytes. I search for those bytes into mm6_2.exe. I find them at offset 0xad400. Let's see if all 0x5000 bytes are identical. I open a DOS window and I run: supcomp c:\orig1.dat mm6_2.exe 0 0xad400 0x5000 Ok, no differences, so we can patch them. supwrite c:\modif1.dat mm6_2.exe 0 0xad400 0x5000 But now if we run mm6_2.exe it hangs because it tries to decrypt already decrypted data and gets garbage. So let's run mm6.exe again, and when we reach the breakpoint we write "u @esp" and we go up some lines: 017F:008CC2FE 8D8D64FEFFFF LEA ECX,[EBP-019C] 017F:008CC304 51 PUSH ECX 017F:008CC305 8B95C4FEFFFF MOV EDX,[EBP-013C] 017F:008CC30B 52 PUSH EDX ;length 017F:008CC30C 8B85E4FEFFFF MOV EAX,[EBP-011C] 017F:008CC312 50 PUSH EAX ;source 017F:008CC313 8B8DBCFEFFFF MOV ECX,[EBP-0144] 017F:008CC319 2B8DB4FEFFFF SUB ECX,[EBP-014C] 017F:008CC31F 51 PUSH ECX ;destination 017F:008CC320 8B15B87D9F00 MOV EDX,[009F7DB8] 017F:008CC326 52 PUSH EDX ;handle 017F:008CC327 FF15B8839F00 CALL [KERNEL32!WriteProcessMemory] We must set length to 0 so we change: mov edx,[ebp-13c] push edx to: xor edx,edx nop nop nop nop push edx That is, we search for bytes (in mm6_2.exe): 8B 95 C4 FE FF FF 52 8B 85 E4 FE FF FF 50 8B 8D BC FE FF FF 2B 8D B4 FE FF FF 51 8B 15 B8 7D 9F 00 52 FF 15 B8 83 9F 00 and we change the first 6 bytes to: 33 D2 90 90 90 90 (it's best to search for many bytes, because there are similar parts of code, and we have to make sure we have found the exact place). You have to work the same way for the two other breakpoints (change crypted code with decrypted code and set to zero the length for WriteProcessMemory). Someone might wonder why I didn't write a program to do all this automatically. Well, the problem is, the code is similar but not the same for the games I tried (for example Grim Fandango uses ECX as the register to push the length parameter). Now we really need the original cdrom (you bought it, haven't you? :-) to get correctly decrypted code. We must still repeat the above procedure to decrypt and set length to zero when it reaches the fourth WriteProcessMemory (this time edx is kindly XORed for us, so we just need to "NOP" the following instruction that loads edx). We must also crack the part of code where it checks for the original cdrom and exits without executing our patched code (this is in the part of code we decrypted before, so if we hadn't decrypted it, we couldn't find it easily in the executable file). In fact if we try to execute the program after fourth decryption but before the last crack, it won't work, even with the original cdrom in the recorder! The last part of the crack is a bit trickier because you can't step into the program's code (F8 or F10 won't work). Moreover, if the program detects that you are trying to step into it, next time won't even load until you restart Windows, so you shouldn't put breakpoints except the ones I'll tell you. I'll spare you the time I spent to understand what the program does. First you can put a breakpoint on GetDriveTypeA that is used to find the cdrom. With F11 you get back to the program's code. If you scroll the code window some pages down, you'll find a series of POPs and a RET followed by a few INT 03. Put a breakpoint on the RET. Run the original mm6.exe with the original cd. Hmm, it doesn't reach the RET. Remove the cd from the reader and run it again. Ahh, now it reaches the RET with EAX=2. Put the original cdrom again into the reader but run mm6_2.exe (you must have decrypted and patched it ALL four times). It reaches the RET with EAX=7. If you put a copy into the reader you also get EAX=7. So it's easy to understand that EAX contains an error code when something goes wrong, and the RET is never reached when all goes right. Now you must run the modified mm6_2.exe after putting the original cd into the recorder and setting a breakpoint on GetDriveTypeA and on the RET. Press F11 to get to the code when it reaches GetDriveTypeA. Remember, you should get error code 7 so scroll down till you find: test edx,edx ;error? jnz ........ ;if it jumps => no error call [.....] ;start of error routine push 07 call ....... mov eax,7 ;error code jmp ........ ;jumps to the POPs and RET So the first jnz must be changed to jmp. We search for the following bytes: 75 17 FF 15 B0 83 9F 00 6A 07 into mm6_2.exe and we change 75 to EB. Run it. Another error, with return code 8. In the code we find: test edx,edx ;error? jnz ........ ;if it jumps => no error call [.....] ;start of error routine push 08 call ....... mov eax,8 ;error code jmp ........ ;jumps to the POPs and RET Search for: 75 17 FF 15 B0 83 9F 00 6A 08 and change 75 to EB. This time if you run it, you get error code 0. You find this code near the RET: jnz ........ ;jumps if error push 2c ;all checks passed! call ....... jmp ........ ;run, baby, run :-) So you must simply change jnz -> nop nop. The sequence to search for is 75 09 6A 2C and you change 75 09 with 90 90 At last the modified executable runs again with the original. But what about a copy, I hear you ask? Hooray, it works too because you removed error codes 7, 8 and 0 that also a copy produces! Of course the copy must have the right volume name, otherwise you'll get "Wrong disc" message box. Well, I don't know if this is the simplest way to crack Securom: I wrote all this especially for didactic purposes. It should work on any Securom protected game. So bye, bye Securom, we won't miss you :-) For comments write to: Pedro <pedro_i@iname.com>