淺談被加殼ELF檔案的DUMP修復

wyzsk發表於2020-08-19
原文網址 : https://zhuanlan.kanxue.com/article-12773.htm
作者： 騰訊電腦管家 · 2015/06/10 15:45

前面的文章中，我已經介紹瞭如何除錯被加殼的ELF，這裡不在敘述，直接進入正題，以某加固為例，如何DUMP和修復被加殼的ELF，使其能除錯載入

我們先來看看被加殼ELF的頭和Program Header

enter image description here

enter image description here

首先我要讓偵錯程式停在入口點0x3860的位置

開始DUMP修復之旅，我的第一次DUMP修復的方法，延續了PE的思路，結果失敗了

失敗的原因並不是思路不對，而是細節上出現問題

第一次DUMP的方法：

1.廢除不影響載入的section(直接把結構體填0)，只關心PT_LOAD和PT_DYNAMIC兩種型別節 2.計算DUMP檔案最大值 align_up(0x28ca4, 0x8000) = 0x31000 3.將offset和va變成相等值，filesize和memsize按照align對齊 4.根據PT_LOAD節資料把資料DUMP出來，把DUMP資料放進檔案裡

那麼根據上圖描述資料，應該有兩塊兒

PT_LOAD : 0 ----align_up(0x12044, 0x8000) = 0 ----- 0x1B000
PT_LOAD : align_down(0x28ca4,0x1000) = 0x28000 ---- align_up(0x28ca4, 0x8000) = 0x31000

因為安卓也是linux核心，記憶體頁對齊粒度為4K(0x1000)

按照上述方法DUMP完，我們來看看IDA載入以後，JNI_ONLOAD的樣子

enter image description here

看下紅色的部分，奇怪了，本來應該有的程式碼去哪裡了??

0x221b0這個地址竟然無效

可是動態偵錯程式中明明可以看到這段程式碼：

enter image description here

對照Program Header, 再看0x221b0這個地址，PT_LOAD節中並沒有描述這個地址 所以，失敗就是在這個地方，殼的程式碼裡一定是mmap了這段記憶體，將解密後的資料，放進去，並修改了記憶體屬性

透過跟蹤殼程式碼，發現確實如此，殼程式碼透過svc 0，呼叫了mmap,mprotect兩個函式

mmap(0x3000, 0x23710, 0x3, 0x32, 0xffffffff, 0x0)  
map頁屬性：PROT_READ | PROT_WRITE
mprotect(0x3000, 0x23710, 0x5)

修改頁屬性：PROT_READ | PROT_EXEC 具體引數說明請參考幫助文件

這段區域起始地址：0x3000 大小：align_up(0x23710, 0x1000) = 0x24000 結束地址：0x3000 + 0x24000 = 0x27000 0x221b0這個地址正好在0x3000---|0x27000這個範圍裡

透過上述過程，重新總結DUMP方法如下

  1. 廢除不影響載入的section(直接把結構體填0)，只關心PT_LOAD和PT_DYNAMIC兩種型別節
  2. 計算DUMP檔案最大值 align_up(0x28ca4, 0x8000) = 0x31000
  3. 只保留一個PT_LOAD節，從0到0x31000 將整塊兒資料DUMP下來直接寫入檔案，修改align為0x1000，修改flag為RWE
  4. 修改PT_DYNAMIC節的offset,和VA相等 修復完的節表如下：

enter image description here

最後一個注意的地方，就是幹掉INIT段或者是INIT_ARRAY段

幹掉INIT方法：定位INIT描述的資料偏移，將偏移+8的資料，前移8個位元組

幹掉INIT_ARRAY方法：定位到VA處，按照結構，將資料填充為0xffffffff或者0

看下圖，INIT段已經不存在了

enter image description here

我們來開啟IDA，載入修復的檔案，看看效果：

enter image description here

enter image description here

資料完整，再看看動態載入的效果

enter image description here

載入成功~~~

哈哈，至此，修復完成

本文章來源於烏雲知識庫，此映象為了方便大家學習研究，文章版權歸烏雲知識庫！

相關文章