.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);
- }
最后,说一下,其实没有破解不了的保护,只有破解不了的人心,不管安全软件机构如何宣传,碰到有心人士也是无解,我们做开发的,只是在增加破解难度而已。