某银行iOS frida检测(例二)
搜索frida等特征关键词后对相关函数进行hook,发现并未调用即闪退。
检测时机较早,对main函数进行hook,发现仍然没执行。
main函数执行前的流程:
1. 程序执行从_dyld_star开始
- 1.1. 读取macho文件信息,设置虚拟地址偏移量,用于重定向。
- 1.2. 调用dyld::_main方法进入macho文件的主程序。
2. 配置一些环境变量
- 2.1. 设置的环境变量方便我们打印出更多的信息。
- 2.1. 调用getHostInfo()来获取machO头部获取当前运行架构的信息。
3. 实例化主程序,即macho可执行文件
4. 加载共享缓存库
5. 插入动态缓存库
6. 链接主程序
7. 初始化函数
- 7.1. 经过一系列的初始化函数最终调用notifSingle函数。
- 7.2. 此回调是被运行时_objc_init初始化时赋值的一个函数load_images
- 7.3. load_images里面执行call_load_methods函数,循环调用所用类以及分类的load方法。
- 7.4. doModInitFunctions函数,内部会调用全局C++对象的构造函数,即_ _ attribute_ _((constructor))这样的函数。
8. 返回主程序的入口函数,开始进入主程序的main()函数
关于初始化过程:
https://tenloy.github.io/2021/10/21/dyld-objc.htm
涉及到两个段:
__objc_nlclslist(+ load方法)
__mod_init_func(init 方法)
查看hook __objc_nlclslist段中各个类的load函数
只发现在Sciapodous类的load函数中有可疑函数
基本都是MsgRbKVPGCrUcJUf类的初始化行为,之后分析得知MsgRbKVPGCrUcJUf就是用于风险检测的类,-[MsgRbKVPGCrUcJUf FZyLGPttEmkjUXIg:]函数中存在对特征文件的检测。但是这些函数只是对标志位的设置,并无主动退出行为。
再在__mod_init_func段中找
通过对各个init函数hook,在onEnter和onLeave中打log,通过闪退时的日志输出可以找到是哪个函数执行后导致的闪退。
最后发现是InitFunc_27:
MsgRbKVPGCrUcJUf类应该是一个用于风险监测的类,InitFunc_27开头通过获取MsgRbKVPGCrUcJUf中的开关属性(在Sciapodous + load 中设置)判断是否进入监测分支,sub_101013C80函数是判断以下文件是否存在:
1 | __const:00000001012991D8 ; sub_101013C80+28↑o ... |
sub_101006B80函数进行如下检测:
判断传入的函数名的函数头是否被修改为跳转指令(是否被hook)
sub_101006FEC函数是对方法Swizzling Hook的检测。
对以下函数分别使用sub_101006B80和sub_101006FEC函数进行frida hook和Swizzling Hook的检测:
1 | v18 = NSStringFromSelector("nkGUHXJzuioWfEml"); |
绕过InitFunc_27函数后发现仍然闪退,继续分析发现InitFunc_28中存在对InitFunc_27是否被hook的检测:
(sub_101006E08函数和sub_101006B80的检测方式相同)
InitFunc_29中存在对InitFunc_28是否被hook的检测:
InitFunc_30中存在对sub_100FF8E64和sub_101001764函数是否被hook的检测:
(sub_100FF8E64函数是检测27042端口是否占用,sub_101001764对frida文件检测)
InitFunc_31中同样是使用sub_101006E08和sub_101006FEC对指定的函数进行hook检测;
InitFunc_32延迟执行sub_100FFC0FC和sub_100FFC208,其中包含一些对标志位的判断;
InitFunc_33延迟执行sub_100FFC3EC,同样是使用sub_101006E08和sub_101006FEC对指定的函数(DTRpcOperation、DTURLRequestOperation)进行hook检测。
绕过以上函数后发现仍然闪退,关闭frida后仍然闪退,应该是越狱检测,越狱检测不再赘述,使用插件绕过越狱检测后运行正常。