Didactic ARM32 shellcode project for studying how a keyboard configuration poisoning payload can be built, injected, and debugged in a controlled Raspbian lab.

This project demonstrates an end-to-end exploitation workflow on a 32-bit Raspbian Jessie target:

• a toy vulnerable echoing TCP server receives attacker-controlled input
• a stack-based overflow is used to redirect execution
• an ARM/Thumb shellcode overwrites /etc/default/keyboard
• the shellcode sets the immutable flag on that file with ioctl(FS_IOC_SETFLAGS, ...)

The payload currently replaces the keyboard layout with a French configuration:

XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT=""
XKBOPTIONS=""
BACKSPACE="guess"

Two assembly variants are included:

• shellcode/keyboard_poisoning.s: original shellcode with NUL bytes in the resulting blob
• shellcode/keyboard_poisoning_denull.s: de-nullified variant intended for string-copy exploitation scenarios

.
|-- shellcode/
|   |-- keyboard_poisoning.s
|   `-- keyboard_poisoning_denull.s
|-- vulnerable_program/
|   `-- vulnb.c
|-- DOCS.md
|-- exploit.py
`-- README.md

• shellcode/: ARM assembly payloads and shellcode source
• vulnerable_program/vulnb.c: intentionally unsafe TCP server listening on 0.0.0.0:4444
• exploit.py: payload builder with the overwrite padding, shellcode address, sled, and injected bytes
• DOCS.md: step-by-step lab notes for exploitation, GDB work, shellcode building, and verification

The repository is written around the following target:

• Raspbian 8 (2017-04-10-raspbian-jessie)
• 32-bit ARM
• kernel qemu-4.4.34-jessie

Reference lab setup: Azeria Labs ARM VM v1.0

Useful tooling on the target machine:

• gcc, as, ld, objcopy, hexdump
• gdb with GEF if available
• nc
• root access for the final shellcode effect and some debug flows

The vulnerable program allocates a 32-byte stack buffer and then copies network input into it with strcpy(). Because the source buffer can hold much more data, the saved frame state can be overwritten when the stack layout is favorable.

The shellcode itself performs four main actions:

1. switches from ARM mode to Thumb mode
2. opens /etc/default/keyboard with O_WRONLY | O_TRUNC
3. writes the replacement keyboard configuration
4. issues ioctl to set FS_EXTENT_FL | FS_IMMUTABLE_FL, then exits

The de-nullified version patches specific bytes at runtime so the payload can survive string-based copies such as the strcpy() used by the demo server.

Copy the complete repo using proxyjump + scp configuration, or copy file contents directly using nano.

cd vulnerable_program
gcc -fno-stack-protector -z execstack -o vulnb vulnb.c
sudo sysctl -w kernel.randomize_va_space=0
./vulnb

This starts the demo service on port 4444.

The repository already includes exploit.py with:

• the current overwrite padding
• the shellcode bytes as a ready-to-send hex dump
• a sample shellcode start address for the documented lab setup

You can use that file directly for a quick lab run:

python exploit.py | nc 127.0.0.1 4444

cat /etc/default/keyboard
lsattr /etc/default/keyboard

Expected outcome:

• the keyboard file contains the replacement configuration
• the immutable flag (i) is set on /etc/default/keyboard

To undo the immutability during cleanup:

sudo chattr -i /etc/default/keyboard

• Main walkthrough: DOCS.md
• Repository-specific instructions: AGENTS.md

Current project version: v0.1.0

Telmo Rubio - LinkedIn

MIT. See LICENSE.