[原创]iOS脱壳-iOS安全-看雪-安全社区|安全招聘|kanxue.com

[原创]iOS脱壳

2021-3-15 16:29 14964

[原创]iOS脱壳

System32

2021-3-15 16:29

14964

刚学了iOS来水一篇
环境：
mac
iphone 12.5(越狱)
工具:
lldb(手动)
otool(检查工具)
dumpdecrypted(自动)https://github.com/stefanesser/dumpdecrypted.git
bfinject(自动)https://github.com/BishopFox/bfinject
crackerXI (自动)cydia商店里面哦
frida-ios-dump(自动)https://github.com/AloneMonkey/frida-ios-dump
Clutch(自动)https://github.com/KJCracks/Clutch/releases

iOS脱壳
要脱壳那么首先要知道加壳的
对于iOS加壳来说所有上架到appstore 的app 都会被apple进行加壳，当然市面上也有商业壳
如何发现iOS是否加壳
从iphone上将下载的app 导出到mac 使用 MachOView/010editor 来检查app的可执行文件Mach-O文件格式中的一项为LC_ENCRYPTION_INFO 当该项的cryptid 1 代表加壳 0为不加壳
加密后
在mac上也可以使用otool来查看
otool -arch arm64 -l ./WhatsApp ｜grep -a 4 LC_ENCRYPTION_INFO >>whatsapp.txt

Load command 12
          cmd LC_ENCRYPTION_INFO_64
      cmdsize 24
     cryptoff 16384
    cryptsize 15548416
      cryptid 1
          pad 0

如果是处于加密状态我们使用ida打开会发生这样的情况
图片描述
yes

当我们把cyptid的值修改了之后

虽然ida不报文件已被加密的提示了，但是加载进入之后，和上面的ida加载后的图是一样的，那也就是说ida分析mach-o的文件是否加密也是从LC_ENCRYPTION_INFO的cryptid 来检查的

这里我们使用lldb手动脱壳
1.首先使用debugserver 将app调试起来，这样app才可以在内存中将加密的数据进行解密。

1	`debugserver` `-x backboard localhost:8888` `/var/containers/Bundle/Application/375C1A70-079A-4006-975C-904529E4F9CD/WhatsApp.app/WhatsApp`

mac使用 lldb 进行连接调试
2.获取app内存的加载地址，因为每一个app的内存加载地址都不同，所以使用lldb命令将内存加载地址获取

1 2	`image` `list` `-f` `-o` `[` `0]` `/private/var/containers/Bundle/Application/375C1A70-079A-4006-975C-904529E4F9CD/WhatsApp.app/WhatsApp` `0x00000000008e8000(0x00000001008e8000)`

3.利用lldb命令 memory 将解密后的数据dump出来。
0x00000000008e8000 获取到的内存加载地址+
上面使用otool获取到的加密起始地址
完整地址就是:0x00000000008e8000+16384

1	`memory read` `0x00000001008e8000+16384` `-c` `15548416` `--force` `--binary` `--outfile ./WhatsAppDecrypted`

首先内存加载地址 0x00000001008e8000 +16384(加密数据的偏移) -c 15548416(加密数据的大小) 将指针移至加密数据偏移开始的地址，然后dump 15548416大小的数据，也就将加密数据全部dump下来了，而dump出来的数据是没有Mach-O头数据的所以需要修复头
4.使用命令dd在加密的app可执行文件上进行patch

mob@vuldeMacBook-Pro /tmp % dd seek=16384 bs=1 conv=notrunc if=./WhatsAppDecrypted  of=WhatsApp
15548416+0 records in
15548416+0 records out
15548416 bytes transferred in 58.542579 secs (265592 bytes/sec)