Shutlock 2026 on kiperZ

3, 2, 1... 0-click (1/3) - Shutlock 2026

Tue, 14 Jul 2026 00:00:00 +0000

CTF Shutlock 2026 · pwn Android

CSMS is an Android messenger: a central server, and on the victim side (the spylock account) a client app (ctf.shutlock.csms) that fetches its new messages on its own, every 10 s, which makes the attack 0-click.

The challenge hands us plenty to work with: the app’s APK, the C source of its native layer (csms.c, csms_mem.c) and a live infra (the server and an Android emulator running the victim). Every incoming message flows through Java, pure plumbing, then into a template engine written in C (libcsms.so); that is where, inside a homemade allocator, the bug that gives us code execution hides.

3, 2, 1... 0-click (2/3) - Shutlock 2026

Tue, 14 Jul 2026 00:00:00 +0000

CTF Shutlock 2026 · pwn Android

Part 1 gave us 0-click native code execution, but under the app’s uid (ctf.shutlock.csms). That was enough for flag1. Not for flag2, which belongs to system: no open() will read it, whatever native code we run. We need to borrow someone else’s rights.

Goal: read /data/vendor/flag2.txt (-r-------- system system) remotely.

TL;DR

RCE in the app != reading everything: flag2 is protected by DAC (uid system). We pivot through a broken vendor ContentProvider (SNotesProvider): a path traversal (content://ctf.shutlock.snotes.provider/../flag2.txt) makes it read the file with its system rights, a confused deputy. Since a provider query() is a Java/Binder operation (not a syscall) and seccomp blocks the execve shortcut, we rebuild a JNIEnv from raw shellcode (resolving JNI_GetCreatedJavaVMs via /proc/self/maps, then GetEnv) and replay ContentResolver.query() in JNI. Payload too big for part 1’s groom: we deliver it in two stages. Content XORed with a key hardcoded in the APK, decoded attacker-side.

3, 2, 1... 0-click (3/3) - Shutlock 2026

Tue, 14 Jul 2026 00:00:00 +0000

CTF Shutlock 2026 · pwn Android

Parts 1 and 2 gave us 0-click native code execution, first under the app’s uid (flag1), then the ability to make a broken provider read a system file (flag2). flag3 climbs one more notch: it belongs to root, and, surprise, root isn’t even enough. The file is also SELinux-protected: under enforcing, even uid 0 takes a denial. So we need kernel code: enough to become root and neutralize the SELinux policy.