The SWC-based Security Analysis Tool for Smart Contract Vulnerability Detection

Abstract

Smart contracts publicly deployed on blockchain have been shown to contain several vulnerabilities that users can maliciously exploit. To detect smart contract vulnerabilities as categorized in the Smart Contract Weakness Classification (SWC) standard, we propose the SWC-based Analysis Tool (SWAT). It operates by matching patterns in Solidity codes, making it easy to use and allowing any Solidity developers to conveniently check their smart contracts before deploying. We conducted experiments to compare the proposed solution against state-of-the-art tools in identifying 46 SWC registries. SWAT outperformed the existing tools in terms of the number of SWC vulnerabilities supported. Moreover, our solution is memory-efficient as it uses 44.58% less memory than other tools.

Full text

Pre-Printed Version
The SWC-based Security Analysis Tool for
Smart Contract Vulnerability Detection
Nattawat Songsom, Warodom Werapun, Jakapan Suaboot, Norrathep Rattanavipanon
{s6430621005, warodom.w, jakapan.su, norrathep.r}@phuket.psu.ac.th
College of Computing,
Prince of Songkla University, Phuket Campus
Abstract— Smart contracts publicly deployed on
blockchain have been shown to contain several
vulnerabilities that users can maliciously exploit. To detect
smart contract vulnerabilities as categorized in the Smart
Contract Weakness Classification (SWC) standard, we
propose the SWC-based Analysis Tool (SWAT). It
operates by matching patterns in Solidity codes, making it
easy to use and allowing any Solidity developers to
conveniently check their smart contracts before deploying.
We conducted experiments to compare the proposed
solution against state-of-the-art tools in identifying 46
SWC registries. SWAT outperformed the existing tools in
terms of the number of SWC vulnerabilities supported.
Moreover, our solution is memory-efficient as it uses
44.58% less memory than other tools.
Keywords- SWC; vulnerability detection; smart contract;
exploit; blockchain
I. INTRODUCTION
The frequency of crypto-related attacks has exploded
over recent years. Examples of those cases are the DAO
attack in June 2016 which allowed hackers to steal ~$50
million in Ethereum [1], and the Parity Wallet hack in
July 2017, in which hackers stole nearly $32 million
worth of Ethereum [2] tokens. Other notable attacks are
the Rubixi attack and the King of the Ether Throne
attack [3][4]. Since applications using smart contracts
are usually financial-related, deploying vulnerable
smart contracts could lead to a catastrophic result, as
demonstrated by many financial losses for a total of
billions of dollars in the past recent years. These
incidents indicate the importance of protecting smart
contracts against exploitation. While a vulnerable smart
contract can be fixed and redeployed [5], the upgrading
process must follow the delegate proxy pattern, which
is hard to implement. Moreover, this upgrading process
may take time, causing a window of vulnerability that
an attacker can exploit the vulnerable contract before
getting redeployed. In addition, smart contract
redeployment incurs an overhead of contract audits,
which can be cumbersome since they must be done
manually by software security analysts or security
experts. The existing smart contract analysis tools can
be categorized into static and dynamic based on their
detection technique. The static tools analyze a smart
contract without executing it. The dynamic tools, on the
other hand, require executing the contract to analyze it.
As a result, those dynamic tools often run slower than
tools that use a static analysis method. However, the
dynamic tools can reproduce the exploitation that
matches the exact scenario. Hence, the dynamic tools
support detection of more vulnerabilities than the static
tools. Unfortunately, many existing tools are ad-hoc
solutions; they do not comply with any security
standard. In particular, only a handful of either dynamic
or static tool targets vulnerabilities categorized by the
Smart Contract Weakness Classification (SWC)
standard. Nevertheless, none of them covers all
vulnerabilities in SWC [6].
Contributions of this work are summarized as
follows: (1) we propose the SWC-based Analysis Tool
(SWAT), a static analysis tool that currently covers the
detection of most smart contract weaknesses in the
SWC standard. Moreover, we benchmark memory
usage of SWAT and compare it to Slither [7] and
Mythril[8], and (2) we present a mapping of Slither and
Vandal [9] detection results to the SWC standard.
This paper is organized as follows. Section 2 reviews
the SWC standard, existing smart contract analysis
tools, and smart contract analysis tool development
methods. The proposed SWAT framework and its
implementation are presented in Section 3. Section 4
benchmarks the proposed SWAT against the state-of-
the-art and discusses the experimental results. Finally,
the paper is concluded in Section 5.
II. RELATED WORK
A. Smart contract Weakness Classification
While Common Weakness Enumeration (CWE) is
widely adopted in the software industry, it only
describes the weakness for generic software, and thus,
it is not specific to the Solidity code. Smart contract
Weakness Classification (SWC) is a weakness
classification system targetting specifically on the
Solidity code. It consists of 37 weaknesses, identifiers,
weakness titles, related CWE items, and test case codes
[10]. SWC can be a guideline for developing secure
smart contracts and tools.
B. The smart contract analysis tool
Several tools have been developed to analyze
Ethereum Virtual Machine (EVM) [11] based smart

contracts. They can be categorized as static and
dynamic based on their analysis methods.
Static analysis tools
These tools analyze smart contracts without
executing them. Slither is one in this category; it is
implemented using Python and its intermediate
representation called SlithIR. It works by translating the
code to Solidity Abstract Syntax Tree (AST) and its
intermediate representation to recover semantic facts.
Then it compares the facts with a list of pre-defined
analyses to detect vulnerabilities. Vandal [9] is another
static tool implemented using Python and Souffle [12].
It decompiles an EVM bytecode to its internal
representation language to recover semantic facts, then
feeds the facts to the Souffle analysis engine to detect
vulnerabilities. The aforementioned tools are open-
source. The latest version of Slither can detect 76
vulnerabilities, and the latest version of Vandal supports
detection of 6 vulnerabilities. However, Slither and
Vandal still lack the SWC standard support.
Other notable static tools include Securify [13]
implemented using Python and Souffle, and Solhint
[14] implemented using NodeJS; whereas, both Vandal
and Securify are implemented using Python and
Souffle. This paper chose Vandal as our benchmark
because it has analyzed 141k datasets of smart contracts
[9], more than Securify, which examined only 18k
smart contracts datasets [13]. Although Solhint supports
security and style analysis, it mainly focuses on style
analysis. Solhint is not widely discussed in security
analysis tool review researches compared to Vandal
[15][16][17], despite being developed before Vandal.
Therefore, this paper chooses Vandal as our benchmark.
Figure 1. Slither and Vandal results mapped to SWC
Dynamic analysis tools
In contrast to the static tools, the dynamic analysis
tools analyze a smart contract by actually executing the
contract. It leverages at least one of the following
techniques to discover vulnerabilities: symbolic/
concolic execution, taint tracking, and fuzzing. For
instance, Mythril uses concolic analysis [18], taint
analysis, and control flow checking to detect various
security vulnerabilities [7]. Oyente [19] is one of the
first tools that used symbolic execution to analyze smart
contracts. These tools (i.e., [8], [19] and [20]) are open-
source. In comparison, Mythril has its paid version
called MythX [20]. Mythril and MythX are developed
with Python, while Oyente is implemented using
JavaScript. The latest version of Mythril supports
detection of 14 SWC vulnerabilities [6], the latest
version of MythX supports detection of 46 SWC
vulnerabilities, and the newest version of Oyente
supports detection of 7 SWC vulnerabilities. While
Mythril and Mythx are based on the SWC standard, they
do not support all vulnerabilities in the SWC standard.
Other notable dynamic analysis tools include Edchidna
[21], which works by fuzzing the contract, and
Manticore [22], which uses symbolic execution.
We chose three state-of-the-art tools, Slither [7],
Mythril, and Vandal [9], as benchmarks. The reasons
are based on two criteria. Firstly, the tool must use a
static analysis like our proposed work. Slither and
Vandal fit this criterion. The second criterion is that the
tool must support the SWC standard. Mythril and
MythX fit this criterion, but we can only experiment
using Mythril because the latter is not open-source.
Since Slither and Vandal do not support the SWC
standard, we map their detection results to SWC
vulnerabilities such that we can compare their results
with SWAT. This mapping is depicted in Figure 1.
III. SWAT FRAMEWORK
SWAT is a static analysis framework that aims to
detect SWC vulnerabilities in smart contract code. In this
section, we describe the architecture and implementation
examples of the proposed framework.
Figure 2. Overview of the SWAT architecture
Figure 2 illustrates the architecture overview of
SWAT. It takes the Solidity code as the input and
outputs vulnerable parts in the Solidity code. SWAT
follows a modular design. It consists of 3 main
components: (1) Core Analysis, (2) Validator, and (3)
Visualizer. The Core Analysis is where we implement
our detection system. The Validator is responsible for
filtering false-positive results, and the Visualizer is a
report generator.
A. Implementation
SWAT analyzes Solidity code using a pattern
matching technique. In this paper, we focus on detecting
the following vulnerabilities in Solidity code, namely
SWC-100, SWC-102-104, SWC-111, SWC-129, and
SWC-134, detailed as follows.
a) SWC-100 function default visibility
A function without function visibility, as shown in
Figure 3, is a public function by default. It executes
transfer() of the contract balance to the caller. Given
that the function was intended to be called by only
internal functions, this contract is vulnerable to

malicious attacks, where an external user can directly
call this function and drain all tokens or coins from the
contract wallet. This can lead to unintended or
unauthorized access by malicious users [9].
1 function _sendWinnings() {
2 msg.sender.transfer(this.balance);
3 }
Figure 3. Solidity code with default function visibility declaration
1 function _sendWinnings() internal {
2 msg.sender.transfer(this.balance);
3 }
Figure 4. Solidity code with explicit function visibility declaration
The correct implementation of this function is to
explicitly declare function visibility as internal, as
depicted in Figure 4. Our implementation uses regular
expression [23] to detect the visibility of all functions
for handling this vulnerability. In other words, the smart
contract is flagged as vulnerable if no function visibility
is declared.
b) SWC-102 Outdated Compiler Version
Solidity compiler uses semantic versioning, a
widely adopted version scheme [24]. An outdated
compiler version could be left exposed to previously
disclosed vulnerabilities such as integer overflow and
underflow. Solidity 0.8 now has a built-in overflow
checking [25], which means using a Solidity compiler
older than version 0.8.0 is vulnerable. A regular
expression is used to detect the outdated version of the
Solidity compiler to identify this issue. If the pattern
matches, the current major version is considered
outdated and SWAT marks this contract vulnerable.
c) SWC-103 Floating Pragma
Using floating pragma means the contract is
compiled with flexible compiler versions. This could
introduce nondeterministic behaviors potentially
leading to a vulnerability. Therefore, to be secure,
contracts should be compiled with a specific compiler
version [6].To detect this weakness, we use a regular
expression to search for the circumflex accent (^) in the
pragma version. If the pattern matched, we consider the
pragma version floating, and the contract is considered
vulnerable.
d) SWC-111 Use of Deprecated Solidity Functions
Several functions and operators in Solidity are
deprecated. Continuing to use them may result in
unexpected behaviors. Solidity provides alternative
variables and functions regarding the deprecated
functions, exemplified in Table I. Replacing old
structures with their alternatives will not break current
behavior.
e) SWC-129 Typological Error
Some operators in Solidity are resemblant. This can
lead to typographical errors if operators are not defined
correctly. For example, using =+ instead of += results
in a variable re-initialization, which can lead to
unintended behaviors in the contract. Similarly, we use
a regular expression to check for similar operators to
find this vulnerability. The incorrect operators are
detected, and the contract is deemed insecure if this
pattern is discovered.
TABLE I. DEPRECATED CONSTRUCTIONS AND ALTERNATIVES
Deprecated
Alternative
suicide(address)
selfdestruct(address)
block.blockhash(uint)
blockhash(uint)
throw
revert()
msg.gas
gasleft
constant
view
sha3(…)
keccak256(…)
callcode(…)
delegatecall(…)
f) SWC-134 Message call with the hardcoded gas
The transfer() and send() functions consume a
fixed amount of gas. Initially, they are designed to
prevent reentrancy attacks [26]. Nonetheless, hard forks
may change the gas cost of EVM instructions and break
deployed contracts. To detect this vulnerability, we use
a regular expression to detect the fixed gas amount. The
contract is considered vulnerable if the pattern is found
(i.e., the fixed gas amount is detected).
IV. EXPERIMENT RESULT
To evaluate SWAT, we select official experimental
test cases [10] from the SWC standard as our test dataset
and consider the following experimental factors: the
number of vulnerabilities detected and memory
consumption. We compared SWAT to Slither [7],
Mythril [8], and Vandal [9] to evaluate the number of
vulnerabilities supported. Table II shows that our tool
can detect SWC-103 and SWC-134, which were not
supported by other tools.
TABLE II. VULNERABILITY SUPPORT COMPARISON
SWC
SWAT
Slither
Mythril
Vandal
SWC-100
✓
✓
SWC-102
✓
✓
SWC-103
✓
SWC-104
✓
SWC-111
✓
✓
✓
SWC-129
✓
✓
SWC-134
✓
TABLE III. MEMORY USAGE (IN MB) COMPARISON
SWAT
Slither
Mythril
Difference
SWC-100
13.3
24
-
44.58%
SWC-102
14.3
24.1
-
40.66%
SWC-103
14.1
-
-
N/A
SWC-111
14.5
22.6
80.62
35.84%a
SWC-129
14.5
13.2
-
-9.85%
SWC-134
14.5
-
-
N/A
a. Percentage difference is compared with Slither.
To evaluate memory consumption, we compared
SWAT with Slither and Mythril. We did not compare
with Vandal because the SWAT detection result (SWC-
104) did not overlap with Vandal. As shown in Table III
and Figure 5, on average, SWAT used less memory than

other tools by 44.58%, 40.66%, and 35.84% for
detecting SWC-100, SWC-102, and SWC-111. For
SWC-129, Slither consumed less memory than our tool
by 9.85%. The memory usage of our tool to detect
SWC-103 and SWC-134 are 14.1 and 14.5 MB (Figure
5). Other tools cannot detect these vulnerabilities.
Figure 5. Memory usage comparison by vulnerabilities
V. CONCLUSION
This paper presents SWAT, a novel static analysis
tool for detecting smart contract vulnerabilities based
on the SWC standard using a pattern matching
technique. We demonstrated how Solidity code can be
vulnerable and how SWAT detects these issues through
examples. Moreover, we describe in detail the
implementation issue of each vulnerability.
Additionally, we mapped the detection results from
Slither and Vandal tools to the SWC standard to
compare with the proposed SWAT. From conducted
experiments, SWAT can detect 6 SWC vulnerabilities,
which is the best compared to Slither, Mythril, and
Vandal. Importantly, SWAT consumes the least
memory compared to other tools. In future work, we
will evaluate SWAT in terms of other metrics including
accuracy. Furthermore, we will develop SWAT to
support both static and dynamic analyses and cover a
wider range of SWC vulnerabilities, especially the more
complex vulnerabilities that cannot be detected using a
pattern matching technique.
REFERENCES
[1] A. Averin and O. Averina, “Review of Blockchain Technology
Vulnerabilities and Blockchain-System Attacks,” in 2019
International Multi-Conference on Industrial Engineering and
Modern Technologies (FarEastCon), Vladivostok, Russia, Oct.
2019, pp. 1–6.
[2] “The Multi-sig Hack: A Postmortem.”
https://www.parity.io/blog/the-multi-sig-hack-a-postmortem
(accessed Jun. 15, 2022).
[3] N. Atzei, M. Bartoletti, and T. Cimoli, “A Survey of Attacks on
Ethereum Smart Contracts (SoK),” in Principles of Security
and Trust, vol. 10204, M. Maffei and M. Ryan, Eds. Berlin,
Heidelberg: Springer Berlin Heidelberg, 2017, pp. 164–186.
[4] Pete Humiston, “Smart Contract Attacks [Part 2] - Ponzi Games
Gone Wrong.” https://hackernoon.com/smart-contract-attacks-
part-2-ponzi-games-gone-wrong-d5a8b1a98dd8 (accessed Jun.
10, 2022).
[5] Elena Gesheva, “Solidity 0.6.x Features: Fallback and Receive
Functions.” https://betterprogramming.pub/solidity-0-6-x-
features-fallback-and-receive-functions-69895e3ffe (accessed
Jun. 08, 2022).
[6] “Smart Contract Weakness Classification and Test Cases.”
https://swcregistry.io/ (accessed May 05, 2022).
[7] J. Feist, G. Grieco, and A. Groce, “Slither: A Static Analysis
Framework For Smart Contracts,” in 2019 IEEE/ACM 2nd
International Workshop on Emerging Trends in Software
Engineering for Blockchain (WETSEB), May 2019, pp. 8–15.
[8] “Mythril: a security analysis tool for ethereum smart contracts.”
https://github.com/ConsenSys/mythril-classic (accessed May
20, 2022).
[9] L. Brent et al., “Vandal: A Scalable Security Analysis
Framework for Smart Contracts.” arXiv, Sep. 11, 2018.
Accessed: May 18, 2022. [Online]. Available:
http://arxiv.org/abs/1809.03981
[10] J.-H. Lee, S. Yoon, and H. Lee, “SWC-based Smart Contract
Development Guide Research,” in 2022 24th International
Conference on Advanced Communication Technology
(ICACT), PyeongChang Kwangwoon_Do, Korea, Republic of,
Feb. 2022, pp. 138–141.
[11] R. Norvill, B. B. F. Pontiveros, R. State, and A. Cullen, “Visual
emulation for Ethereum’s virtual machine,” in NOMS 2018 -
2018 IEEE/IFIP Network Operations and Management
Symposium, Taipei, Apr. 2018, pp. 1–4.
[12] X. Hu, J. Karp, D. Zhao, A. Zreika, X. Wu, and B. Scholz, “The
Choice Construct in the Souffle Language.” arXiv, Aug. 25,
2021. Accessed: Jun. 22, 2022. [Online]. Available:
http://arxiv.org/abs/2108.11212
[13] P. Tsankov, A. Dan, D. D. Cohen, A. Gervais, F. Buenzli, and
M. Vechev, “Securify: Practical Security Analysis of Smart
Contracts.” arXiv, Aug. 24, 2018. Accessed: Jun. 22, 2022.
[Online]. Available: http://arxiv.org/abs/1806.01143
[14] “Solhint.” https://protofire.github.io/solhint (accessed Jul. 06,
2022).
[15] M. di Angelo and G. Salzer, “A Survey of Tools for Analyzing
Ethereum Smart Contracts,” in 2019 IEEE International
Conference on Decentralized Applications and Infrastructures
(DAPPCON), Newark, CA, USA, Apr. 2019, pp. 69–78
[16] M. Almakhour, L. Sliman, A. E. Samhat, and A. Mellouk,
“Verification of smart contracts: A survey,” Pervasive Mob.
Comput., vol. 67, p. 101227, Sep. 2020.
[17] H. Chen, M. Pendleton, L. Njilla, and S. Xu, “A Survey on
Ethereum Systems Security: Vulnerabilities, Attacks, and
Defenses,” ACM Comput. Surv., vol. 53, no. 3, pp. 1–43, May
2021.
[18] P. Godefroid, N. Klarlund, and K. Sen, “DART: directed
automated random testing,” ACM SIGPLAN Not., vol. 40, no.
6, pp. 213–223, Jun. 2005.
[19] S. Badruddoja, R. Dantu, Y. He, K. Upadhayay, and M.
Thompson, “Making Smart Contracts Smarter,” in 2021 IEEE
International Conference on Blockchain and Cryptocurrency
(ICBC), Sydney, Australia, May 2021, pp. 1–3.
[20] “MythX: Smart contract security service for Ethereum.”
https://mythx.io/ (accessed May 20, 2022).
[21] G. Grieco, W. Song, A. Cygan, J. Feist, and A. Groce,
“Echidna: effective, usable, and fast fuzzing for smart
contracts,” in Proceedings of the 29th ACM SIGSOFT
International Symposium on Software Testing and Analysis,
Virtual Event USA, Jul. 2020, pp. 557–560.
[22] M. Mossberg et al., “Manticore: A User-Friendly Symbolic
Execution Framework for Binaries and Smart Contracts.”
arXiv, Nov. 18, 2019. Accessed: Jun. 22, 2022. [Online].
Available: http://arxiv.org/abs/1907.03890
[23] “re — Regular expression operations — Python 3.10.4
documentation.” https://docs.python.org/3/library/re.html
(accessed May 10, 2022).
[24] P. Lam, J. Dietrich, and D. J. Pearce, “Putting the Semantics
into Semantic Versioning.” arXiv, Aug. 16, 2020. Accessed:
May 18, 2022. [Online]. Available:
http://arxiv.org/abs/2008.07069
[25] “Solidity v0.8.0 Breaking Changes.”
https://docs.soliditylang.org/en/v0.8.13/080-breaking-
changes.html (accessed May 08, 2022).
[26] N. F. Samreen and M. H. Alalfi, “Reentrancy
Vulnerability Identification in Ethereum Smart Contracts,” in 2020
IEEE International Workshop on Blockchain Oriented Software
Engineering (IWBOSE), Feb. 2020, pp. 22–29.