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

TomInu 攻击事件

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

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

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

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

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

推文：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 中。

为什么

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

1. 为什么推文中的关于漏洞成因的结论是含糊的不准确的。
2. 什么说关于 reflection token 攻击事件的成因分析中提到“由于攻击者 deliver 了一笔 token ，导致了 pair 中的 token 升值，从而能够 skim 出更多的 token 进行获利”的分析结论都是错误的。
3. 为什么看到攻击过程先 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 操作进行获利的基础条件。

后记

在 TomInu 攻击事件发生的4个月后，存在相同漏洞的 ADU token 再次被攻击。
ADU token attack tx：https://explorer.phalcon.xyz/tx/bsc/0xc6f6b70e9e35770b699da9b60244d461d02db66859df42319c3207d76931423c

为什么会写这篇文章，因为当我想对这些攻击事件进行学习与分析的时候，我查看了网络上的分析文章，他们给出的漏洞成因含糊不清毫无根据。我读了很多篇分析文章，说辞都是大同小异地糊弄。还没分析清楚就胡乱指点，最终被忽悠的就是真心想研究清楚的人。走了不少弯路，把弯路总结成这篇文章，感谢你的阅读。