Witam,
Panuje powszechna opinia, że .NET jest łatwy do dekompilacji i złamania.
Zatem stworzyłem CrackMe w C#.NET. Zawiera ono takie same zabezpieczenia jak mój program, który tworzę.
Chciałbym, aby społeczność przetestowała te zabezpieczenia.
CrackMe w załączniku. Cel to znaleźć prawidłowe hasło.
Pozwolę sobie zawołać ludzi, którzy znają się na RE:
@Bartosz Wójcik @Gynvael Coldwind @Rev
Podejmiecie wyzwanie?
A sprawdziłeś najpierw czy ILSpy albo Reflector tego od razu nie rozwalą? ;)
edit: a, widzę że popakowane jakimś automatem. To mogłeś od razu napisać że chcesz przetestować jak ten packer się sprawuje a nie ze to jakieś "twoje zabezpieczenia".
Yaaay crackme ;)
Raz w życiu coś z .NET robiłem tbh, ale i tak miałem przetestować to co tam w PIWie mamy, więc czemu nie :)
(ale mam jeszcze jedno crackme do dokończenia, więc jak je zrobię, to się za to wezmę)
Całkiem fajne crackme, chociaż poza spakowaniem go ConfuseremEx to w sumie jest banalne. Nie postarałeś się Bartek :P.
;]
(writeup zrobię później, na razie dam innym powalczyć)
Challange accepted ;)
Poprawne hasło to "AUIFYfasn8afns87afn87afsn7af"
Hasło sprawdzane jest w 1 funkcji:
C#
//
// funkcja odpalana po kliknięciu
//
// GForm0
// Token: 0x0600005E RID: 94 RVA: 0x000087EC File Offset: 0x000069EC
private void button_0_Click(object sender, EventArgs e)
{
if (GForm0.smethod_1(GForm0.smethod_0(this.textBox_0), <Module>.smethod_36<string>(3210498722u)))
{
while (true)
...
//
// funkcja sprawdzająca poprawność wprowadzonego hasła
//
// Token: 0x06000062 RID: 98 RVA: 0x00008D2C File Offset: 0x00006F2C
static bool smethod_1(string string_0, string string_1)
{
return string_0 == string_1;
}
Mimo, że codeflow nie jest naprawiony (switch/while), wystarczy sobie prześledzić to w dnSpy po rozpakowaniu, zastawić breakpointa na smethod_1 i z pamięci zrzucić poprawne hasło.
Jako ciekawostka, moje rozwiązanie było zupełnie inne niż rozwiązanie @Bartosz Wójcik.
(Trochę przeskoczę kilka problemów bo nie było aż tak prosto do celu, ale żeby nie zanudzać & nie pisać za dużo :P).
Spróbowałem zdekompilować CrackMe.exe, zobaczyłem że wszystko tam brzydkie bardzo i nawet nie próbowałem analizować.
Uruchomiłem program CrackMe.exe
Zaatachowałem się do programu za pomocą IDA Pro (deasembler/debugger aplikacji natywnych).
Kiedy wpiszemy złe hasło pojawia się windowsowy natywny messagebox - więc dałem breakpoint na MessageBoxW w user32.dll
Wpisałem złe hasło, poczekałem na breakpoint i popatrzyłem na stack trace:
Znalazłem na ramce stosu odpowiednią funkcję (hard part) - jako że ramka stosu była uszkodzona trochę i akurat tej jednej funkcji której szukałem na niej nie było, dałem breakpointy na wszystkich funkcjach pomiędzy MessageBoxW (na pewno za wysoko) a debug064 (na pewno za nisko() i patrzyłem po kolei co się wywołuje
Znalazłem funkcję która zaczynała się tak:
v2 = (*(int (**)(void))(*this[81] + 356))();
v3 = ((int (__fastcall *)(signed int, void *))unk_3C72A8)(-1084468574, &unk_1E7AC4);
if ( ((int (__fastcall *)(int, int))unk_6F421E60)(v2, v3) ) {
...
} else {
...
}
Co domyśliłem się że w oryginale wyglądało jakoś tak:
textbox_string = (*(int (**)(void))(*this[81] + 356))();
password = ((int (__fastcall *)(unsigned int, void *))decrypt_string)(0xBF5C52A2, &unk_307AC4);
if ( ((int (__fastcall *)(int, int))str_equals)(textbox_string, password) )
Teraz wystarczył breakpoint w momencie wywołania if() i odzyskałem hasło w plaintexcie.
Może to brzmiec jak overkill (używanie debuggera natywnego do analizy aplikacji .netowej), ale było zaskakująco przyjemne (w sumie JITowany kod niewiele różnił się od typowego kompilowanego) - jedynym problem był brak symboli (ale to standard tez przy analizie malware), przez co trzeba by się było trochę domyślać jak wyglądają struktury w środku.
Shalomfasadin