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), "관리자 명령 프롬프트에서 regsvr32를 사용하여 DLL을 등록하십시오."라고 나온 부분부터 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에서 프로그램을 리베이스하고 평소처럼 작업을 할 수 있습니다 :) . 나머지 블로그도 즐기세요!
=============================================================================
Bindiffing 원본 winload.efi와 blacklotus가 드롭한 파일
```