I was completely sure that I found minefield array. text:010036AC mov currentMineFieldHeight, ecxĪnd when I saw it. text:010036A7 mov currentMineFieldWidth, eax
text:01003698 cmp ecx, currentMineFieldHeightĪ little bit later new values overwrite current and subroutine is called. text:0100368A cmp eax, currentMineFieldWidth text:0100367F mov ecx, newMineFieldHeight
text:0100367A mov eax, newMineFieldWidth
MINESWEEPER HACK CODE
Let's set new names.text:0100367A startNewGame proc near CODE XREF: handleButtonPress+CAp Playing with custom minefield size showed that first pair are new dimensions and second - current dimensions. Take a look at actual values using WinDBG ('bp 01003696' on break 'p eax p ecx') - they seemed like minefield dimensions for me. There are two values (dword_10056AC, uValue) read into registers eax and ecx and compared to another two values (dword_1005164, dword_1005338). Let's take a look at the first part of that function. Is that the function that initiates new game? Find that out in the last part! Stay tuned. text:01001ECD jmp callDefAndExit default It leads to code chunk that calls some proc and exits wndProc.text:01001EC8 loc_1001EC8: CODE XREF: mainWndProc+20Fj text:01001DD8 jz loc_1001EC8 here is our jump text:01001DBC HandleWM_COMMAND: CODE XREF: mainWndProc+197j Use context menu or 'H' keyboard shortcut to display decimal values and you can see our jump. It compares wParam with different constants.text:01001DBC HandleWM_COMMAND: CODE XREF: mainWndProc+197j
Now let's get back to code, that handles WM_COMMAND. You can see here, that F2 button corresponds to 510 in wParam. Feed it with binary and it shows you everything.
MINESWEEPER HACK HOW TO
Ok, we already found where WM_COMMAND is processed, but how to determine corresponding wParam parameter value? This is where Resource hacker comes into play. Part 2 of 3Īccording to Using Keyboard Accelerators when F2 button is pressed wndProc function Long story short minefield stored as an array of bytes, 0x0F shows that byte is not used (playing smaller field), 0x10 - empty field, 0x80 - mine. If you are interested I can write another couple of posts. It's quite a lot of text for a single answer. To understand accelerator handling check out: It is an easy way to find out message id values. Right click on 111h and use "Symbolic constant" -> "Use standard symbolic constant", type WM_ and Enter. It can be done either by tracing down edx in IDA or by setting conditional breakpoint in WinDbg and pressing F2 in the game.Įither way leads to something like. You are to find where it is compared to 111h. This is message id, which in case of F2 button press should contain WM_COMMAND value. Hit Enter on function name (use 'N' to rename it to something better) I already named function mainWndProc in my case.text:0100225D mov, offset mainWndProc Now look above for RegisterClass function and it's parameter WndClass.lpfnWndProc. Open up IDA, Imports window, find "CreateWindow*", jump to it and use "Jump xref to operand (X)" command to see where it is called.
MINESWEEPER HACK WINDOWS
Good reverse engineer should first get to know OS, core API functions, program general structure (what is run loop, windows structures, event handling routines), file format (PE). If you are serious into reverse engineering - forget about trainers and cheat engines.