inVtero.net
inVteroCore.0.1
https://github.com/ShaneK2/inVtero.net/blob/master/quickdumps/publish.zip
Linux menggunakan server simbol untuk resolusi tipe, itu berfungsi;)
Lihat rilis inVteroCore untuk menyediakan integritas untuk XEN dan VMWare di Linux (atau di mana pun CORECLR berjalan, OSX & FBSD)
##$ PENTING (Pengguna Windows di .NET) => Anda harus memiliki msdia140.dll yang terdaftar "cmd /c regsvr32 msdia140.dll" (lihat zip)
Tidak diperlukan konfigurasi, sepenuhnya dinamis / pengetikan bebek
UI baru untuk format yang didukung pengeditan memori (dis/assemble dan patch). Gunakan "Loader()" pada instance vtero seperti;
Loader(test(MemList))
Ubah string MemoryDump untuk menunjuk ke dump memori. Contoh memory dump berjalan dan ketik penjelasan sistem di analisa.py, lihat WalkProcListExample()
quickdumps
>>> MemList = [ "c:\temp\win10.64.xendump" ]
>>> test(MemList)
++++++++++++++++++++++++++++++ ANALYZING INPUT [c:tempwin10.64.xendump] ++++++++++++++++++++++++++++++
PART RUNTIME: 00:00:08.5211677 (seconds), INPUT DUMP SIZE: 4,303,692,448.00 bytes.
SPEED: 466,980 KB / second (all phases aggregate time)
++++++++++++++++++++++++++++++ DONE WITH INPUT [c:tempwin10.64.xendump] ++++++++++++++++++++++++++++++
>>> Loader(vtero)
Temukan/Ekstrak proses, hypervisor (termasuk yang bersarang) dalam dump memori menggunakan teknik Introspeksi Mesin Virtual independen mikroarsitektur. Alat analisis memori fisik berkinerja tinggi multi-arsitektur dan lintas platform.
| x64 Rilis |
|---|
Quickdumps adalah contoh penggunaan API inVtero.net untuk mengekstrak dan memvalidasi memori fisik.
Cara kami menginisialisasi terjemahan alamat virtual ke fisik, tidak ada ketergantungan pada format file input. .DMP, .RAW, .DD apa pun seharusnya baik-baik saja. Sayangnya, ada masalah besar, jika format pengambilan yang mendasarinya menggunakan beberapa bentuk penyimpanan luas (yaitu tidak menggunakan penyimpanan fisik untuk halaman NULL, atau TIDAK PRESENT), jarak tempuh Anda mungkin bervariasi. Ada banyak alat untuk mengonversi dump memori, volatilitas - rekal adalah beberapa tempat yang baik untuk memulai. BITMAP. File DMP ada di tugas untuk membuat analisis liveump lebih mudah (saat ini semuanya berfungsi paling baik jika Anda melakukan layar biru yang dimulai secara manual dengan konfigurasi dump lengkap atau menggunakan alat tipe dd mentah pihak ketiga).
Beberapa konsep digunakan untuk memastikan kami berinteraksi dengan pengguna hanya jika diperlukan. Demikian pula, dengan proyek github Actaeon @eurecom-s3/actaeon, tujuan utamanya adalah menemukan dan memanfaatkan halaman VMCS untuk menemukan EPTP yang dikonfigurasi (penunjuk tabel halaman diperpanjang) yang diperlukan untuk menemukan halaman fisik milik a contoh OS tamu. Google @google/rekall rekal kemudian menerapkan implementasi yang lebih luas yang mengharuskan pengguna untuk menjalankan modul kernel Linux pada sistem asal dump memori tertentu yang dimaksudkan untuk membuat profil khusus yang dapat digunakan untuk kemudian mengimpor ke rekal lokal profil yang memungkinkan Anda mengisolasi/mengekstraksi memori tamu dari dump host fisik.
Selama CanSecWest/DC22 saya menyajikan teknik berkualitas tinggi (berdasarkan interaksi lapisan terendah antara lapisan CPU dan OS mm) untuk mengidentifikasi proses apa pun yang berjalan pada sistem dengan memeriksa snapshot memori fisik. Mekanisme ini didasarkan pada apa yang disebut self-pointer (Windows) atau penunjuk direktori halaman rekursif (*BSD) yang selalu diharapkan dapat ditemukan (kecuali sistem Windows Anda memiliki mm yang banyak dimodifikasi/ditambal, atau hanya kernel khusus untuk * BSD). Hasil akhirnya adalah kita mengetahui semua nilai register CR3 yang diberikan. Karena VMCS berisi setidaknya 1 nilai CR3 yang diketahui (nilai kedua dapat ditiru atau dipetakan ulang secara dinamis) kami yakin bahwa dump memori komprehensif dapat dilakukan tanpa mengetahui apa pun tentang versi OS yang mendasarinya (misalnya XP(64bit)->Win2016 adalah konsisten) atau mikroarsitektur.
Brute force selalu menang pada akhirnya! Atau begitulah yang saya dengar... Bagaimanapun, jika pemetaan VMCS yang tidak diketahui ditemukan (indeks EPTP), quickdumps akan mengeluarkan serangkaian nilai/indeks yang mungkin. Daftarnya biasanya kecil, paling banyak 10-20. Fitur yang akan datang adalah mengotomatiskan upaya untuk setiap nilai yang mungkin hingga nilai yang 'berfungsi' ditemukan. Ini akan memastikan kita bekerja untuk mikroarsitektur CPU yang akan datang tanpa perubahan kode apa pun (atau saya mungkin akan menyiapkan beberapa kelas yang menentukan ini untuk membuat hidup lebih mudah). Apa pun yang terjadi, pemaksaan secara kasar seharusnya dilakukan dengan cukup cepat. Saya mencoba memanfaatkan CPU multi-core semaksimal mungkin, jadi jika Anda memiliki core tambahan, kemungkinan besar core tersebut akan berfungsi jika Anda menganalisis dump besar dengan banyak VM.
Contoh dijalankan dari laptop:
Process CR3 [00000002DD41F000] File Offset [0000000293A12000] Diff [FFFFFFFFB65F3000] Type [Windows]
159 candiate process page tables. Time so far: 00:01:01.4826693, second pass starting. rate: 32588.149 MB/s
Hypervisor: VMCS revision field: 16384 [00004000] abort indicator: NO_ABORT [00000000]▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
Hypervisor: Windows CR3 found [00000000016A0000)] byte-swapped: [00006A0100000000] @ PAGE/File Offset = [00000001262DA000]
[435][00000000006F0054]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001308D3000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [0000000130AD1000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001314CF000]
[14][000000007433301E]
Hypervisor: VMCS revision field: 0 [00000000] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000016A0000)] byte-swapped: [00006A0100000000] @ PAGE/File Offset = [0000000160643000]
[106][00000000001E001C]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [0000000195922000]
[14][000000007433301E]
Hypervisor: VMCS revision field: VMWARE_NESTED [00000001] abort indicator: NO_ABORT [00000000]
Hypervisor: Windows CR3 found [00000000001AB000)] byte-swapped: [00B01A0000000000] @ PAGE/File Offset = [00000001959A3000]
[14][000000007433301E]
159 candiate VMCS pages. Time to process: 00:02:51.8973861
Data scanned: 34,171,150,654.00Second pass done. rate: 1277.967 MB/s▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
grouping and joinging all memory
Scanning for group correlations
MemberProces: Groupt 1 Type [Windows] Group Correlation [100.000 %] PID [1AB000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [16A0000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [1FCA000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [62AB000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [34CE8000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [37300000]
MemberProces: Groupt 1 Type [Windows] Group Correlation [90.909 %] PID [7DCC6000]
Finished Group 1 collected size 48 next group
Scanning for group correlations
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [65C8000]
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [6B51000]
MemberProces: Groupt 2 Type [FreeBSD] Group Correlation [100.000 %] PID [6CC9000]
Dalam contoh di atas, EPTP VMWARE berada pada indeks 14 di VMCS-nya.
* Kita akan lihat apakah saya dapat menghapus yang satu ini tetapi saat ini hanya membuang memori kernel dari setiap lapisan. Bekerja pada ruang pengguna dari VM OS tamu.
Banyak TODO tetapi saya akan menambahkannya sesegera mungkin. Masalah utama saat ini adalah saya sangat ragu untuk menambahkan apa pun yang disediakan OS meskipun itu akan sangat membantu. Saya pikir konteks yang cukup tersedia untuk menghindari penambahan ketergantungan OS logis. Saya suka bagaimana Rekal menjanjikan hal ini tetapi sepertinya arsip profil mereka juga sangat besar, jadi sedikit dari keduanya.
Masih ada sedikit pembersihan yang harus dilakukan. Ini masih tahap alfa, namun akan terus berkembang secara aktif.
Perluas ke jenis EPTP yang lebih dikenal sehingga tidak diperlukan kekerasan
Akan membuat indeks bitmap PFN untuk secara otomatis menentukan proses yang dijalankan (saat ini, jika Anda mencoba membuang/menanyakan apa pun setelah dijalankan, itu akan menyebabkan masalah atau terlewatkan, dll. Akan menambahkan ini selanjutnya untuk memastikan kami mendapatkan 100% dump yang komprehensif .
Untuk tidak menggunakan struktur logis OS untuk mendukung analisis memori. Kemungkinan besar sebagian besar struktur, data, kode, dan objek lapisan OS dapat dimanipulasi oleh penyerang untuk menyesatkan upaya analis.
Fungsionalitas yang akan datang untuk merender peta integritas untuk halaman kode yang dapat dipetakan kembali ke nilai hash blok/halaman yang aman secara kriptografis (yaitu SHA256 atau TIGER192). Hasil kami menunjukkan tingkat verifikasi sebelum win10 lebih dari 99%, memori volatil pasca win10 hampir 100% dapat dibuktikan. Hal ini menghilangkan dugaan-dugaan substansial dan ketidaktahuan karena penanganan/peninjauan/pembongkaran memori secara manual ketika mencoba mendeteksi/menganalisis input multi-gigabyte.
Dokumentasi
Implementasi GUI
