Writeup: FlareOn 2020: 008 - Aardvark

1. TLDR

2. Dane wejściowe

Plik z zadaniem znajduje się tutaj. Hasło: flare.

Przedmiot zadania stanowi plik ttt2.exe.

3. Inspekcja pliku ttt2.exe

Zweryfikowałem plik narzędziem file:

$ file ttt2.exe                                         
ttt2.exe: PE32+ executable (GUI) x86-64, for MS Windows

Przeanalizowałem plik pod względem występujących ciągów znaków. Oprócz nazw funkcji wskazujących na wykorzystanie WinAPI, pojawił się ciąg świadczący o konieczności wykorzystania Windows Subsystem for Linux:

$ strings ttt2.exe
...
Default distribution must be WSL 1
...

Uruchomienie aplikacji poskutkowało błędem:

Po zainstalowaniu WSL oraz Ubuntu 20.04 LTS próba uruchomienia programu powiodła się:

Plik ttt2.exe jest więc grą w kółko i krzyżyk.

4. Analiza ttt2.exe

Przegląd importowanych funkcji pozwolił ujawnić, że aplikacja dosyć często korzysta z Windows Sockets 2.0:

Postanowiłem jeszcze przeanalizować uruchomiony proces, wykorzystując do tego pakiet narzędzi Sysinternals Suite. Przyglądając się procesowi ttt2.exe, zauważyłem istnienie innego procesu 9F29.tmp.

Kiedy podejrzałem jego właściwości, nie zobaczyłem żadnych informacji o istniejącym pliku wykonywalnym:

Podejrzałem właściwości procesu w narzędziu Process Hacker:

W ten sposób została ujawniona ścieżka do pliku wykonywalnego 9F29.tmp. Testując dalej aplikację zauważyłem, że przy każdym uruchomieniu ttt2.exe w katalogu %TEMP% zostaje utworzony nowy plik o losowej nazwie zakończonej .tmp. Plik 9F29.tmp był niewątpliwie związany z aplikacją ttt2.exe i nie był to na pewno przypadkowy proces pochodzący z innej aplikacji.

Dygresja: Warto zwrócić uwagę na fakt, że Proces Explorer z Sysinternals oraz Process Hacker pokazują różne wyniki. Nigdy nie warto polegać tylko na jednym narzędziu. “Wrażliwość” programów tego typu pokazałem m.in. tutaj

5. Analiza 9F29.tmp

Zweryfikowałem plik narzędziem file:

$ 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

Plik 9F29.tmp był zatem uruchamiany z wykorzystaniem Windows Subsystem for Linux. Analiza z wykorzystaniem deasemblera ujawniła, że jest to program udający drugiego gracza.

Za generację znaku przeciwnika (litery ‘X’) odpowiadał fragment głównej funkcji programu, który był zlokalizowany tuż przed wywołaniem funkcji _send. Funkcja _send z kolei odpowiadała za komunikację z wykorzystaniem socketu:

Bezpośrednio znak przeciwnika generowała instrukcja

mov byte ptr [rax+rdx], 58h

która w kodzie maszynowym była zapisana jako:

6. Modyfikacja kodu

Należało zatem wykonać modyfikację polegającą na wymuszeniu generacji znaku gracza zamiast znaku przeciwnika.

W tym celu należało zmodyfikować istniejący rozkaz w taki sposób, aby wykonana była instrukcja

mov byte ptr [rax+rdx], 4Fh

Zmodyfikowany kod po deasemblacji wyglądał następująco:

7. Odczytanie flagi

Uruchomienie programu 9F29.tmp skutkowało błędem wynikającym z braku możliwości podłączania się do socketu:

$ ./9F29.tmp
connect: No such file or directory

Należało zatem zmusić program ttt2.exe do utworzenia socketu i dołączyć się do niego zanim zrobi to nowy program z losową nazwą. W tym celu:

1. Postawiłem breakpoint w programie ttt2.exe tuż po udanym nawiązaniu połączenia z socketem i uruchomiłem program ttt2.exe:

2. Po zatrzymaniu się programu ttt2.exe na breakpoincie, uruchomiłem program 9F29.tmp:

$ ./9F29.tmp

3. Następnie kontynuowałem proces ttt2.exe

W efekcie wyżej opisanych czynności, przeciwnik zaczął używać znaku gracza:

Wystarczyło zatem wygrać:

oraz odczytać flagę:

Poszukiwana flaga to:

c1ArF/P2CjiDXQIZ@flare-on.com