"狼人杀"游戏里有一个规则，"狼人"可以在黑夜随意杀人，在白天还能通过口舌雄辩来逃避"平民"的指认，最终两面三刀杀光所有的"平民"赢得胜利。这两天，DApp江湖里就上演了一个真实版"狼人杀"。一家名为TronBankPro的资金盘DApp被黑客洗劫了2,673万个TRX，项目投资者"平民"蒙受了近500万元的财产损失。然而，究竟谁是"狼人"？众说不一，社区开始了激烈的讨论。目前为止，出现了三种看似合理的故事主线：项目方"监守自盗"，其合约代码中留有"后门"。原因在于，项目方开源的代码和实际执行的代码并不一致，向合约发送0.011911TRX的withdraw()操作会触发预留的后门，将合约余额全部取走。尽管TronBankPro发了公告否认了这种说法，但目前为止，为何会存在"后门"并没有合理的解释。项目方遭第三方验证服务平台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的合约一致性校验服务。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链上获取到合约的bytecodecreateByteCode;通过给定的合约源码和编译器版本编译得到bytecodereCompileByteCode;根据reCompileByteCode长度获取等长的createByteCode，然后按字节比较两者的差异性；如果两者差异的字节数<64，那么认为两者是一致的，否则验证失败。上述的验证流程简单『实在』，小编对此次受『攻击』的TronBankPro合约，即TSC开源的TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ源码重新验证，发现两者无法匹配，差异非常之大，根本不可能满足代码中的条件。在此，小编认为TSC在此次『事故』中非常有可能不按套路出牌。另外，小编意外发现了以下几个疑点：TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ合约验证时间在北京时间2019-04-2822:51:32；而在同一天TSC将GitHub上面开源的所有已经验证的合约的gitcommit历史全部删除了，号称Dbbackup,删除之后验证的第一个合约就是TronBankPro的TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ合约，这怎么看都像是在搞事情：TSC#author页面显示，这一平台的捐助者地址为TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr：天黑了
天黑了，所有人请闭眼，狼人出来杀人…仔细分析与TTX5N…这一地址有往来的其它地址信息，发现了一些比较有趣的故事，请听小编慢慢道来。整个『事故』的时间线大体分为几部分：准备期潜伏期收割期套现期看官，请看完整的故事情节：准备期
4.2817:35+UTC8TSC捐助者地址TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr创建了合约bytecode与后面出事的TronBankPro几乎完全一样的TBPro合约，合约地址为TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz，对应的交易哈希为b20242bbabfc357f4e6f5d31641d350670c7be1a6536eef1133f344a29972f53，试问当时TronBankPro合约并未上线，那么TSC如何知道一个并未上线的合约内容？4.2822:48+UTC8TronBank项目方部署TBPro合约，合约地址为TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ,交易哈希为267a8671989e5e0cf30cc9a32eb8a74cfb0c106209dd8ac462211687280419b5；根据tronsmartcontract.verify/TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ/info.jsonatmaster·TSC/tronsmartcontract.verify中指定的时间，我们知道TronBankPro部署的TBPro在4.2822:51+UTC8『验证通过』；；4.2823:00+UTC8TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr对TronBankPro部署的TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ合约发送withdraw()命令，并携带了0.011011TRX,对应的交易哈希为d6d89713ebdb98402ddfd1d454be394a5521c83b7d385ce2c394924a2b923c89。从区块浏览器中可以看到，这一笔交易被REVERT，根据PeskShield安全人员分析认为原因是因为发送的withdraw()命令携带了TRX,这一点是可以理解的：withdraw()用于从合约中取回之前投资的TRX,这时携带了TRX过来的交易认为是『误操作』，REVERT是合理的：潜伏期
等待着用户投资蜂拥而至，合约资金池壮大。4.3010:12+UTC8TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr对自己部署的TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz合约同样发送携带了0.011011TRX的withdraw()命令,对应的交易哈希为4b8dd07afa029126f16c192e8eb8a158f883e80a6be1eceaa432247bb06ef6ab，同上一个操作，这一笔交易被REVERT；4.3010:12+UTC8在稍后的几个区块中，TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr对自己部署的TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz合约同样发送携带了0.011911TRX的withdraw()命令,对应的交易哈希为87bf173c126c4873ad333c02d4e352bacda9bfaae4d91d0bce156eb64bd5219f，而这一次却成功了：这一次，不仅成功了，而且还从TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz合约中转了100.011911TRX到此次交易的发起方TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr。到此为止，好像并没有太多的故事发生，不过好戏才刚刚开始...收割期
5.1假期总是那么地来去匆匆，在小编还在家带娃的时间里，TronBankPro合约已经吸引了近1600+用户近30,000,000TRX的投资：折合当前的市价为700,000美元。眼看就到了丰收期，可是05.0304:12+UTC8有一个称号为wojak的黑客THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH通过与TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr在上面一致的操作半路截胡了，并成功『取回』2600W+TRX。至于wojak黑客到底是谁，目前无人知晓。具体的交易哈希如下：基于此，PeckShield安全人员认为TSCTTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr部署的TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz合约与TronBankPro部署的TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ合约均存在后门，至于后门是如何被安插的，被谁安插的，还不得而知。PeckShield安全人员对TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz和TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ合约逆向代码之后，发现其中的withdraw()逻辑中存在下面一段代码：不难看出，withdraw()根据msg.value即携带的TRX大小分为三种情况：0x2B03==msg.value16进制的0x2B03转换成十进制之后为11011Sun(由于TRX==10^6Sun)，等价于0.011011TRX。这个值刚好就是上面TSCTTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr测试时携带的TRX值。这个分支下，并不改变状态，交易输出OK，并最后以REVERT退出，这一行为与上面交易的返回信息一致，PeckShield安全人员认为这个分支代码是开发者故意留下的调试功能，以确认合约的逻辑是否符合预期。0x2E87==msg.value：16进制的0x2E87转换成十进制之后为11911Sun(由于TRX==10^6Sun)，等价于0.011911TRX。这一值与TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr以及THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH调用的值是相等的。这一分支下，将本合约中所有的TRXbalance全部转移到调用发起者，一点不剩。其它情况，正常的withdraw()取回操作。在此，PeckShield安全人员认为，上述的0.011011TRX以REVERT退回的『误操作』实则是黑客进行攻击之前的测试环节。套现期
黑客THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH获取2600W+TRX之后，开始分批次分步骤转移资产：其中，截止北京时间2019-5-519:00共有1,4000,000TRX转移至Binance交易所。天亮了
以上纯技术的分析说明，充分验证了两点：第三方验证服务平台TSC并不专业，其服务过的大部分合约均存在合约源码与Tron链上bytecode不一致的情况，证明TronBankPro项目方找TSC进行一致性校验服务存在很大疏漏。第三方验证服务平台TSC很难避嫌，其早在TronBankPro项目上线前发现了合约漏洞，然而其并没有督促项目方及时调整问题，而是反其道而行之实施了攻击测试，而今项目合约遭到了攻击，TSC又怎能置身事外呢？当然，即使PeckShield已经通过技术追踪，将事情的来龙去脉还原至此，在区块链的虚拟世界里，这场"狼人杀"大戏究竟谁是狼人，仍然难有定论。项目方在不对损害资金进行如数赔付之前，于情于理都难逃其责；第三方服务平台TSC目前来看是最大的"鬼"，但其和项目方的关系真说得清吗？至于那个任性又有些小情绪的黑客wojak究竟是真有其人，还是只是漩涡中一方的小马甲，谁能道得明，说得清？校验得了的是代码，猜不透的是人性！PeckShield是面向全球顶尖的区块链数据与安全服务提供商。商业与媒体合作，请通过Telegram、Twitter或邮件与我们联系。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。