The Effect of Code Obfuscation on Human Program Comprehension

Imagine you are trying to read a map to find a treasure.

Normal Code (L0): The map has clear labels like "River," "Mountain," and "Old Oak Tree." You can quickly glance at it, recognize the landmarks, and say, "Ah, the treasure is here!" This is System 1 thinking: fast, intuitive, and easy.
Obfuscated Code: Now, imagine someone takes a marker and scribbles over the map. They change "River" to "X," "Mountain" to "Z," or worse, they write "River" but draw a picture of a mountain. They also twist the roads so the path isn't a straight line anymore.

This paper is a scientific experiment to see what happens to a human's brain when they try to read these "scrambled" maps (code). The researchers wanted to know: Does making code harder to read actually make it harder to understand, and does it slow people down?

Here is the breakdown of their findings, using simple analogies:

1. The Experiment: The "Output Prediction" Game

The researchers gave 50 computer science students a challenge. They showed them a small piece of code (a function) and a specific input (like a number), and asked: "What is the result?"

They tested five levels of difficulty:

Level 0 (Clean): The code is normal.
Level 1 (Boring Names): They changed calculateTotal to var_x. (Like changing "River" to "X").
Level 1b (Tricky Names): They changed calculateTotal to calculateTax (when it actually calculates tax minus a fee). This is a trap. It looks right but is wrong. (Like labeling a mountain "River").
Level 2 (Twisted Roads): They kept the names but scrambled the order of the steps so the logic flows in a circle instead of a straight line.
Level 3 (The Nightmare): They did both—scrambled the names AND twisted the roads.

2. The Big Surprise: "More Confusion" Doesn't Always Mean "Harder"

The researchers expected that as they added more tricks, the students would get worse and worse at a steady pace. They were wrong.

JavaScript (The Literal Reader): For JavaScript, the results were predictable. The more they scrambled the code, the worse the students did. It was a straight line down. JavaScript relies heavily on variable names to make sense of things, so changing the names broke the students' brains.
Python (The Pattern Seeker): For Python, something weird happened. When they changed the names to boring things (Level 1), the students actually got better at solving the puzzles!
- Why? In the clean Python code, the names were so "helpful" that students relied on a quick guess (System 1). They thought, "Oh, it's a sorting function, so it must sort!" and guessed wrong.
- When the names were stripped away, the students couldn't guess. They were forced to slow down, trace every step carefully (System 2), and actually read the logic. Removing the "helpful" clues forced them to do the work correctly.

3. The "Goldilocks" Zone of Thinking

The study looked at how long it took students to answer. They found a sweet spot:

Too Fast: If you answer in 10 seconds, you are likely guessing (System 1). You get it wrong, especially if the code is tricky.
Too Slow: If you stare at the screen for 10 minutes, you are likely confused and spinning your wheels. You get it wrong because you've lost the thread.
Just Right: The best results happened when students took a moderate amount of time (about 1 to 3 minutes). This is the "deliberate" zone where they were thinking hard but not panicking.

The Analogy: Think of it like solving a maze.

Running in blindly (Fast) gets you stuck in a wall.
Standing still and staring at the ceiling for an hour (Too Slow) gets you nowhere.
Walking slowly, checking the walls, and thinking (Just Right) gets you to the exit.

4. Experience is a Double-Edged Sword

You might think that an expert programmer would be great at reading scrambled code.

The Good News: If you know Python well, you are generally better at reading Python code, even if it's scrambled.
The Bad News: Being an expert in Python can actually hurt you when reading JavaScript, and vice versa.
The "Expert Trap": Experts are so used to seeing patterns that they rely on their "fast brain" (System 1). When the code is scrambled, their fast brain makes a confident but wrong guess. Beginners, who don't have those strong habits, are sometimes forced to slow down and read carefully, which actually helps them get the right answer!

5. What This Means for the Real World

Security: If you want to hide code from a human hacker, just changing the names isn't enough. You have to twist the logic (the roads).
Programming: Sometimes, writing code with very descriptive names is good, but sometimes it makes you lazy. If you strip away the names, you might force yourself (or your team) to actually understand the logic, not just the labels.
Tools: We need to stop measuring code difficulty just by counting lines or complexity. We need to measure how much it forces the human brain to switch from "autopilot" to "manual driving."

The Bottom Line

Code obfuscation doesn't just make code "harder"; it changes how we think about it. It forces us to stop guessing and start working. Sometimes, taking away the "helpful" labels actually helps us understand the code better because it stops us from making lazy assumptions. But if you twist the logic too much, even the smartest experts get lost.

Here is a detailed technical summary of the paper "The Effect of Code Obfuscation on Human Program Comprehension."

1. Problem Statement

Software obfuscation is widely used to protect intellectual property and deter reverse engineering. However, its effectiveness is typically evaluated using automated metrics (e.g., code complexity, decompilation success) or theoretical attacker models that assume a monotonic relationship: more obfuscation equals harder comprehension for humans.

The authors identify a critical gap: there is limited empirical evidence on how specific obfuscation mechanisms actually impact human cognitive processes. They challenge the assumption that obfuscation difficulty scales linearly with transformation complexity and investigate whether human cognition (specifically the transition between intuitive and analytical reasoning) behaves differently across programming languages (Python vs. JavaScript).

2. Methodology

Experimental Design

The study employed a controlled human subject experiment involving 50 undergraduate computer science students. Participants were tasked with output prediction: given a function and a specific input, they had to determine the exact output. This task was chosen as a proxy for program comprehension because it requires building a correct mental model of semantics and offers an objective binary metric (correct/incorrect).

Obfuscation Tiers

The researchers constructed a hierarchy of five obfuscation levels ( $L0$ – $L3$ ) applied to function-level code snippets from the HumanEval-X benchmark (Python and JavaScript subsets):

$L0$ (Baseline): Original, unobfuscated code.
$L1$ (Identifier Renaming): Replaces identifiers with short, non-informative names (e.g., var_xxxx), removing semantic shortcuts.
$L1b$ (Adversarial Renaming): Replaces identifiers with semantically plausible but misleading names (e.g., naming a variable smoothArea when it actually calculates a Fibonacci number), designed to trigger incorrect mental models.
$L2$ (Control-Flow Alteration): Flattens control flow by decoupling execution logic from syntactic structure (e.g., using dispatchers/indirect jumps), disrupting structural cues.
$L3$ (Combination): A realistic combination of $L1$ (renaming) and $L2$ (control-flow flattening).

Data Collection & Analysis

Metrics: Accuracy (correctness), Response Time (seconds), and self-reported programming experience (None, <1 year, >1 year).
Theoretical Framework: The study utilizes Dual-System Theory (System 1: fast, heuristic, intuitive; System 2: slow, deliberate, analytical). The authors hypothesize that obfuscation acts as a barrier to System 1, forcing a computationally expensive switch to System 2.
Variables: The study analyzed correlations between performance and code properties (cyclomatic complexity, line count, identifier length) and language-specific factors.

3. Key Contributions & Findings

A. Non-Monotonic Relationship Between Obfuscation and Difficulty

Contrary to the assumption that "more obfuscation = harder," the results show a non-monotonic relationship that varies significantly by language:

JavaScript: Follows the expected linear degradation. Accuracy drops steadily as obfuscation increases ( $L0 \to L3$ ), with Control-Flow alteration ( $L2$ ) being more damaging than renaming.
Python: Exhibits a paradoxical trend. Accuracy for Python actually increased under renaming ( $L1$ $L 1$ and $L1b$ $L 1 b$ ) compared to the unobfuscated baseline ( $L0$ $L 0$ ).
- Explanation: In Python, original semantic names may trigger misleading System 1 heuristics (incorrect assumptions). Removing or altering these names forces the programmer to abandon intuition and engage in deliberate System 2 tracing, which ironically improves accuracy for certain tasks.

B. The Role of Response Time and Cognitive Modes

System 1 vs. System 2: Obfuscation successfully disrupts System 1 processing. Fast responses on obfuscated code are highly error-prone.
The "Goldilocks Zone": Accuracy peaks at moderate response times (indicating effective System 2 engagement).
- Too Fast: Indicates reliance on broken heuristics (System 1).
- Too Slow: Often indicates confusion, unproductive searching, or mental model collapse, leading to lower accuracy.
Adversarial Renaming ( $L1b$ ): This tier acts as a "trap" for System 1. Misleading names cause fast, confident errors. Accuracy improves significantly only when participants slow down to verify logic (System 2).

C. Language-Specific Vulnerabilities

JavaScript: Heavily relies on identifier semantics for mental modeling. Renaming destroys these anchors, causing immediate comprehension failure.
Python: More resilient to renaming; in some cases, the removal of "distracting" semantic cues aids comprehension by forcing structural analysis. Python tasks generally showed higher baseline accuracy and robustness across obfuscation tiers compared to JavaScript.

D. Experience and Transferability

Within-Language: Experience correlates positively with accuracy in the same language (e.g., Python experience helps with Python tasks).
Cross-Language: Experience transfer is weak or negative.
- High Python experience did not help with JavaScript tasks and, in some cases, hindered performance (negative transfer).
- Experts often rely on fast System 1 patterns specific to their primary language, which can misfire when encountering obfuscated code in a different language.
- "Mixed-profile" participants (moderate experience in both) sometimes outperformed those with high experience in a single language, suggesting that over-reliance on language-specific heuristics is a liability under obfuscation.

E. Complexity Metrics

Cyclomatic Complexity (CC): A strong predictor of difficulty in JavaScript, but less so in Python.
Identifier Length: No significant correlation with performance. Misleading names (even if long) are more harmful than short, non-informative names.
Line Count: Control-flow obfuscation becomes increasingly harmful as code length increases, whereas pure renaming can sometimes be mitigated by longer code structures that provide more traceable cues.

4. Significance and Implications

For Security Researchers

Rethink Metrics: Traditional static metrics (complexity, length) fail to predict human cognitive load. Evaluations must incorporate behavioral signals like response time distributions and the split between fast/slow reasoning.
Adversarial Identifiers: Misleading names are a distinct and potent obfuscation vector that actively distorts mental models, not just noise. They should be treated as a first-class experimental factor.

For Practitioners

Context-Dependent Strategy: There is no universal "best" obfuscation.
- To defeat human analysts in JavaScript, control-flow flattening is most effective.
- In Python, renaming (especially adversarial) might be surprisingly effective or even counter-productive depending on the goal.
Threat Modeling: Obfuscation strategies must be tailored to the specific language ecosystem and the expected experience level of the adversary.

For Tool Builders

Human-Centric Deobfuscation: Tools should not just restore syntax but specifically target the cognitive bottlenecks introduced by each tier (e.g., restoring structural readability for control-flow obfuscation, or providing skepticism scaffolds for adversarial renaming).
Experience-Aware Assistance: AI assistants should detect when a user is likely falling into a "System 1 trap" (e.g., trusting misleading names) and nudge them toward deliberate verification.

Conclusion

The paper demonstrates that code obfuscation is not a simple linear barrier but a complex cognitive intervention that interacts with programming language syntax and human reasoning strategies. It proves that more obfuscation does not always equal harder comprehension; in some contexts (like Python), it can force a shift to more rigorous reasoning that improves accuracy. This necessitates a move away from purely computational metrics toward human-centric, cognitive models of security evaluation.