Android應(yīng)用安全這個(gè)話題如今已經(jīng)變?yōu)樵絹碓綗衢T的話題，本文帶大家簡單梳理一下一些相關(guān)概念，如果有補(bǔ)充和看法， 歡迎在評論中指出來哦~

代碼混淆

Android開發(fā)除了部分功能采用C/C++編碼外，其余主要都是采用Java進(jìn)行編碼開發(fā)功能。Java應(yīng)用非常容易被反編譯，Android自然也不例外。只要利用apktool等類似的反編譯工具，就可以通過安裝包獲取源代碼。Google為了保護(hù)開發(fā)者的知識(shí)產(chǎn)權(quán)，為Android提供了ProGuard混淆方案，以增加反編譯后源碼閱讀，但對于Android開發(fā)老司機(jī)和逆向工程師來說，解讀還原出源代碼只是時(shí)間問題。

ProGuard是針對Java應(yīng)用的保護(hù)，并不是專門針對Android應(yīng)用的，Android雖然使用Java開發(fā)，但是畢竟不是跑在JVM上，所以安裝包結(jié)構(gòu)和普通的Java應(yīng)用還是區(qū)別多多。如果你對免費(fèi)的ProGuard放心不下，可考慮試試付費(fèi)的混淆方案DexGuard，除了擁有ProGuard的功能外，還包含資源混淆，字符串加密，類加密和dex文件分割等。

雖然代碼混淆是最為基礎(chǔ)的保護(hù)措施，不過國內(nèi)仍有不少應(yīng)用還是裸奔的，其中還包括一些大廠應(yīng)用（此處不表）。

簽名校驗(yàn)

Android黑產(chǎn)里面，有一個(gè)叫做二次打包，也稱為重打包。即通過反編譯正版應(yīng)用后，可以獲得smali源碼，往其中注入代碼或者修改相應(yīng)業(yè)務(wù)邏輯后，再利用新的簽名進(jìn)行重新打包，并發(fā)布到應(yīng)用市場去，很多無良開發(fā)者就是通過這種方式去破解一些付費(fèi)應(yīng)用或者往其中注入廣告代碼來獲利。簡單梳理一下重打包的基本流程：

1. 對正版應(yīng)用用apktool類逆向工具進(jìn)行解包；
2. 在某處地方注入smali代碼；
3. 利用IDE生成簽名文件，再通過jarsigner進(jìn)行簽名；
4. 上傳應(yīng)用市場；

為了與二次打包做對抗，可以在應(yīng)用內(nèi)的關(guān)鍵功能入口增加校驗(yàn)簽名的檢測，如果發(fā)現(xiàn)應(yīng)用簽名非正版，則強(qiáng)制關(guān)閉應(yīng)用或者限制用戶使用。加簽名校驗(yàn)代碼時(shí)，可以考慮：

1. 在JNI層中加校驗(yàn)代碼，相比在Java層的代碼，JNI層的逆向難度更大；
2. 如果要在Java層加校驗(yàn)代碼，不要在一個(gè)地方暴露一段長串字符串，對于逆向工程師是來說，這是非常明顯的提示。可以考慮將字符串打散存放在各處，這樣會(huì)增加破解分析的難度；

當(dāng)然，不要以為放在JNI就高枕無憂，對于JNI層，同樣可以進(jìn)行代碼注入，來暴力破解你簽名校驗(yàn)的邏輯，只不過相比Java層的，JNI層所需成本更高，這樣也就能攔截掉一部分逆向人員的歪主意。

加殼

加殼的原理是通過加密原應(yīng)用的安裝包中的dex文件，其主要操作方式大致如下：

1. 準(zhǔn)備要進(jìn)行加殼的原應(yīng)用安裝包（以下簡稱原apk）、用于做殼的安裝包（以下簡稱殼apk）；
2. 對原Apk進(jìn)行拆解獲取各個(gè)部分，并將dex文件進(jìn)行算法加密（以下簡稱加密原dex）；
3. 將加密原dex和殼Apk中的dex進(jìn)行組合，合并成為新的dex文件；
4. 利用特制的打包工具合并生成加密后的apk；

這種通過隱藏dex文件的方式加殼方式，最終是利用ClassLoader在內(nèi)存中解密并進(jìn)行動(dòng)態(tài)加載運(yùn)行。而如果是修改dex文件的加殼方式，其主要是抽取DexCode中的字節(jié)碼指令后用零去填充，或者修改方法屬性等操作，其修復(fù)時(shí)機(jī)則是運(yùn)行時(shí)在內(nèi)存中做相應(yīng)的修正工作。
通過加殼得到的安裝包如果不進(jìn)行脫殼操作，逆向人員就無法拿到真正的dex文件，也就無從分析。這里可以看看使用360加固的一個(gè)應(yīng)用的結(jié)構(gòu)在沒脫殼前的安裝包結(jié)構(gòu)只有寥寥幾個(gè)類，而正真的安裝包中的dex文件則被藏起來了，這進(jìn)一步加大了逆向的難度。關(guān)于加殼，市面上已經(jīng)有很多成熟企業(yè)加固方案可以使用，如梆梆安全、愛加密、360加固保等，如果不是專門研究這塊的開發(fā)者去自行開發(fā)一套加殼方案，顯然不太現(xiàn)實(shí)。
加殼也只是提高被逆向的門檻，對于功力不夠的逆向開發(fā)者而言，只能就此作罷，而對于逆向老鳥來說，脫殼同樣這是外包時(shí)間問題罷了。此外，對應(yīng)用加殼還要留意平臺(tái)兼容性問題，如此前某著名加固產(chǎn)品就出現(xiàn)過在ART虛擬機(jī)不兼容問題，以及將會(huì)影響項(xiàng)目使用某些熱修復(fù)技術(shù)。

反動(dòng)態(tài)調(diào)試

你是不是曾以為沒有拿到源代碼就不可以調(diào)試Android應(yīng)用了？然而并不是，只要反編譯后拿到smali代碼工程，再加上smalidea調(diào)試神奇，分分鐘在Android Studio調(diào)試應(yīng)用給你看，具體操作并不復(fù)雜，可以參照我文末提供的資料。即使你把核心代碼放到了JNI層，我也可以祭出神器IDA Pro繼續(xù)調(diào)試給你看，更何況，實(shí)際開發(fā)中能放進(jìn)JNI層實(shí)現(xiàn)的核心代碼實(shí)在有限。
為了對抗動(dòng)態(tài)調(diào)試，可以考慮在源碼中隨意穿插相關(guān)的檢測代碼，在檢測到動(dòng)態(tài)調(diào)試時(shí)，直接進(jìn)程自殺，異常退出虛擬機(jī)，大致實(shí)現(xiàn)如下：

 /**
     * 檢測動(dòng)態(tài)調(diào)試
     */
    public void detectedDynamicDebug(){
        if (!BuildConfig.DEBUG){
            if (Debug.isDebuggerConnected()){
                //進(jìn)程自殺
                int myPid = android.os.Process.myPid();
                android.os.Process.killProcess(myPid);

                //異常退出虛擬機(jī)
                System.exit(1);
            }
        }
    }

以上只是一個(gè)簡單的例子，市面上很多加固產(chǎn)品做了更多的動(dòng)態(tài)調(diào)試對抗措施。

數(shù)據(jù)保護(hù)

數(shù)據(jù)保護(hù)這個(gè)主要例舉以下幾點(diǎn)：

• 不要在客戶的存放登錄密碼（即使你加密了），最好采用token的形式；
• 數(shù)據(jù)傳輸記得加密；
• 重要數(shù)據(jù)存放內(nèi)置存儲(chǔ)中，不要存放在外置存儲(chǔ)；
• 加密存放在xml和數(shù)據(jù)庫中的重要信息；

資源保護(hù)

資源保護(hù)同樣可以提高逆向分析的難度，但個(gè)人覺得只對逆向小白有效，可以考慮引入試試，目前比較知名的方案就是微信和美團(tuán)兩家的了。

總結(jié)

應(yīng)用安全的攻防就是這么一個(gè)相愛相殺又相輔相成的過程，對于客戶端能做到的安全防范也是有限的，更多的還是應(yīng)該結(jié)合后臺(tái)業(yè)務(wù)分析來實(shí)現(xiàn)相應(yīng)的對抗機(jī)制，對于中小企業(yè)而言，沒有專門的安全人員去研究對抗方案，選擇市面上成熟的加固方案是一個(gè)不錯(cuò)的選擇。而對于大企業(yè)來說，內(nèi)部早已有了自己的安全中心，自然也有自己的一系列對抗方案，包括在后端生成每個(gè)用戶的畫像來判別用戶類型等等。