-
-
[原创]2022腾讯游戏安全竞赛安卓客户端决赛writeup
-
发表于: 2022-4-28 12:05
-
外挂进程先通过java层解密出sock001并运行，读取数据到/sdcard/1A.txt文件中，然后外挂进程native层不断读取/sdcard/1A.txt文件中的数据，同时调用java层的绘图函数，实现透视。
在查看外挂apk给的so，发现里面并没有远程读写的代码，怀疑是新起了一个进程，在assert文件夹下发现了可疑的以sock开头的几个文件
用010打开，发现所有文件都是被加密过的，看不出来是什么东西
开始在java层上找解密的地方，java层被混淆的很厉害，最终在MainActivity中找到了解密的地方
这里是对sock1进行解密，跟进去，是非常明显的rc4加密，密钥为gamesec
本地用python对sock1进行解密
解密后，再用010打开，发现是一个安卓上的elf可执行文件
同时这里java层采用shell命令，启动了进程，可以用ps -ef查看启动进程的参数
发现是2236 1080，这两个是我测试手机屏幕的高宽，后面会用到
从函数名都可以知道，外挂的native层主要是读取文件数据，然后调用java层绘图函数画图的，这里并不是重点。
用ida打开后发现区段只有两个，明显是被加壳了
怀疑是upx的壳，用010查看upx的特征，发现被改动了
upx的字符串都被替换成了ue4，同时和正常upx加壳的对比，还删掉了声明，尝试手动修复，修复不了，转而采用动态调试方式找到oep入口，因为有反调试，调试器无法attach，老是报奇怪的错，后面才知道是信号的问题，由于调试过程中，老是会跑飞到linker里面，所以萌生了在底层函数上下断的想法，最直接是在libc_init这个函数下断，然后第三个参数就是main函数。
先单步到这，linker位置，此时libc已加载，再跟到libc中下断
成功断下，r2寄存器里面此时是main函数的地址，在main函数下断，f9，此时是程序真正的入口了，发现里面混淆的非常严重
主要混淆有字符串加密以及控制流平坦化，这里想办法脱壳并且去掉混淆先，方便调试
这里通过010editor发现里面的upx字符串都被改成ue4,然后用upx -d直接不识别为upx，应该是本地被patch修改过了，尝试修复
将所有的出现的ue4！字符串改成upx！，算是最基本的特征了
搜索UE4，发现有四个，其中小写的不用改，将其他改为UPX
这里主要是对比了其他upx加壳后的文件，发现基本都是3个0x00结尾
的，所以这里要删除
从文件尾部继续找倒数第一个和倒数第二个UPX!,距离倒数第一个UPX!的20个字节处，为正确的p_info值，取出并填入距离第一个UPX!字符串8个字节的位置。
取出的值0x0004f9ec
填入的位置
再次用upx -d尝试发现已经能识别出upx了，但是还是报错了
这里通过查看upx源码https://github.com/upx/upx，以及调试upx官方可执行程序，发现在一处文件头的对比中，我的数据是4个0x00，所以报错了，upx源码，同样找到了这个逻辑
说明需要去填入.ELF, 填入位置参考了其他upx加壳文件，在距离第一个UPX!字符串的第28个字节开始填入
再用upx -d，发现还是报错了，但是报错信息更新了
通过搜索upx源码的字符串，找到这里关键对比逻辑
通过调试upx官方程序，发现这里blocksize一直为0，所以报错
在这里下断，找到了位置了，同时我自己在本地用upx加壳后的程序进行对比，找规律，发现p_info的那个值要和blocksize相同。
心情还是比较激动的，折腾挺久的了
可以看出是release版本的控制流平坦化，为了方便，这里用ida 插件https://github.com/obpo-project/obpo-plugin，来去掉混淆，主函数去除混淆前:
然后这里用这个插件来去掉，右键在函数主分发块上点击OBPO
点击mark and process function，再连续按两次f5，去除混淆成功
主函数去掉混淆后:
效果非常好，伪代码非常清晰
发现每个函数要用的字符串都被加密起来了，解密逻辑都在函数的开头.
而且执行过后，并没有再次加密，这里可以采用先让外挂正常运行一遍，然后dump下来，再把解密后的字符串patch到之前没有解密字符串的程序中。
在调试过程中，发现sock1将sock002、sock003、sock004、sock005都进行了密钥为TencentGameSecurity的rc4算法解密,并且发现sock001文件中间有空缺，
空缺的位置的似乎就是那几个文件，本地重新分析一个安卓可执行elf文件，对照的分析，得出结论sock002解密后对应的是program table，并在调试中确定了这点
解析sock002（progame table），然后将sock001的要加载的代码加载进内存，然后下一步是通过解密后的sock005进行重定位，解密后的sock005为.rel.plt section
sock003解密后，本地查看发现很明显是动态链接的字符串表
sock004dec 经过对比，发现是动态符号表，几个文件的代表意义都知道了，继续分析，相当于自实现了一个linker，再继续调试时发现pc值跳到了sock001、sock002、sock003、sock004、sock005加载到内存中的区间，说明sock1进程相当于执行了一段这几个文件的shellcode，最终进入了这个外挂的关键函数
这里为了证实这个函数是那几个文件中的，用010去搜机器码的十六进制
是可以搜的，同时内存地址，也是在几个文件加载进内存中的地址区间。
并设置pc值为此内存地址，触发异常，调试器会接受到此异常
如果没有调试器，则信号由先前设置的信号处理函数处理，跟进信号处理函数，会发现同样调用了momove函数，将之前的数据覆盖到断点指令上，程序回归正常。
核心函数位于sock001偏移的0x8490
跟进去分析一下是如何做转换的
发现是将pitch yaw roll，传入函数并转化为matrix矩阵，为了后续的计算。
同时在github上找到类似的三维转换二维的代码https://github.com/kp7742/PUBGPatcher/blob/27628b3ff53e0766e7084a82b293bb58ee6c426b/Daemon/jni/Server/StructsCommon.h
不过这里计算并没有fov，其他倒是差不多
远程读写的操作都集中在这个getprocessvalue函数（自命名)中
根据不同情况选择用syscall或者process_vm_readv来进行远程读写
第一次参与这个比赛，还是挺多收获的，感谢主办方和出题人了，也希望看wp的师傅们也能有所收获2333。
# coding=utf-8DEFAULT_KEY = ""
def rc4(data, key=DEFAULT_KEY, skip=1024):
x = 0
box = range(256)
x = 0
for i in range(256):
x = (x + box[i] + ord(key[i % len(key)])) % 256
tmp = box[i]
tmp2 = box[x]
box[i] = box[x]
box[x] = tmp
x = 0
y = 0
out = []
if skip > 0:
for i in range(skip):
x = (x + 1) % 256
y = (y + box[x]) % 256
box[x], box[y] = box[y], box[x]
for char in data:
x = (x + 1) % 256
y = (y + box[x]) % 256
box[x], box[y] = box[y], box[x]
k = box[(box[x] + box[y]) % 256]
out.append(chr(ord(char) ^ k))
return out
if __name__ == '__main__':
# handle input file or stream
import sys
tt = open("sock1", "rb")
ww = tt.read()
decrypt_files=rc4(ww, "gamesec", 0)
decttt=open("sock1dec","wb")
decttt.write("".join(decrypt_files))
# coding=utf-8DEFAULT_KEY = ""
def rc4(data, key=DEFAULT_KEY, skip=1024):
x = 0
box = range(256)
x = 0
for i in range(256):
x = (x + box[i] + ord(key[i % len(key)])) % 256
tmp = box[i]
tmp2 = box[x]
box[i] = box[x]
box[x] = tmp
x = 0
y = 0
out = []
if skip > 0:
for i in range(skip):
[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 感谢大佬肯定
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
