   
                    _______                   ______
                    |   _   |-----.--.--.-----.   _  \
                    |   1___|  -__|  |  |  -__|.  |   |
                    |____   |_____|\___/|_____|.  |   |
                    |:  1   |                 |:  |   |
                    |::.. . | POLISH CRACKERS |::.|   |
                    `---===='__             __`-==_---'
                       |       |-----.---.-.   Y   |
                       |.|   | |  -__|  _  |.      |
                       `-|.  |-'_____|___._|. \_/  |
                         |:  |             |:  |   |
                         |::.|             |::.|:. |
                         `---'             `--- ---'


.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,-= InFo =-,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.
;                                                                              ;
;   What       :  tut                                                          ;
;   Date       :  4/02/2000                                                    ; 
;   Written by :  plastek                                                      ;
;                                                                              ;
;,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.-= How To =-.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,;

			
                      How to make our SoftICE (almost) invisible.

W tym texciku postaram sie przedstawic kilka najwaznieszych i najczesciej stosowanych metod wykrywania naszego ukochanego narzedzia. Jednak nie bede sie zajmowal szczegolowymi opisami poszczegolnych metod tylko sposobami na ominiecie ich.
Do napisania tego textu sklonil mnie sipatch by CookieCrk ktory mimo ze bardzo dobry dziala tylko na niektorych konfiguracjach (nie mam tego im za zle w koncu tyle jest wersji Windozy i SI).

                                     !!! UWAGA !!!
Zadna z informacji tu przedstawionych nie ma na celu doprowadzenia do zniszczenia twojego systemu operacyjnego oraz debugger'a jezeli jednak cos sie stanie to jest to albo TWOJA wina albo specjalistow z Micro$oftu. Pamietaj rob kopie zapasowe zmienianych plikow!!! Najlepiej przy kazdej zmianie (bedziesz wiedzial na czym ci siada).
                                     !!! UWAGA !!!


Dobra zaczynamy:

I. 
   Pierwsza i najczesciej stosowana metoda jest tzw. MELTICE polega to na wykrywaniu obecnosci SI    poprzez jego vxd'ki. Program ktory chce sprawdzic obecnosc SI wywoluje funkcje CreateFileA i     probuje stworzyc pliki o nazwach naszych VXD'kow. Oczywiscie jesli SI jest w pamieci system na    to nie pozwoli i wtedy program porownuje wynik operacji(-1) z wartoscia wpisana w kod ;) i       jezeli mu wyjdzie ze nie udalo sie stworzyc pliku (-1) to sie wywala :(. Rozwiazanie jest        bardzo proste wystarczyc zmienic nazwy naszych VXD'kow na cos innego i juz nie ma problemu.
   Ale gdzie one sa???. Odpalamy Hiew (lub inny edytor hex ja uzywam tego) ladujemy plik            winice.exe i szukamy stringow SICE i NTICE a nastepnie zamieniamy je na cos innego(o tej samej    liczbie znakow of coz). Odpalamy program ktory sie opieral i ladnie sie uruchamia czyli          MELTICE mamy z glowy. Nie jeszcze nie sprobuj odpalic SI loadera i uruchomic jakis plik wywala    ze nie ma SoftICE :(. Tak bo te nazwy VXD'kow sluzyly do komunikacji SI z loaderem a jak je      zmienilismy to loader nie dziala bo nie wykrywa SI. Wiec nalezy przerobic loadera. Tak           ogladamy pod Hiew (lub innym ;)) plik loader32.exe ale tam nie ma zadnych SICE i NTICE. Nie      bede juz tu wyjasnial w jaki sposob znalazlem gdzie sa nasze nazwy ukryte wystarczy              uruchamiajac w loaderze jakis program zastawic bpx na CreateFileA. Dobra wiec te nazwy sa w      nmtrans.dll wiedzac to szukamy stringo SICE i NTICE w tym pliku i zamieniamy je na to na co      zamienilismy stringi w winice.exe!!! No i problem z glowy :)

II. 
   Kolejna metoda jest troche bardziej wyrafinowana i wykorzystuje sposob w ktory kontaktuje sie 
   jedno z narzedzi NUMEGI (BoundsChecker) z SoftICE'm. Polega to na wykorzystaniu tzw. wyjatkow
   nie bede tego opisywal (zajrzyjecie na stronke CrackPL) podam tylko najwazniejsze informacje.
   Przy eax=4 i ebp="BCHK" wywolanie INT 3 (po uprzednim SetUnhandledExceptionFilter) nie           powoduje kontynuacji dzialania programu od okreslonego miejsca w przpadku obecnosci SI.          Dlaczego??? Dlatego ze SI mysli ze to BoundsChecker sie do niego zwraca wiec mu odpowiada ;)
   Rozwiazanie: patch winice.exe ;). Hiew->winice.exe i szukamy ciagu BCHK i nie ma :(. Nie ma      bo nie moze byc ten string jest zapisany w postaci HEX i porownywany w pewnym miejscu z EBP.
   Co nalezy zrobic??? Tak notacja intel'a zapisujemy HEX naszego stringu w odwrotnej kolejnosci
   tzn zamiast 42,43,48,4b  dajemy szukanie 4b,48,43,42 :). Tak znalazl wiec zmieniamy to na cos    innego na przyklad 43,43,43,43 i juz gotowe :).

III.
   I znowu programisci z NUMEGI dolozyli nam roboty ;) kolejna metoda na wykrycie i znowu           wykorzystany sposob w jaki kontaktuje sie SI z loaderem ale ze starszej wersji (katalog          Util16). Spsob jest prawie identyczny jak poprzedni z tym ze INT 3 jest wywolywane nie z eax=4    i ebp="BCHK" tylko z si="FG" i di="JM". Otwieramy winice.exe i znajdujemy stringi FG i JM (nie    razem tylko po kolei) sa one niedaleko od miejsca gdzie byl (teraz juz co innego) BCHK.          Oczywiscie notacja intela wiec szukajac FG wpisujemy GF a JM wpisujemy MJ. Jesli korzystasz ze    starych loaderow podobnie zmien plik wldr.exe i dldr.exe.
IV.
   Czwarta metoda jest jeszcze bardziej zaawansowana i wymaga przerobienia plkiu krnl386.exe.       Jezeli uwazasz ze system operacyjny jest swietoscia NIE ROB tego ale znienacka moze cie kiedys    zaskoczyc CRACKME i lezysz ;)!!! Sposob ten jak juz sam pewnie zauwazyles opiera sie na          komunikacji systemu z debuggerem (lub na odwrot). Chodzi o to ze jezeli wywolamy INT 41 przy     ax=4F jezeli jest obecny SI w sytemie przejmie on obsluge przerwania i wprowadzi do ax wartosc 
   F386 jest to identyfikator debuggera w systemie. W tym momencie moje rozwiazanie odbiega od      standardow ale jest skuteczne i pewne. System MUSI widziec debugger'a bo inaczej sie nie         uruchomi albo nie pozwoli na debugowanie!!!. Rozwiazania jakie do tej pory widzialem opieraly    sie na zamianie identyfikatora F386 na inny (jak chcesz mozesz tak zrobic ale nie wiem ktore     miejsca w SI trzeba zapatchowac zeby nie kolidowalo nam to z metoda V ktora zaraz przedstawie)
   Ja jednak postanowilem utworzyc inna droge do komunikacji z debuggerem zmieniajac wykrywanie     debuggera przy ax=4F na ax=??(nie powiem co u mnie;)). Ok jestes gotowy??? Odpalamy Hiew (lub    inny) ladujemy winice.exe i szukamy F386 oczywiscie wpisujemy to nie jako string tylko jako      HEX i bajty w odwrotnej kolejnosci czyli 86,F3 i patrzymy. Bedzie tam pare linijek mov           ???,F386 i podobne ale nas interesuje ta:
   000819EE: 6683F84F                     cmp       ax,04F ;"O"<- to jest wazne 04F
   000819F2: 7505                         jne       0000819F9
   000819F4: B886F30000                   mov       eax,00000F386
   NIE szukaj po offsetach (mozesz sprobowac ale nie sugeruj sie) bo moga byc inne!!!
   Ok wiec mamy cmp ax,04F zmieniamy to na cmp ax,033. Ale to nie koniec jak bys teraz uruchomil    system to przy uruchamianiu by sie przeladowywal caly czas :(. Trzeba poszukac jeszcze jednego    cmp ax,04F (czyli 66,83,F8,4F) i tez zmienic na cmp ax,033 (moze byc na cos innego byle nie      kolidowac z innymi zajetymi juz ;) i zeby bylo tak samo jak wczesniej). Ale to nadal nie         koniec w tej chwili debugger mowi swoje a system swoje i sie nie moga dogadac trzeba zmienic     takze krnl386.exe zeby mogly sie dogadac (KOPIA ZAPASOWA!!!). Wiec ladujemy nasz krn386.exe do    Hiew i szukamy 86,F3 jak znajdziemy to bedzie cos takiego:
   0000F11B: B84F00                       mov       ax,0004F ;" O"
   0000F11E: CD41                         int       041
   0000F120: 3D86F3                       cmp       ax,0F386 ;""
   NIE szukaj po offsetach (mozesz sprobowac ale nie sugeruj sie) bo moga byc inne!!!   
   I tu taka sama zmiana jak w winice.exe!!! I mamy zabezpieczonego debuggera przed kolejna         metoda.
V.
  Ta metoda jest bardzo podobna do poprzedniej tylko jeszcze bardziej ryzykowna jakoze zmianom     bedziemy poddawali vmm32.vxd. 
                                       !!! UWAGA !!!
  Ten sposob zebezpieczenia SI zostal w calosci wywmyslony przeze mnie i tylko przeze mnie byl     testowany. U mie chodzi kewl ale nie wiem jak u innych. Dlatego KOPIA ZAPASOWA!!!
                                       !!! UWAGA !!!
  Jesli sie zdecydowales to czytaj dalej ;)
  Poprzedni sposob (IV) byl uzywany do komunikacji debuggera z systemem ale tylko poprzez          krnl386.exe ten opiera sie na vmm32.vxd. Nie pytajcie sie po co systemowi tyle bajerow bo nie    wiem. Vmm32.vxd chcac sprawdzic obecnosc debugger'a wywoluje INT 68 przy ah=43 jezeli system     jest to zwraca do ax F386. Odpalamy Hiew (lub inny) i ladujemy vmm32.vxd. Szukamy naszego        kochanego 86,F3 i znajdujemy cos takiego:
  00001524: B443                         mov       ah,043 ;"C"
  00001526: CD68                         int       068
  00001528: 3D86F3                       cmp       ax,0F386 ;""
  NIE szukaj po offsetach (mozesz sprobowac ale nie sugeruj sie) bo moga byc inne!!!
  Oczywiscie zmieniamy 43 na cos innego np 45 i juz. Teraz otwieramy winice.exe i szukamy          cmp ah,43 czyli 80,FC,43 i znajdujemy:
  00001506: 050080FC43                   add       eax,043FC8000 ;"C "
  0000150B: 0F84260180FC                 je        0FC801637
  No tak ale tu nie ma cmp ah,43 to teraz daj F5 i adres 1508 (u mnie u ciebie moze byc inny       wpisz adres ktory wskazywany jest przez Hiew gdy znajdzie to czego szukamy.
  Teraz mamy:
  00001508: 80FC43                       cmp       ah,043 ;"C"
  0000150B: 0F84260180FC                 je        0FC801637
  I co zrobic??? Tak zmienic 43 na 45 (tak jak w vmm32.vxd). I to juz koniec :))))
  
Do tutka dolaczam program detect ktory sprawdzi twojego SI na cztery sposoby oprocz MELTICE ktorego nie chcialo mi sie dopisywac. Programik ten nie ma na celu udowadniania moich zdolnosci programistycznych ktore sa IMHO niewielkie tylko ma robic to do czego zostal stworzony. Pomysl zostal oparty na podobnym narzedziu dolaczanym do SIPATCH'a CookieCrk ale nie zerznalem ani troche kodu ;). 
.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,-= OtHer =-.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.
;                                                                              ;
;   Thanks for: Ptasiek, Dulek, Maxibogas, _r00t_, massh (INT 41/4F)           ;
;                                                                              ;
;   My e-mail: plastek2@zielonagora.com                                        ;
;              ~~~~~~~~~~~~~~~~~~~~~~~~                                        ;
;   SeveN Team Page: http://www.7team.z.pl                                     ;
;                    ~~~~~~~~~~~~~~~~~~~~~                                     ;
;,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,-= MeMberS =-,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.;
;                                                                              ;
;            MaxiBogas _ _ _ _ _ _ _ _ _ _ _ _ founder/coder/cracker           ;
;            Plastek _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ founder/cracker           ;
;            Jube _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _cracker           ;
;            {ATOM} _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _cracker/decoder           ;
;            LIAR _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _webmaster           ;
;            Dumboo_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ cracker           ;
;            jamman_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ cracker           ;
;,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.;