Ox78 — TJCTF 2026

Description

I'm trying to test my FSOP prevention mechanism...

We are given a 64-bit PIE ELF binary (Ox78), the matching libc.so.6 (Ubuntu glibc 2.34), ld-linux-x86-64.so.2, and a Dockerfile. The remote is at nc tjc.tf 31378.

The binary has Full RELRO, PIE, NX, SHSTK, IBT — no canary, but all modern mitigations are on. With glibc 2.34, __free_hook and __malloc_hook are removed, so the only viable code-execution primitive is FSOP (File Stream Oriented Programming).

The challenge name "Ox78" is a hint: 0x78 is the number of bytes we can write into the FILE structure.

Analysis

Binary behavior (Ox78.c reconstruction)

FILE *fp;          // global

void create_test_file() {
    umask(0);
    int fd = open("/tmp/test.txt", 0);
    close(fd);
}

void Ox78() {
    create_test_file();
    char *testbuf = malloc(0x78);
    fp = fopen("/tmp/test.txt", "r");

    printf("I'm trying to test my FSOP prevention mechanism...\n");
    printf("Here's the address of the File Structure: 0x%llx\n", fp);

    void *puts_addr = /* resolved puts from GOT */;
    printf("I'm pretty confident you can't break out of this, "
           "so I'll give you a libc leak as well: %p\n", puts_addr);

    read(0, fp, 0x78);       // ← THE VULNERABILITY
    prevent_fsop();
    fread(testbuf, 1, 0x78, fp);
    prevent_fsop();
}

int main() {
    setvbuf(stdin, NULL, _IONBF, 0);
    setvbuf(stdout, NULL, _IONBF, 0);
    Ox78();
    return 0;
}

Leaks

1. Heap FILE* address — the exact address of the FILE structure on the heap
2. puts@libc — resolved GOT entry, giving us the libc base

Vulnerability

read(0, fp, 0x78) writes 0x78 bytes directly into the FILE structure from stdin. This lets us control all fields from offset 0x00 through 0x77:

...