Witam,
jak zwykle mam problem z sufitu wzięty, ale zna ktoś może jakiś sposób na pobranie rejestru z obcej aplikacji (konkretnie ciekawi mnie esp:ip)?
Przy czym zależałoby mi na rozwiązaniu bez użycia hooka (jakaś funkcja Win? - wątpię, ale może ktoś się spotkał), byłoby ładniej i nie tak inwazyjnie.
Jeśli nie ma/jest ale bezsensowny to niech ktoś po prostu napisze, będę wdzięczny [soczek] .
MSM napisał(a)
jak zwykle mam problem z sufitu wzięty, ale zna ktoś może jakiś sposób na pobranie rejestru z obcej aplikacji (konkretnie ciekawi mnie esp:ip)?
Chyba cs:eip... Jak? Bierzesz uchwyt do wątku (enum albo powiedzmy GetWindowThreadProcessId), OpenProcess, SuspendThraed, GetThreadContext, ResumeThread, CloseHandle... cała filozofia.
Aha, jeszcze GetThreadSelectorEntry może się przydać coby potem przeliczyć początek segmentu na 'płaski' adres w przestrzeni adresowej.
Chyba cs:eip... Jak? Bierzesz uchwyt do wątku (enum albo powiedzmy GetWindowThreadProcessId), OpenProcess, SuspendThraed, GetThreadContext, ResumeThread, CloseHandle... cała filozofia.
(jak zwykle) Nie wiem co mi wpadło do głowy z tymi rejestrami, ale podziwiam domyślność żeby domyślić się dwóch błędnych nazw.
(I pomyśleć że naprawdę byłem gotowy zakładać tego hooka...)
Dzięki za szybką odpowiedź, krótki research na MSDN daje nadzieję że o to mi chodziło.
Co wy tak staroświecko przypisujecie rejestry do segmentów? Jakim prawem EIP jest uzależniony od CS? Przecież mamy płaską pamięć w której rejestry są w stanie zaadresować dowolną komórkę z 32-bitowej szyny adresu, a segmentów używamy tylko z konieczności indeksowania jakiegoś bloku pamięci (np. TEB) którego liniowy adres nikogo nie powinien obchodzić.
Sami sprawdźcie co się stanie przy adresowaniu mov eax,[cs:offset] pod kontrolą 32-bitowego windowsa.
Podobnie ESP w disassemblerach jest błędnie przypisywany do SS, a dane do DS, chociaż opcode wcale nie zawiera informacji o rejestrze segmentu. Nostalgia nikogo nie usprawiedliwia, a nauka pojęć assemblera z kursów powstałych z nostalgii lub z zasłyszanych plotek, jest warta potępienia.
Jeżeli ktoś poczuł się obrażony, to niech się pocieszy faktem że nawet fachowcy z firmy Microsoft robią takie błędy: jeżeli segment nie jest znany, to wyświetlimy domyślny segment, pomimo tego że domyślny jest NULL segment.
sapero napisał(a)
Jakim prawem EIP jest uzależniony od CS? Przecież mamy płaską pamięć w której rejestry są w stanie zaadresować dowolną komórkę z 32-bitowej szyny adresu, a segmentów używamy tylko z konieczności indeksowania jakiegoś bloku pamięci (np. TEB) którego liniowy adres nikogo nie powinien obchodzić.
Takim prawem, że procesor wykonuje instrukcje via cs:eip, nie 'samo' eip. Poza tym podałem GetThreadSelectorEntry właśnie ze względu na TEB. Nikogo nie powinien adres bazowy FS obchodzić? No ciekawe, bo ja sobie bez tego głębszego grzebania w aplikacjach po prostu nie wyobrażam...
sapero napisał(a)
Sami sprawdźcie co się stanie przy adresowaniu mov eax,[cs:offset] pod kontrolą 32-bitowego windowsa.
Tylko dlatego, że selektory mają ten sam adres bazowy i limit...
sapero napisał(a)
Podobnie ESP w disassemblerach jest błędnie przypisywany do SS, a dane do DS, chociaż opcode wcale nie zawiera informacji o rejestrze segmentu.
Błędnie? Podobno bezpośrednie operacje na stosie domyślnie łapią segment SS zaś 'zwykłe' DS i ew. ES (stringi)...
sapero napisał(a)
Jeżeli ktoś poczuł się obrażony, to niech się pocieszy faktem że nawet fachowcy z firmy Microsoft robią takie błędy: jeżeli segment nie jest znany, to wyświetlimy domyślny segment, pomimo tego że domyślny jest NULL segment.
Nie przesadzaj, wspomniany TEB idzie przez FS, jego adres bazowy trzeba ustalić.
Poza tym segmenty w Windows są ważne, czasem się w abuse przydają ];->
sapero napisał(a)
Przecież mamy płaską pamięć
Ta płaska pamięć bierze się stąd, że segmenty mają poustawiany zerowy adres bazowy i maksymalny limit. Czyli tak jakby ich nie było. Ale segmenty mają więcej parametrów oprócz tych dwóch, i są one nadal brane pod uwagę.
Podobnie ESP w disassemblerach jest błędnie przypisywany do SS, a dane do DS, chociaż opcode wcale nie zawiera informacji o rejestrze segmentu.
Ależ zawiera. Jeśli instrukcja jawnie nie zawiera prefiksu segment override, to zakładany jest domyślnie segment cs dla kodu, ds dla danych i ss dla stosu.
To, że są one zrównane do liniowej adresacji w tablicy deskryptorów, nie znaczy że nie działają.
Oczywiście mowa o trybie 16- i 32-bitowym. W 64 bitach jest inaczej.
pomimo tego że domyślny jest NULL segment
Nie ma czegoś takiego.