inVtero.net
inVteroCore.0.1
https://github.com/ShaneK2/inVtero.net/blob/master/quickdumps/publish.zip
Linux は型解決にシンボル サーバーを使用しますが、それは問題なく機能します ;)
Linux (または CORECLR が実行される場所、OSX および FBSD) 上の XEN および VMWare の整合性を提供する inVteroCore リリースを確認してください。
##$ 重要 (.NET 上の Windows ユーザー) => msdia140.dll を「cmd /c regsvr32 msdia140.dll」として登録する必要があります (zip を参照)
設定は不要、完全に動的/ダックタイピング
メモリ編集 (逆アセンブルおよびパッチ) サポートされる形式のための新しい UI。 vtero インスタンスで「Loader()」を次のように使用します。
Loader(test(MemList))
MemoryDump 文字列をメモリ ダンプを指すように変更します。メモリ ダンプ ウォーキングの例と、analyze.py の型システムの説明。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)
マイクロアーキテクチャに依存しない仮想マシン イントロスペクション技術を使用して、メモリ ダンプ内のプロセス、ハイパーバイザー (ネストされたものを含む) を検索/抽出します。クロスプラットフォーム、マルチアーキテクチャの高性能物理メモリ分析ツール。
| x64 リリース |
|---|
Quickdumps は、inVtero.net API を使用して物理メモリを抽出して検証する例です。
仮想アドレスから物理アドレスへの変換を初期化する方法では、入力ファイル形式には依存しません。 .DMP、.RAW、.DD であればどれでも問題ありません。残念ながら、基盤となるキャプチャ形式が何らかの形式のエクステント ストレージを使用する (つまり、NULL または NOT PRESENT ページの物理ストレージを消費しない) 場合、使用できる距離は変わる可能性があります。メモリ ダンプやボラティリティを変換するためのツールはたくさんあります。まずは、ここから始めるとよいでしょう。ビットマップ。 DMP ファイルは、livedump の分析を容易にするために todo に含まれています (現時点では、完全なダンプを構成して手動でブルー スクリーンを開始するか、サードパーティの raw dd タイプ ツールを使用すると、最もうまく機能します)。
必要な場合にのみユーザーと対話できるようにするために、いくつかの概念が使用されています。同様に、Actaeon github プロジェクト @eurecom-s3/actaeon の主な目標は、VMCS ページを見つけて利用して、ゲスト OS インスタンス。その後、Google @google/rekall rekal は、ローカル rekal にインポートするために使用できる特殊なプロファイルを構築することを目的とした、特定のメモリ ダンプが発生したシステム上で Linux カーネル モジュールを実行することをユーザーに要求する、より拡張的な実装を実装しました。このプロファイルを使用すると、物理ホスト ダンプからゲスト メモリを分離/抽出できるようになります。
CanSecWest/DC22 中に、私は物理メモリのスナップショットを検査することでシステム上で実行されているプロセスを識別する高品質な手法 (CPU 層と OS mm 層の間の最下位層の相互作用に基づく) を紹介しました。このメカニズムは、自己ポインタ (Windows) または再帰的ページ ディレクトリ ポインタ (*BSD) と呼ばれるものに基づいており、常に見つかることが期待されています (Windows システムに大幅に変更/パッチが適用された mm、または単に * のカスタム カーネルがある場合を除く)。 BSD)。この最終結果は、与えられた CR3 レジスタ値をすべて知ることになります。 VMCS には少なくとも 1 つの既知の CR3 値が含まれているため (2 番目の値はエミュレートまたは動的に再マップされる可能性があります)、基盤となる OS バージョンについて何も知らなくても包括的なメモリ ダンプを実行できると確信しています (例: XP(64 ビット) -> Win2016 は、一貫性のある）またはマイクロアーキテクチャ。
結局のところ、力ずくで勝つのが常です!または、そう聞いています... いずれの場合でも、不明な VMCS マッピング (EPTP インデックス) が見つかった場合、クイックダンプは可能な値/インデックスのセットを出力します。通常、リストは小さく、多くても 10 ～ 20 です。今後の機能は、「機能する」値が見つかるまで、考えられる値ごとに試行を自動化することです。これにより、コードを変更することなく、今後の CPU マイクロアーキテクチャに対応できるようになります (または、作業を容易にするために、これらを指定するクラスをセットアップする可能性があります)。いずれにせよ、ブルート フォースはかなり迅速に行われるはずです。マルチコア CPU を最大限に活用するよう努めているため、追加のコアがある場合は、多くの VM による巨大なダンプを分析する場合に問題を解決できる可能性があります。
ラップトップから実行する例:
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]
上の例では、VMWARE の EPTP は VMCS のインデックス 14 にあります。
* これをノックアウトできるかどうか確認してみますが、現時点では各レイヤーからカーネル メモリをダンプしているだけです。ゲスト OS VM からのユーザー空間での作業。
TODOはたくさんありますが、できるだけ早く追加するつもりです。現時点での主な問題は、たとえそれが非常に役立つとしても、OS が提供するものを追加することに非常に躊躇していることです。論理的な OS 依存関係の追加を避けるために十分なコンテキストが利用可能であると思います。 Rekal がこれを約束する方法は気に入っていますが、彼らのプロフィール アーカイブも非常に大きいようですので、両方を少しずつ。
まだ少し掃除が残っています。これはまだアルファ版ですが、積極的に開発される予定です。
より既知の EPTP タイプに拡張できるため、総当たり攻撃は必要ありません
実行内容を自動的に判断するための PFN ビットマップ インデックスを作成します (現時点では、実行後に何かをダンプ/クエリしようとすると、問題が発生したり、失敗したりする可能性があります。100% 包括的なダンプを確実に取得できるように、次にこれを追加する予定です) 。
メモリ分析をサポートするために OS の論理構造を使用しないようにします。ほとんどの OS 層構造、データ、コード、およびオブジェクトは、分析者の努力を誤った方向に向けるために攻撃者によって操作される可能性があります。
暗号的に安全なブロック/ページ ハッシュ値 (つまり、SHA256 または TIGER192) にマップバックできるコード ページの整合性マップをレンダリングする今後の機能。私たちの結果は、win10 以前の検証率は 99% 以上で、win10 以降の揮発性メモリは事実上 100% 検証可能であることを示しています。これにより、数ギガバイトの入力を検出/分析しようとする際の、従来の手動によるメモリの処理/レビュー/分解に起因する大幅な推測作業や不明な作業が排除されます。
ドキュメント
GUIの実装
