A konzol kivágása a zongorákat a proaktív védelem útján indítja
Mit tehet a fejlett felhasználó a Windows konzolon? Valószínűleg véletlenül formázza a csavart, mélyen felborul és segítséget kér egy illetékes szomszédtól.
Egy igazi hacker lesz a szolgálatába. Tehát ez lehetővé teszi, hogy elérje a kedvelt célt - a láthatatlanság az antivirusokkal szemben. És nem csak ...
A szabványos Windows konzol (igen, ugyanaz, amely megjelenik, például, amikor hív cmd.exe, az örök tárgya megfélemlítés Linux felhasználók) - úgy tűnik, hogy ott lehet unalmas? De sietek biztosítani Önöket: a konzol Windows - nagyon szórakoztató és érdekes dolog, dig nem lesz felesleges a belső. Mi határozza meg egyszerre (és egyesek nem értik, mire gondolok) - mi ebben a cikkben nem lesz érdekelt hozzáférés MS-DOS vagy parancssori trükkök a Windows. Arról szól, hogy a fekete ablak ténylegesen létezik.
A konzol teljesen a CSRSS gyermeke, és] [már többször írt róla a szigorú Windows alrendszerről. Egyes olvasók úgy gondolják, hogy ez mind kognitív, hanem unalmas a hack szempontjából. Mindazonáltal azt javaslom, hogy olvassa végig a cikket, biztosan van valami, amire gondolni kell.
A folyamatok közötti kölcsönhatás
A Windows gazdag eszköztárat biztosít a fejlesztőknek a folyamatok - a billentyűzet, a fájlok, a csövek (csövek), a megosztott memória, az LPC / RPC, a COM, a foglalatok és valami más - közötti kölcsönhatást. Mindegyik többé-kevésbé jól dokumentált, nincs értelme megállítani őket (általános fejlesztéshez - en.wikipedia.org/wiki/Mezhprotsessnoe_interaction). Mindazonáltal kevés ember úgy gondolta, hogy a konzolnak ilyen mágikus tulajdonsága van, mint a folyamatok közötti kölcsönhatás. És ez a tulajdonság a konzolhoz érkezett a CSRSS alrendszerből.
Hogyan lehet a konzol a két folyamat közötti pufferben? Kiderült, nagyon könnyen. Például egy program létrehoz egy új konzolt az AllocConsole API hívásával. És a második program (olvasható folyamat) felhívja a AttachConsole-ot, és így csatlakozik a konzol "szöveges felületéhez".
Mi történik: a két folyamatobjektum a csrss.exe külső folyamatához tartozó harmadik objektum tulajdonában van. Továbbá, miután elérte a konzolt, az első két "idegen" folyamat könnyen megváltoztathatja a konzolbeállításokat - például a kurzor pozícióját, a konzolablak méretét vagy annak (ablak) nevét. Mindezt meghívásával egy jól dokumentált SetConsoleCursorInfo funkciók SetConsoleCursorPosition, SetConsoleTitle (vagy a Get-ekvivalens).
A fentiek alapján a megfigyelő olvasó arra a következtetésre juthat, hogy a csrss.exe segítségével lehetőség van két vagy több folyamathoz való információcserére. Hogyan? Igen át Tittle (ablak címét) konzol - ez egy időben fér 65535 bájt, a potenciális adatsebesség ebben az esetben nagyon magas lesz. Igaz, szem előtt kell tartani, hogy az egyetlen olyan adatfajta, amely alkalmas a két folyamat közötti információcserére a CSRSS-en keresztül, szövegszövegek. Ezért a fejlesztőnek további technikákat kell alkalmaznia a bináris adatok ilyen módon történő átvitelére.
CTRL + C - egy ismerős helyzet?
Elgondolkodtál már arról, hogy a konzol hogyan reagál a CTRL + C kombinációjára, amely megszünteti a szál aktuális végrehajtását? Általában a konzol öt CTRL + eseményre reagál. Az első CTRL_C_EVENT, jelezve, hogy megnyomta a CTRL + C billentyűkombinációt. A második a CTRL_BREAK_EVENT, amelyet a debuggerek használnak. A harmadik pedig CTRL_CLOSE_EVENT, és minden olyan folyamatot elmond, amely a konzolt a boltban lefedi. A CTRL_LOGOFF_EVENT minden folyamathoz elküldik, ha a felhasználó bejelentkezik. Végül CTRL_SHUTDOWN_EVENT, amely azt mondja, hogy a rendszer ki van kapcsolva. Az első két jel a billentyűzet ismert billentyűinek megnyomásával vagy programozható módon hívható meg a GenerateConsoleCtrlEvent API használatával.
Az összes ilyen CTRL esemény feldolgozását lehetővé tevő mechanizmus rendkívül érdekes, de a jel meglétéről nem lesz hasznos, ha a program nem képes ezeket a jeleket valamilyen módon feldolgozni. És itt van a kernel32.dll! SetConsoleCtrlHandler függvény segítségével, amellyel beállíthatja a kezelőt a CTRL jelekhez. De nem annyira egyszerű.
A kép tökéletes tisztázása érdekében meg kell értenünk a következőket. Abban az esetben, ha a szál a regisztrált kezelő végrehajtva van?
Talán ez az első folyamatábra, vagy újonnan létrehozott, vagy akár meg fügét tudja, hol? Annak érdekében, hogy válaszoljon a kérdésekre, tekerje vissza a szalagot vissza az időben a konzol, és meglátjuk, mi történik, ha hívja AllocConsole. Ezt a funkciót a winsrv! SrvAllocConsole hívja. Ez a funkció viszont átvitt paraméterként két mutató funkciók kernel32! CtrlRoutine és kernel32! PropRoutine (CsrClientCallServer majd kihívást a belső műveleti kódot 0x20224). És akkor jön a móka része - ha bármilyen CSRSS CTRL-jel létrehoz egy új szál keretében egy csatolt konzolt a folyamat: winsrv ProcessCtrlEvents - winsrv CreateCtrlThread - winsrv InternalCreateCallba ckThread - kernel32 CreateRemoteThread (!) !!!!.
Az új szálnak ugyanaz a mutatója lesz a CtrlRoutine bejárati pontnak.
A hacker íze
Leírt mechanizmust, amikor CSRSS taxi rakodók konzol, akkor nagyon népszerű a fejlesztők a malware probléma - hogyan lehet létrehozni, elrejtsük vagy egy új szál által észrevétlenül proaktivok vagy Avery. A becsületes programokban az ismert funkciókat CreateThread (Ex) általában új szálak létrehozására használják. De ha azt akarjuk, hogy ezt a tényt, akkor tegye a következőket: Hozzon létre egy új konzol, regisztráció egy vagy több jelkezelőit majd programozottan jeleket hoznak létre a Ctrl + C és Ctrl + Break, hogy hozzon létre egy új téma. Az API segítségével minden program könnyen regisztrálhatja vagy törölheti a jelkezelőket. Így bármely folyamat kap egy nem dokumentált funkció CSRSS alrendszer egyenlő hatalom közvetlen hívások CreateThread (Ex).
Szöveget létrehozva a leírt módszerrel egy szálat fog kinézni:
AllocConsole ();
SetConsoleCtrlHandler (threadHandler1, TRUE);
SetConsoleCtrlHandler (threadHandler2, TRUE);
GenerateConsoleCtrlEvent (CTRL_C_EVENT, GetCurrentProcessId ());
// Itt lesz a kód végrehajtva
threadHandler2 (CTRL_C_EVENT)
// Itt lesz a kód végrehajtva
threadHandler1 (CTRL_C_EVENT)
SetConsoleCtrlHandler (threadHandler1, FALSE);
SetConsoleCtrlHandler (threadHandler3, TRUE);
GenerateConsoleCtrlEvent (CTRL_BREAK_EVENT, GetCurrentProcessId ());
// Itt lesz a kód végrehajtva
// threadHandler3 (CTRL_BREAK_EVENT)
// Itt lesz a kód végrehajtva
// threadHandler2 (CTRL_BREAK_EVENT)
FreeConsole ();
Nagyszerű, nem igaz? És senki nem fog tudni új szálak létrehozásáról. De ez csak a kezdet :). Amint már említettük, a AttachConsole API köszönhetően minden program hozzáférhet a konzol szöveges felületéhez. És annak ellenére, hogy bármikor csak egy folyamat lehet a "tulajdonos" a konzolon, minden más folyamat képes teljes mértékben felügyelni az ablakot, és minden funkciót kezelni a konzolt. Ebben az esetben az ilyen folyamatok nem csak kezelik a konzolt, hanem értesítéseket is kapnak a konzol eseményekről.
Tehát itt van egy egyszerű módja annak, hogy levonhassuk a következtetést - a AttachConsole API funkció használata végső soron a CreateRemoteThread alternatívájaként szolgálhat!
Megnézzük, hogyan történik:
Ehhez a példához érdemes megemlíteni egy jellemzőt: a leírt esetben a CTRL_C_EVENT jel nem fog működni, a CTRL_BREAK_EVENT értéket kell használni. Ezenkívül a GenerateConsoleCtrlEvent funkció hívója csak akkor tudja kezdeményezni a szálak létrehozását, de nem tudja ellenőrizni a végrehajtás eredményét.
A figyelmes olvasó emlékeztet arra, hogy ha felhívja a winsrv! SrvAllocConsole konzol létrehozásának fő funkcióját, a CtrlRoutine és PropRoutine függvényekhez két mutatót ad át.
A CtrlRoutine-lal úgy tűnik, kiderült, de hol van a PropRoutine? Ez egyszerű - a PropRoutine felelős az ablak tulajdonságainak feldolgozásáért. Amikor a felhasználó megpróbálja megváltoztatni a konzol ablak tulajdonságait, kiválasztja a megfelelő menüt, beállítja a kiválasztott opciót, és megerősíti a kiválasztott változtatásokat. Semmi bonyolultnak tűnik, de a rendszer belsejében nagyon szórakoztató események zajlanak ki.
Abban a pillanatban, amikor a felhasználó a konzol ablak "Tulajdonságok" menüpontjára kattint, az egyik ablakkezelő funkció (vagyis a winsrv! ConsoleWindowProc) ablakot kap ilyen paraméterekkel:
- uMsg = WM_SYSCOMMAND
- wParam = 0xFFF7
- lParam = undefi ned
Mi történik ezután? A fájl futtatásához vetítés mechanizmus a memória okozta NtCreateSection funkciót, majd NtMapViewOfSection, akkor a vetítés van töltve az aktuális beállításokat a konzolt. A következő NtUnmapViewOfSection hívást, majd hivatkozni NtDuplicateObject, amely létrehoz egy másolatot a nyélrész (a folyamat keretében a konzol tulajdonos!) És csak akkor hívják CreateRemoteThread telepített PropRoutine másolást és a nyélrész továbbított paramétereket.
Vegye figyelembe, hogy PropertiesDlgShow nem vár a végén a munkafolyamatok, az azt jelenti, winsrv! ConsoleWindowProc egyszerűen létrehoz egy szál, és visszaadja a vezérlést manager ablak üzeneteket. Hihetetlen tény - ez nem jelenti azt, hogy az ablak frissített tulajdonságait más módon állították be, nem csak a PropertiesDlgShow függvényt.
Mesterosztály kezdőknek
Így kiderül, hogy a hard-core kernel32! PropRoutine helyett helyesen implementálja funkcióját, könnyen megvalósíthatjuk a CreateThread (Ex) API-t. Ezt az AllocConsole / AttachConsole funkcióinak lehallgatásával és módosításával, vagy egészen őrültséggel, az AllocConsole () függvény saját végrehajtásával lehet végrehajtani.
By the way, annak érdekében, hogy a konzolt egy új szál létrehozására kényszerítsék, elegendő egy üzenetet küldeni az ablaknak az alábbi paraméterekkel:
SendMessage (hConsole, WM_SYSCOMMAND, 0xFFF7, 0)
Itt a hConsole a GetConsoleHandle () hívás által fogadott normál HWND. Mit kapunk ennek eredményeképpen? Ahhoz, hogy hozzon létre egy új szál esetén a hívás kernel32! CtrlRoutine számos összetett mozgások, akkor is csak siess, cseréje kernel32! PropRoutine a nem teljesen igazságos funkciót. Úgy, mint a szabály, létrejöttéhez vezet egy új, „láthatatlan”, hogy a szem és az Avery proaktivok áramlását.
És végül, beszéljünk a fenti konzol.dll-ről, vagy inkább - hogyan használható ez a piszkos célokra. A Windows XP, letöltés console.dll végzett szörnyű hiba - nem adja meg az utat, ahonnan betölteni a könyvtárban, így a hackerek lehetőséget lecserélni. A Windows Vista-ról kezdve a helyzet nem javult - hozzátettek egy relatív útvonalat ehhez a könyvtárhoz. Tekintve, hogy az algoritmus, amelyet még mindig használnak a Windows-ban a könyvtárak megtalálásához, ismét helyénvaló annak helyettesítése. Mielőtt betöltené a console.dll rendszert a system32-ből, először a program telepítési mappájába keres. De ez nem minden. Az összes leírt mechanizmust felhasználhatjuk a kód injektálásának elrejtésére távoli folyamatban! De el kell hagynom önnek, mint információ visszaverődésre, különösen azért, mert az összes szükséges alkotóelem megtalálható a cikkben.
következtetés
Úgy tűnik - mi lehet unalmasabb, mint egy konzol? De még ott is, ha ásni egy jó debugger, lesz egy csomó érdekes dolgot - annál is inkább, hogy minden lehet használni, hogy megtalálták a piszkos kapcsolatban! Legyen szó akár ... Olvassa kedvenc magazinjaidat] [- Megígérem új és izgalmas témákat! Sikeres összeállítás, és az Erő is veled lehet!