Analisis dump memori dan kernel pada sistem Windows dan Unix.

Informatec Digital » Sumber daya » Analisis dump memori dan kernel pada sistem Windows dan Unix.

Ketika sebuah sistem operasi mengalami panic atau crash secara spektakuler, satu-satunya cara untuk memahami apa yang terjadi adalah dengan... Pengambilan data memori kernel dan analisis selanjutnyaData hasil dump ini menangkap kondisi internal sistem pada saat terjadi kegagalan dan merupakan bahan mentah untuk men-debug kesalahan yang kompleks, menyelidiki insiden keamanan, atau melakukan pemeriksaan forensik.

Meskipun mungkin terdengar sangat "tingkat rendah," menganalisis dump memori bukanlah hal yang eksklusif bagi pengembang kernel. Administrator sistem, insinyur dukungan, dan bahkan auditor keamanan dapat memperoleh manfaat darinya jika mereka mengetahui dasar-dasarnya. alat yang tepat, jenis data yang dibuang, dan teknik interpretasi dasar.Kami akan membahas seluruh proses ini di Windows, Unix/Linux, dan BSD, menggunakan alat-alat seperti WinDbg, crash, kgdb, dan LiME.

Apa itu kernel memory dump dan mengapa penting untuk menganalisisnya?

Sebuah dump memori kernel (sering disebut Kernel Crash Dump atau singkatnya crash dump) adalah file yang berisi salinan, seluruhnya atau sebagian, dari memori pada saat sistem mengalami kegagalan kritis, seperti panik kernel di Unix/Linux atau layar biru kematian (BSOD) di Windows.

Dalam praktiknya, dump jenis ini menyimpan struktur kernel internal, tumpukan panggilan, konteks proses, dan driver yang dimuatBerkat hal ini, setelah bencana, analisis "pasca-mortem" dapat dilakukan, sangat mirip dengan proses debugging pada sistem yang sedang beroperasi, tetapi tanpa tekanan harus menyentuh mesin produksi saat sedang mengalami kerusakan.

Alasan untuk mempelajari kernel dump secara mendalam sangat beragam: mulai dari Memperbaiki bug yang tampaknya acak dan kerusakan yang terjadi sesekali....bahkan menyelidiki apakah suatu sistem telah dimanipulasi secara jahat atau apakah kerusakan sistem mungkin meninggalkan jejak informasi sensitif di disk.

Selain dump kernel lengkap, ada kemungkinan untuk mengekstrak dump dari proses individual (klasik pembuangan inti), yang sangat berguna ketika yang kita inginkan adalah untuk membatasi suatu masalah pada aplikasi tertentu atau untuk meninjau dampaknya terhadap kerahasiaan suatu layanan. seperti aplikasi email atau pesan instan.

Jenis-jenis memory dump di Windows dan kegunaannya

Pada sistem Windows, sistem operasi itu sendiri dapat menghasilkan berbagai jenis dump ketika terjadi kesalahan STOP. Setiap jenis menyertakan tingkat detail yang berbeda, jadi sangat penting untuk mengetahui mana yang harus digunakan. Jenis dump apa yang kita butuhkan berdasarkan masalah dan keterbatasan ruang disk?.

Salah satu format yang paling umum di lingkungan pengguna dan banyak server adalah dump memori kecil (minidump)Ini adalah yang paling hemat tempat dan biasanya terletak di %SystemRoot%\Minidump, dengan berkas-berkas gaya tersebut MiniMMDDYY-01.dmp.

Dokumen singkat ini berisi informasi yang sangat spesifik namun penting: yaitu: Kode kesalahan STOP dan parameternya, daftar driver yang dimuat pada saat kegagalan, konteks prosesor yang berhenti (PRCB), konteks proses dan thread yang terlibat (struktur EPROCESS dan ETHREAD) dan tumpukan panggilan mode kernel dari thread tersebut.

Berkat struktur dasar ini, bahkan dengan minidump pun seringkali memungkinkan untuk mengidentifikasi driver atau modul mana yang menyebabkan crash, meskipun tidak selalu mungkin untuk melacak seluruh masalah jika masalah tersebut berasal jauh dari thread yang sedang berjalan pada saat crash terjadi. Informasi kontekstual yang tersedia terbatas..

Windows juga dapat menghasilkan dump memori kernel dan dump lengkap yang jauh lebih besar yang berisi sebagian atau seluruh memori fisik. Ini sangat berguna dalam analisis tingkat rendah, investigasi forensik, dan debugging tingkat lanjut pada driver atau sistem itu sendiri.

Mengkonfigurasi dan membuka dump memori di Windows dengan WinDbg dan KD.

Untuk memanfaatkan dump di Windows, hal pertama yang harus dilakukan adalah mengkonfigurasi opsi dengan benar. memulai dan memulihkanDari Panel Kontrol, di properti sistem lanjutan, Anda dapat memilih jenis dump yang ingin Anda hasilkan jika terjadi kegagalan: misalnya, "Dump memori kecil (256 KB)" dan jalur tempat dump tersebut akan disimpan.

Sistem ini juga membutuhkan berkas paging pada volume boot minimal beberapa megabyte untuk menulis file dump. Pada versi Windows modern, setiap crash akan membuat file baru dan riwayatnya akan disimpan dalam folder yang telah dikonfigurasi, sehingga memudahkan peninjauan insiden sebelumnya.

Setelah dihasilkan, ada beberapa cara untuk memvalidasi kebenaran dump tersebut. Salah satu alat klasik adalah Dumpchk.exeyang memungkinkan Anda untuk memeriksa integritas dasar file dan mencetak informasi ringkasan. Untuk analisis yang lebih lanjut, berikut ini digunakan: Alat Debugging untuk Windows, yang mencakup WinDbg (antarmuka grafis) dan KD (versi baris perintah).

Setelah menginstal paket debugging dari situs web Microsoft, alat-alat tersebut biasanya terletak di dalam folder seperti ini: C:\Program Files\Alat Debugging untuk WindowsDari situ kita bisa membuka command prompt dan memuat dump dengan WinDbg atau KD menggunakan parameter -z untuk menentukan file:

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

Jalur simbol dapat menunjuk ke sebuah server simbol dengan cache lokal, misalnya:

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

Meskipun jalur biner biasanya seperti ini: C:\Windows\I386 atau folder tempat kita menyalin file eksekusi sistem yang sesuai dengan versi yang menghasilkan dump tersebut. Ini penting karena Minidump tidak mencakup semua file biner., hanya referensi ke sana, jadi debugger perlu dapat menemukannya.

Analisis dasar dari dump crash kernel di Windows

Setelah dump dimuat dengan WinDbg atau KD, menganalisis dump crash kernel sangat mirip dengan sesi debugging post-mortem. Perintah pertama yang hampir semua orang jalankan adalah !menganalisayang meluncurkan analisis otomatis dan menghasilkan laporan awal.

Perintah !analyze -show menunjukkan Kode bugcheck dan parameternyaSementara !analyze -v Ini menghasilkan keluaran yang jauh lebih detail: modul yang dicurigai, tumpukan panggilan, informasi kontekstual dan, dalam banyak kasus, saran tentang kemungkinan penyebab atau langkah-langkah diagnostik.

Untuk melengkapi analisis tersebut, perintahnya adalah... .bugcheck Program ini mencetak ulang kode kesalahan dan parameter terkait, yang kemudian dapat dibandingkan dengan referensi kode bugcheck dari Microsoft untuk mempelajari arti pasti dari setiap nilai dan penyebab umumnya.

Perintah lm N T (daftar modul) memungkinkan Anda untuk melihat Daftar modul yang dimuat beserta jalur, alamat, dan statusnya.Ini membantu memastikan apakah driver yang diidentifikasi oleh analisis otomatis benar-benar ada di memori dan versi berapa driver tersebut. Daftar ini sangat berguna ketika kita mencurigai driver pihak ketiga atau komponen keamanan yang berinteraksi dengan kernel.

Jika diinginkan, kita dapat menyederhanakan proses pemuatan dump dengan membuat sebuah berkas batch Skrip ini menerima jalur ke file dump dan menjalankan KD atau WinDbg dengan parameter yang sesuai. Dengan cara ini, Anda hanya perlu menulis perintah singkat yang mencakup lokasi file, dan skrip akan menangani sisanya.

Menggunakan WinDbg untuk dump kernel mendalam.

Untuk dump memori mode kernel, WinDbg juga menawarkan kemampuan untuk bekerja dengan banyak file dan sesi. Dump dapat dibuka dari baris perintah dengan -zatau dari antarmuka grafis, menggunakan menu File > Open Memory Dump atau pintasan keyboard. Ctrl + D.

Jika WinDbg sudah terbuka dalam mode pasif, cukup pilih file di kotak dialog "Buka dump crash", tentukan jalurnya atau telusuri disk. Setelah dimuat, kita dapat memulai sesi dengan sebuah perintah. g (Go) dalam skenario tertentu, atau langsung menjalankan perintah analisis pertama.

Selain klasik !analyzeSebaiknya Anda membiasakan diri dengan hal tersebut. bagian referensi perintah debuggerIni menjelaskan semua perintah yang tersedia untuk membaca struktur internal, memeriksa memori, menginterpretasikan tumpukan, dan banyak lagi. Banyak dari teknik ini dapat diterapkan baik pada sesi langsung maupun dump offline.

WinDbg juga memungkinkan Anda untuk bekerja dengan beberapa pembuangan paralelKita dapat menambahkan beberapa parameter -z pada baris perintah, masing-masing diikuti oleh nama file yang berbeda, atau menambahkan target baru menggunakan perintah tersebut. .opendumpMelakukan debugging pada beberapa tujuan berguna untuk membandingkan kegagalan yang berulang atau insiden berantai.

Di beberapa lingkungan, dump memori dikemas ke dalam file CAB untuk menghemat ruang atau mempermudah transmisi. WinDbg dapat langsung membukanya. .cab dengan dump di dalamnya, baik menggunakan -z maupun dengan .opendumpmeskipun dia akan membaca Program ini hanya akan mengekstrak salah satu file yang telah di-dump dan tidak akan mengekstrak file lainnya. yang bisa dimasukkan dalam satu paket yang sama.

File dump crash di Unix dan Linux: kegunaan, alat, dan persyaratannya.

Pada sistem Unix dan GNU/Linux, filosofinya serupa, tetapi ekosistem perangkatnya berbeda secara signifikan. Sebagian besar kernel mirip Unix menawarkan kemungkinan untuk Simpan salinan memori saat terjadi peristiwa bencana., apa yang kita kenal sebagai pembuangan inti atau Kernel Crash Dump.

Meskipun penggunaan utamanya tetap untuk pengembangan kernel dan driver, dump ini memiliki aspek keamanan yang jelas. Sebuah crash dapat disebabkan oleh... kesalahan pemrograman, tetapi juga tindakan jahat. Upaya yang gagal untuk memanipulasi komponen sistem atau mengeksploitasi kondisi persaingan (race condition) secara ceroboh.

Dalam sistem Unix yang terkonfigurasi dengan baik, kerusakan harian bukanlah hal yang umum, tetapi ketika hal itu terjadi, ada baiknya memiliki rencana cadangan. infrastruktur dumping seperti Kdump, LKCD, atau solusi lainnya yang memungkinkan untuk menangkap memori sistem. Namun, perlu mempertimbangkan baik nilai diagnostik dari dump tersebut maupun risiko bahwa dump tersebut berisi data yang sangat sensitif.

Salah satu alat yang paling lengkap dan banyak digunakan untuk jenis analisis ini di Linux adalah tabrakanAwalnya dikembangkan oleh Red Hat, utilitas ini telah menjadi standar de facto untuk memeriksa dump kernel dan menganalisis sistem yang sedang berjalan.

Crash dapat berdampak negatif terhadap memori aktif sistem melalui /dev/mem atau, pada Red Hat dan distribusi turunannya, menggunakan perangkat khusus tersebut. /dev/crashMeskipun demikian, praktik umum yang dilakukan adalah memasukkan file dump yang dihasilkan oleh mekanisme seperti ke dalam alat tersebut. Kdump, file makedump, Disk dump atau dump khusus arsitektur seperti s390/s390x atau xendump dalam lingkungan tervirtualisasi.

Peran crash dan pentingnya vmlinux dalam Linux

Utilitas crash dibuat, sebagian, untuk mengatasi keterbatasan penggunaan gdb langsung pada /proc/kcoreAntara lain, akses ke citra semu memori tersebut mungkin dibatasi, dan, selain itu, opsi kompilasi kernel tertentu mempersulit interpretasi struktur internal dengan benar jika kita hanya memiliki biner eksekusi terkompresi.

Agar crash berfungsi dengan benar, dua elemen kunci diperlukan: ​​a berkas vmlinux yang dikompilasi dengan simbol debugging (biasanya dengan flag seperti -g) dan dump kernel itu sendiri. Kombinasi ini memungkinkan alat tersebut untuk memetakan alamat memori ke fungsi, struktur, dan baris kode.

Penting untuk membedakannya vmlinux dan vmlinuzPada sebagian besar sistem, hanya vmlinux yang terlihat, yaitu versi kernel yang terkompresi dan dapat di-boot. Crash membutuhkan vmlinux yang telah didekompresi secara simbolis; tanpanya, saat mencoba memuat dump atau /dev/mem Kita akan menemukan kesalahan jenis ini. Kernel yang di-boot tidak ditemukan — harap masukkan argumen namelist..

Meskipun dimungkinkan untuk mendekompilasi vmlinuz secara manual, prosesnya tidak selalu mudah dan, dalam praktiknya, biasanya jauh lebih nyaman. Kompilasi ulang kernel untuk mendapatkan vmlinux dan vmlinuz. Secara paralel. Dalam lingkungan administrasi yang serius, praktik yang baik adalah memelihara vmlinux yang sesuai dengan setiap versi kernel yang digunakan khusus untuk kasus-kasus ini.

Setelah persyaratan terpenuhi, melakukan crash pada dump relatif mudah: Anda menentukan vmlinux dan file dump yang sesuai, dan alat tersebut akan membuka sesi interaktif tempat Anda dapat menelusuri struktur kernel, mencantumkan proses, melihat tumpukan panggilan, dan mengekstrak informasi forensik.Bagi yang ingin mempelajari lebih dalam lagi dapat merujuk pada dokumentasi khusus, seperti whitepaper teknis tentang kegagalan sistem yang sudah terkenal.

Keterbatasan /dev/mem dan pendekatan awal di Linux

Sebelum menggunakan alat-alat khusus, banyak administrator secara historis telah mencoba untuk mendapatkan dump memori. membaca langsung dari perangkat /dev/memPendekatan ini tampak sederhana: gunakan alat seperti memdump (yang akan mengirimkan output perangkat tersebut ke STDOUT) atau mengambil dari dd if=/dev/mem of=volcado.mem.

Namun, kernel modern menawarkan opsi kompilasi seperti KONFIG_STRICT_DEVMEMyang sangat membatasi akses dari ruang pengguna ke /dev/memHasil tipikalnya adalah pembacaan terputus setelah blok kecil (misalnya, 1 MB) atau, dalam kasus terburuk, bug dalam interaksi tersebut dapat berujung pada panik kernel Segera lakukan restart mesin.

Perlindungan ini sangat masuk akal dari sudut pandang keamanan, tetapi memaksa kita untuk mencari Cara lain untuk mendapatkan dump yang andal dan lengkap tanpa sepenuhnya bergantung pada perangkat generik yang tidak lagi semudah diakses seperti sebelumnya.

Oleh karena itu, tren saat ini adalah mengandalkan modul spesifik atau infrastruktur dump crash terintegrasi, alih-alih hanya mencoba "mengikis memori" dengan alat ruang pengguna yang tidak dirancang untuk hidup berdampingan dengan kebijakan perlindungan kernel modern.

LiME Forensics: Ekstraksi Memori di Linux dan Android

Alternatif yang sangat ampuh di dunia forensik adalah LiME (Linux Memory Extractor)LiME adalah modul kernel yang dirancang khusus untuk menangkap memori volatil secara terkontrol dan tanpa batasan yang memengaruhi /dev/mem. LiME berjalan di ruang kernel, sehingga dapat mengakses RAM secara jauh lebih langsung.

LiME didistribusikan bersama kode sumbernya dan dikompilasi terhadap header kernel yang digunakanProses kompilasi menghasilkan sebuah modul. .ko spesifik untuk versi kernel tempat ia akan dimuat. Setelah dikompilasi, kita dapat memverifikasinya dengan alat-alat seperti... file untuk memastikan bahwa modul ELF yang sesuai dengan arsitektur kami telah dihasilkan dengan benar.

Untuk menggunakan LiME, cukup muat modul dengan insmod dari root dan meneruskan opsi yang sesuai, misalnya dengan menentukan sebuah Tujuan pengambilan data jaringan menggunakan TCP dan format mentah.:

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

Secara paralel, pada mesin yang akan menerima dump, kita mendengarkan pada port yang telah dikonfigurasi menggunakan alat seperti ncMengalihkan output ke file:

nc <IP_origen> 4444 > volcado.mem

Setelah beberapa menit, tergantung pada jumlah RAM dan kinerja jaringan, kita akan memiliki file yang ukurannya sesuai dengan memori fisik sistem sumber. Ini adalah sebuah sebuah dump RAM lengkap yang dapat kita analisis dengan alat forensik atau bahkan dengan string atau utilitas lainnya. sebagai langkah pertama untuk menemukan jaringan toko yang menarik.

Risiko kebocoran proses dan data

Pengambilan data kernel lengkap sangat informatif, tetapi juga bisa berlebihan jika kita hanya tertarik pada proses tertentu. Dalam hal ini, masuk akal untuk menggunakan... dump proses individu menggunakan alat seperti gcore di Unix/Linux.

Data per proses ini jauh lebih kecil dan lebih mudah dikelola, dan memungkinkan Anda untuk memfokuskan analisis pada aplikasi tertentu seperti klien pesan (misalnya, Skype) atau klien email (seperti Thunderbird), di mana relatif mudah untuk menemukan informasi yang dibutuhkan. kata sandi dalam teks biasa, token sesi, atau data kontak jika string memori dieksplorasi.

Dari perspektif pengembangan, core dump ini membantu menemukan kesalahan pemrograman, kebocoran memori, atau keadaan yang tidak konsisten dalam suatu layanan. Namun dari perspektif keamanan, masalah muncul ketika... Data hasil dump dihasilkan secara rutin dan disimpan di lokasi yang dapat diakses oleh pengguna lain.baik pada sistem itu sendiri maupun pada sumber daya jaringan bersama.

Jika pengguna menjadwalkan, misalnya, sebuah tugas cron Dengan secara berkala mengambil salinan proses sensitif dan menyimpannya di direktori yang dapat dibaca secara global, penyerang membuka pintu besar bagi terungkapnya informasi penting. Dalam banyak skenario audit, menganalisis file-file ini memungkinkan penyerang untuk memulihkan informasi tersebut. kredensial, daftar kontak, riwayat komunikasi, dan data pribadi lainnya dengan usaha yang relatif rendah.

Oleh karena itu, dalam setiap audit serius terhadap sistem Unix, disarankan untuk meluangkan beberapa menit untuk memeriksa apakah dump (lengkap atau sebagian) dihasilkan, di mana dump tersebut disimpan, izin apa yang dimilikinya, dan apakah ada hal lain yang perlu diperhatikan. proses otomatis yang membiarkan salinan memori dapat diakses oleh pengguna yang tidak berwenang.

Analisis post-mortem dari dump di FreeBSD dengan kgdb

Dalam dunia BSD, dan khususnya di FreeBSD, pendekatan terhadap analisis post-mortem melibatkan Aktifkan dump crash pada sistem dan pastikan kernel dikompilasi dengan simbol debugging.Hal ini dikendalikan dari direktori konfigurasi kernel, biasanya di /usr/src/sys/<arq>/conf.

Dalam file konfigurasi yang bersangkutan, pembuatan simbol dapat diaktifkan dengan baris seperti ini:

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

Setelah memodifikasi konfigurasi, kernel harus dikompilasi ulang. Beberapa objek akan dibuat ulang (seperti trap.o) karena perubahan pada file build. Tujuannya adalah untuk mendapatkan kernel dengan Kode yang sama dengan yang bermasalah, tetapi menambahkan informasi debugging yang diperlukan.Sebaiknya bandingkan ukuran lama dan baru menggunakan perintah tersebut. size untuk memastikan bahwa tidak ada perubahan tak terduga dalam data biner.

Setelah kernel diinstal menggunakan simbol, kita sekarang dapat memeriksa dump dengan kgdb seperti yang dijelaskan dalam dokumentasi resmi. Tidak semua simbol mungkin lengkap, dan beberapa fungsi mungkin muncul tanpa nomor baris atau informasi argumen, tetapi dalam kebanyakan kasus tingkat detailnya cukup untuk melacak masalahnya.

Tidak ada jaminan mutlak bahwa analisis ini akan menyelesaikan semua insiden, tetapi, dalam praktiknya, Strategi ini cukup efektif dalam sebagian besar skenario.terutama ketika dump crash digabungkan dengan tinjauan yang baik tentang perubahan sistem terbaru.

Praktik terbaik untuk menganalisis dan mendokumentasikan kesalahan kernel

Terlepas dari sistem operasinya, analisis kernel dump biasanya berujung pada dokumentasi teknis, basis pengetahuan, forum khusus, atau bahkan kode sumber kernel itu sendiri untuk menafsirkan pesan, kode kesalahan, dan simbol yang tidak dikenal.

Di Linux, sangat membantu untuk mengandalkan pohon kode sumber resmi, dokumentasi bawaan, dan sumber daya komunitas. Banyak pesan kesalahan kernel dapat dilacak kembali ke file persis tempat asalnya, yang membantu dalam memahami masalah tersebut. konteks di mana BUG() atau WARN() dipicu bertekad.

Di Windows, dokumentasi Microsoft, basis pengetahuan (KB), dan forum teknisnya menyediakan penjelasan rinci tentang Kode bugcheck, rekomendasi penyelesaian, dan pola kesalahan yang diketahui.Dengan menggabungkan informasi tersebut dengan laporan !analyze -v, dimungkinkan untuk menyusun rencana mitigasi yang masuk akal.

Nilai sebenarnya dari dump crash muncul ketika semua informasi tersebut dibandingkan dengan pengetahuan mendalam tentang sistem operasi dan lingkungan spesifik tempat terjadinya kegagalan.Hanya dengan cara ini solusi jangka panjang dapat diusulkan dan, yang terpenting, mencegah masalah yang sama terulang kembali di masa depan dengan konsekuensi yang lebih serius.

Analisis dump memori kernel pada akhirnya merupakan perpaduan antara sains dan keterampilan: hal ini membutuhkan alat yang tepat, konfigurasi sebelumnya (simbol, opsi dump, penyimpanan yang aman), dan banyak pengalaman dalam membaca stack, struktur, dan kode kesalahan. Menguasai teknik-teknik ini memungkinkan Anda tidak hanya untuk men-debug insiden yang kompleks, tetapi juga untuk meningkatkan secara drastis tingkat keamanan dan ketahanan sistem yang kami kelola..