背景
FPC 是 BPE-20 项目，实现了复杂的交易机制，包括买卖手续费、流动性池燃烧机制、限制交易频率、限制交易数量 等功能。漏洞产生的原因是当用户卖出代币时，合约会从流动性池中燃烧代币（而非从卖出者余额中燃烧），导致池子中 FPC 代币数量减少，价格抬高。
项目方应该是为了加上流动性池燃烧机制，发现直接加上这不行呀，这个会被利用去套利的。然后打了限制交易频率和限制交易数量两个补丁。希望以此来限制代币持有者通过机制进行获利。
攻击交易
- 攻击交易哈希 :
0x3a9dd216fb6314c013fa8c4f85bfbbe0ed0a73209f54c57c1aab02ba989f5937 - 攻击者地址 :
0xbf6e706d505e81ad1f73bbc0babfe2b414ba3eb3
漏洞合约
- FPC代币合约 :
0xb192d4a737430aa61cea4ce9bfb6432f7d42592f - 主要流动性池 :
0xa1e08e10eb09857a8c6f2ef6cca297c1a081ed6b
Trace 分析
-
攻击者通过闪电贷获得大量的 USDT
-
在 [FPC, USDT] 池子中购买大量的 FPC
-
把 FPC 转移到新的地址中
-
出售所有的 FPC：先触发流动性池燃烧机制，推高了 FPC 的价格，然后再计算出售获得的 USDT，从而获得超额的利润。
代码分析
在背景介绍了 FPC 代币实现了流动性池燃烧机制、限制交易频率、限制交易数量等功能，接下来将会通过代码实现以及攻击者的手法向读者展示。
在 [FPC, USDT] 池子中购买大量的 FPC
在黑客购买 FPC 的操作中，黑客没有通过 router 进行兑换，而是直接调用 pool 进行兑换。
markdown
CALLCake-LP.swap(**amount0Out=1,000,000,000,000,000,000**, amount1Out=790,178,970,489,172,772,916,652)并且在购买大量 FPC 代币的同时，还换出了 1 USDT。很反常的操作，如果只是为了购买 FPC，这个amount0Out 的值应为为 0。
黑客这样做的目的是为了绕开最大购买数量的限制
在直接通过 pool 大量购买 FPC 时同时换出 1 个 USDT，目的就为了欺骗 _isLiquidity 函数的检查，伪装成移除流动性的操作，使得 isDel 的值为 true。
如果 isDel 的值为 true，就会绕过 value <= _maxBuyAmount() 的限额检查了。
把 FPC 转移到新的地址中
在 FPC 代币中，如果用户进行 swap 操作，会被记录下操作的区块号，并且限制 3 个区块内不允许再次交易。但是它没有对转账操作进行限制，所以攻击者可以通过把 FPC 转移到没有进行过 swap 的地址进行出售，从而绕过这个限制。
出售所有的 FPC：触发流动性池燃烧机制
这一步是关键的步骤，卖出 FPC 代币，触发合约的燃烧机制
markdown
CALLPancakeSwap: Router v2.swapExactTokensForTokensSupportingFeeOnTransferTokens(
amountIn=247,441,170,766,403,071,054,109)在 sell 的逻辑分支中，会调用 burnLpToken 函数按照出售的数量 value 来销毁 FPC 代币。
而在 burnLpToken 函数函数中，燃烧的是 pool 中的代币（不是燃烧 seller 提供的代币，而是直接燃烧 pool 中的代币）。这样会使得 pool 中 FPC 的价格被推高。使得黑客在卖出 FPC 代币时能够获取到更多的利润。
后记
这个代币在添加流动性池燃烧机制的初衷应该是希望在用户出售代币的时候，啊把池子里面的代币取出来一点，一个是收归项目方所有，第二个是抬高一点币价不要跌的这么快。
但是，但是在 Pancake 和 Uniswap 的 V2/V3 版本中，都是遵循着"先转账，后结算"的模式去进行 swap 的。而代币设置的各种机制只能在转账的过程中触发，这就使得了这个燃烧机制始终都是发生在结算前的，这就给了黑客套利的空间。如果想要实现这种特殊机制，可以考虑一下通过 Uniswap V4 的 Hook 去实现，但是会对开发的技术与质量要求更高（不得不说后续更新的版本都不如 V2 的 x * y = k 来得简单直接，叽里咕噜又集中流动性又 Hook 说啥呢，我 V2 一把加完流动性就能用。也是为什么直至现在很多代币的发行方都钟爱在 V2 上部署池子）。