0x01 Hello Buffer Overflow

· 3 min read

Firstly let’s connect to the device, write some simple (vulnerable) C code, compile and run it leading to buffer overflow. I’ll be writing, compiling and debugging on device. So this example is about basic buffer overflow vulnerability, let’s do it 😉

0x01.c

So let’s create new file, name it 0x01.c, with content like so:

#include <stdio.h>
#include <string.h>

int main() {
    printf("0x01 Hello Buffer Overflow); 
    printf("enter some data:\n");

    char buffer[12];
    scanf("%s", buffer);
    printf("You entered: %s\n", buffer);

    return 0;
}

Compile it with clang, command should be crafted like this (some extra flags will be explained later):

$ clang 0x01.c -isysroot /var/root/theos/sdks/iPhoneOS10.3.sdk/ -fno-stack-protector -fno-pie -arch armv7 -mios-version-min=6 -o 0x01

If you run your app now, you should probably get following error:

$ ./hello 
Killed: 9

The reason for this is that this binary is not signed yet so could not be run on our device. So we should also sign our app with ldid:

$ ldid -S 0x01

And then we can run the app without the killed: 9 error.

Let’s analyse

So let’s take a look what this app does and how can we exploit it. When we run it normally, this app prints some info and waits for user input to read it and print.

$ ./0x01 
0x01 Hello Buffer Overflow
enter some data:
12345
You entered: 12345

So far so good. Program works as expected, until the data provided doesn’t exceed declared buffer (12 bytes). So let’s enter more data than program excepcts

$ ./0x01 
0x01 Hello Buffer Overflow
enter some data:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
You entered: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault: 11

And we get segmentation fault error. This error means that our program has attempted to access a restricted area of memory. So we made our app crash, now let’s find and take a look at crash report.

Crash reports

Crash reports in iOS are located in /var/mobile/Library/Logs/CrashReporter/. Every crash should be logged here in .ips files with app name. Example content of this file is listed below.

$ cat /var/mobile/Library/Logs/CrashReporter/0x01-2020-09-03-210304.ips 

{"app_name":"0x01","share_with_app_devs":false,"name":"0x01","app_version":"","is_first_party":true,"os_version":"iPhone OS 9.3.6 (13G37)","slice_uuid":"9197cc5f-322f-3f7e-9cfa-6837096df923","bug_type":"109","build_version":"","timestamp":"2020-08-03 21:03:04.04 +0100"}
Incident Identifier: A08EE28B-CED3-4AA0-BABF-710D96040F6B
CrashReporter Key:   de13734ab18978452a2bbd324f04da651f9baae6
Hardware Model:      iPhone4,1
Process:             0x01 [1110]
Path:                /private/var/root/dev/0x01
Identifier:          0x01
Version:             ???
Code Type:           ARM (Native)
Parent Process:      sh [1094]

Date/Time:           2020-08-03 21:03:04.04 +0100
Launch Time:         2020-08-03 21:03:02.02 +0100
OS Version:          iOS 9.3.6 (13G37)
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x41414140
Triggered by Thread:  0

Filtered syslog:
None found

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   ???                           	0x41414140 0 + 1094795584

Thread 0 crashed with ARM Thread State (32-bit):
    r0: 0x00000000    r1: 0x00000000      r2: 0x00000400      r3: 0x00000040
    r4: 0x00000000    r5: 0x0000bef8      r6: 0x00000000      r7: 0x41414141
    r8: 0x00110da4    r9: 0x3b834278     r10: 0x00000000     r11: 0x00000000
    ip: 0x00012868    sp: 0x00110d90      lr: 0x0000bf64      pc: 0x41414140
  cpsr: 0x40000030

...

Taka a closer look at the registers address in Thread 0 crashed with ARM Thread State (32-bit) block, and pc (program counter) value. pc value indicates what address our program tried to access when got crashed. We will take advantage of this information in further tests.