background image

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 

background image

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 

background image

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 

background image

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 

background image

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ą 

background image

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