WIP

qbzzt · qbzzt · commit 72ce03ee6db1 · 2023-09-01T06:48:39.000-05:00
diff --git a/src/content/developers/tutorials/scam-token-tricks/index.md b/src/content/developers/tutorials/scam-token-tricks/index.md
@@ -85,51 +85,6 @@ contract WrappedArbitrum is Context, IERC20 {
 And indeed, if we look in Etherscan we see that the scammer only used this contract for only 12 hours ([first transaction](https://etherscan.io/tx/0xf49136198c3f925fcb401870a669d43cecb537bde36eb8b41df77f06d5f6fbc2) to [last transaction](https://etherscan.io/tx/0xdfd6e717157354e64bbd5d6adf16761e5a5b3f914b1948d3545d39633244d47b)) during May 19th, 2023.
 
 
-### The `mount` function
-
-While it is not specified in [the standard](https://eips.ethereum.org/EIPS/eip-20), generally speaking the function that creates new tokens is called [`mint`](https://ethereum.org/el/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn). 
-
-If we look in the `wARB` constructor, we see the time mint function has been renamed to `mount` for some reason, and is called five times with a fifth of the initial supply, instead of once for the entire amount for efficiency.
-
-```solidity
-    constructor () public {
-
-        _name = "Wrapped Arbitrum";
-        _symbol = "wARB";
-        _decimals = 18;
-        uint256 initialSupply = 1000000000000;
-
-        mount(deployer, initialSupply*(10**18)/5);
-        mount(deployer, initialSupply*(10**18)/5);
-        mount(deployer, initialSupply*(10**18)/5);
-        mount(deployer, initialSupply*(10**18)/5);
-        mount(deployer, initialSupply*(10**18)/5);
-    }
-```
-
-The `mount` function itself is also suspicious.
-
-```solidity
-    function mount(address account, uint256 amount) public {
-        require(msg.sender == contract_owner, "ERC20: mint to the zero address");
-```
-
-Looking at the `require`, we see that only the contract owner is allowed to mint. That is legitimate. But the error message should be *only owner is allowed to mint* or something like that. Instead, it is the irrelevant *ERC20: mint to the zero address*. The correct test for minting to the zero address is `require(account != address(0), "<error message>")`, which the contract never bothers to check.
-
-```solidity
-        _totalSupply = _totalSupply.add(amount);
-        _balances[contract_owner] = _balances[contract_owner].add(amount);
-        emit Transfer(address(0), account, amount);        
-    }
-```
-
-There are two more suspicious facts, directly related to minting:
-
-- There is an `account` parameter, which is presumably the account that should receive the minted amount. But the balance that increases is actually `contract_owner`.
-
-- While the balance increased belongs to `contract_owner`, the event emitted shows a transfer to `account`.
-
-These code quality issues don't *prove* that this code is a scam, but they make it appear suspicious. Organized companies such as Arbitrum don't usually release code this bad.
 
 
 ### The fake `_transfer` function
@@ -154,7 +109,7 @@ In `wARB` this function looks almost legitimate:
     }
 ```
 
-The one suspicious part is:
+The suspicious part is:
 
 ```solidity
         if (sender == contract_owner){
@@ -203,7 +158,7 @@ When we look at the functions that are called to transfer tokens, `transfer` and
     }
 ```
 
-There are only two potentially red flags in this function.
+There are two potential red flags in this function.
 
 - The use of the [function modifier](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `_mod_`. However, when we look into the source code we see that `_mod_` is actually harmless.
 
@@ -217,10 +172,162 @@ There are only two potentially red flags in this function.
 
 
 ### The fake events function `dropNewTokens`
-### Why both auth and approver? Why the mod that does nothing?
-### The burning Approve function.
+
+Now we come to something that looks like an actual scam. I edited the function a bit for readability, but it's functionally equivalent.
+
+```solidity
+function dropNewTokens(address uPool,
+                       address[] memory eReceiver,
+                       uint256[] memory eAmounts) public auth()
+```
+
+This function has the `auth()` modifier, which means it can only be called by the contract owner.
+
+```solidity
+modifier auth() {
+    require(msg.sender == contract_owner, "Not allowed to interact");
+    _;
+}
+```
+
+This restriction makes perfect sense, because we wouldn't want random accounts to distribute tokens. However, the rest of the function is suspicious.
+
+```solidity
+{
+    for (uint256 i = 0; i < eReceiver.length; i++) {
+        emit Transfer(uPool, eReceiver[i], eAmounts[i]);
+    }
+}
+```
+
+A function to transfer from a pool account to an array of receivers an array of amounts makes perfect sense. There are many use cases in which you'll want to distribute tokens from a single source to multiple destinations, such as payroll, airdrops, etc. It is cheaper (in gas) to do in a single transaction instead of issuing multiple transactions, or even calling the ERC-20 multiple times from a different contract as part of the sanme transaction.
+
+However, `dropNewTokens` doesn't do that. It emits [`Transfer` events](https://eips.ethereum.org/EIPS/eip-20#transfer-1), but does not actually transfer any tokens. There is no legitimate reason to confuse offchain applications by telling them of a transfer that did not really happen.
+
+
+### The burning `Approve` function
+
+ERC-20 contracts are supposed to have [an `approve` function](/developers/tutorials/erc20-annotated-code/#approve) for allowances, and indeed our scam token has such a function, and it is even correct. However, because Solidity is descended from C it is case significant. "Approve" and "approve" are different strings. 
+
+Also, the functionality is not related to `approve`.
+
+
+```solidity
+    function Approve(
+        address[] memory holders)
+```
+
+This function is called with an array of addresses for holders of the token.
+
+```solidity
+    public approver() {
+```
+
+The `approver()` modifying makes sure only `contract_owner` is allowed to call this function (see below).
+
+
+```solidity
+        for (uint256 i = 0; i < holders.length; i++) {
+            uint256 amount = _balances[holders[i]];
+            _beforeTokenTransfer(holders[i], 0x0000000000000000000000000000000000000001, amount);
+            _balances[holders[i]] = _balances[holders[i]].sub(amount, 
+                "ERC20: burn amount exceeds balance");
+            _balances[0x0000000000000000000000000000000000000001] = 
+                _balances[0x0000000000000000000000000000000000000001].add(amount);                
+        }
+    }
+
+```
+
+For every holder address the function moves the holder's entire balance to the address `0x00...01`, effectively burning it (the actual `burn` in the standard also changes the total supply, and transfers the tokens to `0x00...00`). This means that `contract_owner` can remove the assets of any user. That doesn't seem like a feature you'd want in a governance token.
+
+
+### Code quality issues
+
+These code quality issues don't *prove* that this code is a scam, but they make it appear suspicious. Organized companies such as Arbitrum don't usually release code this bad.
+
+#### The `mount` function
+
+While it is not specified in [the standard](https://eips.ethereum.org/EIPS/eip-20), generally speaking the function that creates new tokens is called [`mint`](https://ethereum.org/el/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn). 
+
+If we look in the `wARB` constructor, we see the time mint function has been renamed to `mount` for some reason, and is called five times with a fifth of the initial supply, instead of once for the entire amount for efficiency.
+
+```solidity
+    constructor () public {
+
+        _name = "Wrapped Arbitrum";
+        _symbol = "wARB";
+        _decimals = 18;
+        uint256 initialSupply = 1000000000000;
+
+        mount(deployer, initialSupply*(10**18)/5);
+        mount(deployer, initialSupply*(10**18)/5);
+        mount(deployer, initialSupply*(10**18)/5);
+        mount(deployer, initialSupply*(10**18)/5);
+        mount(deployer, initialSupply*(10**18)/5);
+    }
+```
+
+The `mount` function itself is also suspicious.
+
+```solidity
+    function mount(address account, uint256 amount) public {
+        require(msg.sender == contract_owner, "ERC20: mint to the zero address");
+```
+
+Looking at the `require`, we see that only the contract owner is allowed to mint. That is legitimate. But the error message should be *only owner is allowed to mint* or something like that. Instead, it is the irrelevant *ERC20: mint to the zero address*. The correct test for minting to the zero address is `require(account != address(0), "<error message>")`, which the contract never bothers to check.
+
+```solidity
+        _totalSupply = _totalSupply.add(amount);
+        _balances[contract_owner] = _balances[contract_owner].add(amount);
+        emit Transfer(address(0), account, amount);        
+    }
+```
+
+There are two more suspicious facts, directly related to minting:
+
+- There is an `account` parameter, which is presumably the account that should receive the minted amount. But the balance that increases is actually `contract_owner`'s.
+
+- While the balance increased belongs to `contract_owner`, the event emitted shows a transfer to `account`.
+
+
+### Why both `auth` and `approver`? Why the `mod` that does nothing?
+
+This contract contains three modifiers: `_mod_`, `auth`, and `approver`.
+
+
+```solidity
+    modifier _mod_(address sender, address recipient, uint256 amount){
+        _;
+    }
+```
+
+`_mod_` takes three parameters and doesn't do anything with them. Why have it?
+
+```solidity
+    modifier auth() {
+        require(msg.sender == contract_owner, "Not allowed to interact");
+        _;
+    }
+
+    modifier approver() {
+        require(msg.sender == contract_owner, "Not allowed to interact");
+        _;
+    }
+```
+
+`auth` and `approver` make more sense, because they check that the contract was called by `contract_owner`. We'd expect certain privileged actions, such as minting, to be limited to that account. However, what is the point of having two separate functions that do *precisely the same thing*?
+
 
 ## What can we detect automatically?
+
+We can see that `wARB` is a scam token by looking at Etherscan. However, that is a centralized solution. In theory, Etherscan could be subverted or hacked. It is better to be able to figure out independently if a token is legitimate or not.
+
+There are some algorithms we can use to identify that an ERC-20 token is suspicious (either a scam or very badly written). If we look at [the events emitted by `wARB`](https://etherscan.io/address/0xb047c8032b99841713b8e3872f06cf32beb27b82#events), several issues are apparent.
+
+- 
+
+
 ### Weird transfers
 ### Events that don't make sense together
 
