Memory dump i anàlisi de kernel en sistemes Windows i Unix

Informatec Digital » Recursos » Memory dump i anàlisi de kernel en sistemes Windows i Unix

Quan un sistema operatiu entra en pànic o es penja a la bèstia, l'únic que queda per entendre què ha passat és el bolcat de memòria del nucli i la seva anàlisi posterior. Aquests bolcats capturen l'estat intern del sistema a l'instant de la sentència i són la matèria primera per depurar errors complexos, investigar incidents de seguretat o realitzar peritatges forenses.

Encara que pugui sonar molt "sota nivell", l'anàlisi d'un memory dump no és exclusiva de desenvolupadors del nucli. Administradors de sistemes, enginyers de suport i fins i tot auditors de seguretat poden treure'n partit si coneixen les eines adequades, els tipus de bolcats i les tècniques bàsiques d'interpretació. Recorrerem tot aquest camí tant a Windows com a Unix/Linux i BSD, recolzant-nos en eines com WinDbg, crash, kgdb o LiME.

Què és un bolcat de memòria del nucli i per què val la pena analitzar-ho

Un bolcat de memòria del nucli (sovint anomenat Kernel Crash Dump o simplement crash dump) és un fitxer que conté una còpia, total o parcial, de la memòria en el moment en què el sistema pateix una fallada crítica, com un pànic del nucli a Unix/Linux o una pantalla blava (BSOD) a Windows.

A la pràctica, un bolcat d'aquest tipus guarda estructures internes del nucli, piles de trucades, context de processos i drivers carregats. Gràcies a això, després del desastre es pot fer una anàlisi post-mortem molt semblant a depurar un sistema en viu, però sense la pressió d'haver de tocar una màquina de producció mentre falla.

Les raons per ficar-se a fons amb els bolcats del nucli són variades: des de depurar bugs aparentment aleatoris i col·lapses intermitents, fins a investigar si un sistema ha estat manipulat de forma maliciosa o si un crash pot haver deixat rastres dinformació sensible en disc.

A més dels bolcats de nucli complets, hi ha la possibilitat de treure bolcats de processos individuals (els clàssics core dumps), que són molt útils quan el que volem és fitar un problema a una aplicació concreta o revisar l'impacte en la confidencialitat d'un servei com un client de correu o de missatgeria.

Tipus de bolcats de memòria a Windows i la seva utilitat

En sistemes Windows, el propi sistema operatiu és capaç de generar diferents tipus de bolcats quan es produeix un STOP error. Cada modalitat inclou un nivell de detall diferent, per la qual cosa és clau saber quin tipus de bolcat necessitem segons el problema i les limitacions d'espai al disc.

Un dels formats més habituals en entorns d'usuari i molts servidors és el bolcat de memòria petit (small memory dump, minidump). És el que menys espai consumeix i sol situar-se a %SystemRoot%\Minidump, amb fitxers de l'estil MiniMMDDYY-01.dmp.

Aquest mini bolcat conté informació molt concreta però important: el codi d'error STOP i els paràmetres, la llista de controladors carregats en el moment de la fallada, el context del processador que es va aturar (PRCB), els contextos del procés i del fil implicats (estructures EPROCESS i ETHREAD) i la pila de trucades en mode kernel d'aquest fil.

Gràcies a aquestes estructures bàsiques, fins i tot amb un minidump es pot identificar moltes vegades quin driver o mòdul està provocant els penjats, encara que no sempre serà possible seguir tota la pista si el problema s'origina lluny del fil que s'estava executant al moment del crash i la informació de context disponible és limitada.

Windows també pot generar bolcats de memòria de kernel i bolcats complets, molt més grans, que contenen porcions o la totalitat de la memòria física. Aquests són especialment útils en anàlisi de baix nivell, investigacions forenses i debugging avançat de drivers o del propi sistema.

Configurar i obrir bolcats de memòria a Windows amb WinDbg i KD

Per aprofitar els bolcats a Windows, el primer és tenir ben configurades les opcions de inici i recuperació. Des del Panell de control, a les propietats avançades del sistema, es pot triar el tipus de bolcat que volem que es generi davant d'una fallada: per exemple, el “Volcat de memòria petit (256 KB)” i la ruta on s'emmagatzemarà.

El sistema necessita a més un arxiu de paginació al volum d'arrencada d'almenys uns quants megues per poder escriure el bolcat. En versions modernes de Windows, cada crash crea un nou fitxer i es manté un històric a la carpeta configurada, cosa que permet revisar incidents passats amb certa comoditat.

Un cop generats, hi ha diverses maneres de validar que els dumps són correctes. Una utilitat clàssica és Dumpchk.exe, que permet comprovar la integritat bàsica del fitxer i imprimir informació resumida. Per a anàlisis més avançades s'utilitzen les Eines de depuració per a Windows, que inclouen WinDbg (interfície gràfica) i KD (versió de línia d'ordres).

Després d'instal·lar el paquet de depuració des de la web de Microsoft, el més normal és que les eines quedin ubicades en una carpeta com C:\Program Files\Debugging Tools for Windows. Des d'aquí podem obrir un símbol del sistema i carregar un bolcat amb WinDbg o KD utilitzant el paràmetre -z per indicar el fitxer:

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

La ruta de símbols pot apuntar a un servidor de símbols amb memòria cau local, Per exemple:

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

Mentre que la ruta de binaris sol ser alguna cosa com C:\Windows\I386 o la carpeta on tinguem copiats els executables del sistema corresponents a la versió que va generar el dump. Això és important perquè els minidumps no inclouen tots els binaris, només referències a ells, així que el depurador necessita poder trobar-los.

Anàlisi bàsica d'un crash dump de kernel a Windows

Un cop carregat el bolcat amb WinDbg o KD, l'anàlisi d'un crash dump de kernel s'assembla força a una sessió de depuració post-mortem. La primera ordre que gairebé tothom executa és !analyze, que llança una anàlisi automàtica i genera un informe inicial.

la comanda !analyze -show mostra el codi de comprovació d'errors (bugcheck) i els seus paràmetres, mentre que !analyze -v produeix una sortida molt més detallada: mòdul sospitós, pila de trucades, informació contextual i, en molts casos, suggeriments sobre possibles causes o passos de diagnòstic.

Per complementar aquesta anàlisi, l'ordre .bugcheck imprimeix novament el codi d'error i els paràmetres associats, que es poden contrastar amb la referència de codis de bugcheck de Microsoft per conèixer el significat exacte de cada valor i les causes típiques.

la comanda lm N T (list modules) permet veure el llistat de mòduls carregats amb la ruta, adreces i estat, la qual cosa ajuda a confirmar si el driver assenyalat per lanàlisi automàtica està realment en memòria i quina versió és. Aquesta llista és especialment útil quan sospitem de drivers de tercers o components de seguretat que interactuen amb el kernel.

Si ho desitgem, podem simplificar la càrrega de bolcats creant un arxiu per lots que rebi la ruta al dump i llanci KD o WinDbg amb els paràmetres adequats. Així n'hi ha prou amb escriure una ordre curta que inclogui només la ubicació del fitxer i l'script s'encarrega de tota la resta.

Ús de WinDbg per a bolcats de kernel en profunditat

Per a bolcats de memòria en mode kernel, WinDbg ofereix a més la possibilitat de treballar amb múltiples arxius i sessions. Es poden obrir dumps des de la línia d'ordres amb -z, o bé des de la interfície gràfica, usant el menú Fitxer > Obrir bolcat de memòria o la drecera de teclat Control + D.

Si WinDbg ja està obert en mode passiu, només cal seleccionar el fitxer al quadre de diàleg “Obrir crash dump”, indicant la ruta o navegant pel disc. Un cop carregat, podem començar la sessió amb una ordre g (Go) en certs escenaris, o directament llançar les primeres ordres danàlisi.

A més del clàssic !analyze, convé familiaritzar-se amb la secció de referència d'ordres del depurador, que descriu totes les ordres disponibles per llegir estructures internes, examinar memòria, interpretar piles i molt més. Moltes d'aquestes tècniques són aplicables tant a sessions en viu com a bolcats fora de línia.

WinDbg permet també treballar amb múltiples bolcats en paral·lel. Podem afegir diversos paràmetres -z a la línia d'ordres, cadascun seguit d'un nom de fitxer diferent, o anar sumant nous objectius mitjançant l'ordre .opendump. La depuració de diverses destinacions és útil per comparar errors recurrents o incidents encadenats.

En alguns entorns, els bolcats de memòria s'empaqueten en fitxers CAB per estalviar espai o facilitar-ne l'enviament. WinDbg pot obrir directament un .cab amb un dump dins, tant mitjançant -z com amb .opendump, encara que llegirà només un dels bolcats continguts i no extraurà altres fitxers que poguessin anar al mateix paquet.

Crash dumps a Unix i Linux: utilitat, eines i requisits

En sistemes Unix i GNU/Linux, la filosofia és semblant però l'ecosistema d'eines canvia força. La majoria de kernels tipus Unix ofereixen la possibilitat de guardar una còpia de la memòria quan es produeix un esdeveniment catastròfic, El que coneixem com core dump o Kernel Crash Dump.

Tot i que l'ús principal continua sent el desenvolupament del nucli i de controladors, aquests bolcats tenen un vessant de seguretat clar. Un crash pot estar provocat per errors de programació, però també per accions malicioses fallides, intents de manipular components del sistema o condicions de carrera explotades de forma maldestre.

En un sistema Unix ben configurat no és habitual tenir col·lapses diaris, però quan ocorren, convé tenir-ne preparada una infraestructura de bolcat com Kdump, LKCD o altres solucions que permetin capturar la memòria del sistema. Això sí, cal valorar tant el valor diagnòstic del bolcat com el risc que contingui dades molt sensibles.

Una de les eines més completes i esteses per a aquest tipus danàlisi a Linux és xocar, inicialment impulsada per Red Hat. Aquesta utilitat ha esdevingut pràcticament un estàndard de facto per examinar bolcats de kernel i també per analitzar sistemes en execució.

Crash pot treballar contra la memòria viva del sistema a través de /dev/mem o, en distribucions Red Hat i derivades, mitjançant el dispositiu específic /dev/crash. Tot i així, el més habitual és alimentar l'eina amb un fitxer de bolcat generat per mecanismes com Kdump, makedumpfile, Diskdump o bolcats específics d'arquitectures com s390/s390x o xendump en entorns virtualitzats.

El paper de crash i la importància de vmlinux a Linux

La utilitat crash va néixer, en part, per superar les limitacions d'usar gdb directament sobre /proc/kcore. Entre altres coses, l'accés a aquesta pseudoimatge de memòria pot estar restringit i, a més, certes opcions de compilació del nucli dificulten interpretar adequadament les estructures internes si només tenim el binari executable comprimit.

Perquè crash funcioni correctament calen dos elements clau: un fitxer vmlinux compilat amb símbols de depuració (habitualment amb banderes com -g) i el mateix bolcat del nucli. Aquesta combinació permet a l'eina mapejar adreces de memòria a funcions, estructures i línies de codi.

És important distingir entre vmlinux i vmlinuz. A la majoria de sistemes només es veu vmlinuz, que és una versió comprimida i llesta per arrencar del nucli. Crash necessita el vmlinux descomprimit amb símbols; sense ell, en intentar carregar un dump o /dev/mem ens trobarem amb errors del tipus cannot find booted kernel — please enter namelist argument.

Encara que hi ha la possibilitat de descomprimir manualment vmlinuz, el procés no sempre és trivial i, a la pràctica, sol ser molt més còmode recompilar el nucli per obtenir tant vmlinux com vmlinuz en paral·lel. En entorns d'administració seriosa, és bona pràctica conservar el vmlinux corresponent a cada versió de nucli desplegat precisament per a aquests casos.

Un cop reunits els requisits, llançar crash contra un dump és relativament senzill: se li indica el vmlinux adequat i el fitxer de bolcat, i l'eina ens obre una sessió interactiva des de la qual podem recórrer estructures del nucli, llistar processos, veure piles de trucades i extreure informació forense. Qui vulgui aprofundir encara més pot consultar la documentació especialitzada, com ara el conegut whitepaper tècnic de crash.

Limitacions de /dev/mem i primeres aproximacions a Linux

Abans de recórrer a eines específiques, molts administradors han provat històricament a obtenir un bolcat de memòria llegint directament el dispositiu /dev/mem. Aquesta aproximació semblava senzilla: fer servir una eina com memdump (que bolca aquest dispositiu a STDOUT) o estirar dd if=/dev/mem of=volcado.mem.

No obstant això, en kernels moderns hi ha opcions de compilació com CONFIG_STRICT_DEVMEM, que limiten severament l'accés des d'espai d'usuari a /dev/mem. El resultat típic és que la lectura es talla després d'un petit bloc (per exemple, 1 MB) o, en el pitjor dels casos, un bug en aquesta interacció pot acabar en un pànic del nucli immediat i reinici de la màquina.

Aquesta protecció té tot el sentit del món des del punt de vista de seguretat, però ens obliga a cercar altres camins per obtenir un dump fiable i complet sense fiar-ho tot a dispositius de caràcter genèrics que ja no són tan accessibles com abans.

Per això la tendència actual és recolzar-se en mòduls específics o infraestructures de crash dump integrades, en lloc d'intentar “rascar memòria” sense més ni més amb eines d'espai d'usuari que no estan pensades per conviure amb les polítiques de protecció modernes del nucli.

LiME Forensics: extracció de memòria a Linux i Android

Una alternativa molt potent al món forense és LiME (Linux Memory Extractor), un mòdul de kernel dissenyat precisament per capturar la memòria volàtil de forma controlada i sense les restriccions que afecten a /dev/mem. LiME s'executa en espai de kernel, per la qual cosa podeu accedir a la RAM de manera molt més directa.

LiME es distribueix amb el seu codi font i es compila davant dels headers del kernel en ús. El procés de compilació genera un mòdul .ko específic per a la versió del nucli en què es carregarà. Un cop compilat, podem verificar-ho amb eines com file per assegurar-nos que s'ha generat correctament el mòdul ELF corresponent a la nostra arquitectura.

Per utilitzar LiME, només cal carregar el mòdul amb insmod des de root i passar-li les opcions adequades, per exemple indicant un destinació de bolcat per xarxa usant TCP i un format raw:

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

En paral·lel, a la màquina que rebrà el bolcat, escoltem pel port configurat amb una eina com nc, redirigint la sortida a un fitxer:

nc <IP_origen> 4444 > volcado.mem

Després d'uns minuts, segons la quantitat de RAM i el rendiment de la xarxa, tindrem un fitxer la mida del qual coincideix amb la memòria física del sistema origen. Es tracta d'un dump de RAM complet que podrem analitzar amb eines forenses o fins i tot amb strings o altres utilitaris com a primera passada per localitzar cadenes interessants.

Bolcats de processos i riscos dexposició de dades

Un kernel dump complet és extremadament informatiu, però també pot ser excessiu quan allò que ens interessa és un procés concret. En aquest cas, té molt sentit recórrer a bolcats de processos individuals usant eines com gcore a Unix/Linux.

Aquests bolcats per procés són molt més petits i manejables, i permeten centrar l'anàlisi en aplicacions específiques com un client de missatgeria (per exemple, Skype) o un client de correu (com Thunderbird), on és relativament senzill trobar contrasenyes en text clar, tokens de sessió o dades de contactes si s'exploren les cadenes de memòria.

Des del punt de vista del desenvolupament, aquests core dumps ajuden a localitzar errors de programació, fuites de memòria o estats inconsistents en un servei. Però, des de l'òptica de seguretat, el problema ve quan els bolcats es generen de forma rutinària i s'emmagatzemen en ubicacions accessibles a altres usuaris, ja sigui en el propi sistema o en recursos compartits de xarxa.

Si un usuari programa, per exemple, una tasca cron que captura periòdicament bolcats de processos sensibles i els deixa en un directori de lectura global, obrint una porta enorme a l'exposició d'informació crítica. A molts escenaris d'auditoria, analitzar aquests fitxers permet a un atacant recuperar credencials, llistes de contactes, historials de comunicació i altres dades privades amb un esforç relativament baix.

Per tot això, en qualsevol auditoria seriosa d'un sistema Unix convé dedicar uns minuts a comprovar si s'estan generant bolcats (totals o parcials), on es guarden, quins permisos tenen i si n'hi ha procés automatitzat que estigui deixant còpies de memòria a l'abast d'usuaris no autoritzats.

Anàlisi post-mortem de bolcats a FreeBSD amb kgdb

Al món BSD, i concretament a FreeBSD, l'aproximació a l'anàlisi post-mortem passa per habilitar els crash dumps al sistema i disposar d'un kernel compilat amb símbols de depuració. Això es controla des del directori de configuració del nucli, normalment a /usr/src/sys/<arq>/conf.

Al fitxer de configuració corresponent es pot activar la generació de símbols amb una línia com:

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

Després de modificar la configuració, cal recompilar el nucli. Alguns objectes es regeneraran (com trap.o) degut al canvi en els fitxers de construcció. L'objectiu és obtenir un kernel amb el mateix codi que el que presenta problemes, però afegint la informació de depuració necessària. Convé comparar les mides antiga i nova amb l'ordre size per assegurar-se que no hi ha hagut canvis inesperats al binari.

Un cop instal·lat el kernel amb símbols, ja podem examinar els dumps amb kgdb tal com es descriu a la documentació oficial. És possible que no tots els símbols estiguin complets, i algunes funcions apareguin sense números de línia o sense informació d'arguments, però en la majoria dels casos el nivell de detall és suficient per seguir la traça del problema.

No hi ha garantia absoluta que l'anàlisi resolgui tots els incidents, però, a la pràctica, aquesta estratègia funciona força bé en un alt percentatge d'escenaris, especialment quan es combinen els crash dumps amb una bona revisió de canvis recents al sistema.

Bones pràctiques d'anàlisi i documentació d'errors de kernel

Sigui quin sigui el sistema operatiu, l'anàlisi de bolcats de kernel sol acabar remetent a documentació tècnica, bases de coneixement, fòrums especialitzats o fins i tot al mateix codi font del nucli per interpretar missatges, codis derror i símbols poc coneguts.

A Linux, és molt útil recolzar-se a l'arbre de codi font oficial, la documentació integrada i recursos comunitaris. Molts missatges d'error del nucli es poden rastrejar fins al fitxer exacte on es generen, cosa que ajuda a entendre el context en què es dispara un BUG() o un WARN() determinat.

Al Windows, la documentació de Microsoft, la base de coneixement (KB) i els fòrums tècnics proporcionen explicacions detallades de codis de bugcheck, recomanacions de resolució i patrons d'errors coneguts. Combinant aquesta informació amb els informes de !analyze -v podeu traçar un pla de mitigació raonable.

El valor real d'un crash dump apareix quan es creua tota aquesta informació amb coneixements sòlids del sistema operatiu i de l'entorn concret on ha passat la sentència. Només així es poden plantejar solucions duradores i, sobretot, evitar que el mateix problema es repeteixi en el futur amb conseqüències més greus.

L'anàlisi de bolcats de memòria del nucli és, al final, una barreja de ciència i artesania: exigeix ​​eines adequades, configuració prèvia (símbols, opcions de bolcat, emmagatzematge segur) i una bona dosi d'experiència llegint piles, estructures i codis d'error. Dominar aquestes tècniques permet no només depurar incidents complexos, sinó també elevar dràsticament el nivell de seguretat i resiliència dels sistemes que administrem.