Four years ago, I wrote an article “How to steal Bitcoins” that was about finding address corresponding to weak brainwallets, and some forensic evidence that it was exploited automatically, for profit.

This article is about Ethereum smart contracts, how you can automatically find bugs in them allowing you to steal money. I will also present forensic evidence that it happens in the wild.

Smart contracts¶ Smart contracts are programs (executable code) that are stored in the Ethereum blockchain. That means that they are all publicly accessible! These program are also “accounts” that can own money. Once created, the smart contract’s code is immutable, and it is the sole owner and manager of its own funds. Its code can call functions to receive and send money. They are implemented in EVM bytecode (for Ethereum Virtual Machine). It’s a bit of an exotic architecture, and it’s purely a stack machine, but unlike x86 bytecode it is very simple. The EVM is described in Ethereum’s yellow paper. The interactions with the environment are very limited (you can call other contracts, send/receive money but that’s pretty much it). Because execution cost fees (called gas), these contracts are generally very simple, which make them perfect for automatically analyzing them. Assuming you have Ether to pay for transaction fees, you can call any contract that lives on the blockchain.

Symbolic execution¶ Symbolic execution is the idea of executing a program but having user-controlled input be “symbols” (representing an unknown value). When we encounter a conditional statement, we execute both branches but we take note of the “constraints” that need to be respected for that branch to run. For example, if we analyze that code: function f ( int user_input ) { if ( user_input % 2 == 0 ) { send_all_my_money (); } } There is a valid execution that calls send_all_my_money() , and it is associated with the constraint user_input % 2 == 0 . An SMT solver like Z3 knows if such a constraint is satisfiable and will give us values for user_input where it would work. I developed a tool called Pakala to do exactly that. It is slightly different than the other published tools because it first computes all the interesting execution paths that the program can take, and then try to stack these executions together to find bugs where multiple calls (executions) are needed.

Bugs we are looking for¶ My tool, Pakala, looks for two simple things: Programs that can send back more ether that they are sent.

Programs that can self-destruct themselves and give us all their money. These are basically the two ways we can get free money. Some other checks leading to arbitrary code execution could be worth adding, and are checked by other existing tools.