Android安全講座第九層(二) 記憶體dump

標籤：android

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

      1 dex加殼

      2 so加殼

      3 dex藏在so中，在適當的時候釋放。

      這是技術上一個進步，並且還有一些專業的公司提供了整個安全的解決方案，比如防ptrace，或者加密dex檔案等。但是不管如何，在技術層面，cpu要啟動並執行指令還必須是cpu能夠支援的，除非不考慮效率利用複雜的動態記憶體機制來保護代碼，一般情況下，載入記憶體的so或者dex等檔案還都是原生態的cpu可以執行的指令集。

      因為有時候駭客要破解你精心涉及的演算法是一件很麻煩的事情，他要求一條一條的看枯燥的彙編代碼，不是達不到，而是效率特別低。所以這個時候記憶體dump卻是駭客們經常採用的一種手段了。

   

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

      為了方便我個人的使用，我編寫了一個memdump工具，這是一個elf的可執行檔，在android系統下adb shell進去以後直接可以執行。首先說一下這個工具的用法。

[email protected]:/ # memdumpusage: memdump pid start_addr end_addr filaname255|[email protected]:/ #

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

然後後面需要有4個參數

pid                     要dump目標進程的進程號start_addr         要dump目標進程資料的虛擬起始地址end_addr           要dump目標進程資料的虛擬結束位址filename            dump出來的資料要儲存的檔案名稱（要求有路徑）

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

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M00/26/EE/wKiom1NvM3DQMHvpAARWmCgkncg722.jpg" title="Screenshot from 2014-05-11 16:18:52.png" alt="wKiom1NvM3DQMHvpAARWmCgkncg722.jpg" />

一

中我自己編寫了一個 包名為 com.example.socketcomm 的apk應用，裡面載入了一個 libsocketback.so的庫，開啟以後其進程號為 11164 ，通過查看其maps資訊，發現其可執行檔

程式碼片段在

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

這三個物理頁面上

由於物理頁面是以0x1000對其，我不知道這個so具體的大小，但是沒有關係，先將其全部dump出來

再做處理。

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M00/26/EE/wKiom1NvNXyS4km_AAUhNLE3rzM887.jpg" title="Screenshot from 2014-05-11 16:27:49.png" alt="wKiom1NvNXyS4km_AAUhNLE3rzM887.jpg" />

如，

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)

這個共用對象。

仔細的同學會看到

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

這條錯誤，產生的原因是 linux在載入so的時候是按照程式視圖的方式載入的，主要關心的是

Start of program headers:          52 (bytes into file)

這個開始的頭部資訊，對於連結方式的視圖的 段名等資料並不敏感，所以直接從記憶體dump出來的資料，是沒有 .symstrtab   .symtab  .strtab 這些段的，所以解析錯誤也很正常。一般常用的修補so的方法是拿到原來的so，這個你只要有這個應用就應該能拿到，然後根據elf檔案頭部，找到

Start of section headers:          12600 (bytes into file)

段表在檔案中的位移地址，拼接一下檔案即可，這個程式的編寫需要對elf檔案有一定的瞭解，回頭我會根據自己的研究和學習補充一些elf格式相關的博文。

從本質來看，基本上這個時候的so中的指令都應該是符合商務邏輯的指令了，dex檔案的提取同理，這個時候大家可以通過ida工具對其進行靜態分析。

附件為：memdump工具，我壓縮了一下，解壓即可，關於原始碼，誰有需要在下面留個郵箱，我發過去即可。