安卓安全小分队系列文章

最新推荐文章于 2024-10-27 23:54:38 发布

weixin_33853794

最新推荐文章于 2024-10-27 23:54:38 发布

阅读量125

点赞数

文章标签：移动开发 java 操作系统

原文链接：https://my.oschina.net/zhuzihasablog/blog/115651

版权

2019独角兽企业重金招聘Python工程师标准>>>

1. 智能手机网络防火墙的现状

随着智能手机越来越普及，以及3G网络的快速发展，越来越多的用户使用手机上网冲浪。于此同时，各类恶意软件也通过网络来盗取用户手机上的的隐私，甚至控制用户的手机。因此智能手机上的防火墙应运而生。

与PC上的环境不同， Android手机上的网络环境相对没有那么复杂。因此现行主流的Android防火墙解决方案都是对手机里的应用设置网络访问权限，而不会像PC上的防火墙那样提供强大的网络监视、数据包过滤、端口监控等功能。

2. Android网络防火墙的几种实现方式

a) Android应用层：敏感函数hook

i. 绝大多数Android应用都是调用Android Framework来实现网络通讯。例如：WebView.loadUrl()，HttpClient.execute()，DefaultHttpClient.execute()等。只需穷举这些类的函数，并将它们都Hook住，就可实现拦截上网的功能了。

ii. 当然想要Hook这些函数入口，有两种方式：1. 首先获得root权限，然后通过进程注入，将Client代码注入到应用进程，在进程上网时，应用进程将会发起IPC请求到Server进程，由Server进程来决定是否允许其访问网络。2. 通过修改应用本身来加入Hook代码，从而避免了root手机，相对比较安全。洗大师就是使用了这种方法。

iii. 这种方案的优点是：简单、快速、可实现网络热开关（无需杀死进程）。缺点是：不能拦截所有的网络访问入口。例如：某应用没有调用Android的库，而是自己实现了一个访问网络的库，或者甚至用native代码来实现，那么这时候这个方案将拦截不到任何的上网请求。

b) Android框架层：android.permission.INTERNET权限

i. 在Android系统中，任何想访问网络的应用必须申请android.permission.INTERNET权限。当Zygote在fork()一个AndroidManifest.xml中带有这个权限的应用时，会将当前应用加到inet组中。凡是一个进程的gid组中有inet，那么这个应用就有权限上网。

ii. 因此禁止应用上网有两种方式：1. 修改应用的AndroidManifest.xml，使其没有android.permission.INTERNET权限。2. 获得root权限，然后注入zygote进程，使其在fork()之后，不要将inet设到应用的gid组中。

iii. 这个方案相对于第一个方案来说，它可以彻底的屏蔽一个应用上网。实现起来也不复杂，但是gid组一旦设定后，应用进程将再无权限修改。因此被禁止掉上网权限的进程，想要再次获得上网权限，则必须杀死，然后重新由zygote进程fork()生成。

c) Linux内核层：iptables

i. 在Linux内核中，NetworkFilter在TCP/IP的协议栈中加了相应的Hook。通过这些Hook我们可以对网络数据包可以进行过滤，丢弃，修改等。但直接使用起来相对麻烦。幸好Linux给我们提供了一个强大的工具：iptables来简化这一过程。Iptables是一个Linux命令，通过这个命令，可以对整个系统发出去的包，接收到的包，以及转发的包进行拦截，修改，拒绝等操作。具体起使用方法，这里不再展开，有兴趣的朋友可以自行到网上搜索相应的资料即可。

ii. Iptable不仅可以按照uid来禁用应用上网，还可以分别禁用某个uid的3G上网和Wifi上网。这给用户带来的极大的方便。

iii. 这个方案的优点是，不需要进程注入，所以实现起来相对简单。同时能够将3G网络和Wifi网络分别禁用，用户体验将更加好。此外由于iptables的功能远不止这些，基于iptables可以实现功能更加强大的防火墙。Iptable虽然好，但是也是有缺点的，运行iptables需要root权限。基于iptables的Android防火墙目前有许多，这里有一个开源的项目http://code.google.com/p/droidwall/

有兴趣的朋友，可以研究一下。目前主流安全软件的联网拦截功能，如360手机卫士，手机毒霸等都是使用这一方案。

3. 总结

以上主要介绍了通过三个层面来控制一个应用的上网。具体使用哪一种，需要看用户的需求，以及手机的系统环境而定。

a) 如果不能获得root权限，基本思路就是定制修改apk，可以考虑加入hook代码，或者是压根在AndroidManifest.xml里将android.permission.INTERNET权限去除。

b) 如果能获得root权限，可以考虑注入zygote，使之fork()之后不加入inet组，还可以注入应用进程加上敏感函数的hook。此外还可以使用iptables命令。

c) 如果用户希望不杀死进程就实现上网权限的开关，并且要求可以分别禁用3G网络和Wifi网络的话，那么非iptables不可了。

其实比较下来，还是基于iptables的方案相对较好。它似乎只有一个缺点就是需要root权限。但大家又知道一旦手机被root以后，安全性反而将大大降低。我们可否找到一种手机既不被root，又能使用iptables的方案呢？

其实是有的。只是这无法通过第三方的应用实现。必须有手机厂商对Android系统进行定制化修改，添加一个具有root权限的service来负责iptables命令的操作。其他进程只有向这个service提出请求，才能间接调用iptables。当然app应用要和这个service沟通，必须遵循一定的协议和获得相应的授权才行，否则又会变的不安全了。

我们 @安卓安全小分队 已经实现了上述方案，并且效果还不错。我们在init.rc里添加了一个service，并且授予这个service root权限。这个service起来之后，会等待client端请求。对于这个client端，我们对外提供了一套SDK，应用程序只需调用这套SDK API就可以和这个root service进行通信了，然后就可以间接执行iptables命令。

以下是我们的SDK API接口。Uid指应用的uid。type是针对的网络类型，可以是3G网络或者是Wifi网络。Blocked表示禁用还是启用网络。

public static final int MOBILE_NETWORK = 1;

public static final int WIFI_NETWORK = 2;

public void setApplicationPolicy(int uid, int type, boolean blocked); //设置拦截状态

public boolean getApplicationPolicy(int uid, int type); //获得当前的拦截状态

手机毒霸去广告功能分析一：总体分析

不久前金山公司推出了手机毒霸，并声称手机毒霸具有了清除广告的功能，顿时在业内掀起轩然大波。国内众多靠广告生存的移动开发者们对金山的这一功能进行强烈的谴责，但另一方面，大多数用户都觉得这个功能挺不错的，毕竟国内市场上的应用里的广告真的实在太多了。

当然口水战不是本文关注的重点，只是对手机毒霸的去广告功能产生的极大的兴趣。这东西到底是怎么实现的呢？在好奇心的驱使下，@安卓安全小分队通过一些技术手段分析了一下手机毒霸（v1.6.0）去广告功能的实现原理，在此与大家一起分享。如有错误的地方，敬请不吝赐教！

1. 手机毒霸去广告功能简介

如图所示，当用户打开某款带有广告的应用后，广告在屏幕底部显示了出来，而此时在屏幕的左下角，出现的手机毒霸的一个小窗口。当用户点击这个小窗口里的叉叉，广告就会被去除。

那这个毒霸的小窗口是手机毒霸放出来的一个悬浮窗口吗？是与不是，只需要看一下当前屏幕上View的层级关系即可。请出SDK自带工具 hierarchyviewer后，可以发现这个小窗口不是悬浮的，它就是在广告应用的界面之中。到这里读者应该也猜到了，广告应用被手机毒霸注入了。这也是手机毒霸需要申请root权限才能去广告的原因。

2. 手机毒霸把什么注进了广告应用

进程注入的通常做法是使用ptrace()来使目标进程加载一个预先准备好的.so，然后执行.so里的函数。那广告应用被注入时，加载了哪个.so呢？其实通过访问/proc节点就可以知道了。运行adb shell su 0 cat /proc/xxx/maps（其中xxx是广告应用的pid）。

51914000-51915000 r--s 00014000 b3:14 97609 /data/data/com.ijinshan.duba/app_jar/ksremote.jar

5b31f000-5b32c000 rwxp 00000000 b3:14 97610 /data/data/com.ijinshan.duba/app_ctrl/libksrootclient.so

5b353000-5b369000 r--p 00000000 b3:14 97612 /data/data/com.ijinshan.duba/app_jar/ksremote.dex

5b369000-5b36b000 r--p 00016000 b3:14 97612 /data/data/com.ijinshan.duba/app_jar/ksremote.dex

5b36b000-5b388000 r--p 00018000 b3:14 97612 /data/data/com.ijinshan.duba/app_jar/ksremote.dex

可以看到广告应用被注入后，加载了3个文件： ksremote.jar

ksremote.dex 和libksrootclient.so。

其中ksremote.jar 包含了两个文件：ksremote.dex 和 adclose.png。这个adclose.png就是刚才提到的关闭广告的小窗口图标了。

顺便提一下，手机毒霸不仅注入普通应用进程，同时也注入了zygote，system_server以及com.android.systemui三个系统进程，但注入之后所做的事情跟注入普通应用进程是不一样的。

3. 注入后做了些什么

想要实现Java层的注入，通常的做法是首先注入.so，然后通过.so加载.jar/.dex文件。libksrootclient.so 很显然担起了这个重任，并且跳到ksremote.dex中KsRemoteCtrl类的SetAppHook()中去执行。在SetAppHook()里主要做了一下几件事情。

a) 加载图片资源：adclose.png

b) 反射得到ActivityThread类的currentActivityThread()获得当前ActivityThread对象

c) 加载/data/data/com.ijinshan.duba/app_ctrl/libksrootclient.so，并调用native方法StartSocketHook()。这里是在Native层对网络操作函数加Hook。

d) 反射获得当前ActivityThread对象的mInitialApplication成员（Application 类型），从而获得当前包名（Context.getPackageName()）

e) 如果发现自己不是"com.ijinshan.duba"，就开始更新广告规则

f) 替换当前ActivityThread中的mH(Handler类型)的mCallback，用金山自定义的一个callback对象来包裹过原callback并且替换原callback，从而起到hook作用。

拦截的消息有：RESUME_ACTIVITY，PAUSE_ACTIVITY，RECEIVER，ACTIVITYBIND_APPLICATION

在广告应用中某个Activity的onResume()触发前，注入的代码会先遍历当前Activity里的所有View，一旦找到广告View，就会调用addView()将添加到广告View的附近。

同样在Activity的onPause()触发前，会做一些清理工作。

4. 广告是怎么“去除”的

当用户点击时，注入的代码主要做了如下几件事情：

a) 将目标广告view设成View.GONE，从而隐藏。

b) 将设成View.GONE。

总的来说，手机毒霸的去广告的功能的用户体验还是不错的。无需修改应用就能去除应用中的广告。而且目前市场上还未曾出现过第二款能去嵌入式广告的安全软件。

但同时手机毒霸也存在着一些不足和可以改进的空间：

1）需要root，毕竟并不是所有的用户都会root自己的手机，而且root以后手机的风险将更大。

2）仅能去除部分类型的广告。有些广告手机毒霸目前还检测不出来，都没能显示。

3）去除的广告有可能复发。因为有些广告插件会反复将广告View设成VISIBLE，而手机毒霸只是去除第一次的显示。

4）手机毒霸的去广告功能其实只是一个UI操作，广告SDK如果还在后台继续下载广告内容的话，依然会占用流量，也会占用一定的CPU。

另外，补充一点，手机毒霸的开发人员还真是大大滴狡猾，把好几个重要的.so和.jar文件都隐藏成了.mp3文件，然后打包进了apk。不过还是被我们发现了。

手机毒霸去广告功能分析三：java代码（dex）注入

(

首先简单介绍一下进程注入的概念：进程注入就是将一段代码拷贝到目标进程，然后让目标进程执行这段代码的技术。由于这样的代码构造起来比较复杂，所以实际情况下，只将很少的代码注入到目标进程，而将真正做事的代码放到一个共享库中，即.so文件。被注入的那段代码只负责加载这个.so，并执行里面的函数。

由于.so中的函数是在目标进程中执行的，所以在.so中的函数可以修改目标进程空间的任何内存，当然也可以加钩子，从而达到改变目标进程工作机制的目的。

当然不是任何进程都有权限执行注入操作的。Android平台上的进程注入是基于ptrace()的，要调用ptrace()需要有root权限。目前市面上的主流安全软件也都是基于进程注入来管理和控制其他应用进程的。这也就是为什么这些安全软件需要获得root权限的原因。

关于如何.so注入的实现，有兴趣的朋友可以参考看雪论坛的上的一个注入库LibInject

和洗大师的一个开源项目Android Injector Library。

.so注入以后已经可以干很多事情了，但毕竟是在native层。想要在native层直接修改Java层的变量和逻辑还是很不方便的。况且Android平台的绝大多数应用都是用Java代码写的。因此自然而然就会想到，有没有什么方式可以将dex文件注入目标进程，然后执行dex文件中的Java代码？

经过一段时间的研究，笔者找到了一个切实可行的方法。这里分享给大家：首先，所有的Java类都是由类加载器(ClassLoader)加载的，我们要从特定的路径下加载一个我们自己的dex文件，就必须要有一个自己类加载器才行。有了这个类加载器我们就可以加载我们自己的类，并用反射调用这个类里面的方法。其次，要构造生成这样一个类加载器必须要获得现有的类加载器，因为类加载器是双亲委派模式的。现有的类加载器可以通过反射获得。只是这些都需要用native代码实现。

下面简述一下dex注入的过程：

1. 将.so注入目标进程，执行.so文件中的某个函数。

2. 在这个函数里先获得一个JNIEnv指针，通过这个指针就可以调JNI函数了。

3. 反射得到当前应用进程的PathClassLoader，用这个ClassLoader来构造一个DexClassLoader对象。Dex文件路径作为一个参数传入DexClassLoader的构造函数，另一个重要的参数是，一个具有可写权限的文件夹路径。因为在做dex优化时，需要生成优化过的dex文件，这跟生成/data/dalvik-cache/下的dex文件是一个道理。

4. 通过这个DexClassLoader对象，来加载目标类，然后反射目标类中的目标函数。最终调用之。

//功能：调用dexPath文件中的className类的methodName方法。
//dexPath: dex/jar/apk 文件路径
//dexOptDir: 优化目录, 这个目录的owner必须是要被注入进程的user，否则dex优化会失败
//className: 目标类名，如“com.hook.Test”
//methodName: 目标方法名，如"main", 在Java代码里必须定义为public static void main(String[] args);
//argc，传给目标方法的参数个数
//argv，传给目标方法的参数
int invoke_dex_method(const char* dexPath, const char* dexOptDir, const char* className, const char* methodName, int argc, char *argv[]) {
    ALOGD("Invoke dex E");
    JNIEnv* env = android::AndroidRuntime::getJNIEnv();
    jclass stringClass, classLoaderClass, dexClassLoaderClass, targetClass;
    jmethodID getSystemClassLoaderMethod, dexClassLoaderContructor, loadClassMethod, targetMethod;
    jobject systemClassLoaderObject, dexClassLoaderObject;
    jstring dexPathString, dexOptDirString, classNameString, tmpString;
    jobjectArray stringArray;

    /* Get SystemClasLoader */
    stringClass = env->FindClass("java/lang/String");
    classLoaderClass = env->FindClass("java/lang/ClassLoader");
    dexClassLoaderClass = env->FindClass("dalvik/system/DexClassLoader");
    getSystemClassLoaderMethod = env->GetStaticMethodID(classLoaderClass, "getSystemClassLoader", "()Ljava/lang/ClassLoader;");
    systemClassLoaderObject = env->CallStaticObjectMethod(classLoaderClass, getSystemClassLoaderMethod);

    /* Create DexClassLoader */
    dexClassLoaderContructor = env->GetMethodID(dexClassLoaderClass, "<init>", "(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/ClassLoader;)V");
    dexPathString = env->NewStringUTF(dexPath);
    dexOptDirString = env->NewStringUTF(dexOptDir);
    dexClassLoaderObject = env->NewObject(dexClassLoaderClass, dexClassLoaderContructor, dexPathString, dexOptDirString, NULL, systemClassLoaderObject);

    /* Use DexClassLoader to load target class */
    loadClassMethod = env->GetMethodID(dexClassLoaderClass, "loadClass", "(Ljava/lang/String;)Ljava/lang/Class;");
    classNameString = env->NewStringUTF(className);
    targetClass = (jclass)env->CallObjectMethod(dexClassLoaderObject, loadClassMethod, classNameString);
    if (!targetClass) {
        ALOGE("Failed to load target class %s", className);
        return -1;
    }

    /* Invoke target method */
    targetMethod = env->GetStaticMethodID(targetClass, methodName, "([Ljava/lang/String;)V");
    if (!targetMethod) {
        ALOGE("Failed to load target method %s", methodName);
        return -1;
    }
    stringArray = env->NewObjectArray(argc, stringClass, NULL);
    for (int i = 0; i < argc; i++) {
        tmpString = env->NewStringUTF(argv[i]);
        env->SetObjectArrayElement(stringArray, i, tmpString);
    }
    env->CallStaticVoidMethod(targetClass, targetMethod, stringArray);
    ALOGD("Invoke dex X");
    return 0;

}

参考网址：http://blog.csdn.net/grace_0642/article/details/8784347

转载于:https://my.oschina.net/zhuzihasablog/blog/115651