# Detecting Rug-Pull: Analyzing Smart Contract Backdoor Codes in Ethereum
## 3 Balance-Tracking-Based Backdoor Detection Model
### Balance Tracker  
The Balance Tracker analyzes the public functions generated by the Function Extractor to classify candidate functions that pose a risk of being backdoor functions. A candidate function is defined as a function that has balance changes within it or contains a proxy-type function. To this end, the proxy function patterns are inspected, and balance changes are tracked. First, the command to call another contract is inspected to examine the proxy function pattern. The method for calling another contract on the Ethereum network can be divided into Call, DELE-GATECALL, and STATICCALL, as shown in Table 1 below. CALL and STATICCALL can execute the code of the called contract and receive the result. For example, looking at the staticTransfer function in Algorithm 4, the ADD and SUB functions that process the increase and decrease of the balance are called from the calculator address, and the results are received and applied. If the developer modifies the address of the calculator function, they can execute the backdoor code. In addition, DELEGATECALL is a method that is executed directly in the context of the caller through the function call, enabling direct backdoor code application. For example, looking at the transfer function in Algorithm 4, the transfer function is called from the calculator address, and the transfer is processed without directly calculating the balance within the function. If the developer modifies the calculator address, they can execute the backdoor code. Therefore, the presence of CALL, DELEGATECALL, and STATICCALL commands is inspected and then classified as candidate functions. Then, for the functions, the balance changes that may occur when the function is executed are tracked and classified as candidate functions. Except for proxy, all of the backdoor code types explained in Section 2.2--token generation, destroy token, transfer limitation, funds manipulation, and transfer fee--cause balance changes. For example, in the case of the token generation backdoor, the balance increases when the function is executed, but a new balance is generated without a corresponding decrease or by a larger amount compared to the existing balance. To track such balance changes, it is necessary to first identify the balance to be tracked. In the smart contract, the balance is managed as a Mapping structure that stores the user wallet address as a key and the balance as data, as shown in Algorithm 7, and can be queried using the balanceOf function, which is an ERC-20 standard function [30]. Therefore, to identify the balance variable, the variables in \begin{table}
\begin{tabular}{l l} \hline \hline
**Call Type** & **Description** \\ \hline CALL & Call a method in another contract. \\ DELEGATECALL & Call a method in another contract using the storage of the current contract. \\ STATICCALL & Call a method in another contract without state changes. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Type of Contract Calls in the Ethereum Network. the mapping structure are identified, and the variables returned by the balanceOf function are tracked to identify the variable that stores the balance. ```
11  mapping(address => uint256) private balance;
21  function balanceOf(address account) public view returns (uint256) {
31  return balance[account];
41 }
```  
**Algorithm 7**Solidity code of the balanceOf function. After that, whether there is an operation on the balance variable in each function is closely inspected. Operations on the balance variable can be largely divided into two cases. The first case is when the balance variable is directly used for the operation, which means the balance variable is directly used within the function, as in line 4 of Algorithm 1. In this case, all locations where the balance variable is used are found, and the result of the operation and the location where the operation occurred are recorded.