iOS Anti-Debugging Protections #1

Many iOS applications use anti-debugging techniques to prevent malicious users from using a debugger to analyze or modify their behavior. In this first part of the iOS anti-debugging series I will describe one of the most commonly used anti-debugging techniques in iOS nowadays and provide ways to bypass it.

Using ptrace with PT_DENY_ATTACH

Ptrace is a system call that is primarily used to trace and debug applications. The ptrace call is defined as:

int ptrace(int request, pid_t pid, caddr_t addr, int data);

The first argument (request) specifies the operation to perform. All valid operations are defined in /usr/include/sys/ptrace.h. One of the operations is called PT_DENY_ATTACH and has the value 31. When the request is set to that value the application informs the operating system that it doesn’t want to be traced or debugged. Any attempts to trace the process will be denied and the application will receive a segmentation violation.

The following block of code contains an example C program that uses the ptrace call to prevent GDB from debugging it. Currently, GDB is the only debugger that works on iOS devices. The following paragraphs contain an analysis of the protection as well as ways to bypass it.

int main(int argc, char **argv)
{
    ptrace(PT_DENY_ATTACH, 0, 0, 0);
    printf("Try to attach to me!");
    while (1)
    {
        sleep(1);
        printf(".");
        fflush(stdout);
    }
    return 0;
}

The call to activate the protection is on line 3:

ptrace(PT_DENY_ATTACH, 0, 0, 0);

When the request is set to PT_DENY_ATTACH all other arguments aren’t used and set to zero.

First, let’s examine the effects of this protection. We will run the application in one terminal and try to attach using GDB in another:

tl0gic:~ mobile$ ./ptrace
Try to attach to me!........

Now we try to attach with GDB:

tl0gic:~ mobile$ ps ax | grep ptrace
2761 s000 S+ 0:00.05 ./ptrace
2774 s001 R+ 0:00.01 grep ptrace
tl0gic:~ mobile$ gdb -p 2761
/private/var/mobile/2761: No such file or directory
Attaching to process 2761.
Segmentation fault: 11
tl0gic:~ mobile$

As you can see GDB terminated with a segmentation fault.

Next, let’s try to start the application from GDB:

tl0gic:~ mobile$ gdb ./ptrace
Reading symbols for shared libraries . done
(gdb) run
Starting program: /private/var/mobile/ptrace
Reading symbols for shared libraries ...................... done
 
Program exited with code 055.
(gdb)

The application was terminated with exit code 055.

Bypassing ptrace

In the following paragraphs we will describe two different ways to bypass the ptrace protection. In the first, we will modify the arguments of ptrace to invalidate the call, and in the second we will do a memory patch to replace the ptrace call with NOP instructions.

Method 1 – modifying the arguments to ptrace

First, start GDB with the process we want to debug:

$ gdb ./ptrace
Then, setup a breakpoint on ptrace:
(gdb) break ptrace
Function "ptrace" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
 
Breakpoint 1 (ptrace) pending.

Note that GDB complains that ptrace isn’t defined. This is normal just select“”y” as the answer. The next step is to start the process. It will take some time for GDB to load all the symbols. At the end it will notify us that it resolved the ptrace symbol and was able to setup the breakpoint. Once the process is started the breakpoint is hit and we are back at the GDB prompt.

Starting program: /private/var/mobile/ptrace
Reading symbols for shared libraries ...................... done
Breakpoint 1 at 0x30e6f3a8
Pending breakpoint 1 - "ptrace" resolved
 
Breakpoint 1, 0x30e6f3a8 in ptrace ()
(gdb)

Let’s examine the registers. On ARM CPUs the first four registers (r0 to r3) contain the first four arguments to a function call. Since ptrace accepts exactly four arguments we can just print the first four registers to examine the contents of the arguments.

(gdb) info registers r0 r1 r2 r3
r0 0x1f 31
r1 0x0 0
r2 0x0 0
r3 0x0 0

As you can see, r0 contains the number 31, which is the value of PT_DENY_ATTACH. The other registers are all set to zero. As we discussed above when ptrace is invoked with the request set to PT_DENY_ATTACH all other arguments aren’t used so they are set to zero.

At this point we will replace the first argument with an invalid value. Ptrace will try to execute the invalid request and return an error instead. Most applications don’t really check the return value of ptrace for errors and therefore we can get away with it.

(gdb) set $r0=-1
(gdb) continue
Continuing.
Try to attach to me!.....

As you can see the application is running with GDB attached ☺

Method 2 - memory patch

The second way is to do a memory patch when the application is running and remove the call to ptrace completely. We will use otool to disassemble the binary and find the address we need to patch. Then, we will load the application in GDB and patch it.

Lets start by disassembling the application and locating the call to ptrace:

$ otool -tV ./ptrace
 
00002f20 4610 cpy r0, r2
00002f22 4619 cpy r1, r3
00002f24 461a cpy r2, r3
00002f26 e868f000 blx 0x2ff8 ; symbol stub for: _ptrace
00002f2a 019ef240 blx 0x243268
00002f2e 0100f2c0 blx 0x2c3130
00002f32 4479 add r1, pc

From the disassembly above we can see that the call to ptrace in this binary happens at address 0x2f26 (instruction “blx 0x2ff8”). Also, the opcode is 4 bytes long. Therefore, to completely remove the call we need to replace 4 bytes at address 0x2f26 with one or more instructions that don’t do anything (NOP). There are several opcodes for NOP instructions in ARM, in this patch we will use 0xbf00.

First, we will load the application in GDB and examine the disassembly of address 0x2f26 (where the call to ptrace is):

tl0gic:~ mobile$ gdb ./ptrace
Reading symbols for shared libraries . done
(gdb) x/5i 0x2f26
0x2f26 : blx 0x2ff8
0x2f2a : movw r1, #158 ; 0x9e
0x2f2e : movt r1, #0 ; 0x0
0x2f32 : add r1, pc
0x2f34 : str r0, [sp, #16]

Then, we will setup a breakpoint in main() and start our application. We need to do that because GDB doesn’t have write access to the process’ memory unless the application is running.

(gdb) b main
Breakpoint 1 at 0x2f0e
(gdb) run
Starting program: /private/var/mobile/ptrace
Reading symbols for shared libraries ...................... done
 
Breakpoint 1, 0x00002f0e in main ()

Now that the breakpoint is hit we are back in GDB and we can perform the memory patch:

(gdb) set *(long *)0x2f26 = 0xbf00bf00

Note that we are casting the address 0x2f26 to a type of long so that GDB knows how many bytes to write at the address. In this case we know that the call to ptrace is 4 bytes long so we are using a long type which is also 4 bytes. Note that the value we are writing is 0xbf00bf00 and contains two NOPs. We need to use two NOPs because each NOP is two bytes. After we execute the command we will examine the disassembly one more time to verify that we patched the application properly:

(gdb) x/5i 0x2f26
0x2f26 : nop
0x2f28 : nop
0x2f2a : movw r1, #158 ; 0x9e
0x2f2e : movt r1, #0 ; 0x0
0x2f32 : add r1, pc
(gdb) continue
Continuing.
Try to attach to me!.........

As you can see the instruction at address 0x2f26 is a NOP instruction and is followed by another NOP instruction. The call to ptrace is completely gone. We can now use the GDB command “continue” to continue execution.