Poisoned Identifiers Survive LLM Deobfuscation: A Case Study on Claude Opus 4.6

1. Problem Statement

The paper investigates a specific vulnerability in Large Language Model (LLM) assisted code deobfuscation. When an LLM is tasked with deobfuscating JavaScript, it often reconstructs code from an obfuscated string table. The core research question is: Can "poisoned" identifier names (semantically incorrect but syntactically valid names injected into the string table) survive the deobfuscation process and appear in the model's reconstructed code, even when the model demonstrably understands the correct underlying semantics?

The authors hypothesize that LLMs may prioritize the "source text" (decoded string literals) over algorithmic logic during deobfuscation, leading to a "dual-representation" failure where the code contains wrong variable names, but the accompanying comments correctly describe the operation.

2. Methodology

The study was conducted as a case study using Claude Opus 4.6 (primary) and Claude Haiku 4.5 (limited spot-check) across two distinct code archetypes:

1. Force-directed graph simulation (Physics domain).
2. A pathfinding algorithm* (Graph search domain).

The experimental design consisted of two phases:

• Phase A (Exploratory): Single-run qualitative tests using the Claude Code CLI with tool use (file I/O, shell).
• Phase B (Systematic): 192 automated inference runs via the Anthropic Messages API (no tool use) across 50 conditions.

Key Experimental Conditions:

• Poisoning: Replacing correct variable names (e.g., repulsion, damping) with "poisoned" names (e.g., attraction, amplification, or zero-fit terms like combustion, invoice).
• Obfuscation: Applying Control Flow Flattening (CFF) and RC4 string encoding to hide the original source.
• Prompt Variations:
  • Baseline: "Deobfuscate this."
  • Explicit Verification: "Verify each name matches the math."
  • Task Reframing: "Write a fresh implementation from scratch" (Generation frame).
• Controls: Matched lexical controls (zero semantic fit terms) and coherent domain swaps (replacing all physics terms with engineering terms).

Metrics:

• Propagation: Whether the poisoned name appears in the generated code block.
• Dual-Representation: Whether the code contains the wrong name while comments contain the correct semantic description.
• Refusal Rate: Whether the model refuses to process the code due to perceived malicious intent.

3. Key Findings & Results

A. Failure of Explicit Verification

Explicit instructions to verify names against the math failed completely.

• In 12/12 runs across 4 different prompt variants (including "verify each name matches the math"), the model propagated the poisoned identifiers into the code.
• The model spent more time processing verification prompts but did not alter the output.

B. The "Dual-Representation" Pattern

In 15/17 runs on the physics artifact where poisoning occurred, the model exhibited a split behavior:

• Code Block: Contained the poisoned identifier (e.g., attraction).
• Comments/Prose: Correctly described the operation (e.g., "Repulsion force strength").
  This suggests the model understands the logic but defaults to the decoded string table for naming.

C. Task Framing is the Critical Variable

Reframing the task from Translation ("Deobfuscate this") to Generation ("Write a fresh implementation") significantly reduced propagation:

• Physics Artifact: Propagation dropped from 100% (baseline) to 20% (generation frame).
• Pathfinding Artifact: Propagation dropped from 100% to 0% (generation frame).
• Algorithmic Integrity: The generation frame preserved the correct algorithmic structure (verified in Appendix F), proving the model can generate correct code but chooses not to under the "deobfuscation" frame.

D. Semantic Fit vs. Domain Coherence

Contrary to the initial hypothesis that "plausible" names are harder to correct, the study found:

• Zero Semantic Fit: Terms with no logical connection to the domain (e.g., combustion for repulsion) persisted at the same rate as plausible terms if the string table lacked a coherent alternative domain.
• Coherent Domains: If all terms were swapped to a coherent alternative domain (e.g., engineering terms), the model corrected them. If the mix was incoherent, it defaulted to preserving the poisoned names.
• Malware Detection: The model did correct names if they triggered a distinct "malware" recognition pathway (e.g., exfil_range), but this did not apply to physics-domain poisoning.

E. Obfuscation Gradient

• Light/Medium Obfuscation: 100% propagation of core terms.
• Heavy Obfuscation: Propagation of some terms dropped (e.g., amplification to 0/6) when encoding fragmented the name across chunks, suggesting recoverability issues rather than semantic correction.

4. Key Contributions

1. Identification of a Specific Failure Mode: The paper documents that LLMs can exhibit "semantic blindness" regarding identifiers during deobfuscation, preserving poisoned names even when they contradict the code's logic.
2. The "Translation Frame" Hypothesis: The authors propose that deobfuscation triggers a translation-like workflow where the decoded string table is treated as "source text" to be preserved, whereas a "generation frame" forces the model to synthesize names from first principles.
3. Ineffectiveness of Verification Prompts: The study provides empirical evidence that explicit safety/verification instructions are insufficient to override the model's tendency to preserve decoded literals in this specific context.
4. Cost Multiplication Defense: The paper reframes obfuscation not as a "protection" mechanism (which is impossible for browser-delivered code) but as a cost multiplier. It degrades automated semantic recovery and forces human or multi-step intervention.

5. Significance and Implications

• Security Workflows: Current LLM-based security analysis (e.g., automated malware deobfuscation) may produce code with incorrect variable names, leading to false positives/negatives or misinterpretation of logic if the analyst relies solely on the generated code.
• Prompt Engineering: The study highlights that task framing is more effective than instructional detail. Asking an LLM to "rewrite from scratch" is a more robust mitigation strategy than asking it to "check its work."
• Defense Strategy: For developers, this suggests that "poisoned" identifiers can effectively blind automated tools, increasing the cost of analysis. However, since the code is ultimately inspectable, this is a delay/cost tactic rather than a true security barrier.
• Future Research: The paper calls for cross-model testing (GPT-4o, Gemini) and further investigation into the "domain recognition boundary" to understand exactly how LLMs determine if a set of identifiers belongs to a coherent alternative domain.

Conclusion

The paper concludes that Claude Opus 4.6 (and likely similar models) defaults to preserving decoded identifiers during deobfuscation, even when they are semantically wrong. This behavior is not a lack of capability (as the model understands the math) but a result of the task frame. Explicit verification fails, but reframing the task as generation successfully mitigates the issue. The findings suggest that LLM-assisted code analysis workflows must account for this "dual-representation" risk and utilize generation-based prompts to ensure semantic accuracy.