**
對於目前android平台上的脫殼技術，方法有很多，但對於一名coder而言，如何實現那些「奇技淫巧」，對我而言更加有趣些。
對於梆梆，之前有文章討論可以attach到其binder執行緒上，通過gcore、dd來dump記憶體中的dex。（當然，脫殼方法有很多，不一定非要用這種方法。）
但對於其最新版本，當使用gdb attach到主程序的任一線程上時，要麼permission denied，要麼會退出，本文章會對其實現機理進行一下分析。
1. 主程序fork子程序c1，c1 fork子程序c2；
2. c1會ptrace attach到主程序的主線程與gc執行緒（其也會操作memory，所以需要用ptrace方法保護），這樣當試圖ptrace attach時，會有permission denied；
3. 主程序為了能讓c1這個子程序跟蹤，需要呼叫prctl，option為set_dumpable。但這個api比較危險，其效果與androidmanifest檔案中debuggable選項設為true等價。如果不呼叫這個api，子程序是不能trace父程序的；
4. c1也會ptrace到c2程序，來對其進行保護；
5. 這個三個程序間彼此用pipe進行通訊；
6. c1會向主程序記憶體空間注入大約52位元組的資料，應為金鑰；
7. 之後c1進入pipe讀阻塞sleep；
8. c2使用inotify監控主程序的每個clone process的mem與pagemap，於是當gdb、dd試圖dump記憶體時，mem的access事件被觸發，三個程序集體退出，導致記憶體dump不完整；
9. c2並monitor主程序的task目錄，來判斷是否有新的clone process或現有的已消亡，來更新monitor的select loop的fd集合。
愛加密也是使用類似方法來實現其功能。
另外，梆梆還hook了write方法，來阻止在程序內部將header為dex的magic code的內容寫入磁碟。
【原創】梆梆脫殼分析2-依然使用gcore脫殼的方法
**續前文：
前文中可以看出主程序的孫子程序是起到防gdb/gcore的關鍵，那麼如何繞過它，依然使用gdb去dump出完整dex呢？
開始時，我是重新編譯了乙個rom，遮蔽與重定向了相關api，可以dump出來，顯然這個方法相對煩躁一點，下面介紹一種在目前梆梆的版本上，更為簡單粗暴的方法。
1. 首先通過ps找出孫子程序的pid，記為pid3；
2. 檢視/proc//task找出孫子程序所有的thread，通常是3個，並記錄下他們的tid；
3. 使用kill -20 將其子執行緒掛起；
4. gdb 主程序，順利gcore
Youpk 實戰脫殼 愛加密 梆梆脫殼
下面是我整理的乙份常用的脫殼機的對比 這裡在網上找了梆梆2020 加固過的樣本。這裡加殼前的 比較簡單 只有乙個類mainactivity mainactivity 裡只有簡單的add 和 sub方法。可以看到方法裡面的 也比較簡單，返回相加相減的值。這裡可以看到 加殼後 mainactivity ...
梆梆安全加固企業版分析
我是一名奮戰在安全第一線的程式猿，愛好和平，愛好打包不平，freedom forever 最近移動安全太火，火的我都忍不住玩了一把，最近幾個月在研究各家的安全加固方案，大多dex加密 反除錯等技術，玩著玩著就沒了意思。前段時間，突然發現有的企業客戶端apk的加固方式發生了一些變化，勾起了我的興趣，好...
360脫殼分析1 記憶體dump的時機選擇
360對dex的保護是比較好的，直接去dump記憶體會發現activity類都是有問題的，從dex格式而言，其dexclassdef結構體是有問題的，除了classid的所有成員均為0。那應該怎麼脫呢，當然360對so有加殼，我們可以對其進行脫殼後進行分析 另外，當然也可以修改libdvm來進行脫殼...