如果你是想直接用
FART github
直接裝完一用就行了。
本文完！
如果想繼續(xù)了解
注意點(diǎn)：
1、多dex：
使用脫完之后，可能會有很多dex文件。fart脫出來的dex文件會伴隨著同名的txt文件。如果有想找的類名，可以grep類名到txt文件找，然后再找同名的dex。
2、打開異常：
可能是dex的開頭魔數(shù)故障
https://blog.csdn.net/sinat_18268881/article/details/55832757
這里有解釋魔數(shù)是什么。大概意思是用010Editor打開。開頭是dex.035開頭的。
問題的出現(xiàn)可能是魔數(shù)沒了，或者開頭不是dex.035開頭的,比如
圖里要把dex035前面的都刪了。
如果沒有魔數(shù)的，開頭全是00000000，就把別的有魔數(shù)的直接粘過來就行
擴(kuò)展一下
https://github.com/lasting-yang/frida_dump/blob/master/dump_dex.js
這里yang的脫殼代碼也是通過掃內(nèi)存然后通過魔數(shù)來判斷存不存的，當(dāng)然缺陷也很明顯，抹頭的dex dump不出來。
這個是葫蘆娃的frida脫殼
https://github.com/hluwa/frida-dexdump/blob/master/frida_dexdump/agent/agent.js
加殼原理：
安卓有很多類加載器：(主要看后兩個)
- BootClassLoader：其他加載器父類。
- PathClassLoader：默認(rèn)的類加載器。
- DexClassLoader： 可以加載任意地方的類的加載器。所以也是插件化、熱修復(fù)、加殼的重點(diǎn)
- InMemoryDexClassLoader： 這個是安卓8之后的內(nèi)存加載dex
還有很多其他的。暫不考慮。用到再說。還有什么雙親委派機(jī)制能。不講那么細(xì)了。說多了不容易理解
這里因?yàn)槟軇討B(tài)加載類，只要?dú)S商能自定義DexClassLoader，然后在殼想用的時候加載就ojbk了。
幾代殼：
- 一代殼：dex整體套起來了
- 二代殼：類、函數(shù)啥的還在，里面代碼為空，比如：func main(){}
- 三代殼：java的native化。代碼不dex,跑so里去了，主要兩類：vmp、dex2c
vmp、dex2c
開源代表作：
分辨：
- 函數(shù)的 注冊地址相同 , 并且 函數(shù)邏輯相似 , 則使用的是 VMP 加殼 ;
- 函數(shù)的 注冊地址不同 , 并且 函數(shù)邏輯不相似 , 則使用的是 Dex2C 加殼 ;
方法：
adb logcat | grep Acticity.onCreate
看一下每次切換Acticity。日志里FromJni:0X地址 看一下每次地址是否相同。
通用脫殼法：
因?yàn)閯偛盘岬搅薎nMemoryDexClassLoader和DexClassLoader
然后去源碼里看http://www.aospxref.com/android-8.1.0_r81
就像這樣 一層一層往上找，一直找到C代碼。找到這些。
一、InMemoryDexClassLoader 類加載器脫殼點(diǎn)總結(jié)
- dalvik_system_DexFile.cc#CreateSingleDexFileCookie
- dalvik_system_DexFile.cc#CreateDexFile
- dex_file.cc#DexFile::Open
- dex_file.cc#DexFile::OpenCommon
- dex_file.cc#DexFile::DexFile
二、ART 虛擬機(jī)下 DexClassLoader 類加載器脫殼點(diǎn)總結(jié)
- file_magic.cc#OpenAndReadMagic 函數(shù)
- dex_file.cc#DexFile::OpenCommon
- dex_file.cc#DexFile::DexFile
這兩種方式都有dex_file.cc#DexFile::OpenCommon和dex_file.cc#DexFile::DexFile
總結(jié)：
加固廠商可能使用 InMemoryDexClassLoader 類加載器 , 也可能使用 DexClassLoader 類加載器 , 這里為了保證不管使用什么類加載器 , 都可以進(jìn)行脫殼 , 選擇 2個類加載器都有的脫殼點(diǎn) , 可以兼容兩種類加載器 ;這兩種方式都有dex_file.cc#DexFile::OpenCommon和dex_file.cc#DexFile::DexFile，就可以選擇他倆。把傳進(jìn)來的dex保存下來就ojbk了
修改系統(tǒng)源碼式的脫殼代碼編寫：↓
https://hanshuliang.blog.csdn.net/article/details/121964509?spm=1001.2014.3001.5502
找到上面說的那些時候還有一點(diǎn)提一下：
【Android 逆向】ART 函數(shù)抽取加殼 ( ART 下的函數(shù)抽取恢復(fù)時機(jī) | 禁用 dex2oat 機(jī)制源碼分析 )
這篇文章講的主要的點(diǎn)是art下的時候，Dalvik虛擬機(jī)下沒這么多事而且由于系統(tǒng)有點(diǎn)老這里就不談了。
首先它給app加殼了，用的時候總要恢復(fù)。找恢復(fù)的時機(jī)是個比較重要的點(diǎn)。art虛擬機(jī)為了讓app運(yùn)行的更快搞了個預(yù)編譯也就是dex2oat。
如文章所說
ART 下的函數(shù)抽取恢復(fù)時機(jī) :
- 恢復(fù)抽取函數(shù)早于 oat 文件編譯 : 在 ART 虛擬機(jī)下 , 需要將 dex 文件編譯生成為 oat 文件 , 將 dex 文件中的 函數(shù)指令 抽取出來 , 必須 在 生成 oat 文件之前 , 將從 抽取的函數(shù)指令恢復(fù) ;
- 禁用 dex2oat 機(jī)制 : 如果 禁用 dex2oat 的編譯過程 , 則 恢復(fù) 被抽取的 函數(shù)指令 , 不在受 該條件限制 , 不是必須在 dex2oat 之前恢復(fù) , 可以稍晚一些再恢復(fù)函數(shù)指令 ;
如果選擇第一種方案 , 在 dex2oat 之前進(jìn)行恢復(fù) , 這沒有任何意義 , dex2oat 編譯后 , 生成的 oat 文件是完整的 , 此時 可以 完整的將 oat 文件 dump 到 SD 卡中 , 基本等于沒有加固 , 還是一個一代殼 ;
因此 , 大部分加固廠商 , 選擇 禁用 dex2oat 機(jī)制 ; 這樣處于安全考慮 , 犧牲了應(yīng)用的運(yùn)行效率 ;
此人博客2021年12月12日--20日有多篇脫殼加殼詳細(xì)文章，感興趣可讀。
——————————————————
暫時更新此處，本周內(nèi)在此篇繼續(xù)更
參考文獻(xiàn)：
https://blog.51cto.com/u_15101562/2622410
