No to może dzisiaj wejdziemy na temat reverse craftingu i metod zabezpieczania gotowych plików wykonywalnych. No niestety żyją asemblerowcy i potrafią odklepać z soft'u z maszynowego kodu i odczytać/modyfikować zapisane tam klucze/wartości
Ktoś zabezpiecza swój soft? Jakimi metodami?
/Dodam ze brakuje mi 2 tygodni do glebszego wejscia w dyskusje.
Ale dlaczego chcesz za wszelką cenę ukrywać jakieś klucze/wartości?
Security through obscurity to zła droga.
Azarien napisał(a)
Ale dlaczego chcesz za wszelką cenę ukrywać jakieś klucze/wartości?
Security through obscurity to zła droga.
Kolega oczekiwał odpowiedzi na zadane pytanie, a nie pytania i to dosyć głupiego. Może jest mu to do czegoś potrzebne, więc szuka o tym informacji. Takie posty jak Twoje powinny być usuwane bo nic do tematu nie wnoszą. Żenada.
@Azarien
zeby przejsc z demo do full wersja gdzies trzeba wpisac klucz nie? powiedzmy ze moj soft matylko jeden klucz ktory odblokuje wersje PRO/FULL w ktoryms momencie musze go wpisac, taki crakz0r wezmie sobie znajdzie ten moment wpisze byle shit do srodka znajdzie wylapie odmowe funkcji czyli ja musi zablokowac albo podrzucic swoja ktora przesle do kolejnego momentu programu prawdę.
mozna z poziomu c++ mieszajac z asemblerem pulapki na RC np. ktore oszukuja dane albo ukrywaja tworzac wielopoziomowe skoki ktore nie pozwalaja odnalezc klucza, a taka sztuczna prawda(funkcja crakz0ra) będzie błądziła. Założmy że dla programu
funkcja
(int) bool pass_key() zwraca true(wlasnie o to chodzi nie moge tego pojac moze dlatego ze nie znam mozliwosci szablonow) dla prawdziwego klucza ale na prawde przesyla powiedzmy liczbe 23(int) ktora leci do deszyfrowania, wysyla odpowiednie sygnaly do reszty modulow jako odblokowane...
ta pulapka polegalaby na tym ze crakzor widzi zwrot bool a program czeka na prawde na 23 ktora wysle odpowiedni kod do reszty
hmm no mniej wiecej tak to widze ;D
Ktoś się zna na tym? ^^
Hiro napisał(a)
(int) bool pass_key() zwraca true(wlasnie o to chodzi nie moge tego pojac moze dlatego ze nie znam mozliwosci szablonow) dla prawdziwego klucza ale na prawde przesyla powiedzmy liczbe 23(int) ktora leci do deszyfrowania, wysyla odpowiednie sygnaly do reszty modulow jako odblokowane...
ta pulapka polegalaby na tym ze crakzor widzi zwrot bool a program czeka na prawde na 23 ktora wysle odpowiedni kod do reszty
hmm no mniej wiecej tak to widze ;DKtoś się zna na tym? ^^
Cracker to nie komorowski, jak zobaczy cmp eax, 23 to raczej nie będzie boola szukał...
no właśnie musisz znać assemblera i wiedzieć mniej więcej jak to będzie przełożone na kod niskiego poziomu. To co jest sprytnie ukryte w kodzie, może być bardzo dobrze widoczne w asm (jak wielki migający napis "tutaj jestem")
Użyj RSA, a klucz do odszyfrowania to jest klucz dla jakichś tam blubrów i sprawdzić hash odszyfrowanego pliku. Jeśli się zgadza z wartością w programie to ok. Jak nie to do diabła.
Bo mnisi widzą wszystko, nawet co nie widoczne ;]
Komorowski nie jest mnichem? ale ma swoja gwardie.
a czy wiecie cos o maszynkach w programie ktore czaja ze ktos dissaembluje program i ukrywaja jego kod?
Hiro napisał(a)
Bo mnisi widzą wszystko, nawet co nie widoczne ;]
Komorowski nie jest mnichem? ale ma swoja gwardie.a czy wiecie cos o maszynkach w programie ktore czaja ze ktos dissaembluje program i ukrywaja jego kod?
Nie trzeba uruchamiać programu żeby go przeanalizować.
Dobra to inaczej - zakladam mechanizm ktory sprawdza zgodnosc calosci kodu, czyli mam jeden mechanizm na calosc.
ukryje go - tak ze nie bedziesz widzial o tym ale on sie odpali w ktoryms momencie programu(no na pewno nie na poczatku)/bedzie sie odpalal co jakis czas(no ale prawdopodobnie wychwycisz go jak tylko wywali komunikat typu : nielegalna operacja programu - no chyba ze od razu taki mechanizm usunie program caly xD smieszne rozwiazanie ale dla bezpieczenstwa ok)
teraz pozostaje go ukryc. kurde musza byc jakies techniki :D crakerzy moze stawiaja pulapki ale jak widza pulapke ktora jest pulapka na nich to nic nie zrobia :D
ej dobra moze ta rozmowa jest troche abstrakcyjna ale moze powstanie dzieki niej cos bardzo pozytecznego - dla kazdego przyszlego developera.
Emulatora, maszyny wirtualnej czy hardware breakpointa to raczej nie obejdziesz... Zresztą tak jak mówiłem - program można przeanalizować nie uruchamiając go. Nawet jeśli sprawdzałbyś jakieś sumy kontrolne, czy kod nie był patchowany, to wystarczy podmienić te sumy albo zależnie od implementacji postawić dwa NOPy i program będzie myślał, że jest okej...
dobra a powiedzmy ze taki przyklad starForce daliscie wyzej.
mam play.exe do gry ktory odpala w ktoryms momencie i sprawdza mi zgodnosc - to juz bylo nie.
ale mechanizm daje w jakims innym pliku exe uruchamianym w tle jeszcze lepiej niewidocznym dla usera.
mechanizm ustawia flage, niech bedzie ze mechanizm wlacza sie przy wylaczeniu programu i wlaczeniu programu.
przy wylaczeniu sprawdza zgodnosc i ustawia flage a przy wlaczeniu sprawdza flage.
zmieniasz moj kod i moj zewnetrzny mechanizm to wykrywa ustawia flage i wlacza soft jest ok myslisz ze ci sie udalo.
ale to twoja ostatnia chwila radosci bo za drugim razem wlaczysz i flaga bedzie ustawiona to na twoim dysku zostanie pusta przestrzen po programie.
no to teraz moj glowny plik nie ma nic wspolnego z mechanizmem bezpieczenstwa, soft sobie smiga normalnie a mechanizm czuwa. Kwestia ukrycia mechanizmu w otwartych procesach.
Widzisz moment w ktorym odpala sie zewnetrzny mechanizm?
sry pomieszalem dwie metody:
-jedna w glownym pliku na ktorym oczywiscie wykryjesz przerwania wlaczajace mechanizm
-a druga metoda to uruchomic mechanizm rownolegle z odpaleniem glownego pliku, ale raczej systemowe procesy wykryjesz, a na kernel nie ma opcji wjechac. Chyba ze system pozwolilby mi stworzyc kernel programu, ukryty z poziomu systemu i chroniony z poziomu kernela systemu dzieki czemu monitorujac procesy systemu nie widzisz mojego wirtualnego systemu softu.
czy to możliwe?
Widzisz moment w ktorym odpala sie zewnetrzny mechanizm?
Wystarczy wykryć call do WinAPI i zrobić jakiś injector do usługi pilnującej, ewentualnie po prostu podmienić mu w pamięci sumy kontrolne. Kwestia tego gdzie jest ta twoja "flaga" zapisana też jest prosta do ustalenia. Procmon i widzisz wszystkie odwołania do plików/kluczy rejestru/etc. Nawet zmiana w overlayu albo markerze właściwego pliku .exe jest do wykrycia. Już nie mówię o tym, że jak zaczniesz grzebać i próbować ukryć proces to się może AV oburzyć.
moze ta rozmowa jest troche abstrakcyjna ale moze powstanie dzieki niej cos bardzo pozytecznego - dla kazdego przyszlego developera.
Powiedzmy sobie szczerze: jesteś początkującym w tej dziedzinie. Istnieje ogromny zasób ogólnodostępnej wiedzy działu reverse-engineering/cracking, masz marne szanse na wymyślenie czegoś co faktycznie będzie trudne do złamania, szczególnie jak wyłącznie teoretyzujesz.
No dobra Monk moze jestes mastah ale wroc do momentu gdzie byles laikiem - z teorii do praktyki, wiedza nie zawsze plynie z ksiazek ale np. for jak to. Dla mnie wypas, jest kilka osob które na poziomie pogają.
Ale zabierając się za programowanie trzeba już sobie na początku zadać pytanie czy zabezpieczać swoje programy i jakimi metodamy
(może jakiś admin doda ankiete: "Czy zabezpieczasz swoje programy?" ;)
ja wymiękam koniec mojej teorii
ide czytać kolejnego booka i chlonąć C++
Monk szacun ;]
Azarien jest za Open Sourcem?
Winerfresh podal szyfr RSA
Sarrus jest tu też ^^
a reszta? Jest jakis mastah ktory zna metode ktorej Monk nie zniszczy?
Hiro napisał(a)
Jest jakis mastah ktory zna metode ktorej Monk nie zniszczy?
Ten temat to jest pytanie typu "jaka blokada na rower aby nikt go nie ukradł", istnieją tylko dwie bardzo dobre odpowiedzi, "nie spuszczać go z oka" lub "nie kupować roweru". Analogicznie z zabezpieczeniem programu... pytasz czy ktoś zna metody to odpowiadam: "nie pisać w ogóle" lub "nie udostępniać nikomu" :) prędzej czy później każde zabezpieczenie zostanie złamane.
pozdrawiam
To zostawmy otwartą furtkę niech biorą co chcą :)
Monk a co powiesz na wirtualny system ? i na nim odpalenie softu? wyhaczysz na nim calle?
Jak napiszesz taki system wraz z pełną obsługą PE COFF Windowsa i własnym kernelem to zadzwonią do ciebie z Googla i Microsoftu...
Jeśli chodzi o zwykłą maszynę wirtualną to fakt, bywają z tym problemy. Tylko do tego potrzeba deczko doświadczenia...