Z2A-BlackLotus チャレンジ ステージ2 ブートキット/ルートキット解析
BlackLotus ステージ2 ブートキット-ルートキット解析
この神がかった代物に踏み込む前に(信じてくれ、これは神の御心なしには誰にも成し得ない神がかった代物だ(少なくとも私の意見では))、ブートキットファイルのハッシュをここに示す
まず最初に、これが正常なシステムの見え方だ
identifier {bootmgr} device partition=\Device\HarddiskVolume9 path \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI description Windows Boot Manager locale en-US inherit {globalsettings} default {current} resumeobject {3f80ecd0-df10-11ed-bafc-80a84b2564bb} displayorder {current} toolsdisplayorder {memdiag} timeout 30
identifier {current} device partition=C: path \Windows\system32\winload.efi description Windows 10 locale en-US inherit {bootloadersettings} recoverysequence {3f80ecd2-df10-11ed-bafc-80a84b2564bb} displaymessageoverride Recovery recoveryenabled Yes isolatedcontext Yes allowedinmemorysettings 0x15000075 osdevice partition=C: systemroot \Windows resumeobject {3f80ecd0-df10-11ed-bafc-80a84b2564bb} nx OptIn bootmenupolicy Standard
さて、私の分析では、自分のマシンに感染させることはできなかったので、先ほど参照したアジアの研究者のブログ記事の例を使います。これは感染したものがどのように見えるべきかの例です。```
// Windows Boot Manager
// --------------------
// identifier {9dea862c-5cdd-4e70-acc1-f32b344d4795}
// description Windows Boot Manager
// locale en-US
// inherit {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
// bootdebug Yes
// displayorder {57e1b615-0355-11ec-abb0-005056c00008}
// timeout 30
// Windows Boot Loader
// -------------------
// identifier {57e1b615-0355-11ec-abb0-005056c00008}
// device boot
// path \system32\hvloader.efi
// description Hoy la disco se flota
// locale en-US
// inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
// truncatememory 0x10000000
// avoidlowmemory 0x1000
// nointegritychecks Yes
// testsigning Yes
// isolatedcontext Yes
// osdevice boot
// systemroot \
// ems Yes
=============================================================================
=============================================================================
始める前に、そもそもEFIモジュールを解析するための環境をどのようにセットアップするのでしょうか？ これは @MaverickMusic__ のおかげです。彼との議論の中で、彼は私にこれを渡してくれました( https://zhuanlan-zhihu-com.translate.goog/p/343293521?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-GB )。さて、私はそこにある手順を完全には従いませんでした。ここに、環境を立ち上げるために私が実際に行ったことを正確に示します：
-最初にedk2をインストールしました(https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems)
-次に、ovmfをリリースではなくデバッグとして構成しました(これは後で役立ちます)。コマンドは次のとおりです build -a X64 -t VS2019 -b DEBUG -p OvmfPkg/OvmfPkgX64.dsc
-第三に、windbgを構成する必要がありました。これをいったいどうやってやったのか？ 私はこのリンクからすべてをダウンロードしました(git clone https://github.com/microsoft/WinDbg-Samples)。それからExdiGdbSrv.slnをコンパイルしました。その後、私はこのリンク(https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-qemu-kernel-mode-debugging-using-exdi)にあるすべての手順を、`Use regsvr32 to register the DLL in an Administrator command prompt. と書かれている箇所から、PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files"まで実行しました。混乱するのは分かっていますが、すべての手順を説明するビデオを必ず作るので、どうか辛抱強く待ってください！ よし、これでデバッグ用の環境が整いました。では、いったいどうやってコードをデバッグするのでしょうか？ そこでqemuを起動します。私の場合、次のコマンドを実行して起動しましたqemu-system-x86_64.exe -L . -bios OVMF.fd -hdd dos.img -debugcon file:debug.log -global isa-debugcon.iobase=0x402`。qemuコマンドを実行すると、すぐにqemuのviewメニューからcompat_monitor0を選択しました。そうすると、次のように表示されるはずです。
また、これを選択した後、gdbserverと入力して、gdbデバッグのリモートインスタンスを起動します。これにwindbgを使って、次のコマンドでアタッチします .\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64。接続すると、次のように表示されます。
さて、この出力を解釈しましょう。私たちのケースでは、唯一関連する行は EntryPoint=0x000062C9A8C で、これはブートキットを実行する際の優先ロードアドレスのようなものです。具体的には、このブートキットでは 0x62C4A8C または 0x62C9A8C の間で変動します。これで IDA でプログラムをリベースして、通常の作業を進めることができます :) 。ブログの残りもお楽しみください!
=============================================================================
元の winload.efi と blacklotus がドロップした winload.efi を BinDiff で比較する
