SingPass RASP Analysis

I started to dig into the SingPass application which turned out to be obfuscated and protected with Runtime Application Self-Protection (RASP).

Retrospectively, this application is pretty interesting to analyze RASP functionalities since:

By grepping some keywords in the install directory of the application, we actually get two results which reveal the name of the obfuscator:

The NuDetectSDK binary also uses the same obfuscator but it does not seem involved in the early jailbreak detection shown in the previous figure. On the other hand, SingPass is the main binary of the application and we can observe strings related to threat detections:

Unfortunately, the binary does not leak other strings that could help to identify where and how the application detects jailbroken devices but fortunately, the application does not crash …

If we assume that the obfuscator decrypts strings at runtime, we can try to dump the content of the __data section when the error message is displayed. At this point of the execution, the strings used for detecting jailbroken devices are likely decoded and clearly present in the memory.

Once the data section is dumped, we end up with the following changes in some parts of the __data section:

Fig 1. Slices of the __data section before and after the dump

In addition, we can observe the following strings which seem to be related to the RASP functionalities of the obfuscator:

Fig 2. Strings Related to the RASP Features

All the EVT_* strings are referenced by one and only one function that I named on_rasp_detection. This function turns out to be the threat detection callback used by the app’s developers to perform action(s) when a RASP event is triggered.

To better understand the logic of the checks behind these strings, let’s start with EVT_CODE_PROLOGUE which is used to detect hooked functions.

While going through the assembly code closes to the cross-references of on_rasp_detection, we can spot several times this pattern:

To detect if a given function is hooked, the obfuscator loads the first byte of the function and compares this byte with the value 0xFF. 0xFF might seem – at first glance – arbitrary but it’s not. Actually, regular functions start with a prologue that allocates space on stack for saving registers defined by the calling convention and stack variables required by the function. In AArch64, this allocation can be performed in two ways:

These instructions are not equivalent, but somehow and with the good offsets, they could lead to the same result. In the second case, the instruction sub SP, SP, #CST is encoded with the following bytes:

As we can see, the encoding of this instruction starts with 0xFF. If it is not the case, then either the function starts with a different stack-allocation prologue or potentially starts with a hooking trampoline. Since the code of the application is compiled through obfuscator’s compiler, the compiler is able to distinguish these two cases and insert the right check for the correct function’s prologue.

If the first byte of the instruction of the function does not pass the check, it jumps to the red basic block. The purpose of this basic block is to trigger a user-defined callback that will process the detection according to the application’s design and the developers’ choices:

From the previous figure, we can observe that the detection callback is loaded from a static variable located at #hook_detect_cbk_ptr. When calling this detection callback, the obfuscator provides the following information to the callback:

Let’s now take a closer look at the design of the detection callback(s) as a whole.

As explained in the previous section, when the obfuscator detects tampering, it reacts by calling a detection callback stored in the static variable at the address: 0x10109D760

By statically analyzing hook_detect_cbk, the implementation seems to corrupt the pointer provided in the callback’s parameters. On the other hand, when running the application we observe a jailbreak detection message and not a crash of the application.

If we look at the cross-references which read or write at this address, we get this list of instructions:

So actually only one instruction – init_and_check_rasp+01BC – is overwriting the default detection callback with another function:

Compared to the default callback: hook_detect_cbk, the overridden function, hook_detect_cbk_user_def does not corrupt a pointer that would make the application crash. Instead, it calls the function on_rasp_detection which references all the strings EVT_CODE_TRACING, EVT_CODE_SYSTEM_LIB, etc, listed in the figure 2.

By looking at the function init_and_check_rasp as a whole, we can notice that the X23 register is also used to initialize other static variables:

Fig 3. X23 Writes Instructions

These memory writes mean that the callback hook_detect_cbk_user_def is used to initialize other static variables. In particular, these other static variables are likely used for the other RASP checks. By looking at the cross-references of these static variables #EVT_CODE_TRACING_cbk_ptr, #EVT_ENV_JAILBREAK_cbk_ptr etc, we can locate where the other RASP checks are performed and under which conditions they are triggered.

Thanks to the #EVT_* cross-references, we can go statically through all the basic blocks that use these #EVT_* variables and highlight the underlying checks that could trigger the RASP callback(s). Before detailing the checks, it is worth mentioning the following points:

The version of the obfuscator used by SingPass implements two kinds of debug check. First, it checks if the parent process id (ppid) is the same as /sbin/launchd which should be 1.

If it is not the case, it triggers the EVT_ENV_DEBUGGER event. The second check is based on sysctl which is used to access the extern_proc.p_flag value. If this flag contains the P_TRACED value, the RASP routine triggers the EVT_ENV_DEBUGGER event.

In the SingPass binary, we can find an instance of these two checks in the following ranges of addresses:

As for most of the jailbreak detections, the obfuscator tries to detect if the device is jailbroken by checking if some files exist (or not) on the device.

Files or directories are checked with syscalls or a regular functions thanks to the following helpers:

While in the introduction, I mentioned that a dump of the section __data reveals strings related to jailbreak detection, the dump does not reveal all the strings used by the obfuscator.

By looking closely at the strings encoding mechanism, it turns out that some strings are decoded just-in-time in a temporary variable. I’ll explain the strings encoding mechanism in the second part of this series of blog posts but at this point, we can uncover the strings by setting hooks on functions like fopen, utimes and dumping the __data section right after these calls. Then, we can iterate over the different dumps to see if new strings appear.

In the end, the approach does not enable to have all the strings decoded but it enables to have a good coverage. The list of the files used for detecting jailbreak is given the Annexes.

There is also a particular check for detecting the unc0ver jailbreak which consists in trying to unmount /.installed_unc0ver:

The obfuscator also checks environment variables that trigger the EVT_ENV_JAILBREAK event. Some of these checks seem to be related to code lifting detection while still triggering the EVT_ENV_JAILBREAK event.

In addition to regular checks, the obfuscator performs advanced checks like verifying the current status of the SIP (System Integrity Protection), and more precisely, the KEXTS code signing status.

The obfuscator also uses the Sandbox API to verify if some paths exist:

The paths checked through this API are OSX-related directories, so I guess it is also used to verify that the current code has not been lifted on an Apple Silicon. Here is, for instance, a list of directories checked with the Sandbox API:

In addition, it uses the Sandbox attribute file-read-metadata as an alternative to the stat() function.

The application uses the sandbox API through private syscalls to determine whether some jailbreak artifacts exists. This is very smart but I guess it’s not really compliant with the Apple policy.

The purpose of this check is to verify that the addresses of the resolved imports point to the right library. In other words, this check verifies that the import table is not tampered with pointers that could be used to hook imported functions.

During the RASP checks initialization (sub_100E544E8), the obfuscator manually resolves the imported functions. This manual resolution is performed by iterating over the symbols in the SingPass binary, checking the library that imports the symbol, accessing (in-memory) the __LINKEDIT segment of this library, parsing the exports trie, etc. This manual resolution fills a table that contains the absolute address of the resolved symbols.

In addition, the initialization routine setups – what I called – a metadata structure that follows this layout:

symbols_index is a kind of translation table that converts an index known by the obfuscator into an index in the __got or the __la_symbol_ptr section. The index’s origin (i.e __got or __la_symbol_ptr) is determined by the origins table which contains enum-like integers:

The length of both tables: symbols_index and origins, is defined by the static variable nb_symbols which is set to 0x399. The metadata structure is followed by two pointers: resolved_la_syms and resolved_got_syms which point to the imports address table manually filled by the obfuscator.

Then, macho_la_syms points to the beginning of the __la_symbol_ptr section while macho_got_syms points to the __got section.

Finally, stub_helper_start / stub_helper_end holds the memory range of the __stub_helper section. I’ll describe the purpose of these values later.

All the values of this metadata structure are set during the initialization which takes place in the function sub_100E544E8.

In different places of the SingPass binary, the obfuscator uses this metadata information to verify the integrity of the resolved import(s). It starts by accessing the symbols_index and the origins with a fixed value:

In other words, we have the following operations:

Then, given the sym_idx value and depending on the origin of the symbol, the function accesses either the resolved __got table or the resolved __la_symbol_ptr table. This access is done with a helper function located at sub_100ED6CC0. It can be summed up with the following pseudo-code:

The entries at the index sym_idx of section_ptr and manually_resolved are compared and if they don’t match, the event #EVT_CODE_SYMBOL_TABLE is triggered.

Actually, the comparison covers different cases. First, the obfuscator handles the case where the symbol at sym_idx is not yet resolved. In that case, section_ptr[sym_idx] points to the symbols resolution stub located in the section __stub_helper. That’s why the metadata structure contains the memory range of this section:

In addition, if the pointers do not match, the function verifies their location using dladdr:

In the case where the origin[sym_idx] is set to SYM_ORIGINS::NONE the function skips the check. Thus, we can simply disable this RASP check by filling the original table with 0. The number of symbols is close to the metadata structure and the address of the metadata structure is leaked by the ___atomic_load and ___atomic_store functions.

The Code Tracing check aims to verify that the current is not traced. By looking at the cross-references of #EVT_CODE_TRACING_cbk_ptr, we can identify two kinds of verification.

EVT_CODE_TRACING seems able to detect if the Frida’s Stalker is running. It’s the first time I can observe this kind of check and it’s very smart. For those who would like to follow this analysis with the raw assembly code, I will use this range of addresses from the SingPass binary:

Here is the graph of the function that performs the Frida Stalker check:

Code associated with Frida Stalker Detection

Yes, this code is able to detect the Stalker. How? Let’s start with the first basic block. _pthread_mach_thread_np(_pthread_self()) aims at getting the thread id of the function that invokes this check.

Then more subtly, MRS(TPIDRRO_EL0) & #-8 is used to manually access the thread local storage area. On ARM64, Apple uses the least significant byte of TPIDRRO_EL0 to store the number of CPU while the MSB contains the TLS base address.

Then, the second basic block – which is the loop’s entry – accesses the thread local variable with the key tlv_idx which ranges from 0x100 to 0x200 in the loop:

The following basic block which calls _vm_region_64(…) is used to verify that the tlv_addr variable contains a valid address with a correct size (i.e. larger than 0x30). Under these conditions, it jumps into the following basic block with these strange memory accesses:

Condition that (somehow) Triggers EVT_CODE_TRACING

To figure out the meaning of these memory accesses, let’s remind that this function is associated with the EVT_CODE_TRACING event. Which well-known public tool could be associated with code tracing? Without too much risk, we can assume the Frida’s Stalker.

If we look at the implementation of the Stalker, we can notice this kind of initialisation (in gumstalker-arm64.c):

So the Stalker creates a thread local variable that is used to store a pointer to the GumExecCtx structure which has the following layout:

If we add the offsets of this layout and if we virtually inline the GumArm64Writer structure, we can get this representation:

With this representation, we can observe that:

GumOS and GumPtrauthSupport are enums defined in gumdefs.h and gummemory.h with these values:

GumOS contains 6 entries starting from GUM_OS_WINDOWS = 0 up to GUM_OS_QNX = 5 and similarly, GUM_PTRAUTH_INVALID = 0 while the last entry is associated with GUM_PTRAUTH_SUPPORTED = 2

Therefore, the previous strange conditions are used to fingerprint the GumExecCtx structure:

One way to prevent this Stalker detection would be to recompile Frida with swapped fields in the _GumExecCtx structure.

An alternative to the previous Frida stalker check consists in accessing the current thread status through the following call:

Then, it checks if state->ts_64.__pc is within the libsystem_kernel.dylib thanks to the following comparison:

In other words, state->ts_64.__pc is considered to be in libsystem_kernel.dylib, if its distance from &mach_msg is smaller than 0x4000.

At first sight, I was a bit confused by this RASP check but since the previous checks, associated with EVT_CODE_TRACING, aims at detecting the Frida Stalker, this check is also likely designed to detect the Frida Stalker.

To confirm this hypothesis, I developed a small test case that reproduces this check, in a standalone binary and we can observe a difference depending on whether it runs through the Frida stalker or not:

Output of the Test Case with the Stalker

Output of the Test Case without the Stalker

This check can be bypassed without too much difficulty by using the function gum_stalker_exclude to exclude the library libsystem_kernel.dylib from the stalker:

As a result of this exclusion, state->ts_64.__pc is located in libsystem_kernel.dylib:

Output of the Test Case with Excluded Memory Ranges

The RASP event EVT_APP_LOADED_LIBRARIES aims at checking the integrity of the Mach-O’s dependencies. In other words, it checks that the Mach-O imported libraries have not been altered.

The code associated with this check starts by accessing the Mach-O header thanks to the dladdr function:

Dl_info contains the base address of the library which encompasses the address provided in the first parameter and since, a Mach-O binary is loaded with its header, dl_info.dli_fbase actually points to a mach_header_64.

Then the function iterates over the LC_ID_DYLIB-like commands to access dependency’s name:

This name contains the path to the dependency. For instance, we can access this list as follows:

The dependency’s names are used to fill a hash table in which a hash value in encoded on 32 bits:

Later in the the code, this computed table is compared with another hash table – hard-coded in the code – which looks like this:

Fig 4. Examples of Hashes

If some libraries have been modified to inject, for instance, FridaGadget.dylib then the hash dynamically computed will not match the hash hard-coded in the code.

Whilst the implementation of this check is pretty “standard”, there are a few points worth mentioning:

This check is associated with the event EVT_CODE_SYSTEM_LIB which consists in verifying the integrity of the in-memory system libraries with their content in the dyld shared cache (on-disk).

This check usually starts with the following pattern:

If the result of iterate_system_region with the given check_region_cbk callback is not 0, it triggers the EVT_CODE_SYSTEM_LIB event:

To understand the logic behind this check, we need to understand the purpose of the iterate_system_region function and its relationship with the callback check_region_cbk.

This function aims to call the system function vm_region_recurse_64 and then, filter its output on conditions that could trigger the callback given in the first parameter: check_region_cbk.

iterate_system_region starts by accessing the base address of the dyld shared cache thanks to the SYS_shared_region_check_np syscall. This address is used to read and memoize a few attributes from the dyld_cache_header structure:

The following snippet gives an overview of these computations:

Following this memoization, there is a loop on vm_region_recurse_64 which queries the vm_region_submap_info_64 information for these addresses in the range of the dyld shared cache. We can identify the type of the query (vm_region_submap_info_64) thanks to the mach_msg_type_number_t *infoCnt argument which is set to 19:

This loop breaks under certain conditions and the callback is triggered with other conditions. As it is explained a bit later, the callback verifies the in-memory integrity of the library present in the dyld shared cache.

The verification and the logic behind this check is prone to take time, that’s why the authors of the check took care of filtering the addresses to check to avoid useless (heavy) computations.

Basically, the callback that performs the in-depth inspection of the shared cache is triggered if:

When the conditions are met, iterate_system_region calls the check_region_cbk with the suspicious address in the first parameter:

During the analysis of SingPass, only one callback is used in pair with iterate_system_region, and its code is not especially obfuscated (except the strings). Once we know that the checks are related to the dyld shared cache, we can quite easily figure out the structures involved in this function. This callback is located at the address 0x100ed5e0c and renamed check_region_cbk.

Firstly, it starts by accessing the information about the address:

This information is used to read the content of the __TEXT segment associated with the address parameter:

On the other hand, the function opens the dyld_shared_cache and looks for the section of the shared cache that contains the library associated with the address parameter:

The purpose of the second call to mmap() is to load the slice of the shared cache that contains the code of the library. Then, the function checks byte per byte that the __TEXT segment’s content matches the in-memory content. The loop which performs this comparison is located between these addresses: 0x100ED6C58 - 0x100ED6C70.

As we can observe from the description of this RASP check, the authors paid a lot of attention to avoid performance issues and memory overhead. On the other hand, the callback check_region_cbk was never called during my experimentations (even when I hooked system function). I don’t know if it’s because I misunderstood the conditions but in the end, I had to manually force the conditions (by forcing the pages_swapped_out to 1).

Thanks to the different #EVT_* static variables that hold function pointers, the obfuscator enables to have dedicated callbacks for the supported RASP events. Nevertheless, the function init_and_check_rasp defined by the application’s developers setup all these pointers to the same callback: hook_detect_cbk_user_def. In such a design, all the RASP events end up in a single function which weakens the strength of the different RASP checks.

It means that we only have to target this function to disable or bypass the RASP checks.

Using Frida Gum, the bypass is as simple as using gum_interceptor_replace with an empty function:

Thanks to this weakness, I could prevent the error message from being displayed as soon as the application starts.

SingPass Jailbreak & RASP Bypass

This first part is a good example of the challenges when using or designing an obfuscator with RASP features. On one hand, the commercial solution implements strong and advanced RASP functionalities with, for instance, inlined syscalls spread in different places of the application. On the other hand, the app’s developers weakened the RASP functionalities by setting the same callback for all the events. In addition, it seems that the application does not use the native code obfuscation provided by the commercial solution which makes the RASP checks un-protected against static code analysis. It could be worth to enforce code obfuscation on these checks regardless the configuration provided by the user.

From a developer point of view, it can be very difficult to understand the impact in term of reverse-engineering when choosing to setup the same callback while it can be a good design decision from an architecture perspective.

In the second part of this series about iOS code obfuscation, we will dig a bit more in native code obfuscation through another application, where the application reacts differently to the RASP events and where the code is obfuscated with MBA, Control-Flow Flattening, etc.

If you have questions feel free to ping me 📫.

Annexes

Flagged Packages