NationalSecurityAgency/ghidra · error · ConcretionError
Cannot make taint concrete
Error message
Cannot make taint concrete
What it means
Taint is a label set, not a value - it has no bytes to concretize. toConcrete therefore throws ConcretionError. The arithmetic is designed to run as an auxiliary alongside a concrete arithmetic that owns the actual bytes, and the paired concrete arithmetic is what should answer concretization. ConcretionError is the framework's standard signal that this arithmetic cannot produce concrete bytes.
Source
Thrown at Ghidra/Debug/TaintAnalysis/src/main/java/ghidra/pcode/emu/taint/TaintPcodeArithmetic.java:233
* Constant values have no taint, so we just return a vector of empty taint sets
*/
@Override
public TaintVec fromConst(byte[] value) {
return TaintVec.empties(value.length);
}
/**
* {@inheritDoc}
*
* <p>
* Taint vectors have no values. We're expect the taint arithmetic to be used as an auxiliary to
* concrete bytes, so the paired arithmetic should always defer to its concrete element. Thus,
* an {@link AssertionError} might also be fitting here, but we'll stick to convention, since
* technically a user script could attempt to concretize taint.
*/
@Override
public byte[] toConcrete(TaintVec value, Purpose purpose) {
throw new ConcretionError("Cannot make taint concrete", purpose);
}
/**
* {@inheritDoc}
*
* <p>
* Taint vectors do have length, so return it here.
*/
@Override
public long sizeOf(TaintVec value) {
return value.length;
}
}
View on GitHub (pinned to d5f144c24d)
Solutions
- Run taint as an auxiliary arithmetic paired with a concrete one, so the concrete arithmetic answers toConcrete.
- Avoid ops that force concretization, or pre-supply concrete bytes for them.
- Catch ConcretionError at a higher level if graceful degradation is acceptable for your analysis.
Example fix
// before (taint used alone; toConcrete fails) byte[] v = taintArithmetic.toConcrete(taintVec, Purpose.OTHER); // after (delegate concretization to the paired concrete arithmetic) byte[] v = concreteArithmetic.toConcrete(concreteVec, Purpose.OTHER);
Defensive patterns
Strategy: fallback
Validate before calling
// Route concretization to the paired concrete arithmetic:
if (arithmetic instanceof TaintPcodeArithmetic) {
// do not call toConcrete on taint; use the concrete partner
return concreteArithmetic.toConcrete(concreteVec, purpose);
} Try / catch
try {
return arithmetic.toConcrete(value, purpose);
} catch (ConcretionError e) {
// fall back to the paired concrete arithmetic or skip the op
} Prevention
- Always pair taint arithmetic with a concrete arithmetic that owns real bytes.
- Avoid ops that force concretization in pure-taint analysis.
When it happens
Trigger: The pcode executor or user code calls arithmetic.toConcrete(taintVec, purpose) - e.g. an instruction that needs a concrete constant (branch target, address computation), or a user script explicitly trying to read taint as bytes.
Common situations: Running a taint-only executor where an instruction forces concretization (conditional jumps, syscalls, address resolution); wiring taint as the primary arithmetic without a concrete partner; user scripts calling toConcrete on taint.
Related errors
- Cannot make Taint concrete
- Not supported
- TaintVecs must match in length
- Timed out reading or writing target
- Error reading or writing target
AI-assisted analysis of NationalSecurityAgency/ghidra@d5f144c24d (2026-08-14).
Data as JSON: /api/errors/17c7c1724a082e8d.
Report an issue: GitHub.