Opaque Predicates: How Obfuscators Hide Dead Code and Real Logic

It's a predicate (a true/false condition) whose value is opaque to the reader but known to whoever inserted it. Two flavours do all the work:

• Opaquely true — always evaluates to True (e.g. x*x >= 0). Used to wrap real code, so the branch always runs but can't be removed without proof.
• Opaquely false — always evaluates to False (e.g. x*x < 0). Used to guard junk/dead code that never runs but litters the listing.

import random

# each of these is the SAME for every integer x —
# obvious to the obfuscator, not to a reader:
assert all((x*x >= 0)         for x in range(-10000, 10000))   # always True
assert all((x*(x+1) % 2 == 0) for x in range(-10000, 10000))   # always True
assert all(not (x*x < 0)      for x in range(-10000, 10000))   # always False
# x*(x+1) is a product of two consecutive integers, so it's always even.

Here's the whole trick in one snippet. The obfuscator inserts branches that *look* conditional but aren't — burying junk behind an always-false guard and wrapping the real work behind an always-true one:

# opaquely FALSE — this junk never runs, but a reverser can't
# statically prove it's dead, so it stays and wastes their time:
if x * x < 0:
    log_fake_telemetry(payload)   # pure noise

# opaquely TRUE — the real check always runs, but deleting the
# 'if' isn't obviously safe, so the control flow looks branchy:
if x * (x + 1) % 2 == 0:
    granted = verify_license(key)

Sprinkle dozens of these through a function and the control-flow graph balloons with branches that never fork in practice. The reverser now has to evaluate every predicate to know which paths are real — exactly the work opaque predicates are designed to impose.

A human can eyeball x*x >= 0, but obfuscators use predicates that require actual reasoning to resolve. The classic is number-theoretic — Collberg's example that `7·y² − 1` is never a perfect square, so a check based on it is always true, but proving it takes number theory, not a glance:

from math import isqrt

# 7*y*y - 1 is never a perfect square, so this branch is ALWAYS taken:
if 7*y*y - 1 != isqrt(7*y*y - 1) ** 2:
    run_real_code()
# tested: holds for every y in range(-200000, 200001)

Automated tools don't fare much better on the strong forms. Static analysis and compiler optimizers can't fold these away, and defeating them generally needs symbolic execution or an SMT solver to prove each predicate constant — expensive, and defeatable further by varying the predicate at every site so nothing pattern-matches.

Number-theoretic and bitwise predicates are the easiest to generate and verify in Python (they're pure integer math). Aliasing- and environment-based predicates are harder for automated tools to crack but also harder to construct correctly.

• Overhead: every opaque predicate is real code that runs, so heavy use adds instructions and branches — apply it around *sensitive* logic, not everywhere.
• Correctness: an opaque predicate must be genuinely constant for all inputs, or you change behavior — which is why obfuscators stick to proven identities (like the ones tested above).
• One layer: opaque predicates confuse *control flow*; they don't hide names, strings, or constants. Real protection combines them with the other techniques.

Inserting these by hand is fiddly and risky. Our free Python Obfuscator injects opaque-predicate-style junk and bogus control flow automatically as part of its layered pass, alongside MBA integer encoding, renaming, string encryption, and control-flow flattening — see the full picture in Python obfuscation explained.