广西十一选五玩法|广西十一选五开奖查询
  • Android防護相關知識點掃盲

    發布:51Code 時間: 2019-07-26 14:29

  • 已知防護策略 1.不可或缺的混淆 Java 是一種跨平臺、解釋型語言,Java 源代碼編譯成的class文件中有大量包含語義的變量名、方法名的信息,很容易被反編譯為Java 源代碼。為了防止這種...

  • 已知防護策略

    1.不可或缺的混淆

    Java 是一種跨平臺、解釋型語言,Java 源代碼編譯成的class文件中有大量包含語義的變量名、方法名的信息,很容易被反編譯為Java 源代碼。為了防止這種現象,我們可以對Java字節碼進行混淆。混淆不僅能將代碼中的類名、字段、方法名變為無意義的名稱,保護代碼,也由于移除無用的類、方法,并使用簡短名稱對類、字段、方法進行重命名縮小了程序的大小。

    ProGuard由shrink、optimize、obfuscate和preverify四個步驟組成,每個步驟都是可選的,需要哪些步驟都可以在腳本中配置。 參見ProGuard官方介紹。

    ♦ 壓縮(Shrink):偵測并移除代碼中無用的類、字段、方法、和特性(Attribute)。

    ♦ 優化(Optimize):分析和優化字節碼。

    ♦ 混淆(Obfuscate): 使用a、b、c、d這樣簡短而無意義的名稱,對類、字段和方法進行重命名。

    上面三個步驟使代碼size更小,更高效,也更難被逆向工程。

    ♦ 預檢(Preveirfy):  在java平臺上對處理后的代碼進行預檢。

    一般來說優化和預檢選項在Android中是關閉的,腳本如下:

    ♦ dontoptimize

    表示不進行優化,建議使用此選項,因為根據proguard-android-optimize.txt中的描述,優化可能會造成一些潛在風險,不能保證在所有版本的Dalvik上都正常運行。

    ♦ ontpreverify

    表示不進行預校驗。這個預校驗是作用在Java平臺上的,Android平臺上不需要這項功能,去掉之后還可以加快混淆速度。(在安裝apk過程中系統會對dex校驗及優化成odex)

    作為防護來說對于混淆的需求就是Obfuscate,增加閱讀代碼的難度。

    2.簽名校驗

    校驗各個文件的信息,比如微信的dex文件校驗,阿里聚安全的簽名文件校驗等高強度操作。

    第一:直接在本地做防護,如果發現簽名不一致直接退出應用

    第二:將簽名信息攜帶請求參數中參與加密,服務端進行簽名校驗,失敗就返回錯誤數據即可

    Android的簽名機制可以有效防止應用二次簽名后不能覆蓋安裝,具體原理這里不分析了,但也導致安裝了二次簽名的apk,無法覆蓋安裝正常簽名的apk,所以在很容易被二次簽名的防護基礎上進行簽名校驗是有必要的,當然如果很難被反編譯破解就可以酌情考慮了。

    3、反調試異常檢測

    1)so跟蹤調試是基于進程的注入技術,然后使用Linux中的ptrace機制,進行調試目標進程的

    ptrace提供了一種使父進程得以監視和控制子進程的方式,它還能夠改變子進程中的寄存器和內核映像,因而可以實現斷點調試和系統調用的跟蹤

    ptrace機制有一個特點,就是如果一個進程被調試了,在他進程的status文件中有一個字段TracerPid會記錄調試者的進程id值,可以選擇兩種方式:

    1.輪訓查看文件:/proc/[myPid]/status,讀取TracerPid字段的值,發現大于0,就立馬退出程序

    2.一般一個進程只能被附加一次,我們在破解調試的時候都會附加需要調試應用的進程,如果我們先占坑,父進程附加自己,那么后面在附加調試就會失敗

    2) 調試狀態檢查

    1.檢查應用是否屬于debug模式

    直接調用Android中的flag屬性:ApplicationInfo.FLAG_DEBUGGABLE,判斷是否屬于debug模式,為了防止現在破解者為了調試應用將應用反編譯在AndroidManifest.xml中添加:android:debuggable屬性值,將其設置true。然后就可以進行調試。

    2.檢查應用是否處于調試狀態

    借助系統的一個api來進行判斷:android.os.Debug.isDebuggerConnected();這個就是判斷當前應用有沒有被調試

    3.循環檢查端口

    查看設備的tcp端口使用情況 cat /proc/net/tcp

    比如Frida框架,他的端口號是27042和27043,以及進程名是frida-server

    4、加固方案

    加固的基本步驟如下:

    1. 從App原始apk文件里獲取到原始dex文件 

    2. 對原始dex文件進行加密,并將加密后的dex文件和相關的存放到assert目錄里 

    3. 用脫殼dex文件替換原始apk文件里的dex文件;脫殼dex文件的作用主要有兩個,一個是解密加密后的dex文件;二是基于dexclassloader動態加載解密后的dex文件 

    4. 因為原始apk文件已經被修改,所以需要刪除原始apk的簽名信息,即刪除META-INF目錄下的.RSA、.SF 和MANIFEST.MF文件 

    5. 生成加固后的apk文件 

    6. 對加固后的apk文件進行簽名,apk加固完成。

    dex加固主要是防止被靜態反編譯,進而獲取源碼并修改

    除了以上業務相關性弱的防護方案,還有防被抓包,防被hook等和業務密切相關的防護方案,如傳輸數據加密,防作弊等策略。

    以上每個防護策略都有對應的破解之道,當然破解了不代表不能防,防護只是增加破解的難度和時間,攻防沒有永遠的勝利方,有人攻就有人防,防護策略也在不斷的升級更新換代。

    要深入理解Android安全防護,就必須了解Android應用的結構。

    APK(Android  PacKage)結構  

    assets目錄:

    用于存放需要打包到APK中的靜態文件,和res的不同點在于,assets目錄支持任意深度的子目錄,用戶可以根據自己的需求任意部署文件夾架構

    lib目錄:

    程序依賴的native庫(so庫)

    META-INF目錄:

    存放應用程序簽名和證書的目錄,包含的文件有CERT.RSA,CERT.DSA,CERT.SF和MANIFEST.MF,其中CERT.RSA是開發者利用私鑰對APK進行簽名的簽名文件,CERT.SF,MANIFEST.MF記錄了文件中文件的SHA-1哈希值

    res目錄:

    存放應用程序的資源,存在這個文件夾下的所有文件都會映射到Android工程的.R文件中,生成對應的ID,res文件夾下可以包含多個文件夾,其中anim存放動畫文件;drawable目錄存放圖像資源;layout目錄存放布局文件;values目錄存放一些特征值,colors.xml存放color顏色值,dimens.xml定義尺寸值,string.xml定義字符串的值,styles.xml定義樣式對象;xml文件夾存放任意xml文件,在運行時可以通過Resources.getXML()讀取;raw是可以直接復制到設備中的任意文件,他們無需編譯。

    resources.arsc:

    資源配置文件,用來記錄資源文件和資源ID之間的映射關系,用來根據資源ID尋找資源

    AndroidManifest.xml:

    應用程序的配置文件,程序打包時,會把AndroidManifest.xml進行簡單的編譯,便于Android系統識別,編譯之后的格式是AXML格式。

    classes.dex:

    dex可執行文件,傳統的Java程序,首先先把Java文件編譯成class文件,字節碼都保存在了class文件中,Java虛擬機可以通過解釋執行這些class文件。而Dalvik虛擬機是在Java虛擬機進行了優化,執行的是Dalvik字節碼,而這些Dalvik字節碼是由Java字節碼轉換而來,一般情況下,Android應用在打包時通過AndroidSDK中的dx工具將Java字節碼轉換為Dalvik字節碼。dx工具可以對多個class文件進行合并,重組,優化,可以達到減小體積,縮短運行時間的目的。

    對于逆向首入門檻就是dex,了解dex的數據結構對防護和逆向都是極其重要的,dex文件結構分析文章非常多,這里不多贅述,不了解的先去了解下。

    對于Android防護目前流行的最后方案就是加固,某些應用市場已經把加固和上架進行了綁定,說明加固的逆向難度公認度是很高的。

    上面介紹了加固的基本步驟,市面上的加固方案都大同小異,最核心的部分就是對apk/dex進行加密-解析-動態加載,對dex加密各有各的方式和算法,了解dex結構和動態加載之后就可以對不同加固方案進行具體分析了,不過分析大廠的apk之后發現都沒有對dex進行加固就令人深思,也許在客戶端的防護只是門檻,服務端的防護及防作弊才是終極防護策略,而加固會增加崩潰的概率,作為大流量的app來說萬分之一的概率也是很高的,而對dex加固的安全性并不是最高的,所以放棄對dex加固也是有跡可循的。

    作為Android應用開發者來說,navite層的代碼具有更高的挑戰性,大部分Android開發者并不熟悉c/c++開發,所以so的加固應運而生。

    動態鏈接庫so:

    動態鏈接庫是程序運行時加載的庫,當動態鏈接庫正確安裝后,所有的程序都可以使用動態庫來運行程序。動態鏈接庫是目標文件的集合,目標文件在動態鏈接庫中的組織方式是按照特殊方式形成的。庫中函數和變量的地址是相對地址,不是絕對地址,其真實地址在調用動態庫的程序加載時形成。

    so文件是基于ELF(Executable and Linking Format)文件格式。而so是共享目標文件,所以要想對so文件進行加密就必須了解

    ELF文件格式:

    可執行鏈接格式(Executable and Linking Format)最初是由 UNIX 系統實驗室(UNIX System Laboratories,USL)開發并發布的,作為應用程序二進制接口(Application Binary Interface,ABI)的一部分。工具接口標準(Tool Interface Standards,TIS)委員會將還 在發展的 ELF 標準選作為一種可移植的目標文件格式,可以在 32 位 Intel 體系結構上的 很多操作系統中使用。

    目標文件有三種類型:

    可重定位文件(Relocatable File) .o)包含適合于與其他目標文件鏈接來創建可執行文件或者共享目標文件的代碼和數據。

    可執行文件(Executable File) .exe) 包含適合于執行的一個程序,此文件規定了exec() 如何創建一個程序的進程映像。

    共享目標文件(Shared Object File) .so) 包含可在兩種上下文中鏈接的代碼和數據。首先鏈接編輯器可以將它和其它可重定位

    文件和共享目標文件一起處理, 生成另外一個目標文件。其次動態鏈接器(Dynamic Linker)可能將它與某 個可執行文件以及其它共享目標一起組合,創建進程映像。

    目標文件全部是程序的二進制表示,目的是直接在某種處理器上直接執行。

    了解ELF格式分析移步ELF文件格式與動態鏈接/靜態鏈接與動態庫/靜態庫。

    通過對so中的section和函數進行加密來加固對逆向的難度會提高很多,雖然對于了解so的人來說并不是難事,比如動態調試一下,或者dump出內存中運行的dex,所以沒有絕對的安全,只有相對的攻防。

    文章來源:網絡 版權歸原作者所有
    如涉及知識產權問題,請權利人聯系博為峰小編(021-64471599-8103),我們將立即處理。
  • 上一篇:App相互喚醒的幾種方式

    下一篇:怎樣在Android面試中聊聊多線程

網站導航
Copyright(C)51Code軟件開發網 2003-2019 , 滬ICP備05003035號-6
广西十一选五玩法 捕鱼多福技巧 pk10免费计划软件哪个好 时时彩倍投怎样稳赚 福建快三哪里开奖最快 聊城赚钱行业 11选5任7聪明组合 加拿大28稳赚计划 疯狂玩德州 赚钱宝还赚钱吧 单机麻将下载