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

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

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

對(duì)于打包黨對(duì)于移動(dòng)App帶來(lái)的危害有以下幾種：

1. 插入自己廣告或者刪除原來(lái)廣告；

2. 惡意代碼, 惡意扣費(fèi)、木馬等；

3. 修改原來(lái)支付邏輯。

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

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

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

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

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

### 如何解決移動(dòng)App安全風(fēng)險(xiǎn)問(wèn)題？

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

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

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

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

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

通過(guò)PackageManag對(duì)象可以獲取APK自身的簽名。

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

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

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

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

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

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

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

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

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

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

一、混淆代碼

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

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

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

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

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

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

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

混淆代碼逆向分析

如果想要反編譯混淆代碼，鐘亞平分享了一個(gè)國(guó)外的工具DEGUADR，它能夠通過(guò)統(tǒng)計(jì)的方式來(lái)解混淆。雖然這個(gè)工具的正確率達(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加固是對(duì)Dex文件進(jìn)行加殼防護(hù)，防止被靜態(tài)反編譯工具破解而泄露源碼，最剛開(kāi)始出現(xiàn)的是整體加固技術(shù)方案。

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

整體Dex加固逆向分析

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

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

三、拆分Dex加固

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

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

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

拆分Dex加固逆向分析

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

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

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

四、虛擬機(jī)加固

虛擬機(jī)加固也屬于Dex拆分加固的一種，它是對(duì)字節(jié)做了一些變化處理。如下所示，這是一個(gè)正常安卓系統(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ù)了，也不會(huì)以add-int v0, v1, v2、sub-int v0, v1, v2、mul-int v0, v1, v2這三條指令進(jìn)行替換，然后進(jìn)行加固編譯，這樣子操作后，即使把替換后的數(shù)據(jù)恢復(fù)了，也不會(huì)變形成為之前的字節(jié)碼，安全系數(shù)較高。

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

這種方式下的逆向分析，一方面可以通過(guò)HOOK JNI 接口來(lái)實(shí)現(xiàn)，它有兩種實(shí)現(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, …)

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

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

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

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

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

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

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

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

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

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

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

3、難度型

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

4、較難度型

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

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

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

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

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

一招教你打造一個(gè)滑動(dòng)置頂?shù)囊曈X(jué)特效

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

（Android）面試題級(jí)答案（精選版）

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