Vào ngày 4 tháng 5, trò chơi TRX pro của Tron Bank trên Tron đã bị tấn công và 26,73 triệu TRX đã bị đánh cắp, trị giá khoảng 4,27 triệu RMB. Nhân dân tệ. Theo dữ liệu của PeckShield, hơn 13 triệu TRX đã chảy vào sàn giao dịch Binance. Đây là lần thứ hai trong tháng Tron Bank bị tấn công. Vào ngày 11 tháng 4, trò chơi BTT trên Tron Bank đã bị tấn công và hàng chục triệu BTT đã bị đánh cắp.
Trước khi hợp đồng TRX pro được ra mắt, nó đã được công cụ đánh giá hợp đồng của bên thứ ba tronsmartcontract.space (TSC) xem xét và không tìm thấy vấn đề gì vào thời điểm đó. Một số người cho rằng bên dự án Tron Bank đã để lại cửa sau trong hợp đồng, một số cho rằng việc xem xét TSC đã thất bại. Để biết chi tiết về quá trình sự việc, vui lòng xem bài viết DApp Review bên dưới.
Về cuộc tấn công này, PeckShield đã vượt qua Sau khi nghiên cứu kỹ lưỡng, tôi thấy rằng
span>
1. Nền tảng dịch vụ bên thứ ba TSC đã biết về sự tồn tại của "cửa sau" vào ngày 28 tháng 4, tức là trước khi hợp đồng TRX Pro trực tuyến và triển khai nó vào lúc 17:35 chiều ngày 28. Hợp đồng thử nghiệm tương tự như TronBank Pro và một nỗ lực tấn công đã được thực hiện đối với hợp đồng TronBank Pro vào lúc 23:00 đêm hôm đó.
Dựa vào đó, có thể rút ra hai kết luận: p>
1) Nhóm dự án TronBank Pro đã nhận thức được những sơ hở trong dự án trước khi hợp đồng được đưa ra nhưng vẫn đưa ra hợp đồng;
2) Nền tảng dịch vụ bên thứ ba TSC đã phát hiện ra sự cố nhưng không thông báo cho nhóm dự án và có khả năng chờ đợi một cuộc "tấn công".
2. Bên thứ ba Nền tảng dịch vụ TSC một lần nữa tấn công hợp đồng thử nghiệm vào lúc 10h12 ngày 30/4 sau khi hợp đồng dự án lên mạng và thành công.
Dựa vào đó, việc phân tích và suy luận có thể được thực hiện:
1) TSC chưa tấn công ngay vào hợp đồng dự án và có thể đang chờ nguồn vốn tăng trưởng;
2) Trước khi TSC bắt đầu tấn công, nó đã vô tình bị các hacker khác chặn lại và thực hiện cuộc tấn công trước;
3) Không tìm thấy mối tương quan nào giữa TSC và hacker wojak đã thực hiện cuộc tấn công.
Người sáng lập Tron Justin Sun cũng phản hồi về vụ hack. Ông nói rằng quan chức này đã xem xét nền tảng đánh giá hợp đồng của bên thứ ba Người ta tin rằng tronsmartcontract.space không sử dụng phương pháp xem xét hợp đồng chính xác và không thể đạt được hiệu quả xác minh mã nguồn mở. Bạn không nên sử dụng kết quả xác minh của TSC.

Sau đây làĐánh giá DApp Review quá trình phát triển cuộc tấn công vào TRX pro.
Lúc 4:12 sáng ngày 3 tháng 5, giờ Bắc Kinh, một hợp đồng kỳ diệu có tên The 26.73 triệu TRX (trị giá 4,27 triệu RMB) trong hợp đồng TronBank đã được chuyển đi và số dư hợp đồng trở về 0.

Chỉ hơn 20 ngày trước, trò chơi thứ hai của nhóm Tronbank, BTTBank, đã bị hack bằng tiền giả trong vòng 3 giờ kể từ khi phát hành Sau khi tấn công và cướp hàng chục triệu BTT (không phải 180 triệu BTT), chưa đầy một tháng sau, trò chơi thứ ba TRX Pro đã chính thức ra mắt vào lúc 20h ngày 29/4. Chỉ trong vài ngày, số dư hợp đồng đã vượt quá 25 triệu TRX.
Đây có phải là Dapp trên hệ sinh thái TRON đã bị tin tặc nhắm tới một lần nữa không? và Cướp bóc thành công?
Và điều gì đã xảy ra tiếp theo
Thật bất ngờ
Một lỗi vô tình được kích hoạt ?
Sau khi số dư hợp đồng trở về 0, dự án telegram Có vô số nghi ngờ về các trò gian lận và tin tặc trong nhóm, DappReview và những người bạn của nó bắt đầu nghiên cứu những gì đã xảy ra. Địa chỉ của "hacker" là THERTTCvN4SHEVYNqcLVLNGGVsWLR4smyH. Sử dụng công cụ xem dữ liệu người chơi của DappReview, bạn có thể thấy chủ sở hữu của địa chỉ này trông giống như một người chơi Dapp bình thường. Từ tháng 1 đến tháng 5 năm nay, người chơi này đã tham gia hàng chục Dapp. Với họ, TronGoo là game anh ấy chơi nhiều nhất, từ bảng xếp hạng chính thức của TronGoo, chúng ta có thể thấy anh ấy là người chơi lớn thứ hai.

Nguồn dữ liệu https://player.dapp.review/
Khoảng 2 giờ sau vụ trộm, trên kênh Discord có tên Scam Watch, Wojak này, chủ sở hữu địa chỉ THeRTT** với 26,73 triệu TRX, đã xuất hiện. p>

Theo wojak, anh ấy đã viết một đoạn script để phân tích các ký tự máy ảo TRON. , quét các hợp đồng theo đợt và bắt đầu giao dịch để xem có cách nào để kiếm tiền không, kết quảvô tình chạm vào Đã sửa lỗi lỗi trong hợp đồng Tronbank. Thậm chí ngay từ đầu, anh ấy cũng không phải là chính mìnhBiết tiền đến từ đâuTronbank đã gọi.
Một số người trong cộng đồng đề nghị wojak trả lại tiền cho các nhà phát triển Tronbank, nhưng wojak tin rằng đây không phải là vấn đề của anh ấy. Các nhà phát triển nên viết ví dụ thử nghiệm của riêng họ, thực hiện kiểm tra và ít nhất thực hiện một số xác minh chính thức (rõ ràng là họ không làm gì cả) , Anh ấy sẵn sàng trả lại số tiền nguyên vẹn cho mọi nhà đầu tư ở Tronbank chứ không phải cho các nhà phát triển dự án.
wojak đã yêu cầu các nhà đầu tư tham gia Tronbank gửi cho anh ấy giá trị băm giao dịch của khoản đầu tư và Địa chỉ riêng của mình, anh ta sẽ viết kịch bản xác minh và hứa sẽ hoàn trả cho những nhà đầu tư Tronbank bị thua lỗ.
Cố tình chôn cửa sau?
Khi cuộc điều tra đi sâu hơn, giao dịch gây ra lỗi đã được đặt lại lên bàn và phân tích cẩn thận. Chúng ta hãy xem lại:
Lưu ý rằng giao dịch này gọi hàm rút tiền trong hợp đồng,Số tiền được gửi là 0,011911 TRX. Cần lưu ý rằng theo logic kinh doanh thông thường của Tronbank, việc gọi chức năng rút tiền sẽ không gửi bất kỳ TRX nào và số tiền phải là 0 . Điều này có thể được xác minh trong mã nguồn.
Các Dapp như Tronbank, có tính chất dựa trên quỹ, thường mở mã nguồn của chúng để làm cho hợp đồng và logic trở nên minh bạch và đáng tin cậy để thu hút nhà đầu tư. , ở vị trí dễ thấy nhất của trang web cũng được đánh dấuThông qua công cụ xác minh của bên thứ ba tronsmartcontract .space (sau đây gọi tắt là TSC) Thông tin mã sau khi xác minh mã hợp đồng.

Sau khi nhấp vào mã nguồn mở từ TSC, tìm hàm rút. Dòng đầu tiên của hàm sẽ gọi _withdraw() để lấy số lượng TRX có thể rút. Chúng ta có thể thấy ở phần đầu tiên dòng của hàm _withdraw() :
require(msg.value == 0, "sai số lượng trx");
Dòng mã này có nghĩa là lượng TRX được gửi trong giao dịch này phải bằng 0, nếu không quá trình thực thi không thể tiếp tục và giao dịch sẽ bị HOÀN LẠI.
Nói cách khác, theo logic của mã nguồn mở, giao dịch gây ra lỗi không thể có đã xảy ra chút nào.
Thực tế là logic thực thi thực tế của hợp đồng TRX Pro không nhất quán với cái gọi là logic mã “nguồn mở”.
Giải thích thêm ở đây là cái gọi là quy trình chứng nhận mã giống như thế này:
1. Nhà phát triển xuất bản hợp đồng trên mạng chính
2. Nhà phát triển tải mã lên TSC và chọn biên dịch phiên bản, biên dịch thành mã byte,
3. TSC khớp mã byte ở bước 2 với mã byte của hợp đồng được phát hành ở bước 1, nếu khớp thành công thì quá trình xác thực sẽ được thông qua. Về lý thuyết, việc có nhiều hay ít một khoảng trắng không quan trọng.
Tìm sâu hơn, tôi tìm thấy nó từ tronscan. Mã byte của hợp đồng TRX Pro được xử lý bằng công cụ dịch ngược:

Công cụ dịch ngược:https://www.trustlook.com/products /người bảo vệ hợp đồng thông minh
Trong chức năng rút tiền, có một thêm Xác định khác nếu ((0x2E87 == msg.value)), nếu đáp ứng các điều kiện thì toàn bộ số dư của hợp đồng sẽ được chuyển cho người khởi tạo giao dịch! Chúng ta chuyển số thập lục phân 0x2E87 thành số thập phân là 11911. Chúng ta phải biết rằng độ chính xác của TRX là 6 chữ số và số TRX tương ứng với 11911 là 0,011911 TRX... Và phần nhận định này không tồn tại trong mã nguồn mở của TSC, có vẻ như bị ẩn và chưa được công bố cửa sau.
Hãy suy nghĩ bằng ngôn ngữ đơn giản hơn:
1. Đối với hợp đồng được triển khai trên mạng chính, thông qua dịch ngược, người ta nhận thấy rằng khi chức năng rút tiền được gọi, nếu số tiền được gửi bằng 0,011911 TRX, toàn bộ số dư hợp đồng sẽ được chuyển giao;
2. Trong mã nguồn mở được chứng nhận trên TSC, nếu chức năng rút tiền được gọi khi số tiền gửi khác 0 thì giao dịch sẽ bị rút.
Vậy thì mọi thứ rất rõ ràng. Những gì thực sự xảy ra hoàn toàn phù hợp với điểm đầu tiên. Mã mainnet chạy mà không gặp vấn đề gì. Điều đó là, có một mã backdoor trong hợp đồng được TronBank triển khai trên mạng chính có thể rút trực tiếp số dư hợp đồng. Điều thú vị là điểm thứ hai. Làm thế nào mà logic mã rõ ràng khác biệt lại vượt qua quy trình chứng nhận TSC sau khi được tải lên?
Dựa trên thông tin hiện có, Vẫn còn quá sớm để kết luận rằng "nhà phát triển đã đặt một cửa hậu trong hợp đồng". Hiện tại, chúng ta chỉ có thể rút ra hai kết luận khách quan: span>
1. TRX Pro có cửa sau trong hợp đồng mainnet khoảng>
2. Mã được chứng nhận trên TSC không khớp với logic vận hành hợp đồng thực tế
Lưu ý: Nội dung sau đây có thể là một cuộc thảo luận dựa trên các sự kiện hiện có và không đại diện cho kết luận cuối cùng và sự thật. Vui lòng không đưa nó ra khỏi bối cảnh khi phổ biến nó.
Ai đã đặt cửa sau và bằng cách nào? Hiện không có bằng chứng xác thực, có người cho rằng đó là nhà phát triển của Tronbank, có người cho rằng nhà phát triển đó không đủ mạnh để lừa TSC xác minh mã khác với triển khai thực tế.
Phân tích khách quan các khả năng có thể xảy ra (lưu ý ở đây chỉ thảo luận về khả năng đó, ngay cả khi khả năng đó là cực kỳ thấp, hiện tại không có bằng chứng chắc chắn nào cho sự thật), Có các loại sau:
Khả năng 1: Các nhà phát triển Tronbank đưa vị trí hàng hóa tư nhân vào hợp đồng triển khai thực tế đã tìm thấy backdoor và đã lừa thành công TSC hoàn thành một lần xác minh mã khác mà không cần backdoor.
Khi khám phá khả năng này, cách đánh lừa TSC đã trở thành trọng tâm,Nếu có lỗi trong quá trình xác minh của TSC, thì điều này có nghĩa là tất cả những người đã vượt qua chứng nhận TSC và được quảng cáo Trước khi các Dapp mã nguồn mở không còn đáng tin cậy và minh bạch. Trên thực tế, trong nhóm Discord, nhà phát triển TSC Khánh thừa nhận rằng mã này đã không được duy trì trong một thời gian dài và có thể có lỗi. Các nhà phát triển khác cũng xác nhận rằng họ thực sự đã triển khai mã này. có thể không hoàn toàn giống với mã được chứng nhận.
Mặt khác, serif; color: rgb(84, 141, 212);">Các nhà phát triển Tronbank đã nhiều lần tuyên bố trong nhóm Telegram rằng nhóm không đặt bất kỳ cửa hậu nào trong hợp đồng. Có một cách để chứng minh sự vô tội của mình: chính thức Được cung cấp mã nguồn và phương pháp biên dịch (bao gồm các công cụ và phiên bản biên dịch) trong quá trình triển khai, về lý thuyết, mã byte được biên dịch bởi bất kỳ ai theo cùng một cách phải nhất quán với hợp đồng TRX Pro được triển khai trực tuyến. Nhưng khi chúng tôi nêu ra câu hỏi này thì câu trả lời chính thức như sau:
Nếu nội dung trả lời này là đúng thì sự việc sẽ kịch tính và phức tạp hơn, hãy tham khảoKhả năng ba
Khả năng 2: Nhóm Tronbank và nhóm TSC thông đồng để triển khai hợp đồng có cửa sau và TSC đã hỗ trợ hoàn tất xác minh bằng hợp đồng khác mà không cần một cửa sau. .
Đây là một khả năng được đề xuất với tiền đề là khó thiết lập "gian lận TSC". TSC cuối cùng đã được đánh dấu Nhãn xác minh thực chất là một hành vi tập trung và có thể được vận hành hoàn toàn thủ công. Tuy nhiên, đối với TSC với tư cách là công cụ xác minh hợp đồng của bên thứ ba, hiện tại chưa có sản phẩm cạnh tranh nào, làm như vậy chắc chắn sẽ gây tổn hại nghiêm trọng đến thương hiệu của chính bạn. tiết kiệm chi phí, quá thấp.
Khả năng ba: Nhóm Tronbank không đặt cửa hậu trong hợp đồng, nhưng cửa hậu đã được sử dụng trong quá trình quá trình triển khai hợp đồng được sản xuất theo một cách nào đó.
Khả năng này dựa trên gợi ý từ câu trả lời chính thức trong "Possible One" mà dự án Fang đã thực hiện sử dụng hợp đồng không có cửa sau khi triển khai hợp đồng Công cụ biên dịch đã có một thủ thuật trong quá trình triển khai hợp đồng lên mạng chính và thêm một cửa hậu có vấn đề. Tuy nhiên, nhóm dự án hiện không cung cấp bất kỳ thông tin có thể xác minh nào, các công cụ biên dịch được sử dụng hoặc thông tin về các kết quả khác nhau của việc biên dịch cùng một mã hai lần.
Trong mọi trường hợp, chúng tôi không biết mã thực tế được các nhà phát triển TronBank triển khai và chúng tôi không thể xác minh tính xác thực của nó. Sự thật của vụ việc này cần phải chờ thêm thông tin từ tất cả các bên, chỉ có bằng chứng thuyết phục mới có thể dần dần được khôi phục.
Ít nhất tại thời điểm này, chúng tôi không thể đưa ra kết luận xem ai đã tạo ra cửa hậu này.
Điều gì xảy ra với tiền của nhà đầu tư?
Trước thông tin phức tạp trên, hầu hết người chơi đã từ bỏ việc truy tìm sự thật và quan tâm hơn đến Nó là để thu hồi tổn thất.
Sau khi hứa hoàn lại tiền và yêu cầu các nhà đầu tư bị thua lỗ gửi thông tin giao dịch, wojak đã mất liên lạc trong hơn 12 giờ. Trong thời gian này Sau đó, phần lớn số tiền trong tài khoản của wojak đã được chuyển sang sàn giao dịch Binance. Một số người bắt đầu nghi ngờ rằng wojak không có ý định trả lại tiền và đang chuẩn bị quyên góp tiền rồi bỏ trốn, những người khác cho rằng đây là hành vi trộm cắp của bên dự án TronBank và wojak là một trong những bên tham gia dự án.
2:44 chiều ngày 3 tháng 5
Bên kia, trong nhóm chính thức của Tronbank, thông báo hàng đầu được quản trị viên đăng tải là "TRX Pro đã bị hacker THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH tấn công. Nhóm phát triển hiện đang xử lý khẩn cấp và sẽ cập nhật thông báo trong nhóm trong thời gian."

Ngày 3 tháng 5, 9:13 chiều

wojak lại xuất hiện và cho biết anh đã mất hơn 4 tiếng đồng hồ để viết kịch bản lấy dữ liệu đầu tư của tronbank từ chuỗi để so sánh với thông tin tổn thất thu thập được. Nhiều người đã nhầm lẫn báo lỗ, ngay cả người dùng chưa từng tham gia đầu tư cũng báo lỗ sai, chỉ có một số ít người báo cáo con số một cách trung thực. wojak cũng đăng thông tin so sánh https://pastebin.com/raw/gMtxCw97.
Ngày 4 tháng 5, 1:24 chiều mạnh mẽ>
Chính xác một ngày sau, nhóm dự án Tronbank đã đưa ra một Thông báo khác rằng họ đang liên hệ với wojak để yêu cầu hoàn lại tiền. Nếu wojak không phản hồi trước 7 giờ tối ngày 4 tháng 5, quan chức này sẽ cung cấp kế hoạch bồi thường cho các nhà đầu tư.
Ngày 4 tháng 5, 3 giờ chiều - 4 giờ chiều
Liên quan đến báo cáo phân tích sự cố đã hứa trước đó trong vòng 24 giờ, quan chức này sẽ hoãn lại một lần nữa và tuyên bố rằng họ sẽ liên hệ với công ty bảo mật, các quan chức TSC và TRON để tiến hành điều tra thêm. Đồng thời, còn có bình luận cho rằng còn có rất nhiều chi tiết vẫn cần phải xác nhận, tình huống tương tự chưa từng gặp phải trước đây, đây có thể là một câu chuyện tuyệt vời.
Ngày 4 tháng 5, 7 giờ tối
The Bên dự án Tronbank công bố kế hoạch trả thưởng như đã hứa khiến hầu hết mọi người đều ngạc nhiênBên dự án không bỏ chạy mà hứa sẽ thu thập thông tin trong vòng 24 giờ và bồi thường đầy đủ trong vòng 72 giờ. Nếu khoản bồi thường được đưa ra như thường lệ thì đây có thể là khoản bồi thường lớn nhất cho bên dự án trong lịch sử của Dapp.

Và thông báo đền bù này có thể nói là bữa cơm cho các nhà đầu tư Sự yên tâm này khiến hầu hết người dùng bỏ cuộc"Cửa sau do nhà phát triển để lại" mạnh> nghi ngờ. Nhưng trước khi sự thật được đưa ra ánh sáng, DappReview vẫn giữ thái độ hoài nghi và chờ dự án tung ra thêm báo cáo điều tra.
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
