Advanced Cracking

Project 4 (Cd-ROM faking)

Reversing the Securom "protection"

With a little "Addendum" by +Xoanon

With a new "GrimFandango Addendum" by Pedro

25 November 1998

courtesy of reverser+'s page of reverse engineering

Dear Reverser+,

I'm pleased to submit you a tutorial to contribute to project 4 about
cracking Securom protection, that is now used to protect many games.
This protection is based on an interesting new technique: data encoded in the
original cd that can be read by any reader but can not be reproduced
into a copy, and that is used to decrypt parts of the protection code. My
crack is based on replacing crypted data with decrypted data got from the
protection itself with a dump, then to remove the cd check.
After the tutorial, there is also the source of two C programs I wrote
to help the crack process.
Everything follows as pasted text.




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
- 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
- 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
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
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


xor edx,edx
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
Someone might wonder why I didn't write a program to do all this
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
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
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 <>

****************** Source code for supcomp ****************************

#include <stdio.h>
#include <conio.h>
#include <stdlib.h>
#include <mem.h>
#define AREA 32768

FILE *f,*g;
unsigned char *b1,*b2;
char notfound[]="Can't open: %s\n";
char seekerror[]="Seek error: %s\n";
char readerror[]="Read error or end of file: %s\nAborting\n";
long l,cont,ofsrc,ofdest;

void uscita(void)
if (b1) free(b1);
if (b2) free(b2);
if (f) fclose(f);
if (g) fclose(g);

void main(int argc, char *argv[])
        if (atexit(uscita))
           printf("Atexit error\n");
	if (argc!=6)
printf("Supcomp v1.0 by Pedro '98\n\n"
"Usage: supcomp <src> <dest> <offset src> <offset dest> <length>\n"
"Numbers may be in hex if prefixed by 0x\n\n"
"The program compares <length> bytes of <src> with the corresponding\n"
"bytes in <dest> starting from the specified offsets\n"
"Only differences are written to the output\n");
	if ((b1=(char *)malloc(AREA))==NULL) exit(EXIT_FAILURE);
	if ((b2=(char *)malloc(AREA))==NULL) exit(EXIT_FAILURE);
	if ((f=fopen(argv[1],"rb"))==NULL)
	if ((g=fopen(argv[2],"rb"))==NULL)
	if (fseek(f,ofsrc,SEEK_SET))
	if (fseek(g,ofdest,SEEK_SET))
        if ((l=strtol(argv[5],NULL,0))==0)
		printf("Wrong length\n");
	while (l)
		long letti,i;

		if (l>=AREA) letti=AREA;
		else letti=l;
		if (fread(b1,1,letti,f)!=letti)
		if (fread(b2,1,letti,g)!=letti)
                for (i=0;i<letti;i++)
                    if (b1[i]!=b2[i])
                       printf("%.8lx %.2x - %.8lx %.2x\n",cont+ofsrc+i,
                          (unsigned int)b1[i],cont+ofdest+i,(unsigned int)b2[i]);

****************** Source code for supwrite ****************************

#include <stdio.h>
#include <conio.h>
#include <stdlib.h>
#include <mem.h>
#define AREA 32768

FILE *f,*g;
unsigned char *b1;
char notfound[]="Can't open: %s\n";
char seekerror[]="Seek error: %s\n";
char readerror[]="Read error or end of file: %s\nAborting\n";
char writeerror[]="Write error: %s\n";
long l,ofsrc,ofdest;

void uscita(void)
if (b1) free(b1);
if (f) fclose(f);
if (g) fclose(g);

void main(int argc, char *argv[])
        if (atexit(uscita))
           printf("Atexit error\n");
	if (argc!=6)
printf("Supwrite v1.0 by Pedro '98\n\n"
"Usage: supwrite <src> <dest> <offset src> <offset dest> <length>\n"
"Numbers may be in hex if prefixed by 0x\n\n"
"The program writes <length> bytes of <src> to the corresponding\n"
"bytes in <dest> starting from the specified offsets\n");
	if ((b1=(char *)malloc(AREA))==NULL) exit(EXIT_FAILURE);
	if ((f=fopen(argv[1],"rb"))==NULL)
	if ((g=fopen(argv[2],"rb+"))==NULL)
	if (fseek(f,ofsrc,SEEK_SET))
	if (fseek(g,ofdest,SEEK_SET))
        if ((l=strtol(argv[5],NULL,0))==0)
		printf("Wrong length\n");
	while (l)
		long letti;

		if (l>=AREA) letti=AREA;
		else letti=l;
		if (fread(b1,1,letti,f)!=letti)
		if (fwrite(b1,1,letti,g)!=letti)

+Xoanon's addendum

                           Addendum to Pedro's crack
                             by xOANINO [UCF/CLASS]

Grüss dich, reverser+! Guess who's writing ? Marigold ? naaaaah....
Stone ? no no no ! Owl ? Nooooooooooo! Pippo Baudo ? Neither !!!!!

Its just your little xOANINO :)
I just read the essay by Pedro on SecuROM, very good essay .... But as
all italian things... its not a complete work. As our amazing politicians, he made
easy things more hard than they really are as I'll show you in this little
"addendum" (i can't write a full essay, as always i've girls awaiting 
me... you know :))

Anyway, very good work Pedro ... Even if your work is not 100%
complete, it works... and its good to see that also Italy has 
(indeed!) something worth to show in the cracking scene!

Well.... Here's the problem: As you all can read above in Pedro's essay, he
correctly decrypts all the stuff in the .text and .idata section and
patches the .exe. Ok, this is how SecuROM must be cracked.

So...w hat's wrong in Pedro's essay? Well, try to use his method with
(for ex.) a game which you want to rip and use without the CD. It won't work.
Why ? Well, coz the EXE Pedro produces is not 100% rebuilded. It still
depends on the SecuROM dlls, and if it dont find a CD in the drive with the
correct name and stuff, the program will not run.

And so here it comes your mega-busy, with girls, study, coding xOANINO to
the rescue to produce a full 100% working rebuilded executable :)

Just follow these 6 steps:

1) Follow Pedro essay until the BPX GetdrivetypeA / BPX on the RET some
   pages down.

2) As you can notice, some lines above the ret (where Pedro patches the
   last JNZ) there's a JMP EAX. Now... what is this JMP? It's the jump to the
   correct program entrypoint, which code is already decrypted following
   the Pedro essay.

3) Write down the value of EAX, and simply write this value at the
   entrypoint field of the PE header (PE+28h . should be at offset 
   A8h in every PE file).
   Consider you must subtract from EAX the imagebase value :
   Example : EAX = 418DB4h (Omnia99 entrypoint)
             Imagebase = 400000h
             value to write = 418DB4-400000 = 018DB4h (reversed, of course)
4) Now you can also kill the nomore needed sections... like .CMS_D
section and .PETITE section !! (use procdump for this, or do it by hand)

5) Wow, you can also delete the CMSxx.DLL !

6) ri-Wow, the EXE runs with no more problems !!!!

That's all ... its just an "addendum" :) Pedro made a very good work


Hiho to Devil,Miramax,Stone,Owl,RFlagg,CindyG,Randooooooooooome etc...etc....

Pedro's "GrimFandango" addendum

Dear Reverser+,

some days ago I found a small change in SecuROM protection that has been
made by Sony in a recent game, so I decided to write you again about
My essay is still valid, but, as we'll see, there is a bit more work to
do in order to crack the new SecuROM.
First of all, I'd like to thank +Xoanon for writing his "addendum". I
had really made things harder than they were. With his simple idea, we no
longer need to set WriteProcessMemory length to zero, nor we have to crack
error codes before the RET, because we simply skip all SecuROM code and we go
directly to the real entry point. I've still got a lot to learn... :-)

But there is something more to say about SecuROM.

Well, in my essay I was a bit imprecise. If you remember I cracked Might and
Magic VI as an example, and of course that worked (I read Reverser+'s FAQ and
I don't want to write him saying "My lame crack doesn't work" after he has
published my job :-).
I also said that Conflict Freespace and Grim Fandango were the same.
It's here, that I've been imprecise. In fact I only had a non-working copy of
those two games, but I saw there was the same multi-step decryption, so
I assumed the entire protection was the same.
Some days later I got the original of Grim Fandango and I was disappointed
when I saw that Sony left the multi-step decryption, but added something more
to the protection.
So I want to behave better than my hated italian politicians and I don't want
to let this crack be another unfinished italian thing :-)

First of all, you have to make the usual copy of the decompressed original
executable called grim2.exe.
Then you must patch the four parts of code as I described in my first essay.
You can skip the part where I put zero length for WriteProcessMemory or I
crack the error codes, because we'll no longer need that part of
SecuROM code.
Also, you should put a breakpoint on "jmp eax" as +Xoanon pointed out, to
get the real entry point, and change it into PE header.
But if you run it, it doesn't work. Why? Follow me and you'll discover it.

Now let's breakpoint again on WriteProcessMemory and execute the original
GrimFandango.exe (with the original copy in the reader).
We see there is the same four parts decryption, but after that,
WriteProcessMemory is called many more times during game execution, and
only 4 bytes are patched every time.
When we are inside the breakpoint if we write "u (@esp+8)-2" to see
where the data is going to be written, we always see the same call:

call [008d6218] (of course it changes from game to game)

by the way, this is the point the SecuROM procedure at [008d6218] was
just called from, and it's this procedure that is calling now
If we press F11 we can see what happens. That call has been changed to:

call [KERNEL32!GetVersion]

(this is just an example, every call is changed to its original value, i.e. 
the value that was in the unprotected game before Sony messed with it :-)

We have now understood it. Every time the unprotected game had to call a
system routine, or even one of its own routines, Sony saved the address
of the call into a table, and made the call point to a SecuROM routine.
When this routine is executed, it can understand where it was called
from by looking at the return value in the stack, then it patches the code
so next time the call will be made directly. At last it must give
control to the routine that was to be called, and it achieves this by a "jmp
eax" (in our example eax will contain the address of GetVersion).
Unfortunately this goes on during the whole execution of the program.
But we don't like to keep such a boring neighbour as a SecuROM part of
code, we want to kill it completely.

First of all we must see what the real address of this SecuROM routine is: 

in location [8d6218] we find address 8cb050.

Now let's take Wdasm and disassemble grim2.exe (so the code at 8cb050 is
already decrypted). Well you don't really need to disassemble it to make
the crack, because I'll explain all steps to make later on, but it's
useful to learn, because that's the real reason you are studying reversing 
and reading this for, not for just copying some silly games, are you? :-)

You can just view the code with Softice when you are inside the procedure.
Let's go to 8cb050. Here we see many references like these:

:008CB069 8B0DBCDF8E00            mov ecx, dword ptr [008EDFBC]
:008CB072 890DBCDF8E00            mov dword ptr [008EDFBC], ecx
:008CB0AA 8A8240FC8E00            mov al, byte ptr [edx+008EFC40]

So there must be the table for decoding all the calls. Note that we
don't care about how this table is made. We just need to rebuild the
executable the same way we did with the four patches.
The routine ends like this:

:008CB385 FF1518E78E00            call dword ptr [008EE718]
				  ;call to WriteProcessMemory

:008CB38B 61                      popad
:008CB38C 8B45F8                  mov eax, dword ptr [ebp-08]
:008CB38F 8BF0                    mov esi, eax
:008CB391 8B06                    mov eax, dword ptr [esi]
:008CB393 5F                      pop edi
:008CB394 5E                      pop esi
:008CB395 5B                      pop ebx
:008CB396 8BE5                    mov esp, ebp
:008CB398 5D                      pop ebp

:008CB399 FFE0                    jmp eax	;here it makes the original
						;game's call

:008CB39B 5F                      pop edi
:008CB39C 5E                      pop esi
:008CB39D 5B                      pop ebx
:008CB39E 8BE5                    mov esp, ebp
:008CB3A0 5D                      pop ebp
:008CB3A1 C3                      ret

Hmm, now an interesting idea comes to my mind.
First of all the routine doesn't use ebx, so we can use it to get control
after calling the routine. Then we could "simulate" the program calls by
using the following small assembly program that can be
Softice-assembled in an unused area of Adump (poor Adump, we are 
overloading it :-) :

:00000100 B9FA0F4F00              mov ecx, 004F0FFA
				;this is (length - 6 bytes) of .text section
				;of course you'll have to change it with
				;different games

:00000105 BA00104000              mov edx, 00401000
				;this is starting address of .text section
:0000010A 803AFF                  cmp byte ptr [edx], FF
				;FF 15 18 62 8D 00 is the sequence that
				;corresponds to call [008d6218], and
				;you'll have to change it according to
				;the game you're cracking.
				;We are searching for that sequence into
				;the code

:0000010D 7530                    jne 0000013F
				;not found, continue searching

:0000010F 807A0115                cmp byte ptr [edx+01], 15
:00000113 752A                    jne 0000013F
:00000115 807A0218                cmp byte ptr [edx+02], 18
:00000119 7524                    jne 0000013F
:0000011B 807A0362                cmp byte ptr [edx+03], 62
:0000011F 751E                    jne 0000013F
:00000121 807A048D                cmp byte ptr [edx+04], 8D
:00000125 7518                    jne 0000013F
:00000127 807A0500                cmp byte ptr [edx+05], 00
:0000012B 7512                    jne 0000013F

:0000012D 8D4206                  lea eax, dword ptr [edx+06]
				;found! Now we "simulate" the call: we put
				;the return address into the stack like the
				;call was made by the program
:00000130 60                      pushad
				;...but first we'd better save our precious

:00000131 50                      push eax
				;ahhh, now the correct return address is in

:00000132 BB3D010000              mov ebx, 0000013D
				;we load ebx with the address of the follwing
				;"pop eax" instruction, so the we'll regain
				;control after the patching. Change this value
				;according to your offset in Adump

:00000137 FF2518628D00            jmp dword ptr [008D6218]
				;and now, ladies and gentlemen, let's foul
				;SecuROM (as always, change 008d6218 according
				;to the game you're cracking)

:0000013D 58                      pop eax
:0000013E 61                      popad

:0000013F 42                      inc edx

:00000140 E2C8                    loop 0000010A
				;the search will go on...

:00000142 CC                      int 03
				;finished, back to Softice

Let's run GrimFandango.exe with +Xoanon's breakpoint on "jmp eax". Now
we are about to enter the program (remember we are always running
GrimFandango.exe because grim2.exe doesn't work).
With "u 8cb050" we see our mostly hated routine :-). Scrolling some
pages down we see the "jmp eax" I was telling you about before. 
This must be changed to "jmp ebx", to let our tiny (tiny but effective :-) 
assembly program regain control.
Then we write current eip down, we set "i3here on" and we set eip to the
beginning of our assembly code. F5, then we wait a little bit (if I or
you have made no mistakes, otherwise you might wait forever for Windows to
resurrect :-)
Wow, it's finished. So what happened? Well, all "call [008d6218]" should
have been replaced with their correct original counterpart. To tell the
truth it's possible (but very unlikely) that a spurious sequence FF 15 18 62
8D 00 that didn't represent the above mentioned call has been incorrectly
It's unlikely, though, because 6 bytes are a very specific pattern. So let's 
just try it first, if everything crashes -or worse- we'll just tediously 
investigate all the replace locations.

We must now dump from 401000 to the end of the .text section that can
be seen with "map32" (start=401000, length=4f1000 => end=8f2000).
The problem now is that some pages are not loaded into memory, so when
we write "m" command we get an error.

What follows is an idea to dump even if some pages are not loaded into
memory: suppose Adump's dumping area starts at "pippo" (with incredible 
italian imagination :-).
We should assemble this small program with Softice near the end of
Adump's area, say pippo+4ff000 (ah, remember of course to increase Adump's
area, if you need it, like in this case, that should be at least 0x500000 


Ok, when we need to dump we write down current eip, then we change eip
to pippo+4ff000, we step over pushad and pushf, then we manually load ecx
with the dump length (in this case 4f1000), esi with starting offset
(401000), and edi with destination offset (pippo) and we step over the 
remaining instructions.

When we've finished dumping we can restore the eip we wrote down
before, and GrimFandango will continue peacefully not even knowing we 
have turned it inside out! :-)
Ah, just a note of warning: before dumping or calling my assembly
routine, remove ALL breakpoints, otherwise you'll have unwanted "int 3"'s 
in the dump (like I did :-).

The last part is very easy: see where the dumped area starts in the
executable and replace it with supwrite (well, my knowledge of PE executables 
is limited, but I think it's ok to replace it all. Otherwise you may 
write a small C program to replace only the FF 15 18 62 8D 00 sequences 
with the correct ones from the dump).
If the complete replacing is correct, you don't even need the first four
steps: with this single dump and the correct entry point you get it all.

What a nice thing: our non-working GrimFandango is alive again! Not bad
for a skeleton :-)).

As always my address is added below for comments but I won't answer stupid
questions nor too generic questions (like "Can you tell me more about 
SecuROM ?" :-)


redhomepage red links red anonymity +ORC redstudents' essays redacademy database redbots wars
redantismut redtools redcocktails redjavascript wars redsearch_forms redmail_reverser
redIs reverse engineering illegal?