暗夜临近，DApp江湖上演现实版"狼人杀"

"狼人杀"游戏里有一个规则，"狼人"可以在黑夜随意杀人，在白天还能通过口舌雄辩来逃避"平民"的指认，最终两面三刀杀光所有的"平民"赢得胜利。

这两天，DApp 江湖里就上演了一个真实版"狼人杀"。一家名为 TronBank Pro 的资金盘 DApp 被黑客洗劫了 2,673 万个 TRX，项目投资者"平民"蒙受了近 500 万元的财产损失。然而，究竟谁是"狼人"？众说不一，社区开始了激烈的讨论。

目前为止，出现了三种看似合理的故事主线：

• 项目方"监守自盗"，其合约代码中留有"后门"。原因在于，项目方开源的代码和实际执行的代码并不一致，向合约发送 0.011911 TRX 的 withdraw() 操作会触发预留的后门，将合约余额全部取走。尽管 TronBank Pro 发了公告否认了这种说法，但目前为止，为何会存在"后门"并没有合理的解释。

• 项目方遭第三方验证服务平台 TSC "算计"。根据区块链安全公司 PeckShield 的深入分析，作为第三方服务平台，TSC 早在 4 月 28 日即项目合约上线前就发现了该"后门"，并且成功实施了攻击测试。但黑客代号 wojak的用户目前并未发现和 TSC 有任何关联，一时间事情真相又陷入扑朔迷离。但可以断定，第三方服务平台 TSC 很难跟此事撇清关系了。

• 黑客上演了"螳螂捕蝉黄雀在后"的精彩大戏。存在一种可能，TSC 一早就命中了"后门"，但碍于资金池尚未壮大起来迟迟没有下手，然而躲在暗处的黑客 wojak 同样发现了"后门"，且抢先一步实施了攻击。吊诡的是，wojak 竟然还在事后现身说法，承诺将退还被盗资金，不过，因为种种原因，wojak 很快又表态拒绝归还，并已消失不见。如此任性且可爱的黑客，并不多见。

PeckShield 数字资产追踪平台介入了 Tron 平台上的这起重大『安全事故』（事故分两种：一种是天灾，一种是人祸），并追踪还原了事情的来龙去脉，尽可能的通过技术分析帮助受害投资者"平民"找到真相。

至于以下讲述的是天灾还是人祸，留给读者自行判断。

背景

朋友，你听说过 TronBankPro 吗？一种日收益固定 1.8% - 4.8% 的区块链投资产品，我们合约代码开源，合约通过『知名』校验机构 tronsmartcontract.space(TSC) 验证与链上数据一致。虽然我们之前受到 BTTBank 假币事件的攻击，但我们是一个负责任的团队，我们不会，跑路...

小白投资者认为既然 TronBank 团队之前发生过安全事件，想必这次应该会做好相应的合约审查工作，用户从其官网上的确可以看到，这个团队还是在『做事的』，相比其它未开源 DApp 来说，这个项目方竟然把源代码都公布了出来，『还是值得信赖的』。

不专业的 TSC

由于缺乏官方的认证平台，一些 DApp 开发者平着『向用户负责』的态度，Tron 平台上大部分 DApp 合约使用了第三方平台 TSC 的合约一致性校验服务（目前 Tron 官方并未推出此类服务，市面可见的只有 https://tronsmartcontract.space 一家）。PeckShield 安全人员深入分析发现：TSC 能帮 DApp 开发者验证一些基础安全保障，但TSC服务代码自身尚不完备，不能保证校验结果的可靠性。截止目前 TSC 审核通过的 278 个合约中，其合约源码与 Tron 链上一致的仅为 85 个，不合格比例高达 70%，如此高比例的不合格率，如何能获得用户和 DApp 开发者的认可？

PeckShield 安全人员和 TSC 开发者取得联系之后，对方也坦言此项服务尚在建设初期，不能保障审计结果的可靠性。另外，Tron 官方并未承认，也不建议社区采纳和信任 tronsmartcontract.space 的验证结果，见 Tron 孙老板的微博内容：

搞鬼的 TSC

PeckShield 安全人员分析 TSC 官网，查找该站点是否存在被黑客攻击的蛛丝马迹，当访问该站点『合约验证』功能时，发现在这个关键时刻 TSC 出于某种原因关闭了。PeckShield 安全人员与 TSC  维护者 KhanhND69 询问相关事宜之后，对方表示之前的审计日志近期被删除了，『合约验证』功能关闭是由于当前在开发新版本的功能，这一旧功能已经下线。至于新功能何时上线，对方并未明确表示。

至于 TSC 的说法是否合乎逻辑，动机是否单纯，留待读者自行品味。

既然 TSC 只是一个『独立』的代码验证平台，那么他和这次 TronBankPro 被『盗』又有什么关系呢？

通过 GitHub 上开源的后端验证代码：

可以知晓，其验证的流程如下：

• 通过指定的合约地址从 Tron 链上获取到合约的 bytecode createByteCode;

• 通过给定的合约源码和编译器版本编译得到 bytecode reCompileByteCode;

• 根据 reCompileByteCode 长度获取等长的 createByteCode，然后按字节比较两者的差异性；

• 如果两者差异的字节数 < 64，那么认为两者是一致的，否则验证失败。

上述的验证流程简单『实在』，小编对此次受『攻击』的 TronBankPro 合约，即  TSC 开源的 TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ 源码重新验证，发现两者无法匹配，差异非常之大，根本不可能满足代码中的条件。

在此，小编认为 TSC 在此次『事故』中非常有可能不按套路（套路是什么？我不懂，手动黑人脸）出牌。

另外，小编意外发现了以下几个疑点：

• TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ  合约验证时间在北京时间 2019-04-28 22:51:32；而在同一天 TSC 将 GitHub 上面开源的所有已经验证的合约的 git commit 历史全部删除了，号称 Db backup, 删除之后验证的第一个合约就是 TronBank Pro 的 TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ 合约，这怎么看都像是在搞事情：

  

• TSC#author 页面显示，这一平台的捐助者地址为  TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr：

  

天黑了

天黑了，所有人请闭眼，狼人出来杀人…

仔细分析与 TTX5N… 这一地址有往来的其它地址信息，发现了一些比较有趣的故事，请听小编慢慢道来。

整个『事故』的时间线大体分为几部分：

• 准备期

• 潜伏期

• 收割期

• 套现期

看官，请看完整的故事情节：

准备期

• 4.28 17:35 +UTC8 TSC 捐助者地址  TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr 创建了合约 bytecode 与后面出事的 TronBankPro 几乎完全一样的 TBPro 合约，合约地址为 TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz，对应的交易哈希为 b20242bbabfc357f4e6f5d31641d350670c7be1a6536eef1133f344a29972f53，试问当时 TronBank Pro 合约并未上线，那么 TSC 如何知道一个并未上线的合约内容？

• 4.28 22:48 +UTC8 TronBank 项目方 部署 TBPro 合约，合约地址为 TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ, 交易哈希为 267a8671989e5e0cf30cc9a32eb8a74cfb0c106209dd8ac462211687280419b5；

• 根据 tronsmartcontract.verify/TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ/info.json at master · TSC/tronsmartcontract.verify 中指定的时间，我们知道 TronBankPro 部署的 TBPro 在 4.28 22:51 +UTC8 『验证通过』；（前面小编使用了各种计算机知识，根本就无法验证通过，那么 TSC 又是如何验证通过的呢？鬼知道呢）；

• 4.28 23:00 +UTC8  TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr 对 TronBankPro 部署的 TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ 合约发送 withdraw() 命令，并携带了 0.011011TRX, 对应的交易哈希为 d6d89713ebdb98402ddfd1d454be394a5521c83b7d385ce2c394924a2b923c89。从区块浏览器中可以看到，这一笔交易被 REVERT ，根据 PeskShield 安全人员分析认为原因是因为发送的 withdraw() 命令携带了 TRX, 这一点是可以理解的：withdraw() 用于从合约中取回之前投资的 TRX, 这时携带了 TRX 过来的交易认为是『误操作』，REVERT 是合理的：

  

潜伏期

等待着用户投资蜂拥而至，合约资金池壮大。

• 4.30 10:12 +UTC8  TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr 对自己部署的  TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz 合约同样发送携带了 0.011011TRX 的  withdraw() 命令, 对应的交易哈希为 4b8dd07afa029126f16c192e8eb8a158f883e80a6be1eceaa432247bb06ef6ab，同上一个操作，这一笔交易被 REVERT；

• 4.30 10:12 +UTC8 在稍后的几个区块中， TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr 对自己部署的  TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz 合约同样发送携带了 0.011911TRX 的  withdraw() 命令, 对应的交易哈希为 87bf173c126c4873ad333c02d4e352bacda9bfaae4d91d0bce156eb64bd5219f，而这一次却成功了：

  

  这一次， 不仅成功了，而且还从 TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz 合约中转了 100.011911TRX 到此次交易的发起方 TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr。

到此为止，好像并没有太多的故事发生，不过好戏才刚刚开始...

收割期

5.1 假期总是那么地来去匆匆，在小编还在家带娃的时间里，TronBankPro 合约已经吸引了近 1600+ 用户近 30,000,000 TRX的投资：

折合当前的市价为 700,000 美元。

眼看就到了丰收期，可是 05.03 04:12 +UTC8 有一个称号为 wojak 的黑客THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH 通过与 TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr 在上面一致的操作（withdraw() 携带 0.011911TRX）半路截胡了，并成功『取回』2600W+ TRX。至于 wojak 黑客到底是谁，目前无人知晓。具体的交易哈希如下：

基于此，PeckShield 安全人员认为 TSC  TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr 部署的 TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz 合约与 TronBankPro 部署的 TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ 合约均存在后门，至于后门是如何被安插的，被谁安插的，还不得而知。

PeckShield 安全人员对  TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz 和 TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ 合约逆向代码之后，发现其中的 withdraw() 逻辑中存在下面一段代码：

不难看出，withdraw() 根据 msg.value 即携带的 TRX 大小分为三种情况：

• 0x2B03 == msg.value

  16 进制的 0x2B03转换成十进制之后为 11011Sun(由于 TRX == 10^6 Sun)，等价于 0.011011TRX。这个值刚好就是上面 TSC TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr  测试时携带的 TRX 值。

  这个分支下，并不改变状态，交易输出 OK，并最后以 REVERT 退出，这一行为与上面交易的返回信息一致，PeckShield 安全人员认为这个分支代码是开发者故意留下的调试功能，以确认合约的逻辑是否符合预期。

• 0x2E87 == msg.value：

  16 进制的 0x2E87转换成十进制之后为 11911Sun(由于 TRX == 10^6 Sun)，等价于 0.011911TRX。这一值与 TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr  以及 THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH 调用的值是相等的。

  这一分支下，将本合约中所有的 TRX balance 全部转移到调用发起者，一点不剩。

• 其它情况，正常的 withdraw() 取回操作。

在此，PeckShield 安全人员认为，上述的 0.011011TRX 以 REVERT 退回的『误操作』实则是黑客进行攻击之前的测试环节。

套现期

黑客 THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH 获取 2600W+ TRX 之后，开始分批次分步骤转移资产：

其中，截止北京时间 2019-5-5 19:00 共有 1,4000,000 TRX 转移至 Binance 交易所。

天亮了

以上纯技术的分析说明，充分验证了两点：

• 第三方验证服务平台 TSC 并不专业，其服务过的大部分合约均存在合约源码与 Tron 链上 bytecode 不一致的情况，证明 TronBank Pro 项目方找 TSC 进行一致性校验服务存在很大疏漏。

• 第三方验证服务平台 TSC 很难避嫌，其早在TronBank Pro项目上线前发现了合约漏洞，然而其并没有督促项目方及时调整问题，而是反其道而行之实施了攻击测试，而今项目合约遭到了攻击，TSC 又怎能置身事外呢？

当然，即使 PeckShield 已经通过技术追踪，将事情的来龙去脉还原至此，在区块链的虚拟世界里，这场"狼人杀"大戏究竟谁是狼人，仍然难有定论。项目方在不对损害资金进行如数赔付之前，于情于理都难逃其责；第三方服务平台 TSC 目前来看是最大的"鬼"，但其和项目方的关系真说得清吗？至于那个任性又有些小情绪的黑客 wojak 究竟是真有其人，还是只是漩涡中一方的小马甲，谁能道得明，说得清？

校验得了的是代码，猜不透的是人性！

（作者：PeckShield，内容来自链得得内容开放平台“得得号”；本文仅代表作者观点，不代表链得得官方立场）