For the last couple of years, I've been planting a CTF-like challenge as an easter egg in Swisscom's security.txt file (RFC 9116). The current challenge is here: https://www.swisscom.ch/.well-known/security.txt. All challenges are also archived on Github: https://github.com/swisscom/securitytxt. I thought it was about time to provide the solutions to the past challenges. You can find the writeup for 2022 in my last post. Now let's continue with year 2023. You were given the following string:
aHR0cHM6Ly9pbWd1ci5jb20vYS9kaFlkUXpqExperienced blue teamers will quickly recognize the Base64 encoding as well as guess it's a URL, judging from the prefix. The decoded value is indeed a link to the following image on the image sharing platform imgur:
It's a screenshot of Microsoft Minesweeper featuring some bizarre content in the game field. The way the tiles are arranged certainly does not represent an achievable game state. The image also contains an MD5 hash 9C45D38B74634C9DED60BEC640C5C3CA. Using it, we can find references to the winmine.exe binary on VirusTotal or on The Internet Archive. This is the version of minesweeper which was was originally shipped with Windows XP in 2001. You can download the binary and make sure it matches the given MD5 hash:
Ok, so now we need to make some guesses and assumptions. We are eventually looking for a flag, a secret text, to solve the challenge. If we look at the game field, we see that the tiles are arranged on three lines. The different tiles might map to characters that form words. We will first need to understand how the game field and the tiles are represented in memory. It's safe to assume, that we'll be dealing with a 2-dimensional array of elements. However, note that the game allows to customize the dimensions. By default (beginner mode), it's a 9x9 field. In the screenshot, we have 9x21.
To better understand the inner workings of the program, we are going to proceed with a debugger for dynamic analysis. For this, I can highly recommend the open source x64dbg (you'll need to use the 32bit version, though), or if want to hack like it's 2001, you can also use Immunity Debugger or OllyDbg. First, we need identify the memory region of the game field. For this, we are going to exploit a cheat/easteregg, which - fun fact - already existed in previous Windows 3.1 versions of Minesweeper:
Type XYZZY and press [Shift][Enter]. The top left pixel on your screen will become white but turn black when your mouse is above a mine.
This will use the SetPixel() Windows API call provided in GDI32.dll, the Windows Graphics Device Interface. This is likely the only place the application will use this call, since it will rely on other, more abstract API calls to render all of the game elements instead. Run Minesweeper in the debugger, continue execution past the initial/default breakpoints, and apply the cheatcode. In the executable modules, look for the SetPixel symbol, listed as an export in gdi32.dll and set a breakpoint accordingly.
Now, hovering the cursor above a mine will trigger the breakpoint on the SetPixel() call. Going one step down the call stack, we can identify how the arguments are computed in the caller:
- hDC: is the return value of the previous call to GetDC (this value is irrelevant)
- X and Y: both originate from EDI, which has value 0. This confirms that we are setting the topmost/lefmost pixel of the screen.
- Color: will be either 0x00000000 (black) or 0x00ffffff (white), depending on the value of EAX, which is the result of a computation involving a memory value at address 0x01005340.
By inspecting the memory values starting at memory address 0x01005340, we realize that there is a link to the displayed tiles on the game field. By editing the values in memory and some trial and error, we can start to understand the underlying layout. Starting at an offset of 32 bytes (at address 0x01005360), we can manipulate the displayed tiles by changing the bytes values:
After some exploration, we can devise that each row of the game field is stored using 32 bytes. As the game's dimensions can be changed, the actual fields are surrounded by "guard" values (0x10) each as top/bottom rows and left/right columns. The values depicted as XX below represent the actual tiles. The remaining values (0x0F) are just padding.
0x01005340: 0x10 0x10 0x10 0x10 0x10 0x10 0x10 ... 0x10
0x01005360: 0x10 XX XX XX ... XX 0x10 0x0F 0x0F ... 0x0F
0x01005380: 0x10 XX XX XX ... XX 0x10 0x0F 0x0F ... 0x0F
...
0x01005460: 0x10 XX XX XX ... XX 0x10 0x0F 0x0F ... 0x0F
0x01005480: 0x10 0x10 0x10 0x10 0x10 0x10 0x10 ... 0x10
In our case, using dimensions 9x21, the first row spans from memory addresses 0x01005361 to 0x01005375, the second row from 0x01005381 to 0x01005395, and so on, until the last row at addresses 0x01005461 to 0x01005475. By the way: all mentioned addresses will work for you as well, since winmine.exe does not support address space layout randomization (ASLR).
After we located the memory region, we still need to understand the mapping of bytes to tiles. For that, let's write a PyCommand for Immunity Debugger to fill out all possible values in the range 0-255 in memory:
There are two interesting observations:
- Even rows have a repeating pattern
- Odd rows are blank
From the first observation, we can derive that the different tile faces are represented using the 4 least significant bits. From the second observation, we derive that the 5th bit is a "blank" flag. Next is a mapping of printable ASCII characters to the corresponding tile faces. Due to the "blank" flag, only letters A-O can be recovered, and due to the repeating pattern, the mapping is ambiguous, e.g. the "Bomb with x" is either the + sign, or the letter k/K (fortunately, ASCII was designed such that uppercase and lowercase letters differ only in the 6th bit, which make them map to the same tile).
| Decimal | Binary | Character | Tile Face |
|---------|-----------|-----------|-----------------|
| 32 | 0100000 | Space | Empty |
| 33 | 0100001 | ! | 1 |
| 34 | 0100010 | " | 2 |
| 35 | 0100011 | # | 3 |
| 36 | 0100100 | $ | 4 |
| 37 | 0100101 | % | 5 |
| 38 | 0100110 | & | 6 |
| 39 | 0100111 | ' | 7 |
| 40 | 0101000 | ( | 8 |
| 41 | 0101001 | ) | Clicked ? |
| 42 | 0101010 | * | Black bomb |
| 43 | 0101011 | + | Bomb with x |
| 44 | 0101100 | , | Bomb red bg |
| 45 | 0101101 | - | Unclicked ? |
| 46 | 0101110 | . | Flag |
| 47 | 0101111 | / | Unclicked Empty |
| 64 | 1000000 | @ | Empty |
| 65 | 1000001 | A | 1 |
| 66 | 1000010 | B | 2 |
| 67 | 1000011 | C | 3 |
| 68 | 1000100 | D | 4 |
| 69 | 1000101 | E | 5 |
| 70 | 1000110 | F | 6 |
| 71 | 1000111 | G | 7 |
| 72 | 1001000 | H | 8 |
| 73 | 1001001 | I | Clicked ? |
| 74 | 1001010 | J | Black bomb |
| 75 | 1001011 | K | Bomb with x |
| 76 | 1001100 | L | Bomb red bg |
| 77 | 1001101 | M | Unclicked ? |
| 78 | 1001110 | N | Flag |
| 79 | 1001111 | O | Unclicked Empty |
| 96 | 1100000 | ` | Empty |
| 97 | 1100001 | a | 1 |
| 98 | 1100010 | b | 2 |
| 99 | 1100011 | c | 3 |
| 100 | 1100100 | d | 4 |
| 101 | 1100101 | e | 5 |
| 102 | 1100110 | f | 6 |
| 103 | 1100111 | g | 7 |
| 104 | 1101000 | h | 8 |
| 105 | 1101001 | i | Clicked ? |
| 106 | 1101010 | j | Black bomb |
| 107 | 1101011 | k | Bomb with x |
| 108 | 1101100 | l | Bomb red bg |
| 109 | 1101101 | m | Unclicked ? |
| 110 | 1101110 | n | Flag |
| 111 | 1101111 | o | Unclicked Empty | |---------|-----------|-----------|-----------------|
Using this mapping, we can recover parts of the text. Every _ is then either a space, @, a backtick (`) or one of the letters P-Z:
GOOD_JOB!
_END_EMAIL__O
_ED._ILL___I__COM.COM
The first 10 people who wrote a message to the e-mail address received some Swisscom swag as a reward. Note: the e-mail address was chosen as a reference to the 1999 hacker/cyberpunk movie The Matrix, following the nomenclature of the meeting rooms in the Swisscom Cyber Defence offices. Any other references are explicitly excluded.
I hope you enjoyed solving this challenge. I got my inspiration for it after viewing the following video by jeFF0Falltrades: Reverse Engineering and Weaponizing XP Solitaire (Mini-Course).
Finally, here are some additional links and resources about Minesweeper you might enjoy:
- The notorius mimikatz has a cheat module for minesweeper, however it only applies to newer versions of the game. A previous mimikatz version targeting the WinXP winmine.exe can still be found in meterpreter. If you want to use it in native mimikatz, I retro-ported the code here: mimikatz-winmine.
- The winmine source code leaked in 2004 together with the Windows NT 4.0 and Windows 2000 source code. It's fun to read.
No comments:
Post a Comment