Ciekawi mnie, w jaki sposób można znaleźć nieudokumentowane interfejsy API w systemie Windows.Znajdowanie nieudokumentowanych interfejsów API w systemie Windows
Znam ryzyko związane z ich używaniem, ale pytanie to koncentruje się na ich odnalezieniu, a nie na tym, czy należy z nich korzystać, czy nie.
Użyj narzędzia do zrzutu tabeli eksportowej z udostępnionej biblioteki (na przykład .dll, takich jak kernel32.dll). Zobaczysz nazwane punkty wejścia i/lub porządkowe punkty wejścia. Zasadniczo dla okien nazwane punkty wejścia są niezwiązane (zewnętrzne "C"). Najprawdopodobniej będziesz musiał wykonać pewne zerknięcie na kod zespołu i wyprowadzić parametry (typy, liczby, kolejność, konwencje wywoływania itp.) Z ramki stosu (jeśli taka istnieje) i zarejestrować użycie. Jeśli nie ma ramki stosu, jest to trochę trudniejsze, ale wciąż możliwe do wykonania. Zobacz poniższe linki o referencje:
odjazdu narzędzia takie jak dumpbin dla zbadania sekcje eksportowe.
Istnieją także strony i książki, które obecnie nie starają się zachować zaktualizowaną listę nielegalnych Windows API:
Edytuj: Te same zasady działają na wielu systemach operacyjnych, ale trzeba zastąpić narzędzie, którego używasz do zrzutu tabeli eksportu. Na przykład w systemie Linux można użyć nm, aby zrzucić plik obiektowy i wyświetlić jego sekcję eksportu (między innymi). Można także użyć wartości gdb, aby ustawić punkty przerwania i przejść przez kod zespołu punktu wejścia, aby określić, jakie argumenty powinny być.
Sprawdź biblioteki systemowe i funkcje, które eksportują. Każda funkcja API, niezależnie od tego, czy jest udokumentowana czy nie, jest eksportowana do jednego z nich (użytkownik, jądro, ...).
Dla interfejsów użytkownika w trybie użytkownika można otworzyć plik Kernel32.dll User32.dll Gdi32.dll, w szczególności ntdll.dll w dependancy walker i znaleźć wszystkie wyeksportowane interfejsy API. Ale nie będziesz miał dokumentacji z wykształcenia.
Wystarczy znaleźć dobry artykuł na Native APIS Mark Russinovichem
IDA Pro to Twój najlepszy zakład, ale pod numerem proszę podwoić proszę w rzeczywistości nie używać ich do niczego.
Są wewnętrzne, ponieważ się zmieniają; mogą (i robią) nawet zmienić w wyniku Hotfix, więc nie można nawet zagwarantować, że nieudokumentowane API będzie działać dla konkretnej wersji systemu operacyjnego i poziomu Service Pack, dla którego została napisana. Jeśli wysyłasz taki produkt, żyjesz w pożyczonym czasie.
A jeśli jesteś kimś, kto ma na nie wpływ, Microsoft musi je utrzymać na zawsze, ponieważ jeśli tego nie zrobią, oprogramowanie Crap Inc złamie się, a nieuczciwy użytkownik będzie krzyczeć o tym, jak Microsoft jest do bani, a Apple jest świetny. – Josh
Nawet nie musisz być tym wpływowym - pewnego dnia możesz otworzyć bazę danych aplikacji AppCompat, mamy aplikacje takie jak Disney Timon i Puumba Dowiedz się, jak pisać tam –
Tak. Używam nieudokumentowanego SetConsoleFont z powodzeniem na Windows XP i Windows 7, ale nie działa na Windows 7 sp1. – carlos
Do tej pory brakowało jakiejś znaczącej funkcjonalności obejmującej bardzo nieudokumentowane części systemu operacyjnego Windows RPC. RPC (think rpcrt4.dll, lsass.exe, csrss.exe, etc ...) operacje występują bardzo często we wszystkich podsystemach, poprzez porty LPC lub inne interfejsy, ich funkcjonalność jest pochowana w mistycznych inkantacjach różnych typów/podtypów/struct-typedef etc ... które są znacznie trudniejsze do debugowania, ze względu na asynchroniczną naturę lub fakt, że są one przeznaczone dla procesu, które gdybyś miał debugować za pomocą pojedynczego kroku lub tego, co ty, znalazłbyś cały system blokowanie z powodu zablokowania klawiatury lub innych operacji wejścia/wyjścia;)
ReactOS to prawdopodobnie najbardziej celowy sposób na zbadanie nieudokumentowanego API. Mają dość dojrzałe jądro i inne wbudowane sterowniki. IDA jest dość czasochłonna i jest mało prawdopodobne, że znajdziecie coś, czego jeszcze nie mieli ludzie ReactOS.
Oto blurb z połączonej strony;
ReactOS® to darmowa nowoczesny system operacyjny na podstawie projektu Windows® XP/2003. Całkowicie napisany od , ma na celu postępować zgodnie z architekturą Windows® zaprojektowaną przez Microsoft z poziomu sprzętu aż do poziomu aplikacji . To nie jest oparty na systemie Linux system i nie ma żadnej architektury unix .
Głównym celem projektu ReactOS jest dostarczenie systemu operacyjnego , który jest binarny kompatybilny z Windows. To spowoduje, że Twoje aplikacje Windows i sterowniki będą działać tak samo, jak w systemie Windows . Ponadto, zastosowano wygląd systemu Windows 2000 i odpowiadający systemowi operacyjnemu Windows , tak aby ludzie przyzwyczajeni do znanego użytkownika interfejsu systemu Windows® mogliby znaleźć prosty sposób na użyciu ReactOS . Ostatecznym celem ReactOS jest umożliwienie użytkownikowi usunięcia systemu Windows® i zainstalowania ReactOS ReutOS bez zauważenia przez użytkownika końcowego zmiany .
Kiedy badam niektóre rzadko spotykane konstrukcje systemu Windows, ReactOS jest często jedynym wiarygodnym odnośnikiem.
Och, więc jeśli spróbujesz ręcznie odwrócić inżynier systemu operacyjnego, powinieneś zbadać użyteczność IDL i dowiedzieć się, jak zlokalizować IDL osadzone w DLL, wyodrębnić lokalizację metod implementacji. Zobacz także http://en.wikipedia.org/wiki/MSRPC dla niektórych bardziej przyzwoitych punktów początkowych. – RandomNickName42
-1 złe pytanie: to * nigdy * dobry pomysł, aby korzystać z nieudokumentowanych API; są nieudokumentowane z jakiegoś powodu, a ryzyko nie jest dla ciebie, ale raczej dla twojego dostawcy systemu operacyjnego (jeśli w ogóle zależy im na aplikacji). –
+1 nie jest złe pytanie. Nie ma nic złego w szturchaniu wewnętrznych elementów systemu operacyjnego lub czegokolwiek innego. Ciekawość to dobra rzecz. Po prostu nie polegaj na nieudokumentowanym zachowaniu. –