摘要：接下來，我就來詳解一下如何防止被二次打包。開發(fā)階段移動應(yīng)用開發(fā)時接入安全組件，保護(hù)數(shù)據(jù)安全。

“Android APP二次打包”則是盜版正規(guī)Android APP，破解后植入惡意代碼重新打包。不管從性能、用戶體驗、外觀它都跟正規(guī)APP一模一樣但是背后它確悄悄運行著可怕的程序，它會在不知不覺中浪費手機(jī)電量、流量，惡意扣費、偷窺隱私等等行為。

二次打包問題只是Android應(yīng)用安全風(fēng)險中的一部分， 一般是通過反編譯工具向應(yīng)用中插入廣告代碼與相關(guān)配置，再在第三方應(yīng)用市場、論壇發(fā)布。

對于打包黨對于移動App帶來的危害有以下幾種：

1. 插入自己廣告或者刪除原來廣告；

2. 惡意代碼, 惡意扣費、木馬等；

3. 修改原來支付邏輯。

上述惡意行為嚴(yán)重危害移動產(chǎn)品和用戶利益，同時也影響企業(yè)口碑。

關(guān)于移動App破解、數(shù)據(jù)泄露風(fēng)險問題，以金融行業(yè)為例：眾所周知數(shù)據(jù)是金融類應(yīng)用產(chǎn)品重要資源之一，關(guān)乎企業(yè)生存與發(fā)展、但移動應(yīng)用經(jīng)常被破解、數(shù)據(jù)被抓包，導(dǎo)致本地存儲數(shù)據(jù)以及用戶名、密碼等重要信息泄露。下面舉例說明數(shù)據(jù)泄露案例。

金融類本地存儲數(shù)據(jù)泄漏

數(shù)據(jù)抓包，泄漏用戶名和密碼

面對二次打包不少公司都有自己的防范措施，知名公司的APP幾乎都是自己在程序內(nèi)部做過處理防止其APP被二次打包，一旦打包后重新運行則程序自動退出。接下來，我就來詳解一下如何防止APP被二次打包。

### 如何解決移動App安全風(fēng)險問題？

基于多年的移動安全經(jīng)驗積累，網(wǎng)易云易盾在移動APP安全風(fēng)險問題上，從起始的開發(fā)階段、中間的測試階段再到結(jié)尾發(fā)布階段，針對移動APP全生命周期進(jìn)行安全防護(hù)。

開發(fā)階段——移動應(yīng)用開發(fā)時接入安全組件，保護(hù)數(shù)據(jù)安全。其中，針對安全通信方面，實現(xiàn)數(shù)據(jù)高強(qiáng)度加密，結(jié)合傳統(tǒng)的對稱、非對稱加密算法和hash算法，客戶端加密數(shù)據(jù)只有認(rèn)證服務(wù)端才能解密，從而防止了數(shù)據(jù)泄漏、數(shù)據(jù)竊取和篡改。另外，為了實現(xiàn)加強(qiáng)數(shù)據(jù)的安全強(qiáng)度，安全組件結(jié)合自適應(yīng)特征算法和隨機(jī)切換算法，保證不同時間、不同終端的算法和密鑰的差異性。

測試階段——對移動應(yīng)用進(jìn)行人工滲透測試，發(fā)現(xiàn)漏洞解決產(chǎn)品修復(fù)相關(guān)問題，包括：APP滲透測試和服務(wù)端滲透測試。

發(fā)布階段——APP上架之前針對應(yīng)用做安全加固，提高安全防護(hù)等級，上架之后做盜版監(jiān)測。網(wǎng)易云易盾可針對dex文件進(jìn)行加固防護(hù)，防止被靜態(tài)反編譯獲取代碼邏輯；保護(hù)應(yīng)用在被非法二次打包后不能正常運行；防止通過使用調(diào)試器工具對應(yīng)用進(jìn)行非法破解；提供自研高穩(wěn)定的設(shè)備指紋，防止?jié)撛诘乃物L(fēng)險；加密資源文件，防止apk資源文件被破解；對so文件進(jìn)行加固保護(hù)，防止native代碼被逆向分析；對游戲提供加固保護(hù)，讓游戲免受破解、外掛等威脅。

要實現(xiàn)代碼內(nèi)部防止APP被二次打包首先得了解APK的機(jī)器識別原理，APK的唯一識別是依靠包名和簽名來做鑒定的，類似豌豆夾的洗白白、360手機(jī)衛(wèi)士等安全軟件對APK的山寨識別，他們就是依賴包名來確定APK然后通過簽名來確定其是否山寨。所以說自己的程序內(nèi)部在啟動的時候可以通過獲取APK本身的簽名然后和正確的簽名做對比來識別自己是否被二次打包。

通過PackageManag對象可以獲取APK自身的簽名。

過對簽名的碼的分解得到一串20左右的字符串，此字符串則是APK的簽名的MD5值，通過獲取的簽名MD5值與正確的MD5值進(jìn)行對比，就可以識別其APK是否被盜版。

下圖是一些已做過保護(hù)的APP的代碼塊分析：

上圖是“XX省電王“的防止二次打包的關(guān)鍵代碼

上圖是”XX電池管家”的防止二次打包的關(guān)鍵代碼

以上兩處都是smali層的代碼，以上2處代碼的截圖都是下載量非常高的APP所做的防止二次打包的處理，其處理的代碼肯定會使用到的關(guān)鍵代碼是

Landroid/content/pm/PackageInfo;->signatures:[Landroid/content/pm/Signature。

此方法能夠起到一定的安全作用，一般的打包黨面對它是無可奈何的，如果你了解一些smali語法它的作用就等于0了。

### Android 應(yīng)用加固的技術(shù)細(xì)節(jié)

此外，針對如何加固的技術(shù)細(xì)節(jié)問題，網(wǎng)易云資深安全工程師鐘亞平在安卓巴士全球開發(fā)者論壇的活動中也做過《安卓App逆向與保護(hù)》的主題演講：

安卓App安全包含很多內(nèi)容，包括混淆代碼、整體Dex加固、拆分 Dex 加固、虛擬機(jī)加固等方面。事實上，這些內(nèi)容也是國內(nèi)近幾年Android App安全保護(hù)的一種主要趨勢。

一、混淆代碼

Java代碼是非常容易反編譯的，作為一種跨平臺的、解釋型語言，Java 源代碼被編譯成中間“字節(jié)碼”存儲于class文件中。由于跨平臺的需要，這些字節(jié)碼帶有許多的語義信息，很容易被反編譯成Java源代碼。為了很好地保護(hù)Java源代碼，開發(fā)者往往會對編譯好的class文件進(jìn)行混淆處理。

混淆就是對發(fā)布出去的程序進(jìn)行重新組織和處理，使得處理后的代碼與處理前代碼完成相同的功能，而混淆后的代碼很難被反編譯，即使反編譯成功也很難得出程序的真正語義。ProGuard就是一個混淆代碼的開源項目，能夠?qū)ψ止?jié)碼進(jìn)行混淆、縮減體積、優(yōu)化等處理。

Proguard處理流程圖如下所示，包含壓縮、優(yōu)化、混淆、預(yù)檢四個主要環(huán)節(jié)：

壓縮（Shrink）：檢測并移除代碼中無用的類、字段、方法和特性（Attribute）；

優(yōu)化（Optimize）：對字節(jié)碼進(jìn)行優(yōu)化，移除無用的指令。優(yōu)化代碼，非入口節(jié)點類會加上private/static/final，沒有用到的參數(shù)會被刪除，一些方法可能會變成內(nèi)聯(lián)代碼；

混淆（Obfuscate）：使用a、b、c、d這樣簡短而無意義的名稱，對類、字段和方法進(jìn)行重命名；

預(yù)檢（Preveirfy）：在Java平臺上對處理后的代碼進(jìn)行預(yù)檢，確保加載的class文件是可執(zhí)行的。

混淆代碼逆向分析

如果想要反編譯混淆代碼，鐘亞平分享了一個國外的工具DEGUADR，它能夠通過統(tǒng)計的方式來解混淆。雖然這個工具的正確率達(dá)不到100%，但是能在一定程度上幫助反編譯代碼。

com.xxxxx.common.util.CryptoUtil網(wǎng)站也提供了一種反編譯服務(wù)，如下所示：

java.lang.String a(byte[]) -> encodeToString

java.lang.String a(byte[],boolean,java.lang.String) ->a

byte[] a(byte[],byte[]) -> encrypt

byte[] b(byte[]) -> getKey

byte[] b(byte[],byte[]) -> decrypt

byte[] d(java.lang.String) -> getKey

java.lang.String a(byte,char[]) -> a

java.lang.String a(java.io.File) -> getHash

java.lang.String a(java.lang.String) -> c

java.lang.String b(java.lang.String) -> encode

二、整體Dex加固

為了加強(qiáng)Android保護(hù)強(qiáng)度，隨著安全技術(shù)的發(fā)展，又出現(xiàn)了新型的“加固技術(shù)”。Dex加固是對Dex文件進(jìn)行加殼防護(hù)，防止被靜態(tài)反編譯工具破解而泄露源碼，最剛開始出現(xiàn)的是整體加固技術(shù)方案。

整體加固技術(shù)的原理如上所示，包括替換application/classes.dex、解密/動態(tài)加載原classes.dex、調(diào)用原application相關(guān)方法、將原application對象/名稱設(shè)置到系統(tǒng)內(nèi)部相關(guān)變量四大環(huán)節(jié)。其中最為關(guān)鍵的一步就是解密/動態(tài)加載原classes.dex，通過加密編譯好的最終ex源碼文件，然后在一個新項目中用新項目的application啟動來解密原項目代碼并加載到內(nèi)存中，再把當(dāng)前進(jìn)程替換為解密后的代碼，能夠很好地隱藏源碼并防止直接性的反編譯。

整體Dex加固逆向分析

整體Dex加固逆向分析有兩種常用的方法。其一是在內(nèi)存中暴力搜索 dexn035，再 dump。以下是在32位系統(tǒng)中的效果示例：

另一種方法就是通過Hook dvmDexFileOpenPartial(void addr, int len, DvmDex*)。

三、拆分Dex加固

隨著業(yè)務(wù)規(guī)模發(fā)展到一定程度，不斷地加入新功能、添加新的類庫，代碼在急劇膨脹的同時，相應(yīng)的apk包的大小也急劇增加，那么簡單的整體加固方案就不能很好地滿足安全需求，在整體加固方案之外又出現(xiàn)了拆分加固的技術(shù)方案。

但是如上所示，Dex文件在加固時，針對中間缺失的一部分?jǐn)?shù)據(jù)會以解密后的數(shù)據(jù)來替換，有的時候這種拆分替換也會導(dǎo)致數(shù)據(jù)不準(zhǔn)確。那么到底應(yīng)該拆分什么樣的數(shù)據(jù)呢？就需要了解一下Dex文件的數(shù)據(jù)結(jié)構(gòu)。

Dex文件結(jié)構(gòu)極為復(fù)雜，以下圖示選取了其中較為重要的內(nèi)容。事實上，Dex文件是一個以class為核心組裝起來的文件，其中最重要的是classdata和classcode兩部分，有其特定的接口和指令數(shù)據(jù)，選取這兩部分來拆分的話，即使拆分出來也不會泄露class數(shù)據(jù)和字節(jié)碼數(shù)據(jù)，反編譯出來也不完整，安全性較高。

拆分Dex加固逆向分析

對于Dex拆分加固的逆向分析，如下所示，可以用classdata替換從而組裝成新的Dex文件，雖然和原來的Dex文件不會完全一致，但也在一定程度上復(fù)原了被拆分?jǐn)?shù)據(jù)的樣子。

但要注意的是，這種方法僅適用于被拆分出去的數(shù)據(jù)變形一次性完成，也就是說，在有其他保護(hù)思路的情況下盡量避免使用，而且即使有需要也盡量選在用到這個類的時候才去恢復(fù)。

此外還有一個更底層一些的工具dexhunter，這個工具較為前衛(wèi)，但同時也有一些局限性，譬如部分指令數(shù)據(jù)會被優(yōu)化，形成的代碼界面不是很美觀等等。

四、虛擬機(jī)加固

虛擬機(jī)加固也屬于Dex拆分加固的一種，它是對字節(jié)做了一些變化處理。如下所示，這是一個正常安卓系統(tǒng)中的代碼，在其中進(jìn)行了虛擬機(jī)加固操作：

以add-int v0, v1, v2、sub-int v0, v1, v2、mul-int v0, v1, v2這三條指令進(jìn)行替換，然后進(jìn)行加固編譯，這樣子操作后，即使把替換后的數(shù)據(jù)恢復(fù)了，也不會以add-int v0, v1, v2、sub-int v0, v1, v2、mul-int v0, v1, v2這三條指令進(jìn)行替換，然后進(jìn)行加固編譯，這樣子操作后，即使把替換后的數(shù)據(jù)恢復(fù)了，也不會變形成為之前的字節(jié)碼，安全系數(shù)較高。

虛擬機(jī)加固逆向分析—HOOK JNI 接口

這種方式下的逆向分析，一方面可以通過HOOK JNI 接口來實現(xiàn)，它有兩種實現(xiàn)方式。

其一是類成員/靜態(tài)變量操作相關(guān)接口，比如：

GetStaticDoubleField SetStaticDoubleField GetDoubleField SetDoubleField …

(byte, object, int, long…)

其二是反射調(diào)用類方法，比如：

*   CallVoidMethodA CallBooleanMethodA CallShortMethodA CallObjectMethodA …

*   CallStaticVoidMethodA CallStaticBooleanMethodA CallStaticShortMethodA CallStaticObjectMethodA …

*   (byte, int, long,double …)

*   CallObjectMethodA(JNIEnv* env, jobject object, jmethoID method, …)

通過HOOK JNI 接口實現(xiàn)虛擬機(jī)加固逆向分析

通過HOOK JNI 接口不用逆向底層，就可以了解App大致的調(diào)用流程。但是對于復(fù)雜的調(diào)用過程，或者虛擬化方法數(shù)量較多的情況，這種逆向分析手段看起來會比較混亂；對于不需要返射到Java層執(zhí)行的指令，如算術(shù)、邏輯運算等，則無法監(jiān)控到。

虛擬機(jī)加固逆向分析—分析指令操作碼映射

另一方面，也可以通過分析指令操作碼映射來逆向分析。在同一加固版本，或者映射關(guān)系相同的情況下，可以采取以下所示的方法：

但在實際情況中，每次加固時的映射關(guān)系都是隨機(jī)變化的，如下所示，這種情況下就無法直接建立映射關(guān)系。

不依賴于操作碼的映射關(guān)系只與虛擬機(jī)結(jié)構(gòu)有關(guān)，所以需要根據(jù)偏移關(guān)系建立映射關(guān)系，從而進(jìn)行逆向分析。

安卓App逆向保護(hù)作為開發(fā)工作中的重要內(nèi)容，一直是網(wǎng)易云易盾致力提供的應(yīng)用服務(wù)。后續(xù)，我們將在SO加密保護(hù)方面進(jìn)行更加深入地研究，對SO里面的邏輯進(jìn)行分析，保護(hù)Native代碼不被逆向分析

Android應(yīng)用做不到完全的防止二次打包。
1、簡單型

最簡單的就像簽名驗證。驗證編譯之后的dex簽名，md5等數(shù)據(jù)。

2、微有點技術(shù)含量型

由native在運行時釋放class到內(nèi)存。釋放bytes數(shù)據(jù)直接喂給classloader。

3、難度型

對native本身再進(jìn)行一些加固，加逆向坑（暗樁）增加破解難度。

4、較難度型

Java代碼執(zhí)行代碼的時候調(diào)用native操作，實現(xiàn)破解必須破解native部分。

最后如果需要，部分必要算法轉(zhuǎn)移到云端執(zhí)行，最大限度的去保證防被破解和二次打包

作者：yijian2595
鏈接：https://www.jianshu.com/p/b6c...

react-native技術(shù)的優(yōu)劣

?一招教你讀懂JVM和Dalvik之間的區(qū)別

一招教你打造一個滑動置頂?shù)囊曈X特效

NDK項目實戰(zhàn)—高仿360手機(jī)助手之卸載監(jiān)聽

（Android）面試題級答案（精選版）

在這里獲得的不僅僅是技術(shù)！