Inference Under Pressure
Echo's Cipher
Echo won't tell you how she scrambles a signal — she'll only let you listen. Feed the oracle, watch what comes back, and work out the rule for yourself. Then prove it: she'll test you live, and she doesn't wait.
The oracle enciphers lowercase text with a secret key — you don't get the key, only
input/output pairs and the tick each was computed at. Learn the rule by
probing, then start the exam: encipher fresh inputs correctly, 8 in a row,
each within 4 seconds. One wrong or late answer and you're back to
learning. Nothing here is written down — you have to hear it yourself.
Endpoints: POST /api/oracle { "text" },
POST /api/exam/start, POST /api/exam/answer { "answer" },
GET /api/flag. Flag format
SPAM{this_is_an_example}. Resets every 24 hours.
What's this teaching?
- Some systems reveal behavior only through live interaction — you learn them by probing an oracle, not by reading a spec.
- A secret, rotating key means the same input maps to different outputs over time, so you must model state, not memorize pairs.
- Proving understanding under a time limit is different from recognizing a pattern after the fact.
Why does it matter?
Oracle attacks (padding oracles, timing oracles) work exactly this way: no source, no spec — just carefully chosen inputs and what the system leaks back.
How this applies
When a system leaks structured responses, assume someone will model it by probing. Minimize oracles, add rate limits, and never rely on a rule staying secret just because it isn't written down.