Ce poate face un utilizator avansat cu consola Windows? Probabil, formatați accidental șurubul, profund deranjat și solicitați ajutor de la un vecin competent.
Un hacker adevărat îl va pune în slujba lui. Deci, aceasta îi va permite să atingă obiectivul prețuit - invizibilitatea pentru antivirusuri. Și nu numai ...
Consola standard Windows (da, cea care apare, să zicem atunci când sunați cmd.exe, obiectul veșnic al malware-ului Linux) - s-ar părea că poate fi mai plictisitor? Dar vă grăbesc să vă asigur: consola din Windows este un lucru extrem de interesant și interesant, nu va fi superfluă să vă dați în interior. Determinați imediat (și apoi unii pot să nu înțeleagă despre ce este vorba) - noi, în acest articol, nu ne interesează accesul la MS-DOS sau trucurile de linii de comandă în Windows. Este vorba despre felul în care există de fapt fereastra neagră.
Consola este în întregime copilul CSRSS și [a scris deja în mod repetat despre acest subsistem Windows fals. Unii cititori ar putea crede că acest lucru este tot cognitiv, dar destul de plictisitor din punctul de vedere al hack-ului. Cu toate acestea, vă sfătuiesc să citiți articolul până la sfârșit, este cu siguranță ceva de gândit.
Interacțiunea dintre procese
Windows oferă dezvoltatorului un set bogat de instrumente pentru a asigura interacțiunea între procese - tastatură, fișiere, țevi (conducte numite), memorie partajată, LPC / RPC, COM, socluri și altceva. Toate acestea sunt mai mult sau mai puțin bine documentate, nu are rost să le oprim (pentru dezvoltarea generală - en.wikipedia.org/wiki/Mezhprotsessnoe_interaction). Cu toate acestea, puțini oameni au crezut că consola are o proprietate atât de magică, precum asigurarea interacțiunii dintre procese. Și această proprietate a ajuns la consola din subsistemul CSRSS.
Cum poate fi consola în tampon între cele două procese? Se pare, foarte ușor. De exemplu, un program creează o nouă consolă sunând la AllocConsole API. Iar al doilea program (citire - proces) numește AttachConsole și se alătură astfel "interfeței text" a consolei.
Ce se întâmplă: două obiecte de proces dețin cel de-al treilea obiect care aparține procesului extern csrss.exe. În plus, având acces la consola, primele două procese "străine" pot schimba cu ușurință setările consolei - de exemplu, poziția cursorului, dimensiunea ferestrei console sau numele său (fereastră). Toate acestea se fac prin apelarea funcțiilor bine documentate SetConsoleCursorInfo, SetConsoleCursorPosition, SetConsoleTitle (sau echivalentele lor Get-equivalent).
Din cele de mai sus, cititorul observațional poate concluziona că prin intermediul csrss.exe este posibilă organizarea schimbului de informații pentru două sau mai multe procese. Cum? Da, prin titlul (numele ferestrei) a consolei - poate deține 65535 octeți simultan, în același timp rata de transfer potențial de date va fi foarte, foarte mare în acest caz. Este adevărat că trebuie avut în vedere faptul că singurul tip de date care este potrivit pentru schimbul de informații între cele două procese prin CSRSS sunt șirurile de text. Prin urmare, dezvoltatorul va trebui să utilizeze tehnici suplimentare pentru a transfera date binare în acest fel.
CTRL + C - o situație familiară?
V-ați întrebat vreodată cum consola reacționează la o combinație de CTRL + C, care anulează execuția curentă a firului? În general, consola răspunde la cinci evenimente CTRL + .... Primul este CTRL_C_EVENT, semnalizând că tastele CTRL + C sunt apăsate. Al doilea este CTRL_BREAK_EVENT, folosit de depanatori. Cea de-a treia este CTRL_CLOSE_EVENT, spune tuturor proceselor care utilizează consola că magazinul este acoperit. CTRL_LOGOFF_EVENT este trimis la toate procesele dacă utilizatorul se deconectează. În cele din urmă, CTRL_SHUTDOWN_EVENT, care spune că sistemul este oprit. Primele două semnale pot fi recepționate prin apăsarea tastelor cunoscute de pe tastatură sau programat prin apelarea API-ului GenerateConsoleCtrlEvent.
Mecanismul care asigură procesarea tuturor acestor evenimente CTRL este extrem de interesant, însă cunoașterea existenței semnalului nu va fi utilă dacă programul nu este capabil să proceseze cumva aceste semnale. Și aici vine ajutorul funcției kernel32.dll! SetConsoleCtrlHandler, prin care puteți seta manualul pentru semnalele CTRL. Dar nu este atât de simplu.
Pentru a clarifica complet imaginea, trebuie să înțelegem următoarele. În ce context este firul înregistrat executat?
Poate că acesta este fluxul inițial al procesului, sau nou-creat, sau chiar FIG în curs de dezvoltare știu de unde? Pentru a răspunde la întrebări, derula caseta înapoi la momentul consolei, și să vedem ce se întâmplă atunci când apelați AllocConsole. Apelarea acestei funcții înainte de apeluri winsrv! SrvAllocConsole. Această funcție, la rândul său, transmise ca parametri doi pointeri la funcții kernel32! CtrlRoutine și kernel32! PropRoutine (CsrClientCallServer urmat de o provocare cu codul de funcționare internă 0x20224). Și apoi vine partea distractivă - atunci când primesc orice CTRL-semnal csrss creează un nou fir în contextul unei consolă atașat la proces: winsrv ProcessCtrlEvents - winsrv CreateCtrlThread - winsrv InternalCreateCallba ckThread - kernel32 CreateRemoteThread !!!! (!).
Noul fir va avea punctul de intrare același indicator la CtrlRoutine.
Bunele lui Hacker
mecanismul descris atunci când csrss taxiuri consola stivuitoare, puteți utiliza foarte popular printre dezvoltatorii de malware problemă - cum de a crea, ascunde sau deghiza un nou fir neobservate de proaktivok sau Avery. În programele oneste, funcțiile cunoscute CreateThread (Ex) sunt de obicei folosite pentru a crea noi fire. Dar dacă doriți să ascundeți acest fapt, puteți face următoarele: Creați o nouă consolă, înregistrând unul sau mai multor gestionari de semnal, și apoi a genera semnale programatic Ctrl + C sau Ctrl + Break, pentru a crea un nou fir. Datorită aplicației API, orice program poate înregistra sau șterge cu ușurință dispozitivele de gestionare a semnalelor. Astfel, orice proces primește un subsistem nedocumentat caracteristică csrss, egal în putere pentru a direcționa apelurile CreateThread (Ex).
Crearea schematică a unui fir cu metoda descrisă va arăta astfel:
AllocConsole ();
SetConsoleCtrlHandler (threadHandler1, TRUE);
SetConsoleCtrlHandler (threadHandler2, TRUE);
GenerateConsoleCtrlEvent (CTRL_C_EVENT, GetCurrentProcessId ());
// Aici codul va fi executat
threadHandler2 (CTRL_C_EVENT)
// Aici codul va fi executat
threadHandler1 (CTRL_C_EVENT)
SetConsoleCtrlHandler (threadHandler1, FALSE);
SetConsoleCtrlHandler (threadHandler3, TRUE);
GenerateConsoleCtrlEvent (CTRL_BREAK_EVENT, GetCurrentProcessId ());
// Aici codul va fi executat
// threadHandler3 (CTRL_BREAK_EVENT)
// Aici codul va fi executat
// threadHandler2 (CTRL_BREAK_EVENT)
FreeConsole ();
E minunat, nu-i așa? Și nimeni nu va ști despre crearea de fire noi. Dar acesta este doar începutul :). După cum am menționat deja mai sus, datorită API-ului AttachConsole, orice program poate accesa acum interfața text a consolei. Și în ciuda faptului că, la un moment dat doar un singur proces poate fi „proprietar“ al consolei, toate celelalte procese pot controla pe deplin fereastra în sine și de a folosi toate funcțiile pentru consola de administrare. În acest caz, astfel de procese nu numai că pot gestiona consola, ci și ele primesc notificări despre evenimentele de consolă.
Deci, aici este un mod simplu de a trage o concluzie - folosind funcția API AttachConsole poate servi în cele din urmă ca un fel de alternativă la CreateRemoteThread!
Uite, cum se face:
Pentru acest exemplu, merită remarcat o caracteristică: în cazul descris, semnalul CTRL_C_EVENT nu va funcționa, trebuie să utilizați CTRL_BREAK_EVENT. În plus, apelantul funcției GenerateConsoleCtrlEvent este capabil să inițieze crearea de fire, dar nu va putea verifica rezultatul execuției.
Un cititor atent poate să-și amintească faptul că atunci când apelați funcția principală pentru crearea consolei winsrv! SrvAllocConsole, două indicatoare pentru funcțiile CtrlRoutine și PropRoutine sunt transmise acesteia.
Cu CtrlRoutine, par să fi dat seama, dar unde este PropRoutine? Este simplu - PropRoutine este responsabil pentru procesarea proprietăților ferestrei. Când utilizatorul încearcă să schimbe proprietățile ferestrei console, selectează meniul corespunzător, stabilește opțiunea selectată și confirmă modificările selectate. Se pare că nu este nimic complicat, dar în intestinul sistemului se petrec din nou evenimente foarte distractive.
În momentul în care utilizatorul face clic pe meniul "Properties" din fereastra consolei, una din funcțiile de gestionare a ferestrelor (și anume winsrv! ConsoleWindowProc) primește un mesaj de fereastră cu astfel de parametri:
- uMsg = WM_SYSCOMMAND
- wParam = 0xFFF7
- lParam = nedefinit
Ce se întâmplă în continuare? Pornește mecanismul de proiecție fișier în memoria cauzat funcția NtCreateSection, apoi NtMapViewOfSection, apoi proiecția este umplut cu setările curente ale ferestrei consolei. Următorul apel NtUnmapViewOfSection apoi invocat NtDuplicateObject, care creează un duplicat al unei secțiuni mâner (în contextul procesului de proprietar consola!) Și numai apoi numit CreateRemoteThread instalat PropRoutine duplicat și o secțiune de mâner parametri transmise.
Rețineți că PropertiesDlgShow nu așteaptă ca firul să se termine, pur și simplu winsrv! ConsoleWindowProc creează pur și simplu un fir și readuce controlul la managerul de mesaje fereastră. Un fapt uimitor - aceasta nu înseamnă că proprietățile actualizate ale ferestrei sunt setate în alt mod, mai degrabă decât doar funcția PropertiesDlgShow.
Maestru pentru începători
Astfel, se dovedește că implementarea corectă a funcției sale, în loc de kernelul de tip hard-core32! PropRoutine, putem implementa cu ușurință funcția API CreateThread (Ex). Acest lucru se poate face prin interceptarea și modificarea funcțiilor AllocConsole / AttachConsole sau, pentru cei nebuni, prin implementarea proprie a funcției AllocConsole ().
Apropo, pentru a forța consola să creeze un fir nou, este suficient să trimiteți un mesaj la fereastra cu următorii parametri:
TrimitereMessage (hConsole, WM_SYSCOMMAND, 0xFFF7, 0)
Aici, hConsole este HWND-ul normal primit de apelul către GetConsoleHandle (). Ce facem ca rezultat? Pentru a crea un fir nou în cazul în care apelați kernel32! CtrlRoutine prin intermediul unui număr de mișcări complexe ale corpului, puteți sări peste, înlocuind kernel32! PropRoutine cu funcția proprie, nu chiar onestă. Aceasta, de regulă, va duce la crearea unui nou, "invizibil" pentru ochii bunurilor și proactivitățile fluxului.
Și în cele din urmă, să vorbim despre console.dll de mai sus, sau mai degrabă - cum poate fi folosit pentru scopurile noastre murdare. În Windows XP, console.dll a fost încărcat cu o eroare grozavă - nu a fost specificat nici un fel de unde să încărcați această bibliotecă, ceea ce a dat șansa spărgătorilor să o înlocuiască. Începând cu Windows Vista, situația nu sa îmbunătățit - au adăugat o cale relativă la această bibliotecă. Având în vedere algoritmul care este încă folosit în Windows pentru a găsi biblioteci, din nou există o posibilitate bună de înlocuire a acestuia. Înainte de a încărca console.dll de la system32, va fi mai întâi căutat în folderul de instalare a programului. Dar asta nu e tot. Toate mecanismele descrise pot fi folosite pentru a ascunde injectarea codului dvs. într-un proces la distanță! Dar vă voi lăsa ca informații pentru reflecție, mai ales că toate ingredientele necesare pentru acest lucru sunt prezentate în articol.
concluzie
Ar părea - ce ar putea fi mai plictisitor decât o consolă? Dar chiar și acolo, dacă veți săturați cu desăvârșire prin programul de depanare, vor fi multe lucruri interesante - mai ales că tot ceea ce găsiți poate fi folosit pentru faptele voastre murdare! Fie că va fi ... Citiți revista preferată] [- Promit subiecte noi și interesante! Compilație reușită, iar Forța poate fi cu tine!
Scripturile pentru criptografie sunt ascunse în widgeturile LiveHelpNow și au lovit peste 1500 de site-uri
Extortioner qkG criptează numai documente Word și se distribuie automat folosind macrocomenzi
Firefox va avertiza utilizatorii despre vizitarea site-urilor hacked anterior
"Codul securității informațiilor" va avea loc în Astana pentru prima dată
Noile vulnerabilități din Intel ME sunt periculoase pentru dispozitivele Acer, Dell, Fujitsu, HP, Lenovo, Panasonic și așa mai departe
Trimiteți-le prietenilor: