markupmaster
07-04-2008, 03:57 AM
http://filesharingtalk.com/vb3/picture.php?albumid=25&pictureid=218"I wrote a very simple program to read Minesweeper's memory and display a grid showing where the bombs are. I used OllyDbg for disassembly and reversing and CheatEngine for quickly finding known values in memory.
During this process, I found out that Minesweeper CHEATS, only spawns about half the bombs, and moves bombs mid-game. (Sometimes to where you are clicking, sometimes it will move a bomb that you click on.) Regardless, I consider this project a success.
During this process, I found that Minesweeper will sometimes assist you and move bombs away from where you are clicking on. Originally, I thought that Minesweeper was only "spawning" about half of the bombs, but as it turns out I misunderstood the way minefield was represented in memory and all bombs are generated at the beginning of the game and not first click or any later clicks.
My error was in thinking that minefield was stored in a 2-dimensional array (ie: minefield[x][y] = FLAGS) where max(x) (and max(y)) are the size of the grid (ie: 9x9 on Beginner) but as xumiiz on Reddit (http://www.reddit.com/user/xumiiz/) pointed out:
His program is buggy. It's not reading the grid in correctly - it's a constant width of 32 bytes, but a window from the top left is taken for the actual size of the playing field.
So, first bugfix to his source:
for(DWORD grid_loc = 0; grid_loc < grid_height * grid_width; grid_loc++) {
should be:
for(DWORD grid_loc = 0; grid_loc < grid_height * 32; grid_loc += ((grid_loc%32)==(grid_width-1))?(32-grid_width+1):1) {
And:
if((grid_loc % grid_width) == (grid_width - 1))
should be changed to:
if((grid_loc % 32) == (grid_width - 1))
With these fixes, it reads all the bombs properly.
And also this comment from Anonymous (http://www.subversity.net/reversing/hacking-minesweeper#comment-33):
Sorry but your program is reading the grid incorrectly. Minesweeper uses a grid with a fixed width of 32 bytes and the playing field is takena s a window of that grid from the top left. e.g. beginner mode uses bytes 0 to 8 and skips bytes 9 to 31 per every 32 byte row.* Fixing the program to read based on that patten shows that Minesweeper only moves the mine if it happens to be the first square you click on. Apart from that, all mines are randomly placed at the start of the game.
(* Actually it would use bytes 0 to 10, where bytes 0 and 10 are 0x10 which is to indicate the border of the mine field, and bytes 1 to 9 are the actual squares. but that's not really relevant to the analysis if you're just &ing with 0x80 to find bombs.)
The source of this program is available here: (This is the original and still requires an update, my code will be fixed soon.)
http://www.room641a.net/files/projects/minehack/minehack.cpp
Sample program output:
Minehack - Reverse Engineering and Coding by Sub <[email protected]>
---
Fairly simple program to display already-placed bombs in minesweeper.
---
PID: 2836
Height: 9
Width: 9
---
[ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ] And now, probably the most important comment block of my entire program (I have updated this information here to be current, but the source file still needs updated):
/* Did you know?
*
* Minesweeper stores its minefield in an array char-sized (1 byte) multi-dimensional array. Each byte
* in memory corresponds to a specific location on the grid. It appears to use
* simple bit masks. (This section needs updating, but the information below is current.)
*
* 0x10 "Border" - Appears to mark the beginning of a row, which means my offset is off by +1
* 0x40 Button has been pressed already
* 0x80 Bomb is in place. These can move mid-game if clicked on
* Bit-wise OR with:
* 0x00 The square is exposed
* 0x0X X is 1-8 -- # on square (number of mines neighboring this square)
* 0x0D Square is marked with question mark
* 0x0E Square is marked with flag
* 0x0F Blank squares are all 0x0F
*
* AND THEN THERE'S 0xCC WHICH MEANS YOU CLICKED A DAMN BOMB AND LOST! "
*/ Please note: At 12:20AM EST on 7/3 I have edited this post by merging a couple of updates, adding contributions from comments here and on Reddit, and retracting false, invalid, or unfounded statements (these are still available to read, they are just "crossed out") I'm still on the road (writing this from a hotel in Iowa) but will try to reply to comments when I arrive in California.
------------------------------------------------------------------------------------------------------------------
I found this on digg. It was quite interesting to me..
[b]:source: [B]Source: http://www.subversity.net/reversing/hacking-minesweeper?1
During this process, I found out that Minesweeper CHEATS, only spawns about half the bombs, and moves bombs mid-game. (Sometimes to where you are clicking, sometimes it will move a bomb that you click on.) Regardless, I consider this project a success.
During this process, I found that Minesweeper will sometimes assist you and move bombs away from where you are clicking on. Originally, I thought that Minesweeper was only "spawning" about half of the bombs, but as it turns out I misunderstood the way minefield was represented in memory and all bombs are generated at the beginning of the game and not first click or any later clicks.
My error was in thinking that minefield was stored in a 2-dimensional array (ie: minefield[x][y] = FLAGS) where max(x) (and max(y)) are the size of the grid (ie: 9x9 on Beginner) but as xumiiz on Reddit (http://www.reddit.com/user/xumiiz/) pointed out:
His program is buggy. It's not reading the grid in correctly - it's a constant width of 32 bytes, but a window from the top left is taken for the actual size of the playing field.
So, first bugfix to his source:
for(DWORD grid_loc = 0; grid_loc < grid_height * grid_width; grid_loc++) {
should be:
for(DWORD grid_loc = 0; grid_loc < grid_height * 32; grid_loc += ((grid_loc%32)==(grid_width-1))?(32-grid_width+1):1) {
And:
if((grid_loc % grid_width) == (grid_width - 1))
should be changed to:
if((grid_loc % 32) == (grid_width - 1))
With these fixes, it reads all the bombs properly.
And also this comment from Anonymous (http://www.subversity.net/reversing/hacking-minesweeper#comment-33):
Sorry but your program is reading the grid incorrectly. Minesweeper uses a grid with a fixed width of 32 bytes and the playing field is takena s a window of that grid from the top left. e.g. beginner mode uses bytes 0 to 8 and skips bytes 9 to 31 per every 32 byte row.* Fixing the program to read based on that patten shows that Minesweeper only moves the mine if it happens to be the first square you click on. Apart from that, all mines are randomly placed at the start of the game.
(* Actually it would use bytes 0 to 10, where bytes 0 and 10 are 0x10 which is to indicate the border of the mine field, and bytes 1 to 9 are the actual squares. but that's not really relevant to the analysis if you're just &ing with 0x80 to find bombs.)
The source of this program is available here: (This is the original and still requires an update, my code will be fixed soon.)
http://www.room641a.net/files/projects/minehack/minehack.cpp
Sample program output:
Minehack - Reverse Engineering and Coding by Sub <[email protected]>
---
Fairly simple program to display already-placed bombs in minesweeper.
---
PID: 2836
Height: 9
Width: 9
---
[ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ] And now, probably the most important comment block of my entire program (I have updated this information here to be current, but the source file still needs updated):
/* Did you know?
*
* Minesweeper stores its minefield in an array char-sized (1 byte) multi-dimensional array. Each byte
* in memory corresponds to a specific location on the grid. It appears to use
* simple bit masks. (This section needs updating, but the information below is current.)
*
* 0x10 "Border" - Appears to mark the beginning of a row, which means my offset is off by +1
* 0x40 Button has been pressed already
* 0x80 Bomb is in place. These can move mid-game if clicked on
* Bit-wise OR with:
* 0x00 The square is exposed
* 0x0X X is 1-8 -- # on square (number of mines neighboring this square)
* 0x0D Square is marked with question mark
* 0x0E Square is marked with flag
* 0x0F Blank squares are all 0x0F
*
* AND THEN THERE'S 0xCC WHICH MEANS YOU CLICKED A DAMN BOMB AND LOST! "
*/ Please note: At 12:20AM EST on 7/3 I have edited this post by merging a couple of updates, adding contributions from comments here and on Reddit, and retracting false, invalid, or unfounded statements (these are still available to read, they are just "crossed out") I'm still on the road (writing this from a hotel in Iowa) but will try to reply to comments when I arrive in California.
------------------------------------------------------------------------------------------------------------------
I found this on digg. It was quite interesting to me..
[b]:source: [B]Source: http://www.subversity.net/reversing/hacking-minesweeper?1