1 - Introduction

Today we gonna have a look at the Windows game 'Minesweeper'. Let's see if we can make it that we always win. :-)

You find Minesweeper in your system32 folder in your Windows directory, the file is called winmine.exe (if you installed these games with your windows installation). My file version of winmine.exe is 5.1.2600.0 (I have WinXP with service pack 2 (German)), so if you have another version, the offsets and memory locations can be different.

2 - First look at the target...

We have a gamefield of choosable width and height, also the number of mines we can define. Goal is to open all fields without a mine; as soon as we select a mine, we loose. Note that a field is uncovered when we release the mousebutton and not if we press it; that means we have to look at the WM_LBUTTONUP message.
Let's think how we would code the gamefield as a programmer (at least as I would do it :-) : as data structure we would probably use a one- or two-dimensional array of some type, perhaps an integer, defining each possible state with a special value (e.g MINE=0, EMPTY=1 and so on...). That means at start of a new game a memory block of special size (most probably proportional to width*height of gamefield) is allocated and mines are placed either randomly or with help of an special algorithm. On every release of the left mousebutton, we look if the cursor is over a single field, then we look at the corresponding element in our array. If it was a mine -> gameover, otherwise we would calculate the number to inform the player about near mines. Finally we repaint the gamefield and that's it.
Ok, with that knowledge in mind we can start the real part...

3 - Let's begin...

Ok, start Ollydbg, open a backup copy of winmine.exe and begin tracing:

After some checks and commandline parsing we step into the following call which starts the real game:

Stepping into this call, we see normal startup code like initiation of common controls and loading icons and cursors; after that we see that a window class is registered with 'RegisterClass', the main window is created and the application enters the message loop. So we have to find out where the messages are processed. As we know, the address of the window procedure is part of the WNDCLASS structure passed to the RegisterClass call. Have a look:

For the beginners: How do we know that address 1001BC9 is our wanted window procedure? Well, very often it's a hardcoded address like in our case. But to be more sure, we can look at the definition of the WNDCLASS structure in MSDN. There we see that the pointer to the window procedure is the second member in this structure: here in our case the first member is in [EBP-4C], so in [EBP-48] must be second (the first member is of type UINT and so 4 bytes long).

The call at 1002005 is the only one which is processed when a mousebutton is released, so here must be processed the game logic. Step into it...

At 1005118 the selected field in x-direction is saved, in 100511C the one in y-direction. (Note: To find that out, you can rightclick one of these lines and select 'Find reference to address constant'. Only at three locations a value is written to this address; with some effort we find out that at 10031DD/10031E4 on every mouse move the fields under the cursor are written to these locations).
Both values are checked for validity: if they are greater than zero and smaller than the actual width/height.
Some lines below we have:

After some runnings, it's easy to find out that at 10057A4 a flag is stored saving if it's the first player's try of current game. If so, we don't jump but do some initialization things like starting the game time. Going on, we discover following lines:

Seems promising at first, but this call is not always executed. Step over it and see what coming next:

Ok here is the important part: main purpose of the call at 10038BC is painting the changed gamefield to screen. The call at 10038B1 does the main game logic, e.g it checks again if it's the first try (if so it handles a special case as you may have noticed that on your first try you never hit a mine) and calculates the new field, dependent if the player hit a mine or not.
But let's have a look at the lines in front of this call: the selected column and the selected row multiplied by 32 are added to an address constant. And I can tell you, this calculation also happens quite often inside the game logic call. Follow 1005340 in dump and .... we see this:

It looks as we have found the memory location where the gamefield data is stored. If you want you can change the width, height and number of mines in Minesweeper to become sure that this is really the actual gamefield data.... and yes it is :-)
Well, in fact that's all we have to know: cause the address is a constant, this data is always(!) stored at 1005340 which makes things much more easier than to handle with pointers to changeable memory places. To access a special field, you just do: field = 0x1005340 + (row * 32) + column. 0x8F means there is a mine, 0x0F means it's still uncovered, 0x40 it's uncovered.... the rest you can find out by yourself if you want but it's not necessary...
So what to do know? First I thought of patching, but it seems a bit complicated to me. We would have to check if the player has hit a mine and if so we could redirect the program flow that the field would stay uncovered. But that means inserting additional code into a cave, but what's more a problem is the fact that we have to change also the paint routine in this case (I tried some patching and got some strange graphic errors...). And we have seen that several game states/options etc. are saved somewhere in memory (e.g. is it the first player's try? Is a mouse button currently pressed? And so on...). Probably we would have to take a look at them, too in order to keep them valid.

That's why I have decided to code a little loader which doesn't change the Minesweeper file in any form. The loader starts minesweeper (or attaches a running instance), reads periodically the memory at our found address (0x1005340) and paints the current gamefield, including all mines of course. Have a look at the source, it's quite easy and well commented. Here a screenshot where you can see the loader in action:

I hope you found this little article and my source useful :-) C u again...
Questions, criticism? Mail me!

Sunshine, March 2006

This site is part of Sunshine's Homepage