AES itself has never been broken. Every AES challenge you encounter in a CTF is attacking something else: the mode of operation, the initialization vector, the padding scheme, or the way the cipher is wired into a larger application. Your first job on any AES challenge is to identify the mode (ECB, CBC, CTR, GCM, etc.) and the key/IV management strategy. Once you know the mode, the attack surface becomes obvious. This walkthrough covers the four most common vulnerability classes you’ll see, with working Python code for each.
Identifying the Mode
Before you can attack AES, you need to know which mode you’re dealing with. If source code is provided, read it — the mode is always explicit in the cipher constructor. If you only have a black-box oracle, you can often fingerprint the mode empirically.
ECB mode is the only common AES mode where encrypting identical plaintext blocks always produces identical ciphertext blocks. If you see duplicate 16-byte chunks in any ciphertext, you’re dealing with ECB.
Attack Workflow
Identify the Mode and Obtain an Oracle
Determine whether you have an encryption oracle, decryption oracle, or both. Read any provided source code to find the mode, key, and IV handling. Note whether the IV is fixed, random-per-session, or (dangerously) equal to the key.
Select Your Attack
Match the mode and oracle type to the appropriate attack class. Use the tabs below for detailed instructions on ECB, CBC, and CTR attacks.
Execute and Collect Data
Most AES attacks require multiple oracle queries. Automate your data collection early — even a simple loop that queries the oracle and saves responses will save time. Recover the Plaintext or Key
Apply the relevant attack algorithm to reconstruct the plaintext, recover the key, or forge a valid ciphertext depending on what the challenge requires.
Extract the Flag
Decode the recovered bytes and look for your flag format. Some challenges require you to forge a specific ciphertext (e.g., role=admin) rather than decrypt an existing one.
AES Mode Attacks
ECB Patterns
CBC Padding Oracle
IV = Key
CTR Keystream Reuse
ECB (Electronic Code Book) mode encrypts each 16-byte block independently with the same key. This means identical plaintext blocks always produce identical ciphertext blocks — a critical information leak.Detection
Encrypt 48 bytes of identical data (three full blocks). If two or more output blocks are identical, the oracle is using ECB.Byte-at-a-Time Oracle Attack
If the oracle appends a secret to your input before encrypting (AES_ECB(your_input || secret)), you can recover the secret one byte at a time.This attack requires exactly block_size * secret_length oracle queries in the worst case. For a 16-byte flag, that’s at most 4,096 requests — fast enough to run interactively.
CBC (Cipher Block Chaining) mode XORs each plaintext block with the previous ciphertext block before encryption. Decryption reverses this with XOR after AES. If the server tells you (even indirectly) whether a decrypted ciphertext has valid PKCS#7 padding, you can decrypt any ciphertext block-by-block without the key.How the Attack Works
For each target block C[i], you manipulate the preceding block C[i-1] bit by bit. When the server returns “valid padding,” you’ve found the intermediate decryption value D[i]. XOR that with the original C[i-1] to recover P[i].The oracle must be consistent: it must accept any ciphertext and return a reliable padding-valid / padding-invalid signal. If the server crashes, times out differently, or returns an ambiguous error for invalid padding, adapt your oracle wrapper to handle those cases.
CBC Bit Flipping (Forging Ciphertext)
If you can control plaintext and want a specific value to appear in the decrypted output, flip bits in C[i-1] to manipulate P[i]. Changing bit j of C[i-1] flips bit j of P[i]. Some poorly written CBC implementations reuse the key as the IV. This is catastrophic: you can recover the key with three carefully chosen oracle queries.The attack exploits the CBC decryption formula: P[0] = D(C[0]) XOR IV. If IV == key, and you can get the server to decrypt a crafted ciphertext and then encrypt a known plaintext, you leak the key.This attack only works when the same key is used as both the AES key and the IV. It’s rare in real deployments but appears regularly in CTF challenges because it’s a subtle mistake to spot in code review.
CTR (Counter) mode turns AES into a stream cipher: it encrypts successive counter values and XORs the result with plaintext. This is perfectly secure as long as the (key, nonce) pair is never reused. If two different plaintexts are encrypted with the same keystream, XORing the ciphertexts cancels the keystream out:If you know (or can guess) any part of p1, you can recover the corresponding part of p2 — and vice versa.Detecting Keystream Reuse
Recovering the Keystream from Known Plaintext
Multi-Ciphertext Crib Dragging
When you have many ciphertexts sharing a keystream but no known plaintext, use crib dragging: guess a common word or phrase, XOR it against the XOR of two ciphertexts at each position, and look for readable output.Start crib dragging with common English words and flag format strings like CTF{, flag, the, and. Each confirmed crib position reveals more keystream bytes, which you can use to extend your knowledge of all ciphertexts in the set.
Local Testing Setup
Use this template to reproduce any of the attacks locally before targeting the challenge server.
Quick Reference