继续
于《两》通过专门出台ptrace实施注射的技术解决方案,在这一章,我就为大家介绍一Android在独特的喷射技术,我点了他的名字——Component Injection。顾名思义。这种方法是现在Android相关组件,具体见以下的说明。
Component Injection
原理
在android的开发人员文档里。对android:process的描写叙述是这种:
android:process
process
attribute.<manifest>
element.with the same certificate.
shared with other applications, reducing resource usage.
从描写叙述上能够发现,当两个应用。它们签名同样且具备同样的shareduserID,它们之间仅仅有一个组件的android:process是同样的,那么这两个组件之间的互动能够发生在同一个进程里。这里所说的同一个进程。事实上就是进程注入的效果的了。
演示样例二
演示样例二相同包括两部分代码。各自是com.demo.host和com.demo.inject,它们的代码都很easy,例如以下所看到的:
com.demo.host
先看看host的manifest.xml的配置
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.demo.host"
android:sharedUserId="com.demo"
android:versionCode="1"
android:versionName="1.0" > <application
android:name=".DemoApplication"
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:process="com.demo"
android:theme="@style/AppTheme" >
<activity android:name=".MainActivity" >
<intent-filter>
<action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application> <uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="9" /> </manifest>
关键代码
package com.demo.host; import android.app.Activity;
import android.content.ContentResolver;
import android.net.Uri;
import android.os.Bundle;
import android.util.Log; /**
*
* @author boyliang
*
*/
public final class MainActivity extends Activity {
private static int sA = 1; public static void setA(int a) {
sA = a;
} public static int getA() {
return sA;
} @Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState); ContentResolver resolver = getContentResolver();
Uri uri = Uri.parse("content://demo_contentprovider");
resolver.query(uri, null, null, null, null); new Thread() { public void run() {
while (true) {
Log.i("TTT", "" + getA());
setA(getA() + 1); try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}; }.start();
}
}
host一启动,就立即调用ContentResolver的query,这个正是Inject里的ContentProvider组件。
com.demo.inject
manifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.demo.inject"
android:sharedUserId="com.demo"
android:versionCode="1"
android:versionName="1.0" > <application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:process="com.demo"
android:theme="@style/AppTheme" > <provider
android:name=".DemoContentProvider"
android:authorities="demo_contentprovider"
android:exported="false" /> </application> <uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="9" /> </manifest>
关键代码
<span style="white-space:pre"> </span>@Override
public Cursor query(Uri arg0, String[] arg1, String arg2, String[] arg3, String arg4) { final Timer timer = new Timer("demo");
timer.schedule(new TimerTask() { @Override
public void run() {
try {
Log.i("TTT", ">>>>>>>>>>>>>I am in, I am a bad boy!!!!<<<<<<<<<<<<<<\n");
//Class<?> MainActivity_class = Class.forName("com.demo.host.MainActivity");
Context context = ContexHunter.getContext();
ClassLoader classloader = context.getClass().getClassLoader();
Class<?> MainActivity_class = classloader.loadClass("com.demo.host.MainActivity");
Method setA_method = MainActivity_class.getDeclaredMethod("setA", int.class);
setA_method.invoke(null, 998);
} catch (Exception e) {
e.printStackTrace();
} timer.cancel();
} }, 5000); return null;
}
inject中,当query被调用后。会等待5s,然后通过反射调用host的MainActivity.setA方法,改动打印的数值。
绕过ClassLoader双亲托付
细心的朋友会发现,inject的代码中。获取MainActivity的Class。并非直接通过Class.forName("com.demo.host.MainActivity")获取到,而是先获取到全局Context(即Application对象)。然后再调用其ClassLoader来间接获取得的。为什么要这样呢?我我们知道,Java中每一个class都是通过双亲托付机制载入的,这方面的内容能够參考http://blog.csdn.net/xyang81/article/details/7292380,以下我画出示意图:
当我们尝试在DemoContentProvider通过Class.forNmae寻找MainActivity时,必定会抛ClassNotFoundException。唯一可行的方案是找到host的PathClassLoader,然后通过这个ClassLoader寻找MainActivity。我们须要寻找的变量须要满足例如以下条件:
- 这个变量必须由host产生的;
- 这个变量必须是全局的,并且其引用会保存在BootClassLoader(也就是Android SDK中的某个引用)。
- 能够通过反射机制读取到;
非常自然的,想到了host的Application对象。
通过阅读源代码。发现能够通过以下的方式读取到Application对象:
- 假设是System_Process。能够通过例如以下方式获取
Context context = ActivityThread.mSystemContext
- 假设是非System_Process(即普通的Android进程)。能够通过例如以下方式获取
Context context = ((ApplicationThread)RuntimeInit.getApplicationObject()).app_obj.this$0
输出
理解了上述的原理之后,我们再看看演示样例的输出:
I/TTT ( 633): com.demo.inject starts.
I/TTT ( 633): com.demo.host starts
I/TTT ( 633): 1
I/TTT ( 633): 2
I/TTT ( 633): 3
I/TTT ( 633): 4
I/TTT ( 633): 5
I/TTT ( 633): >>>>>>>>>>>>>I am in, I am a bad boy!!!!<<<<<<<<<<<<<<
I/TTT ( 633): 998
I/TTT ( 633): 999
I/TTT ( 633): 1000
I/TTT ( 633): 1001
I/TTT ( 633): 1002
I/TTT ( 633): 1003
从前二行就能够看出,这两个组件都是执行在同一个进程的。从第5秒開始。打印的数据開始发生变化,证明我们的注入逻辑生效了。
文中的演示样例代码。大家能够到https://github.com/boyliang/Component_Injection下载
最后
ComponentInjection的优点是不须要ROOT权限,但其使用限制或许多。但假设跟MaskterKey漏洞结合起来用,那效果还是相当惊艳的。我们知道。Zygote进程会接收来自system_process的命令,当中比較关键的信息有uid, gid, gids, classpath, runtime-init等等。这些信息是决定了Zygote子进程的载入容器以及所从属的uid。
通过MasterKey漏洞我们能够伪造系统的Setting包。Setting与system_process的配置正好符合我所说的ComponentInjection条件,因此利用这样的方式。能够注入到system_process进程,进而控制传递给Zygote的參数。当中classpath和runtime-init是载入容器的配置,classpath是指向一个dex文件的路径,runtime-init是其main函数所在的类名,通过指定每一个App的载入容器。就能够非常巧妙的控制了全部普通用户的进程的环境。
LBE 以前就是利用这样的技术实现主动防御的。更具体的介绍可訪问http://safe.baidu.com/2013-10/lbe-root.html。只是这个文章分析得并不到位。最关键的环节即ComponentInjection并没有提及,结合的我分享。算是做一个完美的补充吧。
这一章节里。介绍了一种Android特有的注入技术,通过一些小技巧绕过了Java的双父托付机制。并且找到了能够轻松找到Application对象的方法,这个对象在Android开发中能够是至关重要的。在接下来的《四》里,我会具体介绍怎样利用JNI获取JNIEnv指针,再通过JNI找到DexCloassLoader载入中DEX档。
版权声明:本文博主原创文章,博客,未经同意不得转载。