如何hook android sdk

1.1 概述 Xposed 是 GitHUB 上 rovo89 大大設(shè)計(jì)的一個(gè)針對(duì) Android 平臺(tái)的動(dòng)態(tài)劫持項(xiàng)目，通過替換 /system/bin/app_process 程序控制 zygote 進(jìn)程，使得 app_process 在啟動(dòng)過程中會(huì)加載 XposedBridge.jar 這個(gè) jar 包，從而完成對(duì)系統(tǒng)應(yīng)用的劫持。 Xposed 框架的基本運(yùn)行環(huán)境如下：因?yàn)?Xposed 工作原理是在 /system/bin 目錄下替換文件，在 install 的時(shí)候需要root 權(quán)限，但是運(yùn)行時(shí)不需要 root 權(quán)限。需要在 Android 4.0 以上版本的機(jī)器中2. GitHub 上的 Xposed 資源梳理一下，可以這么分類： XposedBridge.jar ： XposedBridge.jar 是 Xposed 提供的 jar 文件，負(fù)責(zé)在 Native層與 FrameWork 層進(jìn)行交互。 /system/bin/app_process 進(jìn)程啟動(dòng)過程中會(huì)加載該jar 包，其它的 Modules 的開發(fā)與運(yùn)行都是基于該 jar 包的。 Xposed ： Xposed 的 C++ 部分，主要是用來替換 /system/bin/app_process ，并為 XposedBridge 提供 JNI 方法。 XposedInstaller ： Xposed 的安裝包，負(fù)責(zé)配置 Xposed 工作的環(huán)境并且提供對(duì)基于 Xposed 框架的 Modules 的管理。 XposedMods ：使用 Xposed 開發(fā)的一些 Modules ，其中 AppSettings 是一個(gè)可以進(jìn)行權(quán)限動(dòng)態(tài)管理的應(yīng)用 1.2 Mechanism ：原理 1.2.1 Zygote 在 Android 系統(tǒng)中，應(yīng)用程序進(jìn)程都是由 Zygote 進(jìn)程孵化出來的，而 Zygote 進(jìn)程是由 Init 進(jìn)程啟動(dòng)的。 Zygote 進(jìn)程在啟動(dòng)時(shí)會(huì)創(chuàng)建一個(gè) Dalvik 虛擬機(jī)實(shí)例，每當(dāng)它孵化一個(gè)新的應(yīng)用程序進(jìn)程時(shí)，都會(huì)將這個(gè) Dalvik 虛擬機(jī)實(shí)例復(fù)制到新的應(yīng)用程序進(jìn)程里面去，從而使得每一個(gè)應(yīng)用程序進(jìn)程都有一個(gè)獨(dú)立的 Dalvik 虛擬機(jī)實(shí)例。 Zygote 進(jìn)程在啟動(dòng)的過程中，除了會(huì)創(chuàng)建一個(gè) Dalvik 虛擬機(jī)實(shí)例之外，還會(huì)將 Java運(yùn)行時(shí)庫加載到進(jìn)程中來，以及注冊(cè)一些 Android 核心類的 JNI 方法來前面創(chuàng)建的 Dalvik 虛擬機(jī)實(shí)例中去。注意，一個(gè)應(yīng)用程序進(jìn)程被 Zygote 進(jìn)程孵化出來的時(shí)候，不僅會(huì)獲得 Zygote 進(jìn)程中的 Dalvik 虛擬機(jī)實(shí)例拷貝，還會(huì)與 Zygote 一起共享 Java 運(yùn)行時(shí)庫。這也就是可以將XposedBridge 這個(gè) jar 包加載到每一個(gè) Android 應(yīng)用程序中的原因。 XposedBridge 有一個(gè)私有的 Native （ JNI ）方法 hookMethodNative，這個(gè)方法也在 app_process 中使用。這個(gè)函數(shù)提供一個(gè)方法對(duì)象利用 Java 的 Reflection 機(jī)制來對(duì)內(nèi)置方法覆寫。具體的實(shí)現(xiàn)可以看下文的 Xposed 源代碼分析。 1.2.2 Hook/Replace Xposed 框架中真正起作用的是對(duì)方法的 hook 。在 Repackage 技術(shù)中，如果要對(duì)APK 做修改，則需要修改 Smali 代碼中的指令。而另一種動(dòng)態(tài)修改指令的技術(shù)需要在程序運(yùn)行時(shí)基于匹配搜索來替換 smali 代碼，但因?yàn)榉椒暶鞯亩鄻有耘c復(fù)雜性，這種方法也比較復(fù)雜。 在 Android 系統(tǒng)啟動(dòng)的時(shí)候， zygote 進(jìn)程加載 XposedBridge 將所有需要替換的 Method 通過 JNI 方法 hookMethodNative 指向 Native 方法 xposedCallHandler ， xposedCallHandler 在轉(zhuǎn)入 handleHookedMethod 這個(gè) Java 方法執(zhí)行用戶規(guī)定的 Hook Func 。 XposedBridge 這個(gè) jar 包含有一個(gè)私有的本地方法： hookMethodNative ，該方法在附加的 app_process 程序中也得到了實(shí)現(xiàn)。它將一個(gè)方法對(duì)象作為輸入?yún)?shù)（你可以使用 Java 的反射機(jī)制來獲取這個(gè)方法）并且改變 Dalvik 虛擬機(jī)中對(duì)于該方法的定義。它將該方法的類型改變?yōu)?native 并且將這個(gè)方法的實(shí)現(xiàn)鏈接到它的本地的通用類的方法。換言之，當(dāng)調(diào)用那個(gè)被 hook 的方法時(shí)候，通用的類方法會(huì)被調(diào)用而不會(huì)對(duì)調(diào)用者有任何的影響。在 hookMethodNative 的實(shí)現(xiàn)中，會(huì)調(diào)用 XposedBridge中的handleHookedMethod這個(gè)方法來傳遞參數(shù)。 handleHookedMethod 這個(gè)方法類似于一個(gè)統(tǒng)一調(diào)度的 Dispatch 例程，其對(duì)應(yīng)的底層的 C++ 函數(shù)是 xposedCallHandler 。而 handleHookedMethod 實(shí)現(xiàn)里面會(huì)根據(jù)一個(gè)全局結(jié)構(gòu) hookedMethodCallbacks 來選擇相應(yīng)的 hook函數(shù)，并調(diào)用他們的 before, after 函數(shù)。 當(dāng)多模塊同時(shí) Hook 一個(gè)方法的時(shí)候， Xposed 會(huì)自動(dòng)根據(jù) Module 的優(yōu)先級(jí)來排序，調(diào)用順序如下： A.before - B.before - original method - B.after - A.after 2 源代碼分析 2.1 Cpp 模塊其文件分類如下： app_main.cpp ：類似 AOSP 中的 frameworks/base/cmds/app_process/app_main.cpp，即/system/bin/app_process 這個(gè) zygote 真實(shí)身份的應(yīng)用程序的源代碼。關(guān)于zygote 進(jìn)程的分析可以參照 Android:AOSPCore 中的 Zygote 進(jìn)程詳解。 xposed.cpp ：提供給 app_main.cpp 的調(diào)用函數(shù)以及 XposedBridge 的 JNI 方法的實(shí)現(xiàn)。主要完成初始化工作以及 Framework 層的 Method 的 Hook 操作。 xposed.h ， xposed_offsets.h ：頭文件Xposed 框架中的 app_main.cpp 相對(duì)于 AOSP 的 app_main.cpp 中修改之處主要為區(qū)分了調(diào)用 runtime.start() 函數(shù)的邏輯。 Xposed 框架中的 app_main.cpp 在此處會(huì)根據(jù)情況選擇是加載 XposedBridge 類還是 ZygoteInit 或者 RuntimeInit 類。而實(shí)際的加載 XposedBridge 以及注冊(cè) JNI 方法的操作發(fā)生在第四步： xposedOnVmCreated中。 1．包含 cutils/properties.h ，主要用于獲取、設(shè)置環(huán)境變量， xposed.cpp 中需要將XposedBridge 設(shè)置到 ClassPath 中。 2．包含了 dlfcn.h ，用于對(duì)動(dòng)態(tài)鏈接庫的操作。 3．包含了 xposed.h ，需要調(diào)用 xposed.cpp 中的函數(shù)，譬如在虛擬機(jī)創(chuàng)建時(shí)注冊(cè) JNI 函數(shù)。 4．增加了 initTypePointers 函數(shù)，對(duì)于 Android SDK 大于等于 18 的會(huì)獲取到 atrace_set_tracing_enabled 函數(shù)指針，在 Zygote 啟動(dòng)時(shí)調(diào)用。 5．AppRuntime 類中的 onVmCreated 函數(shù)中增加 xposedOnVmCreated 函數(shù)調(diào)用。 6．源代碼中的 Log* 全部重命名為 ALog*, 所以 Logv 替換為 Alogv ，但是功能不變。 7．Main 函數(shù)開始處增加了大量的代碼，但是對(duì)于 SDK 版本小于 16 的可以不用考慮。2.1.1 Main 函數(shù)： zygote 入口 int main(int argc, char* const argv[])

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了洛寧免費(fèi)建站歡迎大家使用！

android hook技術(shù) 有哪些

幾天前，在看雪安卓版塊的論壇上，看到有人發(fā)表了一份dalvik hook的實(shí)現(xiàn)代碼，這里小弟果斷獻(xiàn)丑下，給提供一份dalvik hook的另外一種實(shí)現(xiàn)。

首先解釋下dalvik虛擬機(jī)中的Method結(jié)構(gòu)體，Method結(jié)構(gòu)體聲明在源碼目錄樹下的dalvik/vm/oo/Object.h文件內(nèi)，在dalvik的世界中，每一個(gè)java方法都有一個(gè)對(duì)應(yīng)的Method對(duì)象，

dalvik虛擬機(jī)在執(zhí)行java方法時(shí)，就會(huì)通過該方法的Method對(duì)象調(diào)用到方法的具體實(shí)現(xiàn)代碼，Method結(jié)構(gòu)體內(nèi)有個(gè)成員，名位insns，該字段保存著java方法具體的實(shí)現(xiàn)代碼。那么我今天提供的這個(gè)dalvik hook的實(shí)現(xiàn)原理就是通過修改Method對(duì)象中的insns字段的值來達(dá)到hook java的目的。

這里簡短的用文字的形式描述下Hook的實(shí)現(xiàn)過程。

現(xiàn)在有一個(gè)返回字符串的函數(shù)原型聲明為:

public String truth()

{

return "hello from truth";

}

另外聲明一個(gè)方法為：

public String fake()

{

return "fake string";

}

之后，該類被加載后，分別獲得truth和fake方法的Method對(duì)象，并將fake方法的實(shí)現(xiàn)代碼賦值給truth的Method對(duì)象，之后，應(yīng)用程序調(diào)用truth方法時(shí)，獲得的字符串為"fake string"。

android插件化(四)Hook加載插件APK(ClassLoader方式)

前面插件化一和二說了下插樁式加載未安裝的APK，主要是重寫了getResource和getClassloader兩個(gè)方法來實(shí)現(xiàn)的。以及每個(gè)組件要實(shí)現(xiàn)一個(gè)接口，通過接口注入上下文來達(dá)到它的生命周期。

那么插樁式和hook式的實(shí)現(xiàn)方式有什么不同呢？

插樁式是怎么加載到插件中的class文件呢，是通過將將APK轉(zhuǎn)化成插件的Classloader，然后想要加載插件的class文件，我們的去拿這個(gè)插件的classloader去loadClass。所以是有一個(gè)中間者的。

hook式呢是將插件apk融入到了我們的宿主apk，那直接在里面就可以直接loadClass了，在不用這個(gè)插件的ClassLoader了，這樣的話對(duì)于插件和宿主就沒什么區(qū)別了，不像插樁式有一個(gè)中間者。

那么要實(shí)現(xiàn)hook式 就要知道android中一個(gè)class文件式怎樣被加載到內(nèi)存中去的。其實(shí)就是通過PathClassLoader來加載的。

那么我們先看下ClassLoader

任何一個(gè)java程序都是由一個(gè)或者多個(gè)class組成的，在程序運(yùn)行時(shí)，需要將class文件加載到JVM中才可以使用，負(fù)責(zé)加載這些class文件的就是java的類加載機(jī)制。CLassLoader的作用就是加載class文件提供給程序運(yùn)行時(shí)使用，每個(gè)Class對(duì)象內(nèi)部都有一個(gè)ClassLoader來標(biāo)示自己是有那個(gè)classLoade加載的。

Android app的所有的java文件都是通過PathClassLoader來加載的，那么它的父類是BaseDexClassLoader，還有一個(gè)兄弟類是DexClassLoader，那么他們有什么區(qū)別呢。

從上面可以看出這兩個(gè)類的構(gòu)造函數(shù)不同。(在26的源碼中DexClassLoader中的optimizedDirectory也廢棄了)

PathClassLoader：用于Android應(yīng)用程序類加載器?？梢约虞d指定的dex，以及jar、zip、apk中的classes.dex

DexClassLoader：加載指定的dex以及jar、zip、apk中的classes.dex。

可以看到創(chuàng)建ClassLoader的時(shí)候需要接收一個(gè)CLassLoader parent的參數(shù)，這個(gè)parent的目的就在于實(shí)現(xiàn)類加載的委托。

某個(gè)類加載器在接到加載類的請(qǐng)求時(shí)，首先將加載任務(wù)委托給父類加載器，一次遞歸，如果父加載器可以完成加載任務(wù)，那么就返回，只有當(dāng)父加載器無法完成加載任務(wù)時(shí)，才自己去加載。

因此我們自己創(chuàng)建的ClassLoader：newPathClassLoader("/sdcard/xx.dex",getClassLoader()),并不僅僅只能加載我們的xx.dex中的class。

需要注意的是，findBootstrapClassOrNull 這個(gè)方法，當(dāng)parent為null的時(shí)候，去這個(gè)BootCLassLoader進(jìn)行加載，

但是在Android當(dāng)中的實(shí)現(xiàn)：

所以new PathClassLoader("/sdcard/xx.dex",null),是不能加載Activity.class的。

上面分析了加載了一個(gè)class，是利用了雙親委托機(jī)制，那么要是都找不到那就開始調(diào)用自己的findCLass方法

在ClassLoader類中findClass：

任何ClassLoader的子類，都可以重寫loadClass和findClass。如果你不想使用雙親委托，就重寫loadClas修改實(shí)現(xiàn)，重寫findClass則表示在雙親委托機(jī)制下，父ClassLoader都找不到class的情況下，定義自己去查找一個(gè)class。

而我們的PathClassLoader會(huì)自己負(fù)責(zé)加載Activity這樣的類，利用雙親委托父類去加載activity，而我們的PathClassLoader沒有重寫findClass，是在它的父類里面。因此我們可以看看父類的findClass是如何實(shí)現(xiàn)的。

可以看到加載PathClassLoader加載class，轉(zhuǎn)化為從DexPathList中加載class了，那么我們看看DexPathList中的findClass

那么從上面分析得到

到這里我們想要加載一個(gè)插件的apk ，其實(shí)最終加載的是一個(gè)dex文件(先說class文件，加載資源后面說)，有沒有辦法吧這個(gè)dex文件給轉(zhuǎn)化成一個(gè) Element 對(duì)象，給放到 Elemeng數(shù)組 當(dāng)中，這樣直接就可以加載我們插件中的類了。

1、首先我們肯定是要得到插件APK的的中DexPathList對(duì)象中的dexElement數(shù)組

2、插件的dexElements數(shù)組我們拿到了，那么是不是要開始拿我們系統(tǒng)里面的 ，我們反射獲取，和上面的一樣。

3、上面我們獲取到了系統(tǒng)和我們插件的dexElement數(shù)組，然后我們將這個(gè)數(shù)組合并到一個(gè)新的數(shù)組里面去，并且給注入到系統(tǒng)里面

至此，加載插件的一個(gè)流程基本就完成了。但是上面只是處理了class文件，沒有處理資源。資源的話我們也是采用hook的方式去實(shí)現(xiàn)

在宿主的Application中hook這個(gè)方法，然后去重寫getAsserts和getResources兩個(gè)方法：

然后在插件的BaseActivity中繼續(xù)重寫getAssets和getResources兩個(gè)方法

這樣就可以完成hook式加載一個(gè)未安裝的APK了。至此基本就完成了插樁式和Hook式插件化的基本實(shí)現(xiàn)。(后面幾篇是優(yōu)化)。

如何hook android framework

1.向目標(biāo)進(jìn)程注入代碼（注入so，并調(diào)用該so里的一個(gè)函數(shù)）。首先調(diào)用ptrace函數(shù)，調(diào)試com.android.browser進(jìn)程，在這里我們需要遍歷該進(jìn)程加載的libc.so，這里有我們需要的dlopen，dlsym等函數(shù)的地址，我們先中斷com.android.phone,修改其寄存器...

android常見hook框架有哪些

1、Xposed：Java層的HOOK框架，由于要修改Zgote進(jìn)程，需要Root；

2、CydiaSubstrator：本地層的HOOK框架，本質(zhì)上是一個(gè)inline Hook；

3、dexposed框架

4、AndFix框架；

5、Sophix 框架；

6、AndroidMethodHook框架；

7、Legend框架：在AndFix框架的基礎(chǔ)上，在方法進(jìn)行替換前進(jìn)行了方法的備份；

8、YAHFA框架；

9、EPIC框架；

10、VirtualXposed：Virtual APP與Xposed的一個(gè)結(jié)合。

擴(kuò)展資料

使用框架的原因

因?yàn)檐浖到y(tǒng)很復(fù)雜，特別是服務(wù)器端軟件，涉及到的知識(shí)，內(nèi)容，問題太多。在某些方面使用別人成熟的框架，就相當(dāng)于讓別人幫助完成一些基礎(chǔ)工作，只需要集中精力完成系統(tǒng)的業(yè)務(wù)邏輯設(shè)計(jì)。

而且框架一般是成熟，穩(wěn)健的，可以處理系統(tǒng)很多細(xì)節(jié)問題，比如，事務(wù)處理，安全性，數(shù)據(jù)流控制等問題。

還有框架一般都經(jīng)過很多人使用，所以結(jié)構(gòu)很好，所以擴(kuò)展性也很好，而且它是不斷升級(jí)的，可以直接享受別人升級(jí)代碼帶來的好處。框架一般處在低層應(yīng)用平臺(tái)（如J2EE）和高層業(yè)務(wù)邏輯之間的中間層。

框架開發(fā)

框架的最大好處就是重用。面向?qū)ο笙到y(tǒng)獲得的最大的復(fù)用方式就是框架，一個(gè)大的應(yīng)用系統(tǒng)往往可能由多層互相協(xié)作的框架組成。

由于框架能重用代碼，因此從一已有構(gòu)件庫中建立應(yīng)用變得非常容易，因?yàn)闃?gòu)件都采用框架統(tǒng)一定義的接口，從而使構(gòu)件間的通信簡單。

框架能重用設(shè)計(jì)。它提供可重用的抽象算法及高層設(shè)計(jì)，并能將大系統(tǒng)分解成更小的構(gòu)件，而且能描述構(gòu)件間的內(nèi)部接口。

這些標(biāo)準(zhǔn)接口使在已有的構(gòu)件基礎(chǔ)上通過組裝建立各種各樣的系統(tǒng)成為可能。只要符合接口定義，新的構(gòu)件就能插入框架中，構(gòu)件設(shè)計(jì)者就能重用構(gòu)架的設(shè)計(jì)。

框架還能重用分析。所有的人員若按照框架的思想來分析事務(wù)，那么就能將它劃分為同樣的構(gòu)件，采用相似的解決方法，從而使采用同一框架的分析人員之間能進(jìn)行溝通。

參考資料來源：百度百科-框架