阿里巴巴移動安全應用加固能力養成記

近些年來，移動APP數量呈現爆炸式的增加，黑產也從原來的PC端轉移到了移動端，伴隨而來的逆向攻擊手段也愈來愈高明。在解決加固產品容易被脫殼的方案中，代碼混淆技術是對抗逆向攻擊最有效的方式之一。但目前的移動端加固技術真能抵禦黑客的攻擊嗎？  

本報告將分享阿里巴巴集團安所有應用加固能力養成記，重點介紹Android加固對於端上的業務風險控制是如何作到自動化部署和分析，更快捷的感知安全風險，以便快速作出響應，減小沒必要要的業務損失。  

主講人：阿里巴巴安全專家亂武。

今天講的大的標題叫【APP加固新方向】，副標題主要講阿里巴巴對Android加固的基礎介紹，以及在開發這個產品過程當中遇到的一些問題和一些複雜場景的適配過程。因爲大會給個人時間是25分鐘到30分鐘，整個安卓加固方面涉及的技術點還蠻多的，爲了讓此次的分享有一個比較聚焦的點，因此此次的分享主要是講Androidjava代碼方面的保護，也就是說編譯成Android安裝文件以後，Dex文件方面的一些基礎保護點。  

我此次分享的主要有三個部分，第一部分主要是要介紹一下Androidjava代碼保護的技術。第二部分介紹一下應用加固在複雜業務場景下的挑戰以及遇到的一些問題。第三部分說一下將來對於Androidjava代碼保護的一些思路，跟你們分享一下，也許你們未來會碰到，或者有相應的一些啓發。  

第一部分主要講Androidjava代碼的技術保護，剛纔主持人作了一個小的問卷調查，這裏很多同窗不是開發，我大概介紹一下這個上下文。  

自己安卓手機你們不陌生，蘋果和安卓，目前是業內主流的兩大智能操做系統。安卓自己的開發環境是用java語言開發的，它有一個特色。因爲java語言生成的文件是在虛擬機裏面執行的，必然要保留大量的語義，虛擬機可以認識可執行文件的時候保留了不少的語義。這就帶來一個問題，既然編譯生成這種Dex格式，保留了大量的語義，而這種格式谷歌對外徹底公開的，惡意者經過反編譯達到看到原來Java代碼的這種目的。不論是阿里巴巴仍是其餘安全加固的友商，對安卓java代碼的一個保護，也就是安卓上面Dex文件的保護，從加固服務產生到如今一直是重點。  

我簡單介紹一下Androidjava代碼以及Dex代碼保護迭代介紹，業內主要總結了四代的保護方案。  

第一代加固自己這種方案剛出來的時候，大概是2013到2014年之間，自己這個加固方案對於安卓自己的可執行文件，也就是Dex文件的保護，至關因而在打包的時候，就是生成整個安卓安裝應用包的時候會對Dex進行加密。加密算法各類各樣，能夠用AES，也能夠用其它的。在運行的時候經過一個自定義的類加載器進行解密，真正在運行的時候是完整的原來應用開發者編譯出來的Dex文件。這種加固的特色一目瞭然，你拿到文件的時候，既不知道密鑰，也不知道加密算法，看不出來文件的整個邏輯，這個時候必定程度上可以防住，經過一些開源的工具逆向分析這個Dex文件。  

缺點也很明顯，由於它簡單，由於運行時用一個自定義的類加載器在加載的時候解密，把這點攔掉，就把這個殼脫了。  

那經過一段時間的發展之後，又出現了第二代的保護方案，就是類級別的Dex保護。我前面介紹了其實Dex文件來講，它的格式是公開的，公開就意味着這裏面的某些類、某些函數保護的code在哪個位置，其實全部人都可以知道。因此第二代的保護方案，至關於把Dex裏面要保護的核心函數抽離出來生成另一個文件，利用一個虛擬機類加載機制。自己虛擬機有一個特色，它必然會掉到這個類裏面的一個方法，咱們已經在打包的時候，將這些核心函數保留在已知的位置，經過這個函數調用咱們的修復函數，而後將全部的業務邏輯進行修復。這樣的一個方案，其實主要的原理仍是利用虛擬機類加載機制的特色來達到必定保護的效果。固然這種保護有一個特色，咱們若是簡單來講，即使是我把它抽離了，最後運行的指令是谷歌支持的Dex標準指令，這點你們要注意。  

第三代跟前面兩代徹底不一樣，由於谷歌的Dex指令是開源的，無論第一代第二代，內存中運行的都是谷歌的標準指令，因此從原理上必定有辦法將這個指令徹底逆向出來，而後把它反編譯出來。可是第三代就有一個質的區別了。其實第一步和第二代是同樣的，也是在編譯打包的時候將Dex的核心函數抽離的，抽離後，翻譯成一種本身定義的指令，用本身的一種編譯指令進行翻譯，把這個指令變一個種，變成其餘的指令，這個時候運行的時候經過本身的解釋器來解釋執行，是本身定義的相關指令，這是跟第二代有質的區別的。我在內存中運行的指令，在某些保護的函數裏面就必定不是谷歌的標準指令了，這點可以頗有效的防止內存直接拷貝等破解方案。  

第四代，也是行業目前公認的方案，就是java2C的保護方案，這種更簡單直接，它的原理很清晰，咱們若是做爲一個開發者，在開發java代碼的時候，不論是原來傳統的PC上的java虛擬機仍是谷歌的虛擬機，java代碼必定是能夠翻譯成用C代碼來表示的。好比說寫一個java代碼的函數，從原理來講其實只要不嫌麻煩，我必定可以利用虛擬機漏出的接口寫成C代碼，這種保護方案直接從根源上解決這個問題。你認爲核心要保護的函數，咱們直接在編譯打包的時候將這些函數翻譯成C語言的代碼，而後再用編譯器編譯成一個so的文件，也就是這個CPU支持的一個二進制code，這樣達到了比較好的保護。  

這基本上就是我介紹目前安卓移動端對於java代碼保護的四代技術。  

由於第一代和第二代技術相對比較簡單，我介紹一下第三代和第四代技術整個的框架流程圖。  

自定義解釋器的Dex保護方法第一部分應用打包和普通的是沒有什麼區別的，最終生成的也是安卓系統可以認識的一個可執行的文件。可是到了第二步和第三步的時候就有點區別了，第二步要通過一個加固的工具鏈，由於也是一個安卓的可知性的文件，首先要找到一個Dex文件，抽取核心函數指令，而後埋點一些hook接口，接下來打包還回apk文件，簽名後應用發佈。藍色的部分表示是在運行時，黃色的部分是沒有安裝到用戶手上，藍色的部分應用已經發布了，而後在用戶的手機上執行的一個邏輯。由於第二步埋點了hook接口，就進入一個自定義的一個解釋器，根據傳譯的二進制的code翻譯成原來Dex文件想保護的java那個code的邏輯，完成了第三代的保護效果。真正在解釋的時候解釋執行的就是這種變種的指令，而後達到正常執行業務邏輯的效果，這是第三代的一個自定義解釋器Dex保護方案的介紹。  

說一下第四代java2C保護方法的介紹，前兩步也跟第三代是同樣的，就是開發者本身編譯好的一個安卓可安裝程序。不一樣的是，直接簡單粗暴將須要保護的Dex核心函數直接翻譯成C代碼。好比一個編譯好的Dex文件，直接把這個函數編譯成C代碼，能夠自定義一個編譯器翻譯成一個C代碼。C代碼仍是很成熟的，能夠用各類各樣的編譯器，包括谷歌以及第三方編譯器，這樣徹底去除了裏面的核心指令，就變成看這個手機或者這個架構支持的Dex文件。這裏面運行的時候又有不一樣，由於這個時候是須要把SO給打進APP裏面，由於這些代碼其實已經編成SO，要加到apk裏面，因此核心函數通常加一個native標籤，調到自己的SO裏面，後面的執行瓜熟蒂落了，就是本地指令的執行保護函數，可以達到徹底的正常執行的業務邏輯。  

第一部分大概介紹完了，包括目前比較流行的新的技術，就是第三代和第四代，可是其實我這邊要說一下第三代和第四代的一些缺點。  

從剛纔的介紹看起來比較美好，可是到了第三代的自定義解釋器的時候，這個時候因爲要hook系統的一些接口，普通的應用開發者要遇到不少碎片化的問題，對於加固要調用大量的系統私有api的安全服務來講，可能遇到的問題更顯突兀，因此基本上在第三代的自定義解釋器的保護方案，不是說不強，但可能遇到碎片化的東西比較多，到第四代其實反倒碎片化比較小，爲何你們比較推崇java2C的保護方案，是由於把java代碼翻譯成C代碼再編譯成SO，是徹底符合不少虛擬機的開發規範的，這樣的兼容性問題最小。固然這兩個場景也有一個問題，它編譯出來的函數可能會體積變大，可能執行效率變低，可是這些都是一些具體的細節，今天的時間有限，就再也不詳細贅述了。  

第二部分介紹一下加固在複雜業務場景下的挑戰。  

安卓從幾年前你們也不是特別看好的一個智能操做系統到如今成爲全球第一大的智能操做系統來講，自身的操做系統是有一個不斷的迭代，包括今年最新發布的androidO，咱們能看到它的進步。在安卓上面開發各類業務其實如今已經變得很複雜了，就以咱們阿里巴巴公司比較旗艦類型的應用，好比手機淘寶和支付寶的應用，應用開發的流程和開發使用的黑科技的各類技術，已是不亞於傳統上面的一些PC上面一些比較複雜的客戶端開發的程度了，因此加固在服務於這些應用的時候，也面臨着一些複雜業務場景的挑戰，我作一些簡單的介紹，舉兩個例子。  

Hotpatch應用場景，安卓應用若是是說在你的應用發佈之後，到了用戶的手機端上之後若是發現一些bug，按照傳統的方案有一種解決方式，用戶升級再更新一個版本、從新安裝一遍把這個問題解決了。可是在對於不少複雜的應用來講，好比說像手機淘寶或者天貓或者支付寶，它自己的一個安裝包就已經70多兆了，好比裏面有一個很小的bug，好比哪個頁面顯示不對，讓用戶徹底的升級一遍，從新下載包升級一下，用戶體驗不是很好，他們業務方開始研究一種技術，當我發現某一個地方某一段代碼有問題了，這個時候我就只修改這一部分代碼，而不須要用戶安裝整個發佈包。咱們這個原始應用有三個類，分爲A/B/C，當我有問題的時候，好比我發現的問題是某一個代碼有bug了，假設B類有bug，我只須要把他弄成一個Dex文件，把這個下發下來，熱部署之後把原始APP裏面的Dex文件修改一下，讓它變成只有A和C這兩個類，而後再經過一些類加載器裏面尋找Dex的順序，達到首先執行個人熱部署後的這個文件，當須要調用B的時候再執行B這個類，達到修復這個原有程序業務邏輯bug的目的，或者我想更新達到更新的效果，固然這種方案目前在安卓上面運行的仍是比較多的，包括阿里也有發佈熱補丁的。原來這種在蘋果上面也會應用，但整個來講蘋果不讓用了，谷歌想在明年P的版本可能會全面限制這種技術方案，可是目前來講發佈O的版本目前尚未這個限制。可是這種方案其實在加固來講，從加固的原理來講有一點衝突，熱部署後的dex文件會出現一點問題，這是加固服務發展過程當中發現的一個比較複雜場景的舉例。  

第二種場景你們更不陌生，因爲業務發展愈來愈複雜，開發規模稍微大一點的應用，須要插件化的部署，好比手機淘寶集成了各類各樣的服務，這時候要多個團隊協做開發，這就無可避免要利用咱們所謂的插件化的思想，而後分步開發。這時候傳統的加固面臨一個問題，最初咱們主要是保護主Dex文件一些根目錄下的Dex文件，插件會埋到lib下面很深的地方，致使加固刺出現盲點，做爲一個通用化的一個加固方案很難作到將全部的Dex文件也保護，可是有些是比較核心的。剛纔我提的這兩個例子，不論是阿里巴巴仍是不少友商，這個問題都獲得很好的解決，具體的細節我就不贅述了。  

最後一部分介紹一下業內認爲將來對於安卓java代碼一種保護手段的思路。  

第四代java2C保護方案是用編譯器編譯成一個標準的SO文件，其實標準的SO文件開發者都很清楚，這種elf格式也是透明的，至關於自己這種格式也是徹底有規範的，是透明的，也是能夠逆向的。既然能夠把DEX文件翻譯成c代碼，那麼也能夠用支持vmp虛殼的編譯器在編譯成內置於vmp虛殼的保護的so。  

風險設備的控制，咱們作安全來講從原理來講，若是不是特別計較成本的話，其實只要在端上運行的東西，特別谷歌開源運行的，其實原理上是可以破解的，只不過你花費的時間長短和破解成本的高低，因此在手機淘寶和電商的超級應用，保護思路愈來愈從端上防禦傾向於端和雲聯合的防禦。在端上在打包的時候會埋入不少點，不論是安全adk仍是自己加固工具鏈的方式，獲取一個端上惟一的標識，咱們稱爲一個設備指紋。像下單這種行爲會加入這種設備指紋的請求，而後服務器經過這個指紋識別進行風險控制，好比咱們認爲是惡意者操控的設備，能夠加入黑名單，不會讓這個應用崩潰。好比你搶紅包搶不到，你買東西買不成功，給用戶一個反饋，這種其實保護效果是至關好的。