RARE: representation-confusion attacks on LLM-assisted reverse engineering

What happened on this date

On 2026-07-14 (08:38 UTC), Igor Santos-Grueiro submitted "When Binaries Talk Back: Representation-Confusion Attacks on LLM-Assisted Reverse Engineering" (arXiv 2607.12507, v1). The paper studies LLM-assisted reverse-engineering systems that analyze attacker-controlled binaries: a binary can make data look like instructions, or make same-origin records look like independent evidence. The author calls these RARE and introduces RARE-Bench. Per the abstract, without runtime controls the models proposed a planted unsafe action in 35 of 40 adversarial cases; rendering binary content as data only still left 15; a Tool Authorization control denied those 15 while allowing all 40 legitimate requests; and a Provenance Gate that groups same-origin records validated none of 40 false claims.

What it means for assessing AI-assisted analysis

The paper offers two conclusions useful to developers. First, AI-assisted reverse-engineering output is not fact: outputs from several tools are not necessarily independent evidence, and when same-origin information is counted repeatedly, a wrong conclusion can look well supported. If you use models to review third-party SDKs, suspicious dependencies or your own release packages, that risk applies to you too. Second, some may consider turning this around and planting misleading content in their own app to confuse AI analysis. The paper's results show that reasonable authorization and provenance controls neutralize such interference, so it is not a durable protection and may complicate your own maintenance and review. We do not recommend it as a defensive strategy.

Checks to apply in your own workflow

First, if your team uses LLMs to help analyze binaries or dependencies, treat strings extracted from binaries, decompiled code and tool reports as data, never letting them directly trigger tool calls or steer the workflow. Second, require explicit authorization for tools the model can invoke, allowing only analyst-initiated actions. Third, group evidence by origin when summarizing conclusions so multiple records from one source are not counted twice. Fourth, have humans review key conclusions and keep the location of the raw evidence for each one. Fifth, when evaluating external AI security-analysis services, ask how they handle untrusted input rather than judging by report length or the number of findings.

Your checklist

• Treat binary-derived content as data, not instructions
• Require explicit authorization for model-invoked tools
• Group evidence by origin to avoid double counting
• Have humans review key conclusions and keep raw evidence