WWW.ehaker.pl

Łamanie haseł w Windows XP.

1. Wstęp
Przede wszystkim chciałbym zaznaczyć, że ani ja ani Random
Intruders nie ponosi odpowiedzialności za sposób w jaki wiedza
zawarta w tym tekście zostanie wykorzystana. Wszystkie
informacje z tego tutorialu maja służyć jedynie celom
edukacyjnym.

2. Przedmiot Tutorialu

Głównym celem tego tekstu jest omówienie lokalnych sposobów

na zdobycie hasła administratora (i każdego innego) posiadając

jedynie uprawnienia użytkownika lokalnego np. gościa lub nawet

żadne. Tym optymistycznym akcentem rozpoczynam

opowiadanie bajki pt. "Jak to Microsoft radzi sobie z hasłami?".

3. Sposób przechowywania haseł
W systemach Windows95/98/Me hasła przechowywane są w
plikach .pwl, ale ponieważ nie są one w żaden sposób chronione
a programów do ich łamania jest cale mnóstwo (choćby słynny
cain) to w tym tekście skupie się tylko na systemach z serii NT
czyli Windows NT/2k/XP/Server 2003. Otóż w tych systemach
hasła przechowywane są w pliku SAM znajdującym się (pod
warunkiem, że windows został zainstalowany w C:\WINNT) w
katalogu C:\WINNT\system32\config. Plik ten jest swego rodzaju
plikiem rejestru (cos jak plik system.dat w Win95/98/Me),
można go zresztą przeglądać za pomocą edytora rejestru, ale
wymaga to użycia kilku sztuczek i jest całkowicie bezcelowe.
Podczas bootowania windowsa zanim użytkownik może w ogóle
się zalogować do systemu główny watek programu Smss.exe
(Session Manager - Menedżer Sesji) uruchamia proces
Winlogon.exe, gdyż jest on potrzebny by załadować Lsass.exe
(Local Security Subsystem - Lokalny Podsystem
Bezpieczeństwa), który następnie ładuje usługę SAM (Security
Accounts Manager - Menedżer Kont Bezpieczeństwa), który jest
po prosu interfejsem dającym nam dostęp do bazy danych SAM.
Plik SAM nie przechowuje jednak samych haseł a jedynie ich
hashe, czyli wyniki działania jednostronnego (czyli
nieodwracalnego) algorytmu szyfrującego na hasłach. Kiedy ktoś
loguje się na komputer hasło, które wpisał zostaje zaszyfrowane
w ten sam sposób, a wynik (czyli hash) jest porównywany z
hashem z pliku SAM i jeśli są takie same użytkownik uzyskuje
dostęp do systemu. Każde hasło jest przechowywane na dwa
sposoby jako LM hash i jako NT hash, podczas gdy, NT hash jest
hashem naszego hasła to LM hash jest hashem naszego hasła
pisanego dużymi literami. Oznacza to, ze dla haseł:
"Haselko","hAsElko", HaSeLkO",itp NT hash będzie inny, ale LM
hash będzie taki sam!!! Nie musze chyba tłumaczyć, jak
użyteczne jest to dla nas. Możliwe jest jednak wyłączenie przez
admina LM hashy i konieczne w takim wypadku jest łamanie NT
hashy, co znacznie utrudnia sprawę. Na szczęście zdarza się to
rzadko, a poza tym jeśli już się zdarzy, to łamanie hashy nie jest
wtedy najlepszym pomysłem, wiec w tym tutorialu takiej sytuacji
nie zamierzam rozważać. Oczywiście nie zalogujemy się do
systemu używając hasła zdobytego łamaniem LM hash (chyba,
że hasło oryginalne tez nie składało się z małych liter). Jeśli
jednak dowiedzielibyśmy się, że nasz LM hash odpowiada np.
hasłu "HASELKO", to sprawdzenie kombinacji małych i dużych
liter będzie już tylko formalnością (i tak właśnie robią programy
łamiące LM hashe). Hasła w systemach WinNT nie mogą być
dłuższe niżeli 14 znaków, już Win2k dopuszcza dłuższe hasła (do
128 znaków), ale spójrzmy prawdzie w oczy, chyba nikt nie
używa takich haseł;) Dlatego w tym tekście omówię jedynie
sytuacje gdy, hasło ma długość mniejszą lub równą 14 znaków.
Nie testowałem jeszcze Windowsa Server 2003, ale o ile mi
wiadomo jeśli chodzi o hasła to działa on na tej samej zasadzie

wiadomo jeśli chodzi o hasła to działa on na tej samej zasadzie
co XP. Zarówno LM hash jak NT hash zajmują 16 bajtów ja
jednak skupie się tylko na LM hashu, (dlaczego? Patrz wyżej;))
Otóż jego pierwsze osiem bajtów odpowiada pierwszym siedmiu
znakom hasła, a drugie osiem bajtów drugim siedmiu znakom
hasła. Jeśli hasło jest krótsze niż 14 znaków, np. 10, to znowu
pierwsze osiem bajtów hashu odpowiada pierwszym siedmiu
literom naszego hasła, a pozostałe osiem bajtów odpowiada
pozostałym literom naszego hasła. Jeśli jednak hasło ma długość
krótszą lub równą 7 znaków, to po raz trzeci pierwsze osiem
bajtów hashu odpowiada literom hasła, a drugie osiem bajtów
będzie w tym przypadku zawsze równe 0xAAD3B435B51404EE.
Jeśli dane konto w ogóle nie posiada hasła, czy raczej posiada
hasło zerowej długości, to obie części hashu przyjmują tą
wartość. Czyli hash wygląda
tak:0xAAD3B435B51404EEAAD3B435B51404EE.

4. Zdobywanie hashy
Hashe można zdobyć (lokalnie) na dwa sposoby. Pierwszy polega
na użyciu programu pwdump. Włączamy jedynie program, a on
wyświetla nam w oknie konsoli hashe. Jeśli wywołamy go że
znakiem przekierowania, czyli '>', np. "pwdump.exe >hash.txt".
To nasze hashe zostaną zapisane do pliku hash.txt. Jeśli użyjemy
jako parametr adres jakiegoś komputera np. "pwdump.exe
127.0.0.1", "pwdump.exe \\127.0.0.1" lub "pwdump
www.microsoft.com")) To pwdump spróbuje się połączyć z tym
komputerem i jeśli udostępnia on zdalnie swój rejestr, to
pwdump ściągnie z niego hashe. Niestety dużym minusem tego
programu jest to, iż jest on z góry ustawiony na wyciąganie
hashy z systemów anglojęzycznych. Dzieje się tak, gdyż zakłada
on, iż grupa Administratorów ma angielska nazwę
"Administrators", na szczęście program nie jest ani szyfrowany,
ani spakowany (np. aspackiem, no przynajmniej wersja, która ja
posiadam). Dodatkowo za tekstem "Administrators" znajdują się
dwa bajty zerowe, podczas, gdy w operacjach na tablicach
znaków (tzn. tekstach) wymagany jest tylko jeden. Możemy wiec
śmiało zmienić 's' na 'z', a pierwsze zero na 'y' i już mamy tekst
"Administratorzy", a pwdump działa:))) Jest to bardzo prosta
operacja edytorem szesnastkowym, wiec nie będę wdawał się w
szczegóły. Drugi sposób polega na wykorzystaniu programu
samdump. Program jest w stanie wydobyć hasła bezpośrednio z
pliku SAM. Wystarczy wiec skopiować ten plik z jakiegoś
komputera na dyskietkę i spokojnie w domciu użyć samdumpa z
tym plikiem jako parametrem np. "sampdump.exe a:\SAM". Jest
tylko jeden mały problem. Plik SAM jest chroniony przez system i
żaden użytkownik nie ma do niego bezpośredniego dostępu
także wszelkie próby jego odczytu, lub kopiowania zakończą się
niepowodzeniem. Na szczęście Windows w wielu sytuacjach (np.
przy instalacji) tworzy kopie tego pliku i znajduje się ona (pod
warunkiem że windows został zainstalowany w C:\WINNT) w
katalogu C:\WINNT\repair. Co więcej nie tylko członkowie grupy
Administratorzy (zazwyczaj), ale wszyscy użytkownicy maja
prawo do odczytu i kopiowania tego pliku. Może się jednak
zdarzyć (a bardzo często tak właśnie jest), że dane zawarte w
tym pliku są nieaktualne. W takim wypadku pozostają nam dwa
wyjścia. Po pierwsze możemy uruchomić linucha jeśli taki jest w
komputerze lub skorzystać z jakiejś mini dystrybucji
dyskietkowej bądź pełnej płytowej np. KNOPPIX. To rozwiązanie
ma jeszcze jeden plus. Linux bez problemu czyta zarówno
partycje FAT32 jak i NTFS, ale zdaje sobie sprawę, że wielu ludzi
jest z linuchem na bakier wiec dla nich wytłumaczę inny sposób.
Uruchamiamy komputer w trybie MS-DOS (np. korzystając z
dysku startowego Win98). Jeśli system, z którego chcemy
wyciągnąć hashe został zainstalowany na partycji FAT32 to bez
problemu odnajdujemy katalog C:\WINNT\system32\config i
równie bezproblemowo kopiujemy z niego plik SAM. Jeśli

równie bezproblemowo kopiujemy z niego plik SAM. Jeśli
natomiast dany system został zainstalowany na partycji NTFS,
no to mamy problem, gdyż MS-DOS nie rozpoznaje tego
systemu plików (NTFS), wiec nie będziemy mieli dostępu do tej
partycji. W takim przypadku najlepszym rozwiązaniem jest
użycie programu ntfsdos. Postępujemy tak jak w przypadku
partycji FAT32, jednakże pierwsza rzeczą jaką robimy po
uruchomieniu MS-DOS'a jest uruchomienie programu ntfsdos
poprzez wpisanie po prostu "ntfsdos.exe", no jak ktoś się uprze
to może sobie darować końcówkę ".exe". Następnie ntfsdos
poszuka wszystkich partycji NTFS i po kolei zamontuje je nam
jako normalne dyski MS-DOS. Wersja publicznie dostępna
pozwala jedynie na odczyt partycji NTFS, ale akurat nam to w
stu procentach wystarcza. Niestety zarówno program pwdump
jak i samdump nie dadzą nam poprawnych hashy jeśli system
ma SYSKEY'a.

5. Co to jest SYSKEY
Otóż Microsoft zrozumiał, że jak zwykle strzelił babola i poszedł
po rozum do głowy. Bardzo szybko wprowadził na rynek
poprawki sprawiające, iż tylko członkowie grupy
"Administratorzy" maja prawo odczytu całości rejestru, a wiec
również hashy. Program pwdump stal się wiec bezużyteczny. A
co gorsza dodatek Service Pack 3 (a co za tym idzie każdy
następny (było ich w sumie 6)) do Windows NT wprowadził
aplikacje SYSKEY, potem już Windows 2000, Windows XP i
Windows Server 2003 miały ta aplikacje instalowana domyślnie.
SYSKEY jest to skrót od System Key, czyli klucz systemu zwany
również Bootkey'em. Aplikacja ta tworzy podczas instalacji
unikalny dla każdego systemu klucz, którym dla dodatkowego
bezpieczeństwa szyfrowane są hashe. Nie chce się wdawać w
szczegóły, gdyż myślę, że są one zbędne, ale dla ciekawskich
podam że jest to robione za pomocą algorytmów MD5 i RC4.
śeby było jeszcze ciekawiej klucz ten jest wybierany losowo i
nawet ten sam Windows instalowany na tym samym komputerze
będzie miał za każdym razem inny klucz. Czyżby to miał być już
koniec?

6. Jak poradzić sobie z SYSKEY'em
Fakt faktem, ale ta zniewaga krwi wymaga:) A może raczej
powinienem powiedzieć wymagała, gdyż na stworzeniu przez
Microsoft SYSKEY'a ta bajka się nie kończy. Otóż hakerzy z
całego świata postanowili go rozwalić powstawały rożne pomysły,
miedzy innymi słynna już linuxowska dyskietka, która potrafiła
nawet wyłączyć SYSKEY'a. Jednak każdy kto ja przetestuje
szybko zauważy, że do doskonałości "trochę" jej brakuje, wiec w
tym tekście nie będę jej omawiał. Pierwszym prawdziwym
zwycięstwem było stworzenie programu pwdump2. Działa on
analogicznie do swojej poprzedniej wersji, ale tylko na lokalnym
komputerze. Wykorzystuje on fakt iż SYSKEY'a można obejść, a
co za tym idzie zdobyć czyste hashe za pomocą pewnych
wywołań API ale tylko jeśli jest się aplikacja lsass.exe, która to
właśnie zarządza hasłami, kontami itp. pwdump2 tworzy wiec
"zdalny" watek w lsass.exe, a ten watek ładuje bibliotekę
samdump.dll (dostarczana wraz z pwdump2), która to właśnie
omija (jako lsass.exe) SYSKEY'a i odczytuje nasze upragnione
hashe. Program pwdump2 ma tylko jedna wadę. Ponieważ
manipuluje on pamięcią (nie chce się wdawać w szczegóły;))
lsass.exe musi wiec posiadać przywilej debugowania tzw.
SeDebugPrivilege, żadna aplikacja nie może "otworzyć" procesu
o atrybucie systemowym (a takim przecież jest lsass.exe;)) bez
tego przywileju. Tutaj właśnie pojawia się problem, gdyż ten
przywilej mają sobie (tzn. programom, które uruchamiają)
prawo przyznać tylko członkowie grupy "Administratorzy" Wiec
nam (przynajmniej w większości przypadków) się to w ogóle nie
przyda. Warty zainteresowania jest również program pwdump3

przyda. Warty zainteresowania jest również program pwdump3
pozwala nam on na zdobycie hashy że zdalnego komputera
dzieje się to następująco program łączy się serwerem za pomocą
protokółu SMB jeśli mu się to nie uda tzn., że z naszego
komputera jeszcze żaden użytkownik posiadający na
atakowanym serwerze uprawnienia Administratora nie łączył się
z tym serwerem lub po prostu serwer nie udostępnia w ogóle
protokółu SMB, ale on jest domyślnie włączany gdy konfiguruje
się w Windowsie siec wiec nie mamy się o co bać;) Przykładowo
możemy program pwdump3 wywołać tak: "pwdump3 127.0.0.1
hash.txt Administrator" i prosi o hasło użytkownika. po
połączeniu wysyła na serwer pliki LsaExt.dll i pwservice.exe. I
następnie zdalnie uruchamia program pwservice.exe, który robi z
biblioteka LsaExt.dll prawie to samo co pwdump2 robił z
samdump.dll. Znowu jednak pojawia się problem znajomości
przynajmniej jednego hasła Administratora, nie mniej jednak
sam projekt jest ciekawy. Wspomnę jeszcze, że istnieje program
pwdump4, który jest jakby połączeniem pwdump2 i pwdump3,
nie będę go wiec opisywał, podam jedynie jak dla przykładu go
uzyc:"pwdump4 /l" - to samo co pwdump2, "pwdump4 127.0.0.1
/u:Administrator" - to samo co pwdump3. Dopiero jakiś rok
temu programistom udało się całkowicie złamać SYSKEY'a, a to
za sprawa aplikacji samdump2, bkhive i bkreg. Z tych trzech
praktycznie najmniej użyteczna jest aplikacja bkreg. Odczytuje
ona klucz systemu (tzw. Bootkey) z rejestru, a co za tym idzie,
działa tylko uruchamiana (za wyjątkiem niektórych wersji
systemu Windows NT) przez członków grupy "Administratorzy".
bkhive natomiast wyciąga klucz systemu z pliku system, który
można znaleźć wszędzie tam gdzie plik SAM. Bkreg uruchamia
się np. tak: "bkreg key.txt". W tym momencie w pliku plik
key.txt w formacie hex zostaje zapisany klucz systemu. Bkhive
natomiast następująco: "bkhive jakaslokacja\system key.txt" i
znowu mamy Bootkeya w pliku key.txt. Następnie korzystamy z
programu samdump2, który jako parametry wykorzystuje
właśnie plik SAM i jakiś plik z naszym Bootkeyem, czyli np:
"samdump2 SAM key.txt". Nie będę tłumaczył, jak zdobyć plik
system, gdyż jak już powiedziałem, jest on wszędzie tam, gdzie
plik SAM, a jego zdobywanie zostało bardzo szczegółowo
wyjaśnione w rozdziale czwartym - "Zdobywanie hashy", w
części poświeconej aplikacji samdump. Na koniec dodam tylko,
że pierwsze wersje czasami (ale to naprawdę sporadycznie) nie
potrafiły odczytać pliku SAM, ale autor bardzo szybko sobie z
tym poradził i teraz program działa bez zarzutu. Przynajmniej ja
nie miałem z nim żadnego problemu. I tym optymistycznym
akcentem mamy gdzieś SYSKEY'a, a Bill Gates z całym jego
beznadziejnym Microsoftem może się wypchać:)))

7. Łamanie haseł
No wreszcie mamy już te hashe no i co my z nimi możemy
zrobić? Otóż hashe są zaszyfrowane algorytmem jednostronnym,
a co za tym idzie nie wydobędziemy z nich w żaden sposób
haseł. No tak ale możemy sami cos szyfrować np. rożne słowa i
sprawdzać, czy nasz hash nie odpowiada temu z pliku. I to
właśnie robią łamacze tych hashy. Najlepiej wykorzystać
program L0phtCrack. Ostatnia wersja, która posiadam, to 5 cos,
ale ja skupie się na wersji 2.5, gdyż po pierwsze ma bardzo
prosty i czytelny interfejs, podczas, gdy 3,4 i 5 maja naćpane
mnóstwo jakiś rysunków i innych pierdol, co mnie osobiście
niesamowicie wnerwia, ale to jest wynikiem prostego faktu.
Wersja 2.5 była jeszcze tworzona przez grupę l0pht, potem
jednak sprzedali oni prawa do programu i teraz kolejne wersje są
tworzone przez prywatna firmę. I tu pojawia się drugi powód, dla
którego wole 2.5 - sentyment;) Dlatego w tym rozdziale omówię
właśnie opcje tej wersji. Używanie opcji "Tools->Dump
Passwords from Registry", lub "File->Import SAM File...", jest
bezcelowe gdyż są to kolejno odpowiedniki programów pwdump i

bezcelowe gdyż są to kolejno odpowiedniki programów pwdump i
samdump, a my prawie na pewno mamy do czynienia z
SYSKEY'em najlepiej jest po prostu otworzyć plik stworzony
przez program pwdump2,pwdump3,pwdump4 lub samdump2 za
pomocą opcji: "File->Open Password File" Teraz najważniejsza
rzecz to przede wszystkim skonfigurować program wybieramy
plik słownika: "File->Open WordList File..." Domyślnie program
dostarcza nam plik words-english.dic. Po drugie ustawiamy
metodę szukania: "Tools->Options..." zaznaczamy w polu
"Dictionanry Attacks" (czyli ataki słownikowe) tylko opcje
LANMAN, dlaczego tak robimy zostało wyjaśnione w rozdziale
trzecim - "Sposób przechowywania haseł", w polu
"Dictionary/Brute Hybrid" zaznaczamy "Enabled" i zostawiamy
(lub jeśli jej tam nie ma wpisujemy) dwójkę w polu "Characters".
Teraz program sprawdzi wszystkie słowa że słownika (tak na
marginesie, na końcu tego słownika dobrze jest dopisać już
wcześniej złamane hasła, gdyż może to nam w przyszłości
oszczędzić trochę czasu;)), a dodatkowo sprawdzi każde słowo
że słownika z jeszcze dwoma znakami. Oznacza to, że np. jeśli
dodamy do słownika słowo Karol, to w ciągu paru sekund
program sprawdzi, czy hasłem nie jest np.: "Karol12","Karolfg",
"Karol98","Karol7z",itd. I ostatnia opcja w polu "Brute Force
Attack" zaznaczamy "Enabled" i teraz są dwie drogi albo od razu
ustawiamy opcje "Character Set:" na "A-Z,0-9", i program
sprawdzi, wszystkie hasła literowo-cyfrowe(ustawianie większej
ilości znaków jest w większości wypadków bezcelowe, a poza
tym za długo by to trwało;)). Lub tez możemy ustawić program
tylko na opcje "A-Z", a dopiero jeśli ona zawiedzie spróbujemy
"A-Z,0-9". W głównym oknie programu myślę, że wszystkie
kolumny są proste do zrozumienia dodam tylko, że jeśli przy
którymś z użytkowników w kolumnie "<8" jest x, to oznacza to,
iż jego hasło ma mniej niż 8 znaków, a jak program to określił
można wyczytać w rozdziale trzecim - "Sposób przechowywania
haseł". Niestety wersja 2.5 ma z tym problemy, ale wersje 3,4 i
5 radzą sobie bezproblemowo. A dokładnie wersja 2.5 sprawdza
nasze hashe zakładając, że są one zapisane dużymi literami
(hashe nie hasła), natomiast programy: pwdump2,pwdump3, i
samdump2 w przeciwieństwie do aplikacji pwdump (pwdump4
również) i samdump nie zwracają hashy dużymi literami, lecz
małymi. Dla ciekawskich dodam, że porównywanie to ma miejsce
(dla wersji 2.5) pod adresami 0x4048e7 oraz 0x404dde
najlepszym rozwiązaniem (poza zmiana wersji) jest dodanie w
programie procedury sprawdzania hashy również małymi
literami. Na szczęście np. pod adresem 0x404ecc kompilator
pozostawił nam bardzo dużo miejsca, wiec dodania takiego
porównywania nie nastręczy nam żadnych problemów i wymaga
jedynie podstawowej znajomości asemblera, gdyby ktoś jednak
miął problemy, lub po prostu był tym zainteresowany, to mogę
dostarczyć odpowiedniego patcha. Co najciekawsze długość
hasła nie ma praktycznie wpływu na prędkość jego łamania. Po
prostu program łamie hasło na części. Dlaczego jest to możliwe
również jest wyjaśnione w rozdziale trzecim - "Sposób
przechowywania haseł". Dodam na koniec, że w każdym
momencie możemy przerwać łamanie opcja "Tools->Stop
Crack", a po chwili je kontynuować lub korzystając z opcji "File-
>Save/Save as..." zapisać nasza sesje i wrócić do niej innym
razem, gdyż stworzymy tym sposobem plik "jakąś nazwa.lc", w
którym to zostaną zapisane dane dotyczące naszej sesji, co
więcej nie musimy się nawet tym za bardzo martwic, bo co ileś
minut (tak na wszelki wypadek) program zapisuje nasza sesje do
właśnie takiego pliku. Pliki .lc otwieramy tak samo jak pliki z
hashami. Nie wolno nam zmienić ustawień sesji, np. rodzaju
ataków lub szukanych znaków bo program zacznie łamanie od
początku. Teraz tylko włączamy "Tools->Run Crack" i idziemy
obejrzeć jakiś film, zjeść śniadanie/obiad/kolacje, do znajomych
lub spać. W każdym razie musimy dać komputerowi trochę
czasu, gdyż już niedługo wszystkie hasła z serwera będą

czasu, gdyż już niedługo wszystkie hasła z serwera będą
nasze:)))

8. Game Over
No myślę, że nawet ktoś, kto nie miał wcześniej pojęcia o
windowsowskich hasłach po przeczytaniu tego tekstu uzna, że
chyba lepiej zmienić system na linuxa. Wydaje mi się, że w
windowsie najgorsze nie jest to, że do swoich systemów
wypuszcza on około 50 patchy rocznie, a z tego przynajmniej
część o charakterze krytycznym, a jego zabezpieczenia (np.
hasła) pozostawiają wiele do życzenie, ale to, że Microsoft
traktuje swoich klientów, w pewnym sensie, jak idiotów. Jeśli
wykryje on jakąś dziurę w swoich systemach (np. Microsoft
ASN.1 Library Length Overflow Heap Corruption), to doda tylko
jakąś łatę w ServicePacku, a nowsze wersje systemów będę jej
pozbawione, ale użytkownicy, o tej dziurze nigdy się nie
dowiedzą. Ale najgorsza jest chyba, zarozumiałość tej firmy. Na
swoich stronach informuje nas jedynie, iż patch X likwidujący
lukę Y to tylko latka, której niezainstalowanie może spowodować
problemy z zabezpieczeniami. Ja uważam, że podstawa
bezpieczeństwa, jest to iż, Administrator powinien mieć pełna
wiedze o systemie, którego używa, powinien być w stanie (bez
znajomości języka niższego poziomu) sprawdzić swój system,
ocenić jego słabe strony, mięć pełna kontrole nad serwisami,
które uruchamia. W Windowsie natomiast dostajemy w prezencie
domyślnie wiele serwisów, a wyłączenie ich wszystkich zajmie
nam trochę czasu. Podczas, gdy np. Mandrake bez naszego
życzenia nic nam takiego nie zainstaluje, a nawet jeśli sami
zdecydujemy się na instalacje np. demona Apache, to
zostaniemy ostrzeżeni piec razy, iż może to być niebezpieczne, a
co chyba najprzyjemniejsze kod źródłowy jak żubr jest "tuz za
rogiem" Podsumowując w Windowsie najgorszy nie jest sam
Windows,ale Microsoft. Ten system może stać się w miarę
bezpieczny, (przynajmniej dla użytku domowego) ale jest to zbyt
trudne dla normalnego usera, oczywiście na tym polu Linux tez
nie jest doskonały, ale zmierza w dobrym kierunku, podczas gdy
Microsoft zamiast informować użytkownika o wszystkim, stara
się jak najwięcej przed nim ukryć. Komercjalizacja i monopol
jeszcze nigdy nie były źródłem dobrych rozwiązań. Mimo, iż teraz
rynek komputerów osobistych jest zdominowany przez
Windowsy, to uważam, że w tej batalii zwycięstwo prędzej, czy
później odniesie Linux. No to jeśli chodzi o hasła, to już koniec
gry. Morał z tej bajki jest taki: Czego by komercyjny Bill Gates z
całym jego Microsoftem nie wymyślił, to i tak to będzie za
mało:)))

9. Podsumowanie
Jestem świadom tego, iż mogą się pojawić opinie, że (conajmniej
w niektórych partiach) ten tekst jest pisany zbyt dokładnie i
pierdółkowo. Z góry powiem, że zgadzam się z tymi słowami, ale
chciałem napisać go tak, żeby każdy załapał, jak najbardziej
łopatologicznie, po prostu jak krowie na rowie:)))