wojcienty.com - Jak zainstalować NFS Underground 2, nie mając od niego pudełka?

Wstęp

Historia stara jak świat. Macie grę, którą kupiliście 20 lat temu. Stary klaser na płyty kurzy się na półce i nie jest ruszany przez ostatnie 10 lat, bo steam ma wszystko czego potrzebujesz. Wtem jednego dnia stwierdzacie: "Ale bym zagrał w starego Need For Speeda". Odkurzasz klaser, znajdujesz płytę, wkładasz do zewnętrznego napędu, bo Twój komputer już dawno nie ma, odpalasz instalator a tam:

Wyciągasz płytę z napędu, patrzysz na nią dokładnie, a tam nic a nic. Nie ma tego kodu nigdzie. Wtem! Myśl przychodzi: "Kurde, był na pudełku". Ale pudełka już z nami nie ma. Przepadło jak beztroska lat dziecięcych. Co więc teraz? Mamy dwie opcje. Pierwsza, szukamy w internecie działającego kodu, albo ściągamy jakiś keygen z internetu. Opcja druga jest ryzykowna, bo kto wie co tam się jeszcze robi oprócz tego generowania + kto by chciał słuchać tych muzyczek co się odpalają na 200% mocy głośników, a pierwsza jest dla słabych.

Wybieramy więc opcję trzecią. Znajdziemy ten klucz sami.

Pomysł

Jak to zrobić? Ano, jak wiadomo, każdy kod jest open source, jeżeli jesteśmy odpowiednio zmotywowani. Aplikacja, która nam się odpaliła i żąda od nas kodu, gdy ten kod podajemy, wie czy jest on poprawny czy nie. Więc na naszym komputerze, na naszym procesorze wykonuje się kod, który sprawdza czy kod jest właściwy. Skoro to jest prawda, to znaczy, że my mamy dostęp do tego algorytmu, więc możemy go podejrzeć i zobaczyć jak ten kod działa i co nam potrzeba, żeby się algorytm nad nami zlitował i puścił nasz kod, pozwalając nam zainstalować gierkę, którą chcemy.

Potrzebujemy plików

Napęd jest wolny. Strasznie wolny. Więc najfajniej byłoby, żeby zgrać sobie pliczki na dysk, żeby nam napęd nie buczał. Kopiujemy je na dysk. Ukazuje nam się lista plików:

Mamy dwie opcje.

AutoRun.exe

oraz

setup.exe

. Oba mają ten sam efekt, czyli przenoszą nas do meny wyboru języka. Wybieramy więc jakikolwiek, przechodzimy dalej. Pojawia się opcja zrobienia różnych rzeczy, wybieramy instalację i bum. Pojawia się nam ekran kodu. Jesteśmy w dobrym miejscu.

Jaki to proces?

Żeby zobaczyć co się dzieje, musimy sobie programik zdebugować, żeby zobaczyć co robi i dokąd nas będzie nosił, żeby znaleźć kod algorytmu, który nas interesuje. Odpalamy więc debugger, w naszym przypadku x64dbg, ale zagrałby dowolny. Ten jest po prostu mój ulubiony na ten czas. Aplikacja okazuje się być 32bitowa, więc trzeba odpalić odpowiedni wariant debuggera pod 32 bity właśnie. Podpinamy się, odpalamy i...

Co jest? Aplikacja pokazuje nam normalnie okienko, ale debugger pokazuje, że nie działa? Powód może być tylko jeden. Odpaliła inną, a sama się zamknęła. Czyli to pewnie launcher, żeby poodpalać całą resztę procesu. Upewnijmy się w process explorerze, czy aby na pewno:

A więc widać, że na pewno. Skoro tak robi, to zamiast debugować na pałę instrukcje, przeklikajmy się przez proces aż do sprawdzenia klucza, by upewnić się, co tak naprawdę będziemy musieli debugować, żeby czasu nie tracić:

Aha! A więc tak się bawimy. No to teraz wiemy co dokładnie trzeba znaleźć i nad czym się pastwić. Widzimy, że proces ma tylko w command linie parametr języka, więc nie musimy się "potencjalnie" przejmować tym, że ma coś wstrzyknięte. Szukamy więc tego programu i pastwimy się już nad nim, bez zbędnych nad i podprocesów.

Od czego zacząć szukanie?

Wpisuję losowy kod. Niech to będą same litery 'a', przy okazji dostrzegając, że każda mała litera zamieniana jest przez program na wielką. Drobna wskazówka, ale jeżeli chcielibyśmy szukać bruteforcem, to nam się dziedzina odrobinę zmniejsza. Klikając jeszcze jak ciele zauważyłem, że znaki typu: -, +, _, też działają. Brute force więc może się okazać niefajny, ale z FIFY pamiętam, że kody były zazwyczaj literkowo-cyferkowe, więc w razie czego odrzucimy te znaki na testy. Wracając... Wpisujemy same "A" i...:

Mamy teraz dwie informacje. Pierwsza, kod samych A nie działa oraz fakt, że gdy kod źle wpiszemy, pokazuje nam systemowego MessageBoxa. Skoro pokazuje nam messageboxa, to znaczy, że wykonuje systemowy call do

int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);

, gdy sprawdzenie się nie powiedzie, więc tam się zatrzymamy debuggerem, by po call stacku dostać się do źródła. Debugger jednak pokaże nam tylko assembly, a ja bym chciał coś więcej zobaczyć, więc odpalimy sobie ten program w Ghidrze, żeby lepiej było widać co program robi, a debuggerem będziemy sobie go wykonywać. Tworzymy więc nowy projekt w ghidrze i do roboty.

Ghidra na ratunek

Ustawiamy breakpoint na MessageBoxie, odpalamy program przez debugger i badamy call stack:

Oho. Widzimy na stosie nasze literki (A w hex to

0x41

), więc jesteśmy niedaleko. Na stosie widzimy parametry oraz powrotne adresy. Debugger pokazuje, nam ułatwiając, które adresy są w kodzie, więc widzimy skąd przychodzimy po ten message box. Widzimy, że drugi pokazuje nam na jakieś dane, więc to na pewno nie jest kod, ale pierwszy już nie. Kopiujemy adres, wskakujemy tam w ghidrze i patrzymy co się dzieje:

Od razu rzucają się w oczy trzy rzeczy. Pierwsza, to fakt, że tam jest sobie

_sprintf

, który ma pięć

%s

i parametry, co są koło siebie na stosie co

bajty. Wygląda jak nasze wejście, które z resztą widzieliśmy na stosie już wcześniej. Druga sprawa, że jest jakaś zmienna, która ewidentnie jak jest większa niż dwa, to wywołuje

CDialog::EndDialog()

, oraz jak wynik jakiejś tajemniczej funkcji jest prawdą, to też. Z dokumentacji wiemy, że CDialog::EndDialog() zamyka okienko, więc jeżeli wynik tajemniczej funkcji, zamyka okienko, oraz jeżeli jakaś zmienna ma więcej niż

to też się zamyka to... Z testów organoleptycznych dostrzegamy, że jak się wpisze kod źle więcej niż trzy razy, to się nam wyświetla wiadomość, że zły kod i nara, i okienko się zamyka. W kodzie widać, że przed tym zamknięciem dzieje się coś jeszcze, ale to jeszcze, jak się tam w ghidrze wklikamy to zauważymy, że te dwie funkcje zapisują coś do rejestru, oraz wyświetlają MessageBoxa z parameterem

0x10

MB_ICONHAND

, czyli ikonka z krzyżykiem. Jak wpiszemy źle kod to nam pokaże błąd z czerwonym krzyżykiem. Więc jesteśmy zasadniczo w domu. Wnioski:

- zmienna

DAT_0042f648

to ewidentnie licznik błędów

FUN_004182bc

- to wrapper na

MessageBoxA()

FUN_00404cb0

- miesza coś w rejestrze

FUN_004055c0

- też, ale tylko jak tajemnicza funkcja zwróci prawdę

FUN_00405cb0

- to tajemnicza funkcja, która coś sprawdza

Śmiałym założeniem jest, że funkcja

FUN_00405cb0

sprawdza nam, czy mamy poprawny kod. Wjedźmy tam w ghidrze:

Jakiś

thiscall

, na razie nieisotne jaki, bo widzimy, że on robi tylko proxy dla innego wywołania. Wskoczmy więc do

FUN_00405bf0

Wygląda jak coś, co coś liczy. Mamy podejrzanego. Zatrzymajmy się tam w debuggerze i zobaczmy co jest na stosie. Funkcja ma 2 parametry, jest 32bitowym standard callem, co oznacza, że parametry będą jako pierwsze 2 na stosie:

Czyli pierwszy parametr to kod który podaliśmy, a drugi to jakaś tajemnicza liczba. W kodzie widzimy, że ta tajemnicza liczba, jest użyta w funkcji, więc dużo od niej zależy, trzeba więc wziąć ją pod uwagę.

Krótka analiza tej funkcji, która się rzuca na pierwszy rzut oka:

- Zmienna

bVar3

jest zupełnie bezużyteczna. Ostatnia linia, jak sobie sprawdzimy, kiedy ten

return

daje nam

true

, wychodzi na to, że nigdy. Jaki

bVar3

by nie był, to wyrażenie jest fałszem. Więc skoro kod tam dojdzie, znaczy, że nasz kod jest niepoprawny.

- Zmienna

bVar1

wyrzuca nas z pętli, a więc przekierowuje do returna, który zawsze jest fałszem, jeżeli jest różna od tego na co wskazuje

pbVar2

bVar1

jest brana z bufora

param_1

, a więc z naszego kodu. a

pbVar2

jest wskaźnikiem na lokalny bufor

local_20

, więc nasz kod, musi być dokładnie taki sam jak bufor

local_20

local_20

jest wrzucony do drugiej funkcji i ona coś z nim robi.

- jeżeli

bVar1

jest 0, czyli defacto jeżeli kod się skończy, to funkcja zwraca

true

, czyli jak pętla dojdzie do momentu, w którym string się skończy, to znaczy, że nie wywaliła się wcześniej, to znaczy że kod jest ok

Wniosek: Musimy zobaczyć co jest w

local_20

, bo kod oczekuje, że nasz kod będzie dokładnie taki, jak ten. Więc jeżeli wykopiemy to co jest w tym buforze, to mamy nasz kod.

Poor mans keygen

Weźmy debugger i się zatrzymajmy na początku pętli, coby zobaczyć, co nam z tym buforem zrobi funkcja

FUN_00405a80

Debugger sam nam pokazuje co jest pod adresem w

esi

, czyli tam gdzie tymczasowo mamy wskaźnik do

local_20

. Mamy tam wpisany kod, jaki program chce, żeby się utworzył. Wpiszmy ten kod do programu:

No i działa. Teraz możemy generować klucz dowolną ilość razy, zatrzymując się debuggerem w tym dokładnie miejscu, wpisując dowolny kod i sprawdzając, czego program się spodziewał, że dostanie. Brać to czego się spodziewa i po robocie. Ale gdzie tu zabawa? Sprawdźmy czy da się to zrobić w taki sposób, żeby móc to zrobić łatwiej, bez tych wszystkich debuggerów.

Robota właściwa

Biorąc pod uwagę fakt, że interesuje nas tylko bufor

local_20

, jedyna funkcja którą musimy zrozumieć i odtworzyć, to

FUN_00405bf0

. Jak ją możemy odtworzyć? Np. na pałę skopiować z ghidry do pliku i próbować go kompilować, poprawiając i doprowadzić do sytuacji, w której się skompiluje i zacznie działać. No to do dzieła. Kopiujemy wszystko co ma

FUN_00405bf0

oraz wszystko czego mu brakuje. Szybko orientujemy się, że brakuje nam 3 rzeczy:

DAT_0042fab8

DAT_0042dcd8

DAT_0042dcd8

. No to skok w ghidrze do pierwszego:

Same zerka. Czyli albo to rzeczywiście same zera, albo w trakcie wykonania programu się generują. Wróćmy sobie debuggerem do miejsca tam gdzie ostatnio i zobaczmy, czy te dane rzeczywiście się wygenerowały:

No i rzeczywiście się wygenerowały. Trzeba teraz zobaczyć ile ich jest i je sobie skopiować, zamienić na

char[]

i wrzucić do naszego kodu. A więc ile? Z tego fragmentu, gdzie tam pamięć jest rzeczywiście używana:

A więc z

*(uint *)(&DAT_0042fab8 + ((local_40[iVar8] ^ param_3) & 0xff) * 4);

widać że maksymalny offset do którego sięgamy od adresu tej pamięci jest zawsze andowany z

0xff

. Czyli ta tablica ma maksymalnie 256 elementów, które są dla nas wartościowe. Dodatkowo, jako że ten offset jest mnożony razy 4 później, to znaczy że tych elementów jest ostatecznie 1024. To jest później rzucane na

uint*

, więc efektywnie jest to tablica jakichś uintów. Ale nas to nie obchodzi na tym etapie. Nam wystarczą bajty, bez większej analizy. Wracamy więc do debuggera, kopiujemy z dumpa 1024 bajty i konstruujemy z tego tablicę żeby nam się ładnie skompilowała. Teraz wracamy do

DAT_0042dcd8

. Hyc do ghidry:

Ładnie mamy tabliczkę i ją sobie całkowicie skopiujmy też do kodu, już bez kombinowania. Z trzecią robimy dokładnie to samo. Znalazłszy te tablicy, dostrzegamy że funkcja

FUN_004059d0

ma jeszcze pare zmiennych z danych, które trzeba wyekstrahować. Robimy to dokładnie tak samo jak poprzednio, bo okazuje się że to są pojedyncze bajty. Więc pracowicie wyciągamy wszystkie te dane w ghidrze. Z bardziej nieoczywistych problemów, których nie da się w prosty sposób zamienić z ghidrakodu do kompilowalnego kodu, możemy się zatrzymać jeszcze na tym (z funkcji

FUN_00405a80

Jak się temu przyjrzymy, to ten kod tak naprawdę w pierwszym kroku dodaje jeden do tego adresu i zapisuje go pod inną zmienną. Potem inkrementuje ten adres. Potem sprawdza co się kryje pod tym wskaźnikiem i jeżeli tam jest zero to kończy. W ghidrakodzie tego nie widać, ale jak wskoczymy do assembly, to zobaczymy że:

Widzimy więc, że on zbiera sobie adres

local_40

edi

, a potem do dekrementuje. Więc ghidra nie jest w stanie strybić za bardzo co to jest, więc wrzuca jakiś adres, który uznaje za właściwy. A tak naprawdę, to jest po prostu

local_40 - 1

, i jako że pętla od razu inkrementuje ten adres, to znaczy, że on korzysta sobie po prostu z

local_40

. Więc to dziwne przypisanie należy zamienić na

pbVar6 = &local_40[-1];

. W drugiej instancji tego dziwacznego adresu mamy dokładnie to samo.

Z kolejnych nieoczywistych rzeczy, jeżeli się przyjrzymy temu fragmentowi:

Zobaczymy, że bufor jaki jest tworzony na stosie ma

bajtów. Później do jakiejś niezdefiniowanej zmiennej zapisuje się zero. Jeżeli jednak przyjrzymy się funkcji

FUN_004059d0

, zobaczymy, że bufor tam przekazany jako parametr (adres jako

int

, ale do tego wrócimy), robi przypisanie aż

0x14

, czyli

bajtów za bazowym adresem. Widać to w ostatniej linii:

Czyli, żeby program się nie posypał, ten bufor musi mieć przynajmniej

bajtów. Skąd więc to

? Ghidra przyjęła, jako że z jakiegoś dziwnego powodu, funkcja zapisuje sobie za

0x2d

, czyli

bajtów za początek stosu,

, to znaczy, że musi to być jakaś zmienna, ale nie była w stanie określić jej rozmiaru. My wiemy jednak, że bufor jaki wchodzi do funkcji musi mieć przynajmniej

. Więc ten poprzedni bufor ma przynajmniej

bajtów. Skąd ten pomysł, można jeszcze wywnioskować z assembly:

0x2d

wziąłem sobie z ghidry, bo tak się rozkodowuje

local_33

offset. Widzimy, że na stosie na offsecie

0x18

znajduje się

local_40

, a na

0x3c

local_20

. Więc pomiędzy nimi jest

bajtów. Jak dodamy do tego ten pomiędzy nimi

PUSH EAX

to mamy

bonusowe, więc realnie pomiędzy nimi są

bajty. Więc widzimy, że

local_20

ma zarezerwowane dla siebie

bajty tak naprawdę. Start tej zmiennej na stosie to

0x18

, a przypisanie zera wjeżdża na offset

0x2d

, więc

0x18

+ dwa wciśnięte międzyczasie na stos rejestry, czyli

, to

0x20

, no wiec żeby osiągnąć

0x2d

to trzeba dodać

. Więc to przypisanie jest na offset

zmiennej

local_40

, czyli de facto

local_40[13] = 0

Ostatnia rzecz na którą warto zwrócić uwagę, to że ghidra pokazuje nam, że

FUN_00405a80

FUN_00405780

FUN_004059d0

, przyjmują za pierwszy argument

int

, mimo, że z kodu wynika, że przyjmuje ona bufory ze stosu, które są

char*

, więc bezpiecznie jest założyć i w tym przypadku można też zweryfikować, że ghidra po prostu po rozmiarze sobie sklasyfikowała tę zmienną i wstawiła sobie inta. Można to szybko poprawić i po robocie.

Mając to wszystko w głowie, można ten kod skompilować, i tak oto udaje nam się skonstruować full ass keygen, który działa. A oto dowód:

Podsumowanie

Tak jak powiedziałem. Każdy kod jest open source, jeżeli jesteś odpowiednio zmotywowany. Dzięki temu podejściu udało nam się uratować jedną grę od zapomnienia, bo mimo, iż nie da się jej kupić, można ją na spokojnie zainstalować. Więc pliki nie przepadną. Na cracka jeszcze przyjdzie pora. Dziękuję za uwagę i do zobaczenia w następnych artykułach.

P.S. Kody zablurowałem żeby nie mieć problemów z prawem. Przepis natomiast jest tak oczywisty, że wydaje mi się nie będzie potrzebna żadna oczywista pomoc. Jeżeli uzyskam od mądrego człowieka informację, że można już prawnie coś takiego ujawnić, to wrzucę tutaj gotowy kod do generowania tych kluczy lub link do repo na githubie, na którym go udostępnię.

Jak zainstalować NFS Underground 2, nie mając od niego pudełka?