PeckShield 和孫宇晨均對 TRX pro 黑客攻擊評論：第三方合約審覈平臺不安全

5 月 4 日，波場上的 Tron Bank 的 TRX pro 遊戲遭到攻擊，有 2673 萬個 TRX 被盜，價值約合人民幣 427 萬元。據 PeckShield 數據顯示，已經有 1,300 多萬個 TRX 流入幣安交易所。這是在一個月內，Tron Bank 第二次遭到攻擊。4 月 11 日，Tron Bank 上的 BTT 遊戲被攻擊，上千萬個 BTT 被盜。

在 TRX pro 合約上線前，曾經過第三方合約審查工具 tronsmartcontract.space（TSC）審查過，當時並沒有發現問題。有些觀點認爲是 Tron Bank 項目方在合約裏留下後門，有些認爲是 TSC 審查不合格，事件過程可以詳見下方 DApp Review 的文章。

關於這次攻擊，PeckShield 經過仔細研究，發現

1、第三方服務平臺 TSC 在 04 月 28 日即 TRX Pro 合約上線前就已經知道「後門」的存在，先於 28 日下午 17:35 部署了和 TronBank Pro 同樣的測試合約，並於當天晚上 23:00 向 TronBank Pro 合約發出攻擊嘗試。

基於此可得出兩個可能性結論：

1）TronBank Pro 項目方在合約上線前就已經知悉項目存在漏洞，但依然上線了合約；

2）第三方服務平臺 TSC 發現了問題並沒有告知項目方，並存在伺機「攻擊」的可能性。

2、第三方服務平臺 TSC 在項目合約上線後即 04 月 30 日上午 10:12 再次向測試合約實施攻擊攻擊並取得成功。

基於此可展開分析推論：

1）TSC 並沒有即刻對項目合約實施攻擊，可能在等待資金池壯大伺機而動；

2）TSC 在開始下手前，意外被其他黑客截胡，搶先一步實施了攻擊；

3）暫且未發現 TSC 和實施攻擊黑客 wojak 之間存在關聯。

而波場創始人孫宇晨也迴應了此次黑客事件，他表示官方審查了第三方合約審查平臺，認爲 tronsmartcontract.space 並沒有使用正確的合約審查方法，不能達到驗證代碼開源的效果，不建議大家採用 TSC 的驗證結果。

以下是DApp 評論回顧了 TRX pro 被攻擊的事件發展。

北京時間 5 月 3 日凌晨 4 點 12 分，一筆神奇的合約調用轉走了 TronBank 合約中的 2673 萬 TRX（價值 427 萬 RMB），合約餘額歸零。

僅僅在 20 多天前，Tronbank 團隊的第二個遊戲 BTTBank 在發佈 3 小時內即被黑客用假幣攻擊並盜走數千萬 BTT（並非 1.8 億 BTT），事隔不到一個月，第三款遊戲 TRX Pro 於 4 月 29 日 20 點正式上線，幾天時間之內，合約餘額已經突破 2500 萬 TRX。

這是否是 TRON 生態上的 Dapp 又一次被黑客盯上併成功洗劫一空？

,,,

而接下來發生的這一切

更讓所有人始料未及

偶然觸發的Bug？

合約餘額歸零後，項目方 telegram 羣裏面騙局和黑客的質疑聲不絕於耳，DappReview 和小夥伴們開始着手研究到底發生了什麼。"黑客"的地址爲 THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH，利用 DappReview 的玩家數據查看工具，可以看到該地址的所有者像是一個正常的 Dapp 玩家，從今年 1 月到 5 月該玩家涉獵過數十個 Dapp，其中 TronGoo 是他玩過最多的遊戲，從 TronGoo 官方排行榜可以看到他就是排名第二的大戶玩家。

數據來源,

發生被盜事件約 2 個小時之後，在一個名爲 Scam Watch（騙局觀察）的 Discord 頻道中，調走這一筆 2673 萬 TRX 的地址 THeRTT**擁有者 wojak 現身了。

根據 wojak 的說法，他寫了個腳本在分析波場虛擬機字節碼，批量掃描合約併發起交易看看有沒有什麼能賺到錢的方法，結果偶然之中命中了 Tronbank 合約的bug。一開始連他自己都不知道這筆錢是從Tronbank 打過來的。

社區裏部分人建議 wojak 把錢還給 Tronbank 開發者，而 wojak 認爲這不是他的問題，開發者應該自己寫測試例子，做審計以及至少跑一些形式化驗證（很顯然他們啥都沒幹）,他願意把這 筆錢原封不動還給 Tronbank 的每一個投資者，而不是項目方的開發者。

wojak 要求參與了 Tronbank 的投資者發給他投資的交易 hash 值以及自己的地址，他將寫一個腳本進行驗證，並承諾退款給有損  失的 Tronbank 投資人。

刻意埋藏的後門？

隨着調查的深入，那一筆觸發 Bug 的交易被放回桌面上被仔細的剖析。我們再來看一下：

,,,

注意到，該筆交易調用的是合約裏 withdraw 函數，發送的金額爲 0.011911 TRX，要注意在 Tronbank 正常的業務邏輯下，調用 withdraw 函數是不應該發送任何 TRX 的，金額應該爲 0. 這一點在源代碼中就可以驗證。

像 Tronbank 這樣資金盤屬性的 Dapp，往往都會把代碼開源讓合約和邏輯變得透明可信來吸引投資人，在網站最明顯的位置，也標明瞭通過第三方驗證工具 tronsmartcontract.space（以下簡稱 TSC）進行合約代碼驗證後的代碼信息。

從 TSC 點開源代碼之後，找到 withdraw 函數，函數第一行會先調用_withdraw() 來取得可以提取的 TRX 金額，在_withdraw() 函數的第一行我們可以看到：

要求(味精。value == 0，“錯誤的trx金額”);

這一行代碼的意思是要求該筆交易發送的 TRX 金額必須爲零，否則無法繼續執行，交易會被 REVERT。

也就是說，按照開源代碼的邏輯，那一筆觸發 Bug 的交易根本不可能發生。

現實變成了，TRX Pro 的合約實際執行邏輯和所謂「開源」的代碼邏輯並不一致。

這裏補充說明一下，所謂的代碼認證過程是這樣：

1. 開發者在主網發佈合約

2. 開發者在 TSC 上傳代碼，選擇編譯版本，編譯爲 bytecodes，

3. TSC 把步驟 2 中的 bytecodes 和步驟 1 中發佈合約的 bytecodes 做匹配，匹配成功，則認證通過，理論上多或者少一個空格都不行

進一步深扒，從 tronscan 上找到 TRX Pro 合約的 bytecodes，用反編譯工具進行處理得到：

\nbsp;nbsp;

反編譯工具：https://www.trustlook.com/products/smartcontractguardian

在 withdraw 函數中，多了一個判斷 else if ((0x2E87 == msg.value))，如果滿足條件，那麼就會把合約的餘額全部轉給交易發起者！我們把 16 進制的數字 0x2E87 轉換成 10 進制，也就是 11911，要知道 TRX 的精度爲 6 位，11911 所對應的 TRX 金額就是 0.011911 TRX...而這一部分判斷在 TSC 的開源代碼中是不存在的，看起來就像是是一個被藏起來沒有公佈的後門。

用更簡單的語言梳理一遍：

1. 在主網上部署的合約，通過反編譯發現，調用 withdraw 函數時，如果發送金額等於 0.011911 TRX，則會轉移全部合約餘額；

2. 在 TSC 上認證過的開源代碼中，如果發送金額不爲零調用 withdraw 函數，交易會被撤回。

那麼一切就很清晰了，實際發生的與第一點完全吻合，主網的代碼運行沒有問題，即 TronBank 在主網部署的合約中存在一個可以直接提走合約餘額的後門代碼，而有意思的在於第二點，明明不一樣的代碼邏輯是如何上傳後通過了 TSC 的認證過程？

根據已有的信息，斷定「是開發者在合約之中放置後門」這個結論仍然爲時過早，目前我們可以得出的客觀結論只有兩點：

1. TRX Pro在主網的合約中存在後門

2. TSC上認證過的代碼與實際合約運行邏輯不符

注：以下內容是基於現有事實依據的可能性探討，不代表最終結論和真相，請在傳播時不要斷章取義。

至於後門是誰放置的，如何放置的？目前沒有任何實錘證據，有的人認爲是 Tronbank 開發者，有的人認爲開發者的實力還不足以通過欺騙 TSC 驗證與實際部署所不同的代碼。

客觀來分析存在的可能性（注意，此處僅討論可能性，即便該可能性極低，真相目前沒有任何實錘證據），有以下幾種：

可能性一：Tronbank 開發者在實際部署的合約中夾雜私貨放置了後門，併成功欺騙了 TSC 完成了另一份沒有後門的代碼驗證。

在探討這種可能性時，如何欺騙 TSC 成爲了焦點，如果真的 TSC 的驗證存在 Bug，那麼這意味着之前所有通過 TSC 認證並標榜開源的 Dapp 都不再可信和透明，事實上，在 Discord 羣裏，TSC 的開發者 Khanh 承認代碼已經很久沒有維護並存在 bug 的可能性，也有其他開發者證實自己實際部署的代碼和通過認證的代碼可以不完全相同。

另一方面，Tronbank 開發者在 Telegram 羣中多次聲稱團隊沒有在合約中放置任何的後門，有一種自證清白的方式是：官方給出部署時的源代碼以及編譯方式（包括編譯工具以及版本），理論上任何人按照同樣方式編譯出來的 bytecode 和線上部署的 TRX Pro 合約應該一致。但當我們提出該質疑時，官方回覆如下：

,,,,

這個回覆的內容如果當真，則該事件將更加戲劇化和複雜化，參考可能性三

可能性二：Tronbank 團隊和 TSC 團隊合謀，部署了有後門的合約，同時 TSC 協助用另一個沒有後門的合約完成驗證。

這是在「欺騙 TSC」很難成立的前提下提出的可能性，TSC 最終打上驗證的標籤其實是中心化的行爲，完全可以人爲操作，但對於 TSC 作爲一個第三方合約驗證工具來說，目前尚無競品，做這樣的事情無疑嚴重損傷自己的品牌，串通合謀是在性價比太低。

可能性三：Tronbank 團隊沒有在合約中放置後門，而是後門在合約部署過程中以某種方式產生。

這種可能性是基於「可能一」中的官方回覆的一種暗示，即項目方在合約部署時確實使用的是沒有後門的合約，編譯工具在部署合約到主網的過程中出現了貓膩，加入了有問題的後門。但項目方目前沒有提供任何的可驗證信息，使用的編譯工具，以及同樣代碼兩次編譯不同結果的信息。

不論如何，TronBank 開發者實際部署的代碼原樣我們不得而知，也無法驗證真僞，該事件的真相需要等待各方提供更有說服力的證據才能被逐漸還原出來。

至少在此刻，我們還不能下定論，究竟是誰埋下了這個後門。

投資者的錢怎麼辦？

在以上錯綜複雜的信息之下，大部分玩家已經放棄了追查真相，而更關注的則是找回損失。

在承諾退款並要求蒙受損失的投資人發送交易信息之後，wojak 整整失聯了超過 12 小時，這期間 wojak 賬戶裏的錢大部分被轉移到了幣安交易所。有人開始懷疑 wojak 並沒有打算退錢準備捐款跑路，還有人認爲這是 TronBank 項目方監守自盜，wojak 就是項目方之一。

5 月 3 日下午 2 點 44 分

另一邊，在 Tronbank 的官方羣裏，管理員貼出的置頂消息是「TRX Pro 被黑客 THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH 攻擊，目前開發團隊正在緊急處理，將會及時在羣裏更新消息」

5 月 3 日晚上 9 點 13 分

wojak 再次現身，說自己花 4 個多小時寫了腳本從鏈上獲取到 tronbank 的投資數據來跟收集到的損失信息對比，其中有不少人虛報損失，甚至有完全沒有參與過投資的用戶也來謊報損失，僅有少數人誠實地彙報了數字。wojak 也把比對信息貼了出來 https://pastebin.com/raw/gMtxCw97。

5月4日下午1點24分

整整一天之後，Tronbank項目方再次發出通知，他們正在聯繫wojak進行退款，如果wojak在5月4日晚7點時沒有任何回覆，官方將提供給投資人的補償方案。

,,,

5 月 4 日下午 3 點 - 4 點

針對之前所承諾的 24 小時內給出事件分析報告，官方將再次延期，聲稱將聯繫安全公司，TSC 以及波場官方做更多的調查。同時評論到，有很多細節仍需確認，之前從未遇到類似情況，這有可能是一個精彩的故事。

,,,,,

5 月 4 日晚上 7 點 

Tronbank 項目方如約公佈了賠償方案，令大部分人吃驚的是項目方沒有跑路，而是承諾在 24 小時內收集信息，並在 72 小時內進行全額賠付。如果賠付照常發放，這可能是 Dapp 歷史上最大的一次項目方賠付。

而此次賠付通知，可以說是給投資者吃了一顆定心丸，使得大部分用戶打消了「後門是由開發者留下」的疑慮。但在真相露出水面之前，DappReview 依舊保留質疑的態度，等待項目方公開更多的調查報告。

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia