通过上图代码我们可以看出其先对区块头进行反序列化，以解出所需要验证的具体信息。随后调用 getCurEpochConPubKeyBytes 函数从 EthCrossChainData 合约中获取 Keeper 公钥，并通过 deserializeKeepers 函数得到 Keeper 地址。

接下来将通过 ECCUtils.verifySig 验证签名是否为 Keeper，从以下代码中我们可以发现 verifySig 函数中会切出签名者的 v r s，并通过 ecrecover 接口获取签名者地址，然后调用 containMAddresses 函数循环比较签名者是否为 Keeper，只要 Keeper 签名数量符合要求即可通过检查，数量要求即为 EthCrossChainManager 合约传入的 n - ( n - 1) / 3)。

签名验证后会通过 ECCUtils.merkleProve 进行默克尔根验证，只要是正常跨链操作即可通过此项检查。随后会对交易是否重复发送进行检查并存储已验证后的数据。这里只需保证不重复提交即可。

最后，也是最关键的一步，其将通过内部调用 _executeCrossChainTx 函数执行构造的数据。

从上图我们可以看出 _executeCrossChainTx 函数未对传入的 _toContract、_method 等参数进行检查就直接以 _toContract.call 的方式执行交易。

其中通过链上数据我们可以看出 EthCrossChainData 合约的 owner 即为 EthCrossChainManager 合约，而先前我们知道中继链验证人 (即 Keeper) 的公钥存在 EthCrossChainData 合约中，且此合约存在 putCurEpochConPubKeyBytes 函数可以直接修改 Keeper 公钥。

经过以上分析，结果已经很明确了，攻击者只需在其他链通过 crossChain 正常发起跨链操作的交易，此交易目的是为了调用 EthCrossChainData 合约的 putCurEpochConPubKeyBytes 函数以修改 Keeper 角色。随后通过正常的跨链流程，Keeper 会解析用户请求的目标合约以及调用参数，构造出一个新的交易提交到以太坊上。这本质上也只是一笔正常的跨链操作，因此可以直接通过 Keeper 检查与默克尔根检查。最后成功执行修改 Keeper 的操作。

但我们注意到 putCurEpochConPubKeyBytes 函数定义为