Writeup: FlareOn 2020: 008 - Aardvark
2. Input data
The challenge file is here. Password: flare.
The subject of the task is the
3. Inspection of ttt2.exe file
I verified the file using
$ file ttt2.exe ttt2.exe: PE32+ executable (GUI) x86-64, for MS Windows
I analyzed the strings in the file. In addition to the names of functions indicating the use of WinAPI, a string appeared indicating the necessity to use Windows Subsystem for Linux:
$ strings ttt2.exe ... Default distribution must be WSL 1 ...
Launching the application resulted in an error:
After installing WSL and Ubuntu 20.04 LTS, the application was successfully launched:
The ttt2.exe file is therefore a tic-tac-toe game.
4. ttt2.exe analysis
A review of the imported functions revealed that the application uses Windows Sockets 2.0 quite often:
I also decided to analyze the running process, using the Sysinternals Suite. While looking at the ttt2.exe process, I noticed that there is another process called
When I looked at its properties, I didn’t see any information about an existing executable:
I spied process properties in Process Hacker:
This revealed the path to the executable
9F29.tmp. Further testing the application, I noticed that every time ttt2.exe is run, a new file is created in the
%TEMP% directory with a random name ending in
.tmp. The 9F29.tmp file was undoubtedly related to the ttt2.exe application and it was definitely not a random process coming from another application.
Digression: Note that Process Explorer from Sysinternals and Process Hacker show different results. It is never worth relying on just one tool. I showed the “sensitivity” of this type of programs, among others here
5. 9F29.tmp analysis
I verified the file using
$ file 9F29.tmp 9F29.tmp: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e26dfd1a32bf2fc2f804ede74b1b9ef9c73268bf, stripped
The 9F29.tmp file was therefore run using Windows Subsystem for Linux. The 9F29.tmp file was therefore run using Windows Subsystem for Linux. Analysis using a disassembler revealed that it is a program pretending to be a second player.
The fragment of the main function, which was located just before calling the _send function, was responsible for generating the opponent’s character (the letter ‘X’). The _send function, in turn, was responsible for communication using the socket:
Directly the opponent’s mark was generated by the instruction
mov byte ptr [rax+rdx], 58h
that was written in the machine code as:
6. Code modification
Therefore, it was necessary to perform a modification consisting in forcing the generation of the player’s mark instead of the opponent’s mark.
For this purpose, an existing instruction had to be modified so that the instruction was executed:
mov byte ptr [rax+rdx], 4Fh
The modified code after disassembly looked like this:
7. Reading the flag
Running the 9F29.tmp program resulted in an error resulting from the inability to connect to the socket:
$ ./9F29.tmp connect: No such file or directory
So you had to force ttt2.exe to create a socket and attach to it before a new program with a random name did. For this purpose:
- I set a breakpoint in the ttt2.exe program right after successfully establishing a socket connection and launched the ttt2.exe program:
- After ttt2.exe stopped at breakpoint, I ran 9F29.tmp:
- Then I continued with the ttt2.exe process
As a result of the actions described above, the opponent started using the player’s mark:
So it was enough to win:
and read the flag:
The flag you are looking for is: