The Dedaub decompiler takes Ethereum Virtual Machine (EVM) bytecode and produces more readable Solidity-like code, allowing for better understanding of unverified smart contracts.
What is a Dedaub decompiler?
Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure your projects. Our technology offers most of the practical advantages of formal verification, at a fraction of the human effort, enabling thorough one-time or continual security audits. The decompiler works on runtime bytecode (not contract creation code). This bytecode is stored on-chain but can also be produced by running solc with the --bin-runtime flag. Similarly, if you're using a build system, the runtime bytecode can also be extracted from the compiler's output json, in the artifacts/build folder of your project. Use responsibly.
Why is Decompilation Required?
-
Automated, deep static analysis of contract code
-
Dynamic monitoring of a protocol (all interacting/newly deployed contracts, current on-chain state, past and current transactions)
-
Statistical learning over code patterns in all contracts ever deployed in EVM networks (Ethereum, BSC, Avalanche, Fantom, Polygon, …)
-
Human inspection of warnings raised.
How Dedaub decompile Works:
DeFi-specific analyses:
-
Is there a swap action on a DEX (Uniswap, Sushiswap, etc.) that can be attacker-controlled, with respect to token, timing manipulation, or expected returned amount? Such analyses of the contract code are particularly important to combine with the current state of the blockchain (e.g., liquidity in liquidity pools) for high-value vulnerability warnings. More on that in our “dynamic monitoring”, later.
-
Are there callbacks from popular DeFi protocols (e.g., flash loans) that are insufficiently guarded and can trigger sensitive protocol actions?
-
Are there protection schemes in major protocols (e.g., Maker) that are used incorrectly (or, more typically, with subtle assumptions that may not hold in the client contract code)?
Cryptographic/permission analyses:
-
Does a permit check all sensitive arguments?
-
Does cryptographic signing follow good practices, such as including the chain id in the signed data? (If not, is the same contract also deployed on testnets/other chains, so that replay attacks are likely?)
-
Can an untrusted user control (“taint”) the arguments of highly sensitive operations, such as approve, transfer, or transferFrom? If so, does the contract have actual balances that are vulnerable?
Statistical analyses
-
Compare the contract’s external API calls to the same API calls over the entire corpus of deployed contracts. Does the contract do something unusual? E.g., does it allow an external caller to control, say, the second argument of the call, whereas the majority of other contracts that make the same call do not allow such manipulation?
-
Such generic, statistical inferences capture a vast array of possible vulnerabilities. These include some we have discussed above: e.g., does the contract use Uniswap, Maker, Curve, and other major protocols correctly? But statistical observations also capture many unknown vulnerabilities, use of less-known protocols, future patterns to arise, etc.
Conventional analyses
-
Watchdog certainly analyzes for well-known issues, such as overflow, reentrancy, unbounded loops, wrong use of blockhash entropy, delegate calls that can be controlled by attackers, etc. The challenge is to make such analyses precise.
Follow this blogs and video for more information about Dedaub:
The Dedaub Watchdog Service. Secure smart contracts with… | by Yannis Smaragdakis | Dedaub
Dedaub | Watchdog
https://www.dedaub.com/blog
FAQ regarding Dedaub decompile:
Q1: How can I contact you for questions or support?
A1: Contact us at Dedaub | Contact
Q2: What is the default sorting order of contracts? What are the ones I see when I first enter?
A2: Contract-Library continuously decompiles all installed contracts on Ethereum, Fantom, and other EVM-based blockchains. By default, the contracts are ordered by creation block number, so the first page typically shows very fresh contracts, with zero ether balance and no source code available. Contracts with a lot more attributes can be found in later pages or by searching.
Q3: The contract I care about is not decompiled or is not decompiled well. Is there anything I can do?
A3: You can contact us and let us know. Contracts are decompiled and analyzed using automatically chosen settings, designed for maximum throughput. These include, e.g., timeout limits and choice of faster/less precise algorithms if a contract's metrics suggest it is complex. Once we know there is interest in a specific contract, we can change the settings until it is successfully decompiled and analyzed.
Q4: How quickly is contract-library updated?
A4: contract should appear on contract-library within seconds of its creation. Its source code and ETH balance may not be updated until much later, however. Contract-library provides links to most popular blockchain explorers and decompilers, so that you can explore the contract’s status and code at any time, using the best information anyone has at the moment.
Q5: How reliable is the contract decompilation shown?
A5: The decompiled code is just presenting in human-readable form the internal representation of the analysis. Some elements may be skipped, if they don’t straightforwardly map to code we can display. Generally, our emphasis is not on producing a decompiler, but on producing analyses for vulnerabilities. The best code inspection is on contract source code, when available. Also, for each contract, contract-library offers links to other popular decompilers (Eveem, EtherVM) so you can get as much information as possible.