Dump de memorie și analiză a kernelului pe sistemele Windows și Unix

Informatec Digital » Recursos » Dump de memorie și analiză a kernelului pe sistemele Windows și Unix

Când un sistem de operare intră în panică sau se blochează, singura modalitate de a înțelege ce s-a întâmplat este de a lua o imagine de memorie a kernelului și de a o analiza . Aceste imagini de memorie surprind starea internă a sistemului în momentul defecțiunii și sunt esențiale pentru depanarea erorilor complexe, investigarea incidentelor de securitate sau efectuarea de examinări criminalistice.

Deși poate părea de foarte „nivel scăzut”, analiza dump-urilor de memorie nu este exclusivă dezvoltatorilor de kernel. Administratorii de sistem, inginerii de asistență și chiar auditorii de securitate pot beneficia de aceasta dacă cunosc instrumentele potrivite, diferitele tipuri de dump-uri și tehnicile de interpretare de bază . Vă vom ghida prin toate acestea pe Windows, Unix/Linux și BSD, folosind instrumente precum WinDbg, crash, kgdb și LiME.

Ce este o imagine de memorie a kernelului și de ce merită analizată?

Un dump de memorie kernel (adesea numit Kernel Crash Dump sau pur și simplu crash dump ) este un fișier care conține o copie, completă sau parțială, a memoriei în momentul în care sistemul suferă o eroare critică, cum ar fi o panică a kernelului în Unix/Linux sau un ecran albastru al morții (BSOD) în Windows.

În practică, un dump de acest tip salvează structurile interne ale kernelului, stivele de apeluri, contextul procesului și driverele încărcate . Datorită acestui fapt, după dezastru, se poate efectua o analiză post-mortem foarte similară cu depanarea unui sistem live, dar fără presiunea de a fi nevoit să atingeți o mașină de producție în timp ce aceasta se defectează.

Motivele pentru aprofundarea dump-urilor kernelului sunt variate: de la depanarea erorilor aparent aleatorii și a blocărilor intermitente , până la investigarea faptului dacă un sistem a fost manipulat în mod rău intenționat sau dacă o blocare ar fi putut lăsa urme de informații sensibile pe disc.

Pe lângă dump-urile complete ale proceselor (core dumps-urile clasice), există posibilitatea de a face dump-uri ale proceselor individuale ( core dumps-urile clasice ), care sunt foarte utile atunci când dorim să limităm o problemă la o anumită aplicație sau să verificăm impactul asupra confidențialității unui serviciu, cum ar fi un client de e-mail sau mesagerie.

Tipuri de imagini de memorie în Windows și utilitatea lor

Pe sistemele Windows, sistemul de operare în sine poate genera diferite tipuri de dump-uri atunci când apare o eroare STOP. Fiecare tip include un nivel diferit de detaliu, așa că este esențial să știți de ce tip de dump aveți nevoie în funcție de problemă și de limitările de spațiu pe disc.

Unul dintre cele mai comune formate în mediile utilizatorilor și pe multe servere este o mică imagine de memorie (minidump)Este cea care ocupă cel mai puțin spațiu și este de obicei amplasată în %SystemRoot%\Minidump, cu fișiere de stil MiniLLZZAA-01.dmp.

Acest mini dump conține informații foarte specifice, dar importante: codul de eroare STOP și parametrii săi , lista driverelor încărcate în momentul eșecului, contextul procesorului care s-a oprit (PRCB), contextele procesului și firului de execuție implicat (structurile EPROCESS și ETHREAD) și stiva de apeluri în modul kernel a firului de execuție respectiv.

Datorită acestor structuri de bază, chiar și cu un minidump este adesea posibil să se identifice driverul sau modulul care cauzează erorile, deși nu va fi întotdeauna posibil să se urmărească întreaga pistă dacă problema își are originea departe de firul de execuție care rula în momentul erorii, iar informațiile contextuale disponibile sunt limitate.

Windows poate genera, de asemenea, imagini de memorie ale kernelului și imagini complete mult mai mari, care conțin porțiuni sau toată memoria fizică. Acestea sunt utile în special pentru analize de nivel scăzut, investigații criminalistice și depanare avansată a driverelor sau a sistemului în sine.

Configurați și deschideți imagini de memorie în Windows cu WinDbg și KD

Pentru a profita de imaginile de sistem în Windows, primul pas este să configurați corect opțiunile de pornire și recuperare . Din Panoul de control, în proprietățile avansate ale sistemului, puteți alege tipul de imagine de memorie pe care doriți să o generați în caz de eroare: de exemplu, o „Imagine de memorie mică (256 KB)” și calea unde va fi stocată.

Sistemul necesită, de asemenea, un fișier de paginare pe volumul de boot de cel puțin câțiva megaocteți pentru a scrie dump-ul. În versiunile moderne de Windows, fiecare eroare creează un fișier nou, iar un istoric este păstrat în folderul configurat, permițând o revizuire ușoară a incidentelor anterioare.

Odată generate, există mai multe modalități de a valida dacă dump-urile sunt corecte. Un utilitar clasic este Dumpchk.exe , care vă permite să verificați integritatea de bază a fișierului și să imprimați informații rezumative. Pentru analize mai avansate, se utilizează instrumentele de depanare Windows , inclusiv WinDbg (interfață grafică) și KD (versiunea din linia de comandă).

După instalarea pachetului de depanare de pe site-ul web Microsoft, instrumentele vor fi de obicei localizate într-un folder precum C:\Program Files\Debugging Tools for Windows . De acolo, puteți deschide o linie de comandă și încărca un fișier dump folosind WinDbg sau KD, specificând fișierul cu parametrul -z .

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Calea simbolurilor poate indica un server de simboluri cu cache local , de exemplu:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

În timp ce calea binară este de obicei ceva de genul C:\Windows\I386 sau folderul în care am copiat executabilele de sistem corespunzătoare versiunii care a generat dump-ul. Acest lucru este important deoarece Minidump-urile nu includ toate fișierele binare, doar referințe la acestea, deci depanatorul trebuie să le poată găsi.

Analiza de bază a unui dump de eroare al kernelului în Windows

Odată ce dump-ul este încărcat folosind WinDbg sau KD, analizarea unui dump de eroare a kernelului este destul de similară cu o sesiune de depanare post-mortem. Prima comandă pe care aproape toată lumea o execută este `!analyze` , care lansează o analiză automată și generează un raport inițial.

Comanda !analyze -show arată codul de verificare a erorilor și parametrii acestuiaÎn timp ce !analyze -v Produce un rezultat mult mai detaliat: modul suspect, stiva de apeluri, informații contextuale și, în multe cazuri, sugestii despre posibile cauze sau pași de diagnosticare.

Pentru a completa această analiză, comanda .bugcheck afișează din nou codul de eroare și parametrii asociați, care pot fi comparați cu referința codului bugcheck de la Microsoft pentru a afla semnificația exactă a fiecărei valori și cauzele tipice.

Comanda lm N T (listă module) vă permite să vedeți Lista modulelor încărcate cu calea, adresele și starea lorAcest lucru ajută la confirmarea faptului dacă driverul identificat de analiza automată se află într-adevăr în memorie și ce versiune are. Această listă este utilă în special atunci când suspectăm drivere sau componente de securitate terțe care interacționează cu kernelul.

Dacă dorim, putem simplifica încărcarea dump-urilor prin crearea unui fișier batch care primește calea către dump și lansează KD sau WinDbg cu parametrii corespunzători. În acest fel, trebuie doar să scriem o comandă scurtă care include doar locația fișierului, iar scriptul se ocupă de tot restul.

Utilizarea WinDbg pentru deep kernel dumps

Pentru imaginile de memorie în modul kernel, WinDbg oferă și posibilitatea de a lucra cu mai multe fișiere și sesiuni. Imaginile de memorie pot fi deschise din linia de comandă cu -z sau din interfața grafică utilizând meniul File > Open Memory Dump sau comanda rapidă de la tastatură Ctrl+D.

Dacă WinDbg este deja deschis în modul pasiv, pur și simplu selectați fișierul în caseta de dialog „Deschideți dump-ul de eroare”, specificând calea sau răsfoind discul. După încărcare, puteți începe sesiunea cu o comandă „g” (Go) în anumite scenarii sau puteți lansa direct comenzile de analiză inițială.

Pe lângă clasicul !analyzeEste recomandabil să vă familiarizați cu secțiunea de referință a comenzilor de depanareAceasta descrie toate comenzile disponibile pentru citirea structurilor interne, examinarea memoriei, interpretarea stivelor și multe altele. Multe dintre aceste tehnici sunt aplicabile atât sesiunilor live, cât și dump-urilor offline.

WinDbg vă permite, de asemenea, să lucrați cu mai multe dump-uri paralelePutem adăuga mai mulți parametri -z în linia de comandă, fiecare urmat de un nume de fișier diferit, sau putem adăuga noi ținte folosind comanda .opendumpDepanarea destinațiilor multiple este utilă pentru compararea eșecurilor recurente sau a incidentelor înlănțuite.

În unele medii, imaginile de memorie sunt împachetate în fișiere CAB pentru a economisi spațiu sau a facilita transmiterea. WinDbg poate deschide direct un .cab cu un dump în interior, atât folosind -z, cât și cu .opendumpdeși va citi Va extrage doar unul dintre fișierele descărcate și nu va extrage alte fișiere. care ar putea intra în același pachet.

Dump-uri de eroare în Unix și Linux: utilitare, instrumente și cerințe

În sistemele Unix și GNU/Linux, filosofia este similară, dar ecosistemul de instrumente diferă considerabil. Majoritatea nucleelor ​​de tip Unix oferă posibilitatea de a salva o copie a memoriei atunci când are loc un eveniment catastrofal , cunoscut sub numele de core dump sau kernel crash dump.

Deși utilizarea lor principală rămâne dezvoltarea de kernel și drivere, aceste dump-uri au un aspect clar de securitate. O prăbușire poate fi cauzată de erori de programare, dar și de acțiuni rău intenționate eșuate, încercări de manipulare a componentelor sistemului sau condiții de concurență exploatate stângaci.

Într-un sistem Unix bine configurat, căderile zilnice sunt rare, dar atunci când apar, este recomandabil să existe o infrastructură de dump, cum ar fi Kdump, LKCD sau alte soluții care permit capturarea memoriei sistemului. Cu toate acestea, este esențial să se evalueze atât valoarea de diagnosticare a dump-ului, cât și riscul ca acesta să conțină date extrem de sensibile.

Unul dintre cele mai cuprinzătoare și utilizate instrumente pentru acest tip de analiză în Linux este crash , dezvoltat inițial de Red Hat. Acest utilitar a devenit practic un standard de facto pentru examinarea dump-urilor kernelului și, de asemenea, pentru analizarea sistemelor care rulează.

Crash-ul poate afecta memoria activă a sistemului prin /dev/mem sau, în distribuțiile Red Hat și derivate, folosind dispozitivul specific /dev/crashChiar și așa, este o practică obișnuită să se alimenteze instrumentul cu un fișier dump generat de mecanisme precum Kdump, makedumpfile, Discdump sau dump-uri specifice arhitecturii, cum ar fi s390/s390x sau xendump în medii virtualizate.

Rolul prăbușirilor și importanța vmlinux în Linux

Utilitarul de blocare a fost creat, în parte, pentru a depăși limitările utilizării gdb direct pe /proc/kcorePrintre altele, accesul la acea pseudo-imagine de memorie poate fi restricționat și, în plus, anumite opțiuni de compilare a kernelului îngreunează interpretarea corectă a structurilor interne dacă avem doar fișierul binar executabil comprimat.

Pentru ca o eroare de depanare să funcționeze corect, sunt necesare două elemente cheie: un fișier vmlinux compilat cu simboluri de depanare (de obicei cu stegulețe precum -g) și dump-ul kernelului în sine. Această combinație permite instrumentului să mape adrese de memorie la funcții, structuri și linii de cod.

Este important să se facă distincția între vmlinux și vmlinuzPe majoritatea sistemelor, este vizibil doar vmlinux, care este o versiune comprimată și bootabilă a kernelului. O prăbușire necesită vmlinux decomprimat simbolic; fără acesta, la încercarea de încărcare a unui dump sau /dev/mem Vom întâlni erori de tipul nu găsește kernelul bootat — te rugăm să introduci argumentul namelist.

Deși este posibil să extrageți manual vmlinuz, procesul nu este întotdeauna simplu și, în practică, este adesea mult mai convenabil să recompilați kernelul pentru a obține simultan atât vmlinux, cât și vmlinuz. În mediile de administrare serioase, este o practică bună să mențineți un pachet vmlinuz separat pentru fiecare versiune de kernel implementată, special pentru aceste situații.

Odată ce cerințele sunt îndeplinite, rularea erorii (crash) împotriva unui dump este relativ simplă: specificați vmlinux-ul și fișierul dump corespunzătoare, iar instrumentul deschide o sesiune interactivă din care puteți explora structurile kernelului, lista procesele, vizualiza stivele de apeluri și extrage informații criminalistice . Cei care doresc să aprofundeze informațiile pot consulta documentație specializată, cum ar fi binecunoscutul document tehnic privind erorile.

Limitările /dev/mem și primele abordări în Linux

Înainte de a recurge la instrumente specifice, mulți administratori au încercat dintotdeauna să obțină o imagine de memorie (memory dump). citirea directă de pe dispozitiv /dev/memAceastă abordare părea simplă: folosiți un instrument precum memdump (care trimite acel dispozitiv la STDOUT) sau extrage din dd if=/dev/mem of=volcado.mem.

Totuși, kernelurile moderne oferă opțiuni de compilare, cum ar fi CONFIG_STRICT_DEVMEMcare limitează sever accesul din spațiul utilizatorului către /dev/memRezultatul tipic este că citirea este întreruptă după un bloc mic (de exemplu, 1 MB) sau, în cel mai rău caz, o eroare în acea interacțiune poate duce la o kernel panic imediat și repornirea mașinii.

Această protecție are sens din punct de vedere al securității, dar ne obligă să căutăm alte modalități de a obține un dump fiabil și complet, fără a ne baza în totalitate pe dispozitive generice care nu mai sunt la fel de accesibile ca înainte.

Prin urmare, tendința actuală este de a se baza pe module specifice sau infrastructuri integrate de dump-uri de memorie, în loc să se încerce pur și simplu „răzuirea memoriei” cu instrumente din spațiul utilizatorului care nu sunt concepute să coexiste cu politicile moderne de protecție a kernelului.

LiME Forensics: Extragerea memoriei în Linux și Android

O alternativă foarte puternică în lumea criminalistică este LiME (Linux Memory Extractor) , un modul de kernel conceput tocmai pentru a captura memoria volatilă într-un mod controlat și fără restricțiile care afectează /dev/mem. LiME rulează în spațiul kernelului, astfel încât poate accesa memoria RAM mult mai direct.

LiME este distribuit cu codul său sursă și se compilează pe baza anteturile kernelului în uzProcesul de compilare generează un modul .ko specific versiunii de kernel în care va fi încărcat. Odată compilat, îl putem verifica cu instrumente precum file pentru a ne asigura că modulul ELF corespunzător arhitecturii noastre a fost generat corect.

Pentru a utiliza LiME, pur și simplu încărcați modulul cu insmod de la root și îi transmiteți opțiunile corespunzătoare, de exemplu specificând un destinație de dump de rețea folosind TCP și un format brut:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

În paralel, pe mașina care va primi dump-ul, ascultăm pe portul configurat folosind un instrument precum ncredirecționarea ieșirii către un fișier:

nc <IP_origen> 4444 > volcado.mem

După câteva minute, în funcție de cantitatea de RAM și de performanța rețelei, vom avea un fișier a cărui dimensiune corespunde cu memoria fizică a sistemului sursă. Acesta este un dump RAM complet pe care îl putem analiza cu instrumente criminalistice sau chiar cu șiruri de caractere sau alte utilitare, ca prim pas pentru a localiza șiruri de caractere interesante.

Dump-uri de proces și riscuri de expunere a datelor

Un dump complet al kernelului este extrem de informativ, dar poate fi și excesiv atunci când suntem interesați doar de un anumit proces. În acest caz, are mult sens să recurgem la... dump-uri individuale de proces folosind instrumente precum gcore în Unix/Linux.

Aceste dump-uri per proces sunt mult mai mici și mai ușor de gestionat și vă permit să vă concentrați analiza asupra unor aplicații specifice, cum ar fi un client de mesagerie (de exemplu, Skype) sau un client de e-mail (de exemplu, Thunderbird), unde este relativ ușor să găsiți parole în text simplu, token-uri de sesiune sau date de contact explorând șirurile de memorie.

Din perspectiva dezvoltării, aceste memorii de bază ajută la localizarea erorilor de programare, a pierderilor de memorie sau a stărilor inconsistente dintr-un serviciu. Cu toate acestea, din perspectiva securității, problema apare atunci când aceste memorii sunt generate în mod curent și stocate în locații accesibile altor utilizatori , fie în sistemul în sine, fie pe resurse de rețea partajate.

Dacă un utilizator programează, de exemplu, o sarcină cron Prin capturarea periodică a dump-urilor proceselor sensibile și lăsarea lor într-un director lizibil global, un atacator deschide o cale uriașă către expunerea informațiilor critice. În multe scenarii de audit, analizarea acestor fișiere permite unui atacator să recupereze. acreditări, liste de contacte, istoricul comunicațiilor și alte date private cu efort relativ redus.

Prin urmare, în orice audit serios al unui sistem Unix, este recomandabil să se dedice câteva minute verificării dacă se generează dump-uri (complete sau parțiale), unde sunt stocate, ce permisiuni au și dacă există vreun proces automat care lasă copii în memorie la îndemâna utilizatorilor neautorizați.

Analiza post-mortem a dump-urilor în FreeBSD cu kgdb

În lumea BSD, și în special în FreeBSD, abordarea analizei post-mortem implică Activează erorile de depanare pe sistem și compilează un kernel cu simboluri de depanareAcest lucru este controlat din directorul de configurare a kernelului, de obicei în /usr/src/sys/<arq>/conf.

În fișierul de configurare corespunzător, generarea de simboluri poate fi activată cu o linie de genul:

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

După modificarea configurației, nucleul trebuie recompilat. Unele obiecte vor fi regenerate (cum ar fi trap.o) din cauza modificării fișierelor de compilare. Scopul este de a obține un kernel cu același cod ca cel care are probleme, dar adăugând informațiile de depanare necesareEste recomandabil să comparați dimensiunile vechi și noi folosind comanda size pentru a se asigura că nu au existat modificări neașteptate în fișierul binar.

Odată ce kernelul cu simboluri este instalat, putem examina dump-urile cu kgdb așa cum este descris în documentația oficială. Este posibil ca nu toate simbolurile să fie complete, iar unele funcții pot apărea fără numere de linie sau informații despre argumente, dar în majoritatea cazurilor nivelul de detaliu este suficient pentru a identifica problema.

Nu există o garanție absolută că analiza va rezolva toate incidentele, dar în practică, această strategie funcționează destul de bine într-un procent ridicat de scenarii , mai ales atunci când dump-urile de erori sunt combinate cu o analiză bună a modificărilor recente ale sistemului.

Cele mai bune practici pentru analizarea și documentarea erorilor de kernel

Indiferent de sistemul de operare, analiza dump-urilor kernelului ajunge de obicei să se refere la documentație tehnică, baze de cunoștințe, forumuri specializate sau chiar la codul sursă al kernelului în sine pentru a interpreta mesaje, coduri de eroare și simboluri necunoscute.

În Linux, este foarte util să te bazezi pe arborele oficial al codului sursă, pe documentația încorporată și pe resursele comunității. Multe mesaje de eroare ale kernelului pot fi urmărite până la fișierul exact din care provin, ceea ce ajută la înțelegerea contextului în care este declanșat un anumit BUG() sau WARN().

În Windows, documentația Microsoft, baza sa de cunoștințe (KB) și forumurile tehnice oferă explicații detaliate ale codurilor de verificare a erorilor, recomandări de depanare și modele de erori cunoscute . Combinarea acestor informații cu rapoartele din !analyze -v face posibilă dezvoltarea unui plan rezonabil de atenuare.

Adevărata valoare a unui crash dump reiese atunci când toate aceste informații sunt comparate cu o înțelegere solidă a sistemului de operare și a mediului specific în care a avut loc eroarea . Numai atunci se pot dezvolta soluții durabile și, mai presus de toate, se poate preveni reapariția aceleiași probleme în viitor, cu consecințe mai grave.

Analiza dump-urilor de kernel este, în cele din urmă, o combinație de știință și măiestrie: necesită instrumente adecvate, configurare prealabilă (simboluri, opțiuni de dump, stocare securizată) și multă experiență în citirea stivelor, structurilor și codurilor de eroare. Stăpânirea acestor tehnici ne permite nu numai să depanăm incidente complexe, ci și să creștem dramatic securitatea și reziliența sistemelor pe care le gestionăm.