Journal of Information Processing Vol.29 537–547 (Sep.

2021)
[DOI: 10.2197/ipsjjip.29.537]

Recommended Paper

RA: A Static Analysis Tool for Analyzing Re-Entrancy

Attacks in Ethereum Smart Contracts

Yuichiro Chinen1,a) Naoto Yanai1,b) Jason Paul Cruz1,c) Shingo Okamura2,d)

Received: November 11, 2020, Accepted: June 7, 2021

Abstract: Ethereum smart contracts are programs that are deployed and executed in a consensus-based blockchain
managed by a peer-to-peer network. Several re-entrancy attacks that aim to steal Ether, the cryptocurrency used in
Ethereum, stored in deployed smart contracts have been found in the recent years. A countermeasure to such attacks
is based on dynamic analysis that executes the smart contracts themselves, but it requires the spending of Ether and
knowledge of attack patterns for analysis in advance. In this paper, we present a static analysis tool named RA (Re-
entrancy Analyzer), a combination of symbolic execution and equivalence checking by a satisfiability modulo theories
solver to analyze vulnerability of smart contracts to re-entrancy attacks. In contrast to existing tools, RA supports
analysis of inter-contract behaviors by using only the Ethereum Virtual Machine bytecodes of target smart contracts,
i.e., even without prior knowledge of attack patterns and without spending Ether. Furthermore, RA can verify existence
of vulnerability to re-entrancy attacks without execution of smart contracts and it does not provide false positives and
false negatives. We also present an implementation of RA to evaluate its performance in analyzing the vulnerability of
deployed smart contracts to re-entrancy attacks and show that RA can precisely determine which smart contracts are
vulnerable.

Keywords: ethereum, smart contracts, static analysis, EVM, symbolic execution, SMT solver

tracts can be utilized permanently as a springboard of attacks.

1. Introduction Indeed, many attacks [5] and honeypots [32] on Ethereum have
1.1 Backgrounds been found in the past years.
Ethereum, which is often described as “the world computer,” is Security Analysis of Smart Contracts: Based on these back-
a global, open-source platform for decentralized applications and grounds, program analysis for the security of Ethereum smart
execution of programs called smart contracts, which are software contracts is an urgent and significant research theme. In this
programs recorded on the Ethereum blockchain *1 and executed paper, we focus on the analysis of EVM bytecodes of smart
in the Ethereum Virtual Machine (EVM). The EVM is a virtual contracts instead of their corresponding source codes. Analysis
machine that runs codes called EVM bytecodes and is the runtime of bytecodes brings a couple of advantages. First, the analysis
environment for smart contracts in Ethereum. Ethereum enables of EVM bytecodes is independent of a high-level language that
developers to build smart contracts with built-in functions and is periodically updated. For instance, the Solidity language [2],
gain the benefits of cryptocurrency and blockchain technologies. which is one of the major languages used for writing Ethereum
Research Motivation: The blockchain is decentralized and smart contracts, is often updated and offers different capabilities
transparent by nature, and thus anyone can read the bytecodes for different versions. Consequently, a tool that was developed to-
of deployed contracts. Moreover, smart contracts typically con- day for the analysis of contracts written in Solidity before they are
tain financially valuable data and therefore create a criminogenic deployed may not be applicable for analysis of contracts written
environment for adversaries. The attack on “The DAO” on June in future versions of Solidity. In fact, deployed contracts have dif-
2016 is the most infamous case of an attack on smart contracts. ferent versions of Solidity depending on their application and on
In the attack, a vulnerability called re-entrancy, where the main the features of the Solidity language they require or use. There-
contract calls an external contract which again calls into the call- fore, the analysis of EVM bytecodes is more desirable than the
ing contract within a single transaction, was utilized to steal more analysis of Solidity and other high-level languages. Second, the
than 60 million US Dollars worth of Ether. With the transparency analysis of a high-level language, such as Solidity, requires an
of the Ethereum blockchain, the vulnerabilities of deployed con- analyst to input a copy of the actual source codes of the analy-

1
Osaka University, Suita, Osaka 565–0871, Japan The preliminary version of this paper was published at Computer Se-
2
National Institute of Technology, Nara College, Yamatokoriyama, Nara curity Symposium 2019 (CSS2019), Oct. 2019. The paper was recom-
639–1080, Japan mended to be submitted to Journal of Information Processing (JIP) by
a)
t-yuichiro@ist.osaka-u.ac.jp the chief examiner of SIGCSEC.
b) *1
yanai@ist.osaka-u.ac.jp Hereafter, “contract” and “smart contract” are used interchangeably but
c)
cruz@ist.osaka-u.ac.jp have the same meaning. Likewise, “the blockchain” will be used to refer
d)
okamura@info.nara-k.ac.jp to the Ethereum blockchain, unless otherwise specified.


c 2021 Information Processing Society of Japan 537
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

sis targets. If a developer will only analyze the Solidity source was presented at IEEE Blockchain 2020. In the previous work,
codes he/she develops, then a tool that analyzes Solidity source we presented an analysis tool named RA and evaluated its per-
codes will suffice. However, such a tool cannot be used if a user formance. In this paper, we evaluate the performance of RA in
wants to analyze other deployed contracts but he/she does not a theoretical fashion. We also include additional related works
have the corresponding source codes. In contrast, users can ob- from literature.
tain the EVM bytecodes of deployed contracts directly from a
blockchain explorer even if the corresponding source codes are 1.2 Contributions
unpublished and analyze their vulnerabilities anytime. Thus, us- In this paper, we present a new static analysis tool named Re-
ing static analysis of EVM bytecodes, analysts can easily judge entrancy Analyzer (RA) for analyzing EVM bytecodes of smart
whether a deployed contract has benign or malicious codes, e.g., contracts. RA can analyze re-entrancy vulnerabilities via inter-
vulnerable or honeypots. contract flows, for instance, by creating a new contract and call-
In early literature on analysis of EVM bytecodes, formal veri- ing a different function in the main contract via an external con-
fication [6], [16], [18], [19], [33] is a leading approach for verify- tract. RA does not require analysts to have prior knowledge of
ing a specification of bytecodes and symbolic execution [8], [21], the attack patterns and pay Ether for analysis, and it does not
[23], [26], [31] is used for exploring bytecodes in a depth-first provide false positives and false negatives. These advantages
search fashion by extracting control flow graphs (CFGs). Ac- are achieved via integration of symbolic execution and equiva-
cording to Weiss et al. [35], rigid formal verification is often dis- lence checking with a satisfiability modulo theories (SMT) solver.
missed as it puts too high demands on analysts who are not ex- Furthermore, we provide an implementation of RA and evalu-
perts in formal verification. On the other hand, symbolic exe- ate it by utilizing publicly available reference implementations
cution can potentially support analysis of vulnerabilities via ex- of re-entrancy vulnerabilities [1], [2], [29]. Our results confirm
traction of CFGs. Several prior works [23], [26], [31] succeeded that, unlike Oyente [23], RA can analyze precisely the vulner-
in analyzing some vulnerabilities, such as to re-entrancy attacks. ability of deployed contracts to state-of-the-art re-entrancy at-
However, symbolic execution only outputs CFGs from programs tacks [29]. We have released the source codes of RA via GitHub
to be analyzed and does not support detection of the vulnerabil- (https://github.com/wanidon/RA) for reproducibility and as refer-
ities themselves. Accordingly, analysis becomes often heuristic ence for future works.
if an infeasible path exists in the programs. In particular, analy- Our main contribution is the creation of a new symbolic execu-
sis results may produce many false positives and false negatives tion method named symbolic re-entrancy emulation, which em-
because of an infeasible path [7]. ulates re-entrancy attacks by connecting different contracts with
A recent work [29] has found re-entrancy attacks that under- each other. As will be described in detail in Section 3, Oyente
mine existing analysis tools [19], [23], [33] by creating a new and its extensions [19], [33] do not support inter-contract analy-
contract or calling a different function via an external contract. sis, for example, CFGs become fragments. On the other hand, we
Although a monitoring tool was also proposed in the same pa- developed a module that localizes stored data on the blockchain
per as a countermeasure against those attacks, the tool performs in each execution path and a module that stacks a return address
monitoring based on dynamic analysis and is therefore unable to of an account information for each path. Using these modules,
detect vulnerabilities unless the attacks occur during program ex- RA can support inter-contract analysis and emulate the behavior
ecution. Accordingly, analysts need to implement and execute of re-entrancy attacks in a symbolic fashion via an internal im-
attack patterns by themselves in advance to check for vulnerabil- plementation of a dummy contract, i.e., a contract that executes
ities. Although generic attack patterns [12] have been presented other contracts.
formally, dynamic analysis remains impractical for analysis of As another important contribution, we developed a new
smart contracts because it often requires analysts to know how method named vulnerability verification, which verifies vulnera-
an attack is launched as well as to spend Ether for the execution bilities by utilizing the Z3 SMT solver in the CFGs obtained from
of contracts. Ideally, contracts should be analyzed based on only the symbolic re-entrancy emulation. In particular, on path condi-
their bytecodes, i.e., with the use of static analysis. tions of the obtained CFGs, our method verifies whether program
Research Goal: This paper aims to design an inter-contract behavior on paths for executions with re-entrancy attacks is iden-
static analysis tool that (1) uses only EVM bytecodes as input, tical to that without the attacks, i.e., behavior on normal execu-
(2) eliminates false negatives and false positives, and (3) does tions. Using the methods above, RA can completely eliminate
not require analysts to have a priori knowledge of the attacks on false positives and false negatives (see Section 4 for details).
contracts. For this goal, we focus on analysis of re-entrancy at-
tacks [29]. As evident in the attack on “The DAO,” re-entrancy 1.3 Paper Organization
attacks have a significant impact and many contracts have been The rest of this paper is organized as follows. A background
found to be vulnerable to these attacks [19], [23]. Considering of smart contracts and program analysis is presented in Section 2.
findings on new attacks [29] in the recent years, our research goal Re-entrancy attacks and the technical difficulties in analyzing re-
can prove to be important and useful. Moreover, the design of a entrancy attacks are discussed in Section 3. The design of RA
static analysis tool that is effective against new attacks is an open is presented in Section 4, and then its experimental evaluation
challenge [29]. is presented in Section 5. A review of related works is given in
This paper is the full version of our previous work [10] which Section 6. Finally, a conclusion is presented in Section 7.


c 2021 Information Processing Society of Japan 538
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

is more representative. By describing a specification to be ver-

2. Technical Background
ified in some logic formally, an SMT solver verifies whether a
2.1 Ethereum Smart Contracts and EVM program satisfies the given specification.
In Ethereum, there are two kinds of accounts, namely, an ex- Symbolic execution is a method that pseudo-executes a pro-
ternally owned account (EOA) and a contract account. EOAs gram by replacing information unspecified in the program itself
have a private key that can be used to access the corresponding with symbolic values to represent any value. Symbolic execu-
Ether or contracts. A contract account has smart contract code, tion is composed of CFGs and an SMT solver, and it is suitable
which an EOA cannot have, and it does not have a private key. for analysis of smart contracts given that smart contracts utilize
Instead, it is owned and controlled by the logic of its smart con- information on blockchains which are outside of program codes.
tract code. In Ethereum, a smart contract refers to an immutable Specifically, a condition to execute a path is called a path con-
computer program that is deployed on the blockchain and runs dition. Path conditions at the beginning of program execution
deterministically in the context of the EVM. The immutability are valid, and a restriction is newly added to the path conditions
property indicates that, similar to any data published on a general when a branch occurs. In a case where a path condition contains
blockchain, smart contract codes can be considered as trustwor- a symbolic value, executing either one or both paths according to
thy, i.e., once deployed, they cannot be changed or deleted. The a condition, i.e., the condition is satisfied or not, is decided by
deterministic property indicates that the execution of the coded checking the satisfiability of the condition. Path conditions are
functions of smart contracts will produce the same result for any- often represented by first-order predicate logic, and their satisfia-
one who runs them. Once deployed on the blockchain, a contract bility is decided by an SMT solver described above.
is self-enforcing and managed by the peers in the network, i.e.,
3. Motivating Example and Technical Difficul-
its functions are executed when the conditions in the contract are
met. A smart contract is given an identity in terms of a contract ties
address. Using this address, it can receive Ether and its functions In this section, we recall the fallback function and the re-
can be executed. A contract is invoked when its contract address entrancy attacks shown by Rodler et al. [29] as our motivating
is the destination of a transaction, which is a signed message orig- example and then discuss the technical difficulties in the analysis
inating from an EOA, transmitted by the network, and recorded of the attacks.
on the blockchain. Such a transaction causes a contract to run in
the EVM using the transaction (and transaction’s data) as input. 3.1 Re-entrancy Problem
The data indicate which specific function in the contract to run 3.1.1 Fallback Function
and what parameters to pass to that function. To incentivize peers Functions in Solidity are similar to classes in object-oriented
to execute contract functions, Ethereum relies on gas, which is languages. There are four types of Solidity functions, namely,
paid in Ether, to “fuel computations”. The amount of gas needed external, internal, public, and private. A contract can
to execute a transaction is relative to the complexity of the com- have exactly one unnamed function called a fallback function,
putations, thus also preventing infinite loops. which cannot have any arguments, cannot return anything, and
Smart contracts are typically written in a high-level language should have external visibility. The fallback function of a contract
such as Solidity [2]. The source code is then compiled to low- is executed whenever the contract receives Ether without any data
level bytecode that runs in the EVM. The EVM is a simple stack- included. To receive Ether and add it to the total balance of the
based architecture. Its instruction set is kept minimal to avoid contract, the fallback function must be marked payable. If the
incorrect implementations that could cause consensus problems. contract does not have a fallback function, then it cannot receive
The EVM is a global singleton, i.e., it operates like a global, Ether through regular transactions and throws an exception. In
single-instance computer that runs in all peers in the network. other words, if a contract is intended to not receive Ether, then
Each peer runs a local copy of the EVM to validate the execution the payable in the fallback function can simply be removed. The
of contract functions, and the processed transactions and smart fallback function is also triggered if someone tries to call a func-
contracts are recorded on the blockchain. tion that does not exist in the contract, and is often utilized for
re-entrancy attacks.
2.2 Static Analysis of Programs 3.1.2 Create-Based Re-Entrancy Attack
This paper focuses on the use of static analysis composed of CREATE is an instruction that creates a new contract during
CFGs, SMT solver, and symbolic execution. A CFG represents execution of a contract (we call this the original contract for con-
feasible paths of a program as a graph and is utilized for opti- venience). The new contract consists of initialization codes and
mization by a compiler and static analysis of programs. Paths in the codes of its functions, and these codes are allocated by follow-
a manner of sequential execution without branches are called ba- ing a STOP instruction of the original contract. Once the initial-
sic blocks and are identical to nodes of a CFG. Likewise, paths ization codes are executed, data is initialized and then bytecodes
which are feasible via branches or jumps are represented by edges of the new contract are returned. These transitions via the initial-
to connect with nodes. ization codes can be viewed as function calls by CREATE. When-
An SMT solver is a tool used for SMT problems. In contrast ever a new contract is created, its constructor will be executed
to satisfiability problems represented by proportional logic, SMT immediately. In the attacks by Rodler et al. [29], a newly gener-
problems are represented by the first-order predicate logic which ated contract by CREATE can issue further calls in its construc-


c 2021 Information Processing Society of Japan 539
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

tor to other contracts, including malicious contracts, via CALL in false positives and false negatives, analysis tools should include
the initialization codes. Here, the victim contract first creates a a method that can evaluate vulnerabilities without requiring ana-
new contract and then updates its internal state. The newly cre- lysts to have prior knowledge of the attacks.
ated contract then calls a contract owned by an adversary. Con-
4. Design of RA
sequently, the adversary maliciously withdraws from the victim
contract via the re-entrancy. In this section, we present Re-entrancy Analyzer (RA), a new
3.1.3 Cross-Function Re-Entrancy Attack static analysis tool for re-entrancy attacks on Ethereum smart
Whenever function calls in which Ether is sent to an exter- contracts. We first describe our design concept and then describe
nal contract account are executed, transactions are created by the symbolic re-entrancy emulation and vulnerability verification as
CALL instruction. In doing so, some data are sent together with main processes, including their implementation.
the transaction. The four most significant bytes correspond to a
function ID of a caller function, which is obtained from a function 4.1 Design Concept
name and a type name of variables. The callee contract obtains The main idea of RA is to combine symbolic execution and an
the function ID of the caller contract from the received transac- SMT solver in a dual way, i.e., symbolic re-entrancy emulation
tion and then decides a function to be executed by checking if the and vulnerability verification.
ID is identical to that owned by the callee contract. If the callee First, modules that emulate re-entrancy attacks based on sym-
contract does not own a function ID specified by a transaction, a bolic execution are developed. Loosely speaking, by using an
fallback function is executed as described above. Cross-function SMT solver to verify if conditions for calling to an external con-
re-entrancy attacks proposed by Rodler et al. [29] are launched tract and generating basic blocks are satisfied, RA can identify
over multiple functions of the victim contract. Specifically, cross- which function is called. Consequently, RA can find path con-
function re-entrancy attacks are launched by re-entering the same ditions via symbolic execution, which transits executions to each
contract via a different function, whereas classical re-entrancy at- basic block recursively. Second, by utilizing the path conditions
tacks are launched by re-entering the same contract via the same obtained from the emulation process above, RA verifies if a resul-
function. tant running state of a function call based on a fallback function
is equivalent to the original behavior, i.e., without the fallback
3.2 Technical Difficulties function, on the CFG obtained from the emulation. The verifi-
We present some technical issues that need to be solved for the cation is done by the SMT solver. While symbolic executions in
analysis of the attacks described in the previous subsection. First, literature [19], [23], [33] report only program behavior via CFGs
existing tools [19], [23], [33] do not provide support for generat- obtained within a single contract, RA emulates re-entrancy at-
ing running states of a callee contract via opcodes such as CRE- tacks including inter-contract behavior and then it verifies the
ATE and CALL, which utilize an external contract. Consequently, vulnerability of these contracts to re-entrancy attacks. Conse-
in these tools, a caller contract is unidentified uniquely from the quently, in contrast to the early literature, while the coverage of
standpoint of a callee contract and vice versa. More concretely, in the analysis for re-entrancy attacks has improved drastically, RA
the reference implementation of re-entrancy attacks [29], an ini- can analyze the vulnerabilities precisely, i.e., without false pos-
tialization code for the create-based re-entrancy attack is executed itives and false negatives and without requiring analysts to have
in the aforementioned manner. In doing so, the initialization code prior knowledge of attack patterns, including state-of-the-art re-
is on an infeasible path for existing tools. Moreover, because the entrancy attacks [29].
main body of the created code is determined by a return value
from the initialization code, the contract by CREATE is infeasi- 4.2 Tool Overview
ble unless the initialization code is analyzed. Thus, the behavior The overview of RA is as follows. First, for the symbolic re-
of the created contract including CALL is unknown during offline entrancy emulation, RA generates CFGs from bytecodes whereby
analysis. Likewise, when an external contract is called by CALL a newly created/called contract is represented within a flow of the
for the cross-function re-entrancy attacks [29], analysis should be main contract via symbolic execution. Then, for vulnerability
executed independently for each contract because running states verification, RA verifies whether the bytecodes are vulnerable to
of a callee contract are not generated. Consequently, utilizing re-entrancy attacks by utilizing the Z3 SMT solver in accordance
path conditions for a caller contract is no longer meaningful to with path conditions obtained from the symbolic re-entrancy em-
analyze the behavior of a callee contract. Furthermore, there are ulation. To do this, the following notions are defined for RA:
many candidates of function combinations, and thus analyzing • Local-world state is owned by a basic block in local and
vulnerability to cross-function re-entrancy attacks becomes diffi- stores global information, such as balance or storage.
cult due to the potential state explosion [29]. • Call stack is a stack that stores a return address to a basic
Second, a method that evaluates vulnerabilities should be con- block.
sidered as well. Several analysis tools [7], [23], [26] report fea- • Contract queue is a queue that stores bytecodes of a contract
sible paths but do not provide evaluation and detection of vul- to be analyzed.
nerabilities. Accordingly, analysts often need to determine if An overview of RA including the notions is presented in Fig. 1.
a contract is vulnerable in a heuristic fashion, and hence many RA mainly consists of three modules, namely, CFManager, VM,
false positives and false negatives are produced. To eliminate and Verifier. The symbolic re-entrancy emulation process is


c 2021 Information Processing Society of Japan 540
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

Fig. 2 Process of vulnerability verification.

CREATE by specifying basic blocks via the Z3 SMT solver, and

CFManager transits the execution to those blocks in accordance
with branches decided by the Z3 SMT solver. By obtaining each
block and connecting them, CALL in the initialization code can
Fig. 1 Overview of RA.
be identified. Moreover, VM can register the callee contract ob-
mainly conducted by CFManager and VM. On the other hand, tained by the initialization code in the contract queue, and thus
the vulnerability verification process is executed by Verifier as- the whole contract can be symbolically emulated in a recursive
sisted by VM. We describe the role of each module below. manner. On the other hand, for analysis of the cross-function
CFManager handles feasible paths by directly operating data re-entrancy attacks, a function ID is symbolically executed as a
structures in a basic block for a CFG. A basic block contains the symbolic value, and then Verifier extracts the function ID to be
local-world state, the call stack, as well as mnemonic of instruc- executed by the Z3 SMT solver. By giving the ID at the begin-
tions, running states, and path conditions. These give us informa- ning execution and re-execution, combination of any functions is
tion retrieved from the blockchain and return values, i.e., infor- representative.
mation obtained as a result of each caller/callee contract. Conse-
quently, symbolic execution of each block can be covered even 4.4 Vulnerability Verification
through an external contract. First, VM receives a contract to be The vulnerability verification is done by Verifier with path con-
analyzed from the contract queue, and then CFManager executes ditions obtained from the emulation described in the previous
instructions on basic blocks. Finally, Verifier verifies existence of subsection. Let functions to be verified be f, g, where f con-
re-entrancy vulnerability by utilizing the Z3 SMT solver with the tains a function call during the execution. We also denote by I a
information obtained by VM. Based on these modules, the sym- set of path conditions where g is executed by taking over a result
bolic emulation for inter-contract analysis is provided and then in the execution of f , and by C a set of path conditions where
the verification of vulnerabilities is executed. To use RA and an- f calls a fallback function in a manner that the fallback function
alyze contracts, analysts only need to provide EVM bytecodes calls g and then f is executed again with the result of g. The Ver-
of target contracts as input and they do not need to have prior ifier module can receive I and C from the VM module. Then, the
knowledge about re-entrancy attacks. The details of each process Z3 SMT solver verifies whether a program is vulnerable or not as
are presented below. follows:

4.3 Symbolic Re-entrancy Emulation ∃c ∈ C, ∀i ∈ I : ¬(c ≡ i). (1)

The goal of this process is to generate a CFG completely via
emulation of re-entrancy attacks. In particular, the CFManager Using Eq. (1), the Z3 solver finds c ∈ C such that c is not equal
generates a CFG to represent inter-contract behavior by record- to any i ∈ I, i.e., the program is vulnerable if ¬(c ≡ i), and benign
ing basic blocks with transitions as edges. We call such a CFG otherwise.
an extended CFG (ECFG) for convenience. In ECFGs, CREATE The procedure of the vulnerability verification is shown in
and CALL instructions are utilized as separators of basic blocks Fig. 2. The withdraw process is not executed when g is exe-
in addition to JUMP and STOP instructions. For convenience, let cuted after executing f in a normal way, i.e., executions in I. On
contracts to be executed by CREATE and CALL be callers, and let the other hand, the withdraw process is executed due to the re-
contracts to be created or called be callees. When CREATE ap- entrancy on f whereby a fallback function calls g, i.e., executions
pears, the symbolic execution is transited to its callee contract, in C. RA decides that a contract is vulnerable if program behav-
i.e., the initialization code. Similarly, when CALL appears, the iors are equivalent in these executions. In particular, RA checks
execution is transited to a function of its callee contract. When if there is no case where the behaviors are equivalent. Intuitively,
STOP appears within the callee contracts described above, the the main difference between these cases is whether instructions
execution is returned to the caller contract. These transitions of following CALL in f are executed before g. Specifically, g con-
contracts are managed by VM. tains a branch that determines whether the withdraw process is
We now describe the emulation process by RA in detail. For executed in accordance with changing states on the blockchain,
instance, for analysis of the create-based re-entrancy attacks, VM where path conditions at the end of executions for both cases are
extracts an initialization code of a contract from variables of different from each other.


c 2021 Information Processing Society of Japan 541
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

4.5 Implementation given on push to a stack. A CALL instruction normally requires

The main techniques for implementing the symbolic re- push to a stack in accordance with success of a function call, i.e.,
entrancy emulation of RA are presented as the technical parts of 0 or 1. In contrast, a re-entrancy attack is always executed af-
the implementation below. In particular, we describe how ba- ter the success of a function call. Thus, RA always pushes 1,
sic blocks are controlled and function IDs are extracted to re- i.e., the success of the function call, to a stack as assumed in the
duce potential state explosion, which is one of the problems for success of CALL instruction. This enables RA to reduce the num-
static analysis tools according to Rodler et al. [29]. Several tech- ber of path conditions as a speed-up technique. Third, because
niques for improving the performance are presented as well. We CALL is required to always succeed, a constraint, i.e., a balance
released the source codes of the whole implementation publicly for any contract account is a positive value, is given on path con-
via GitHub (https://github.com/wanidon/RA). ditions only at the end states. The computational complexity can
4.5.1 Environment be reduced drastically by giving the constraint at the end states in-
RA is implemented on Python 3.7 and three modules, i.e., z3, stead of at each change of the balance. Surprisingly, for analysis
pysha3, and Graphviz. The z3 module provides APIs for the use of several contracts, the computational performance becomes ten
of the Z3 SMT solver on Python. The pysha3 module enables times faster by using this constraint although we omit the details.
the use of the Keccak256 hash function as a SHA-3 module. Fi- Finally, RA stops to analyze paths for some stop instruction with-
nally, Graphviz provides support for drawing CFGs. We also note out the rollback process. In particular, a stop instruction called
that RA is independent of any specific compiler because it uses REVERT contains the rollback about the blockchain related to
bytecodes as input. a given transaction. However, to the best of our knowledge, re-
4.5.2 Control of Basic Blocks for CFManager entrancy attacks never occur in this case, thus RA does not ana-
The method that represents a branch with a conditional jump lyze the remaining parts of such paths.
operation JUMPI is as follows. First, RA adopts the depth-first
search for finding feasible paths, and the CFManager owns a data
5. Evaluation and Discussion
structure named dfs stack which stores candidates of basic blocks In this section, we will show that RA can analyze inter-
to be searched. Then, the CFManager pops two variables for contract control flows precisely in comparison with execution of
JUMPI from the dfs stack, i.e., a jump address and a condition Oyente [23]. Then, we will show the computational performance
c for the jump where c is determined by true or false. When c of RA for analysis. Finally, we will provide a discussion on the
is a symbolic value, the z3 module decides whether ¬c is satisfi- comparison of RA with other tools and the current limitations of
able. If so, there exists a path that does not contain jump. Then, RA.
a new block is generated by copying the current basic block and
incrementing a program counter, and the new block is newly rec- 5.1 Case Studies
ognized as the basic block. Next, the solver decides whether c As case studies, we test RA with reference implementations
is satisfiable. If so, there exists a path that contains jump. Then, of the re-entrancy attacks by Rodler et al. [29] and known re-
the current basic block is copied as a jump block and the program entrancy vulnerabilities [1], [2]. The goal of these studies is to
counter is set as the jump address. In the case that there exists a clarify the ability of RA to perform inter-contract analysis. The
path with jump but a path without jump does not exist, the current codes of the reference implementations of the re-entrancy at-
basic block is set as a jump block. In contrast, if both a path with tacks [29] are publicly available *2 .
jump and that without jump exist, then the jump block itself is 5.1.1 Creation of Contracts
stored in the dfs stack. Consider the output of RA shown in Fig. A·1 *3 . On a CFG
4.5.3 Extraction of Function ID for Verifier output by RA for a contract created via CREATE, the execution
Decision of a function ID for Verifier is implemented as fol- is transited to a callee contract on the basic block (denoted by the
lows. First, a symbolic value f unction id is assigned with the red box), and the execution is returned to the basic block (denoted
four most significant bytes of any transaction. The value is loaded by the green box). In contrast, Oyente cannot transit execution
onto a contract to be analyzed, and hence paths are branched for into the initialization code, i.e., a created contract, in a symbolic
each function by comparing them with actual function IDs for manner. The remaining parts of the CFG are identical to a CFG
the contract. Then, the function ID can be obtained because a output from Oyente. Consequently, RA can handle a function call
solution satisfying f unction id is obtained by deciding the satis- by extracting the initialization codes on CREATE instructions.
fiability of path conditions for all paths with the z3 module. If Consider the output of RA shown in Fig. A·2 *4 . On a
a CALL instruction appears during the execution, CALLABLE is CFG output by RA on analysis of the reference implementa-
recorded as a state of a basic block. The state of the basic block tion of the create-based re-entrancy attack, the execution is tran-
is inherited by all the descendant paths. In extracting an actual sited/returned to/from a callee contract on the basic block. The
function ID, ID of a function with function call is recorded if the figure is an output of RA for the Fund contract [2], and the same
end state of a basic block is CALLABLE. figure is obtained even when the Fund function is called by the
4.5.4 Speed-up Techniques CREATE instruction. This confirms that, unlike Oyente, RA
The entire performance of RA was improved by using four op-
*2 https://github.com/uni-due-syssec/eth-reentrancy-attack-patterns
timization techniques. First, RA can verify combinations of func- *3 This figure is shown in the Appendix.
tion calls described in Eq. (1) in parallel. Second, a constraint is *4 This figure is shown in the Appendix.


c 2021 Information Processing Society of Japan 542
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

Table 1 Results of Analysis of Contracts Vulnerable to Re-Entrancy Attacks: The Benign Functions and
Vulnerable Functions columns represent the number of benign functions and vulnerable func-
tions in the contract, respectively. The true positive rate is denoted by TPR, false positive rate by
FPR, true negative rate by TNR, and false negative rate by FNR.
Code Benign Vulnerable
Contract Length [Byte] Functions Functions TPR [%] FPR [%] TNR [%] FNR [%]
Fund [2] 356 0 1 100 0 0 0
KnownReentrancy [1] 365 0 1 100 0 0 0
Bank [29] 1,694 2 1 100 0 100 0
Token [29] 2,516 11 1 100 0 0 0
KnownCrossFunction [1] 680 1 1 100 0 100 0

provides analysis of create-based re-entrancy attacks in an inter- Table 2 Computational Time of RA for Analysis: The Combinations of
Functions column represents the number of combinations of func-
contract fashion. tion calls in the contract.
5.1.2 Call of Contracts
Code Combinations
We omit the output of RA in this case due to its length and Contract Length [Byte] of Functions Time [sec]
describe only the intuition. Suppose that an adversary utilizes Fund [2] 356 1 20.750
a contract with only CALL instructions. In particular, because Known
Reentrancy [1] 365 1 23.003
there are two basic blocks, two function calls and two transitions
Bank [29] 1,694 3 47.579
to the caller are identified according to the analysis results of RA. Token [29] 2,516 12 519.676
These results confirm that RA provides analysis of cross-function KnownCross
re-entrancy attacks in an inter-contract fashion. Function [1] 680 2 37.705

5.2 Vulnerability Analysis Table 3 Comparison of RA and Other Analysis Tools: • indicates the tool
can detect the attack, ◦ indicates the tool cannot detect the attack,
The performance of RA is evaluated by using it to analyze the and  indicates the tool can potentially detect the attack but did not
vulnerability of a number of deployed contracts to re-entrancy provide a discussion in its paper.
attacks. In particular, the target contracts included in the evalua- Static Cross- Create-
tion are the Fund contract in the official document of Solidity [2], Tool Analysis Function Based Analysis Target
Oyente [23] Static ◦ ◦ EVM
a contract named KnownReentrancy obtained from the code of
Securify [33] Static ◦ ◦ EVM
“Reentrancy on a Single Function” published on the webpage of
Annotary [35] Static   Solidity
“Ethereum Smart Contract Best Practices” [1], the Bank contract
Sereum [29] Dynamic • • EVM
based on create-based re-entrancy attack [29], the Token contract ÆGIS [12] Dyanmic •  EVM
based on cross-function re-entrancy attack [29], and a contract RA Static • • EVM
named KnownCrossFunction obtained from the code of “Cross-
function Reentrancy” published on “Ethereum Smart Contract 5.3 Computational Performance
Best Practices”. Both Fund and KnownReentrancy contain a sin- We now present the computational performance of RA for
gle contract. Bank contains three contracts, two of which are be- analysis of re-entrancy attacks. The performance was measured
nign, i.e., not vulnerable. Token contains twelve contracts, eleven by utilizing the time.perf counter function as an average of ten ex-
of which are benign and only one contract is vulnerable. Fi- ecutions. The environment for measurement is as follows: iMac
nally, KnownCrossFunction contains one vulnerable contract and 21.5-inch, 2017 with 3.6 GHz Intel Core i7 processor, 32 GB
one benign contract because the cross-function re-entrancy attack memory, and Radeon Pro 560 4 GB as GPU. The measurement
needs “cross” calls between different contracts. Several contracts was done by implementing parallel-processing. As can be seen in
include multiple functions and hence analysis of re-entrancy at- Table 2, the computational time for analysis becomes longer in
tacks becomes complicated due to combinations of function calls proportion to the number of function calls. Surprisingly, analysis
as described in Section 3.2. In doing so, the goal of this eval- of Bank is fast even with its code length because Bank is based
uation is to determine whether RA can precisely identify both on create-based re-entrancy attack, i.e., the majority of its codes
vulnerable contracts and benign contracts. to create a contract and the function call are restricted to call the
The results are shown in Table 1. According to the table, RA created contract. In contrast, Token is based on cross-function
can precisely verify all the existing vulnerabilities without false re-entrancy attack and its code length and variation of function
positives and false negatives. In other words, in addition to be- calls are large. Nevertheless, RA was still able to analyze Token
ing able to analyze contracts that are vulnerable to re-entrancy within reasonable time.
attacks, RA can also analyze contracts that are not vulnerable, as
confirmed by the true negative rate. This precise evaluation for 5.4 Comparison to Other Analysis Tools
verification of vulnerabilities was obtained by the use of the Z3 Table 3 shows a comparison of different tools in terms of
SMT solver with path conditions obtained from symbolic execu- their ability to detect re-entrancy attacks discovered by Rodler
tion. et al. [29]. Oyente [23] and Securify [33] cannot detect such re-
entrancy attacks. In particular, Oyente fails to detect the vulner-


c 2021 Information Processing Society of Japan 543
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

abilities, while Securify produces false alerts due to its conser- ongoing work, may be able to overcome the limitation described
vative policy. Sereum and ÆGIS can potentially detect the vul- above. Finally, bytecodes of contracts cannot include symbolic
nerabilities, but they are based on dynamic analysis. Finally, An- values. Accordingly, a case where created contracts are differ-
notary is a static analysis tool that can deal with CREATE and ent for each execution is not considered. Improving the points
CALL instructions. Thus, it can potentially detect the re-entrancy described above is our ongoing work.
attacks, but its paper did not discuss re-entrancy attacks. More-
over, Annotary’s analysis target are Solidity codes and thus it may
6. Related Works
experience difficulties in analyzing deployed contracts. In this section, we recall early literature on security analysis
of Ethereum smart contracts in terms of symbolic execution and
5.5 Computational Complexity for Vulnerability Verifica- formal methods as static analysis. Then, we describe several mul-
tion tidisciplinary approaches proposed in the past few years as addi-
Let the number of functions with function call be Fn , the num- tional related works. Interested readers are advised to read the
ber of those paths be F p , the number of any function be Gn , and survey papers [11], [37] for details on EVM analysis.
the number of those paths be G p . Here, the number of functions
to be executed in the first step is Fn and its resulting number of 6.1 Symbolic Execution
end states for each execution is F p . Then, in the second step, Gn Symbolic execution of Ethereum smart contracts was origi-
functions are executed in proportion to the number of end states, nally started by Oyente [23]. Although there are many subsequent
and the number of the end states of Gn is G p . Consequently, the works [8], [21], [26], [31], these works do not perform inter-
order complexity to obtain path conditions at the end of the pro- contract analysis. Furthermore, analysis of re-entrancy attacks
cess is O(Fn F pGnG p ). By parallelizing the process, the complex- is often heuristic and thus Oyente often produces many false pos-
ity becomes O(GnG p ) because all combinations of function calls itives. Extensions of Oyente that support readability of outputs
can be parallelized. To compute path conditions using Eq. (1), from symbolic execution have been proposed [24], [25], and the
RA decides whether two sets, i.e., C and I, of the path conditions usability of RA can be potentially improved in a similar way.
obtained from combinations of one function have an identity re- The closest work to RA is Annotary [35], which can analyze
lation between i ∈ I and c ∈ C. In doing so, the order complexity inter-contract behavior via both symbolic executions of EVM
is O(Fn F pG2nG2p ), which is smaller than the complexity to obtain bytecodes and the Z3 SMT solver. The major difference of Anno-
path conditions at the end states. The execution time for analy- tary from RA is that Annotary mainly targets analysis of Solidity
sis becomes longer in proportion to the number of contracts to be codes. In other words, RA mainly checks if deployed contracts
analyzed because the order complexity described above is poly- are secure or not, while Annotary supports developers in imple-
nomial time. In contrast, RA can be expected to be utilized for menting secure codes. Compared to RA, Annotary has several
analysis of contracts developed by a user in realistic time. advantages. In particular, according to Weiss et al. [35], Anno-
tary’s focus on the analysis of Solidity code brings the following
5.6 Extension to Analysis of Delegated Re-Entrancy Attacks two advantages. First, an analyst can use annotations to express
Rodler et al. [29] presented delegated re-entrancy attacks invariants and restrictions directly in the Solidity source code and
where a contract invokes another contract as a library within in- then use these annotations to find a feasible path on symbolic ex-
structions that utilize contracts as an external library, e.g., DELE- ecution effectively. On the other hand, RA focuses on analysis of
GATECALL or CALLCODE. These instructions are currently not EVM bytecodes and hence cannot handle Solidity source code,
implemented in RA, but RA can be extended to analyze delegated i.e., RA cannot analyze Solidity source codes because it targets
re-entrancy attacks by introducing these instructions. The main EVM bytecodes. Therefore, Annotary has an advantage in find-
technical difficulty in analysis of delegated re-entrancy attacks is ing a feasible path effectively by its use of annotations. Second,
that the library contract that will be used is unknown [29]. This Solidity source codes can be operated and written using a typi-
difficulty is also a problem in analyses of create-based and cross- cal editor, and then a software developer can incorporate a plugin
function re-entrancy attacks, which have been overcome already such that an analysis tool coordinates with existing editors. For
in RA. instance, Annotary has provided a Sublime Text plugin. It means
that, for example, a developer can analyze the Solidity source
5.7 Limitations codes written by him-/herself. The analysis of EVM bytecodes
The current implementation of RA has three limitations. First, requires a developer to compile the source codes to get the EVM
analysis of gas is not considered. Thus, contracts that restrict bytecodes or to obtain the EVM bytecodes of deployed contracts,
gas consumption may not be analyzed precisely. Second, a case and therefore it would be challenging to embed RA into a typical
where multiple contracts are tightly coupled with each other, i.e., editor. Providing a plugin is thus another advantage provided by
more than two contracts are strongly interdependent, is out of the Annotary. Although the authors of Annotary did not consider the
scope of RA. Specifically, instructions that utilize other contracts new attacks by Rodler et al. [29], we consider their idea and work
as an external library are not implemented. Consequently, the to be elegant nonetheless.
number of contracts to be analyzed in a single execution should ETHBMC [13] and VerX [27] are recent state-of-the-art works
be at most one, and the number of callee contracts is limited to a that verify properties of Ethereum. VerX is similar to Annotary
single contract. An improved implementation of RA, which is our in terms of taking Solidity codes as input and dealing with exter-


c 2021 Information Processing Society of Japan 544
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

nal contracts. Similar to Annotary, the new attacks by Rodler ties aside from re-entrancy, such as time-dependent vulnerability
et al. [29] were not considered in VerX. On the other hand, which utilizes a timestamp for each block. We believe that the
ETHBMC takes EVM bytecodes for symbolic executions and its inter-contract analysis capability of RA can potentially identify
motivation is rather close to that of RA. However, ETHBMC such a vulnerability. Finally, we will also try to improve the com-
mainly focuses on parity vulnerability. putational performance of RA by reusing parts of the computa-
tions for vulnerability verification.
6.2 Formal Methods Acknowledgments This work is supported by Secom Sci-
Formal verification of EVM was motivated by Bhargavan et ence and Technology Foundation, and Innovation Platform for
al. [6], and EVM was correctly formalized as KEVM [18]. How- Society 5.0 Program Grant Number JPMXP0518071489 by
ever, verification of the security is challenging in general, and MEXT.
the existing works [3], [4], [19], [33] do not provide support for
inter-contract analysis, which is the main target of our work. As References
more theoretical approach, Grishchenko et al. [15], [16] formal- [1] Known Attacks, available from https://consensys.github.io/
ized several attacks, including re-entrancy attacks, as well as for- smart-contract-best-practices/known attacks/ .
[2] Security Considerations Solidity 0.5.11 documentation, available from
malization of EVM. Their formalization inspired the vulnera- https://solidity.readthedocs.io/en/v0.5.11/security-considerations.
bility verification of RA. As the latest work, Grishchenko et al. html .
[3] Albert, E., Gordillo, P., Livshits, B., Rubio, A. and Sergey, I.: EthIR:
presented a formal verification tool [30] that can deal with inter- A Framework for High-Level Analysis of Ethereum Bytecode, Proc.
contract analysis. This work is concurrent with ours. ATVA 2018, Lahiri, S.K. and Wang, C. (Eds.), LNCS, Vol.11138,
pp.513–520, Springer (2018).
[4] Amani, S., Bégel, M., Bortin, M. and Staples, M.: Towards Verifying
6.3 Multidisciplinary Approaches Ethereum Smart Contract Bytecode in Isabelle/HOL, Proc. CPP 2018,
pp.66–77, ACM (online), DOI: 10.1145/3167084 (2018).
NeuCheck [22] can rapidly analyze Solidity source codes [5] Atzei, N., Bartoletti, M. and Cimoli, T.: A survey of attacks on
by extracting a syntax tree on a cross-platform environment. ethereum smart contracts (sok), Proc. POST 2017, LNCS, Vol.10204,
pp.164–186, Springer (2017).
TokenScope [9] can detect vulnerabilities by identifying to-
[6] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Gollamudi, A.,
kens that have a different specification from the ERC20 to- Gonthier, G., Kobeissi, N., Kulatova, N., Rastogi, A., Sibut-Pinote,
ken. SMARTSHIELD [36] is a bytecode rectification system that T., Swamy, N., et al.: Formal verification of smart contracts: Short
paper, Proc. PLAS 2016, pp.91–96, ACM (2016).
fixes security-related bugs automatically. SmartEmbed [14] and [7] Chang, J., Gao, B., Xiao, H., Sun, J., Cai, Y. and Yang, Z.: sCom-
VulDeeSmartContract [28] are automated vulnerability detection pile: Critical path identification and analysis for smart contracts, Proc.
ICFEM, LNCS, Vol.11852, pp.286–304, Springer (2019).
frameworks based on machine learning for the natural language [8] Chen, T., Li, X., Luo, X. and Zhang, X.: Under-optimized smart
processing. TEETHER [20] is a penetration tool for exploit gen- contracts devour your money, Proc. SANER 2017, pp.442–446, IEEE
(2017).
eration of Ethereum smart contracts. The techniques in these mul- [9] Chen, T., Zhang, Y., Li, Z., Luo, X., Wang, T., Cao, R., Xiao, X.
tidisciplinary works can be used to potentially improve RA. Fi- and Zhang, X.: TokenScope: Automatically Detecting Inconsistent
Behaviors of Cryptocurrency Tokens in Ethereum, Proc. CCS 2019,
nally, ILF [17] and ContractWard [34] use a combination of ma- pp.1503–1520, ACM (2019).
chine learning and symbolic execution to improve testing cover- [10] Chinen, Y., Yanai, N., Cruz, J.P. and Okamura, S.: RA: Hunting for
Re-Entrancy Attacks in Ethereum Smart Contracts via Static Analysis,
age. These works are expected to have improved performance if Proc. IEEE Blockchain 2020, pp.327–336, IEEE (2020).
they deploy RA as a building block. [11] Di Angelo, M. and Salzer, G.: A survey of tools for analyzing
ethereum smart contracts, Proc. DAPPCON 2019, pp.69–78, IEEE
7. Conclusion (2019).
[12] Ferreira Torres, C., Steichen, M., Norvill, R., Fiz Pontiveros, B. and
In this paper, we introduced RA, a static analysis tool that pro- Jonker, H.: ÆGIS: Shielding Vulnerable Smart Contracts Against At-
tacks, Proc. AsiaCCS 2020, pp.584–597, ACM (2020).
vides inter-contract analysis of the EVM bytecodes of Ethereum [13] Frank, J., Aschermann, C. and Holz, T.: ETHBMC: A Bounded Model
smart contracts to detect vulnerabilities to state-of-the-art re- Checker for Smart Contracts, Proc. Usenix Security 2020, USENIX
Association (2020) (online), available from https://www.usenix.org/
entrancy attacks [29]. Using RA, analysts do not need to have conference/usenixsecurity20/presentation/frank .
prior knowledge of re-entrancy attacks to detect them. To cre- [14] Gao, Z., Jiang, L., Xia, X., Lo, D. and Grundy, J.: Checking Smart
Contracts with Structural Code Embedding, IEEE Trans. Software En-
ate RA, we designed modules that represent inter-contract CFGs gineering, p.1 (2020).
by the symbolic re-entrancy emulation and the vulnerability ver- [15] Grishchenko, I., Maffei, M. and Schneidewind, C.: Foundations and
Tools for the Static Analysis of Ethereum Smart Contracts, Proc. CAV
ification with the Z3 SMT solver to verify the re-entrancy vul- 2018, LNCS, Vol.10981, pp.51–78, Springer (2018).
nerability of deployed contracts. We also conducted experiments [16] Grishchenko, I., Maffei, M. and Schneidewind, C.: A semantic frame-
work for the security analysis of ethereum smart contracts, Proc.
on deployed contracts and confirmed the performance of RA by POST 2018, LNCS, Vol.10804, pp.243–269, Springer (2018).
precisely identifying combinations of contracts with and without [17] He, J., Balunoviundefined, M., Ambroladze, N., Tsankov, P. and
Vechev, M.: Learning to Fuzz from Symbolic Execution with Applica-
vulnerabilities. The aforementioned performance could be ob- tion to Smart Contracts, Proc. CCS 2019, pp.531–548, ACM (2019).
tained by the high-level combination of the symbolic execution [18] Hildenbrandt, E., Saxena, M., Rodrigues, N., Zhu, X., Daian, P., Guth,
and the Z3 SMT solver. D., Moore, B., Park, D., Zhang, Y., Stefanescu, A., et al.: KEVM:
A complete formal semantics of the ethereum virtual machine, Proc.
As future work, we plan to extend RA for a case in which a CSF 2018, pp.204–217, IEEE (2018).
fraction of contracts to be verified and external contracts become [19] Kalra, S., Goel, S., Dhawan, M. and Sharma, S.: ZEUS: Analyzing
Safety of Smart Contracts, Proc. NDSS 2018, Internet Society (2018).
many-to-many. If successful, RA will be able to deal with more [20] Krupp, J. and Rossow, C.: teEther: Gnawing at Ethereum to Automati-
complicated attacks that can be proposed in the future. More- cally Exploit Smart Contracts, Proc. USENIX Security 2018, pp.1317–
1333, USENIX Association (2018).
over, we plan to design capabilities that check for vulnerabili-


c 2021 Information Processing Society of Japan 545
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

[21] Liu, H., Liu, C., Zhao, W., Jiang, Y. and Sun, J.: S-gram: Towards
semantic-aware security auditing for ethereum smart contracts, Proc.
ASE 2018, pp.814–819, ACM (2018).
[22] Lu, N., Wang, B., Zhang, Y., Shi, W. and Esposito, C.: NeuCheck:
A more practical Ethereum smart contract security analysis tool,
Software: Practice and Experience, Vol.2019, pp.1–20 (2019) (on-
line), available from https://onlinelibrary.wiley.com/doi/abs/10.1002/
spe.2745 .
[23] Luu, L., Chu, D.-H., Olickel, H., Saxena, P. and Hobor, A.: Making
smart contracts smarter, Proc. CCS 2016, pp.254–269, ACM (2016).
[24] Mossberg, M., Manzano, F., Hennenfent, E., Groce, A., Grieco, G.,
Feist, J., Brunson, T. and Dinaburg, A.: Manticore: A User-Friendly
Symbolic Execution Framework for Binaries and Smart Contracts,
Proc. ASE 2019, pp.1186–1189, IEEE (2019).
[25] Mueller, B.: Smashing smart contracts, 9th HITB Security Conference
(2018).
[26] Nikolić, I., Kolluri, A., Sergey, I., Saxena, P. and Hobor, A.: Find-
ing the greedy, prodigal, and suicidal contracts at scale, Proc. ACSAC
2018, pp.653–663, ACM (2018).
[27] Permenev, A., Dimitrov, D., Tsankov, P., Drachsler-Cohen, D. and
Vechev, M.: Verx: Safety verification of smart contracts, Proc. IEEE
S&P 2020, pp.414–430, IEEE (2020).
[28] Qian, P., Liu, Z., He, Q., Zimmermann, R. and Wang, X.: Towards
Automated Reentrancy Detection for Smart Contracts Based on Se-
quential Models, IEEE Access, Vol.8, pp.19685–19695 (2020).
[29] Rodler, M., Li, W., Karame, G.O. and Davi, L.: Sereum: Protecting
Existing Smart Contracts Against Re-Entrancy Attacks, Proc. NDSS
2019, Internet Society (2019).
[30] Schneidewind, C., Grishchenko, I., Scherer, M. and Maffei, M.:
EThor: Practical and Provably Sound Static Analysis of Ethereum
Smart Contracts, Proc. CCS 2020, pp.621–640, ACM (2020).
[31] Torres, C.F., Schütte, J., et al.: Osiris: Hunting for integer bugs
in ethereum smart contracts, Proc. ACSAC 2018, pp.664–676, ACM
(2018).
[32] Torres, C.F. and Steichen, M.: The Art of The Scam: Demystifying
Honeypots in Ethereum Smart Contracts, Proc. Usenix Security 2019,
pp.1591–1607, Usenix Association (2019).
[33] Tsankov, P., Dan, A., Drachsler-Cohen, D., Gervais, A., Buenzli, F.
and Vechev, M.: Securify: Practical security analysis of smart con-
tracts, Proc. CCS 2018, pp.67–82, ACM (2018).
[34] Wang, W., Song, J., Xu, G., Li, Y., Wang, H. and Su, C.: Contract-
Ward: Automated Vulnerability Detection Models for Ethereum Smart
Contracts, IEEE Trans. Network Science and Engineering, p.1 (Early
Access) (2020).
[35] Weiss, K. and Schütte, J.: Annotary: A Concolic Execution System
for Developing Secure Smart Contracts, Proc. ESORICS 2019, LNCS,
Vol.11735, pp.747–766, Springer (2019).
[36] Zhang, Y., Ma, S., Li, J., Li, K., Nepal, S. and Gu, D.:
SMARTSHIELD: Automatic Smart Contract Protection Made Easy,
Proc. SANER 2020, pp.23–34, IEEE (2020).
[37] Zou, W., Lo, D., Kochhar, P.S., Le, X.-B. D., Xia, X., Feng, Y., Chen,
Z. and Xu, B.: Smart Contract Development: Challenges and Oppor-
tunities, IEEE Transactions on Software Engineering, p.1 (2019).

Appendix
A.1 Outputs of RA
Figure A·1 shows CFGs output by RA on analysis of contracts
with CREATE instruction. Figure A·2 shows CFGs output by
RA for the reference implementation of create-based re-entrancy
attacks.

Editor’s Recommendation
This paper proposes a static analysis tool named RA (Re-
entrancy Analyzer), a combination of symbolic execution and
equivalence checking to analyze vulnerability of smart contracts
to re-entrancy attacks. This research is necessary and important
for smart contracts. In particular, this paper shows the experiment
results on deployed contracts and includes a sufficient amount of
survey. The paper gives insights to readers in this research field Fig. A·1 Control flow graph obtained from CREATE instructions.
and thus is selected as a recommended paper.
(Chief examiner of SIGSCEC Toshihiro Yamauchi)


c 2021 Information Processing Society of Japan 546
Journal of Information Processing Vol.29 537–547 (Sep. 2021)

Yuichiro Chinen received his M.E. de-

gree from Graduate School of Information
Science and Technology in Osaka Univer-
sity, Japan, in 2020. His research inter-
ests include blockchains. He has recently
joined the M.S. course in the Graduate
School of Information Science and Tech-
nology in Osaka University, Japan. His
research interests include machine learning and information se-
curity.

Naoto Yanai received his B.E. degree

from The National Institution of Aca-
demic Degrees and University Evalua-
tion, Japan, in 2009, his M.S. Eng. from
Graduate School of Systems and Informa-
tion Engineering, University of Tsukuba,
Japan, in 2011, and his Ph.D. degree
in Engineering from Graduate School of
Systems and Information Engineering, University of Tsukuba,
Japan, in 2014. He is an assistant professor at Osaka University,
Japan. His research area is information security.

Jason Paul Cruz received his B.S. de-

gree in Electronics and Communications
Engineering and M.S. degree in Elec-
tronics Engineering from the Ateneo de
Manila University, Quezon City, Philip-
pines, in 2009 and 2011, respectively, and
his Ph.D. degree in Engineering from the
Graduate School of Information Science,
Nara Institute of Science and Technology, Nara, Japan in 2017.
He is currently a Specially Appointed Assistant Professor at
Osaka University, Osaka, Japan. His current research interests
include role-based access control, blockchain technology, hash
functions and algorithms, privacy-preserving cryptography, and
Android programming.

Shingo Okamura received his B.E.,

M.E., and Ph.D. degrees from Gradu-
ate School of Information Science and
Technology in Osaka University in 2000,
2002, and 2005, respectively. Since 2005,
he has worked for Osaka University. In
2008, he joined National Institute of
Technology, Nara College. Currently, he
is an associate professor at the college. His research interests
include cryptographic protocols and cyber security. He is a
member of IEICE, IPSJ, IEEJ, ACM, IEEE, and IACR.

Fig. A·2 Control flow graph obtained from RA for create-based re-entrancy
attacks.


c 2021 Information Processing Society of Japan 547