iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 17
0

前情提要


有過 readelf 的經驗之後,我們已經對 ELF 格式中的檔頭內容瞭若指掌,所以 size 也就不費吹灰之力的完成了。接下來是小型工具程式之二的 strip 工具!

使用方法與功能介紹


目前為止我們已經使用 readelf 很多次,也透過 as 的實作由上而下地反覆咀嚼過 ELF 格式的奧妙,我們對於區段標頭與區段的概念,應該已經算是很熟悉了。當然,我們也留意到一些很有趣的作法,比方說:

  • 每個區段都有每個區段的名稱,但是這個名稱(一個字串)不存在該區段檔頭中,也非該區段的一部分,而是以一個漂移量存在區段檔頭之中。一個合格的程式要讀懂這個檔案時,就必須理解這個漂移量,同時必須知道要去 .shstrtab 區段(或是某一個在 ELF 檔頭標明的區段)裡面撈取這個字串,作為該區段的名稱使用。
  • symtab:標籤區段存放各式各樣的標籤內容,這個部份會必須要透過類似上一段的手法存取 .strtab 裡面的字串。

這些標籤,到頭來是為了連結而存在的。當一個程式的各個部份(可重定物件檔)被連結成一個可執行檔之後,再執行時再經由動態連結器載入動態函式庫;也許設計者沒有意識到這些過程的實際運作,但是他們理解自己的程式的方法必然牽涉到其中步驟,具體來說,當他們想著:「我這裡要呼叫另外一個檔案的函式、這裡要用到上一個資料夾的哪一個檔案裡面定義的全域變數......」之類的念頭來進行開發時,他們心中的藍圖仍然是與電腦截然不同的程式,他們是以標籤為導向不清楚實際位址的一種抽象,與最後編譯出來的成果完全不同。

那麼,如果我們已經成功取得了連結好的執行檔,是不是有些標籤就可以不需要了呢?是否有辦法能夠去除掉這些不必要的標籤呢?

是的,strip 工具程式的主要功能就是這個用途。更廣泛來說,strip 工具還有其他好處(以下是筆者想得到的部份):

  • 能夠去除不必要的標籤和字串區段,節省儲存空間
  • 能夠去除 debug 資訊區段
  • 安全性:增加逆向工程的困難度,因為反組譯之後缺少了標籤資訊會更難理解程式結構

舉個例子來看看吧!還記得日前我們用以測試的程式嗎?拿 add.o 和 main.c 連結之後的成果來看:

$ riscv64-unknown-linux-gnu-gcc add.o main.c
$ riscv64-unknown-linux-gnu-strip a.out -o b.out  # 將 a.out 程式 strip 掉成為 b.out,然後觀察其中的標籤 
$ /tmp/readelf -S ./b.out | awk '{print $1 $2}'
0.shstrtab
1.comment
2.bss
3.sdata
4.got
5.dynamic
6.fini_array
7.init_array
8.preinit_array
9.eh_frame
10.eh_frame_hdr
11.rodata
12.text
13.plt
14.rela.plt
15.gnu.version_r
16.gnu.version
17.dynstr
18.dynsym
19.hash
20.note.ABI-tag
21.interp
22

如果看 a.out 的話,會發現多了九個區段如下:

1.strtab
2.symtab
3.debug_loc
4.debug_str
5.debug_frame
6.debug_line
7.debug_abbrev
8.debug_info
9.debug_aranges

這就完全印證了前一段的說法:strip 工具會移除不需要的標籤和字串(這兩個在 a.out 形成時就已經可以功成身退,相對的,動態連結所需的 .dynsym.dynstr 區段之類的部份就不會被 strip 影響到),還有 debug 需要的內容。

實作


筆者這個部份打算實作簡單版本的功能,那就是將 .strtab.symtab 區段移除掉。動筆之前的計畫是這樣的:因為只有打算移除這兩個區段,那麼就拿其它的區段來填補即可。

在這裡,筆者又必須承認自己的錯誤了(當然,這也表示又學到了一課)。之前為了叛逆的原因,沒有思考為什麼主流的實作裡面都會把區段檔頭放在檔案的最後面(當然,也是所有區段的最後面才開始接第一個區段檔頭)。現在要實作 strip 工具程式才恍然大悟:因為區段檔頭在最後面的話,一切就如同上面那段一樣輕描淡寫;然而一旦區段檔頭之後還有內容,對於二進位檔來說,就沒有什麼像是 backspace 那樣編輯文字檔一般的方便機制了。

也就是說,我們之後有機會時必須回去修改 as 的生成 ELF 的部份,改成區段標頭在後的方式。但是實際上,由於物件檔不可以被 strip,所以我們目前做的事情還不會造成 strip 的困難,只是日後若是有機會實作到我們自己的 ld,那麼就也必須回想起這點才行。

日後也應該考慮設計更泛用的介面:都有了讀取 ELF 檔,為什麼沒有輸出 ELF 的 API 呢?as 的時候採取的是非常土法煉鋼的方式逐塊拼湊 ELF 檔的元件,現在 strip 也算是有這樣泛用的需求了,日後的 objcopy 可能有一點,而 ld 則更不用說。

小結


看起來,strip 比起昨日的 size 程式有挑戰得多了!之後再來解析實作的內容。各位讀者,我們明日再會!


上一篇
第十六日:使用 size 觀察各區段大小
下一篇
第十八日:nm 工具程式介紹
系列文
與妖精共舞:在 RISC-V 架構上使用 GO 語言實作 binutils 工具包30

尚未有邦友留言

立即登入留言