閱讀：

2,905

QEMU是開發(fā)者在調(diào)試一些不同架構(gòu)的程序時經(jīng)常使用的虛擬機軟件。它有兩種運行模式，全系統(tǒng)模擬(System mode)和單程序運行(User mode)。System mode和開發(fā)者平常用的VMWare一樣，模擬整個系統(tǒng)從加載器開始的啟動和運行。在設(shè)備逆向過程中，如果僅僅是為了運行開發(fā)者提取出文件系統(tǒng)中的某一個程序，那就可以使用QEMU的user mode來簡化整個操作流程，同時能夠方便的利用 QEMU 自帶的GDB服務(wù)來進行調(diào)試，免去搭建環(huán)境的煩惱。

但是，單單在命令行中調(diào)用“qemu-arm myprogram”往往沒有那么簡單，因為動態(tài)鏈接的程序都會依賴幾個動態(tài)鏈接庫。雖然可以傳入 -L 參數(shù)，或者通過指定環(huán)境變量QEMU_LD_PREFIX解決，但這種方式不但不優(yōu)雅，還會造成重復(fù)性的工作——每個程序依賴的庫不同，因此每次都要選擇不同的目錄。而且使用這種方式啟動的程序，所運行的程序文件夾(CWD)與原來不同，很可能訪問不了程序中硬編碼的一些文件的絕對路徑，造成程序出錯。

因此最簡單直接的方法還是使用chroot配合QEMU，來完全模擬程序的文件系統(tǒng)環(huán)境，以固件的根目錄作為chroot的根目錄，程序也能夠自動加載到它所需要的libc與其他各種函數(shù)庫。綠盟的小伙伴在看雪上做過一次分享，我聽過后以為很容易上手，但是操作時踩到了一些坑。這里總結(jié)一下整個流程，順便講解一下其中的原理。

編譯安裝

Ubuntu自帶的 QEMU 版本有點老(我的18.04 LTS 附帶的 QEMU 2.11)，在調(diào)試時會遇到類似下面的報錯：~ # ./gdbserver tcp:2333 /usr/bin/messagingagent

qemu: Unsupported syscall: 117

老版本QEMU不能夠很好的處理與調(diào)試相關(guān)的ptrace系統(tǒng)調(diào)用，我們需要從官方的最新版源代碼編譯安裝QEMU。

依賴的安裝可以參考官方教程。安裝好依賴后從git獲取最新的源碼，并使用以下參數(shù)指定編譯的QEMU采用靜態(tài)鏈接，最后進行編譯。我在這里指定prefix目錄為當前目錄下的 staging，自己操作時可以隨意更改。git clone git://git.qemu.org/qemu.git --recurse-submodules --depth 1

cd qemu

./configure --static --prefix="$PWD/staging/user-static" --disable-system --enable-linux-user

make –j8 && make install

然后 staging/user-static 目錄下就是我們編譯好的核武器了。

安裝binfmt

binfmt(Binary Format)是一個內(nèi)核模塊，它的用處如它的名字，通過二進制文件頭來識別它的格式，從而指定用哪個解釋器去啟動——可以理解為二進制文件的hashbang(用處類似于在Python文件的第一行寫上“#!/usr/bin/env python”)。有了它我們就可以像啟動原生ELF一樣啟動一個ARM或其他任何QEMU支持的程序了。sudo apt install qemu-user-binfmt

update-binfmts --display

安裝這個包會依賴安裝系統(tǒng)軟件源中的qemu-user。我們用不到它，但裝這個包的意義在于它包含了幾個自動向內(nèi)核注冊QEMU binfmt的腳本，這樣我們就不需要再手動指定我們的ARM可執(zhí)行文件需要哪個路徑下的QEMU來執(zhí)行，非常方便。安裝成功后在命令行中執(zhí)行“update-binfmts –display”。

圖 1 update-binfmts輸出

我們此時可以測試一下，臨時將環(huán)境變量QEMU_LD_PREFIX設(shè)置為我們要chroot進去的根目錄，然后運行ARM設(shè)備中提取出的ELF可執(zhí)行文件，如果不報錯就可以了。圖中a.out是我編譯的arm64的hello world，這個程序可在我的測試設(shè)備上正常運行。

圖 2 運行示例程序 Hello World

復(fù)制QEMU程序

hello world可以運行之后，我們還需要準備一下我們的rootfs目錄。

將第一步編譯目錄中的“staging/user-static/qemu-aarch64”復(fù)制到“update-binfmts”中顯示的對應(yīng)位置(/usr/bin/qemu-aarch64)，如果必要的話，將這里的aarch64替換成你所要運行的程序架構(gòu)。注意必須是相同位置！當我們啟動為ARM或其他架構(gòu)編譯的應(yīng)用程序時，系統(tǒng)會調(diào)用binfmts識別它的類型并調(diào)用之前注冊的interpreter(如/usr/bin/qemu-aarch64)來“翻譯”啟動。在chroot下，依然會從這個路徑中尋找。因此如果chroot后這個路徑下找不到QEMU，啟動任何程序都會報錯No such file or directory。這個報錯會有很多歧義，因此一定要自己確認一下QEMU確實在rootfs的“/usr/bin”目錄中。

運行sudo chroot . /bin/sh

到這里，我們就可以像在虛擬機中一樣，通過shell運行這個chroot中的所有程序了！

總結(jié) Xxx not found 相關(guān)的問題

當我運行一個命令時，# ./run_xxx_command

報一個錯——run_xxx_command :No such file or directory

我的第一反應(yīng)肯定是懷疑自己。程序名稱輸錯了？但又不對，我怎么可能這么蠢呢？一路摸爬滾打下來，我發(fā)現(xiàn)最蠢的還是這句模糊的報錯信息。它會有很多歧義。

根據(jù)我的經(jīng)驗，這個報錯會有以下四種原因。最容易想到的：要運行的命令不存在。

動態(tài)鏈接器不存在，如下例，運行IDA的遠程調(diào)試器。

運行objdump可以看到它需要哪個解釋器來讀取它。一般都是ld-xxxx.so

如果ld找不到的話，這程序能運行的概率就很小了。QEMU解釋器沒找到。如果我們注冊了binfmt卻沒有將qemu拷貝到“rootfs/usr/bin“中，chroot時也會報一樣的錯誤——文件沒找到。如果沒有踩過這個坑，大概會很久找不出原因吧。

動態(tài)鏈接庫沒找到。這種情況比較顯而易見，因為他會告訴你哪個庫沒找到。

以后拿到一個新的固件包，只需要解壓到一個文件夾里，把對應(yīng)架構(gòu)的qemu拷貝進去，直接運行命令chroot即可。遇到需要調(diào)試的程序，我們通過運行“qemu-aarch64 -g 2331 /path/to/binary”指定-g參數(shù)開啟調(diào)試選項，也可以聲明一個環(huán)境變量QEMU_GDB=2331，帶上這個環(huán)境變量所啟動的程序，都會自動開啟GDB端口并等待調(diào)試器attach，調(diào)試起來是不是很方便呢？

參考資料：

總結(jié)

以上是生活随笔為你收集整理的静态编译qemu_使用QEMU chroot进行固件本地调试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。