复现主参考： https://oacia.dev/360-jiagu/
so 加固原理： https://www.cnblogs.com/theseventhson/p/16366038.html
包名： com.oacia.apk_protect
找到 application，java 层有字符串混淆，就是一个异或
大概的逻辑就是对应不同的架构 load 不同的 so
第一步：找到 load 的是什么 so
function my_hook_dlopen(soName = '') {
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
if (path.indexOf(soName) >= 0) {
this.is_can_hook = true;
}
}
},
onLeave: function (retval) {
if (this.is_can_hook) {
// dump_so("libjiagu_64.so");
}
}
}
);
}是 libjiagu_64.so，之后在内存中 dump 下来
var dump_once = false;
function dump_so(so_name) {
if (dump_once) {
return;
}
dump_once = true;
var libso = Process.getModuleByName(so_name);
console.log("[name]:", libso.name);
console.log("[base]:", libso.base);
console.log("[size]:", ptr(libso.size));
console.log("[path]:", libso.path);
var file = new File("/data/data/com.oacia.apk_protect/" + so_name + '_' + libso.base + '_' + libso.size + ".so", "wb");
if (!file) {
console.log("open file error");
return
}
Memory.protect(libso.base, libso.size, 'rwx');
file.write(libso.base.readByteArray(libso.size));
file.flush();
file.close();
console.log("dump so success to /data/data/com.oacia.apk_protect/" + libso.name + '_' + libso.base + '_' + libso.size + ".so");
}壳 ELF
用 sofixer 修复内存偏移 sofixer原理
- 这里 dump 的时机是 dlopen 结束之后
- so 后面还有一大堆空的地方，并没有完全解密
- frida 退出的时机是运行在 so 里面某个位置检测到异常退出了
所以现在的思路是看看到哪一步爆炸了，或者找到某个地方获取完整的 so 出来看看逻辑
- hook 所有可能的系统调用，查看逻辑或者反调试可能性
- 或者 frida 跟进，看调用栈情况
大致思路理解
oacia 的大致思路是这样的：
- hook open 函数，发现是 maps 检测，可以重定向到一个不存在的文件
- 发现 open 了 dex，但是中途退出了
- 所以尝试找到什么时候 open dex，可以发现是在附近一起被加载到，但是这附近的位置一开始 dump 出来的没有东西，需要查看这里的逻辑
- 所以这里的逻辑是后来才有的，我们需要向后调整 dump 的时机
- 通过查找 dlopen 找到自定义 linker 的逻辑位置，在 program header 出来的时候 dump，然后就能够借助 program header 的内容修复 so 了
- 修复 ELF 逻辑再往上分析可以发现是 RC4，之后解压缩
- 提取对应逻辑，可以完美外部获得主 ELF
- 找到解密 dex 对应逻辑位置，再通过 Stalker 跟踪下去（把两个文件合并了）
- 猜到是 ptrace 调用，hook 掉 create，发现是 ffi 库，把检测的敏感字符串替换掉
- frida 跟进到一堆加密字符串的地方，解密后发现就是加载 dex 的位置，hook 参数，就可以 dump 下来主 dex 了
- 跟进读取位置，研究 dex 是怎么解密的。多次尝试参数查看，发现真正传入未解密 dex 的位置
- 打印调用栈，发现互斥锁，可以发现是多线程处理，hook 不同 pid 发生位置上，再打印调用栈
- 往下找，找到加密逻辑。通过内存搜索（已经解密过的 dex）找到变动位置。同时通过 mmap 返回值位置（未来分配 dex 空间）找到解密的内存位置。动静态分析可以理解到解密算法
实操
- 首先是最快得到完整的主 so，dump 的点位是 open dex 前
- stackplz 怎么 dump 东西出来，问一下？
应该可以通过触发信号和 dd 命令实现？
./stackplz -n com.oacia.apk_protect -l libjiagu_64.so -w open[str,int]
发现是会报错，因为会找不到 string table section ，因为这个 so 文件是文件格式加密的。所以还是要用 frida 吧（这个太不灵活了，虽然检测不出来，但不是很好用），后面用来辅助用吧（但我都用 frida 了，都被检测完了还怕啥呢，光脚的不怕穿鞋的）
hook dlopen - dump shell elf
function hook_dlopen(soName = '') {
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
if (path.indexOf(soName) >= 0) {
this.is_can_hook = true;
}
}
},
onLeave: function (retval) {
if (this.is_can_hook) {
dump_so("libjiagu_64.so");
}
}
}
);
}
function dump_so(so_name){
var libso = Process.getModuleByName(so_name);
console.log("[name]:", libso.name);
console.log("[base]:", libso.base);
console.log("[size]:", ptr(libso.size));
console.log("[path]:", libso.path);
var file_path = "/data/data/com.oacia.apk_protect/" + libso.name + "_" + libso.base + "_" + ptr(libso.size) + ".so";
var file_handle = new File(file_path, "wb");
if (file_handle && file_handle != null) {
Memory.protect(ptr(libso.base), libso.size, 'rwx');
var libso_buffer = ptr(libso.base).readByteArray(libso.size);
file_handle.write(libso_buffer);
file_handle.flush();
file_handle.close();
console.log("[dump]:", file_path);
}
}
setImmediate(hook_dlopen).venv➜ 360 frida -H 127.0.0.1:1234 -f "com.oacia.apk_protect" -l dump_shell_so.js
____
/ _ | Frida 16.6.6 - A world-class dynamic instrumentation toolkit
| (_| |
> _ | Commands:
/_/ |_| help -> Displays the help system
. . . . object? -> Display information about 'object'
. . . . exit/quit -> Exit
. . . .
. . . . More info at https://frida.re/docs/home/
. . . .
. . . . Connected to 127.0.0.1:1234 (id=socket@127.0.0.1:1234)
Spawned `com.oacia.apk_protect`. Resuming main thread!
[Remote::com.oacia.apk_protect ]-> Error: unable to find module 'libjiagu_64.so'
at value (frida/runtime/core.js:381)
at dump_so (/Users/cyril/Dev/CTF/android/360/dump_shell_so.js:23)
at onLeave (/Users/cyril/Dev/CTF/android/360/dump_shell_so.js:15)
Error: unable to find module 'libjiagu_64.so'
at value (frida/runtime/core.js:381)
at dump_so (/Users/cyril/Dev/CTF/android/360/dump_shell_so.js:23)
at onLeave (/Users/cyril/Dev/CTF/android/360/dump_shell_so.js:15)
[name]: libjiagu_64.so
[base]: 0x7a980ff000
[size]: 0x274000
[path]: /data/data/com.oacia.apk_protect/.jiagu/libjiagu_64.so
[dump]: /data/data/com.oacia.apk_protect/libjiagu_64.so_0x7a980ff000_0x274000.so
Process terminated修复 so，打开
hook open - dump main elf
function dump_so(so_name) {
var libso = Process.getModuleByName(so_name);
console.log("[name]:", libso.name);
console.log("[base]:", libso.base);
console.log("[size]:", ptr(libso.size));
console.log("[path]:", libso.path);
var file_path = "/data/data/com.oacia.apk_protect/" + libso.name + "_" + libso.base + "_" + ptr(libso.size) + ".so";
var file_handle = new File(file_path, "wb");
if (file_handle && file_handle != null) {
Memory.protect(ptr(libso.base), libso.size, 'rwx');
var libso_buffer = ptr(libso.base).readByteArray(libso.size);
file_handle.write(libso_buffer);
file_handle.flush();
file_handle.close();
console.log("[dump]:", file_path);
}
}
var first_dump_main_so = true;
function hook_open() {
console.log("attaching open...")
Interceptor.attach(Module.findExportByName(null, "open"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
console.log("open " + path);
if (path.indexOf("maps") >= 0) {
console.log("find maps");
// redirect to noexits file
this.new_path = Memory.allocUtf8String("/proc/self/noexits");
args[0] = this.new_path;
}
if (path.indexOf(".dex") >= 0) {
console.log("find dex");
// log traceback
// console.log(Thread.backtrace(this.context, Backtracer.FUZZY).map(addr_in_so).join("\n") + "\n");
// dump so
if (first_dump_main_so) { dump_so("libjiagu_64.so"); first_dump_main_so = false; }
}
}
},
onLeave: function (ret) {
var fd = this.context.x0.toInt32();
var buffer = Memory.alloc(0x10000);
var bytesRead = new NativeFunction(Module.findExportByName(null, "read"), 'int', ['int', 'pointer', 'int'])(fd, buffer, 0x10000);
if (bytesRead > 0) {
console.log(buffer.readCString());
} else {
console.log("<empty file>");
}
}
}
);
}
setImmediate(hook_open)分割 so，修复，打开
.venv➜ 360 adb shell
emu64a:/ $ su
emu64a:/ # mv /data/data/com.oacia.apk_protect/libjiagu_64.so_0x7a93f6a000_0x274000.so /data/local/tmp/
emu64a:/ # cd /data/local/tmp
emu64a:/data/local/tmp # chmod 777 libjiagu_64.so_0x7a93f6a000_0x274000.so
emu64a:/data/local/tmp # ^D
emu64a:/ $ ^D
.venv➜ 360 adb pull /data/local/tmp/libjiagu_64.so_0x7a93f6a000_0x274000.so
/data/local/tmp/libjiagu_64.so_0x7a93f6a000_0x274000.so: 1...le pulled, 0 skipped. 167.7 MB/s (2572288 bytes in 0.015s)
.venv➜ 360 binwalk -aM ./libjiagu_64.so_0x7a93f6a000_0x274000.so
/Users/cyril/Dev/CTF/android/360/libjiagu_64.so_0x7a93f6a000_0x274000.so
------------------------------------------------------------------------------------------------------------------------
DECIMAL HEXADECIMAL DESCRIPTION
------------------------------------------------------------------------------------------------------------------------
0 0x0 ELF binary, 64-bit shared object, ARM 64-bit for
System-V (Unix), little endian
946176 0xE7000 ELF binary, 64-bit shared object, ARM 64-bit for
System-V (Unix), little endian
2530312 0x269C08 Zlib compressed file, total size: 11 bytes
------------------------------------------------------------------------------------------------------------------------
Analyzed 1 file for 85 file signatures (196 magic patterns) in 23.0 milliseconds
.venv➜ 360 dd if=./new_so_fixed of=dump_so skip=946176 bs=1program header 损坏了，还是要找到某个修复点给它填进去，这里选择的是 shell elf 的 0x5E6C 偏移位置，因为这里就是 prelink 阶段，用到的就是 program header。0x04918 是 link 的入口位置，用到的参数是魔改的 soinfo，前面有额外的 uint8_t gap[232]; 用来放提前调用的函数之类的信息
放钩子的时机是 dlopen 后
function hook_get_phdr_dump_so() {
var lib = Module.findBaseAddress("libjiagu_64.so")
if (!lib) {
console.log("[x] cannot find lib");
}
Interceptor.attach(lib.add(0x5E6C), {
onEnter: function (args) {
console.log("starting dump main elf program header:")
const target_ptr = ptr(args[0]);
console.log(hexdump(target_ptr, {
offset: 0,
length: 0x38 * 6,
header: true,
ansi: false
}))
}
});
}
function hook_dlopen(soName = '') {
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
if (path.indexOf(soName) >= 0) {
this.is_can_hook = true;
}
}
},
onLeave: function (retval) {
if (this.is_can_hook) {
hook_get_phdr_dump_so()
}
}
}
);
}
setImmediate(hook_dlopen)用 010 填充回去，修复，打开。发现外部符号好像都没有的样子，看来还得研究具体是怎么解密的
画外音：这里的时机还是太早了，如果再往后一点，就可以把填充完四个部分的东西完整 dump 下来了罢
decrypt main elf
向上找调用链，用 stalker，找到 RC4（0x5F20）密钥初始化部分 RC4加密
hook arg0 查看密钥 arg1 是长度
向后查看 RC4 加密主体，hook 查看加密内容和长度
再向后跟踪调用链，hook 解压函数
sub_62A0 → … → uncompress
这里复现的时候有个小插曲，还是写出来吧。在使用 stalker 的时候发现 hook open 的话可能会导致 stalker 崩溃，因为 stalker 也可能要使用 maps。
如果取消 hook open，打印堆栈，能够发现在 0x12500 （sub_11220）里死循环，在这个函数里能够发现多线程函数，所以这里用的是多线程反调试，过这个反调试之后再说，现在是知道这里有这个情况就行了
int uncompress(Bytef *dest, uLongf *destLen, const Bytef *source, uLong sourceLen);
uncompress 函数将 source 缓冲区的内容解压缩到 dest 缓冲区。sourceLen 是 source 缓冲区的大小 (以字节计)。注意函数的第二个参数 destLen 是传址调用。当调用函数时，destLen 表示 dest 缓冲区的大小， dest 缓冲区要足以容下解压后的数据。在进行解压缩时，需要提前知道被压缩的数据解压出来会有多大。这就要求在进行压缩之前，保存原始数据的大小 (也就是解压后的数据的大小)。这不是 zlib 函数库的功能，需要我们做额外的工作。当函数退出后， destLen 是解压出来的数据的实际大小。
最终得到 dump 出来的数据：
RC4 key init
vUV4#�#SVt
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
b400007cc43d8a90 76 55 56 34 23 91 23 53 56 74 00 00 00 00 00 00 vUV4#.#SVt......
len: 0xa
call63:sub_6044
RC4 decrypt
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
b400007a99832ff0 01 18 25 e7 2f d7 6f a2 70 e5 d5 ac db 4e d3 09 ..%./.o.p....N..
b400007a99833000 bd ec c6 5e d5 1f ea ce 78 21 c2 4c 50 a9 38 d6 ...^....x!.LP.8.
b400007a99833010 9d ca 52 f7 50 6d 91 e1 38 a3 96 50 33 43 b3 6a ..R.Pm..8..P3C.j
b400007a99833020 ff 0b 81 f1 63 3f 8d da b3 94 2b 06 60 79 62 eb ....c?....+.`yb.
len: 0xb8010
RC4 decrypt result:
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
b400007a99832ff0 b9 0e 1a 00 78 9c 7c dd 0f f8 db 6f 5d df 7b 35 ....x.|....o].{5
b400007a99833000 6a c1 b8 55 97 49 d5 e8 2a 44 a8 1a a4 3f 89 5a j..U.I..*D...?.Z
b400007a99833010 35 d3 6e cb b6 6e 66 5b f5 c4 73 ea 96 b9 ce 45 5.n..nf[..s....E
b400007a99833020 d7 b9 6c 76 3b 39 5b 9d d9 b5 0a 01 8b 06 2c 18 ..lv;9[.......,.
call64:sub_3574
call65:uncompress
hook uncompress
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
b400007a99832ff4 78 9c 7c dd 0f f8 db 6f 5d df 7b 35 6a c1 b8 55 x.|....o].{5j..U
b400007a99833004 97 49 d5 e8 2a 44 a8 1a a4 3f 89 5a 35 d3 6e cb .I..*D...?.Z5.n.
b400007a99833014 b6 6e 66 5b f5 c4 73 ea 96 b9 ce 45 d7 b9 6c 76 .nf[..s....E..lv
b400007a99833024 3b 39 5b 9d d9 b5 0a 01 8b 06 2c 18 e4 ab 06 ec ;9[.......,.....
uncompress return
0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
b400007cc43d8710 b9 0e 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b400007cc43d8720 01 00 01 00 00 00 76 d9 00 00 00 00 00 00 00 00 ......v.........
b400007cc43d8730 10 98 91 99 7a 00 00 00 0b 00 00 00 01 00 00 00 ....z...........
b400007cc43d8740 01 01 01 00 00 00 eb 1a 00 00 00 00 00 00 00 00 ................
call66:sub_49F0
找到 so 里的原位置 qword_2E270 （0x02E270）接下来写脚本：
import zlib
def rc4(key, data):
S = list(range(256))
j = 0
out = []
for i in range(256):
j = (j + S[i] + key[i % len(key)]) % 256
S[i], S[j] = S[j], S[i]
i = j = 0
for char in data:
i = (i + 1) % 256
j = (j + S[i]) % 256
S[i], S[j] = S[j], S[i]
out.append(char ^ S[(S[i] + S[j]) % 256])
return bytes(out)
def hexdump(list):
for i in range(0x20):
print(f"{list[i]:02x}",end=' ')
print()
file = "new_so_fixed"
# get the data from the offset 0x02E270
with open(file, "rb") as f:
f.seek(0x02E270)
data = f.read(0xb8010)
data = list(data)
hexdump(data)
# RC4 decrypt
key = list(bytes.fromhex("76 55 56 34 23 91 23 53 56 74"))
decrypt_data = rc4(key, data)
hexdump(decrypt_data)
# uncompress data
zdata = decrypt_data[4:]
zlen = int.from_bytes(decrypt_data[:4], byteorder='little')
hexdump(zdata)
dp_data = zlib.decompress(zdata)
hexdump(dp_data)
# save
with open('wrap_elf_part1', 'wb') as f:
f.write(dp_data[:158441])
with open('wrap_elf_part2', 'wb') as f:
f.write(dp_data[158441:])
往上找调用链，分析四个部分的意义。通过注册结构体，然后往上复原。
- 在 3C94 位置（prelink_image）找到 part4 的意义是 .dyn segment
- 在 4918 位置（link_image）找到 part 123 的意义（对照源代码顺序）分别是 program header table，plt 重定位的
.rela.plt基址数据重定位的.rela.dyn
继续编写脚本，分成四个部分：
import zlib
def rc4(key, data):
S = list(range(256))
j = 0
out = []
for i in range(256):
j = (j + S[i] + key[i % len(key)]) % 256
S[i], S[j] = S[j], S[i]
i = j = 0
for char in data:
i = (i + 1) % 256
j = (j + S[i]) % 256
S[i], S[j] = S[j], S[i]
out.append(char ^ S[(S[i] + S[j]) % 256])
return bytes(out)
def hexdump(list):
for i in range(0x20):
print(f"{list[i]:02x}", end=' ')
print()
file = "new_so_fixed"
# get the data from the offset 0x02E270
with open(file, "rb") as f:
f.seek(0x02E270)
data = f.read(0xb8010)
data = list(data)
hexdump(data)
# RC4 decrypt
key = list(bytes.fromhex("76 55 56 34 23 91 23 53 56 74"))
decrypt_data = rc4(key, data)
hexdump(decrypt_data)
# uncompress data
zdata = decrypt_data[4:]
zlen = int.from_bytes(decrypt_data[:4], byteorder='little')
hexdump(zdata)
dp_data = zlib.decompress(zdata)
hexdump(dp_data)
# save
# with open('wrap_elf_part1', 'wb') as f:
# f.write(dp_data[:158441])
with open('wrap_elf', 'wb') as f:
f.write(dp_data[158441:])
xor_key = dp_data[0]
data = dp_data[1:158441]
# take 4 part
# take 4 part
ind = 0
size = int.from_bytes(data[ind:ind+4], 'little')
ind = ind+4
with open(f"wrap_elf_phdr_0x{size:x}", 'wb') as f:
f.write(bytes([i^xor_key for i in data[ind:ind+size]]))
ind = ind+size
size = int.from_bytes(data[ind:ind+4], 'little')
ind = ind+4
with open(f"wrap_elf_rela_plt_0x{size:x}", 'wb') as f:
f.write(bytes([i^xor_key for i in data[ind:ind+size]]))
ind = ind+size
size = int.from_bytes(data[ind:ind+4], 'little')
ind = ind+4
with open(f"wrap_elf_rela_dyn_0x{size:x}", 'wb') as f:
f.write(bytes([i^xor_key for i in data[ind:ind+size]]))
ind = ind+size
size = int.from_bytes(data[ind:ind+4], 'little')
ind = ind+4
with open(f"wrap_elf_dyn_0x{size:x}", 'wb') as f:
f.write(bytes([i^xor_key for i in data[ind:ind+size]]))
之用用 010editor 填充
- 首先在 elf header 里面找到 program header table，填充
- 然后在 program header 里面找到 .dyn ，填充
- 最后在 .dyn 里面找到重定位表的位置，填充
010editor 模板没有对动态链接段到某些特殊表的识别，所以这里借助其他工具 https://zhuanlan.zhihu.com/p/387936093 （MacOS 没有 readelf，objdump 也好像不行，要用 linux 环境）
readelf -d ./wrap_elf
readelf: Error: no .dynamic section in the dynamic segment
Dynamic section at offset 0x16e3c0 contains 27 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [liblog.so]
0x0000000000000001 (NEEDED) Shared library: [libz.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so]
0x0000000000000001 (NEEDED) Shared library: [libm.so]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
0x000000000000000e (SONAME) Library soname: [libjiagu.so]
0x0000000000000019 (INIT_ARRAY) 0x17c3f0
0x000000000000001b (INIT_ARRAYSZ) 112 (bytes)
0x000000000000001a (FINI_ARRAY) 0x17c460
0x000000000000001c (FINI_ARRAYSZ) 16 (bytes)
0x0000000000000004 (HASH) 0x190
0x0000000000000005 (STRTAB) 0x4d20
0x0000000000000006 (SYMTAB) 0x1360
0x000000000000000a (STRSZ) 11316 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000003 (PLTGOT) 0x17e5b0
0x0000000000000002 (PLTRELSZ) 5712 (bytes) <<<<<<<<< .rela.plt.size
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x2cae0 <<<<<<<<<<<<<< .rela.plt
0x0000000000000007 (RELA) 0x7958 <<<<<<<<<<<<<< .rela.dyn
0x0000000000000008 (RELASZ) 151944 (bytes) <<<<<<< .rela.dyn.size
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000000000001e (FLAGS) BIND_NOW
0x000000006ffffffb (FLAGS_1) Flags: NOW
0x000000006ffffff9 (RELACOUNT) 5833
0x0000000000000000 (NULL) 0x0
修复完成，直接用 IDA 打开，简直要爽飞了
继续跟进，导入新的函数数据（记得把文件偏移调成 0xE70000），导出信息之后继续跟进函数调用串
call104:sub_20D36C
call105:sub_20D4B8
call106:_ZNSt3__16vectorIiNS_9allocatorIiEEE21__push_back_slow_pathIRKiEEvOT_
call107:sub_20BF2C
call108:_ZNSt3__16vectorIiNS_9allocatorIiEEE21__push_back_slow_pathIiEEvOT_
call109:sub_20E4D8
call110:sub_20E7C0
call111:sub_20E7C0
call112:sub_20E824
call113:sub_2091DC
call114:sub_20E91C
call115:sub_202C98
call116:sub_20ED30
open /proc/5977/maps
call117:_ZNSt3__16vectorIiNS_9allocatorIiEEE21__push_back_slow_pathIiEEvOT_
call118:sub_20C0DC
open /proc/self/maps
find maps
call119:_Z9__arm_a_2PcmS_Rii
call120:sub_208BC8
call121:sub_20AD24
open /proc/self/maps
find maps
call122:j_ffi_prep_cif_var
call123:ffi_prep_cif_var
call124:sub_21A634
call125:sub_20B900
call126:sub_20B904
call127:sub_20B938
call128:sub_20B958
call129:sub_20B98C
call130:sub_20BB74
Process terminated
我去，还是不行，这又是什么反调试，没见过的啊，不是应该成功到后面的内存检测了吗，怎么中间就卡住了
可疑的地方是
v22 = v12;
memcpy(v27, v15, v7);
memcpy(&v27[v7], &v26, v14);
memcpy(&v27[v23], &v25, v22);
memcpy(&v27[v24], &v26, v21);
v16 = *a3;
hook 这个点查看这个地址是谁的部将，草，怎么在前面就返回了。
看到后面，发现是前面开了一个进程来搞，我这边后面 dump 太多东西，拖累了速度，导致看到的东西就少一点了，把 pthread hook 了之后可以发现，进程就是在这个时候退出的：
call115:sub_202C98
call116:sub_20ED30
open /proc/21799/maps
call117:_ZNSt3__16vectorIiNS_9allocatorIiEEE21__push_back_slow_pathIiEEvOT_
call118:sub_20C0DC
open /proc/self/maps
find maps
call119:_Z9__arm_a_2PcmS_Rii
call120:sub_208BC8
call121:sub_20AD24
======
find thread func offset libjiagu_64.so 1ac1f0
open /apex/com.android.runtime/lib64/bionic/libc.so
open /apex/com.android.runtime/lib64/bionic/libc.so
Process crashed: Bad access due to invalid address
如果把主线程放再慢一点，是不是就能看到整个过程了呢？哈哈，确实可以是可以
call87: sub_8B50
call88: sub_8ED4
call89: sub_8430
call90: interpreter_wrap_int64_t_bridge
call91: sub_9D60
789fb014a4 is in libjiagu_64.so offset: 0xa4a4
789fb03e0c is in libjiagu_64.so offset: 0xce0c
789fb0bedc is in libjiagu_64.so offset: 0x14edc
790fa1e214 is in libstdc++.so offset: 0x10214
789fb0b5f8 is in libjiagu_64.so offset: 0x145f8
789fb0bc90 is in libjiagu_64.so offset: 0x14c90
789fb0c8b8 is in libjiagu_64.so offset: 0x158b8
790fa1e1dc is in libstdc++.so offset: 0x101dc
789fc84ac4 is in libjiagu_64.so offset: 0x18dac4
789fb0e6e0 is in libjiagu_64.so offset: 0x176e0
789fb0e710 is in libjiagu_64.so offset: 0x17710
789fb0dcb4 is in libjiagu_64.so offset: 0x16cb4
789fb043c4 is in libjiagu_64.so offset: 0xd3c4
789fb0bedc is in libjiagu_64.so offset: 0x14edc
789fb00da8 is in libjiagu_64.so offset: 0x9da8
789fb014a4 is in libjiagu_64.so offset: 0xa4a4
789fb03e0c is in libjiagu_64.so offset: 0xce0c
不过这个时候跳进去的是一个内存中的函数，就是这个位置 raise 了一个啥东西吧，看看此时的值是什么
进去的东西在 .data 里面，有加密。所以尝试在这个时候再次 dump 这个 so 看看。
旧的复现
./stackplz
--name com.oacia.apk_protect
--syscall read,write,ptrace,fstat,execve
--out anti_debug.log
--lib libjiagu_64.so
--point "JNI_OnLoad+0x0[uint,uint,uint]"
--stack
--stack-size 16384
--regs
--debug
--uid $(awk '/^Uid:/{print $2}' /proc/$(pidof com.oacia.apk_protect)/status)
./stackplz -n com.oacia.apk_protect --point strstr[str,str] --point open[str,int] -o anti_debug.log
在 open 的地方下硬件断点。识别到了打开 /proc/self/maps 这种东西，之后应用内存里的 frida-server 就挂掉了。
有趣的是，挂掉了之后程序并没有直接退出，而是一直白屏着，然后硬件断电也一直被触发
推测应该是壳一开始就开了一个线程，循环检测这个程序内存中是否有可疑的内存映射，有的话就把这个地方的内存给收回？或者填充什么的让它出错？然后这个循环检测是一直开着的，而应用程序还一直在等待加密壳返回 dex，可能在解密之前的某个地方壳自己卡住了，于是一直白屏。
还得是用 Stalker.follow 更下来，看到哪一步爆了 https://github.com/oacia/stalker_trace_so
var func_addr = [0x2940, , 0x274210];
var func_name = ["sub_2940", , "free"];
var so_name = "libjiagu_64.so";
/*
@param print_stack: Whether printing stack info, default is false.
*/
var print_stack = false;
/*
@param print_stack_mode
- FUZZY: print as much stack info as possible
- ACCURATE: print stack info as accurately as possible
- MANUAL: if printing the stack info in an error and causes exit, use this option to manually print the address
*/
var print_stack_mode = "FUZZY";
function addr_in_so(addr) {
var process_Obj_Module_Arr = Process.enumerateModules();
for (var i = 0; i < process_Obj_Module_Arr.length; i++) {
if (addr > process_Obj_Module_Arr[i].base && addr < process_Obj_Module_Arr[i].base.add(process_Obj_Module_Arr[i].size)) {
console.log(addr.toString(16), "is in", process_Obj_Module_Arr[i].name, "offset: 0x" + (addr - process_Obj_Module_Arr[i].base).toString(16));
}
}
}
function hook_dlopen() {
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
//console.log(path);
if (path.indexOf(so_name) >= 0) {
this.is_can_hook = true;
}
}
},
onLeave: function (retval) {
if (this.is_can_hook) {
// note: you can do any thing before or after stalker trace so.
trace_so();
}
}
}
);
}
function trace_so() {
var times = 1;
var module = Process.getModuleByName(so_name);
var pid = Process.getCurrentThreadId();
console.log("start Stalker!");
Stalker.exclude({
"base": Process.getModuleByName("libc.so").base,
"size": Process.getModuleByName("libc.so").size
})
Stalker.follow(pid, {
events: {
call: false,
ret: false,
exec: false,
block: false,
compile: false
},
onReceive: function (events) {
},
transform: function (iterator) {
var instruction = iterator.next();
do {
if (func_addr.indexOf(instruction.address - module.base) !== -1) {
console.log("call" + times + ":" + func_name[func_addr.indexOf(instruction.address - module.base)])
times = times + 1
if (print_stack) {
if (print_stack_mode === "FUZZY") {
iterator.putCallout((context) => {
console.log("backtrace:\n" + Thread.backtrace(context, Backtracer.FUZZY).map(DebugSymbol.fromAddress).join('\n'));
console.log('---------------------')
});
}
else if (print_stack_mode === "ACCURATE") {
iterator.putCallout((context) => {
console.log("backtrace:\n" + Thread.backtrace(context, Backtracer.ACCURATE).map(DebugSymbol.fromAddress).join('\n'));
console.log('---------------------')
})
}
else if (print_stack_mode === "MANUAL") {
iterator.putCallout((context) => {
console.log("backtrace:")
Thread.backtrace(context, Backtracer.FUZZY).map(addr_in_so);
console.log('---------------------')
})
}
}
}
iterator.keep();
} while ((instruction = iterator.next()) !== null);
},
onCallSummary: function (summary) {
}
});
console.log("Stalker end!");
}
setImmediate(hook_dlopen, 0);
var dump_once = false;
function dump_so(so_name) {
if (dump_once) {
return;
}
dump_once = true;
var libso = Process.getModuleByName(so_name);
console.log("[name]:", libso.name);
console.log("[base]:", libso.base);
console.log("[size]:", ptr(libso.size));
console.log("[path]:", libso.path);
var file = new File("/data/data/com.oacia.apk_protect/" + so_name + '_' + libso.base + '_' + libso.size + ".so", "wb");
if (!file) {
console.log("open file error");
return
}
Memory.protect(libso.base, libso.size, 'rwx');
file.write(libso.base.readByteArray(libso.size));
file.flush();
file.close();
console.log("dump so success to /data/data/com.oacia.apk_protect/" + libso.name + '_' + libso.base + '_' + libso.size + ".so");
}
function addr_in_so(addr) {
var modules = Process.enumerateModules();
for (var i = 0; i < modules.length; i++) {
var module = modules[i];
if (module.base <= addr && addr <= module.base.add(module.size)) {
return module.name + "!" + (addr.sub(module.base));
}
}
return addr;
}
function hook_open() {
// Hook 信号处理函数，阻止 SIGTRAP 触发崩溃
console.log("starting hook... replacing signal");
Interceptor.replace(
Module.findExportByName(null, "signal"),
new NativeCallback((sig, handler) => {
console.log("trap signal");
if (sig === 5) { // SIGTRAP 的信号编号为 5
console.log("Block SIGTRAP");
return 0; // 返回空处理器
}
return signal(sig, handler); // 保留其他信号
}, 'pointer', ['int', 'pointer'])
);
console.log("attaching open...")
Interceptor.attach(Module.findExportByName(null, "open"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
console.log("open " + path);
if (path == "/proc/self/maps") {
console.log("find maps");
// redirect to noexits file
// this.new_path = Memory.allocUtf8String("/proc/self/noexits");
}
if (path.indexOf(".dex") >= 0) {
// console.log("find dex");
// log traceback
// console.log(Thread.backtrace(this.context, Backtracer.FUZZY).map(addr_in_so).join("\n") + "\n");
// dump so
// dump_so("libjiagu_64.so");
}
}
// hook_get_phdr_dump_so();
},
onLeave:function (ret){
var fd = this.context.x0.toInt32();
var buffer= Memory.alloc(0x10000);
var bytesRead = new NativeFunction(Module.findExportByName(null,"read"),'int',['int','pointer','int'])(fd,buffer,0x10000);
if(bytesRead>0){
console.log(buffer.readCString());
}
}
}
);
}
function hook_get_phdr_dump_so() {
var lib = Module.findBaseAddress("libjiagu_64.so")
if (!lib) {
console.log("[x] cannot find lib");
}
Interceptor.attach(lib.add(0x5E6C), {
onEnter: function (args) {
const target_ptr = ptr(args[0]);
console.log(hexdump(target_ptr, {
offset: 0,
length: 0x38 * 6,
header: true,
ansi: false
}))
}
});
}
setImmediate(hook_open)
好像是对内存地址权限修改了，有一个中断信号
Process crashed: SIGTRAP SI_TKILL
tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE) pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY) signal 5 (SIGTRAP), code -6 (SI_TKILL), fault addr -------- Abort message: 'Unable to allocate data slab near 0x6e02f35000 with max_distance=2142449663'
https://blog.csdn.net/newchenxf/article/details/122172137
这里原文采用了 hook open 的方法（注意力惊人注意到到这个函数可能会反 frida？）可能是打开 maps 内存看有没有什么可疑字符串吧
这里看看返回的内容就知道了：
call88:sub_8ED4
call89:sub_8430
call90:interpreter_wrap_int64_t_bridge
call91:sub_9D60
open /proc/self/maps
find maps
12c00000-2ac00000 rw-p 00000000 00:00 0 [anon:dalvik-main space (region space)]
70dd5000-7108e000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot.art]
7108e000-710d7000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-core-libart.art]
710d7000-71101000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-okhttp.art]
71101000-7113f000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-bouncycastle.art]
7113f000-71140000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-apache-xml.art]
71140000-71e10000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-framework.art]
71e10000-71e11000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-framework-graphics.art]
71e11000-71e30000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-ext.art]
71e30000-71f7d000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-telephony-common.art]
71f7d000-7201d000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-voip-common.art]
7201d000-72066000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-ims-common.art]
72066000-721da000 rw-p 00000000 00:00 0 [anon:dalvik-/system/framework/boot-core-icu4j.art]
721da000-72276000 r--p 00000000 fe:00 1329 /system/framework/arm64/boot.oat
这样看下来并不是简单的查看 maps 里找可疑内存，
查看崩溃前的函数调用链，到
sub_491C() // link image
sub_4000() // 从解密后的soinfo的前面的某个gap里的东西作为函数调用起来？
sub_41B4() // 卧槽，这里有猫腻
sub_35AC() sigaction()
... //未知调用
这个函数在 link image 之后加载，自处理了信号处理？
不行，还得要调试器跟一下才行？不然就只能 stackplz 隔山打牛
真是碰到好东西了，看到一个
https://mp.weixin.qq.com/s/5Bvku-K-UBDrkAQgrimXfQ
想到之前做过的题目 SUCTF2025 su_app 这还真有可能是通过 maps 来获取内存位置，进而找到对应内存中的特征和文件比对
dd if=./new_so_fixed of=dump_so skip=946176 bs=1
sub_49F0(__int64 a1) -> add_vdso()
sub_3C94(soinfo *a1, __int64 a2, int a3) -> prelink_image()
sub_4918(__int64 a1) -> link_image()