Insecurity Through Obscurity: Veiled Vulnerabilities in Closed-Source Contracts

arXiv:2504.13398 · cs.CR · Submitted 2026-08-10 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "Insecurity Through Obscurity: Veiled Vulnerabilities in Closed-Source Contracts".

Jane: The paper was written by Sen Yang, Kaihua Qin, Aviv Yaish and Fan Zhang from Yale University and University of Warwick.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Jane: We also have Lu with us today — senior AI researcher at Tsinghua.

Tom: We also have Meng with us today — lead engineer at a mysterious AI startup.

Jane: We also have Lalam with us today — the in-house Large Language Model.

Tom: Alright, let's get started.

Title: Tom: Welcome back to the show, everyone. Today we're digging into a paper that's got a fantastic, almost ominous title: "Insecurity Through Obscurity: Veiled Vulnerabilities in Closed-Source Contracts." Jane, I have to say, just reading that title gave me a chill.

Jane: It should, Tom, because it flips a very old idea on its head. We've all heard of "security through obscurity"—the notion that if you hide how something works, it's safer. This paper argues that, at least for these smart contracts, hiding the code actually makes them more vulnerable, not less.

Tom: Right, and that's so counterintuitive. You'd think a closed-source contract, where the code is hidden, would be harder to attack. But the authors are saying the opposite. They're saying the obscurity itself is the problem.

Jane: Exactly. The paper's authors—Sen Yang, Kaihua Qin, Aviv Yaish, and Fan Zhang—they focused on something called MEV bots. These are automated programs on the Ethereum blockchain that look for trading opportunities, like arbitrage. They're often closed-source because the people running them don't want their strategies copied.

Tom: And because they're closed-source, the researchers couldn't just read the code. They had to analyze the raw bytecode, which is like trying to understand a book by looking at the ink patterns on the pages. And to make it worse, some of these contracts are deliberately obfuscated, meaning the code is scrambled to make it even harder to read.

Jane: So the researchers built a tool to unscramble that code, and what they found is pretty alarming. They looked at over six thousand five hundred of these MEV bots and found over a thousand of them had vulnerabilities that could let an attacker steal their funds. We're talking about a potential loss of over ten million dollars.

Tom: Ten million dollars just sitting there, waiting for someone to figure out the puzzle. And the crazy part is, the obfuscation didn't protect them. It just made it so the developers couldn't see the flaws themselves.

Jane: That's the "insecurity" part of the title. The developers thought they were hiding their code to protect their profits, but they were really just hiding the cracks in their own armor. The attackers, who are often just as clever, can still find a way in.

Tom: It's like locking your front door but leaving the key under the mat because you think no one will look there. And then being surprised when someone finds it.

Jane: Exactly. And this isn't just a theoretical problem. The paper also found over a hundred real-world attacks that used these exact vulnerabilities, costing the victims nearly three million dollars. So this isn't a hypothetical risk; it's happening right now.

Tom: So the title isn't just a clever phrase. It's a warning. Hiding your code isn't a security strategy; it's a liability.

Jane: And that's the big takeaway for anyone listening who might be thinking about building on a blockchain. You can't just assume that because your code is hidden, it's safe. You have to actually test it, and that's what we're going to talk about next.

Tom: Stay tuned, because we're about to get into how they actually cracked these contracts and found the vulnerabilities.

Summary: Jane: Alright, so we've established that hiding code is a bad idea. But how did the researchers actually go about finding these hidden flaws? That's what I want to dig into now, Tom.

Tom: And it's a great story, because they had to overcome two huge hurdles. First, the code was obfuscated, which as we said, is like a puzzle. Second, even if you can read the code, these contracts are so complex that normal analysis tools just give up.

Jane: So they built a tool called skanf. And the first thing it does is tackle the obfuscation. The paper explains that these contracts use something called "indirect jumps." Normally, a program knows exactly where it's going next, but these obfuscated contracts calculate the next step at runtime, making it impossible to trace the flow statically.

Tom: Right, it's like a choose-your-own-adventure book where the page numbers are written in invisible ink. But skanf has a clever trick. It rebuilds what they call a "branch table." It looks at all the possible places the code could jump to, and it rewrites the code so that every jump is explicit.

Jane: That's the deobfuscation step. And once they can see the control flow, they have a second problem: these contracts are massive. They have tons of different functions and interact with other contracts, so running a full analysis would take forever.

Tom: That's where the "transaction-seeded" part comes in. This is the part I found really clever. Instead of starting from scratch, skanf looks at the contract's historical transactions. These are real transactions that actually happened on the blockchain.

Jane: And those transactions are like a map. They show you the paths that actually work. So skanf uses them as starting points for its symbolic execution, which is a fancy way of saying it traces through the code with symbolic inputs to see what conditions are needed to reach certain parts of the code.

Tom: So instead of exploring every possible path, which would be like trying to find a needle in a haystack by looking at every single piece of straw, it focuses on the paths that are actually used. That makes the analysis a thousand times faster.

Jane: And what does it find? It's looking for "asset management vulnerabilities." That means places in the code where an attacker could trick the contract into sending out its tokens to the wrong person.

Tom: And they found a lot. Out of six thousand five hundred fifty-four MEV bots, they identified one thousand forty-six that had these vulnerabilities. And for three hundred ninety-four of them, they were able to automatically generate a working exploit that would drain the contract's funds.

Jane: So they didn't just find the flaw; they proved they could exploit it. That's a huge difference. It's the difference between saying "your door is unlocked" and actually walking in and taking the TV.

Tom: And the potential losses are staggering. They calculated that if all those exploits were carried out, the attackers could have walked away with over ten and a half million dollars.

Jane: That's the scale of the problem. And it really makes you wonder, how many of these bots are just ticking time bombs?

Tom: That's the question, isn't it? And it's one we'll get into more when we talk about what can be done about it.

Improvements: Jane: So we've got a thousand vulnerable contracts and a tool that can exploit them. That's the bad news. But what's the good news? What can we actually do about it?

Tom: Well, that's where the "improvements" part of our discussion comes in. The paper doesn't just identify the problem; it shows how a tool like skanf can be used to fix it. And the first improvement is for the developers themselves.

Jane: Right, so instead of waiting for an attacker to find the flaw, developers can run skanf on their own contract before they even deploy it. It's like a spell-checker for your code, but instead of catching typos, it catches ways to lose millions of dollars.

Tom: And it's not just for new contracts. The paper shows that skanf can analyze historical versions of contracts too. So if a bot has been updated over time, you can go back and check if any of the old versions were vulnerable.

Jane: That's a big deal because these bots often hold assets across multiple versions. If an old version is still holding tokens, it's a sitting duck.

Tom: But the improvements go beyond just finding the bugs. The paper also talks about the design philosophy. They found that many of these vulnerabilities come from a lazy shortcut: using `tx.origin` for access control.

Jane: And for our listeners who aren't blockchain experts, `tx.origin` is the address that started the whole transaction. The problem is, if a contract checks `tx.origin`, it can be tricked. An attacker can create a phishing contract that calls the vulnerable contract, and since the `tx.origin` is still the victim, the check passes.

Tom: It's like a bank checking your ID at the door, but then letting anyone in who says they're with you. The paper suggests that developers need to use more rigorous checks, like verifying the exact address of the caller, even if it costs a bit more gas.

Jane: And that's the trade-off. Being more secure costs a little more in transaction fees. But as the paper shows, the cost of a breach is way, way higher.

Tom: And there's another improvement here that I think is really important. The paper's tool, skanf, is open-source. So it's not just for the researchers. Anyone can use it to check their own contracts or even to audit contracts they're thinking about interacting with.

Jane: That's a powerful idea. Imagine a world where you can check the security of a contract the same way you'd check the safety rating on a car before you buy it.

Tom: And that leads to the biggest improvement of all: prevention. If developers use these tools, and if the community demands better security, then we can stop these attacks before they happen, instead of just cleaning up the mess afterward.

Jane: So the improvements aren't just about patching holes. They're about changing the culture of development.

Tom: And that's a change that could save millions of dollars and make the whole ecosystem safer for everyone. But is that realistic? Let's bring in our guests to get their take.

Conclusion: Tom: Well, we've covered a lot of ground today on "Insecurity Through Obscurity: Veiled Vulnerabilities in Closed-Source Contracts." We've seen how hiding code makes it more vulnerable, how the researchers built a tool to find those vulnerabilities, and how that tool can be used to prevent attacks.

Jane: And I think the biggest takeaway is that the old adage is wrong. Security through obscurity isn't security at all. It's just a delay. And in the fast-moving world of blockchain, that delay can be measured in lost millions.

Tom: The paper really drives home the point that transparency and rigorous testing are the only real defenses. And that's a lesson that goes beyond just smart contracts.

Jane: Absolutely. It applies to any software. If you hide your code because you're afraid of attacks, you're also hiding it from the people who could help you find the bugs.

Tom: So as we say goodbye to this paper, let's remember the numbers: one thousand forty-six vulnerable contracts, three hundred ninety-four exploitable ones, and over ten million dollars at risk. That's not just a statistic; that's a wake-up call.

Jane: And for the developers out there, the message is simple. Use the tools, test your code, and don't rely on obscurity to save you. Because it won't.

Tom: Well said, Jane. And with that, we're going to wrap up our discussion on "Insecurity Through Obscurity." Thanks to everyone for listening, and we'll be back next time with another fascinating paper from the arXiv.

Jane: Until then, stay curious, and stay secure. Goodbye, everyone!

Sen Yang, Kaihua Qin, Aviv Yaish, Fan Zhang

Yale University · University of Warwick

cs.CR

Submitted: 2026-08-10

Comments: Published in ACM CCS 2026

DOI: 10.1145/3830454.3832723

Code: https://github.com/hackingdecentralized/skanf

Project page: https://ethereum.github.io/yellowpaper/paper.pdf

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 74/100

Key concepts

Security through obscurity: The idea that hiding how a system works makes it safer is proven false by the paper. The authors argue that for closed-source smart contracts, hiding the code actually increases vulnerability, not decreases it.
MEV bots: These are automated programs on the Ethereum blockchain designed to find trading opportunities, such as arbitrage. They are often kept closed-source to prevent their specific strategies from being copied by competitors.
Obfuscation: The process of scrambling code to make it extremely difficult for humans or tools to read. The paper found that this obfuscation made it harder for developers themselves to find flaws, but it did not protect the system from attackers.

Terminology

Pruning — 10× in this paper · explained in 4 episodes
Trace — 8× in this paper · explained in 2 episodes
IEEE Symposium on Security and Privacy — 6× in this paper
Computer and Communications Security — 5× in this paper
Maximal Extractable Value — 5× in this paper
Verification — 5× in this paper · explained in 2 episodes
Automated Software Engineering — 4× in this paper
Core — 4× in this paper · explained in 2 episodes
Ablation — 2× in this paper · explained in 1 episode
Accuracy — 2× in this paper · explained in 1 episode
Actor — 2× in this paper · explained in 3 episodes
Analyzer — 2× in this paper · explained in 1 episode
Cumulative Distribution Function — 2× in this paper
Smart Contract Weakness Classification — 2× in this paper
Application Binary Interface — 1× in this paper
Benchmark — 1× in this paper · explained in 2 episodes
Ethereum Virtual Machine — 1× in this paper
Intermediate Representation — 1× in this paper
International Conference on Software Engineering — 1× in this paper
International Symposium on Software Testing and Analysis — 1× in this paper
Network and Distributed System Security Symposium — 1× in this paper
Regret — 1× in this paper · explained in 3 episodes

Summary

Summary

This paper, titled Insecurity Through Obscurity: Veiled Vulnerabilities in Closed-Source Contracts, investigates the security risks of closed-source and obfuscated smart contracts on Ethereum, particularly focusing on MEV (Maximal Extractable Value) bots. The authors argue that while obfuscation is often used to protect proprietary logic, it can paradoxically introduce insecurity by hindering analysis, a phenomenon they term insecurity through obscurity.

The paper's central contribution is the design and implementation of skanf, a novel EVM bytecode analysis tool tailored for closed-source and obfuscated contracts. skanf combines control-flow deobfuscation with symbolic execution based on historical transactions to identify and exploit asset management vulnerabilities.

The paper addresses three research questions:

RQ1: How to effectively deobfuscate the control flow given smart contract bytecode.
RQ2: How to scale vulnerability detection to complex closed-source contracts.
RQ3: How many MEV bot contracts have been exploited in practice, and how much did they lose.

To address these challenges, skanf employs three key methods:

Control-flow deobfuscation: The authors observe that valid jump destinations in the EVM must be marked with JUMPDEST. This property allows them to rebuild jump tables and instrument the bytecode with a branch table, converting indirect jumps into direct, statically analyzable ones.
Transaction-seeded symbolic execution: skanf uses public historical transactions as high-quality concrete seed inputs to guide symbolic execution, mitigating path explosion and improving efficiency. This is a smart-contract-specific realization of seeded symbolic execution.
Vulnerability detection via taint analysis: The tool combines symbolic execution with taint analysis to identify vulnerable CALL instructions that adversaries can trigger with malicious parameters, including cases where only critical parameters are adversary-controlled.

The evaluation of skanf on real-world MEV bots yields significant findings:

Deobfuscation effectiveness (RQ1): skanf effectively addresses control-flow obfuscation. For 90% of contracts with initial code coverage below 50%, skanf successfully increases code coverage. For instance, among the top 10 most active MEV bots, six are highly obfuscated (coverage below 10%), and skanf increases coverage to 100% for five of them.
Vulnerability detection (RQ2): skanf identifies 1,046 vulnerable contracts from a dataset of 6,554 MEV bots. It successfully generates exploits for 394 of them, with potential losses exceeding 10.6 million. The tool outperforms state-of-the-art tools like Mythril, ETHBMC, JACKAL, and Securify in detecting these vulnerabilities.
Attacks in the wild (RQ3): The authors discovered 104 real-world MEV phishing attacks that resulted in approximately 2.76 million in losses. Only three of these attacks had been previously reported. skanf detects asset management vulnerabilities in most of the exploited contracts and could have prevented losses totaling 2.45 million.

The paper also identifies a new attack pattern called MEV phishing attacks, categorizing them into token-based, pool-based, and refund-based attacks. These attacks involve adversaries creating malicious tokens, pools, or refund addresses to lure searchers into interacting with attacker-controlled contracts, thereby bypassing access controls and stealing assets.

The authors conclude that skanf is effective in detecting vulnerabilities in closed-source and obfuscated smart contracts, and its use could have prevented significant financial losses. They also discuss the tradeoff between cost and security, noting that rigorous access control mechanisms can be expensive, and highlight the benefits of skanf for developers and auditors in settings where bytecode-level analysis is necessary.

Improvements for AI systems

Based on the scientific paper, here are specific improvements I can make to AI systems, along with what the improved systems can do:

Improvement: Integrate the paper's branch-table reconstruction technique into AI-powered static analysis and symbolic execution tools (e.g., Mythril, Gigahorse, Slither). The module identifies indirect jumps (JUMP/JUMPI with runtime-computed destinations) and rewrites them into explicit conditional branches using a crafted branch table at PC 0xe000, preserving stack semantics (e.g., SWAP1 for JUMPI, POP for cleanup).

What the improved AI system can do:

Analyze closed-source, obfuscated EVM bytecode that previously caused path explosion or misclassification (e.g., code coverage increased from <10% to 100% for 5 of top 10 MEV bots).
Recover control flow for contracts using indirect jumps derived from calldata, storage, or memory, enabling downstream vulnerability detection.
Avoid bytecode offset shifts by applying transformations at the CFG level rather than raw bytecode, ensuring compatibility with existing decompilers.

These improvements enable AI systems to analyze obfuscated, closed-source smart contracts at scale, detect and exploit asset management vulnerabilities, and quantify real-world risks—capabilities that current tools lack, as demonstrated by the paper's evaluation on 6,554 MEV bots.

Abstract

Most blockchains cannot hide the binary code of programs (i.e., smart contracts) running on them. To conceal proprietary business logic and to potentially deter attacks, many smart contracts are closed-source and in many cases exhibit code obfuscation, either intentionally introduced to hide internal logic or unintentionally produced by optimizations. However, we demonstrate that such obfuscation can obscure critical vulnerabilities rather than enhance security, a phenomenon known as insecurity through obscurity. To systematically analyze these risks on a large scale, we present SKANF, a novel EVM bytecode analysis tool tailored for closed-source and obfuscated contracts. SKANF combines control-flow deobfuscation with symbolic execution based on historical transactions to identify and exploit asset management vulnerabilities. Our evaluation on real-world Maximal Extractable Value (MEV) bots reveals that SKANF detects vulnerabilities in 1,046 contracts and successfully generates exploits for 394 of them, with potential losses of 10.6M. Additionally, we uncover 104 real-world MEV bot attacks that collectively resulted in 2.76M in losses.

Sources

Vandal: A Scalable Security Analysis Framework for Smart Contracts