Geheugendump en kernelanalyse op Windows- en Unix-systemen

Informatic Digital » Middelen » Geheugendump en kernelanalyse op Windows- en Unix-systemen

Wanneer een besturingssysteem vastloopt of crasht, is de enige manier om te begrijpen wat er is gebeurd het maken en analyseren van een kernelgeheugendump . Deze dumps leggen de interne toestand van het systeem vast op het moment van de storing en zijn essentieel voor het debuggen van complexe fouten, het onderzoeken van beveiligingsincidenten of het uitvoeren van forensisch onderzoek.

Hoewel het misschien erg "laag niveau" klinkt, is geheugendumpanalyse niet alleen weggelegd voor kernelontwikkelaars. Systeembeheerders, supportmedewerkers en zelfs beveiligingsauditors kunnen er baat bij hebben als ze de juiste tools kennen, de verschillende soorten dumps begrijpen en de basisinterpretatietechnieken beheersen . We nemen je mee door dit alles op Windows, Unix/Linux en BSD, met behulp van tools zoals WinDbg, crash, kgdb en LiME.

Wat is een kernelgeheugendump en waarom is het de moeite waard om deze te analyseren?

Een kernelgeheugendump (vaak een kernelcrashdump of simpelweg een crashdump genoemd ) is een bestand dat een kopie bevat, geheel of gedeeltelijk, van het geheugen op het moment dat het systeem een ​​kritieke fout ondervindt, zoals een kernelpanic in Unix/Linux of een blauw scherm des doods (BSOD) in Windows.

In de praktijk bewaart een dergelijke dump interne kernelstructuren, aanroepstacks, procescontext en geladen stuurprogramma's . Dankzij dit kan na een calamiteit een postmortem-analyse worden uitgevoerd die sterk lijkt op het debuggen van een live systeem, maar dan zonder de druk om een ​​productiemachine aan te raken terwijl deze uitvalt.

De redenen om kernel dumps grondig te onderzoeken zijn uiteenlopend: van het opsporen van ogenschijnlijk willekeurige bugs en incidentele crashes tot het onderzoeken of een systeem opzettelijk is gemanipuleerd of dat een crash sporen van gevoelige informatie op de schijf heeft achtergelaten.

Naast volledige core dumps is het ook mogelijk om dumps te maken van individuele processen (de klassieke core dumps ). Deze zijn erg handig wanneer we een probleem willen beperken tot een specifieke applicatie of de impact op de vertrouwelijkheid van een dienst, zoals een e-mail- of berichtenclient, willen controleren.

Soorten geheugendumps in Windows en hun nut.

Op Windows-systemen kan het besturingssysteem zelf verschillende soorten dumps genereren wanneer er een STOP-fout optreedt. Elk type bevat een ander detailniveau, dus het is cruciaal om te weten welk type dump u nodig hebt, afhankelijk van het probleem en de beschikbare schijfruimte.

Een van de meest voorkomende formaten in gebruikersomgevingen en op veel servers is de kleine geheugendump (minidump)Het is de variant die de minste ruimte inneemt en zich meestal bevindt in %SystemRoot%\Minidump, met bestanden van de stijl MiniMMDDYY-01.dmp.

Deze minidump bevat zeer specifieke maar belangrijke informatie: de STOP-foutcode en de bijbehorende parameters , de lijst met stuurprogramma's die geladen waren op het moment van de fout, de context van de gestopte processor (PRCB), de contexten van het betrokken proces en de betrokken thread (EPROCESS- en ETHREAD-structuren) en de kernel-modus aanroepstack van die thread.

Dankzij deze basisstructuren is het zelfs met een minidump vaak mogelijk om te achterhalen welke driver of module de crashes veroorzaakt, hoewel het niet altijd mogelijk zal zijn om het volledige spoor te volgen als het probleem ver verwijderd is van de thread die op het moment van de crash actief was en de beschikbare contextinformatie beperkt is.

Windows kan ook kernelgeheugendumps genereren, evenals veel grotere volledige dumps die delen van of het volledige fysieke geheugen bevatten. Deze zijn vooral nuttig voor analyse op laag niveau, forensisch onderzoek en geavanceerd debuggen van stuurprogramma's of het systeem zelf.

Configureer en open geheugendumps in Windows met WinDbg en KD.

Om in Windows gebruik te maken van systeemdumps, is de eerste stap het correct configureren van de opstart- en herstelopties . Via het Configuratiescherm, in de geavanceerde systeeminstellingen, kunt u het type dump kiezen dat u wilt genereren in geval van een storing: bijvoorbeeld een "Kleine geheugendump (256 KB)" en de locatie waar deze wordt opgeslagen.

Het systeem vereist ook een wisselbestand van minimaal een paar megabytes op het opstartvolume om de dump te kunnen schrijven. In moderne versies van Windows creëert elke crash een nieuw bestand en wordt een geschiedenis bijgehouden in de geconfigureerde map, waardoor eerdere incidenten eenvoudig kunnen worden bekeken.

Nadat de dumps zijn gegenereerd, zijn er verschillende manieren om te controleren of ze correct zijn. Een klassiek hulpprogramma is Dumpchk.exe , waarmee je de basisintegriteit van het bestand kunt controleren en samenvattende informatie kunt afdrukken. Voor een meer geavanceerde analyse worden de Windows-debuggingtools gebruikt , waaronder WinDbg (grafische interface) en KD (opdrachtregelversie).

Na het installeren van het debugpakket van de Microsoft-website, bevinden de tools zich doorgaans in een map zoals C:\Program Files\Debugging Tools for Windows . Vanuit die map kunt u een opdrachtprompt openen en een dumpbestand laden met WinDbg of KD, waarbij u het bestand specificeert met de parameter -z .

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

Het symboolpad kan verwijzen naar een symboolserver met lokale caching , bijvoorbeeld:

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

Hoewel het binaire pad er meestal uitziet als... C:\Windows\I386 of de map waar we de systeemuitvoerbare bestanden hebben gekopieerd die overeenkomen met de versie die de dump heeft gegenereerd. Dit is belangrijk omdat Minidumps bevatten niet alle binaire bestanden., er zijn alleen verwijzingen naar, dus de debugger moet ze kunnen vinden.

Basisanalyse van een kernelcrashdump in Windows

Zodra de dump is geladen met WinDbg of KD, is het analyseren van een kernelcrashdump vergelijkbaar met een debugsessie na een crash. De eerste opdracht die bijna iedereen uitvoert is `!analyze` , waarmee een geautomatiseerde analyse wordt gestart en een eerste rapport wordt gegenereerd.

Het commando !analyze -show toont de Foutcontrolecode en de bijbehorende parametersTerwijl !analyze -v Het levert een veel gedetailleerdere output op: verdachte module, aanroepstack, contextuele informatie en in veel gevallen suggesties voor mogelijke oorzaken of diagnostische stappen.

Ter aanvulling op die analyse print de opdracht .bugcheck de foutcode en bijbehorende parameters opnieuw af. Deze kunnen worden vergeleken met de bugcheck-codegids van Microsoft om de exacte betekenis van elke waarde en de meest voorkomende oorzaken te achterhalen.

Het commando lm N T (lijstmodules) stelt u in staat de Lijst van geladen modules met hun pad, adressen en status.Dit helpt te bevestigen of het stuurprogramma dat door de geautomatiseerde analyse is geïdentificeerd daadwerkelijk in het geheugen aanwezig is en welke versie het betreft. Deze lijst is vooral nuttig wanneer we vermoeden dat stuurprogramma's van derden of beveiligingscomponenten interactie hebben met de kernel.

Indien gewenst kunnen we het laden van dumps vereenvoudigen door een batchbestand te maken dat het pad naar de dump ontvangt en KD of WinDbg start met de juiste parameters. Op deze manier hoeven we alleen een korte opdracht te schrijven die alleen de bestandslocatie bevat, en het script regelt de rest.

WinDbg gebruiken voor het maken van diepe kernel-dumps

Voor geheugendumps in kernelmodus biedt WinDbg ook de mogelijkheid om met meerdere bestanden en sessies te werken. Dumps kunnen worden geopend vanaf de commandoregel met -z , of vanuit de grafische interface via het menu Bestand > Geheugendump openen of met de sneltoets Ctrl+D.

Als WinDbg al in passieve modus is geopend, selecteert u het bestand in het dialoogvenster "Crashdump openen" en geeft u het pad op of bladert u door de schijf. Zodra het bestand is geladen, kunt u de sessie in bepaalde gevallen starten met een "g" (Go) commando , of direct de eerste analysecommando's uitvoeren.

Naast de klassieke !analyzeHet is raadzaam om vertrouwd te raken met de Referentiesectie voor debuggeropdrachtenDit beschrijft alle beschikbare commando's voor het lezen van interne structuren, het onderzoeken van geheugen, het interpreteren van stacks en nog veel meer. Veel van deze technieken zijn toepasbaar op zowel live sessies als offline dumps.

WinDbg biedt je ook de mogelijkheid om te werken met meerdere parallelle dumpsWe kunnen meerdere -z parameters aan de commandoregel toevoegen, elk gevolgd door een andere bestandsnaam, of nieuwe doelen toevoegen met behulp van de opdracht. .opendumpHet debuggen van meerdere bestemmingen is handig voor het vergelijken van terugkerende fouten of opeenvolgende incidenten.

In sommige omgevingen worden geheugendumps verpakt in CAB-bestanden om ruimte te besparen of de overdracht te vergemakkelijken. WinDbg kan een CAB-bestand direct openen. .cab met een dump erin, zowel met -z als met .opendumphoewel hij zal lezen Het programma zal slechts één van de gedumpte bestanden uitpakken en de andere bestanden niet. Dat zou in hetzelfde pakket kunnen.

Crashdumps in Unix en Linux: hulpprogramma's, tools en vereisten

In Unix- en GNU/Linux-systemen is de filosofie vergelijkbaar, maar het ecosysteem van tools verschilt aanzienlijk. De meeste Unix-achtige kernels bieden de mogelijkheid om een ​​kopie van het geheugen op te slaan wanneer zich een catastrofale gebeurtenis voordoet . Dit staat bekend als een core dump of kernel crash dump.

Hoewel deze dumps voornamelijk worden gebruikt voor de ontwikkeling van kernels en drivers, hebben ze ook een duidelijk beveiligingsaspect. Een crash kan worden veroorzaakt door programmeerfouten, maar ook door mislukte kwaadwillige acties, pogingen om systeemcomponenten te manipuleren of onhandig misbruikte racecondities.

In een goed geconfigureerd Unix-systeem komen dagelijkse crashes zelden voor, maar als ze zich voordoen, is het raadzaam om een ​​dumpinfrastructuur te hebben, zoals Kdump, LKCD of andere oplossingen waarmee je systeemgeheugen kunt vastleggen. Het is echter cruciaal om de diagnostische waarde van de dump af te wegen tegen het risico dat deze zeer gevoelige gegevens bevat.

Een van de meest uitgebreide en meest gebruikte tools voor dit type analyse in Linux is `crash` , oorspronkelijk ontwikkeld door Red Hat. Deze tool is praktisch een de facto standaard geworden voor het onderzoeken van kernel dumps en ook voor het analyseren van draaiende systemen.

Een crash kan het actieve geheugen van het systeem beschadigen. /dev/mem of, in Red Hat en afgeleide distributies, met behulp van het specifieke apparaat. /dev/crashDesondanks is het gebruikelijk om de tool te voeden met een dumpbestand dat is gegenereerd door mechanismen zoals Kdump, makedumpbestand, Diskdump of architectuurspecifieke dumps zoals s390/s390x of xendump in gevirtualiseerde omgevingen.

De rol van crashes en het belang van vmlinux in Linux

Het crashhulpprogramma is mede ontwikkeld om de beperkingen van het gebruik van te overkomen. gdb direct op /proc/kcoreOnder andere kan de toegang tot die pseudo-geheugenafbeelding beperkt zijn, en bovendien maken bepaalde kernelcompilatieopties het moeilijk om de interne structuren correct te interpreteren als we alleen het gecomprimeerde uitvoerbare binaire bestand hebben.

Om crash correct te laten werken, zijn twee essentiële elementen nodig: een gecompileerd vmlinux-bestand met debugsymbolen (meestal met vlaggen zoals -g) en de kernel-dump zelf. Deze combinatie stelt de tool in staat om geheugenadressen te koppelen aan functies, structuren en regels code.

Het is belangrijk om onderscheid te maken tussen vmlinux en vmlinuzOp de meeste systemen is alleen vmlinux zichtbaar, een gecomprimeerde, opstartbare versie van de kernel. Crash vereist de symbolisch gedecomprimeerde vmlinux; zonder deze zal het laden van een dump of /dev/mem We zullen fouten tegenkomen van het type Kan de opgestarte kernel niet vinden — voer een namelist-argument in..

Hoewel het mogelijk is om vmlinuz handmatig te extraheren, is dit proces niet altijd even eenvoudig. In de praktijk is het vaak veel handiger om de kernel opnieuw te compileren om zowel vmlinux als vmlinuz tegelijkertijd te verkrijgen. In serieuze beheeromgevingen is het raadzaam om voor elke geïmplementeerde kernelversie een apart vmlinuz-pakket te onderhouden, specifiek voor dit soort situaties.

Als aan de vereisten is voldaan, is het uitvoeren van een crashtest op een dump relatief eenvoudig: u specificeert de juiste vmlinux en het dumpbestand, waarna de tool een interactieve sessie opent waarin u kernelstructuren kunt verkennen, processen kunt weergeven, aanroepstacks kunt bekijken en forensische informatie kunt extraheren . Wie dieper in de materie wil duiken, kan gespecialiseerde documentatie raadplegen, zoals de bekende technische whitepaper van Crash.

Beperkingen van /dev/mem en eerste benaderingen in Linux

Voordat beheerders hun toevlucht namen tot specifieke tools, probeerden ze in het verleden vaak eerst een geheugendump te maken. rechtstreeks van het apparaat lezen /dev/memDeze aanpak leek eenvoudig: gebruik een tool zoals memdump (waardoor de gegevens van dat apparaat naar STDOUT worden gedumpt) of ophalen van dd if=/dev/mem of=volcado.mem.

Moderne kernels bieden echter compilatieopties zoals CONFIG_STRICT_DEVMEMdie de toegang vanuit de gebruikersruimte tot /dev/memHet gebruikelijke resultaat is dat de leesbewerking na een klein blok (bijvoorbeeld 1 MB) wordt afgebroken, of in het ergste geval kan een fout in die interactie leiden tot een fout. kernel paniek onmiddellijke herstart van de machine.

Deze beveiliging is vanuit veiligheidsoogpunt volkomen logisch, maar dwingt ons wel om naar andere manieren te zoeken om een ​​betrouwbare en complete dump te verkrijgen zonder volledig afhankelijk te zijn van generieke apparaten die niet meer zo gemakkelijk verkrijgbaar zijn als voorheen.

De huidige trend is dan ook om te vertrouwen op specifieke modules of geïntegreerde crashdump-infrastructuren, in plaats van simpelweg te proberen het geheugen te "doorzoeken" met tools in de gebruikersruimte die niet zijn ontworpen om samen te werken met moderne kernelbeveiligingsprotocollen.

LiME Forensics: Geheugenextractie in Linux en Android

Een zeer krachtig alternatief in de forensische wereld is LiME (Linux Memory Extractor) , een kernelmodule die specifiek is ontworpen om vluchtig geheugen op een gecontroleerde manier vast te leggen, zonder de beperkingen die gelden voor /dev/mem. LiME draait in de kernelruimte, waardoor het veel directer toegang heeft tot het RAM-geheugen.

LiME wordt geleverd met de broncode en compileert tegen de kernelheaders in gebruikHet compilatieproces genereert een module. .ko specifiek voor de kernelversie waarin het geladen zal worden. Na compilatie kunnen we het controleren met tools zoals file om ervoor te zorgen dat de ELF-module die overeenkomt met onze architectuur correct is gegenereerd.

Om LiME te gebruiken, laad je de module eenvoudigweg met insmod vanuit root en geef de juiste opties door, bijvoorbeeld door een specificatie te geven Bestemming voor netwerkdump via TCP en een onbewerkt formaat.:

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

Tegelijkertijd luisteren we op de machine die de dump zal ontvangen naar de geconfigureerde poort met behulp van een tool zoals ncDe uitvoer omleiden naar een bestand:

nc <IP_origen> 4444 > volcado.mem

Na een paar minuten, afhankelijk van de hoeveelheid RAM en de netwerkprestaties, hebben we een bestand waarvan de grootte overeenkomt met het fysieke geheugen van het bronsysteem. Dit is een complete RAM-dump die we kunnen analyseren met forensische tools of zelfs met strings of andere hulpprogramma's als eerste stap om interessante tekenreeksen te vinden.

Procesdumps en risico's op datalekken

Een volledige kernel-dump is zeer informatief, maar kan ook overbodig zijn als we alleen geïnteresseerd zijn in een specifiek proces. In dat geval is het veel logischer om gebruik te maken van... individuele procesdumps met behulp van hulpmiddelen zoals gcore in Unix/Linux.

Deze dumps per proces zijn veel kleiner en beter beheersbaar, en stellen u in staat uw analyse te richten op specifieke applicaties zoals een berichtenclient (bijv. Skype) of een e-mailclient (bijv. Thunderbird), waar het relatief eenvoudig is om wachtwoorden in platte tekst, sessietokens of contactgegevens te vinden door geheugenstrings te onderzoeken.

Vanuit een ontwikkelingsperspectief helpen deze core dumps bij het opsporen van programmeerfouten, geheugenlekken of inconsistenties in een service. Vanuit een beveiligingsperspectief ontstaat er echter een probleem wanneer deze dumps routinematig worden gegenereerd en opgeslagen op locaties die toegankelijk zijn voor andere gebruikers , hetzij op het systeem zelf, hetzij op gedeelde netwerkbronnen.

Als een gebruiker bijvoorbeeld een taak inplant cron Door periodiek dumps van gevoelige processen vast te leggen en deze in een wereldwijd leesbare map op te slaan, creëert een aanvaller een enorme kans op het blootleggen van cruciale informatie. In veel auditscenario's stelt de analyse van deze bestanden een aanvaller in staat om gegevens te herstellen. inloggegevens, contactlijsten, communicatiegeschiedenis en andere privégegevens met relatief weinig inspanning.

Daarom is het bij elke serieuze audit van een Unix-systeem raadzaam om een ​​paar minuten te besteden aan het controleren of er dumps (volledig of gedeeltelijk) worden gegenereerd, waar ze worden opgeslagen, welke machtigingen ze hebben en of er een geautomatiseerd proces is dat geheugenkopieën achterlaat die toegankelijk zijn voor onbevoegde gebruikers.

Postmortem-analyse van dumps in FreeBSD met kgdb

In de BSD-wereld, en met name in FreeBSD, omvat de aanpak van post-mortemanalyse het volgende: Schakel crashdumps in op het systeem en zorg ervoor dat de kernel is gecompileerd met debugsymbolen.Dit wordt beheerd vanuit de kernelconfiguratiemap, meestal in /usr/src/sys/<arq>/conf.

In het bijbehorende configuratiebestand kan symboolgeneratie worden ingeschakeld met een regel als deze:

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

Na het wijzigen van de configuratie moet de kernel opnieuw worden gecompileerd. Sommige objecten worden opnieuw gegenereerd (zoals trap.o) vanwege de wijziging in de buildbestanden. Het doel is om een ​​kernel te verkrijgen met de Dezelfde code als de code die problemen geeft, maar met de benodigde debug-informatie erbij.Het is raadzaam om de oude en nieuwe afmetingen te vergelijken met behulp van het commando. size om ervoor te zorgen dat er geen onverwachte wijzigingen in het binaire bestand zijn opgetreden.

Zodra de kernel met symbolen is geïnstalleerd, kunnen we de dumps onderzoeken met kgdb, zoals beschreven in de officiële documentatie. Niet alle symbolen zijn mogelijk compleet en sommige functies kunnen zonder regelnummers of argumentinformatie verschijnen, maar in de meeste gevallen is het detailniveau voldoende om het probleem op te sporen.

Er is geen absolute garantie dat de analyse alle incidenten zal oplossen, maar in de praktijk werkt deze strategie in een groot percentage van de gevallen vrij goed , vooral wanneer crashdumps worden gecombineerd met een grondige evaluatie van recente systeemwijzigingen.

Aanbevelingen voor het analyseren en documenteren van kernel-fouten

Ongeacht het besturingssysteem, verwijst de analyse van kerneldumps meestal naar technische documentatie, kennisbanken, gespecialiseerde forums of zelfs de kernelbroncode zelf om berichten, foutcodes en onbekende symbolen te interpreteren.

In Linux is het erg nuttig om te vertrouwen op de officiële broncode, de ingebouwde documentatie en bronnen van de community. Veel kernel-foutmeldingen kunnen worden herleid tot het exacte bestand waar ze vandaan komen, wat helpt bij het begrijpen van de context waarin een bepaalde BUG() of WARN() wordt geactiveerd.

In Windows bieden de Microsoft-documentatie, de kennisbank (KB) en technische forums gedetailleerde uitleg over bugcheck-codes, aanbevelingen voor probleemoplossing en bekende foutpatronen . Door deze informatie te combineren met de rapporten van !analyze -v is het mogelijk een redelijk plan van aanpak te ontwikkelen.

De ware waarde van een crashdump komt pas naar voren wanneer al die informatie wordt vergeleken met een grondig begrip van het besturingssysteem en de specifieke omgeving waarin de storing zich voordeed . Alleen dan kunnen duurzame oplossingen worden ontwikkeld en, belangrijker nog, kan worden voorkomen dat hetzelfde probleem zich in de toekomst opnieuw voordoet met ernstiger gevolgen.

Kernel dumpanalyse is uiteindelijk een combinatie van wetenschap en vakmanschap: het vereist de juiste tools, voorafgaande configuratie (symbolen, dumpopties, veilige opslag) en een flinke dosis ervaring met het lezen van stacks, structuren en foutcodes. Door deze technieken te beheersen, kunnen we niet alleen complexe incidenten debuggen, maar ook de beveiliging en veerkracht van de systemen die we beheren aanzienlijk verbeteren.