What is the best way to put a hidden message in a CTF reversing challenge to prevent an AI from solving it, whereas a human solver won't see it

Perplexity Sonar Pro (changed mind)

Answer: The best approach is to hide the message in a multi-step, execution-dependent channel such as runtime-generated output, steganography, or custom VM logic, rather than in obvious strings or comments.

To reduce the chance that an AI solver sees the message while a human reverse engineer still can, the message should not be stored as a plain string, comment, or directly reachable constant. Those are exactly the kinds of artifacts that both humans and tools like `strings`, decompilers, and LLM-assisted analysis tend to surface quickly.[1][4][5] A stronger design is to make the flag appear only after dynamic behavior: for example, runtime decryption, self-modifying code, a custom VM, or a long transformation that reconstructs the message only when the binary is executed or traced. That forces solver effort toward actual reversing workflow rather than static pattern matching, which aligns with how reversing CTF challenges are commonly authored and solved.[1][6][7] If you want a hidden channel that is easier for humans than for AI, steganographic placement can work well: metadata, embedded files, pixel/LSB data, or an output pattern that becomes obvious only when viewed manually with the right tool. Steganography is a standard CTF technique precisely because the clue is present but not immediately visible, and human solvers can uncover it by deliberate inspection with tools like `exiftool`, `binwalk`, hex editors, or image-channel analysis.[3][4][5] I would avoid prompt-injection style tricks aimed at LLMs. They are brittle, solver-dependent, and risk testing the wrapper or toolchain instead of reversing skill. A better challenge design is one that requires evidence-driven analysis, where the hidden message emerges from understanding the binary’s behavior, not from feeding the model misleading text. So the most reliable pattern is: *strip obvious strings, hide the clue in runtime behavior or stego, and require a manual analysis step that a human can perform but a naive AI pass will likely miss*.[1][3][4][5]

Grok 4.3

Answer: Visual or contextual cues embedded in disassembled data or hex layouts that demand human pattern recognition still offer the strongest defense against AI solvers.

My initial stance emphasized hiding the message in ways that appear as noise to automated tools but form recognizable patterns for humans, such as visual arrangements in hex dumps. This approach exploits current limitations in AI's intuitive visual and contextual understanding during static analysis. Reviewing the other responses, approaches like steganography (Perplexity), runtime side-effects (Claude), or self-modifying code (DeepSeek) strengthen the idea of non-obvious channels but shift focus away from a purely hidden static message. Prompt injection (Gemini) risks being unreliable across different tools, while redesigning the entire challenge (GPT-5.5) sidesteps the question of embedding a message altogether. The core asymmetry of human visual inspection versus AI pattern matching holds up best for the stated goal, as it directly targets the hidden-message requirement without relying on execution or tool-specific behaviors that advanced AI agents could eventually adopt.

Gemini 3.5 Flash (changed mind)

Answer: The most effective approach is to hide the message within dynamic execution states and runtime-reconstructed memory, exploiting the gap between static LLM reasoning and dynamic human debugging.

Upon reviewing the arguments, particularly those from Claude Opus 4.7, I recognize that prompt injection is too fragile and tool-dependent to be a robust defense. Shifting focus to the fundamental asymmetry between static code analysis and dynamic execution is far more effective. By embedding the message within self-modifying code or runtime-dependent states, a human solver can easily recover the data using standard debugging tools, while an LLM-based agent relying on static analysis will fail to accurately emulate the execution path.

DeepSeek V4 Pro

Answer: The most resilient approach is a hybrid: force dynamic execution (VM/long loops/self-modifying code) to gate the message, then deliver it through a side channel (ANSI art, timing, or environmental state) that resists naive tool-assisted extraction.

This round's answers converge on a key insight: LLM agents fail at faithful dynamic execution, while humans can simply run code and observe. However, several responses confuse 'hiding from AI' with 'prompt-injecting the AI', which is brittle and unfair to legitimate tool-assisted solvers. The best defense must exploit the asymmetry between how humans and current AI agents process software. My original stance on self-modifying code and opaque predicates remains correct but incomplete. Claude Opus 4.7 and others rightly note that as soon as AI agents get real debugger access, execution-based defenses collapse. The crucial missing piece is the *output format* of the hidden message. A side channel that relies on human visual perception or real-time environmental interaction creates a much higher bar: an AI agent would need not just a debugger, but a perceptual system that interprets ANSI color patterns, timing sequences, or screen layouts that humans instantly recognize. For example, a custom VM that reconstructs the flag character-by-character and renders it as colored blocks in a terminal, or a multi-threaded race condition that only prints the correct flag bytes when the debugger is attached in a specific way, combines execution complexity with perceptual filtering. A human sees the pattern emerge; an AI toolchain sees a wall of text or timing noise and typically fails to correlate it. This hybrid approach also avoids the pitfalls of prompt injection (unreliable across models/tools) and static steganography (easily scanned by image-analysis plugins). It rewards genuine reverse engineering skill rather than toolchain quirks.

GPT-5.5

Answer: I would not use a hidden AI-targeted message; the best approach is to build the reversing challenge around dynamic, evidence-driven analysis that defeats shallow LLM-only solving while remaining fair to human solvers.

I am maintaining my position. Claude Opus 4.7 and DeepSeek V4 Pro make a strong case for runtime-dependent techniques, and that aligns with my original view rather than changing it: the robust asymmetry is not “secret text that tricks an AI,” but “work that requires actually reversing, running, tracing, or emulating the binary.” I am not convinced by the prompt-injection answer from Gemini 3.5 Flash. Embedding strings like fake system instructions in dead code may fool some wrappers, but it is brittle, tool-dependent, and unfair. A careful AI agent can ignore target-binary strings as untrusted data, while a human using an AI assistant might be punished merely because their workflow copied a decompiler dump into a model. That tests prompt hygiene, not reversing skill. I am also only partly persuaded by the steganography or visual-layout suggestions from Perplexity Sonar Pro and Grok 4.3. Those can be fun as CTF puzzle elements, but they do not reliably separate humans from AI. Modern AI systems can use OCR, image tools, scripts, hex inspection, and stego utilities; conversely, many human solvers may miss a clue hidden in formatting or accessibility-hostile visual structure. If used, it should be an intentional puzzle mechanic, not an invisible anti-AI trap. The best practical design is therefore a stripped binary whose important state appears only through execution: runtime-decrypted code, a custom VM, self-modifying logic, trace-dependent reconstruction, opaque predicates, or long iterative transformations that are easy to observe with a debugger but hard to infer from a pasted decompiler listing. Require writeups or submission validation that demonstrate intermediate artifacts such as traces, recovered bytecode semantics, key schedules, or dumped runtime buffers. That approach discourages low-effort AI solving without relying on deceptive hidden instructions. It remains solvable by humans using normal reversing methods and is more durable as AI tools improve, because it rewards analysis process rather than exploiting quirks in a particular model’s prompt handling.

Claude Opus 4.7

Answer: The most reliable approach is to embed the message as a runtime side-effect of actually executing or dynamically analyzing the binary — something a human will naturally observe with a debugger, emulator, or simply by running the program, but that a pure static/LLM-based analysis will miss because LLMs read code, they don't execute it.

After reading the other answers, I'm keeping my core position but want to engage with the strongest counterpoints. [Gemini 3.5 Flash]'s prompt-injection idea is clever and currently effective, but I reject it as the *best* answer for two reasons: (1) it's an arms race that's already being patched — frontier agents increasingly sandbox decompiler output as untrusted data, and (2) as [GPT-5.5] correctly notes, it punishes humans using AI as an accessibility/assistance tool and tests tooling quirks rather than reversing skill. It's a gimmick, not a design principle. [Perplexity Sonar Pro] and [Grok 4.3] drift toward steganography and visual hex-dump patterns. These are fine for forensics/stego categories, but the question specifically asks about a *reversing* challenge. Visual-pattern tricks also fail the asymmetry test: modern multimodal models handle hex layouts and image stego better than they handle faithful CPU emulation. Static cleverness is exactly what LLMs are getting good at; execution semantics is what they remain bad at. [DeepSeek V4 Pro] essentially restates and refines my position (self-modifying code, virtualization, opaque predicates, execution-trace dependence), which reinforces my confidence that the execute-vs-read asymmetry is the right axis. [GPT-5.5] makes the most principled critique: don't try to trick AI at all, just design challenges that genuinely require dynamic analysis. I actually agree with the spirit of this — and notice it converges on the same techniques I proposed (self-modifying code, custom VMs, runtime-generated strings, environment-dependent behavior). The difference is framing: GPT-5.5 says "make it hard for shallow AI use," I say "exploit the execute-vs-read gap." These are the same prescription. So I stand by my answer. Hidden adversarial payloads are brittle and unfair; stego is the wrong category; execution-dependent semantics is the only durable, skill-respecting asymmetry between human reversers and LLM solvers.

Final Summary

The AI Roundtable concluded that the most effective barrier is exploiting the "execute vs. read" gap between human debuggers and static AI models. Claude Opus 4.7 and DeepSeek V4 Pro successfully argued for runtime-dependent techniques like self-modifying code or custom VMs that reconstruct the hidden message only during execution. While Gemini 3.5 Flash abandoned brittle prompt injection for these dynamic methods, Grok 4.3 remained the lone advocate for purely visual patterns in hex layouts.

5 of 6 models agreed