bootkey

[oneat]

Gdzie moge znalesc w winie bootkey

[Mandr4ke]

Zmieniłem bo chyba nie o to Ci kaman....

Albo tak.... Napisz o który Ci chodzi... Bootkey-i to może byc ze 4 jak nie więcej...

1. http://www.brothersoft.com/bootkey-178944.html
2. http://www.techsupportforum.com/micr...o-bootkey.html
3. http://www.cybertech.net.pl/online/s...it/poledit.htm



-,-

[oneat]

Bootkey potrzebuje do lamania SAMa

[Mandr4ke]

Sposob przechowywania hasel

W systemach Windows95/98/Me hasla przechowywane sa w plikach .pwl, ale
poniewaz nie sa one w zaden sposob chronione a programow do ich lamania
jest cale mnostwo (chocby slynny cain) to w tym tekscie skupie sie
tylko na systemach z serii NT czyli Winodws NT/2k/XP/Server 2003.
Otoz w tych systemach hasla przechowywane sa w pliku SAM znajdujacym
sie (pod warunkiem,ze windows zostal 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), mozna go
zreszta przegladac za pomoca edytora rejstru, ale wymaga to uzycia
kilku sztuczek i jest calkowicie bezcelowe. Podczas bootowania
windowsa zanim uzytkownik moze w ogole sie zalogowac do systemu
glowny watek programu Smss.exe (Session Manager - Menedzer Sesji)
uruchamia proces Winlogon.exe, gdyz jest on potrzebny by zaladowac
Lsass.exe (Local Security Subsystem - Lokalny Podsystem
Bezpieczenstwa), ktory nastepnie laduje usluge SAM (Security Accounts
Manager - Menedzer Kont Bezpieczenstwa), ktory jest po prosu
interfejsem dajacym nam dostep do bazy danych SAM. Plik SAM nie
przechowywuje jednak samych hasel a jedynie ich hashe, czyli wyniki
dzialania jednostronnego (czyli nieodwracalnego) algorytmu
szyfrujacego na haslach. Kiedy ktos loguje sie na komputer haslo,
ktore wpisal zostaje zaszyfrowane w ten sam sposob, a wynik (czyli
hash) jest porownywany z hashem z pliku SAM i jesli sa takie same
uzytkownik uzyskuje dostep do systemu. Kazde haslo jest przechowywane
na dwa sposoby jako LM hash i jako NT hash, podczas gdy, NT hash jest
hashem naszego hasla to LM hash jest hashem naszego hasla pisanego
duzymi literami. Oznacza to, ze dla hasel: "Haselko","hAsElko",
HaSeLkO",itp NT hash bedzie inny, ale LM hash bedzie taki sam!!!
Nie musze chyba tulmaczyc, jak uzyteczne jest to dla nas. Mozliwe
jest jednak wylaczenie przez admina LM hashy i konieczne w takim
wypadku jest lamanie NT hashy, co znacznie utrudnia sprawe.
Na szczescie zdaza sie to rzadko, a poza tym jesli juz sie zdazy,
to lamanie hashy nie jest wtedy najlepszym pomyslem, wiec w tym
tutorialu takiej sytuacji nie zamierzam rozwazac. Oczywiscie
nie zalogujemy sie do systemu uzywajac hasla zdobytego lamaniem LM
hash (chyba, ze haslo orginalne tez nie skladalo sie z malych liter).
Jesli jednak dowiedzielibysmy sie, ze nasz LM hash odpowiada np. haslu
"HASELKO", to sprawdzenie kombinacji malych i duzych liter bedzie juz
tylko formalnoscia (i tak wlasnie robia programy lamiace LM hashe).
Hasla w systemach WinNT nie moga byc dluzsze nizeli 14 znakow,
juz Win2k dopuszcza dluzsze hasla (do 128 znakow), ale spojrzmy
prawdzie w oczy,chyba nikt nie uzywa takich hasel Dlatego w tym
teksice omowie jedynie sytuacje gdy, haslo ma dlugosc mniejsza
lub rowna 14 znakow. Nie testowalem jeszcze Windowsa Server 2003,
ale o ile mi wiadomo jesli chodzi o hasla to dziala on na tej samej
zasadzie co XP. Zarowno LM hash jak NT hash zajmuja 16 bajtow ja jednak
skupie sie tylko na LM hashu,(dlaczego? Patrz wyzej) Otoz jego
pierwsze osiem bajtow odpowiada pierwszym siedmiu znakom hasla,
a drugie osiem bajtow drugim siedmiu znakom hasla. Jesli haslo
jest krotsze niz 14 znakow, np. 10, to znowu pierwsze osiem bajtow
hashu odpowia pierwszym siedmiu literom naszego hasla, a pozostale
osiem bajtow odpowiada pozostalym literom naszego hasla. Jesli jednak
haslo ma dlugosc krotsza lub rowna 7 znakow, to po raz trzeci pierwsze
osiem bajtow hashu odpowiada literom hasla, a drugie osiem bajtow
bedzie w tym przypadku zawsze rowne 0xAAD3B435B51404EE. Jesli
dane konto w ogole nie posiada hasla, czy raczej posiada haslo
zerowej dlugosci, to obie czesci hashu przyjmuja ta wartsosc.
Czyli hash wyglada tak:0xAAD3B435B51404EEAAD3B435B51404EE.

Zdobywanie hashy

Hashe mozna zdobyc (lokalnie) na dwa sposoby. Pierwszy polega na
uzyciu progaramu pwdump. Wlaczamy jedynie progaram, a on wyswietla
nam w oknie konsoli hashe. Jesli wywolamy go ze znakiem
przekierowania, czyli '>', np. "pwdump.exe >hash.txt". To nasze hashe
zostana zapisane do pliku hash.txt. Jesli uzyjemy jako parametr
podamy adres jakiegos komputera np. "pwdump.exe 127.0.0.1",
"pwdump.exe \\127.0.0.1" lub "pwdump www.microsoft.com")) To pwdump
sprobuje sie polaczyc z tym komputerem i jesli udostepnia on zdalnie
swoj rejestr, to pwdump sciagnie z niego hashe. Niestety duzym
minusem tego programu jest to, iz jest on z gory ustawiony na
wyciaganie hashy z systemow anglojezycznych. Dzieje sie tak, gdyz
zaklada on, iz grupa Administratorow ma angielska nazwe
"Administrators", na szczescie program nie jest ani szyfrowany, ani
spakowany (np. aspackiem, no przynajmniej wersja, ktora ja posiadam).
Dodatkowo za tekstem "Administrators" znajduja sie dwa bajty zerowe,
podczas, gdy w operacjach na tablicach znakow (tzn. tekstach) wymagany
jest tylko jeden. Mozemy wiec smialo zmienic 's' na 'z', a pierwsze
zero na 'y' i juz mamy tekst "Administratorzy", a pwdump dziala))
Jest to bardzo prosta operacja edytorem szesnastkowym, wiec nie bede
wdawal sie w szczegoly. Drugi sposob polega na wykorzystaniu
programu samdump. Program jest w stanie wydobyc hasla bezposrednio
z pliku SAM. Wystarczy wiec skopiowac ten plik z jakiegos komputera
na dyskietke i spokojnie w domciu uzyc samdumpa z tym plikiem jako
parametrem np. "sampdump.exe a:\SAM". Jest tylko jeden maly problem.
Plik SAM jest chroniony przez system i zaden uzytkownik nie ma
do niego bezposredniego dostepu takze wszelkie proby jego odczytu,
lub kopiowania zakoncza sie niepowodzeniem. Na szczescie Windows
w wielu sytuacjach (np. przy instalacji) tworzy kopie tego pliku
i znajduje sie ona (pod warunkiem,ze windows zostal zainstalowany
w C:\WINNT) w katalogu C:\WINNT\repair. Co wiecej nie tylko czlonkowie
grupy Administratorzy (zazwyczah), ale wszyscy uzytkownicy maja prawo
do odczytu i kopiowania tego pliku. Moze sie jednak zdarzyc
(a bardzo czesto tak wlasnie jest), ze dane zawarte w tym pliku
sa nieaktualne. W takim wypadku pozstaja nam dwa wyjscia.
Po pierwsze mozemy uruchomic linucha jesli taki jest w komputerze
lub skorzystac z jakiejs mini dystrybujcji dyskietkowej badz
pelnej plytowej np. KNOPPIX. To rozwiazanie ma jeszcze jeden plus.
Linux bez problemu czyta zarowno partycje FAT32 jak i NTFS, ale zdaje
sobie sprawe, ze wielu ludzi jest z linuchem na bakier wiec dla nich
wytulmacze inny sposob. Uruchamiamy komputer w trybie MS-DOS
(np. korzystajac z dysku startowego Win98). Jesli system, z ktorego
chcemy wyciagnac hashe zostal zainstalowany na partycji FAT32 to bez
problemu odnajdujemy katalog C:\WINNT\system32\config i rownie
bezproblemowo kopiujemy z niego plik SAM. Jesli natomiast dany
system zostal zainstalowany na partycji NTFS, no to mamy problem,
gdyz MS-DOS nie rozpoznaje tego systemu plikow (NTFS), wiec nie
bedziemy mieli dostepu do tej partycji. W takim przypadku najlepszym
rozwiazaniem jest uzycie programu ntfsdos. Postepujemy tak jak
w przypadku partycji FAT32, jednakze pierwsza rzecza jaka robimy
po uruchomieniu MS-DOS'a jest uruchomienie programu ntfsdos poprzez
wpisanie po prostu "ntfsdos.exe", no jak ktos sie uprze to moze
sobie darowac koncowke ".exe". Nastepnie ntfsdos poszuka wszystkich
partycji NTFS i po koleji zamontuje je nam jako normalne dyski
MS-DOS. Wersja publicznie dostepna pozwala jedynie na odczyt
partycji NTFS, ale akurat nam to w stu procentach wystarcza.
Niestety zarowno program pwdump jak i samdump nie dadza nam
poprawnych hashy jesli system ma SYSKEY'a.

[Mandr4ke]

Co to jest SYSKEY

Otoz Microsoft zrozumial, ze jak zwykle strzelil babola i poszedl
po rozum do glowy. Bardzo szybko wprowadzil na rynek poprawki
sprawiajace, iz tylko czlonkowie grupy "Administratorzy" maja prawo
odczytu calosci rejestru, a wiec rowniez hashy. Program pwdump
stal sie wiec bezuzyteczny. A co gorsza dodatek Service Pack 3
(a co za tym idzie kazdy nastepny (bylo ich w sumie 6)) do
Windows NT wprowadzil aplikacje SYSKEY, potem juz Windows 2000,
Windows XP i Windows Server 2003 mialy ta aplikacje instalowana
domyslnie. SYSKEY jest to skrot od System Key, czyli klucz systemu
zwany rowniez Bootkey'em. Aplikacja ta tworzy podczas instalacji
unikalny dla kazdego systemu klucz, ktorym dla dodatkowego
bezpieczenstwa szyfrowane sa hashe. Nie chce sie wdawac w szczegoly,
gdyz mysle, ze sa one zbedne, ale dla ciekawskich podam ze jest
to robione za pomoca algorytmow MD5 i RC4. Zeby bylo jeszcze
ciekawiej klucz ten jest wybierany losowo i nawet ten sam Windows
instalowany na tym samym komputerze bedzie mial za kazdym razem
inny klucz. Czyzby to mial byc juz koniec?

Jak poradzic sobie z SYSKEY'em

Fakt faktem, ale ta zniewaga krwi wymaga A moze raczej powinienem
powiedziec wymagala, gdyz na stworzeniu przez Microsoft SYSKEY'a ta
bajka sie nie konczy. Otoz hackerzy z calego swiata postanowili go
rozwalic powstawaly rozne pomysly, miedzy innymi slynna juz
linuxowska dyskietka, ktora potrafila nawet wylaczyc SYSKEY'a. Jednak
kazdy kto ja przetestuje szybko zauwazy, ze do doskonalosci "troche"
jej brakuje, wiec w tym tekscie nie bede jej omawial. Pierszym
prawdziwym zwyciestwem bylo stworzenie programu pwdump2. Dziala
on analogicznie do swojej poprzedniej wersji, ale tylko na lokalnym
komputerze. Wykorzystuje on fakt iz SYSKEY'a mozna obejsc, a co za
tym idzie zdobyc czyste hashe za pomoca pewnych wywolan API ale
tylko jesli jest sie aplikacja lsass.exe, ktora to wlasnie zarzadza
haslami, kontami itp. pwdump2 tworzy wiec "zdalny" watek w lsass.exe,
a ten watek laduje biblioteke samdump.dll (dostarczana wraz z pwdump2),
ktora to wlasnie omija (jako lsass.exe) SYSKEY'a i odczytuje nasze
upragnione hashe. Program pwdump2 ma tylko jedna wade. Poniewaz
manipuluje on pamiecia (nie chce sie wdawac w szczegoly) lsass.exe
musi wiec posiadac przywilej debugowania tzw. SeDebugPrivilege, zadna
aplikacja nie moze "otworzyc" procesu o atrybucie systemowym (a takim
przeciez jest lsass.exe) bez tego przywileju. Tutaj wlasnie
pojawia sie problem, gdyz ten przywilej maja sobie (tzn. programom,
ktore uruchamiaja) prawo przyznac tylko czlonkowie grupy
"Administratorzy" Wiec nam (przynajmniej w wiekszosci przypadkow)
sie to w ogole nie przyda. Warty zainteresowania jest rowniez program
pwdump3 pozwala nam on na zdobycie hashy ze zdalnego komputera dzieje
sie to nastepujaco program laczy sie serwerem za pomoca protokolu SMB
jesli mu sie to nie uda tzn., ze z naszego komputera jeszcze zaden
uzytkownik posiadajacy na atakowanym serwerze uprawnienia
Administratora nie laczyl sie z tym serwerem lub po prostu serwer nie
udostepnia w ogole protokolu SMB, ale on jest domyslnie wlaczany gdy
konfiguruje sie w Windowsie siec wiec nie mamy sie o co bac
Przykladowo mozemy program pwdump3 wywolac tak:
"pwdump3 127.0.0.1 hash.txt Administrator" i prosi o haslo uzytkownika.
po polaczeniu wysyla na serwer pliki LsaExt.dll i pwservice.exe. I
nastepnie zdalnie uruchamia program pwservice.exe, ktory robi
z biblioteka LsaExt.dll prawie to samo co pwdump2 robil z samdump.dll.
Znowu jednak pojawia sie problem znajomosci przynajmniej jednego hasla
Administratora, nie mniej jednak sam projekt jest ciekawy. Wspomne
jeszcze, ze istnieje program pwdump4, ktory jest jakby polaczeniem
pwdump2 i pwdump3, nie bede go wiec opisywal, podam jedynie jak
dla przykladu go uzyc:"pwdump4 /l" - to samo co pwdump2,
"pwdump4 127.0.0.1 /u:Administrator" - to samo co pwdump3. Dopiero
jakis rok temu programistom udalo sie calkowicie zlamac SYSKEY'a,
a to za sprawa aplikacji samdump2, bkhive i bkreg. Z tych trzech
praktycznie najmniej uzyteczna jest aplikacja bkreg. Odczytuje ona
klucz systemu (tzw. Bootkey) z rejestru, a co za tym idzie,
dziala tylko uruchamiana (za wyjatkiem niektorych
wersji systemu Windows NT) przez czlonkow grupy "Administratorzy".
bkhive natomiast wyciaga klucz systemu z pliku system, ktory mozna
znalezc wszedzie tam gdzie plik SAM. Bkreg uruchamia sie np. tak:
"bkreg key.txt". W tym momencie w pliku plik key.txt w formacie hex
zostaje zapisany klucz systemu. Bkhive natomast nastepujaco:
"bkhive jakaslokacja\system key.txt" i znowu mamy Bootkeya w pliku
key.txt. Nastepnie korzystamy z programu samdump2, ktory jako
parametry wykorzystuje wlasnie plik SAM i jakis plik z naszym
Bootkeyem, czyli np: "samdump2 SAM key.txt". Nie bede tulmaczyl,
jak zdobyc plik system, gdyz jak juz powiedzialem, jest on wszedzie
tam, gdzie plik SAM, a jego zdobywanie zostalo bardzo szczegolowo
wyjasnione w rozdziale czwartym - "Zdobywanie hashy", w czesci
poswieconej aplikacji samdump. Na koniec dodam tylko, ze
pierwsze wersje czasami (ale to naprawde sporadycznie)
nie potrafily odczytac pliku SAM, ale autor bardzo szybko
sobie z tym poradzil i teraz program dziala bez zarzutu.
Przynajmniej ja nie mialem z nim zadnego problemu.
I tym optymistycznym akcentem mamy gdzies SYSKEY'a, a Bill Gates
z calym jego beznadziejnym Microsoftem moze sie wypchac))

[Mandr4ke]

Lamanie hasel

No wreszcie mamy juz te hashe no i co my z nimi mozemy zrobic?
Otoz hashe sa zaszyfrowane algorytmem jednostronnym, a co za tym
idzie nie wydobedziemy z nich w zaden sposob hasel. No tak ale
mozemy sami cos szyfrowac np. rozne slowa i sprawdzac, czy nasz
hash nie odpowiada temu z pliku. I to wlasnie robia lamacze
tych hashy. Najlepiej wykorzystac program L0phtCrack. Ostatnia
wersja, ktora posiadam, to 5 cos, ale ja skupie sie na wersji 2.5,
gdyz po pierwsze ma bardzo prosty i czytleny interfejs, podczas,
gdy 3,4 i 5 maja nacpane mnostwo jakis rysunkow i innych pierdol,
co mnie osobiscie niesamowicie wnerwia, ale to jest wynikiem
prostego faktu. Wersja 2.5 byla jeszcze tworzona przez grupe
l0pht, potem jednak sprzedali oni prawa do programu i teraz
kolejne wersje sa tworzone przez prywatna firme. I tu pojawia
sie drugi powod, dla ktorego wole 2.5 - sentyment Dlatego
w tym rozdziale omowie wlasnie opcje tej wersji. Uzywanie opcji
"Tools->Dump Passwords from Registry", lub "File->Import SAM
File...", jest bezcelowe gdyz sa to kolejno odpowiedniki
programow pwdump i samdump, a my prawie na pewno mamy
do czynienia z SYSKEY'em najlepiej jest po prostu otworzyc
plik stworzony przez program pwdump2,pwdump3,pwdump4 lub samdump2
za pomoca opcji: "File->Open Password File" Teraz najwazniejsza
rzecz to przede wszystkim skonfigurowac program wybieramy
plik slownika: "File->Open WordList File..." Domyslnie program
dostarcza nam plik words-english.dic. Po drugie ustawiamy metode
szukania: "Tools->Options..." zaznaczamy w polu
"Dictionanry Attacks" (czyli ataki slownikowe) tylko opcje LANMAN,
dlaczego tak robimy zostalo wyjasnione w rozdziale
trzecim - "Sposob przechowywania hasel", w polu "Dictionary/Brute
Hybrid" zaznaczamy "Enabled" i zostawiamy (lub jesli jej tam
nie ma wpisujemy) dwojke w polu "Characters". Teraz program
sprawdzi wszystkie slowa ze slownika (tak na marginesie, na
koncu tego slownika dobrze jest dopisac juz wczesniej zlamane hasla,
gdyz moze to nam w przyszlosci oszczedzic troche czasu), a dodatkowo
sprawdzi kazde slowo ze slownika z jeszcze dwoma znakami. Oznacza
to, ze np. jesli dodamy do slownika slowo Karol, to w ciagu paru
sekund program sprawdzi, czy haslem nie jest np.: "Karol12","Karolfg",
"Karol98","Karol7z",itd. I ostatnia opcja w polu "Brute Force Attack"
zaznaczamy "Enabled" i teraz sa dwie drogi albo od razu ustawiamy
opcje "Character Set:" na "A-Z,0-9", i program sprawdzi, wszystkie
hasla literowo-cyfrowe(ustawianie wiekszej ilosci znakow jest
w wiekszosci wypadkow bezcelowe, a poza tym za dlugo by to trwalo).
Lub tez mozemy ustawic program tylko na opcje "A-Z", a dopiero jesliona zawiedzie sprobojemy "A-Z,0-9". W glownym oknie programu mysle, ze
wszystkie kolumny sa proste do zrozumienia dodam tylko, ze jesli przy
ktoryms z uzytkownikow w kolumnie "<8" jest x, to oznacza to, iz jego
haslo ma mniej niz 8 znakow, a jak program to okreslil mozna wyczytac
w rozdziale trzecim - "Sposob przechowywania hasel". Niestety
wersja 2.5 ma z tym problemy, ale wersje 3,4 i 5 radza sobie
bezproblemowo. A dokladnie sek w tym, ze wersja 2.5 sprawdza
nasze hashe zakladajac, ze sa one zapisane duzymi literami
(hashe nie hasla), natomiast programy: pwdump2,pwdump3,
i samdump2 w przeciwienstwie do aplikacji pwdump (pwdump4 rowniez)
i samdump nie zwracaja hashy duzymi literami, lecz malymi.
Dla ciekawskich dodam, ze porownywanie to ma miejsce (dla wersji 2.5)
pod adresami 0x4048e7 oraz 0x404dde najlepszym rozwiazaniem
(poza zmiana wersji) jest dodanie w programie procedury sprawdzania
hashy rowniez malymi literami. Na szczescie np. pod adresem 0x404ecc
kompilator pozostawil nam bardzo duzo miejsca, wiec dodania takiego
porownywania nie nastreczy nam zadnych problemow i wymaga jedynie
podstawowej znajomosci assemblera, gdyby ktos jednak mial problemy,
lub po prostu byl tym zainteresowany, to moge dostarczyc odpowiedniego
patcha. Co najciekawsze dlugosc hasla nie ma praktycznie wplywu na
predkosc jego lamania. Po prostu program lamie haslo na czesci.
Dlaczego jest to mozliwe rowniez jest wyjasnione w rozdziale
trzecim - "Sposob przechowywania hasel". Dodam na koniec, ze w kazdym
momencie mozemy przerwac lamanie opcja "Tools->Stop Crack",
a po chwili je kontynowac lub korzystajac z opcji
"File->Save/Save as..." zapisac nasza sesje i wrocic do niej
innym razem, gdyz stworzymy tym sposobem plik "jakas nazwa.lc",
w ktorym to zostana zapisane dane dotyczace naszej sesji, co wiecej
nie musimy sie nawet tym za bardzo martwic, bo co iles minut (tak
na wszelki wypadek) program zapisuje nasza sesje do wlasnie takiego
pliku. Pliki .lc otwieramy tak samo jak pliki z hashami. Nie wolno
nam zmienic ustawien sesji, np. rodzaju atakow lub szukanych znakow
bo program zacznie lamanie od poczatku. Teraz tylko wlaczamy
"Tools->Run Crack" i idziemy obejrzec jakis film, zjesc
sniadanie/obiad/kolajce, do znajomych lub spac. W kazdym
razie musimy dac komputerkowi troche czasu, gdyz juz niedlugo
wszystkie hasla z serwerka beda nasze))


<dziekuje Mandr4ke>

[oneat]

Dobra ale gdzie jest ten plik system
W windowsie duzo jest tych plikow a tak w ogole jaki ma format ?


A z druiej beczki czy jak podmienie plik system i SAM to system bedzie dzialac
Czy padnie bo trzeba zrobic cos jeszcze

[Mad_Dud]

Mandr4ke, Następnym razem podawaj źródło lub autora
http://www.haxite.org/index.php3?sit...ul_view&id=361

§ Where do I find the SAM/Hashes?

You can find what you're looking for in several locations on a given machine.

It can be found on the hard drive in the folder %systemroot%system32config. However this folder is locked to all accounts including Administrator while the machine is running. The only account that can access the SAM file during operation is the "System" account.

You may also be able to find the SAM file stored in %systemroot% epair if the NT Repair Disk Utility a.k.a. rdisk has been run and the Administrator has not removed the backed up SAM file.

The final location of the SAM or corresponding hashes can be found in the registry. It can be found under HKEY_LOCAL_MACHINESAM. This is also locked to all users, including Administrator, while the machine is in use.

So the three locations of the SAMHashes are:

- %systemroot%system32config

- %systemroot% epair (but only if rdisk has been run)

- In the registry under HKEY_LOCAL_MACHINESAM

http://www.hackinthebox.org/modules....rder=0&thold=0

[oneat]

Syskey nie sam !