1、在代码第 6 行首先检查了现在是否在保险期限内，这自然是肯定的

2、在代码第 11 行则对 vaultToExerciseFrom 是否创建了 vault 进行检查，注意这里只是检查了是否有创建 vault

3、在代码第 14、16、21 行对传入的 oTokensToExercise 值进行了检查，在上图 OKO 浏览器中我们可以看到攻击者传入了 0x1443fd000，这显然是可以通过检查的

4、接下来在代码第 28 行计算需要消耗的 ETH 数量

5、在代码第 35、41 行计算需要支付的数量与手续费

6、接下来在代码第 59 行对 underlying 是否是 ETH 地址进行判断，而 underlying 在上面代码第 31 行进行了赋值，由于 isETH 为 true， 因此将会进入 if 逻辑而不会走 else 逻辑，在 if 逻辑中 amtUnderlyingToPay 与 msg.value 都是用户可控的

7、随后对 oTokensToExercise 进行了燃烧，并调用 transferCollateral 函数将 USDC 转给 exercise 函数的调用者

以上关键的地方在于步骤 2 与步骤 6，因此我们只需要确保传入的 vaultToExerciseFrom 都创建了 vault，且使 amtUnderlyingToPay 与 msg.value 相等即可，而这些相关参数都是我们可以控制的，所以攻击思路就显而易见了。思路验证

让我们通过攻击者的操作来验证此过程是否如我们所想：

1、首先在保险期限内是肯定的

2、攻击者传入的 vaultToExerciseFrom 分别为：

0xe7870231992ab4b1a01814fa0a599115fe94203f0x076c95c6cd2eb823acc6347fdf5b3dd9b83511e4

经验证，这两个地址都创建了 vault

3、攻击者调用 exercise 传入 oTokensToExercise 为 0x1443fd000 (5440000000)，msg.value 为 272ETH，vaultsToExerciseFrom 分别为以上两个地址

4、此时由于此前攻击者创建的 oToken 为 0xa21fe800 (2720000000)，及 vault.oTokensIssued 为 2720000000 小于 5440000000，所以将走 exercise 函数中的 else 逻辑，此时 oTokensToExercise 为 0xa21fe800 (2720000000)，则以上代码第 60 行 msg.value == amtUnderlyingToPay 是肯定成立的

5、由于 vaultsToExerciseFrom 传入两个地址，所以 for 循环将执行两次 _exercise 函数，因此将 transfer 两次把 USDC 转给攻击者合约 (责任编辑：admin)