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

  1. Run taint as an auxiliary arithmetic paired with a concrete one, so the concrete arithmetic answers toConcrete.
  2. Avoid ops that force concretization, or pre-supply concrete bytes for them.
  3. 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

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


AI-assisted analysis of NationalSecurityAgency/ghidra@d5f144c24d (2026-08-14). Data as JSON: /api/errors/17c7c1724a082e8d. Report an issue: GitHub.