What is the difference between finding references to a string and finding references to an ivar or function in radare2 analysis?

Finding references to a string usually helps you locate the code path that emits a message, checks an error condition, or matches source behavior. Finding references to an ivar or function helps you understand object state and control flow. The underlying workflow is similar, but the investigative goal changes from text tracing to structural code tracing.

Why String Xrefs and Code Xrefs Lead to Different Questions

In radare2, a string reference answers a text-led question: where does this literal appear in logic, output, or error handling? An ivar or function reference answers a structure-led question: where does this field get read, written, or invoked as part of program flow? That distinction matters because the same binary can contain many strings that are never security-relevant, while a single function or object field can control branching, state, or privilege-sensitive behaviour. For reverse engineers, the investigative value is not the reference type alone, but what it reveals about intent and execution.

The difference is especially important when tracing behaviour in unfamiliar code. A string xref often points you toward user-facing messages, protocol markers, or hard-coded checks, which can be useful for mapping features and spotting nearby branches. An ivar or function xref more often reveals object lifecycle, method dispatch, and state transitions, which is where control decisions tend to live. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because disciplined analysis depends on evidence handling and traceability, not just on spotting interesting literals.

In practice, analysts often overvalue string hits because they are fast to find, then discover the real control logic only after following the function and state references instead.

How the Investigation Changes in Practice

A string search in radare2 is usually a starting point for semantic context. It helps answer questions such as: what error path is present, what feature name is embedded, or what external protocol term appears in the binary? From there, the analyst follows cross-references to see which function prints the string, gates access, or reacts to a condition. That workflow is useful when you are triaging a sample, documenting behaviour, or mapping user-visible responses back to code.

An ivar or function reference is different because it is usually part of the program’s structural logic. An ivar reference may show where object state is initialised, mutated, compared, or passed into later decisions. A function reference usually shows direct execution relationships, call chains, and branching behaviour. That means the analyst is no longer asking only “where is this text used?” but also “how does this state move through the program?” or “which routine governs this path?”

Use string xrefs when the goal is to locate output, checks, labels, or protocol text.
Use ivar xrefs when the goal is to trace object state or lifecycle changes.
Use function xrefs when the goal is to recover control flow, dispatch, or call relationships.
Combine all three when a string is only the entry point into a deeper state transition.

In practice, this breaks down when the code is heavily optimised, stripped, or dynamically dispatched, because the most important path may not be obvious from a single reference type alone.

Where the Difference Matters Most in Real Analysis

Tighter reference tracing often increases analyst effort, requiring teams to balance speed against confidence in what the binary is actually doing.

There are a few common edge cases. Some strings are decoys, reused across logging, localisation, or dead code, so a string xref can mislead if you treat every hit as meaningful. Some ivar references are shallow because a field is just copied through multiple objects before any decision is made. Some function xrefs are indirect, especially in virtual dispatch, callback-heavy designs, or plugin architectures, where the visible caller is not the true decision point. In those cases, the investigation should follow the runtime relationship, not just the static reference list.

Guidance versus consensus: practitioners generally agree that string references are better for discovery and function or ivar references are better for structure, but there is no universal rule that one is always more valuable. The better choice depends on whether you are reconstructing user-visible behaviour, internal state, or execution flow. If you are analysing a packed, obfuscated, or highly object-oriented sample, the distinction often blurs and you need to triangulate between several reference types at once.

One useful way to think about it is that string xrefs help you answer “what does this code talk about?”, while ivar and function xrefs help you answer “what does this code do?”

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1027 — Obfuscated Files or Information	xref analysis often starts from strings hidden in packed or stripped binaries.
	T1059 — Command and Scripting Interpreter	function tracing may reveal code paths that launch commands or script-like execution.
Recommendation — Use T1027 to hunt for concealed strings and recovered indicators in unpacked code paths. Map discovered call paths to T1059 when analysis shows interpreter-driven execution.
CIS Controls v8	8.2 — Audit Log Management	reference tracing supports evidence-rich investigation and defensible behavioural reconstruction.
	16.1 — Incident Response Management	the workflow supports triage by moving from textual clues to executable behaviour.
Recommendation — Retain analysis artefacts and trace evidence so findings can be reproduced and reviewed. Use xref-led reverse engineering to prioritise suspicious functions during incident analysis.
NIST CSF 2.0	DE.CM — Security Continuous Monitoring	xref-driven analysis improves visibility into how code behaves at runtime or in static review.
Recommendation — Apply DE.CM to continuously validate what binaries do beyond surface strings.

Practitioner Guidance

What to prioritise: Start with string xrefs when you need a quick behavioural anchor, but switch to ivar and function xrefs as soon as you need to prove control flow or state changes. The common mistake is stopping at the first readable message and treating it as the substantive logic.

What to verify: Verify whether the reference is informational or decisive. A string may only document a branch, while an ivar or function reference may actually determine whether the branch is taken. The useful question is whether the reference changes behaviour or merely labels it.

What good looks like: A strong analysis links the string to the emitting function, then connects that function to the relevant object field or downstream call path. That gives you both the semantic clue and the structural explanation, which is usually what you need to defend the finding.

Practitioner takeaway: Treat string references as discovery points and ivar or function references as proof points; the analysis becomes trustworthy only when the path from text to behaviour is explicit.