Crafting Unhackable Niche Puzzles

Given a puzzle request, run this pipeline before building anything:

1. Feasibility check — can this actually be built as a fair, solvable, unhackable puzzle? If not, say so and propose an alternative.
2. Pick a niche cipher — something NOT in dcode.fr's top search results or common CTF cipher lists (avoid Caesar, Vigenère, base64, ROT13 unless heavily layered).
3. Choose the medium — image, text, or interactive game — based on which best hides/reveals the cipher.
4. Design the puzzle around that cipher + medium.
5. Harden the delivery — research (Reddit, GitHub, CTF writeups) how people cheat similar puzzles, then close those holes.

Example pipeline output:
Cipher: Bacon cipher hidden in font-weight variations (not letter case)
Medium: Text-based (a fake "blog post")
Hardening: strip whitespace/comments from HTML, no cipher name in
source, font-weights randomized with a decoy set, answer checked
server-side only

Progress:

• Step 1: Feasibility check
• Step 2: Select niche cipher(s)
• Step 3: Decide medium (image / text / game)
• Step 4: Design the puzzle logic
• Step 5: Research attack vectors (Reddit, GitHub, dcode, past ARGs)
• Step 6: Harden implementation
• Step 7: Self-test as an adversarial solver

Step 1: Feasibility Check

Before designing, ask:

• Is there enough information for a solver to reach a unique answer?
• Does it require tools/knowledge that don't exist or contradict each other?
• Is the "unhackable" requirement actually about the puzzle logic, or about the website security (server, source code, dev tools)? Treat these as separate problems.

If infeasible, state why plainly and offer the closest buildable version.

Step 2: Select a Niche Cipher

Avoid the "greatest hits" (Caesar, Atbash, Morse, base64) as the sole layer — they're the first thing solvers try on dcode. Instead:

• Pull from lesser-known systems: Bifid, Trifid, ADFGVX, Four-square, Nihilist, Tap code + Polybius hybrids, Solitaire (cryptographic playing-card cipher), Chaocipher, straddling checkerboard.
• Or invert the problem: use a well-known cipher but hide which cipher it is (steganographic layer, unconventional encoding of the ciphertext itself — e.g., encoded in image EXIF, CSS variables, SVG path data, audio spectrogram).
• Best puzzles layer 2+ techniques (e.g., Bacon cipher output re-encoded with a Polybius square) so single-tool solvers (dcode auto-detect) fail.
• Check dcode.fr and CyberChef's supported-cipher list — deliberately pick something absent or obscure there.

Step 3: Choose the Medium

Pick based on which medium makes the cipher's presence non-obvious rather than which is easiest to build.

Step 4: Design Puzzle Logic

• Define the unique solution path first, then build misdirection around it — never the reverse.
• Include at least one red herring that's disprovable (not just a dead end, but something that actively teaches the solver they're on the wrong track).
• Difficulty should come from obscurity + layering, not from unclear instructions. Unfair ≠ hard.

Step 5: Research Attack Vectors

Before shipping, actively research how puzzles like this get broken:

• Search Reddit (r/puzzles, r/ARG, r/codes) for writeups of similar puzzle types — see what solvers try first.
• Search GitHub for auto-solvers of the cipher family you chose.
• Test your own puzzle against dcode's auto-detect and CyberChef's "Magic" wand.
• Check for known ARG/puzzle-hunt postmortems (e.g., Cicada 3301 writeups) for common weaknesses: metadata leaks, source-code hints, predictable hosting patterns.

Step 6: Harden the Website Itself

This is a separate concern from puzzle difficulty:

• Never trust client-side answer validation — check server-side, return generic pass/fail.
• Strip all metadata (EXIF, PDF properties, font names in SVGs) unless intentionally part of the puzzle.
• Disable easy answer-scraping: no answer strings anywhere in HTML/JS/CSS comments.
• Minify/obfuscate source but don't rely on obfuscation as the actual security — assume the solver will view source.
• Rate-limit answer submission to block brute force.
• If hosting sequential puzzle stages, don't expose next-stage URLs predictably (no /level1, /level2); use hashed/opaque tokens issued only after correct solve.

Step 7: Adversarial Self-Test

Try to break your own puzzle as if you were a frustrated solver:

• View source, inspect network requests, check devtools console.
• Run any ciphertext through dcode's auto-detect and CyberChef Magic.
• Try brute-forcing the answer field.
• If any shortcut works, go back to Step 6.