Geheugendump en kernelanalyse op Windows- en Unix-systemen

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

Wanneer een besturingssysteem vastloopt of spectaculair crasht, is de enige manier om te begrijpen wat er is gebeurd... Kernelgeheugendump en daaropvolgende analyseDeze dumps leggen de interne toestand van het systeem vast op het moment van de storing en vormen de basis voor het opsporen van complexe fouten, het onderzoeken van beveiligingsincidenten of het uitvoeren van forensisch onderzoek.

Hoewel het misschien erg "technisch" klinkt, is het analyseren van een geheugendump niet alleen weggelegd voor kernelontwikkelaars. Systeembeheerders, supportmedewerkers en zelfs beveiligingsauditors kunnen er baat bij hebben als ze de basisprincipes kennen. geschikte hulpmiddelen, soorten dumps en basisinterpretatietechniekenWe zullen dit hele traject behandelen in 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 genoemd Kernel crash dump, ofwel crash dump.) is een bestand dat een kopie bevat, geheel of gedeeltelijk, van het geheugen op het moment dat het systeem een ​​kritieke storing ondervindt, zoals een kernel paniek in Unix/Linux of een blauw scherm des doods (BSOD) in Windows.

In de praktijk bespaart een dergelijke dump het volgende: interne kernelstructuren, aanroepstacks, procescontext en geladen stuurprogramma'sDankzij deze functie kan na de ramp een "postmortem"-analyse worden uitgevoerd, vergelijkbaar met 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 en verhelpen van ogenschijnlijk willekeurige bugs en intermitterende crashes....zelfs onderzoek naar de vraag of een systeem opzettelijk is gemanipuleerd of dat een crash sporen van gevoelige informatie op de schijf heeft achtergelaten.

Naast volledige kernel-dumps bestaat ook de mogelijkheid om dumps van individuele processen te extraheren (de klassieke dump). kerndumps), die erg handig zijn wanneer we willen dat om een ​​probleem te beperken tot een specifieke toepassing of om de impact op de vertrouwelijkheid van een dienst te beoordelen zoals een e-mail- of berichtenprogramma.

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 welke je moet gebruiken. Welk type dump hebben we nodig, gezien 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 storing, de context van de processor die is gestopt (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 probleem te traceren als het ver verwijderd is van de thread die op het moment van de crash actief was. De beschikbare contextuele informatie is beperkt..

Windows kan ook kernelgeheugendumps genereren, evenals veel grotere volledige dumps die delen van of het gehele fysieke geheugen bevatten. Deze zijn vooral nuttig in 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 dumpbestanden in Windows te kunnen gebruiken, moet je allereerst de juiste opties configureren. opstarten en herstelIn het Configuratiescherm, bij de geavanceerde systeeminstellingen, kunt u het type dump kiezen dat u wilt genereren in geval van een storing: bijvoorbeeld de "Kleine geheugendump (256 KB)" en de locatie waar deze wordt opgeslagen.

Het systeem heeft ook een nodig wisselbestand op het opstartvolume van minstens een paar megabytes om de dump te 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 gemakkelijk kunnen worden bekeken.

Nadat de dumps zijn gegenereerd, zijn er verschillende manieren om te controleren of ze correct zijn. Een klassiek hulpmiddel hiervoor is... Dumpchk.exeHiermee kunt u de basisintegriteit van het bestand controleren en samenvattende informatie afdrukken. Voor een meer geavanceerde analyse worden de volgende functies gebruikt: Foutopsporingstools voor Windowswaaronder WinDbg (grafische interface) en KD (opdrachtregelversie).

Na het installeren van het debugpakket vanaf de Microsoft-website bevinden de tools zich meestal in een map zoals C:\Program Files\Debugging Tools for WindowsVan daaruit kunnen we een opdrachtprompt openen en een dump laden met WinDbg of KD met de parameter -z om het bestand te specificeren:

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

Het symboolpad kan verwijzen naar een symboolserver met lokale cache, 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 vrijwel hetzelfde als een debugsessie na een crash. De eerste opdracht die bijna iedereen uitvoert is... !analyseren, waarmee een automatische 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, het commando .bugcheck Het programma print de foutcode en de bijbehorende parameters opnieuw af, die vervolgens vergeleken kunnen worden met de bugcheck code referentie Raadpleeg Microsoft om de exacte betekenis van elke waarde en de typische 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 laadproces van de dump vereenvoudigen door een batchbestand Het script ontvangt het pad naar het dumpbestand en start KD of WinDbg met de juiste parameters. Op deze manier hoeft u alleen een kort commando te schrijven met de bestandslocatie, 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 vanaf de commandoregel worden geopend met -zof via de grafische interface, met behulp van het menu Bestand > Geheugendump openen of 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 starten met een commando. g (Ga) in bepaalde scenario's, of start direct de eerste analyseopdrachten.

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 opslaan voor het geval er zich een catastrofale gebeurtenis voordoet., wat we kennen kern dump of kernelcrashdump.

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 kwaadwillige acties. mislukte pogingen om systeemcomponenten te manipuleren of onhandig misbruik te maken van raceomstandigheden.

In een goed geconfigureerd Unix-systeem komen dagelijkse crashes niet vaak voor, maar als ze zich voordoen, is het verstandig om een ​​back-upplan te hebben. dumping-infrastructuur zoals Kdump, LKCD of andere oplossingen die het mogelijk maken om systeemgeheugen vast te leggen. Het is echter noodzakelijk om zowel de diagnostische waarde van de dump als het risico dat deze zeer gevoelige gegevens bevat, tegen elkaar af te wegen.

Een van de meest complete en wijdverspreide tools voor dit type analyse in Linux is neerstortenDeze tool, oorspronkelijk ontwikkeld door Red Hat, is uitgegroeid tot een de facto standaard voor het onderzoeken van kernel-dumps en 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 vmlinux-bestand gecompileerd 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 uit te pakken, is dit proces niet altijd eenvoudig en is het in de praktijk meestal veel handiger. Hercompileer de kernel om zowel vmlinux als vmlinuz te verkrijgen. parallel. In serieuze beheeromgevingen is het goede praktijk om voor elke geïmplementeerde kernelversie een vmlinux-installatie te onderhouden, juist voor deze gevallen.

Als aan de vereisten is voldaan, is het maken van een dump relatief eenvoudig: u specificeert de juiste vmlinux en het dumpbestand, en de tool opent een interactieve sessie van waaruit u verder kunt gaan. Doorloop kernelstructuren, toon processen, bekijk aanroepstacks en extraheer forensische informatie.Wie zich nog verder wil verdiepen in de materie, kan gespecialiseerde documentatie raadplegen, zoals het bekende technische crashwhitepaper.

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 bescherming is vanuit veiligheidsoogpunt volkomen logisch, maar dwingt ons wel om te zoeken naar... Andere manieren om een ​​betrouwbare en complete stortplaats 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)LiME is 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 een complete RAM-dump die we kunnen analyseren met forensische tools of zelfs met strings of andere hulpprogramma's. als eerste stap om interessante ketens 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 de analyse te richten op specifieke applicaties zoals een berichtenclient (bijvoorbeeld Skype) of een e-mailclient (zoals Thunderbird), waar het relatief eenvoudig is om gegevens te vinden. wachtwoorden in platte tekst, sessietokens of contactgegevens als de geheugenstrings worden onderzocht.

Vanuit een ontwikkelingsperspectief helpen deze core dumps bij het opsporen van programmeerfouten, geheugenlekken of inconsistente toestanden in een service. Maar vanuit een beveiligingsperspectief ontstaat het probleem wanneer... De gegevensdumps worden routinematig gegenereerd en opgeslagen op locaties die toegankelijk zijn voor andere gebruikers.ofwel op het systeem zelf, ofwel 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 eventuele geautomatiseerd proces dat geheugenkopieën toegankelijk maakt 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.

Nadat de kernel met behulp van symbolen is geïnstalleerd, kunnen we de dumps nu 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 te traceren.

Er bestaat geen absolute garantie dat de analyse alle incidenten zal oplossen, maar in de praktijk... Deze strategie werkt in een groot percentage van de gevallen behoorlijk goed.vooral wanneer crashdumps worden gecombineerd met een goede analyse van recente systeemwijzigingen.

Aanbevelingen voor het analyseren en documenteren van kernel-fouten

Ongeacht het besturingssysteem leidt analyse van kerneldumps meestal tot... technische documentatie, kennisbanken, gespecialiseerde forums, of zelfs de broncode van de kernel 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 het probleem. context waarin een BUG() of WARN() wordt geactiveerd vastbesloten.

In Windows bieden de Microsoft-documentatie, de kennisbank (KB) en technische forums gedetailleerde uitleg over Foutcodes, aanbevelingen voor oplossingen en bekende foutpatronenDoor die informatie te combineren met de !analyze -v-rapporten, is het mogelijk een redelijk plan voor risicobeperking op te stellen.

De ware waarde van een crashdump komt pas naar voren wanneer al die informatie wordt vergeleken met andere gegevens. gedegen kennis van het besturingssysteem en de specifieke omgeving waarin de storing is opgetreden.Alleen op deze manier kunnen duurzame oplossingen worden aangedragen en, bovenal, kan worden voorkomen dat hetzelfde probleem zich in de toekomst opnieuw voordoet met ernstiger gevolgen.

Kernelgeheugendumpanalyse 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, kunt u niet alleen complexe incidenten debuggen, maar ook om de beveiliging en veerkracht van de systemen die we beheren drastisch te verhogen..