APK需要被重打包舌界，勢必是為了修改其中的代碼掘譬，可能是dex，可能是so呻拌，可能是dll（unity3d）屁药，也可能是某個腳本等等，重打包后簽名（未泄露）就會被改變。
不管怎樣酿箭，可以確定的是簽名和其中的某些文件會被修改复亏。
那么防止重打包的主要目標就是檢測這些修改
在保護之前，先來說說cracker可能會干的幾件事：
1.爆破缭嫡。直接修改代碼缔御，常見于純java編寫的或者簡單的so校驗。
2.脫殼妇蛀。如果方法1不行耕突，那可能是APK被加固了，所以可以考慮脫殼后再修改评架。局限性很大眷茁，困為很多殼脫出來沒法直接打包運行。但是脫殼可以了解程序邏輯纵诞，為方法3做準備上祈。
3.內(nèi)存補丁。如果方法2不行浙芙，那就不脫殼了登刺，根據(jù)程序邏輯，可以直接加載自己編寫的so打內(nèi)存補丁跳過檢測嗡呼。
4.hook纸俭，這可能是最近幾年用得最多的方案了。上面所有方法試了不行（或者懶得試了）南窗，就要走上hook這條路了揍很。
針對以上，可以做的事：
1.針對爆破万伤。這沒啥好說的女轿，把校驗寫進so，復(fù)雜一點壕翩，花里胡哨一點蛉迹，再弄個ollvm，或者加個殼放妈。
2.針對脫殼北救。上文就說了，很多殼脫出來直接打包是不行的芜抒，也有些殼是脫不了的珍策，比如java轉(zhuǎn)c（保護java代碼），vmp（保護so）宅倒，加殼之后原指令徹底消失不見攘宙，也就不存在脫殼的說法了。
3.針對內(nèi)存補丁。這個方法其實很冷門蹭劈，因為內(nèi)存補丁對逆向要求較高疗绣，有能力讀懂ollvm和加殼后的so的邏輯的，基本很難阻止他做事了铺韧。
4.針對hook：
做為最熱門的方法多矮，有必要單獨拎出來多說幾句。
a)檢測hook哈打。方法太多了塔逃，各種hook都有或多或少的特征，要注意的是料仗，會有諸如《通過hook繞過hook檢測》之類的文章……今天你hook我湾盗，明天我檢測你，后天你跳過我的檢測立轧，大后天我檢測你跳過我的檢測……對抗永無止境格粪。
b)不被hook。怎樣不被hook肺孵？自己寫函數(shù)。用java代碼來舉個例子颜阐，有一個bytes數(shù)據(jù)要計算它的md5平窘，最簡單的MessageDigest.getInstance("MD5").digest就完事了，如果調(diào)用了公共庫凳怨，那么就容易被hook住瑰艘，然后就bytes數(shù)據(jù)暴露了，計算結(jié)果也被修改了肤舞。所以多用原生類型自己寫函數(shù)吧紫新。
下面開始真正做事
1.對某些關(guān)鍵的邏輯（如果邏輯是用java寫的，可以先套java轉(zhuǎn)C殼）加一個殼李剖。
2.這個殼的靜態(tài)代碼中不存在任何svc特征芒率，一旦加載so，先進行完整性校驗篙顺，當校驗需要讀取APK時偶芍，釋放svc代碼執(zhí)行讀取操作，這樣在內(nèi)存搜索不到svc德玫，也就無法被hook匪蟀。如果要校驗maps中是否有hook框架也在這里進行。
3.當校驗通過宰僧，再執(zhí)行真正的程序邏輯材彪，并且此時原程序邏輯的so是碎片化的（就像java的指令抽取），此時從內(nèi)存dump出來的so也是不完整的段化，所以無法脫殼出原so嘁捷。
以上，實現(xiàn)了防爆破（加殼無法修改）穗泵，防脫殼（so分解了普气，無法脫殼），防hook（svc即插即用佃延，無法hook现诀，除非改內(nèi)核）。
然后履肃，就只有內(nèi)存補丁一條路了仔沿。
APK內(nèi)的AndroidManifest.xml，resources.arsc尺棋，classes.dex封锉，這3個文件全部修改一下，就會觸發(fā)完整性保護膘螟。有興趣的可以試試成福。
