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ę)
Podejmę się wyzwania! (Chociaż najwcześniej dopiero jak wrócę do domu).
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:
//
// 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.