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ă spectaculos, singura modalitate de a înțelege ce s-a întâmplat este să... dump de memorie al kernelului și analiza ulterioarăAceste dumps surprind starea internă a sistemului în momentul defecțiunii și reprezintă materia primă pentru depanarea erorilor complexe, investigarea incidentelor de securitate sau efectuarea de examinări criminalistice.

Deși poate părea de foarte „nivel scăzut”, analizarea unui dump 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 elementele de bază. instrumente adecvate, tipuri de gropi de gunoi și tehnici de interpretare de bazăVom acoperi întreaga cale în 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ă?

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

În practică, o astfel de dump economisește structuri interne ale kernelului, stive de apeluri, context de proces și drivere încărcateDatorită acestui fapt, după dezastru se poate face o analiză „post-mortem”, foarte similară cu depanarea unui sistem live, dar fără presiunea de a fi nevoit să atingi o mașină de producție în timp ce aceasta se defectează.

Motivele pentru aprofundarea dump-urilor de kernel sunt variate: de la depanare erori aparent aleatorii și blocări intermitente...chiar investigând dacă un sistem a fost manipulat cu rea intenție sau dacă o eroare ar fi putut lăsa urme de informații sensibile pe disc.

Pe lângă dump-urile complete ale kernelului, există posibilitatea de a extrage dump-uri ale proceselor individuale (clasicul depozite de miez), care sunt foarte utile atunci când ceea ce dorim este pentru a limita o problemă la o anumită aplicație sau pentru a analiza impactul asupra confidențialității unui serviciu ca 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ă știm pe care să le folosim. De ce tip de dump avem 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 acestuia, 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 mod 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 problemă dacă aceasta provine departe de firul de execuție care rula în momentul erorii. Informațiile contextuale disponibile sunt limitate.

Windows poate genera, de asemenea, imagini de memorie a kernelului și imagini complete mult mai mari, care conțin porțiuni sau toată memoria fizică. Acestea sunt utile în special în analiză 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 dump-urile din Windows, primul lucru este să configurați corect opțiunile. pornire și recuperareDin Panoul de control, în proprietățile avansate ale sistemului, puteți alege tipul de dump pe care doriți să îl generați în caz de eroare: de exemplu, „Dump de memorie mică (256 KB)” și calea unde va fi stocat.

Sistemul are nevoie și de o 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 în folderul configurat se păstrează un istoric, 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 instrument clasic este Dumpchk.execeea ce vă permite să verificați integritatea de bază a fișierului și să imprimați informații rezumative. Pentru o analiză mai avansată, se utilizează următoarele: Instrumente de depanare pentru Windowscare includ WinDbg (interfață grafică) și KD (versiunea din linie de comandă).

După instalarea pachetului de depanare de pe site-ul web Microsoft, instrumentele se află de obicei într-un folder precum C:\Program Files\Instrumente de depanare pentru WindowsDe acolo putem deschide un prompt de comandă și încărca un dump cu WinDbg sau KD folosind parametrul -z pentru a specifica fișierul:

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

Calea simbolului 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 cu 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 !analiza, 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 Reimprimă codul de eroare și parametrii asociați, care pot fi apoi comparați cu referință de cod 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 procesul de încărcare a dump-ului prin crearea unui fișier batch Primește calea către dump și lansează KD sau WinDbg cu parametrii corespunzători. În acest fel, trebuie doar să scrieți o comandă scurtă care include 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 -zsau din interfața grafică, utilizând meniul Fișier > Deschidere memorie sau comanda rapidă de la tastatură Ctrl + D.

Dacă WinDbg este deja deschis în mod 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, putem începe sesiunea cu o comandă. g (Go) în anumite scenarii sau lansați direct primele comenzi de analiză.

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 salvează o copie a memoriei atunci când are loc un eveniment catastrofal, ceea ce știm ca haldă de miez 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 eroare poate fi cauzată de erori de programare, dar și acțiuni rău intenționate încercări eșuate de manipulare a componentelor sistemului sau exploatare stângace a condițiilor de concurență.

Într-un sistem Unix bine configurat, căderile zilnice nu sunt frecvente, dar atunci când apar, este înțelept să aveți un plan de rezervă. infrastructură de descărcare a deșeurilor, cum ar fi Kdump, LKCD sau alte soluții care permit capturarea memoriei sistemului. Cu toate acestea, este necesar 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 complete și răspândite instrumente pentru acest tip de analiză în Linux este prăbușireDezvoltat inițial de Red Hat, acest utilitar a devenit un standard de facto pentru examinarea dump-urilor kernelului și 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 blocarea să funcționeze corect, sunt necesare două elemente cheie: a fișier vmlinux compilat cu simboluri de depanare (de obicei cu semnalizatoare 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ă decomprimarea manuală a fișierului vmlinuz, procesul nu este întotdeauna banal și, în practică, este de obicei mult mai convenabil. Recompilați kernelul pentru a obține atât vmlinux, cât și vmlinuz în paralel. În mediile administrative serioase, este o practică bună să se mențină vmlinux-ul corespunzător fiecărei versiuni de kernel implementate exact pentru aceste cazuri.

Odată ce cerințele sunt îndeplinite, blocarea unui dump este relativ simplă: specificați vmlinux-ul și fișierul dump corespunzător, iar instrumentul deschide o sesiune interactivă din care puteți parcurge structurile kernelului, listează procesele, vizualizează stivele de apeluri și extrage informații criminalisticeCei care doresc să aprofundeze informațiile pot consulta documentație specializată, cum ar fi binecunoscutul document alb privind accidentele tehnice.

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 o descărcare de date fiabilă și completă fără a se 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 (Extractor de memorie Linux)LiME este un modul de kernel conceput special 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 o memorie RAM completă pe care o putem analiza cu instrumente criminalistice sau chiar cu șiruri de caractere sau alte utilități ca prim pas pentru localizarea lanțurilor 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 imagini de fundal per proces sunt mult mai mici și mai ușor de gestionat și vă permit să concentrați analiza asupra unor aplicații specifice, cum ar fi un client de mesagerie (de exemplu, Skype) sau un client de e-mail (cum ar fi Thunderbird), unde este relativ ușor de găsit parole în text simplu, token-uri de sesiune sau date de contact dacă se explorează șirurile de memorie.

Din perspectiva dezvoltării, aceste imagini de memorie ajută la localizarea erorilor de programare, a pierderilor de memorie sau a stărilor inconsistente dintr-un serviciu. Dar din perspectiva securității, problema apare atunci când Dump-urile sunt generate în mod curent și stocate în locații accesibile altor utilizatori.fie pe 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ă. proces automat care lasă copii de memorie accesibile 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 este instalat folosind simboluri, 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ă nicio garanție absolută că analiza va rezolva toate incidentele, dar, în practică, Această strategie funcționează destul de bine într-un procent ridicat de scenariimai ales 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-ului kernelului duce de obicei la documentație tehnică, baze de cunoștințe, forumuri specializate sau chiar codul sursă al kernelului în sine pentru a interpreta mesaje, coduri de eroare și simboluri nefamiliare.

Î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 problemei. contextul în care este declanșată o acțiune BUG() sau WARN() determinat.

În Windows, documentația Microsoft, baza sa de cunoștințe (KB) și forumurile tehnice oferă explicații detaliate despre coduri de verificare a erorilor, recomandări de rezolvare și modele de erori cunoscutePrin combinarea acestor informații cu rapoartele !analyze -v, este posibil să se elaboreze un plan rezonabil de atenuare.

Adevărata valoare a unui crash dump reiese atunci când toate acele informații sunt comparate cu cunoștințe solide despre sistemul de operare și mediul specific în care s-a produs eroareaNumai așa se pot propune 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 memorie ale kernelului 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 vă permite nu numai să depanați incidente complexe, ci și... pentru a crește drastic nivelul de securitate și reziliență al sistemelor pe care le gestionăm.