diff --git a/SemSEpaper/exercise.bib b/SemSEpaper/exercise.bib index 8d5c974..85edc8c 100644 --- a/SemSEpaper/exercise.bib +++ b/SemSEpaper/exercise.bib @@ -1,4 +1,4 @@ -@INPROCEEDINGS{9678888, +@INPROCEEDINGS{smartian, author={Choi, Jaeseung and Kim, Doyeon and Kim, Soomin and Grieco, Gustavo and Groce, Alex and Cha, Sang Kil}, booktitle={2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE)}, title={SMARTIAN: Enhancing Smart Contract Fuzzing with Static and Dynamic Data-Flow Analyses}, @@ -8,7 +8,7 @@ pages={227-239}, doi={10.1109/ASE51524.2021.9678888}} -@inproceedings{10.1145/3578527.3578538, +@inproceedings{fuzzdrivegen, author = {Pani, Siddhasagar and Nallagonda, Harshita Vani and Vigneswaran and Medicherla, Raveendra Kumar and Rajan M}, title = {SmartFuzzDriverGen: Smart Contract Fuzzing Automation for Golang}, year = {2023}, @@ -26,7 +26,7 @@ series = {ISEC '23} } -@inproceedings {217464, +@inproceedings {teether, author = {Johannes Krupp and Christian Rossow}, title = {{teEther}: Gnawing at Ethereum to Automatically Exploit Smart Contracts}, booktitle = {27th USENIX Security Symposium (USENIX Security 18)}, @@ -39,7 +39,7 @@ month = aug } -@inproceedings{10.1145/3243734.3243780, +@inproceedings{securify, author = {Tsankov, Petar and Dan, Andrei and Drachsler-Cohen, Dana and Gervais, Arthur and B\"{u}nzli, Florian and Vechev, Martin}, title = {Securify: Practical Security Analysis of Smart Contracts}, year = {2018}, @@ -56,3 +56,17 @@ location = {Toronto, Canada}, series = {CCS '18} } + +@MISC{ + doughoyte, + author = {doughoyte}, + title = {MerdeToken: It's Some Hot Shit}, + note = {\url{https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte} [Accessed: Oct. 27th 2023]} +} + +@misc{CiteDrive2022, + title = {CiteDrive brings reference management to Overleaf}, + author = {CiteDrive, Inc}, + year = 2022, + note = {\url{https://www.citedrive.com/overleaf} [Accessed: (Use the date of access)]} +} \ No newline at end of file diff --git a/SemSEpaper/exercises.aux b/SemSEpaper/exercises.aux index bbb3495..92af00e 100644 --- a/SemSEpaper/exercises.aux +++ b/SemSEpaper/exercises.aux @@ -4,18 +4,22 @@ \@writefile{toc}{\contentsline {section}{\numberline {1}Weakness and consequences}{1}{}\protected@file@percent } \@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Solidity storage layout}{1}{}\protected@file@percent } \@writefile{toc}{\contentsline {subsection}{\numberline {1.2}The Weakness}{1}{}\protected@file@percent } -\@writefile{loa}{\contentsline {algocf}{\numberline {1}{\ignorespaces A completely unchecked array write}}{1}{}\protected@file@percent } -\citation{10.1145/3243734.3243780} -\citation{10.1145/3578527.3578538} -\citation{217464} -\citation{9678888} -\bibdata{exercise.bib} -\bibcite{9678888}{1} -\bibcite{217464}{2} -\bibcite{10.1145/3578527.3578538}{3} +\citation{securify} +\citation{teether} +\@writefile{loa}{\contentsline {algocf}{\numberline {1}{\ignorespaces A completely unchecked array write}}{2}{}\protected@file@percent } \@writefile{loa}{\contentsline {algocf}{\numberline {2}{\ignorespaces An incorrectly managed array length}}{2}{}\protected@file@percent } \@writefile{toc}{\contentsline {section}{\numberline {2}Vulnerable contracts in literature}{2}{}\protected@file@percent } -\@writefile{toc}{\contentsline {section}{\numberline {3}Code properties and automatic detection}{2}{}\protected@file@percent } -\@writefile{toc}{\contentsline {section}{\numberline {4}Exploit sketch}{2}{}\protected@file@percent } -\bibcite{10.1145/3243734.3243780}{4} -\gdef \@abspage@last{3} +\citation{securify} +\citation{teether} +\citation{fuzzdrivegen} +\citation{smartian} +\citation{doughoyte} +\bibdata{exercise.bib} +\bibcite{smartian}{1} +\bibcite{doughoyte}{2} +\bibcite{teether}{3} +\bibcite{fuzzdrivegen}{4} +\@writefile{toc}{\contentsline {section}{\numberline {3}Code properties and automatic detection}{3}{}\protected@file@percent } +\@writefile{toc}{\contentsline {section}{\numberline {4}Exploit sketch}{3}{}\protected@file@percent } +\bibcite{securify}{5} +\gdef \@abspage@last{4} diff --git a/SemSEpaper/exercises.bbl b/SemSEpaper/exercises.bbl index c94dfce..690cc6d 100644 --- a/SemSEpaper/exercises.bbl +++ b/SemSEpaper/exercises.bbl @@ -1,6 +1,6 @@ \begin{thebibliography}{1} -\bibitem{9678888} +\bibitem{smartian} Jaeseung Choi, Doyeon Kim, Soomin Kim, Gustavo Grieco, Alex Groce, and Sang~Kil Cha. \newblock Smartian: Enhancing smart contract fuzzing with static and dynamic @@ -8,14 +8,21 @@ Jaeseung Choi, Doyeon Kim, Soomin Kim, Gustavo Grieco, Alex Groce, and Sang~Kil \newblock In {\em 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE)}, pages 227--239, 2021. -\bibitem{217464} +\bibitem{doughoyte} +doughoyte. +\newblock Merdetoken: It's some hot shit. +\newblock + \url{https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte} + [Accessed: Oct. 27th 2023]. + +\bibitem{teether} Johannes Krupp and Christian Rossow. \newblock {teEther}: Gnawing at ethereum to automatically exploit smart contracts. \newblock In {\em 27th USENIX Security Symposium (USENIX Security 18)}, pages 1317--1333, Baltimore, MD, August 2018. USENIX Association. -\bibitem{10.1145/3578527.3578538} +\bibitem{fuzzdrivegen} Siddhasagar Pani, Harshita~Vani Nallagonda, Vigneswaran, Raveendra~Kumar Medicherla, and Rajan M. \newblock Smartfuzzdrivergen: Smart contract fuzzing automation for golang. @@ -23,7 +30,7 @@ Siddhasagar Pani, Harshita~Vani Nallagonda, Vigneswaran, Raveendra~Kumar Conference}, ISEC '23, New York, NY, USA, 2023. Association for Computing Machinery. -\bibitem{10.1145/3243734.3243780} +\bibitem{securify} Petar Tsankov, Andrei Dan, Dana Drachsler-Cohen, Arthur Gervais, Florian B\"{u}nzli, and Martin Vechev. \newblock Securify: Practical security analysis of smart contracts. diff --git a/SemSEpaper/exercises.blg b/SemSEpaper/exercises.blg index 84fb2fc..e469b2a 100644 --- a/SemSEpaper/exercises.blg +++ b/SemSEpaper/exercises.blg @@ -5,44 +5,44 @@ Reallocating 'name_of_file' (item size: 1) to 6 items. The style file: plain.bst Reallocating 'name_of_file' (item size: 1) to 13 items. Database file #1: exercise.bib -You've used 4 entries, +You've used 5 entries, 2118 wiz_defined-function locations, - 525 strings with 5122 characters, -and the built_in function-call counts, 2044 in all, are: -= -- 206 -> -- 107 + 528 strings with 5241 characters, +and the built_in function-call counts, 2246 in all, are: += -- 224 +> -- 114 < -- 3 -+ -- 42 -- -- 38 -* -- 137 -:= -- 313 -add.period$ -- 15 -call.type$ -- 4 -change.case$ -- 31 ++ -- 45 +- -- 40 +* -- 142 +:= -- 346 +add.period$ -- 18 +call.type$ -- 5 +change.case$ -- 35 chr.to.int$ -- 0 -cite$ -- 4 -duplicate$ -- 91 -empty$ -- 144 -format.name$ -- 38 -if$ -- 458 +cite$ -- 5 +duplicate$ -- 98 +empty$ -- 166 +format.name$ -- 40 +if$ -- 502 int.to.chr$ -- 0 -int.to.str$ -- 4 +int.to.str$ -- 5 missing$ -- 4 -newline$ -- 23 -num.names$ -- 8 -pop$ -- 38 +newline$ -- 28 +num.names$ -- 10 +pop$ -- 49 preamble$ -- 1 -purify$ -- 27 +purify$ -- 30 quote$ -- 0 -skip$ -- 75 +skip$ -- 81 stack$ -- 0 -substring$ -- 102 -swap$ -- 40 +substring$ -- 107 +swap$ -- 41 text.length$ -- 3 text.prefix$ -- 0 top$ -- 0 -type$ -- 16 +type$ -- 20 warning$ -- 0 -while$ -- 14 -width$ -- 5 -write$ -- 53 +while$ -- 16 +width$ -- 6 +write$ -- 62 diff --git a/SemSEpaper/exercises.log b/SemSEpaper/exercises.log index d249b30..93014b7 100644 --- a/SemSEpaper/exercises.log +++ b/SemSEpaper/exercises.log @@ -1,4 +1,4 @@ -This is pdfTeX, Version 3.141592653-2.6-1.40.25 (MiKTeX 23.5) (preloaded format=pdflatex 2023.6.4) 23 OCT 2023 20:33 +This is pdfTeX, Version 3.141592653-2.6-1.40.25 (MiKTeX 23.5) (preloaded format=pdflatex 2023.6.4) 27 OCT 2023 11:03 entering extended mode restricted \write18 enabled. %&-line parsing enabled. @@ -515,46 +515,53 @@ Package: relsize 2013/03/29 ver 4.1 \c@algocf=\count297 \algocf@algoframe=\box70 \algocf@algobox=\box71 +) (d:\Users\Forest\AppData\Local\Programs\MiKTeX\tex/latex/float\float.sty +Package: float 2001/11/08 v1.3d Float enhancements (AL) +\c@float@type=\count298 +\float@exts=\toks34 +\float@box=\box72 +\@float@everytoks=\toks35 +\@floatcapt=\box73 ) -\c@theorem=\count298 +\c@theorem=\count299 (d:\Users\Forest\AppData\Local\Programs\MiKTeX\tex/latex/l3backend\l3backend-pd ftex.def File: l3backend-pdftex.def 2023-04-19 L3 backend support: PDF output (pdfTeX) -\l__color_backend_stack_int=\count299 -\l__pdf_internal_box=\box72 +\l__color_backend_stack_int=\count300 +\l__pdf_internal_box=\box74 ) (exercises.aux) \openout1 = `exercises.aux'. -LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 69. -LaTeX Font Info: ... okay on input line 69. -LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 69. -LaTeX Font Info: ... okay on input line 69. -LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 69. -LaTeX Font Info: ... okay on input line 69. -LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 69. -LaTeX Font Info: ... okay on input line 69. -LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 69. -LaTeX Font Info: ... okay on input line 69. -LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 69. -LaTeX Font Info: ... okay on input line 69. -LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 69. -LaTeX Font Info: ... okay on input line 69. +LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 70. +LaTeX Font Info: ... okay on input line 70. +LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 70. +LaTeX Font Info: ... okay on input line 70. +LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 70. +LaTeX Font Info: ... okay on input line 70. +LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 70. +LaTeX Font Info: ... okay on input line 70. +LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 70. +LaTeX Font Info: ... okay on input line 70. +LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 70. +LaTeX Font Info: ... okay on input line 70. +LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 70. +LaTeX Font Info: ... okay on input line 70. (d:\Users\Forest\AppData\Local\Programs\MiKTeX\tex/context/base/mkii\supp-pdf.m kii [Loading MPS to PDF converter (version 2006.09.02).] -\scratchcounter=\count300 +\scratchcounter=\count301 \scratchdimen=\dimen263 -\scratchbox=\box73 -\nofMPsegments=\count301 -\nofMParguments=\count302 -\everyMPshowfont=\toks34 -\MPscratchCnt=\count303 +\scratchbox=\box75 +\nofMPsegments=\count302 +\nofMParguments=\count303 +\everyMPshowfont=\toks36 +\MPscratchCnt=\count304 \MPscratchDim=\dimen264 -\MPnumerator=\count304 -\makeMPintoPDFobject=\count305 -\everyMPtoPDFconversion=\toks35 +\MPnumerator=\count305 +\makeMPintoPDFobject=\count306 +\everyMPtoPDFconversion=\toks37 ) (d:\Users\Forest\AppData\Local\Programs\MiKTeX\tex/latex/epstopdf-pkg\epstopdf- base.sty @@ -566,19 +573,19 @@ Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4 cfg File: epstopdf-sys.cfg 2021/03/18 v2.0 Configuration of epstopdf for MiKTeX )) -\c@lstlisting=\count306 -LaTeX Font Info: Trying to load font information for U+lasy on input line 72 +\c@lstlisting=\count307 +LaTeX Font Info: Trying to load font information for U+lasy on input line 73 . (d:\Users\Forest\AppData\Local\Programs\MiKTeX\tex/latex/base\ulasy.fd File: ulasy.fd 1998/08/17 v2.2e LaTeX symbol font definitions ) -LaTeX Font Info: Trying to load font information for U+msa on input line 72. +LaTeX Font Info: Trying to load font information for U+msa on input line 73. (d:\Users\Forest\AppData\Local\Programs\MiKTeX\tex/latex/amsfonts\umsa.fd File: umsa.fd 2013/01/14 v3.01 AMS symbols A ) -LaTeX Font Info: Trying to load font information for U+msb on input line 72. +LaTeX Font Info: Trying to load font information for U+msb on input line 73. (d:\Users\Forest\AppData\Local\Programs\MiKTeX\tex/latex/amsfonts\umsb.fd @@ -587,41 +594,57 @@ File: umsb.fd 2013/01/14 v3.01 AMS symbols B (d:\Users\Forest\AppData\Local\Programs\MiKTeX\tex/latex/listings\lstlang1.sty File: lstlang1.sty 2023/02/27 1.9 listings language file ) -Overfull \hbox (15.0pt too wide) detected at line 112 -[][] - [] - - -Overfull \hbox (15.0pt too wide) detected at line 147 +Overfull \hbox (15.0pt too wide) detected at line 117 [][] [] [1 {C:/Users/Forest/AppData/Local/MiKTeX/fonts/map/pdftex/pdftex.map}] -(exercises.bbl [2]) [3] (exercises.aux) ) +Overfull \hbox (15.0pt too wide) detected at line 156 +[][] + [] + +[2] (exercises.bbl +! Undefined control sequence. +l.15 \url + {https://github.com/Arachnid/uscc/tree/master/submissions-2017/do... +The control sequence at the end of the top line +of your error message was never \def'ed. If you have +misspelled it (e.g., `\hobx'), type `I' and the correct +spelling (e.g., `I\hbox'). Otherwise just continue, +and I'll forget about whatever was undefined. + + +Overfull \hbox (1.15688pt too wide) in paragraph at lines 12--17 +[]\OT1/cmr/m/n/10 doughoyte. Merdeto-ken: It's some hot shit. https://github. +com/Arachnid/uscc/tree/master/submissions- + [] + +[3]) [4] (exercises.aux) ) Here is how much of TeX's memory you used: - 16507 strings out of 476410 - 322636 string characters out of 5788642 - 1969845 words of memory out of 5000000 - 36589 multiletter control sequences out of 15000+600000 + 16580 strings out of 476410 + 323857 string characters out of 5788642 + 2009845 words of memory out of 5000000 + 36658 multiletter control sequences out of 15000+600000 521468 words of font info for 72 fonts, out of 8000000 for 9000 1141 hyphenation exceptions out of 8191 - 99i,9n,94p,442b,2016s stack positions out of 10000i,1000n,20000p,200000b,200000s - -Output written on exercises.pdf (3 pages, 137405 bytes). + 99i,9n,94p,510b,1991s stack positions out of 10000i,1000n,20000p,200000b,200000s + +Output written on exercises.pdf (4 pages, 150280 bytes). PDF statistics: - 60 PDF objects out of 1000 (max. 8388607) + 68 PDF objects out of 1000 (max. 8388607) 0 named destinations out of 1000 (max. 500000) 13 words of extra memory for PDF output out of 10000 (max. 10000000) diff --git a/SemSEpaper/exercises.pdf b/SemSEpaper/exercises.pdf index fe78170..cc74f11 100644 Binary files a/SemSEpaper/exercises.pdf and b/SemSEpaper/exercises.pdf differ diff --git a/SemSEpaper/exercises.synctex.gz b/SemSEpaper/exercises.synctex.gz index 8b58708..a829a33 100644 Binary files a/SemSEpaper/exercises.synctex.gz and b/SemSEpaper/exercises.synctex.gz differ diff --git a/SemSEpaper/exercises.tex b/SemSEpaper/exercises.tex index c505bef..da184e4 100644 --- a/SemSEpaper/exercises.tex +++ b/SemSEpaper/exercises.tex @@ -9,12 +9,13 @@ \usepackage{xspace} \usepackage{todonotes} \usepackage{listings} +\usepackage[ruled,linesnumbered]{algorithm2e} % Enables the writing of pseudo code. +\usepackage{float}% http://ctan.org/pkg/float + \newcommand{\true}{true} \newcommand{\false}{false} -\usepackage[ruled,linesnumbered]{algorithm2e} % Enables the writing of pseudo code. - - \pagestyle{plain} - \bibliographystyle{plain} +\pagestyle{plain} +\bibliographystyle{plain} \title{192.127 Seminar in Software Engineering (Smart Contracts) \\ @@ -25,15 +26,15 @@ \author{\textbf{*** YOUR NAME AND STUDENT ID ***}} - \newtheorem{theorem}{Theorem} - \newtheorem{lemma}[theorem]{Lemma} - \newtheorem{corollary}[theorem]{Corollary} - \newtheorem{proposition}[theorem]{Proposition} - \newtheorem{conjecture}[theorem]{Conjecture} - \newtheorem{definition}[theorem]{Definition} - \newtheorem{example}[theorem]{Example} - \newtheorem{remark}[theorem]{Remark} - \newtheorem{exercise}[theorem]{Exercise} +\newtheorem{theorem}{Theorem} +\newtheorem{lemma}[theorem]{Lemma} +\newtheorem{corollary}[theorem]{Corollary} +\newtheorem{proposition}[theorem]{Proposition} +\newtheorem{conjecture}[theorem]{Conjecture} +\newtheorem{definition}[theorem]{Definition} +\newtheorem{example}[theorem]{Example} +\newtheorem{remark}[theorem]{Remark} +\newtheorem{exercise}[theorem]{Exercise} \renewcommand{\labelenumi}{(\alph{enumi})} @@ -75,22 +76,26 @@ \subsection{Solidity storage layout} -Any contract's storage is a continuous 256-bit address space consisting of 32-bit values. In order to implement dynamically sized data structures like maps and arrays, Solidity distributes their entries in a pseudo-random location. Due to the vast 256-bit range of addresses collisions are statistically extremely improbable and of no practical relevance. +Any contract's storage is a continuous 256-bit address space consisting of 32-bit values. In order to implement dynamically sized data structures like maps and arrays, Solidity distributes their entries in a pseudo-random location. Due to the vast 256-bit range of addresses collisions are statistically extremely improbable and of little practical relevance in safely implemented contracts. \medspace -In the case of a dynamic array at variable slot $p$, data is written to continuous locations starting at $keccak(p)$. The array itself contains the length information. +In the case of a dynamic array at variable slot $p$, data is written to continuous locations starting at $keccak(p)$. The array itself contains the length information as an $uint256$ value. Even enormous arrays are unlikely to produce collisions due to the vast address space, although an improperly managed array may store data to an unbounded user-controlled offset, thereby allowing arbitrary overwriting of data. \medspace -For maps stored in variable slot $p$ the data for index $k$ can be found at $keccak(k . p)$ where $.$ is the concatenation operator. +For maps stored in variable slot $p$ the data for index $k$ can be found at $keccak(k . p)$ where $.$ is the concatenation operator. This is a statistically safe approach, as the chance of intentionally finding a value for $keccak(k . p)$ s.t. for a known stored variable $x$, $keccak(k . p) == storage\_address(x)$ is about one in $2^{256}$ and $keccak$ is believed to be a cryptographically secure hash function. \subsection{The Weakness} -Any unchecked array write is potentially dangerous, as the storage-location of all variables is publicly known and an unconstrained array index can be reverse engineered to target them. +Any unchecked array write is potentially dangerous, as the storage-location of all variables is publicly known and an unconstrained array index can be reverse engineered to target them. This can be achieved by using the known array storage location $p$, target-variable $x$, and computing the offset-value $o$ such that $keccac(p) + o == storage\_address(x)$. + +\medspace + +A trivial example of such a vulnerable write operation is shown in Algorithm 1. \lstset{style=mystyle} -\begin{algorithm} +\begin{algorithm}[H] \begin{lstlisting}[language=Octave] pragma solidity 0.4.25; @@ -111,37 +116,41 @@ Any unchecked array write is potentially dangerous, as the storage-location of a \caption{A completely unchecked array write} \end{algorithm} -In the following example the $pop$ function incorrectly checks for an array $length >= 0$, thereby allowing the value to underflow when called with an empty array. Once this weakness is exploited $update$ in Algorithm 2 behaves just like $write$ did in Algorithm 1. +\medspace + +In the following example (Algorithm 2) the $pop$ function incorrectly checks for an array $length >= 0$, thereby allowing the $length$ value to underflow when called with an empty array. Once this weakness is triggered, $update$ in Algorithm 2 behaves just like $write$ did in Algorithm 1. + +\medspace \lstset{style=mystyle} -\begin{algorithm} +\begin{algorithm}[H] \begin{lstlisting}[language=Octave] - pragma solidity 0.4.25; + pragma solidity 0.4.25; + + contract MyContract { + address private owner; + uint[] private arr; - contract MyContract { - address private owner; - uint[] private arr; - - constructor() public { - arr = new uint[](0); - owner = msg.sender; - } - - function push(value) { - arr[arr.length] = value; - arr.length++; - } - - function pop() { - require(arr.length >= 0); - arr.length--; - } - - function update(unit index, uint value) { - require(index < arr.length); - arr[index] = value; - } + constructor() public { + arr = new uint[](0); + owner = msg.sender; } + + function push(value) { + arr[arr.length] = value; + arr.length++; + } + + function pop() { + require(arr.length >= 0); + arr.length--; + } + + function update(unit index, uint value) { + require(index < arr.length); + arr[index] = value; + } + } \end{lstlisting} \caption{An incorrectly managed array length} \end{algorithm} @@ -153,17 +162,37 @@ collect vulnerable contracts used by different papers to motivate/illustrate the \section{Code properties and automatic detection} -summarize the code properties that tools are looking for so that they can detect the weakness +Automatic detection tools can be broadly categorized into ones employing static analysis and those who use fuzzing, i.e. application of semi-random inputs. Notable static analysis tools include Securify \cite{securify} and teEther \cite{teether} which both function in a similar manner: + +\medspace + +Initially, the given EVM byte-code is disassembled into a control-flow-graph (CFG). In the second step, the tools identify potentially risky instructions. In the case of arbitrary writes, the instruction of note is $sstore(k,v)$ where both $k$ and $v$ are input-controlled. The tools differ in the way they identify whether or not the values are input-controlled. + +\medspace + +In the case of Securify \cite{securify}, the CFG is translated into what the authors call "semantic facts" to which an elaborate set of so-called security patterns is applied. These patterns consist of building blocks in the form of predicates, which allows the tool to simply generate output based on the (transitively) matched patterns. + +\medspace + +teEther \cite{teether} employs a similar approach, but instead the authors opt to build a graph of dependent variables. If the graph arrives at a $sstore(k,v)$ instruction and a path can be found leading to user-controlled inputs, the tool infers a set of constraints which are then used to automatically generate an exploit. + +\medspace + +The fuzz-driven approach to vulnerability detection is more abstract, as general-purpose fuzzing tools generally don't have knowledge of the analysed program. For the tool SmartFuzzDriverGenerator \cite{fuzzdrivegen}, a multitude of these fuzzing libraries can be used. The problem at hand is, however, that the technique cannot interface with a smart contract out of the box. The "glue" between fuzzer and program is called a driver, hence the name of "driver-generator". + +\medspace + +SmartFuzzDriverGenerator aims to automatically generate such a driver by %TODO: I have no idea how it does this actually% + +\medspace + +The Smartian tool \cite{smartian} attempts to find a middle-ground between static and dynamic analysis by first transforming the EVM bytecode into control-flow facts. Based on this information, a set of seed-inputs is generated that are expected to have a high probability of yielding useable results. Should no exploit be found, the seed-inputs are then mutated in order to yield a higher code coverage. %TODO: This is probably extemely inprecise and should be re-written% \section{Exploit sketch} -sketch ways to potentially exploit the different variants of the weakness. +\cite{doughoyte} +%TODO: just explain what this guy does: https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte% -%remove this later% -\cite{10.1145/3243734.3243780} -\cite{10.1145/3578527.3578538} -\cite{217464} -\cite{9678888} \bibliography{exercise.bib}