方舟編譯器來了,APK加固還怎麼搞

方舟編譯器來了,apk裏的代碼都變成so文件了,還怎麼做加固?

熱烈歡迎方舟編譯器上線開源!

根據華爲發佈的方舟編譯器架構圖可看出,應用方舟編譯器後,輸出變成了二進制文件,並添加編譯器運行時庫後最終鏈接成可執行文件。類 Linux 系統的可執行文件一般是指無後綴的二進制文件(對應 Windows 下的 .exe 文件)和 .so 文件(對應 Windows 下的 .dll 文件)。華爲官方表示方舟編譯器能夠將系統操作流暢度提升 24%、系統響應力提升 44%、第三方應用操作流暢度提升 60%。如此大的性能提升,簡直是一統江湖之勢。所謂:優化盡頭誰爲峯,一見方舟道成空!

有鑑於安卓平臺各種黑產極爲猖狂,一般的應用軟件開發者都要將自己的 apk 軟件包做加固之後再發布。而講到 apk 加固,主要是對 dex 文件做加密。dex 是 Android 平臺上(Dalvik/Art 虛擬機)的可執行文件, 相當於 Windows 平臺中的 exe 文件, 每個 Apk 安裝包中都有 dex 文件, 裏面包含了該 app 的所有代碼, 通過反編譯工具可以獲取到相應的 java 源碼。dex 文件加密就是 apk 加固的核心問題。那麼問題來了,方舟編譯器直接把 Java 代碼變本地代碼( .so 文件)了,apk 加固的重心必將轉到 so 文件加殼。那麼我們有現成的 so 加殼技術嗎?現有的 so 加殼技術能保證我們的應用安全嗎?援引現有的基於 dex 的 apk 加殼技術,將 so 庫加殼也做一下分代介紹

分代 原理 破解方法
1.1 對so文件整體加密,創建Loader, so文件運行時loader先運行,對密文解密,恢復原程序 難度*,直接掛鉤,dump內存中的明文即可得到so文件,簡單修復即可。
1.2 函數級加密。將每個函數單獨加密,將原函數替換爲中轉函數,中轉函數做解密,並將原函數的明文寫回原地址 難度*,需要將各個函數運行一遍後再dump,並修復
1.3 函數級加密。將每個函數單獨加密,將原函數替換爲中轉函數,中轉函數做解密,並將原函數的明文分配在堆上 難度**,需要對運行過程做分析,將加密函數掛鉤,並找出對應的明文地址,再dump+修復
2 類ollvm代碼混淆 基於蘋果的開源LLVM框架,魔改clang編譯器,在編譯過程的IR(中間代碼)層面做混淆操作。讓軟件開發商換用魔改版clang編譯器。得到混淆後的so文件。常見的混淆手段見附錄。 難度***,僅對代碼做了變形,並沒有隱藏代碼,只是代碼裏多了很多的垃圾,複雜了很多,增加了算法分析的難度。不能防止反編譯,基本上用ida可以反編譯成C語言代碼,很容易分析。
2.5 基於LLVM的代碼虛擬化。用LLVM基礎庫構造虛擬機指令handler,規避後端指令多樣性,在不涉及具體CPU的前提下實現虛擬化。由於方舟編譯器是開源的,並且也有中間的IR表示,可以想見同樣原理的混淆和虛擬化技術也會紛紛湧現。 難度***+,與混淆相比,代碼邏輯隱藏較深,但一般handler可以反編譯成C語言,分析難度不高。但代碼邏輯隱藏到了虛擬指令中,算法還原較爲複雜。
3 本地代碼混淆。直接對so文件中的二進制代碼進行混淆。2代殼中所用的手段在此同樣可用。針對不同的指令要單獨開發一套混淆方法,不具備2代的平臺普適性。但是由於是彙編/字節碼級別的混淆,可任意插入各種不常用的指令,手段更靈活,代碼更復雜。 難度****,各種你想不到的指令和應用都可能出現。ida基本不能反編譯成C語言代碼。雖然沒有真的將代碼隱藏起來,但各種地址變換和跳轉指令結合,根本沒有一個好的方法找到目標代碼。破解難度比ollvm上升一個級別。
4 本地代碼虛擬化。直接對so文件中的二進制代碼進行虛擬化。 難度*****,同時具備2.5和3的特點,破解極難。想想就頭疼。

商業化產品分析

  • 1代:upx
  • 2代:基於ollvm的互聯網產品:梆梆、愛加密、360、騰訊、網易、百度… 所謂安全編譯器都是
  • 2.5 梆梆(SI2S安全編譯器)、深思數盾(Virbox Compiler)
  • 3代:深思數盾-VirboxProtector
  • 4代:無。

總結

世界上從來沒有無緣無故的愛,也沒有無緣無故的恨。任何高大上的技術都不是空中樓閣。方舟編譯器橫空出世極大改變了安卓生態環境,但我們也不必因此而驚慌失措。安全技術公司深厚的技術積累足以應對因此而帶來的變局。

附錄

  • ollvm常見混淆手段
  1. 控制流扁平化 這個模式主要是把一些if-else語句,嵌套成do-while語句
  2. 指令替換 這個模式主要用功能上等效但更復雜的指令序列
  3. 虛假控制流程 這個模式主要嵌套幾層判斷邏輯,一個簡單的運算都會在外面包幾層if-else 參考文檔:《OLLVM代碼混淆移植與使用》
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章