https://kiperz.dev/tags/jni/ Recent content in JNI on kiperZ Hugo -- 0.147.7 en Tue, 14 Jul 2026 00:00:00 +0000 https://kiperz.dev/writeups/3-2-1-0-click-2/ Tue, 14 Jul 2026 00:00:00 +0000 https://kiperz.dev/writeups/3-2-1-0-click-2/ <blockquote> <p>CTF Shutlock 2026 · pwn Android</p></blockquote> <p>Part 1 gave us 0-click native code execution, but under the app&rsquo;s uid (<code>ctf.shutlock.csms</code>). That was enough for <code>flag1</code>. Not for <code>flag2</code>, which belongs to <code>system</code>: no <code>open()</code> will read it, whatever native code we run. We need to <strong>borrow someone else&rsquo;s rights</strong>.</p> <p>Goal: read <code>/data/vendor/flag2.txt</code> (<code>-r-------- system system</code>) remotely.</p> <h2 id="tldr">TL;DR</h2> <p>RCE in the app != reading everything: <code>flag2</code> is protected by DAC (uid <code>system</code>). We pivot through a broken <strong>vendor</strong> <code>ContentProvider</code> (<code>SNotesProvider</code>): a path traversal (<code>content://ctf.shutlock.snotes.provider/../flag2.txt</code>) makes it read the file with its <code>system</code> rights, a <em>confused deputy</em>. Since a provider <code>query()</code> is a <strong>Java/Binder</strong> operation (not a syscall) and seccomp blocks the <code>execve</code> shortcut, we <strong>rebuild a <code>JNIEnv</code> from raw shellcode</strong> (resolving <code>JNI_GetCreatedJavaVMs</code> via <code>/proc/self/maps</code>, then <code>GetEnv</code>) and replay <code>ContentResolver.query()</code> in JNI. Payload too big for part 1&rsquo;s groom: we deliver it in two stages. Content XORed with a key hardcoded in the APK, decoded attacker-side.</p>