作者归档:风吹走了我

sysctl反调试&反sysctl反调试

目录

一、关于systcl
二、利用systcl做反调试
(一)、了解原理
(二)、反调试代码
三、反sysctl反调试
四、增强sysctl反调试
五、静态分析绕过反调试
六、小结

Demo

一、关于systcl

通过man sysctl查看该函数的描述

sysctl反调试&反sysctl反调试
sysctl函数

sysctl反调试&反sysctl反调试
sysctl函数

根据描述:sysctl可以检索内核状态且运行有权限的进程设置内核状态,同样也可以获取内核、进程的状态。

二、利用systcl做反调试

(一)、了解原理

当一个进程被调试时,该进程中会有对应的标记位来表示自身正在被调试,因此可以通过sysctl函数来获取当前进程的信息,通过这些信息来检查状态,阻止调试。简单说一下原理,在proc.h头文件中定义了一些与进程相关的信息,结构体struct extern_proc中包含一个p_flag表示进程的一些标记

struct extern_proc {
    ···
    struct  vmspace *p_vmspace; /* Address space. */
    struct  sigacts *p_sigacts; /* Signal actions, state (PROC ONLY). */
    int p_flag;         /* P_* flags. */
    char    p_stat;         /* S* process status. */
    pid_t   p_pid;          /* Process identifier. */
    ···
};

接着往下看,会看到一些状态值的宏定义,因为都是数值的定义,我猜测是用于与当前进程标记做某些运算操作得出结果来判断进程状态,看到其中的P_TRACED,根据注释,大概知道是调试、跟踪进程的意思

#define P_TRACED    0x00000800  /* Debugged process being traced */

根据测试,p_flag的值在调试状态与正常运行状态下是不同的,可以通过宏P_TRACED判断,原理如下图:

sysctl反调试&反sysctl反调试
原理

(二)、反调试代码

//
//  main.m
//  sysctl
//
//  Created by kinken on 2018/12/28.
//  Copyright © 2018 kinkenyuen. All rights reserved.
//

#import <UIKit/UIKit.h>
#import "AppDelegate.h"
#import <sys/sysctl.h>

BOOL isDebuggingWithSysctl(){
    /**
     需要检测进程信息的字段数组
     */
    int name[4];
    name[0] = CTL_KERN;
    name[1] = KERN_PROC;
    name[2] = KERN_PROC_PID;
    name[3] = getpid();

    /**
     查询进程信息结果的结构体
     */
    struct kinfo_proc info;
    size_t info_size = sizeof(info);
    info.kp_proc.p_flag = 0;

    /*查询成功返回0*/
    int error = sysctl(name, sizeof(name) / sizeof(*name), &info, &info_size, NULL, 0);
    if (error == -1) {
        NSLog(@"sysctl process check error ...");
        return NO;
    }
    
    /*根据标记位检测调试状态*/
    return ((info.kp_proc.p_flag & P_TRACED) != 0);
}

/**
 定时器检测是否在调试状态
 */
static dispatch_source_t timer;
void debugCheckTiming() {
    timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_global_queue(0, 0));
    dispatch_source_set_timer(timer, DISPATCH_TIME_NOW, 1.0 * NSEC_PER_SEC, 0.0 * NSEC_PER_SEC);
    dispatch_source_set_event_handler(timer, ^{
        if (isDebuggingWithSysctl()) {
            NSLog(@"检测到调试");
            exit(-1);
        }else {
            NSLog(@"正常");
        }
    });
    dispatch_resume(timer);
}

int main(int argc, char * argv[]) {
    debugCheckTiming();
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

说明一下,防护代码仅仅用的是exit函数做了个简单的退出,后续学习更深入的防护。

三、反sysctl反调试

简单来说,hooksysctl函数,修改检测结果来绕过,通常使用动态库注入,由于MonkeyDev自带了反反调试代码,先屏蔽掉,自己练习一遍,代码如下:

@implementation AntiAntiDebug

static int (*orig_sysctl)(int *, u_int, void *, size_t *, void *, size_t);
int my_sysctl(int *name, u_int nameLen ,void *info ,size_t *info_size, void *newp, size_t newLen);

+ (void)load {
    rebind_symbols((struct rebinding[1]){{"sysctl",my_sysctl,(void *)&orig_sysctl}}, 1);
}

int my_sysctl(int *name, u_int nameLen ,void *info ,size_t *info_size, void *newp, size_t newLen) {
    if (nameLen == 4 && name[0] == CTL_KERN && name[1] == KERN_PROC && name[2] == KERN_PROC_PID && info && info_size && ((int)*info_size == sizeof(struct kinfo_proc))) {
        //先调用原始sysctl查询进程信息
        int result = orig_sysctl(name, nameLen, info, info_size, NULL, 0);
        
        //获取进程信息
        struct kinfo_proc *info_ptr = (struct kinfo_proc *)info;
        NSLog(@"检测到调试时p_flag的值:%d",info_ptr->kp_proc.p_flag);
        
        if (info_ptr && (info_ptr->kp_proc.p_flag & P_TRACED) != 0) {
            NSLog(@"检测到反调试,尝试绕过...");
            //两个值按位异或,赋值给p_flag,实质是将p_flag的第12位标记位改为0
            info_ptr->kp_proc.p_flag ^= P_TRACED;
            if ((info_ptr->kp_proc.p_flag & P_TRACED) == 0) {
                NSLog(@"反反调试成功!");
            }
        }
        NSLog(@"去掉检测调试后p_flag的值:%d",info_ptr->kp_proc.p_flag);
        return result;
    }
    return orig_sysctl(name, nameLen, info, info_size, NULL, 0);
}

@end
sysctl反调试&amp;反sysctl反调试
反反调试结果

四、增强sysctl反调试

思路:先执行防护代码,也就是先于三方注入的动态库加载
操作:反调试防护代码写在自己的库内
原理:自己的动态库先于注入的动态库加载

代码跟上面的一样,只是换了个位置,就不赘述了

sysctl反调试&amp;反sysctl反调试
动态库防护代码

将上面的*.app复制到MonkeyApp工程,重签名调试,下了一个exit符号断点,运行工程时断住了, 说明防护的代码生效,上一节的绕过反调试代码不起作用,如下:

sysctl反调试&amp;反sysctl反调试
反反调试失效

五、静态分析绕过反调试

  • 尝试下符号断点,查找线索,exitptrace可能比较常见,接着查看调用栈

    sysctl反调试&amp;反sysctl反调试
    调用栈

    可以看到exit的调用者是AntiDebug里的debugCheckTiming函数,对应上面的防护代码部分。

  • 通过image list查看是否有AntiDebug模块加载

    sysctl反调试&amp;反sysctl反调试
    查看是否有对应的动态库
  • 静态分析该动态库

    sysctl反调试&amp;反sysctl反调试
    分析__debugCheckTiming

留意到BL _isDebuggingWithSysctl 的下一条指令TBZ W0,#0,loc_7DCC,该指令的含义为若W0[0] == 0,则跳转到7DCC地址处,可以想到这是一个if-else条件判断,那么我们可以直接修改该指令,让它直接跳转到7DCC处,这样就不会再执行下面的_exit

  • 修改汇编指令绕过防护代码
    由于本人对IDA修改指令方面不熟悉,因此使用hopper修改,如下:
    选中需要修改的指令,option + A

    sysctl反调试&amp;反sysctl反调试
    修改指令

修改后的指令直接跳转到0x7DCC处,也就是对应代码的else块

sysctl反调试&amp;反sysctl反调试
修改后的指令

生成新的可执行文件

sysctl反调试&amp;反sysctl反调试
image.png

将新的可执行文件(这里是动态库类型)拷贝回Monkey工程下的*.app的Frameworks内的对应动态库内,重新运行工程

sysctl反调试&amp;反sysctl反调试
成功绕过检测到调试后的防护代码

六、小结

本次学习主要了解防护与破除防护的思路以及通过简单的Demo代码练习加深攻防印象,为日后更深入的分析奠定基础。

LLDB解密(砸壳)

前言

前段时间学习过利用工具来对加密的应用ipa包砸壳,dumpdecrypted砸壳,Clutch砸壳,frida-ios-dump砸壳,这次通过LLDB自己手动操作可执行文件,dump出解密的文件(实际上dumpdecrypted就是这个原理),简单了解砸壳的原理。

一、原理

加密内容在手机启动执行加载到内存后,是解密的,可以根据Mach-O文件记录的加密内容开始偏移值以及加密内容大小,从内存中dump出已经解密的部分,再将dump出的部分写回原执行文件,这样就得到一个完整的解密的可执行文件。

二、从越狱手机拷贝出原可执行文件

以WeChat为例

LLDB解密(砸壳)
查看可执行文件路径

LLDB解密(砸壳)
拷贝

LLDB解密(砸壳)
查看可执行文件加密字段信息

LLDB解密(砸壳)
arm64架构

了解到了这两个数据信息,就可以利用LLDB进行解密,下面选择64位架构进行解密

三、使用LLDB砸壳

参考LLDB+debugserver调试第三方应用进入lldb调试界面,并且附加到目标进程,如下:

LLDB解密(砸壳)
LLDB调试

查看主模块加载地址

LLDB解密(砸壳)
image.png

我们使用的物理地址为:0x0000000100014000,先记录下来,接着根据cryptoofcryptsize字段dump出解密部分,如下:

LLDB解密(砸壳)
dump出解密部分

这样dump出的文件是没有Mach-O header,因此要将dump出文件Patch回原可执行文件(可以先备份原可执行文件),Patch之前先说个注意点:

注意:手机上拷贝出的Mach-O文件含有两种架构,因此我们在Patch的时候要找对架构起始偏移

从下面的Mach-O头信息可知,我们需要将dump出的文件写回70041600 + 16384 =70057984的位置

LLDB解密(砸壳)
架构起始偏移

Patch操作如下(过程会有点久,耐心等待):

LLDB解密(砸壳)

到这一步,原可执行文件的arm64架构文件已经解密,最后修改一下对应的加密标识cryptID即可。

提取arm64架构的文件

lipo -thin arm64 WeChat -output /Users/kinken_yuen/Desktop/WeChat_arm64

使用Mach-OView修改字段

LLDB解密(砸壳)
修改加密标识字段

最后使用class-dump能够正常dump出工程的类头文件,砸壳成功。

四、脚本调用LLDB砸壳

Github:https://github.com/BlueCocoa/dumpdecrypted-lldb

LLDB解密(砸壳)
python脚本dump

参考

使用lldb砸壳

frida-ios-dump砸壳

一、越狱设备端配置

  • 安装frida
    cydia添加源:http://build.frida.re/
frida-ios-dump砸壳
安装Frida

二、Mac端配置frida

  • Mac安装frida

pip install frida-tools

PS:有可能Mac没有安装pip

sudo easy_install pip

  • 克隆frida-ios-dump并且安装依赖

git clone https://github.com/AloneMonkey/frida-ios-dump.git
sudo pip install -r requirements.txt --upgrade(需要Python2.7,Python3请检出3.x分支,github README.md有说明)

配置过程可能出现异常:

frida-ios-dump砸壳
sudo pip install -r requirements.txt –upgrade提示异常

使用sudo -H pip install -r requirements.txt --upgrade解决

  • 使用usbmuxd做端口转发

iproxy 2222 22

  • 列出Display name(应用名称)

frida-ps -U

frida-ios-dump砸壳
target:微信

三、dump出脱壳的ipa

./dump.py 微信

参数用Display name或者Bundle ID都行

PS:这一步可能会提示认证失败,原因是没有将Mac公钥传到越狱设备上,庆哥github上面也有提示。

nice~

frida-ios-dump砸壳
得到砸壳的ipa
frida-ios-dump砸壳
验证是否加密

Clutch砸壳

一、准备工作

Clutch

git clone https://github.com/KJCracks/Clutch.git

设置生成所有架构(Build Active Architecture Only – NO),Xcode编译,我遇到了编译失败,有待解决:

Clutch砸壳
Xcode编译失败

按照github README处理
终端:

killall Xcode

cp /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist ~/

sudo /usr/libexec/PlistBuddy -c "Set :DefaultProperties:CODE_SIGNING_REQUIRED NO" /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist

sudo /usr/libexec/PlistBuddy -c "Set :DefaultProperties:AD_HOC_CODE_SIGNING_ALLOWED YES" /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/SDKSettings.plist

接着到项目目录、终端:

xcodebuild clean build

会有build文件夹生成,里面有编译好的可执行的Clutch,拷贝手机端:
注意:命令采用USB ssh方式,并且做了端口转发

scp -P 2222 ./build/Clutch root@localhost:/usr/bin/Clutch

二、在手机端进行砸壳

我尝试了两次对Wechat砸壳,手机都死机了,终端提示以下:

Clutch砸壳
砸壳失败

接着我又直接在手机终端上砸,同样失败,终端闪退,手机黑屏死机,又要强制重启重新越狱…

对于失败的猜测,可能是自己编译Clutch可能架构不对,无法正确使用,那么我直接使用作者Release出来的,换了个App,成功。后续学习过程了解到,Clutch会对App内部的Framework也解密,所以可能会出错,像微信、支付宝就会出错。

Clutch砸壳
换个了App砸

再砸一次WeChat,失败!

学习对比了几个砸壳的方式,个人感觉frida-ios-dump最方便,直接在Mac端拿到解密的可执行文件。

dumpdecrypted砸壳

一、原理

动态注入可执行文件Mach-o,从内存dump出解密的内容

github : dumpdecrypted

二、编译dumpdecrypted

cd到目录 make 得到一个dumpdecrypted.dylib

PS:后面注入过程出现一个问题:

dumpdecrypted砸壳
因为没有签名dylib,注入失败

解决方案:
列出可签名证书

security find-identity -v -p codesigning

为dumpecrypted.dylib签名

codesign --force --verify --verbose --sign "iPhone Developer: xxx xxxx (xxxxxxxxxx)" dumpdecrypted.dylib

三、砸壳(解密)

1.定位目标应用的可执行文件

手机退出其他应用,只打开目标应用(以微信为例),电脑ssh到手机,使用ps -e(ps命令需要手机安装插件adv-cmds)命令查看进程:

dumpdecrypted砸壳
定位微信进程

2.获取应用沙盒目录Documents

动态库注入解密需要写到同一目录下,而应用存在沙盒中,通过BundleID调用私有API获取Documents目录:
cat /var/containers/Bundle/Application/BE4C2082-083B-4DE4-924D-EDCA98EB1701/WeChat.app/Info.plist | grep CFBundleIdentifier -A 1

dumpdecrypted砸壳
获取bundleID

3.调用私有API获取沙盒Documents目录

新建iOS工程,在目标应用设备上运行

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    NSString *bundleID = @"com.tencent.xin";
    NSURL *dataURL = [[NSClassFromString(@"LSApplicationProxy") performSelector:@selector(applicationProxyForIdentifier:) withObject:bundleID] performSelector:@selector(dataContainerURL)];
    NSLog(@"%@",[dataURL.absoluteString stringByAppendingString:@"/Documents"]);
    return YES;
}

控制台输出:
2018-11-08 23:13:26.751557 decrypt[623:18364] file:///private/var/mobile/Containers/Data/Application/02A7FF42-8A6B-45BA-8C25-99760F0311C7/Documents
对应Documents目录:
/var/mobile/Containers/Data/Application/02A7FF42-8A6B-45BA-8C25-99760F0311C7/Documents

4.复制dylib到Documents目录并进行解密

  • 在dumpdecrypted.dylib目录下打开终端,复制dylib使用以下命令(自行修改不同参数):
    scp ./dumpdecrypted.dylib root@192.168.10.170:/var/mobile/Containers/Data/Application/02A7FF42-8A6B-45BA-8C25-99760F0311C7/Documents

  • ssh到手机端解密
    1.cd /var/mobile/Containers/Data/Application/02A7FF42-8A6B-45BA-8C25-99760F0311C7/Documents
    2.DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /var/containers/Bundle/Application/BE4C2082-083B-4DE4-924D-EDCA98EB1701/WeChat.app/WeChat

    dumpdecrypted砸壳
    dump出解密文件
  • 解密文件就在Documents目录,拷贝出来玩耍吧
    Mac端:
    scp root@192.168.10.170:/var/mobile/Containers/Data/Application/02A7FF42-8A6B-45BA-8C25-99760F0311C7/Documents/WeChat.decrypted ~/desktop

  • 查看解密文件

    dumpdecrypted砸壳
    cryptid为0表示未加密

上述操作比较原始,后面会有更快的砸壳方法,庆哥的改版dumpdecrypted(试过一遍没搞懂),庆哥推荐使用 frida-ios-dump,传送门:使用frida-ios-dump快速通过越狱设备砸壳