Detect if Cycript/Substrate or gdb is attached to an iOS app's process?

Question

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.

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.

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?

EDIT: 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).

Answer 1

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).

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.

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.

Answer 2

Based on @petesh's answer, I found the below code achieved what I wanted on a jailbroken phone with Cycript. The existence of printf strings is gold to a reverse engineer, so this code is only suitable for demo / crack-me apps.

#include <stdio.h>
#include <string.h>
#include <mach-o/dyld.h>

int main ()
{
        int max = _dyld_image_count();
        for (int i = 0; i < max; i++) {
            const char *name = _dyld_get_image_name(i);
            const char needle[11] = "libcycript";
            char *ret;

            if ((ret = strstr(name, needle)) != NULL){
                printf("%s\nThe substring is: %s\n", name, ret);
            }
        }

    return 0;
}

Answer 3

As far as I know, Cycript process injection is made possible by debug symbols. So, if you strip out debug symbols for the App Store release (the default build setting for the Release configuration), that would help.

Another action you could take, which would have no impact on the usability of the App, would be to use an obfuscator. However, this would render any crash reports useless, since you wouldn't be able to make sense of the symbols, even if the crash report was symbolicated.