iOS 应用加固方法

前提

众所周知,iOS系统安全性非常高,很少出现漏洞,几乎不会中毒。大家认为苹果系统的封闭性会使iOS APP安全性比较高,但是实际上iOS应用本身被破解的难度并不高,一旦在越狱设备上,ipa被分析就会变得很容易。对于iOS开发者来说,有必要了解一些APP加固的方法,用以提高破解的难度,特别是针对一些金融、游戏类APP的开发。

iOS代码保护

在大多数iOS应用中,一些工具,比如Clutch,class-dump,cycript,lldb,theos.对应用程序的结构,代码逻辑,运行流程,可以做到很容易的分析。然后进行应用的破解,篡改,重签名。可以从逆向分析的方式做代码保护的思路:

  • 1.静态分析:针对这种情况可以把字符串加密,类名方法名混淆,代码混淆
  • 2.调试 :反调试
  • 3.注入 :反注入
  • 4.中间人攻击 :https, 证书验证, 数据加密

一,静态分析

静态分析是指用工具对程序结构,代码逻辑的分析。很大程度上取决关键字,通过关键字找到敏感代码,进行破解。所以静态分析的防护主要是代码混淆。

1,混淆硬编码的明文字符串

明文字符串可直接在二进制包搜索到,常常是作为逆向分析的切入口,隐藏明文字符串可有效提升静态分析的难度。在源代码中将字符串加密,运行时先解密在使用,如果直接在代码中写加密后字符串,代码的可读性会变得非常差。网上又一个方法不是很优雅,但有效,私以为不错:

  • 将源代码中的字符串通过函数宏手动标记
  • 打包的时候拷贝源代码副本
  • 执行脚本,将副本代码中所有标记过的字符串,替换成decrypt("密文")的形式
  • 在适当的位置,插入decrypt函数的实现(或者事先在源代码中写好)
  • 编译

通过函数宏手动标记字符串:


iOS 应用加固方法_第1张图片

执行加密脚本后:


iOS 应用加固方法_第2张图片

这里的加密仅仅是和0xAA做了一个简单的异或运算,解密函数内联编译到代码中。

iOS 应用加固方法_第3张图片

上图是未做混淆前的反汇编代码,可以直接看到明文字符串。
下面是经过混淆的反汇编代码,已经看不到明文字符串了。

iOS 应用加固方法_第4张图片

2,objective C代码混淆

网上方法较多,其中尤以念茜大神的方法为佳。大抵是在编译前执行混淆脚本,对OC函数(消息)进行混淆。但是又不能全部混淆,有一些是SDK的代理回掉,如tableView的UITableViewDataSource,混淆后将不会调用,如继承子类的init,混淆后也不会调用。解决办法有很多,这里介绍两个匹配的办法:

  • 1,建立一个索引文件,将需要混淆的函数写入索引文件,混淆脚本读取索引文件的函数名进行匹配。
  • 2,在代码中以前缀或后缀的方式标识需要混淆的函数,混淆脚本通过这些标识进行自动混淆。

匹配函数名后,将混淆过的函数写入数据库中记录下来,以便在后续在分析app Crash的时候找对应的函数,快速定位到对应的问题代码.
未做混淆的代码经过class-dump或者直接在hopper中可直接看到函数名,逆向者以此猜测程序功能,快速切入,找到hock点。

iOS 应用加固方法_第5张图片

iOS 应用加固方法_第6张图片

混淆脚本设置
iOS 应用加固方法_第7张图片

混淆后的代码,无法通过函数名猜测到程序功能,可大大增加逆向难度。

iOS 应用加固方法_第8张图片

代码混淆除了函数名的混淆,还有类名,协议名,文件名的混淆等。此外,敏感代码可以用C函数来实现,可以避免在class-dump等工具中倒出,但是在nm等工具中还是可以看到一些符号表的信息。

小结,静态分析的防护手段主要是作代码的混淆,已到达提升逆向的难度。此外还有代码逻辑的混淆,通过在代码中加入大量无用的逻辑判断,增加程序结构的复杂性,以此提升程序在ida,hopper等工具分析中的难度。但是此方法对源代码的改动性较大,使代码的可读性变得极差。

二,动态分析 反调试

逆向者不仅可以静态分析程序,也可以通过debugserver,lldb等工具动态分析程序,通过在程序中打断点,修改内存中的变量等方式分析,改变程序的行为。以此达到分析,hock程序的目的。

1,反调试之 ptrace

谈到debug,首先会想到的一个系统调用是ptrace,它主要用于实现断点调试和系统调用跟踪。 PT_DENY_ATTACH是苹果增加的一个ptrace选项,用以防止gdb等调试器依附到某进程。代码如下:

#ifndef PT_DENY_ATTACH
#define PT_DENY_ATTACH 31
#endif

typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];


    void *handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
    ptrace_ptr_t ptrace_ptr = (ptrace_ptr_t)dlsym(handle, "ptrace");
    ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);

}

手边没有越狱机器,直接通过xcode debug,应用会Crash掉,安装到手机后可正常打开。
针对这种ptrace的反反调试方法其实很简单,通过下断点,然后修改ptrace的参数或者用hook函数去掉反调试保护就可以搞定。也可在程序多个处调用来增加crash,提高逆向难度。

2,反调试之 sysctl

思路是通过sysctl查看信息进程里的标记,判断自己是否正在被调试。sysctl是用以查询内核状态的接口,并允许具备相应权限的进程设置内核状态。其定义如下:

 int sysctl(int *name, u_int namelen, void *old, size_t *oldlen, void *newp, size_t newlen);
 name参数是一个用以指定查询的信息数组;
 namelen用以指定name数组的元素个数;
 old是用以函数返回的缓冲区;
 oldlen用以指定oldp缓冲区长度;
 newp和newlen在设置时使用;
    当进程被调试器依附时,kinfo_proc结构下有一个kp_proc结构域,kp_proc的p_flag的被调试标识将被设置,即会进行类似如下的设置:
    kinfo_proc. kp_proc. p_flag & P_TRACED
   其中P_TRACED的定义如下:
   #define P_TRACED        0x00000800  /* Debugged process being traced */

我们可以通过sysctl查询进程相应的kinfo_proc信息,查询函数的实现可以这样:

static int is_debugged() __attribute__((always_inline));

@implementation ViewController


- (void)viewDidLoad {
    [super viewDidLoad];

    if (is_debugged() == YES) {
        self.label.text = @"is_debugged ";
        exit(-1);
    }else{
        self.label.text = @"not is_debugged";
    }

}

static int is_debugged(){
    int name[4] = {CTL_KERN,KERN_PROC,KERN_PROC_PID,getpid()};
    struct kinfo_proc Kproc;
    size_t kproc_size = sizeof(Kproc);
    
    memset((void*)&Kproc, 0, kproc_size);
    
    if (sysctl(name, 4, &Kproc, &kproc_size, NULL, 0) == -1) {
        perror("sysctl error \n ");
        exit(-1);
    }
    
    return (Kproc.kp_proc.p_flag & P_TRACED) ? 1 : 0;
}

针对sysctl的反反调试的思路其实很简单,只需要在函数返回时清除p_flag标识位即可,根据sysctl.h文件中的定义:

#define CTL_KERN    1
#define KERN_PROC 14
#define KERN_PROC_PID 1

以及sysctl的第二个参数为4,对sysctl下条件断点,在sysctl返回后,根据反编译二进制文件找到kproc的首地址,接下来找到p_flag相对kproc首地址的偏移,最后修改对应内存地址的值就OK了。

文中混淆脚本 以及Dome地址

动态分析的防护还有很多,如:dylib注入检测,越狱检测等。当然,也有相应的反反调试手段,且许多检测方法涉及到iOS的私有API,存在一定的上架风险。

三,总结

总体来说,iOS系统安全性是很高的,且大多数iOS应用都没做混淆,反调试等。对于金融类,游戏类的应用防护套路来一点还是能增加逆向破解的难度的。当然,要完全防止程序被调试或者被逆向,理论上来说是不可能的。

参考文章

iOS App的加固保护原理 http://www.cocoachina.com/ios/20170324/18955.html
iOS代码混淆 http://xelz.info/blog/2016/11/20/ios-code-obfuscation/
阿里 iOS Anti-Debug https://jaq.alibaba.com/blog.htm?id=53
关于反调试&反反调试那些事 http://bbs.iosre.com/t/topic/8179
看雪论坛 iOS加固浅谈之字符串加密 http://bbs.pediy.com/thread-217991.htm

你可能感兴趣的:(iOS 应用加固方法)