Lefoglaló api-funkciók Windows NT
A rendszer programozók dolgoznak az MS DOS, emlékszik csapda lehallgatás technológia, amely lehetővé teszi, hogy átvegye az irányítást a gyakorlatilag az összes folyamat lezajlott a kedvenc operációs rendszer.
Mi az a „lehallgatást API-funkciók”
Vegyünk két módszer lehallgató API funkciók:
1. metszéspont API módszer a közvetlen belépés a kódot a rendszer működését.
A recepció a tetején az elfogott funkció írásutasítás JMP vasha_funktsiya_dvoynik vagy azzal egyenértékű. Felülírja a byte kívánatos valahol menteni. Hívása után a javított funkció alkalmazás vezérlés át fog kerülni a funkciót. Meg kell feldolgozni a verem, hogy van, távolítsa el a számukra átadott, és akkor tegye meg a szükséges intézkedéseket. Aztán, ha meg akarsz hívni az eredeti funkció, meg kell visszaállítani az elakadt byte elején az eredeti funkciót. Nevezzük, átadva a szükséges paramétereket. Miután visszatért az eredeti funkciót, meg kell ismét a tetején a funkció kód rögzíti az átmenet csapat a funkciót. Vissza a vezérlés a hívó programban.
A módszer előnye, hogy lehetővé teszi, hogy elkapjam minden olyan funkciót, nem csak azokat, amelyek szerepelnek az import táblázatban.
Hibája többszálú alkalmazások lehet a helyzet, amikor egy szál hívott el elfogott funkció kontroll adtak át a függvény-dupla, ő visszaállította az eredeti kezdési a funkció, de ezen a ponton egy párhuzamos szál tett hívást ugyanazt a funkciót. Ennek eredményeként, a vezérlés az eredeti függvényt közvetlenül, megkerülve az :(.
Nézzük egy példát egy program (a DLL-fájl) lehallgató funkció MessageBoxA 1.
Mert a munka, szükségünk van a következő fejlécek:
Megvalósítása a kódot egy másik folyamat a Windows NT
Most azt kell megmutatni, hogy a fenti DLL lehet végrehajtani egy olyan eljárásban választott, mint egy kísérlet áldozata. (Meg kell jegyezni, hogy a folyamat a sértett kell a Windows standard MessageBox üzenetküldés mi példánkban).
2. A horgokat.
végrehajtás 1
Tekintsük a leghatékonyabb, véleményünk szerint, a végrehajtás módját, - az első. Ő egy rövid szakaszon a gépi kódot a felvételi folyamat a memóriát, hogy csatlakoztassa a DLL a folyamat, futtatja a kódot, amely után a DLL bármely intézkedés nevében ezt a folyamatot. Elvileg nem tud kapcsolódni a DLL, és hajtsa végre a szükséges intézkedéseket a végrehajtási natív kód, de nem lenne túl időigényes feladat, mivel az összes korrekciós adatokat értelmetlenné válik, és nem tud megfelelő hivatkozni rájuk, nincsenek megfelelően beállítva torzítás (zavartság :( ).
Végrehajtása során ezt a módszert, meg kell mondanunk, hogy a fordító igazítsa a bájtstruktúra. Ellenkező esetben, a natív kód szerkezet tartalmaz egy teljesen rossz kódot, amelyet terveznek.
Az általános rendszer keretei:
- Nyílt eljárás (OpenProcess).
- Kiemelés az ő emlékére (VirtualAllocEx - csak a WinNT).
- Jegyezzük fel a bejuttatott kód a memóriában (WriteProcessMemory).
- Végrehajtani (CreateRemoteThread).
Által megvalósított natív kódot (a mi esetünkben), hogy ilyen lépéseket:
- hívja LoadLibrary - hívja LoadLibrary függvény kernel32.dll letöltéséhez be a könyvtár (az egyik elemzett fent).
- Hívjon ExitThread - függvényt hívja ExitThread KERNEL32.dll helyes befejezése után a patak.
Az alábbiakban egy példát eljárás végrehajtására dll meg egy nevet a folyamatot egy adott PID (process ID) (ami látható a lap „eljárások” a feladatkezelő, illetve kapott standard API-funkciók).
A bevezetése 2
A második módszer végrehajtása futtatható kódot (via horgok) a legegyszerűbb használni. Ez alapján horgok technológia, nevezetesen: ha meg a horog egy patak másik folyamat, amint a menet egy üzenet jelenik meg megfelel egy adott típusú horog, a rendszer automatikusan csatlakozik DLL c horog a folyamatban. A hátránya ennek a módszernek, hogy nem lehet beágyazni a DLL egy folyamat, amely nem rendelkezik az üzenet sorban. Ez a DLL lesz csatolva mások folyamat csak addig, amíg a program indult, amely létrehozta a horgot. Miután elvégezte ezt a programot, dll automatikusan kikapcsol. Az első módszer mentes az ilyen hibák.
Másrészt, az első módszer csak akkor működik a WinNT, mert a használat VirtualAllocEx funkció, amely fenntartja az előre meghatározott memória (eltér az, amelyben a hívás ez a funkció) folyamatban. Elméletileg ez a probléma kiküszöbölhető, ha írsz a kódot, hogy egy részének megjelenítéséhez az exe-fájlt egy másik folyamat, például a DOS fejlécet, amelyet nem használnak indítás után. De az operációs rendszer nem mindig teszi lehetővé, hogy írjon a memóriát, akkor is, ha megpróbálja megváltoztatni a engedélyekkel VirtualProtextEx.
Van egy harmadik eljárás végrehajtására, de ez a legveszélyesebb, mert ez vezethet a rendszer összeomlik. Ezzel a módszerrel, maga az operációs rendszer valósítja meg a megadott dll, hogy kivétel nélkül működő rendszer feldolgozza, sőt védett. Végrehajtásához szükséges regisztrálni a nyilvántartásban az úton HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ windows a kulcs AppInit_DLLs teljes elérési utat dll.
Hogyan keressünk hibát ilyen trükk
A legtöbb programozó debug a programok használata beágyazott hibakereső fordító. Ezek a könnyen használható, és megfelel a legtöbb követelménynek hibakeresés céljából. De ha valami kód kell végrehajtani, és végre egy másik, egy idegen folyamat beépített debugger használata nagyon nehéz. Ezekre a célokra célszerű alkalmazni a rendszert debugger SoftIce, amely tele van, mielőtt az operációs rendszer fut a nulla gyűrű és ezért hozzáférést biztosít az összes OS tárgyakat. Beszéljétek meg, hogy a hibakeresés a beágyazott kódot, amely elvégzi a lehallgatás API funkciókat egy idegen folyamatban.
Mindenféle hibakeresés osztható 3 csoportba:
- Hibakeresés bootloader-kód (assembly nyelven), amely, mivel a beültetett másik folyamat végrehajtása külön patak és tulajdonít Dll nevében a folyamatot.
- Hibakeresés funkciót végre kezdetét a dll. Általában ezt a funkciót, hogy a helyettesítés kód funkciókat API-test-funkció sebességváltó vezérlő megfelelője.
- Debug funkciók, ikrek, akik kap az irányítást a hívás elfogott az API-funkciókat.
Hibakeresés a betöltőkódját
Tehát van két folyamat:
- A folyamat, amely fecskendez kódot. Mi jelöljük P1.
- A folyamat, amely végrehajtja a kódot. P2 jelöljük.
Hibakeresés funkciót végre kezdetét a DLL
A példában ez a funkció InterceptFunctions intercpt.dll könyvtár hívott DllMain csatlakozási könyvtár és végrehajtja a folyamat lehallgatás funkciókat.
Először is meg kell fordítani a könyvtár debug információ, amely a jövőben használni SoftIce megjelenítéséhez utasításokat C. MS Visual C így történt: Projekt-> Beállítások-> C / C ++ lista Debug Info - szükség van, hogy kiválassza a típusú karakter információ - a program adatbázis szerkesztése és folytatása, valamint Projekt-> Beállítások-> link lista kategória -> hibakeresés, meg a négyzetet hibakeresési információ, és válassza ki a debug információ formátum, mint például a Microsoft formátumban.
Az alternatív -, akkor egyszerűen csak meg a projekt típusa konfiguráció, az összes paramétert debug információk automatikusan telepítésre kerül. Ez azért történik így. BuildService> Set Active Configuration -> Win32 Debug.
Most már elkezdhetjük használni SoftIce. Először le kell töltenie a hibakereső szimbólum információt a dll, míg ő még mindig betöltött dll nem. A szimbólum szükséges információkat később töréspont kódja képviselet magas szintű nyelven. Ez úgy történik, Symbol Loader segédprogram a SoftIce.
Először meg kell nyitni egy dll modult (tétel Fájl-> Megnyitás modul).
Akkor meg kell töltse be a hibakereső (Modul -> Load). A sikeres befejezése az összes ezeket a műveleteket a Symbol Loader képernyőn kell valami, mint ez:
Most folytassa a főnök. Meg kell határozni egy töréspontot InterceptFunctions funkció dll, miközben Dll még nincs csatlakoztatva a folyamatot! Fuss SoftIce. Hozzon létre egy töréspontot a szimbolikus neveket:
Hibakeresés funkciók - ikrek hívás fogadásakor menedzsment elfogott API függvények
Először le kell töltenie a szimbólum információt a lehallgatás Dll.
Ebben a példában intercpt.dll.
A közüzemi Symbol Loader válassza a Fájl-> Megnyitás modul, akkor a modulrendszerűen> Load menü, töltse be a szimbolikus információ a debugger. Dll még nem csatlakozik semmilyen folyamatot.
Továbbá, ismerve a nevét a funkciók iker meg egy töréspontot a függvény neve. Például, a funkciója a kettős Intercept_MessageBoxA, amelyet úgynevezett amikor egy kihívás történik MessageBoxA funkciója a program. Mi meg a töréspont rajta - írja a hibakereső ablakban: BPX Intercept_MessageBoxA.
Most intercpt.dll csatlakoztatható bármely folyamat.
Ha ez a folyamat hatására a kampós funkciót MessageboxA, vezérlés át fog kerülni a funkció és a munka Intercpt_MessageBoxA töréspont.
tesztelés
Ha ki szeretné próbálni az összes fenti első podyschu számítógépén olyan alkalmazás, amely összetételében MessageBox típusú üzenet. Kísérleti alkalmazása írta magunkat, ez az úgynevezett MESS.EXE és megjeleníti egymás után három üzenet doboz, kollázs, amely az alábbi:
Következő, példa a fordítási bevezetett DLL, a fent leírtak szerint. Az eredmény a válogatás hívtunk meg METOD1.DLL és METOD2.DLL.
Fordítsd példája DLL végrehajtási eljárások a külső kód folyamatot. A teljesítménye ennek az eljárásnak meg kell adni a kódot a fő program modul, valami ilyesmit:
Amikor futtatja a programot (nevezzük MELLÉKELJE .EXE) paraméterként meg kell adnia a folyamat azonosítóját, amelyhez bevezetjük a kódját, és a nevét a DLL csatolni kívánt külső folyamatot.
Másolás mindhárom kapott METOD1.DLL modul METOD2.DLL tulajdonítanak .EXE egy könyvtárba (például C: \ test \). Most elkezdheti tesztelés.
A program futtatása az áldozat (ebben az esetben MESS.EXE). Feladatkezelő megnyitásához, és nézd meg a futó folyamat (mess.exe):
és meghatározzák annak PID (esetünkben azonos PID mess.exe 1076).
Most, a parancssorból futtassa a program végrehajtásának első DLL kód:
Ennek eredményeként, amikor megpróbálja felhívni a MessageBox ablak MESS.EXE a program megkapja ugyanazt a képet:
Lefoglaló API függvény történt!
következtetés
„Nem is olyan ördög, mint a Microsoft programja ...” Azonban, ha az olvasó óvatosan áthaladt maga kijelentette anyag, láttam, hogy a szokásos módon, minden ragyogó - csak. És még olyan dolog, mint egy API lehallgatás Windows NT, nem igényel bonyolult szoftver kódját és végre lehet hajtani az első kérésre.