Android安全講座第九層(二) 內(nèi)存dump

      近來android上越來越多的應(yīng)用對自身的保護機制加強了重視，主要表現(xiàn)在幾個方面。

      1 dex加殼

      2 so加殼

      3 dex藏在so中，在適當(dāng)?shù)臅r候釋放。

      這是技術(shù)上一個進步，并且還有一些專業(yè)的公司提供了整個安全的解決方法，比如防ptrace，或者加密dex文件等。但是不管如何，在技術(shù)層面，cpu要運行的指令還必須是cpu能夠支持的，除非不考慮效率利用復(fù)雜的動態(tài)內(nèi)存機制來保護代碼，一般情況下，加載內(nèi)存的so或者dex等文件還都是原生態(tài)的cpu可以執(zhí)行的指令集。

      因為有時候駭客要破解你精心涉及的算法是一件很麻煩的事情，他要求一條一條的看枯燥的匯編代碼，不是達不到，而是效率特別低。所以這個時候內(nèi)存dump卻是駭客們經(jīng)常采用的一種手段了。

      linux下的內(nèi)存dump離不開 ptrace，所以有些安全方案直接防止別的進程對其ptrace，主要手段就是ptrace住自己。即便如此，依然有孜孜不倦的駭客成功繞開了防止ptrace的保護機制，關(guān)于這方面的事情，我以后有時間在專門寫一篇文章分享。今天只講如何內(nèi)存dump，內(nèi)存dump需要的ptrace目標(biāo)進程。

      為了方便我個人的使用，我編寫了一個memdump工具，這是一個elf的可執(zhí)行文件，在android系統(tǒng)下adb shell進去以后直接可以執(zhí)行。首先說一下這個工具的用法。

shell@android:/ # memdump
usage: memdump pid start_addr end_addr filaname
255|shell@android:/ #

用法十分簡單，將memdump通過 adb push拷貝到你的手機里面，我是放在了/system/bin 下面了，這樣我不用每次找路徑，直接運行命令即可。

然后后面需要有4個參數(shù)

pid                     要dump目標(biāo)進程的進程號
start_addr         要dump目標(biāo)進程數(shù)據(jù)的虛擬起始地址
end_addr           要dump目標(biāo)進程數(shù)據(jù)的虛擬結(jié)束地址
filename            dump出來的數(shù)據(jù)要保存的文件名稱（要求有路徑）

ok 介紹完了命令使用方法，下一步就具體操作一下如何使用的。

如圖一

上圖中我自己編寫了一個 包名為 com.example.socketcomm 的apk應(yīng)用，里面加載了一個 libsocketback.so的庫，打開以后其進程號為 11164 ，通過查看其maps信息，發(fā)現(xiàn)其可執(zhí)行的

代碼段在

56d34000-56d37000 r-xp 00000000 103:04 579426   
/data/data/com.example.socketcomm/lib/libsocketback.so

這三個物理頁面上

由于物理頁面是以0x1000對其，我不知道這個so具體的大小，但是沒有關(guān)系，先將其全部dump出來

再做處理。

如上圖，

memdump 11164 0x56d34000 0x56d37000 /sdcard/dump.so

通過這個命令將libsocketback.so  dump到了 /sdcard/dump.so

然后退出adb cmdline 以后，通過 adb pull 將 /sdcard/dump.so 拉到linux host機器上

再使用 readelf -h dump.so 查看 elf文件頭部，果然是

Type:                              DYN (Shared object file)

這個共享對象。

仔細(xì)的同學(xué)會看到

readelf: Error: Unable to read in 0x370 bytes of section headers

這條錯誤，產(chǎn)生的原因是 linux在加載so的時候是按照程序視圖的方式加載的，主要關(guān)心的是

Start of program headers:          52 (bytes into file)

這個開始的頭部信息，對于鏈接方式的視圖的 段名等數(shù)據(jù)并不敏感，所以直接從內(nèi)存dump出來的數(shù)據(jù)，是沒有 .symstrtab   .symtab  .strtab 這些段的，所以解析錯誤也很正常。一般常用的修補so的方法是拿到原來的so，這個你只要有這個應(yīng)用就應(yīng)該能拿到，然后根據(jù)elf文件頭部，找到

Start of section headers:          12600 (bytes into file)

段表在文件中的偏移地址，拼接一下文件即可，這個程序的編寫需要對elf文件有一定的了解，回頭我會根據(jù)自己的研究和學(xué)習(xí)補充一些elf格式相關(guān)的博文。

從本質(zhì)來看，基本上這個時候的so中的指令都應(yīng)該是符合業(yè)務(wù)邏輯的指令了，dex文件的提取同理，這個時候大家可以通過ida工具對其進行靜態(tài)分析。

附件為：memdump工具，我壓縮了一下，解壓即可，關(guān)于源代碼，誰有需要在下面留個郵箱，我發(fā)過去即可。