Strona:
17

Współpraca i reklama !
 

Kurs crackingu - część 5

CO DALEJ ... ?!?!?! :

Hmmm ... powyżej opisałem jak się można dostać do kodu zabezpieczenia ...
ale co zrobić dalej ??? ... hmmm ... trochę już powinieneś wiedzieć
po przeczytaniu textow wcześniejszych <-) ... eh ... no ale dobra
przeor klasztoru reverserow wam podpowie <-) ... hmmm ... np. w
poprzednich textach opisywałem CrackMEs które używały standardowej
funkcji API GetDlgItemTextA i podawałem ze znajdujemy nasz SERIAL
w pamięci przez sprawdzenie adresu zawartego w argumencie PUSH-a
który natomiast znajdował się przed wywołaniem funkcji GetDlgItemTextA
(oczywiście wiemy ze jako jej argument <-) ) ... jednak nie jest to
metoda która jest zawsze odpowiednia ... argument może być rejestrem
np. EAX przy czym GetDlgItemTextA modyfikuje ten rejestr i już po
wykonaniu procedury GetDlgItemTextA komenda <d eax> NIC nam nie da !
co prawda możemy użyć rejestru stosu ESP do tego celu (np. zobacz
na dołączony WINICE.DAT na makro dotyczące GetDlgItemTextA i
GetWindowTextA i zwróć uwagę ze gdy je uruchomię to S-ice
przerwie na wywołaniu tych funkcji AUTOMATYCZNIE pokazując w oknie danych
NAME/SERIAL - to BARDZO ułatwia życie - lepiej to przeanalizuj !)
Jednak ja nie robię tak jak podałem w poprzednich textach (no ...
kiedyś tak robiłem <-) ) ... ZAWSZE wykonuj komendę :

s ds:0 l ffffffff "twoj_SERIAL"

Komenda ta powoduje przeszukanie określonego obszaru pamięci w
poszukiwaniu twojego SERIALA ... składnia komendy to :
<s> to komenda <ds:0> to adres początkowy (ds to Data Segment ...
czyli rejestr segmentowy danych ... wskazuje na aktualny segment
w pamięci gdzie przechowywane są dane !!!) przeszukiwania pamięci
<l> trzeba dać ale nie ma (?) to celu ... <ffffffff> jest to adres
końcowy przeszukiwania pamięci ... <"twoj_SERIAL"> wiadomo -
string jaki chcesz znaleźć w pamięci ... Okay ... wykonałeś ta komendę
i S-ice znalazł twój SERIAL w pierwszym miejscu - wyświetlił twój SERIAL
w oknie danych !!! ... teraz spisujesz adres pod jakim jest ten SERIAL
w oknie danych (bez segmentu - to (zazwyczaj) nie potrzebne) ... i aby
znaleźć następne miejsce w pamięci z twoim SERIALEM wykonujesz komendę :

s

ta ... bez żadnych argumentów ... S-ice znalazł (lub nie) następne miejsce
występowania ... i znowu spisujesz ... ale musisz wiedzieć ze :
Zazwyczaj tylko kilka (lub jeden albo zero) "najniższych" adresów które
wskazują na miejsce w pamięci z twoim SERIALEM są tymi które nas interesują
i zazwyczaj zaczynają się one od cyfry "0" ... czyli np. adres
01234567 jest ciekawy ... i często ten adres jest jeszcze niższy
np. 00123456 albo 00012345 ... natomiast jeśli S-ice napotka twój SERIAL
w wyższym adresie to on nas NIE interesuje ... tzn. głównie chodzi o DWA
adresy : adres zaczynający się od cyfry "8" np. 80123456 ... wszystkie
adresy zaczynające się od tego "8" określają pamięć EKRANU (video) ... drugi
adres to adres zaczynający się od cyfry "C" np. C0123456 i te adresy określają
pamięć S-ice'a (w końcu S-ice tez musi gdzieś trzymać dane <-) ) ...
Teraz tak ... przypuszczam ze spisałeś wszystkie miejsca w pamięci
zaczynającej się od adresu 0xxxxxxx (zazwyczaj) ... ALE ... prawdopodobnie
wystąpiło raczej tylko jedno takie miejsce (oczywiście jeśli wykonałeś
ta komendę bezpośrednio po przerwaniu S-ice'a na funkcji GetDlgItemTextA -
bo jeśli to zrobiłeś "gleboko" w kodzie programu to może być cały SZEREG
takich miejsc !!!) ... hmmm ... w zasadzie to nie musisz spisywać tych
adresów (adresu) bo od razu możemy zastawić na nich breakpointy ! ...
Chyba wiesz jak to zrobić, prawda ? ... <-) ... no wiesz komenda <bpm>
... tylko teraz jeśli ustawisz breakpoint komenda <bpm> to S-ice
automatycznie zamienia komendę <bpm> na <bpmb> co oznacza (breakpoint
on memory - byte) ze S-ice przerwie na odczycie/zapisie danych pod
adres określony argumentem komendy <bpm> ALE tylko na JEDNYM BAJCIE !!!
... chyba wiesz co to oznacza ? ... <-) ... huh ? znowu nie ? <-) ...
ajajaj ... no dobra niech Ci będzie ... wyjaśnię ... przypuśćmy ze mamy
SERIAL "1234567890" czyli 10-cyfrowy i jest zapisany pod adresem "0009A3FE"
czyli wiadomo ze zajmuje 10 bajtów ... ustawiamy breakpoint na tym adresie

bpm 9a3fe

oczywiście S-ice zamienia to na <BPMB> i pozwalamy programowi się dalej
wykonywać (wychodzimy z S-ice) ... i ... nic ... program nie przerwał ...
hmmm ... dlaczego ? ... przecież musi pobrać dane z tamtego adresu ! ...
musi odczytać nasz SERIAL ! ... Oczywiście ze MUSI ! ... wiec co ?
... hmmm ... program mógł zrobić np. cos takiego : odczytać 5-ty
bajt w naszym SERIAL-u i porównać go z jakąś stałą !!! i na podstawie
TYLKO tego osądzić czy dobry/zły SERIAL !!! ... Chyba się już wiesz
dlaczego S-ice NIE przerwał !? ... no to dobrze ... ale jak temu
zaradzić ??? ... czy musimy ustawiać <bpm> na każdym znaku w SERIAL-u ???
... oczywiście NIE ... S-ice przychodzi z pomocą i łatwo możemy temu
zaradzić ... najpierw gorsze rozwiązanie : możemy zastosować zamiast
komendy <bpm> (bpmb) komendę <bpmw> (word) albo <bpmd> (doubleWord)
chyba nie musze tłumaczyć co to zrobi (odpowiedz się sama nasuwa <-) ) ...
ALE ja nie używam powyższej metody (bo widać oczywiste ograniczenia) ...
Zamiast niej robię cos takiego : używam komendy <bpr> np. :

bpr 9a3fe 9a3fe+a rw

hmmm ... co to oznacza ? ... otóż komenda <bpr> (breakpoint on memory
range) robi to samo co komenda <bpm> z tym ze OKRESLAMY obszar na którym
ten breakpoint ma działać ! ... składnia tej komendy to oczywiście :
<bpr> - komenda, <9a3fe> - początkowy adres, <9a3fe+a> to końcowy adres
<rw> (ReadWrite) to opcja która nakazuje S-ice'owi przerwanie i na
ODCZYCIE danych z danego miejsca w pamięci jak i ZAPISIE do tego miejsca
(jeśli byśmy NIE dali tej opcji - standardowo byłaby tylko opcja <w>) ...
Jeszcze wyjaśnienie dlaczego ten końcowy adres to <9a3fe+a> ? ...
ponieważ jak wiemy adres początku naszego SERIALA w pamięci to "9a3fe"
SERIAL ma 10 znaków ... przy czym to "10" to jest decymalnie natomiast
hexadecymalnie to wiadomo ze "0A" !!! ... czyli jeśli chcemy ustawić
breakpoint na odczycie/zapisie KAŻDEGO bajtu z naszego SERIALA to musimy
podaj jego początkowy i końcowy adres w pamięci !!! ... ufff ... chyba
jasne, nie ? ... <-) ... czyli podsumowując komenda <bpm> możemy ustawić
breakpoint odczytu/zapisu danych TYLKO na JEDNYM bajcie w pamięci (bpmw -
na odczycie słowa (dwóch bajtów) i bpmd - na odczycie podwójnego słowa
(czterech bajtow)) ... natomiast komenda <bpr> na odczycie/zapisie DOWOLNIE
dużego obszaru pamięci !!! ... ech ... jeszcze tego nie widzisz ? ...
jeszcze ostatnia próba zobrazowania tego <-) :

BPM: BPR:
__ __
|31| <----P----> |31| :0009A3FE
-- R |--| :0009A3FF
32 <----O----> |32| :0009A400
33 G |33| :0009A401
34 R |34| :0009A402
35 <----A----> |35| :0009A403
36 M |36| :0009A404
37 | |37| :0009A405
38 | |38| :0009A406
39 | |39| :0009A407
30 <----|----> |30| :0009A408 => (0009A3FE+0A)
--

Rysunek symbolizuje BPMB VS BPR ! <-) ...
Jak zauważyłeś pewnie ciąg "31 32 33 34 35 36 37 38 39 30" to nasz SERIAL
(1234567890) w postaci hexadecymalnej ... i tutaj widać czym różnią się obie
komendy ... miedzy kolumnami BPM i BPR jest nazwa "PROGRAM----" która symbolizuje
program który łamiemy (a cóżby innego <-) ) ... od niego odchodzą strzałki
które symbolizują poszczególne dostępy programu do komórek pamięci zawierających
nasz SERIAL ... i teraz, jeśli dana komórka jest zakreślona to S-ice przerwie
na odczycie/zapisie do niej !!! ... a widzimy ze przy BPM zakreślona jest
TYLKO 1 komórka podczas gdy przy BPR zakreślone SA WSZYSTKIE !!! ...
eh ... Kurd ... nie wiem po co rysowałem ten rysunek, przecież to jest
bardzo proste ... w każdym razie już pewnie rozumiesz jaka jest różnica
pomiędzy komenda <bpm> i <bpr> ... tylko teraz która lepiej stosować ??? ... hmmm
... to zależy ... przy BPM w związku z tym ze S-ice przerwie na odczycie/
zapisie TYLKO jednej komórki możemy kilku rzeczy NIE zauważyć, ale za to
S-ice nie musi przerywać w WIELU miejscach o których wiemy co robią ! ...
Natomiast przy BPR S-ice przerwie na odczycie/zapisie WSZYSTKICH (oczywiście
jeśli tak sobie zażyczy cracker/reverser, bo można określić dowolny "zasięg"
tej komendy !!!) komórek z SERIALA (czy czegokolwiek) i w związku z tym
możemy mięć lepszy wgląd na to co się dzieje wokół nas ! ... np. jeśli widzimy
ze S-ice przerwał 10 (tyle znaków ma nasz SERIAL) razy na jakimś określonym
miejscu kodu to możemy wnioskować ze program "przerobił" każdy znak z naszego
SERIALA i cos z nim zrobił ! ... ale za to, przy BPR możemy się nieźle namęczyć
naciskając F5 tu i tam, ponieważ np. jeśli program stosuje procedurę zamiany
każdego znaku z twojego SRIALA na duża literę to przy BPR S-ice przerwie wewnątrz
procedury zamiany przy zamianie KAŻDEGO znaku ! ... a przy BPM przerwałby tylko raz,
zorientował byś się co robi ta procedura i już S-ice by na niej NIE przerwał
... hmmm ... wiec jaki wybór ? ... hmmm ... ja robię tak : najpierw BPM
jeśli to nie wystarczy do zorientowania się o co biega to robię BPR i to
wydaje mi się jest najlepsze rozwiązanie <-)... ... No i w zasadzie to
jest standardowe podejście do zabezpieczeń typu SERIAL ! ... po tym jak
S-ice przerwie na BPM czy BPR już powinieneś wiedzieć co robić - po prostu
ANALIZOWAĆ ! <-) ... acha ! ... i CZĘSTO podczas śledzenia kodu wykonuj komendę
<s 0 l ffffffff "twoj_SERIAL"> bo możliwe ze nie zauważyłeś a program skopiował
twój SERIAL w jakieś inne miejsce w pamięci !!! ...
END...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

+++++++++++++++++++++++++++++++++++++++++++++++
JAK ZMIENIAĆ NA STALE PLIKI :

Wiadomo ze jeżeli zamienisz jakąś instrukcje w S-ice na inna to to
nie powoduje zmian w pliku programu tylko w pamięci (RAM) ... i jeżeli
na nowo uruchomimy program to wprowadzone przez nas dane NIE istnieją !!!
Dlatego jeśli chcemy zmienić jakąś instrukcje na stale to musimy
dokonać modyfikacji na określonym pliku programu ... !!!
hehe ... prawdopodobnie już wiesz jak to zrobić bo każdy początkujący
cracker/reverser woli znaleźć ten "odpowiedni" skok i zwykle go "przestawić"
z własnym upodobaniem niz. żmudnie odkodowywac proces kodowania SERIALA ...
no może nie reverser <-) ... ale cracker raczej na pewno <-) ... heh ...
Mimo ze z pewnością 80-90% czytelników już wie jak to zrobić to pokaże
tym mniej "ambitnym" <-) żeby nie zalewali mnie tonami poczty jak to
zrobić ... A wiec tak dla przykładu wrócimy jeszcze do CrackMe 1.0 ...
Przyjmuje ze przeczytałeś mój text nr. 2 ... tam jest opisane cale zabezpieczenie
i jeśli czegoś nie rozumiesz to tam przeczytaj <-) ... Do naszego zadania
wystarczy przytoczyć końcowy fragment zabezpieczenia :

58 POP EAX
3BC3 CMP EAX,EBX
7407 JZ 0040124C (x) <---|
E818010000 CALL 00401362 |
EB9A JMP 004011E6 |
E8FC000000 CALL 0040134D <-------|

Wyjasninie tych linijek macie w text #2 ... teraz to co musimy wiedzieć to
ze jeśli skok (x) nastąpi to jesteśmy zarejestrowani natomiast jeśli nie
to jesteśmy nie-zarejestrowani ... proste i logiczne <-) ... heh ...
w tym programie akurat BARDZO łatwo jest odkodowac prawidłowy SERIAL wiec
tutaj nie maja sensu patch-e ... PAMIETAJCIE : PATCHE (czyli zmiany w pliku)
wykonujemy TYLKO w tedy gdy NIE ma INNEGO wyjścia !!! ... w zabezpieczeniach
typu SERIAL robimy to tylko w 1% przypadków !!!, bo w 99% przypadków MOŻEMY
odkodowac SERIAL chociaz mielibyśmy się męczyć parę miesięcy <-) ... jeśli
pójdziesz na łatwiznę i zrobisz zwykłego patcha to NIE jesteś prawdziwym
reverser-em tylko co najwyżej crackerem !!! <-) ... Dobra, wracamy do kodu ...
Pomyśl teraz co możesz zrobić aby program "myślał" ze jest zarejestrowany ??? ...
No, teraz to już wszystko zależy od twojej fantazji ... jest wiele metod złamania
(zpatchowania) tego programu ... musimy jednak zwrócić uwagę na to ze każda instrukcja
ASM zajmuje w pamięci ileś tam BAJTOW ... Jeśli chcemy zastąpić ja jakąś inna to
musi ona mięć DOKŁADNIE TA SAMA ilość bajtów !!! ... natomiast jeśli chcemy zastąpić
ta instrukcje KILKOMA innymi instrukcjami to SUMA ich bajtów MUSI być taka sama
jak ilość bajtów zastępowanej instrukcji np.

3BC3 CMP EAX,EBX (ta instrukcja ma 2 bajty)
=
90 NOP (ta instrukcja ma 1 bajt)
90 NOP (ta instrukcja ma 1 bajt)

Jak widzimy, 2-bajtowa instrukcje CMP EAX,EBX możemy zastąpić dwoma
pojedynczymi instrukcjami 1-bajtowymi !!! inny przykład to np.

E818010000 CALL 00401362
=
90 NOP
90 NOP
90 NOP
90 NOP
90 NOP
=
83E201 AND EDX,01
90 NOP
90 NOP

Chyba juz teraz wszystko jasne ? ... chyba wiadomo ze liczba hexadecymalna
składająca się z dwóch cyfr czyli 00-FF to BAJT ? ... eh ... jeśli nie to ikonicznie
musisz się wziąć za ASM !!! ... Musze tu polecić dla wszystkich znających
English WSPANIAŁY tutorial ASM : "ART OF ASSEMBLY LANGUAGE" ... Nic tylko
przylepić mu etykietę "A MUST READ" <-) !!! ... Okay ... Jeśli DALEJ mi nie
wierzysz ze NIE MOŻNA zmienić jednej instrukcji w programie na inna która ma
wieksza/mniejsza liczbę bajtów to zrób cos takiego (UWAGA ! ... nie ponośże
odpowiedzialności jeśli zrobisz sobie tym krzywdę !!!) : wejdź teraz do
S-ice'a (Ctrl+D) i po prostu wpisz komendę <a> (btw: jest to BARDZO pomocna
komenda - jeśli wie się jak ja używać <-) ) ... powoduje ona zastąpienie
aktualnej instrukcji (tej na której masz pasek w oknie kodu) jakąś inna ...
Po komendzie <a> wpisz dowolna komendę w ASM np. "mov eax,ebx" albo "nop" (sprawdz
czy ma napewno inna ilość bajtów niz. ta która chcesz zastąpić) teraz naciśnij
eter i (Jeszcze raz mowie : NIE ponośże odpowiedzialności !!!) wyjdź z S-ice
(F5) ... Oczywiście Win się totalnie zawiesił !!! ... ale może tez to spowodować
inne rzeczy ... nie wiem jakie ale tak na wszelki wypadek mowie <-) ... No
chyba teraz już mi wierzysz ze NIE można zmieniać instrukcji instrukcja o większej
liczbie bajtów !!!?!!! ... No nic, wracamy do kodu ...
Podaje np. standardowe rozwiązanie problemu (złamanie programu) : możemy skok (x)
czyli dwubajtowa instrukcje "Z 0040124C" zamienić na także dwubajtowa instrukcje
"JNZ 0040124C" co spowoduje ze program zarejestruje się dla jakichkolwiek danych
(Jakikolwiek NAME i SERIAL), no chyba ze podamy te właściwe dane (ale to graniczy
z cudem, żeby trafić właściwą "kombinacje") ... No chyba ze nie jesteś tak przekonany
ze to graniczy z cudem, to możemy zastąpić ten skok czymś takim : "JMP 0040124C" co
tez jest 2-bajtowe !!! ... heh ... możliwości jest naprawdę DUŻO ... moglibyśmy np.
wy-NOP-owac "CALL 00401362" i "JMP..." za nim, czyli zastąpić te dwie instrukcje kilkoma
instrukcjami NOP (zależy ile te dwie instrukcje maja bajtów) ... albo zamiast instrukcji
"CMP EAX,EBX" dać "CMP EAX,EAX" i skok (x) zawsze nastąpi ... możliwości jest naprawdę
DUŻO ! ... Okay ... przypuśćmy ze już wiesz co chcesz zmienić ... ale teraz JAK to
zrobić ??? ... eh ... a wiec tak, potrzebujemy HEXedytora ... obojętnie jakiego ...
Ja używam "Hacker's View" , ale to naprawdę OBOJĘTNE ... Opisze tu jak to zrobić
przy pomocy HIEW-a (potocznie Hacker's View), lecz mniej więcej tak samo to będzie
wyglądało u Ciebie ... No wiec tak, przyjmijmy na przykład ze chcesz zmienić
"JZ 0040124C" na "JMP 0040124C" ... co musimy zrobić ? ... po pierwsze wiadomo ze
w pliku dane zapisane są w postaci bajtów ... aby znaleźć w nim interesującą nas
instrukcje musimy znać jej "OPcode" czyli np. "OPcode" instrukcji "JZ 0040124C" to
7407 (Jeśli w S-ice w twoim "oknie kodu" nie widzisz nic pomiędzy kolumna adresów
a kolumna instrukcji to wykonaj komendę <code on> - wtedy zobaczysz OPcod-y
instrukcji !!!) ... Teraz jeśli znamy już "OPcode" danej instrukcji możemy ja
znaleźć w pliku !!! ... eh ... Teraz tylko nasuwa się pytanie : "a co jeśli w pliku
jest więcej takich instrukcji - z kad możemy wiedzieć która jest ta "ważna" ??? " ...
no właśnie ... w takim razie musimy także spisać OPcod-y instrukcji z "otoczenia" ...
Czyli dla naszego przykładu jakim jest CrackMe 1.0 aby zlokalizować ten "interesujący"
skok spiszemy OPcod-y kilku instrukcji z otoczenia, oto co powinieneś zapisać sobie na
kartce :

58,3B,C3,74,07,E8,18,01,00,00

(Chyba rozpoznajesz w tym ciągu instrukcje z otoczenia i ta "główna" - 7407)
Okay ... to powinno wystarczyć ... Teraz tworzymy kopie zapasowa pliku którego
kod chcemy modyfikować ... chyba wiadomo dlaczego ? <-) ... i jeszcze kopiujemy
ten plik do katalogu z HIEW-em ... w wyniku mamy 3 pliki ! ... Jeden - oryginał ...
dwa - kopia zapasowa ... trzy - do pracy z HIEW-em ... teraz uruchamiamy HIEW-a
albo zwykle (nowsze wersje) i pokazuje nam się "menadżer plików" <-) z którego
szukamy i wybieramy plik który chcemy edytować albo możemy go uruchomić bezpośrednio
z prompt-a DOS-a podając jako argument plik który chcemy edytować, czyli :

hiew crackme.exe

Ukazuje nam się okno które przypomina wbudowany edytor NC/FAR ... hmmm ...
teraz przechodzimy do trybu hexadecymalnego (byliśmy w ASCII) naciskając F4 ...
Aby znaleźć wycinek kodu który szukamy naciskamy F7 ... możemy teraz szukać zarówno
ASCII jak i Hex ... nam zależy na hex-ach wiec przechodzimy do okna przy którym pisze
Hex i wpisujemy to co sobie zapisałeś na kartce ... Naciskamy Enter ... Teraz HIEW
powinien szybko znaleźć to co szukamy ... w oknie z wartościami hexadecymalnymi
na samej górze powinien pojawić się bajt 58 (pierwszy który wpisaliśmy do szukania)
Oczywiście widać wyraźnie nasz ciąg : 58 3B C3 74 07 E8 18 01 00 00 ... Wiemy
ze bajty 74 07 odpowiadają instrukcji "JZ 0040124C" a my ja chcemy zmienić na
"JMP 0040124C" ... heh ... powinniście wiedzieć ze niektóre bajty w instrukcji
odpowiadają za sama instrukcje a inne za jej argumenty ... w instrukcji
"JZ 0040124C" bajt 74 odpowiada za określenie samej instrukcji czyli ze jest
to "skok warunkowy gdy zero" natomiast bajt 07 odpowiada za jej argument
czyli "0040124C" ... my argumentu nie chcemy zmieniać, tylko sama instrukcje !!! ...
wiec bajt 07 zostawimy bez zmian natomiast zajmiemy się bajtem 74 ... hmmm ...
Co mamy z nim zrobić ??? ... Tu musisz wiedzieć ze do określenia instrukcji JMP
śluzy bajt EB ... czyli jeśli chcemy aby instrukcja "JZ..." zmieniła się na "JMP..."
to musimy zmienić pierwszy bajt z jej OPcod-u : 74 na bajt EB !!! ... proste nie ? <-)
... hmmm ... zapytasz skąd masz wiedzieć jaki bajt(y) charakteryzują jaka instrukcje ???
heh ... Musisz sobie skądś załatwić taki wykaz !!! ... (nie pytaj mnie skąd <-) ) ...
A wiec chcemy zmienić bajt 74 na EB ... zaraz go zmienimy ... ale NAJPIERW ! :
A wiec tak ... jesteśmy w HIEW ... znaleźliśmy te instrukcje ... Teraz KONIECZNIE
zrób jeszcze jedno szukanie (F7) aby być PEWNYM ze w kodzie programu nie występuje
więcej miejsc z naszymi instrukcjami ... w tym przypadku nie będzie ... ale co
by było gdyby były ??? ... musielibyśmy jeszcze raz wejść do S-ice'a i spisać
WIĘCEJ bajtów (OPcod-ow) z "okolicy" interesującego nas kodu ... Dobra, wiec
wiemy ze NAPEWNO kod który znaleźliśmy w HIEW odpowiada temu z S-ice ...
aby być jeszcze bardziej pewnym naciśnij F2 - zobaczysz kod ASM - jeśli odpowiada
on temu z S-ice to wszystko OK ... dobra wracamy do trybu HEX naciskając ponownie F2 ...
teraz chcemy zamienić bajt 74 który widzimy w oknie HIEW-a
(no wiesz - ten z ciągu 58 3B ...) na EB ... Aby to zrobić naciskamy F3 i widzimy
ze kursor jest na oknie z wartościami HEXadecymalnymi ... teraz wystarczy tylko
najechać na bajt 74 i wpisać EB !!! (Jeśli jeszcze nie wiesz dlaczego EB - to
przeczytaj KILKA razy powyższy text) ... Jeśli się pomyliłeś albo wpisałeś cos
innego to możesz nacisnąć ESC i wszystko wróci do normy ... natomiast jeśli chcesz
aby zmiany zostały zapisane w pliku to wystarczy nacisnąć F9 (zaraz po wpisaniu EB) !!!
Gdy zmiany już zostały zapisane możemy spokojnie wyjść z HIEW-a ... teraz wystarczy
zastąpić oryginalny plik programu tym który wyszedł po "obróbce" w HIEW-ie <-)
i uruchomić CrackMe ... wchodzimy do Help/Register wpisujemy DOWOLNE dane ... i
... yeah ! ... program zarejestrowany dla dowolnych danych <-D !!!
Mam nadzieje ze wszystko zrozumiałeś ... bo to jedna z podstawowych rzeczy <-) ...
Jeśli nie to KONIECZNIE przeczytaj jeszcze kilka razy powyższy text, aż do skutku <-)
acha ... i oczywiście NAJWAŻNIEJSZY morał to : PRZECZYTAJ "ART OF ASSEMBLY LANGUAGE"
!!! <-) to jest "lektura obowiązkowa" dla każdego szanującego się (przyszłego)
crackera/reversera - i węz sobie dłuższy urlop bo jest tego cos 5 MB w PDF !!!!!
... Czasami się może zdarzyć ze tych OPcod-ow które spisałeś w S-ice ani rusz nie
możesz znaleźć w pliku programu używając HEXedytora !?!?!? ... To prawdopodobnie
znaczy ze albo :
a) Źle spisałeś bajty (sprawdź 3 razy)
b) Szukasz w złym pliku !!! tzn. ze np. procedura sprawdzająca jat w jakimś
zewnętrznym DLL-u albo jakimkolwiek innym pliku !!! (w S-ice gdy jesteś
przy procedurze sprawdzającej sprawdź co pisze w linijce oddzielającej
okno komend od okna kodu - czy to nie przypadkiem nazwa czegoś innego
niz. tego co się spodziewałeś !?!?!)
c) Plik jest albo spakowany albo szyfrowany ... nie to nie znaczy
ze plik jest w ZIP-ie ... <-) ... tzn. ze plik jest tak pakowany ze
jest rozpakowywany dopiero w momencie uruchomienia (rozpkowowywuje się w
PAMIĘCI operacyjnej (RAM)) ... Są takie rożne standardowe sposoby kompresji
np. WWPACK(32) (btw : wymyślony przez Polaka <-) ), PKLite , Shrinker , VBox ...
i wiele innych ... Te może i byłyby trudne do zdekompresowania dla początkujących
ale są gotowe automatyczne programy które to za nas robią, a my jak wiadomo
jesteśmy tacy LENIWI ze zaraz sięgniemy po to co nam choćby trochę ułatwi "prace"
<-) ... Takie narzędzia to UNP (dla 16-bit) i ProcDump (dla 32-bit) ... przy czym
ten drugi jest na tyle konfigurowalny (za pomocą skryptu) ze BARDZO łatwo możemy
go "nauczyć" dekompresowac/dekodowac rożne sposoby kompresji/kodowania !!! Jeśli
programista wymyśli sobie jakiś swój sposób kompresji/kodowania to ZAZWYCZAJ
jest to bardzo prymitywne ... i nawet początkujący sobie z tym poradzi ... a mając
ProcDump-a to nawet dziecko <-) ...
Na koniec wyjaśnię cos jeszcze ... mianowicie możesz sobie zadawać pytanie dlaczego
musimy spisywać te wszystkie bajty z okolicy naszej instrukcji zamiast po prostu
spisać offset danej instrukcji i ja znaleźć w HIEW-ie ... hmmm ... ponieważ te
offsety w S-ice to NIE to samo co offsety w pliku !!! ... te w S-ice to są offsety
uzależnione od W95/98 i pamięci RAM !!! ... a te w pliku to są liczone od zera od
początku pliku do końca pliku (jak zobaczysz są ułożone rosnąco i są uzależnione od
długości pliku !) ... dlatego NIE możemy po prostu spisać offsetu z S-ice i znaleźć go
w pliku w HIEW-ie ... natomiast umożliwia to WDASM który podaje offset instrukcji w
pliku ! ...

heh ... Ok ... to by było na tyle na temat wprowadzania zmian w plikach <-)
+++++++++++++++++++++++++++++++++++++++

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ŁAMANIE POD STARYM DOBRYM DOS-em ... (ech to były czasy <-) ) ...

hmmm ... w zasadzie to nie ma dużo różnic ... cracking (reversing)
to cracking (reversing) ... może taka z większych różnic to PRZERWANIA,
w programach W95/98 NIE zobaczysz ich zbyt wiele ... ale w DOS są
WSZECHOBECNE ! ... Najlepiej zdobądź jakiś spis wszystkich przerwań
... oczywiście najlepszy to słynny "Ralf Brown's interrupt List" ...
i zobacz co robią ... eh ... zresztą przypuszczam ze ludzie to czytający
znają się na komputerach wiec wiedza co to przerwanie i które odpowiada
za co (przynajmniej przypuszczam ze znacie te najpopularniejsze) ...
w zasadzie to jest ta główna różnica - nie ma API ... bo chyba nikt
z was nie próbował GetDlgItemTextA na programie DOS-owym <-)) ...
jest jeszcze szereg innych drobnych ... ale to już sam zobaczysz <-) ...
wiec np. wiecie ze odczyt SERIALA z okna dialogowego może wystąpić
przy pomocy przerwania 21h (chyba najpopularniejsze w DOS-ie) funkcji
AH=0Ah ... oczywiście także może za pomocą innych np. INT 16h albo
czegoś innego (po prostu zapoznaj się z przerwaniami) ... no dobra
ale jak zmusić S-ice'a żeby się pojawił na tym przerwaniu ... hmmm
za pomocą komendy <BpInt> (Breakpoit on interrupt) ... np. :

bpint 21 if ah==a

Musimy tu zastosowac wyrażenie warunkowe gdyż jeśli dalibyśmy samo
<bpint 21> S-ice przerwał by na każdym wywołaniu tego przerwania które
jak wiesz jest stosowane przez programy DOS-owe trochę często <-) ...
Nawiasem mówiąc to to wyrażenie warunkowe można stosować nie tylko
przy komendzie <bpint> ... można je stosować przy WIELU komendach ...
to <bpx> czy <bpm> i innych ... zwróć uwagę ze maja być dwa znaki
'=' !!! ... (notacja C/C++) ... i przy okazji powiem ze w S-ice domyślnym
systemem liczbowym jest hexadecymalny czyli szesnastkowy !!! i jeśli chcesz
jakąś liczbę użyć do czegoś w systemie dziesiętnym to musisz postawić przed
nią znak '+' !!! ... czyli np. jeśli chcemy zobaczyć jaka wartość w hex ma
liczba dziesiętna 21 to stosujemy komendę :

? +21

No ale to tak poza tematem <-) ... Czyli jeśli postawiłeś ten breakpoint
na przerwaniu 21h funkcji 0Ah to zobacz czy to działa ! ... jeśli nie
to sproboj z innym przerwaniem i funkcja (po prostu zapoznaj się z
jak największa liczba przerwań) ... oczywiście ja nie znam wszystkich
dlatego mam pod ręka książkę która musze polecić ! ... Książka ma
tytuł : "ENCYKLOPEDIA INFORMATYKI" napisana przez Stanisława Kruka ...
miedzy innymi ma w sobie wyjaśnienia 1000 terminów informatycznych, wykaz
instrukcji koprocesora 80387 (!), wykaz wszystkich instrukcji ASM
procesorów x86 (!!), wykaz wszystkich przerwań (!!!), i kilka innych rzeczy !
... po prostu musisz ja mięć ... wszystkie informacje co Crackerowi (Reverserowi)
są potrzebne są w niej zawarte (nie wiem dlaczego nie ma tytułu
"ENCYKLOPEDIA CRACKERA") <-) ... paskudna reklama co ? <-) ... no ale nic
... eh ... Nie będę się dalej rozwodził nad DOS-em ... gdyż i tak już
umiera (będziemy tęsknic przyjacielu <~~-( ) ... Pamiętaj o tych przerwaniach
... potem już postępujesz podobnie pamiętając o zasadach zadzacych się w
16-bit (16-bitowe adresy itp.) ... aha ... nie potrzebujesz specjalnie
Debuggera dla DOS gdyż równie dobrze możesz uruchomić program DOS-owy
pod W95/98 ... albo skorzystać z narzędzia które udostępnione jest
wraz z S-ice : dldr.exe ... jest ono w katalogu UTILS16 (nazwa mówi sama
za siebie) i ładujesz nim program :

dldr programx.exe

i ładujesz na początku kodu programu ... potem już robisz wszystko "normalnie" ...
Jeśli jednak MUSISZ w DOS-ie go lamac to jest tez S-ice 2.80 dla DOS-a ... znajdź
go w sieci i używaj ! <-) ...
No dobra ... to tyle <-) ...
END ! ...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

...................................................................
ŁAMANIE VB-SHIT <-(

Eh ... nawet nie chce mi się o tym pisać bo to przykre ... jednak
trudno ... robota to robota <-) ... VB to takie cos co nie jest jakby
zwyczajnym programem (tylko gównem <-) ) tylko programem który jest związany
ze standardowymi bibliotekami VB (DLL-e) ... zależnie od wersji - VB3 , VB4 , VB5 , VB6
(VB 1 i 2 to nie wiem czy to było czy nie ... w każdym razie nie pod W32) ...
- nazwy bibliotek się różnią np. dla programów napisanych w VB4 (32-bitowych)
nazwa biblioteki to : VB40032.DLL albo dla VB5 to : MSVBVM50.DLL ...
prawdę mówiąc to nie pamiętam reszty nazw i nie chce mi się sprawdzać
ale możesz gdzieś na to zerkanac ... Nie znam dlatego ze po prostu nie
musze ... zawsze udaje mi się rozpoznać który program jest VB a który
nie ... to proste ... wystarczy zobaczyć podczas śledzenia kodu na DLL-e
jakie program "przerabia" jeśli są w którejś nazwie DLL-a literki "vb" to
prawdopodobnie jest to program VB ... nie ma tu żadnej filozofii ...
Rozpoznać można tez czy to program VB przy instalacji ... jeśli widzisz
ze instalowane są jakieś "podejrzane" biblioteki to łatwo to rozpoznać ...
W zasadzie jest tylko kilka różnic w łamaniu "zwykłych" programów i VB ...
przedstawię to w punktach :
1) Do kodu zabezpieczenia NIE dostaniemy się przez GetDlgItemTextA czy tym
podobnych standardów ... dostaniemy się za to przez HMemCpy !!! ...
(chociaż to tez w zasadzie można uznać za standard <-) ) ...
Zobacz na dział "SPOSOBY PODEJŚCIA" na dokładniejsze ino o HMemCpy ...
Tylko tutaj po tym hmemcpy nie dostaniemy się do kodu właściwego programu
lecz do BIBLIOTEKI !!! ... czyli po iluś tam F12 w linijce com/dat nie będzie
nazwa programu tylko nazwa biblioteki np. VB40032.DLL ... i musimy śledzić
bibliotekę (w zasadzie to nie musimy (zazwyczaj) wystarczy znaleźć ciąg
bajtów odpowiadający za określony ciąg instrukcji poznasz to przy okazji <-) )
2) Jak wiadomo programy VB korzystają ze standardowych bibliotek to wykonania
nawet najdrobniejszych żądań (takich jak np. porównanie SERIALI <-) ) ...
w związku z tym sprawdzenie czy SERIAL był właściwy (zazwyczaj) zostanie
przeprowadzone w tej właśnie bibliotece (DLL-u) ... I tu przestroga ! ...
jeśli już znajdziesz kod sprawdzający poprawność SERIALA w DLL-u to NIE możesz
zmienić w kodzie DLL-a jakiegoś bajt np. skoku JZ na JMP czy JNZ ...
hmmm ... dlaczego ? ... ponieważ z tego DLL-a NIE korzysta tylko program
który akurat łamiesz, lecz TAKŻE inne programy VB4 (jeśli to był program VB4)
i te inne tez by korzystały ze zmienionej biblioteki powodując nie przewidziane
konsekwencje ... a jeśli nawet tylko program który łamiesz korzysta z danego
DLL-a to i tak jest niebezpieczeństwo ! ... gdyż odcinek kodu w bibliotece
który jest odpowiedzialny za sprawdzenie SERIALA i który zpatchowales NIE
jest prawdopodobnie odpowiedzialny tylko i wyłącznie za sprawdzenie tego
SERIALA lecz jest odpowiedzialny tez za porównanie JAKICHKOLWIEK łańcuchów znaków !!!
... uh ... dalej nie łapiesz ? ... no cóż ... zobrazuje to na przykładzie ...
WYOBRAŹMY sobie program X który formatuje dyski ... jest to program VB4 ...
ma pole textowe w którym wpisujesz literę dysku do sformatowania ...
jest to shareware i można go zarejestrować przez podanie numeru licencyjnego
... Znalazłeś miejsce w DLL-u gdzie jest porównywany twój SERIAL z
prawidłowym ... okay ... zmieniłeś skok JZ który odpowiada za zarejestrowany/
niezarejestrowany program w hexedytorze na JMP (w pliku VB40032.DLL !!!) ...
uruchamiasz program, wpisujesz dowolne dane i spoko, program zarejestrowany ...
a teraz chcesz sobie sformatować dyskietkę, wiec wpisujesz literę dysku "A" ...
przypuśćmy ze program NAJPIERW porównuje czy zostało wpisane "C" ... a jeśli ty
zpatchowales tego DLL-a to program "pomyśli" ze to co wpisałeś jest ZAWSZE "C" ! ...
i co ? ... i zamiast sformatowanej dyskietki masz sformatowany HDD <-) ... (dzieci :
nie probojcie tego w domu <-) ) ... Oczywiście program jest fikcyjny, ale to tylko
jako przykład - abyś zrozumiał problem <-) ... Program VB może porównywać KAŻDE
stringi ta metoda i BĘDĄ się działy nie przewidziane rzeczy !!! ... WIEC PAMIĘTAJ !
... NIE EDYTUJ VB-DLL-a !!! (przynajmniej w zabezpieczeniach typu SERIAL <-) ) ...
3) W VB-DLL-ach istnieją standardowe miejsca gdzie są porównywane stringi (jeśli
zerkniesz na dołączony WINICE.DAT do tego textu to zobaczysz w makrach jakie
to miejsca) ... jednak sproboj najpierw standardowo ... tak dla praktyki
później zaczniesz stosować te "wzorce" <-) ...
4) Wszystkie (chyba) wersje VB zanim zrobią cos ze stringami zamieniają ich
format na WIDE CHAR ! tzn. ze oddzielają każdy znak bajtem "00" !!! ...
Obrazowo :

ZWYKŁY : "12345" (okno danych : 12345)

WIDE CHAR : "1",0,"2",0,"3",0,"4",0,"5",0 (okno danych : 1.2.3.4.5.)

Jeśli zobaczysz w oknie danych twój SERIAL właśnie w formacie WIDE CHAR
to możesz podejzewac ze VB się gdzieś tutaj kręcił <-) ... taka konwersja
pomiędzy zwykłym formatem textu a WIDE CHAR jest wykonywana (zazwyczaj) przy
pomocy funkcji API : MultiByteToWideChar ... możemy na niej zastawić BPX
i od razu przechwycić miejsce w pamięci z naszym przekonwertowanym SERIALEM
zastawić na nim BPM/PR. i już dalej standardowo ... UWAGA ! to jest bardzo
ważne z tym WIDE CHAR, jeśli nie będziesz o tym pamiętał możesz sobie
nie poradzić z programami VB ! ...

5) Istnieją dekompilatory dla VB3 i VB4 ... możesz spróbować ta droga <-) ...
Istnieje także program o nazwie SmartCheck jest to "program flow analyzer"
tzn. śledzi określone działania w programie i wykonuje "raport" ...
Jednak ten program nie jest tylko dla programów VB (chociaż wydaje się
ze do tego został przeznaczony <-) ) lecz także do innych ... Po prostu
uruchom go i się z nim zapoznaj (poproboj opcje I PRZECZYTAJ Hela) ma
"idioto-odporny" interface (zresztą tak jak WDASM) <-) ... (może kiedyś
napisze cos jeszcze o SmartCheck) ...

EEE ... dobra ... więcej nie chce mi się pisać ...
spadam z tego działu <-) ...
....................................................................

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PREZENCIK !!! <-) :

A teraz na koniec jako "prezent" <-) - "zadania domowe" ...
Wiele osób pyta mnie o to wiec postanowiłem to tutaj zamieścić ... <-) ...
Jest to zbiór 35 programikow które są albo BARDZO proste albo BARDZO banalne <-) do
złamania ... tzn. ze macie na każdy program 1-5 min ... wszystkie zabezpieczenia
w nich są typu SERIAL czyli sam SERIAL albo NAME/SERIAL ... nawet nie ma żadnego z
plikiem rejestracyjnym (nie miąłem żadnego prostego pod ręka <-) ) ...
Postarajcie się je złamać ... tak w ramach treningu <-) ...
... nie napisałem które wersje - bo nie chciało mi się sprawdzać ... <-) ...
Ze zdobyciem programów nie powinno być większych problemów ... w każdym razie
w okolicy czasu gdy to pisze <-) ... wszystkie (chyba) programy są z magazynów :
CHIP/PC WORLD KOMPUTER/WWW ... numery : 12/98 , 1/99 , 2/99 ... programy
oznaczone znaczkiem "(VBx)" znaczy ze są napisane w Visual Basic-u (niezbyt
ich dużo <-) ) ... no ale "programiści" VB tworzą ich coraz więcej <-(( ) ...
(przynajmniej zadbałem o wszystkie wersje VB <-) ... wersja 3 już praktycznie
wychodzi z użytku)

Oto "CZARNA LISTA" <-) :

* WIN BOOST 98
* TELEPORT PRO
* EDIT++
* MIRC
* AUTOODTWARZACZ
* PACT GHOST 98
* WINHACKER
* ICCD
* MULTIMEDIA XPLORER
* MOMSHELL 32
* MACRO MAGIC
* CAOS GRAPH
* AUDIO COMPOSITOR
* FXEDIT
* WINAMP
* BUSINESS CARD DESIGNER PLUS
* GROUND CONTROL
* SAFETY NET PRO (VB4)
* GOLDWAVE
* KATALOG CD
* REMINDER
* THINGS TO DO
* SAFETY SCAN
* ARJSHELL
* WINZIP
* LINEAGE MANAGER FOR DOGS
* MUSIC MASTERWORKS
* TWIN EXPLORER
* HTMLOWIEC
* SCREEN LOUPE
* HTMLCOLORS
* CONNECTPAL PROFESSIONAL (VB5)
* F-SECURE SSH
* WEB WEAVER 98 (VB6)
* IRFAN VIEW

Okay ... Okay ... wiem mitrze ze to dla was za proste <-) ...
jeszcze podam 2 programiki które są na trochę wyższym poziomie ...
(ale nie myśl ze to są BARDZO dobre zabezpieczenia !!!)
programy te to :

* FAR
* FIRE HAND EMBER PRO

wskazówka do FAR-a :
Rejestracja odbywa się przez uruchomienie programu z opcja -r ! ...
czyli w prompt DOS-a (bezpośrednio z FAR-a ... tak jak NC - jest prompt)
wpisujemy (będąc w katalogu FAR-a) komendę : far.exe -r ... !!!
program jest 32-bit ale pracuje w trybie textowym ! ... nie zadziała
tu żaden API (tzn. żaden do pobrania textu z okna np. GetDlgItemTextA) ...
Są zapewne inne metody dostania się do kodu programu ... ale powiem wam
jedna (najbardziej oczywista) ... eh, powinniście to sami wykombinować ...
JEŚLI CHCESZ TO NIE CZYTAJ DALEJ KILKU LINIJEK !!!
Ta oczywista metoda to oczywiście : wpisz dane rejestracyjne ... wejdź do
S-ice'a przeszukaj pamięć czy nie ma w niej twojego SERIALA (s 0 l ffffffff "xxx")
Jeśli znajdziesz to breakpoint (BPM/PR.) wychodzisz z S-ice'a i naciskasz OK ...
Jeśli nie to wyjdź i znowu wejdź i znowu poszukaj i tak w kolko <-) (albo F12) ...
dalej już sam ...

wskazówka do FIRE HAND EMBER PRO :
Nie ma <-) ...

Jeśli powiedzie Ci się z FAR-em i FIRE HAND EMBER PRO to już sobie możesz odpuscic
czytanie textow ! ... po prostu dalej możesz iść już bez ich pomocy ... przynajmniej
moich ... (aż do pewnego numeru <-) ) ... co najwyżej czytaj texty o jakichś
nieznanych trickach (najlepiej na fravia.org) ... a tak to możesz polegać na
swojej inteligencji i wprawiać się w naszej "sztuce" ... <-) ... (ale powtarzam :
nie popadnij w MEGALOMANIE bo to nie są BARDZO trudne zabezpieczenia !!!) ... <-)

UWAGA !!! ... WSZYSTKIE programy TRZEBA skasować zaraz po złamaniu ... bo podąłem
je TYLKO jako zadanie praktyczne ... i da się je zastąpić jakimiś FREEWARE ...
oczywiście jak chcesz to możesz je kupić <-) ... ale dla mnie (prawie) wszystkie z
nich są BEZUŻYTECZNE ... (tzn. (prawie) wszystkie mam zastąpione przez FREEWARE -
i zmierzam do tego aby wszystkie (nie tylko prawie) zastąpić FREEWARE-ami a te co
mam SHAREWARE to chodzą na zasadach przyjętych przez autora !) ...
hehe <-) ... TO NIE ŻADEN ŻART ! ... MÓWIŁEM POWAŻNIE <-| ... podsumowując macie
zrobić tak : a)INSTALL, b)CRACK, c)UNINSTALL !!! ... przynajmniej ja tak zrobiłem i
mam nadzieje ze zrobisz to samo ... !!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

================================================
Linki :

CrackPL - http://www.hyperreal.art.pl/cypher/crkpl/ WRESZCIE polska strona
dotyczaca crackingu !!!
ma liste E-mail na która
możesz się zapisać ...

(UWAGA! reszta stron po angielsku!) :

MiB - mib99.cjb.net/ Kilka dobrych FAQ i
kilka dobrych programikow CrackMe
wraz z rozwiązaniami ... tam są wszystkie
CrackMe które opisałem w moich testach
napisane przez +Cruehead-a

Fravia+ - fravia.org/ bardzo dobra strona czlonka +HCU (HQ +HCU)
bardzo dużo opisów złamań
NIEZASTĄPIONA ... i jedyna ... praktycznie
wystarczyłaby ta jedna strona do nauki <-)
Przynajmniej ja praktycznie z innych NIE korzystam

ASM tutorials - www.la-online.com/assembly.htm Dużo faq dotyczących ASM-a

+Greythorne - home.sol.no/reopsahl/files/assem.htm ciekawa strona
o Crackingu i ASM

Iczelion - iczelion.cjb.net NARZĘDZIA ! ... dość szybki
transfer (jeśli cokolwiek z
TPSA można nazwać "szybkością" <-) )

Więcej rożnego rodzaju stron poszukaj w linkach na Fravia.org ...
Jest tam wszystko czego potrzebujesz <-) ...
=================================================

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
LITERATURA <-) :

"ZROZUMIEĆ ASEMBLER" - Eheheh ... nauka assemblera dla nowicjuszy
JEFF DUNTEMANN UWAGA ! ... jest to tak LOPATOLOGICZNIE napisane
Wydaw. "WILEY" ze prościej się NIE da ! ... wiec jeśli nie pojmujesz
ASM-a z innych źródeł powinieneś na to zerknąć <-) ...

"ART OF ASSEMBLY LANGUAGE" - To jest cos co każdy powinien przechowywać na HDD !!!
NIE znam autora DOSKONAŁY tutorial ASM-a (Po angielsku) ... po
Wydaw. NIE znam prostu lepszego nie ma ! <-) ... Nie pytaj się mnie
gdzie to dostać ... powinno być na stronie +Greythorne'a
... poza tym umieszczę go na swej stronie ... jest już
załadowany na FTP ...

"FRAVIA.ORG" - Najlepiej przeczytaj jak najwięcej z tej strony WWW ... <-) ...
FRAVIA+
Wydaw. SIEC <-)

"ENCYKLOPEDIA INFORMATYKI" - Prawie cala "techniczna" strona Crackingu/reversingu
STANISLAW KRUK opisana ! ...
Wydaw. "PRACOWNIA
KOMPUTEROWA JACKA
SKALMIERSKIEGO"

"WIELE INNYCH" - Szukaj rożnych źródeł ... np. książki dotyczące wnętrza
WIELE AUTORÓW W95/98 ... ASM-a ... budowy i działania komputera (adresowanie
Wydaw. "WIELE pamięci, porty I/O, przerwania ... itp.) ... texty o crackingu
WYDAWNICTW" dostępne w sieci (słownik angielskiego się przyda <-) ) ...
texty na temat Kryptografii i Virii ... Struktury plików
wykonywalnych (EXE, COM ...) i ich naglowki (NE, PE ...) ...
metody kompresii/kodowania danych (plików) ... rejestr W95/98 ...
kody źródłowe virusow ... programowanie W32 (API reference) ...
HELP-y dolaczone do naszych ukochanych narzędzi ... no porostu
wszystko co ma choćby jakiś związek ... nawet nie bezpośredni <-)

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
KONIEC. END. FIN. TERMINO. ENDE. KONEC. UTOLSO. <-) ...