学徒浅析Android开发——SO文件的混淆

 

.so（SharedObject）作用等同于windows环境下的.dll（dynamic link library）文件，我们在引用第三方SDK时，也会遇到需要调用相应的.so文件的情况，.so文件本事更多的是集成公共处理方法，当然有事也会用来保存重要的数据信息。

对于应用的编译与反编译过程中，本地混淆一直是有效的方法。对于.so文件，同样也适用于混淆，.so文件虽然在使用破解工具IDA打开后看到的是汇编数据，但仍然存在着规律可循，不妨碍专业人员的阅读，所以掌握对.so文件的混淆也是必须的。

.so文件的混淆是从两方面入手：

1：方法名混淆

2：数据混淆

方法名混淆

我们在创建构建.so文件所需的.c和.h文件时，NDK会帮助我们自动生成native方法名，这个方法名是格式化，该方法名同时也是索引表中的索引名。因其特殊性，在IDA浏览时，可以通过索引表快速查看到。比如我们创建一个TestSimple，在里面声明一个native方法showDsc()，最终得到的方法名是：
      Java_com_example_xx_TestSimple_showDsc

生成的.so文件在经过IDA反编译后，可以在函数索引表中清楚的看到：

好在NDK提供了修改的方法，帮助我们隐藏掉这种显眼的名字。首先说一下两个基础方法：
1、简化方法名，该方法如下：

   继续以TestSimple为例，声明

#defineJNIFUNCTION_NATIVE(sig)  Java_com_example_xx_TestSimple_##sig

   将函数名前边的路径剔除掉，只显示函数名，避免显得直接。

  

 JNIEXPORT void JNICALL JNIFUCTION_NATIVE (showMath(JNIEnv *env, jobject obj));

   该方法只能用来简化方法名，在编辑时有用，但是在破解中，对隐藏没有作用，修改后，在IDA中依然可以查看到：

 

2、替换section索引名，该方法如下：

__attribute__((section(".XXXX")))

其中XXXX表示自定义的索引名，需要在指定的函数名前 声明该方法， 例如：

__attribute__((section (".xxxsimple")))  JNICALL jstring show(JNIEnv *env, jclass obj){
         return realShow(env,obj);
}

实际效果图如下：

 

该方法通过改变属性类型，影响破解后相关代码段解析顺序，

 

NDK的方法名混淆就是将1和2 两种方法通过配合RegisterNatives()注册的方式混合使用，RegisterNatives()可以实现与类关联的本地方法，这步操作必须在调用之前完成，也就是库加载过程中。一般是用JNI_Onload这个函数来完成。通过RegisterNatives()进行关联，将实际执行函数由声明的类函数转变成本地函数，达到隐藏的效果，调用步骤如下：

 

步骤一：

声明待替换的方法集合JNINativeMethod，是一个方法类型集合，

//指针操作，将java层的showDsc函数指向到Native层的show()函数上
static JNINativeMethodgetMethods[] = {
        {"showDsc","()Ljava/lang/String;",(void*)show},
};

其中JNINativeMethod的结构定义如下：

typedef struct{
   char *name;// 待指向函数名
   char *signature;// 待指向函数和形参类型
   void *fnPtr//函数指针，实际执行函数
}

 

声明待注册的类名

#define JNIREG_CLASS"com/example/xx/Test"

步骤二：

在实际执行函数前标记自定义属性名称

__attribute__((section(".xxxfirst"))) JNICALL jstring show(JNIEnv *env, jclass obj){
        return realShow(env,obj);
}

步骤三：

在实际执行函数完成操作。

jstringrealShow(JNIEnv *env, jclass obj){
     return (*env)-> NewStringUTF(env,“10086”);
}

步骤四：

执行RegisterNatives()，注册与指定类相关联的方法

static int registerNativeMethods(JNIEnv* env, const char* className,JNINativeMethod* gMethods, int numMethods)
{
    jclass clazz;
    clazz = (*env)->FindClass(env, className);
    if (clazz == NULL) {
        return JNI_FALSE;
    }
    if ((*env)->RegisterNatives(env, clazz, getMethods, numMethods) < 0) {
        return JNI_FALSE;
    }
    return JNI_TRUE;
}

步骤五：对指定的类进行指定方法名注册，注册成功则返回0，失败为1。

static intregisterNatives(JNIEnv* env)
{
if(!registerNativeMethods(env,JNIREG_CLASS,
getMethods, sizeof(getMethods) /sizeof(getMethods[0])))
{
           return JNI_FALSE;
}
    return JNI_TRUE;
}

 

步骤六：

在JNI_OnLoad中执行注册操作

JNIEXPORT jintJNI_OnLoad(JavaVM* vm, void* reserved)
{
    JNIEnv* env = NULL;
jint result = -1;
    if ((*vm)->GetEnv(vm,(void**) &env, JNI_VERSION_1_4) != JNI_OK) {//GetEnv()用以获得一个JNIEnv全局对象
        return -1;
    }
    assert(env != NULL);
    if (!registerNatives(env)) {
        return -1;
    }
    result = JNI_VERSION_1_4;
    return result;
}

构建成功之后，我们可以看到，在方法名索引表中找不到调用的函数名称。只有找到自定的section区域才能进行下一步解析。

 

数据混淆

通常情况下，在.so库中放置的是方法集合，但是如果存在文本内容时，就需要考虑数据混淆了，一旦使用声明常量的方式设置文本数据，这些数据在使用过程中会被基本类型完整保存，这些数据在通过破解后，会直白的出现在破解者面前。这种设置让汇编程序在进行地址指引时，指向的是一个数据源，而非指针地址时。如果我们对外提供文本数据时，对数据采取数组拼接的方式，指向数组获得的是一个指针地址，这样破解者看到的是地址标记而非直白的数据源。下面是两组对比。

直接以文本形式输出：

JNIEXPORT jstring JNICALLJava_com_example_xx_Test_showC
(JNIEnv *env, jobject obj){
      charsha[100];
              nstrcpy(sha,H, A, C, E, J, F, NULL);
      return(*env)-> NewStringUTF(env, sha);
}

使用数组组合的形式：

JNIEXPORT jstring JNICALLJava_com_example_xx_Test_showB
(JNIEnv *env, jobject obj){
          char str[15];
          str[0]= O[1];
          str[1]= N[4];
          str[2]= P[0];
          str[3]= N[2];
          str[4]= D[0];
          str[5]= Q[0];
          str[6]= Q[2];
          str[7]= O[1];
          str[8]= D[0];
          str[9]= P[3];
          str[10]= '\0';
      return(*env)-> NewStringUTF(env, str);
}

 

最后，说一下，其实没有破解不了的保护，只有破解不了的人心，不管安全软件机构如何宣传，碰到有心人士也是无解，我们做开发的，只是在增加破解难度而已。