在本篇文章中，我将通过一个攻击事件引出 Reflection Token 攻击事件的一个通用分析思路。
关于 Reflection Token 的其他案例分析，可以参考BEVO代币攻击事件分析及复现一文。

TomInu 攻击事件

TomInu Token 是一个反射型代币 reflection token，于2023-01-26遭到黑客攻击，攻击者获利35577美元。

TomInu（被攻击合约）: 0x2d0e64b6bf13660a4c0de42a0b88144a7c10991f
攻击交易: https://phalcon.blocksec.com/tx/eth/0x6200bf5c43c214caa1177c3676293442059b4f39eb5dbae6cfd4e6ad16305668

攻击过程较为简单，攻击者通过几个常规操作就完成获利。

攻击者借出闪电贷
用 WETH swap 出 1465904852700232013011 TINU
deliver 1465904852700232013011 TINU
skim 得到 1733770910894426471783 TINU（在这一步已经完成了获利）
把 TINU swap 为 WETH
归还闪电贷

本次攻击事件通过推文告警并且进行了分析，但是很可惜分析的结论略显含糊的。红框标注的部分并不是攻击者获利的真正原因。（为什么不是真的）

推文：https://twitter.com/QuintenDes/status/1618730379447508998

并且，目前在在网络上搜索到的所有关于 reflection token 攻击事件的成因分析中提到：“由于攻击者 deliver 了一笔 token ，导致了 pair 中的 token 升值，从而能够 skim 出更多的 token 进行获利”。这类分析大多是理所当然地下结论，没有通过实际的计算推导，妄下结论误导读者。（为什么这么说）

攻击过程很简单，先 deliver 然后 skim，就能够获利了。根据这个攻击过程的特征，我们直接找 rToken增发代码，定位漏洞点。（为什么可以这么做）

以上的几个为什么都将会在后面“为什么”这一章节进行解释，读者可以先带着疑问进行阅读。

漏洞分析

在 _transferStandard 函数中可以看出，TomInu 代币在进行转账 rAmount 时需要收取 team 和 fee 两种手续费，并将扣除了手续费后的 rTransferAmount 转给收款人。

其中 team 手续费 rteam 留存在本合约中，fee 手续费 rfee 则是直接销毁。

此时他们的数量关系应该为：rTransferAmount = rAmount - rteam - rfee

问题出现在 _getRValues 函数中，该函数在计算 rTransferAmount 的过程中忽略了 rteam 参数，计算 rTransferAmount = rAmount - rfee 得到的结果比实际结果要大，造成了 rToken 的增发。也就是说，因为这个计算问题，市场上实际流通的 rAmount 总和是要大于 rTotal 的值的。

代币合约在执行 _transfer() 函数的时候，会将本合约的代币 swap 成 ETH，这个操作使得增发的代币一直累计在 pair 中。

为什么

在这个章节中，会对前面的暴言暴论进行解释

为什么推文中的关于漏洞成因的结论是含糊的不准确的。
什么说关于 reflection token 攻击事件的成因分析中提到“由于攻击者 deliver 了一笔 token ，导致了 pair 中的 token 升值，从而能够 skim 出更多的 token 进行获利”的分析结论都是错误的。
为什么看到攻击过程先 deliver 然后 skim 就完成获利之后，我得出的结论是直接找 rToken增发代码定位漏洞点。

首先我将举几个例子来模拟整个 deliver-skim 的过程，为了使得这个例子尽可能的简单，这个过程中将不考虑任何手续费的收取。

场景1：

只有 attacker 和 pair 持有所有的 token

rTotal 1000, tTotal 100, rate 10

pair: rAmount 500, tAmount 50
attacker: rAmount 500, tAmount 50

attacker deliver 500 rAmount

rTotal 500, tTotal 100, rate 5

pair: rAmount 500, tAmount 100
attacker: rAmount 0, tAmount 0

此时，pair 的 tAmount 从 50 变成了 100。接下来 attacker 将调用 skim 来获利了是不是？

attacker calls pair.skim()

rTotal 500, tTotal 100, rate 5

pair: rAmount 250, tAmount 50
attacker: rAmount 250, tAmount 50

attacker 如愿以偿获利了吗？没有，attacker 和 pair 又回到了最初的 50 tAmount，并不能通过这个操作来进行获利。

场景2：

attacker， pair 以及一些其他用户共同持有所有的 token

rTotal 1000, tTotal 100, rate 10

pair: rAmount 250, tAmount 25
attacker: rAmount 500, tAmount 50
others: rAmount 250, tAmount 25

attacker deliver 500 rAmount

rTotal 500, tTotal 100, rate 5

pair: rAmount 250, tAmount 50
attacker: rAmount 0, tAmount 0
others: rAmount 250, tAmount 50

attacker calls pair.skim()

rTotal 500, tTotal 100, rate 5

pair: rAmount 125, tAmount 25
attacker: rAmount 125, tAmount 25
others: rAmount 250, tAmount 50

pair 回到了原始的 25 tAmount，而 attacker 由原来的 50 亏损到了 25 tAmount。坚定持有的 others 由 25 上涨到了 50 tAmount。

通过上面的两个例子，我们可以得出结论，只有当 attacker 和 pair 所持有的代币份额合计 100% 的情况下，deliver-skim 的操作 attacker 才不会亏损。而两者份额不足 100% 的情况下，deliver-skim 的操作反而会导致 attacker 遭受损失。也就是说 attacker 通过 deliver-skim 的操作无论怎么样都是不赚的，最好的情况是 attacker 和 pair 所持有的代币份额合计 100% 的情况下才不至于亏损。

那么…有没有更好的情况呢？好到…两者持有的代币份额合计起来…超过100%？

比如，发生了代币增发？

场景3：

由于代码存在 rToken 相关的计算错误，导致代币增发的发生，具体表现为 rToken 的实际流通量大于 rTotal 的数量。

rTotal 1000, tTotal 100, rate 10

pair: rAmount 400, tAmount 40
attacker: rAmount 800, tAmount 80
others: rAmount 400, tAmount 40

sum_rAmount = 1600 > rTotal = 1000
pair.rAmount + attacker.rAmount = 1200 > rTotal = 1000

attacker deliver 800 rAmount

rTotal 200, tTotal 100, rate 2

pair: rAmount 400, tAmount 200
attacker: rAmount 0, tAmount 0
others: rAmount 400, tAmount 200

attacker calls pair.skim()

rTotal 200, tTotal 100, rate 2

pair: rAmount 80, tAmount 40
attacker: rAmount 320, tAmount 160
others: rAmount 400, tAmount 200

至此，attacker 从原来的 80 tAmount，通过 deliver-skim 操作获利达到 160 tAmount。

通过这个场景，也就可以解释为什么看到攻击过程中通过 deliver-skim 操作获利时，首先想到的就是去找代码中使得 rAmount 增发的计算操作。因为只有 rAmount 发生了增发，pair 和 attacker 的份额大于 100%，且增发部分需要留存在 pair 合约中，才能够满足通过 deliver-skim 操作进行获利的基础条件。