首先反编译apk,观察整个程序框架
找到MainActivity的内部类的run
可以看到,连接的时候关键在于upload
这个函数,其他都只是前端界面操作
于是找它,发现是native函数
private native int upload(String arg1) {
}
- 1
- 2
- 3
导入库是
static {
System.loadLibrary("net");
}
- 1
- 2
- 3
- 4
解压apk得到libnet.so
,拖入IDA进行反编译
发现一个提示
很关键,说明so文件的节区很可能被破坏了
反编译结果:

没有任何有用的东西,显然是加壳了
结合刚才的提示,搜索发现可能是section加密
技术
它将加解密都放在.init_array段,这个最早执行的段中来初始化代码
不过无论加解密有多复杂,为了使Java层能够正常调用upload函数,都一定会出现这个字符串和函数,那么只需要动态调试就可以找到它啦
连接机器,下断,调试开始~
F9让程序跑起来以后
在Modules中搜索libnet即可找到需要的模块:
双击发现JNI_OnLoad
此时由于已经在运行中了,相关节区都已经是解密状态了
(然而dump下来并无法正确分析,猜测是ELF头被毁了)
于是只好在调试状态下进行分析咯:
一个FindClass,一个RegisterNatives,显然是动态注册的Native函数
查看该函数的说明
jint RegisterNatives(jclass clazz, const JNINativeMethod* methods,
jint nMethods)
- 1
- 2
- 3
正好对应,stru_5DF9911C就是JNINativeMetod结构体了
PS:刚开始IDA给我把它识别成一个函数sub_5DF9911C了,跳过去发现开头几个字符并不是常见汇编,于是undefine以后再导入结构体才正确识别
typedef struct {
const char* name;
const char* signature;
void* fnPtr;
} JNINativeMethod;
- 1
- 2
- 3
- 4
- 5
- 6
按照结构体可以发现,函数名为Upload,类型为(LjavaLangString;)I, 地址为sub_5E08230C+1
终于找到Natvie_Upload啦~快去分析吧
往下翻动过程中发现这里比较可疑
这种简单的异或加密大概率是字符串的处理
写一个简单的IDC将它们处理出来,得到几个字符串:
socket
hacker@China
pwn#Phone
connect
send
close
很明显,除了第2、3个以外都是API,应该是通过loadlibrary来导入函数,而第2、3个就是connect的参数–用户名和密码了
Flag:
天天向上
学习
去年比赛遇见了这个,什么都不会
测试是否可见