### **概述** Android应用程序是运行在一个沙箱中。这个沙箱是基于Linux内核提供的用户ID（UID）和用户组ID（GID）来实现的。Android应用程序在安装的过程中，安装服务PackageManagerService会为它们分配一个唯一的UID和GID，以及根据应用程序所申请的权限，赋予其它的GID。有了这些UID和GID之后，应用程序就只能限访问特定的文件，一般就是只能访问自己创建的文件。此外，Android应用程序在调用敏感的API时，系统检查它在安装的时候会没有申请相应的权限。如果没有申请的话，那么访问也会被拒绝。对于有root权限的应用程序，则不受上述沙箱限制。此外，有root权限的应用程序，还可以通过Linux的ptrace注入到其它应用程序进程，以及系统进程，进行各种函数调用拦截。 本系列主要讲代码加壳、注入和拦截技术的，包括： 1. SO注入。也就是从一个进程向另外一个进程注入一个SO文件，通过该注入的SO文件就可以实现函数拦截功能。 2. SO加壳。加壳的目的自然就是加大别人对自己的C/C++代码进行静态逆向难度了，这个技术的关键是要实现一个能纯内存操作的Linker了。也就是说，解密后的SO文件内容是保存在一个内存缓冲区的，然后再针对该内存缓冲区进行解析和链接，最终形成一段可执行的代码。这个过程不会产生任何文件供别人做静态分析。 3. C/C++函数GOT拦截。通过修改SO的GOT项来实现函数拦截。这个技术的特点是简单和稳定，但是不足之处于它是针对函数的调用方进行拦截的，而不是针对函数本身的实现来进行拦截的。这样当我们想对某一个函数进行拦截的时候，就必须要检查进程内所有的模块，然后对调用了目标函数的模块的相关GOT 项进行修改。此外，如果某一个模块是通过动态SO加载技术（dlopen、dlsym）来调用目标函数的话，GOT拦截就失效了，因为动态SO加载技术不会产生GOT项。 4. C/C++函数INLINE拦截。这种方法是直接对目标函数的前面几条指令进行修改，用来实现拦截技术。INLINE拦截没有上述GOT拦截的缺点，但是它的实现会复杂很多。由于绝大部分Android设备都是基于ARM架构，因此这里只讨论ARM架构的C/C++函数INLINE拦截。ARMl架构主要分为ARM和THUMB两种指令集，也就是在Android设备上运行的C/C++函数分为ARM和THUMB两种类型。对于ARM指令集的函数，对它们进行拦截至少需要修改头8个字节；对于THUMB指令集，对它们进行拦截至少需要修改头12个字节。无论ARM指令还是THUMB指令函数，我们要修改的头8个字节或者12个字节都很容易碰到跳转或者PC相对寻址指令，这样就需要对指令进行重定位。这个重定位工作相当于繁重和麻烦，得实现一个ARM和THUMB指令解析库才行。不像X86的函数INLINE拦截，只需要函数的头5个字节即可，而且这5个字节几乎都是堆栈相关的操作，不会涉及到跳转或者PC相对寻址指令。 5. DEX注入。在SO注入的基础上，要对目标进程进行DEX注入是相当简单的，通过DexClassLoader即可实现。 6. DEX加壳。DEX加壳与SO加壳一样，都要求在解密之后，能够进行纯内存操作，中间不要产生任何和DEX或者ODEX文件，否则的话，就会给别提供静态分析的机会，这样就失去了加壳的目的。 7. Java函数拦截。与C/C++函数拦截相对，Java函数拦截要优雅得多，因为所有的Java函数都是通过虚拟机来执行的。Dalvik虚拟机执行的函数分为Java和Native两种，它们都是使用Method结构体来描述。当一个Method结构体描述的是一个Java函数时，它有一个成员变量就指向该Java函数的方法区。而当一个Method结构体描述的是一个Native函数，它有一个成员变量指向该Native函数的地址。因此，主要我们能将一个用来描述Java函数的Method结构体修改为一个指向Native函数的Method结构体，就可以骗过Dalvik虚拟机来执行我们所指定的Native函数，从而实现拦截。 以上7个技术点涵盖了Android安全的攻与防基础。在这些基础上不仅可以保护我们自己的代码，还可以对别人的代码进行攻击。 * Android安全模型 * SO注入技术 * SO加壳技术 * C/C++函数拦截技术 * DEX注入技术 * DEX加壳技术 * Java函数拦截技术 #### **Android安全模型**   **用户** * 系统中可以存在多个用户，每一个用户都具有一个UID * 用户按组划分形成用户组，每一个用户组都具有一个GID * 一个用户可以属于多个用户组 **文件** * 每一个文件都具有三种权限 Read、Write、Execute * 文件权限按用户属性分为三组 Owner、Group、Other  **进程** * UID -- setuid * GID -- setgid * Supplementary GIDS – setgroups * Capabilities -- capset  * 系统中的第一个进程Init的UID是root * 子进程的UID默认与父进程相同，但可以通过setuid进行修改 * 子进程被fork之后exec了一个设置了SUID位的bin文件，那么子进程的UID变为该bin文件的Ower UID   **每一个APK在安装的时候，PMS都会给它分配一个唯一的UID和GID** * 如果两个APK具有相同的签名，那么可以通过android:sharedUserId申请分配相同的UID和GID * 如果一个APK具有平台签名，那么可以通过android:sharedUserId=“android.uid.system”获得System UID > **备注** > 通过Master Key漏洞获得System UID > http://drops.wooyun.org/papers/219 > http://safe.baidu.com/2013-10/android-masterkey-9695860.html > http://safe.baidu.com/2013-11/masterkey-9950697.html > 打开文件/data/local.prop，设置以下属性： > `ro.kernel.qemu=1` > 即可使得adb具有root权限 **每一个APK都可以通过<uses-permission android:name=“android.permission.XXX”/>申请若干个Permission** * 有些Permission需要具有平台签名才可以申请，如INSTALL_PACKAGES **每一个Permission都对应于一个Supplementary GID，因此，给APK分配Permission即为APK分配Supplementary GID** http://developer.android.com/reference/android/Manifest.permission.html **APK进程是由UID为root的Zygote进程fork出来的，fork之后**：  http://man7.org/linux/man-pages/man2/capset.2.html **PMS记录有每一个APK所申请的Permission，当APK调用敏感API时，相应的模块就会通过PMS会验证调用APK是否申请有相应的Permission**  **突破沙箱**  * **突破沙箱：创建其它APK也能访问的文件**  * **突破沙箱：Binder IPC**  * **突破沙箱：Content Provider**  * **突破沙箱：黑客技术** * SO注入 - C/C++函数拦截 - DEX注入 - Java函数拦截 - …… #### **SO注入技术** **ptrace** ~~~ long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data); ~~~ http://man7.org/linux/man-pages/man2/ptrace.2.html  * Step 1: PTRACE_ATTACH到目标进程，并且让目标进程发生PTRACE_SYSCALL时停止 * Step 2: PTRACE_GETREGS保存目标进程的上下文 * Step 3: PTRACE_SETREGS改写目标进程的PC寄存器，使得它指向函数mmap的地址 * Step 4: PTRACE_CONT让目标进程恢复执行，这时候将会执行函数mmap * Step 5: PTRACE_GETREGS获得目标进程的R0寄存器值，即为函数mmap的返回值，指向在目标进程地址空间分配的一块内存 * Step 6: PTRACE_POKETEXT往在目标进程分配的地址写入以下一段SHELL CODE  * Step 7: PTRACE_SETREGS改写目标进程的PC寄存器，使得它指向上述SHELL CODE的起始地址_inject_start_s * Step 8: PTRACE_DETTACH目标进程，目标进程恢复执行后，就会执行注入的 * Step 9: 注入的SHELL CODE在目标进程加载一个SO，并且找到这个SO的指定入口函数，进行调用 #### **SO加壳技术** **系统中的SO文件由一个叫Linker的加载器负责加载，即调用dlopen函数进行加载**： ~~~ void *dlopen(const char *filename, int flag); ~~~ 如果能将第一个参数改为一个内存地址，就可以实现从内存加载SO的功能，进而可以对该内存进行加密处理 **dlopen**  **find_library**  **load_library**  **Read Elf32_Ehdr** Elf32_Ehdr header[1]; read(fd.fd, (void*)header, sizeof(header)) http://man7.org/linux/man-pages/man5/elf.5.html **ReadElf32_Phdr**  **Reserve Enough Memory**  **Load Segments**  **What data we need?** Elf32_Ehdr Elf32_Phdr Segments **How to fill above data? **  **struct elfinfo**  **Open file and create elfinfo**  **Read Elf32_Ehdr**  **Read Elf32_Phdr**  **Read segments**  #### **C/C++函数拦截技术** * Got Hook * VTable Hook * Inline Hook **Got Hook**  * **Step 1: Find the address of eglSwapBuffers** ~~~ void * handle = dlopen(“/system/lib/libEGL.so”, RTLD_NOW) void* addr = dlsym(handle, “eglSwapBuffers”); ~~~ * **Step 2: Find the .got section **  * **Step 3: Find the address of eglSwapBuffers in .got section**  * **Step 4: Replace it**  **VTable Hook**  * **Step 1: Find the address of Surface::unlockAndPost ** ~~~ void * handle = dlopen(“/system/lib/libgui.so”, RTLD_NOW) void* addr = dlsym(handle,“_ZN7android7Surface13unlockAndPostEv”); ~~~ * **Step 2: Find the .data.rel.ro section**  * **Step 3: Find the address of Surface::unlockAndPost in .data.rel.ro section ** 、 * **Step 4: Replace it**  **Inline Hook**  * **Problem** 移动的指令可能包含： **普通指令** * PC相对寻址指令 * 跳转指令 **对于PC相对寻址和跳转指令**： * 需要进行重定位 **因此，实现Inline Hook要求**： * 动态的指令解析 * 动态的指令重定位 #### **DEX注入技术**   #### **DEX加壳技术** * 通过DexClassLoader可以动态地加载DEX文件，但是它在加载DEX文件的过程会生成一个ODEX文件，给别人提供了静态逆向的可能 * 通过分析DexClassLoader的实现可以知道，它是通过DexFile来实现动态加载DEX文件的 * 进一步分析DexFile的实现，发现它提供了两个隐藏接口来实现加载内存DEX文件   * 但是，DexFile从Android 4.0开始才支持加载内存DEX文件，如何支持Android 4.0以下的版本呢？ * 通过分析DexFile加载内存DEX文件的实现可以发现，里面用到的关键函数都可以从libdex.a和libdvm.so获得 * 于是，可以模仿Android 4.0，实现DexFile加载内存DEX文件的功能 * 辅助数据结构和函数  * **Step 1: custome_load_class_from_memory**  * **Step 2: open_dex_from_memory**  * **Step 3: raw_dex_file_open_array**  * **Step 4: prepare_dex_in_memory**  * **Step 5: rewrite_dex **  * **Step 6: dex_file_open_partial**  * **Step 7: allocate_aux_structures**  * **Step 8: add_to_dex_file_table**  * 上述过程用到的关键函数均可从libdex.a和libdvm.so获得： * dexSwapAndVeriry * dexCreateClassLookup * dexFileParse * dvmAllocRegion * dvmAllocAtomicCache * dvmHashTableLock * dvmHashTableLookup * dvmHashTableUnlock #### **Java函数拦截技术** * 在Dalvik虚拟机中，无论是Java函数，还是Native函数，都是通过Method结构体来描述的  * Dalvik虚拟机通过dvmIsNativeMethod判断一个函数是Java函数还是Native函数  * Dalvik虚拟调用一个函数之前，首先判断它是Java函数还是Native函数  * Java函数拦截技术原理分析 * 对于Java函数，Davik虚拟机使用解释器来执行 * 对于Native函数， Davik虚拟机找到它的函数指针nativeFunc，进行直接调用 * 如果我们能把一个Java函数修改为Native函数，并且将nativeFunc指针设置为自定义的函数，那么就可以实现拦截了 * 拦截完成之后，根据情况决定是否需要调用原来的Java函数，即可完成整个拦截过程 * libdvm导出了两个函数dvmDecodeIndirectRef和dvmSlotToMethod，如果我们知道一个Java函数在它所属的Class里面的位置Slot，那么就可以通过它们获得该Java函数在Dalvik虚拟内部所对应的Method结构体：  * 得到一个Java函数在Dalvik虚拟内部所对应的Method结构体之后，就可以将它设置为Native函数：  **如何获得一个Java函数所属的Class，以及它在该Class的位置Slot呢？** **假设我们知道：** * Java函数的名称—methodName * Java函数的原型—prototype * Java函数的类名称—className * 用来加载该Java类的ClassLoader--classLoader **Step 1: 获得Class对象** ~~~ Class<?> clazz = classLoader.loadClass(className); ~~~ **Step 2: 获得Method对象** ~~~ Method method = clazz.getDeclaredMethod(methodName, prototype); ~~~ **Step 3: 获得clazz的Slot域描述** ~~~ Field field = clazz.getDeclaredField(“Slot”); ~~~ **Step 4: 获得method的slot** ~~~ int slot= field.getInt(method); ~~~ **Step 5: 将clazz和slot通过JNI传递到C/C++层，调用dvmDecodeIndirectRef和dvmSlotToMethod** ~~~ ClassObject* declared_classs = (ClassObject*) dvmDecodeIndirectRef(dvmThreadSelf(), clazz); Method* method = dvmSlotToMethod(declared_class, slot); ~~~