是否检测Cycript/Substrate或gdb是否已附加到iOS应用程序的进程? [英] Detect if Cycript/Substrate or gdb is attached to an iOS app's process?

问题描述

我正在构建一个iOS应用程序，该程序将敏感数据传输到我的服务器，并且正在对我的API请求进行签名，以作为一项额外措施.我想使逆向工程尽可能地困难，并且使用Cycript查找一些实际应用程序的签名密钥，我知道通过附加到进程中来找到这些密钥并不难.我绝对知道，如果有人真的很熟练并且尝试足够努力，他们最终会会利用，但是我正在努力使之尽可能地艰辛，同时仍然为我自己和用户提供方便.

I am building an iOS app that transmits sensitive data to my server, and I'm signing my API requests as an additional measure. I want to make reverse engineering as hard as possible, and having used Cycript to find signing keys of some real-world apps, I know it's not hard to find these keys by attaching to a process. I am absolutely aware that if someone is really skilled and tries hard enough, they eventually will exploit, but I'm trying to make it as hard as possible, while still being convenient for myself and users.

我可以检查越狱状态并采取其他措施，或者可以进行SSL固定，但是通过附加到进程并修改内存，仍然很容易绕过两者.

I can check for jailbroken status and take additional measures, or I can do SSL pinning, but both are still easy to bypass by attaching to the process and modifying the memory.

是否有任何方法可以检测到某物(无论是Cycript，gdb还是可用于破解该过程的任何类似工具)是否已附加到该过程中，而没有被拒绝App Store?

Is there any way to detect if something (whether it be Cycript, gdb, or any similar tool that can be used for cracking the process) is attached to the process, while not being rejected from App Store?

编辑:这不是

This is not a duplicate of Detecting if iOS app is run in debugger. That question is more related to outputting and it checks an output stream to identify if there's an output stream attached to a logger, while my question is not related to that (and that check doesn't cover my condition).

推荐答案

gdb检测可行

gdb detection is doable via the linked stackoverflow question - it uses the kstat to determine if the process is being debugged. This will detect if a debugger is currently attached to the process.

还有一段代码-

There is also a piece of code - Using the Macro SEC_IS_BEING_DEBUGGED_RETURN_NIL in iOS app - which allows you to throw in a macro that performs the debugger attached check in a variety of locations in your code (it's C/Objective-C).

对于检测Cycript，当它针对某个进程运行时，它将dylib注入该进程中以处理cycript命令行与该进程之间的通信-库的名称部分类似于cynject.该名称看起来与典型的iOS应用程序中存在的任何库都不相似.这应该可以通过类似(C)的小循环来检测到:

As for detecting Cycript, when it is run against a process, it injects a dylib into the process to deal with communications between the cycript command line and the process - the library has part of the name looking like cynject. That name doesn't look similar to any libraries that are present on a typical iOS app. This should be detectable with a little loop like (C):

BOOL hasCynject() {
    int max = _dyld_image_count();
    for (int i = 0; i < max; i++) {
        const char *name = _dyld_get_image_name(i);
        if (name != NULL) {
            if (strstr(name, "cynject") == 0) return YES;
        }
    }
}

同样，给它一个比这更好的名称是明智的，同时还要混淆正在测试的字符串.

Again, giving it a better name than this would be advisable, as well as obfuscating the string that you're testing.

这些只是可以采取的方法-不幸的是，这些方法只能在运行时以某种方式保护您，如果有人选择将IDA或其他反汇编程序指向它，那么您将不会受到保护.

These are only approaches that can be taken - unfortunately these would only protect you in some ways at run-time, if someone chooses to point IDA or some other disassembler at it then you would not be protected.

将调试器检查实现为宏的原因是，您会将代码放置在代码中的各个位置，结果有人试图对其进行修复，则必须对应用程序进行各种修补.的地方.

The reason that the check for debugger is implemented as a macro is that you would be placing the code in a variety of places in the code, and as a result someone trying to fix it would have to patch the app in a variety of places.

这篇关于是否检测Cycript/Substrate或gdb是否已附加到iOS应用程序的进程?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！