PeckShield and sun yuchen both commented on the TRX pro hack: the third-party contract review platform is not secure

On May 4, 26.73 million TRX worth about 4.27 million yuan were stolen from the Tron Bank's TRX pro game. More than 13 million TRX have entered the exchange, according to PeckShield. It was the second attack on Tron Bank in a month. On April 11, BTT games on Tron Bank were attacked and tens of millions of BTT were stolen.

Prior to the launch of the TRX pro contract, tronsmartcontract.space (TSC), a third-party contract review tool, reviewed the contract and found no problems. Some people think that the project side of Tron Bank left a back door in the contract, while others think that TSC failed the Review. The event process can be detailed in the article of DApp Review below.

As for the attack, PeckShield took a closer look and found out

1. TSC, the third-party service platform, knew the existence of the "back door" before the TRX Pro contract was launched on April 28, and deployed the same test contract with TronBank Pro at 17:35 p.m. on April 28, and sent an attack attempt to the TronBank Pro contract at 23:00 p.m. on the same day.

Based on this, two possible conclusions can be drawn:

1) the project side of TronBank Pro has known about the loopholes in the project before the contract was launched, but it still launched the contract;

2) TSC, the third-party service platform, found the problem and did not inform the project party, and there was a possibility of opportunistic "attack".

2. TSC, the third-party service platform, launched another attack on the test contract at 10:12 am on April 30 after the project contract came online and succeeded.

Based on this, the following analysis can be carried out:

1) TSC did not immediately attack the project contract and may be waiting for the capital pool to grow;

2) TSC was accidentally cut off by other hackers before it started to attack, so it carried out the attack first;

3) no connection has been found between TSC and wojak.

Sun yuchen, founder of wave field, also responded to the hacking incident, saying that officials have reviewed the third-party contract review platform and believe that tronsmartcontract.space does not use the correct contract review method to achieve the effect of open source code verification, so it is not recommended to use TSC's verification results.

The following is aDApp ReviewReviewed the development of the attack on TRX pro.

At 4:12 am on May 3, Beijing time, a magical contract call transferred 26.73 million TRX (worth 4.27 million RMB) from the contract of TronBank, and the contract balance was reduced to zero.

Just over 20 days ago, the second game of the Tronbank team, BTTBank, was attacked by hackers with fake currency and stole tens of millions of BTT (not 180 million BTT) within 3 hours of its release. Less than a month later, the third game, TRX Pro, was officially launched at 20:00 on April 29. Within a few days, the contract balance has exceeded 25 million TRX.

Is this another time that Dapp on the TRON ecosystem has been targeted and looted by hackers?

And what happened next

Let everybody more unexpected

A Bug accidentally triggered?

Contract balance to zero, after your telegram of fraud and the hacker's doubts, DappReview and friends set out to research what has happened. & quot; Hackers & quot; Address for THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH, use DappReview player data view tool, you can see the address of the owner like a normal Dapp players, from January to may this year that player read dozens of Dapp, including TronGoo is he played most of the game, from TronGoo official list you can see he is ranked the second big players.

The data source 

About two hours after the theft, THeRTT** owner wojak, the 26.73 million TRX address, was pulled up in a Scam Watch channel.

According to wojak, he wrote a script analyzing the wave field virtual machine bytecode, scanning contracts in bulk and initiating trades to see if there was any way to make moneyResults,Hit the Tronbank contract by accidentbug。At first he wasn't even himselfKnow where the money comes fromTronbank called.

Some in the community suggested that wojak give the money back to the Tronbank developers, but wojak didn't think it was his problem and that developers should write their own test cases, do their own audits, and at least run some formal validation (they obviously didn't do anything).He was willing to return the money intact to each investor in Tronbank, not to the developer on the side of the project

Wojak asked investors involved in Tronbank to send him the hash value of the trades and his address. & have spent Lost Tronbank investors.

A deliberately buried back door?

As the investigation goes deeper, the deal that sent the Bug is put back on the table and dissected carefully. Let's look again:

Notice that the transaction calls the withdraw function in the contract,The amount sent is 0.011911 TRX. Please note that under the normal business logic of Tronbank, we should not send any TRX when we call withdraw function and the amount should be 0. This can be verified in the source code.

Dapps like Tronbank, with their proprietary nature, tend to attract investors by making open source code transparent and credible about contracts and logic, even in the most obvious places on the siteThe code information after contract code validation is performed through the third-party validation tool tronsmartcontract.space (hereinafter referred to as TSC)

After the source code is opened from TSC point, the withdraw function is found. The first line of the function will first call _withdraw() to obtain the extracted TRX amount. In the first line of the _withdraw() function, we can see:

require(msg.value == 0, "wrong trx amount"); 

This line of code means that the amount of TRX sent by the transaction must be zero or it cannot proceed and the transaction will REVERT.

In other words, according to the logic of open source code, that one buggy transaction is impossible.

The reality is that the actual execution logic of the TRX Pro contract is inconsistent with the so-called "open source" code logic.

As a side note, the so-called code authentication process looks like this:

1. Developers publish contracts on the main network

2. The developer uploads the code in TSC, selects the compiled version, and compiles it to bytecodes.

3. TSC matches the bytecodes in step 2 with the bytecodes that published the contract in step 1. If the match succeeds, the authentication will be passed

Further digging, we found the bytecodes of the TRX Pro contract on tronscan and processed them with the decompression tool:

Decompiling tools:https://www.trustlook.com/products/smartcontractguardian

In withdraw function, there is an extra judge else if ((0x2E87 == msg.value)). If the condition is met, the balance of the contract will be transferred to the transaction initiator. We converted the hexadecimal number 0x2E87 into hexadecimal number 0x2E87, which is 11911. We need to know that the precision of TRX is 6 bits, and the amount of TRX corresponding to 11911 is 0.011911 TRX...This part of the judgment does not exist in TSC's open source code, which looks like a hidden backdoor.

In simpler terms:

1. For the contract deployed on the main network, it is found through decompression that when withdraw function is called, if the amount sent is equal to 0.011911 TRX, the whole contract balance will be transferred;

2. In the open source code certified on TSC, the transaction will be withdrawn if the withdraw function is called if the amount sent is not zero.

Everything is very clear, actual and the perfect fit for the first point, the main code runs without problems, namely TronBank deployment in the main contract in a can directly pull contract balance the back door of the code, and interesting is that the second point, clearly logic is not the same code through the certification process of TSC after how to upload?

Based on the information available,It is still too early to conclude that "developers put backdoors into contracts", and there are only two objective conclusions to be drawn:

1. TRX Pro has a back door in the main network contract

2. The certified code on TSC is inconsistent with the actual contract operation logic

Note: the following content is a discussion of the possibility based on the existing facts and does not represent the final conclusion and truth. Please do not take it out of context when spreading it.

Who placed the back door and how? At presentThere is no real hammer evidence, some people think it's the Tronbank developers, others think the developers are not strong enough to fool TSC into validating code that is different from the actual deployment.

An objective analysis of the possibility of existence (note that only the possibility is discussed here, even if the probability is extremely low and there is no real evidence of the truth at this time) includes the following:

Possibility 1: the Tronbank developer put a backdoor in the actual deployment contract and managed to trick TSC into completing another code validation without a backdoor.

In exploring this possibility, how to trick TSC became the focus,If there is a Bug in TSC's validation, then it means that all previous dapps that have been certified by TSC and advertised as open source are no longer trusted and transparentIn Discord, TSC developer Khanh admits that the code has been unmaintained and buggy for a long time, and that other developers have verified that their actual deployed code is not identical to the approved code.

On the other hand,Tronbank's developers repeatedly claimed in the Telegram group that the team had not placed any backdoors in the contract,One way to prove your innocence is to give the source code at deployment time and the compilation method (including the compilation tools and versions), which should theoretically be the same for any bytecode compiled the same way as the TRX Pro contract deployed online. But when we raised the question, the official response was:

If the content of this reply is serious, the event will be more dramatic and complicated, seePossibility of three

Possibility 2: the Tronbank team conspired with the TSC team to deploy the contract with the back door, while TSC assisted in validating the contract with another contract without the back door.

This is on the premise of "deceit TSC is difficult to set up" puts forward the possibility of TSC final validation on label is centralized, can completely artificial operation, but for TSC as a third-party verification tool for contract, there is no competing goods, to do things like this will undoubtedly serious damage their own brands, is complicit in the price is too low.

Possibility 3: the Tronbank team did not put a back door in the contract, but the back door was created in some way during the contract deployment.

This possibility is based on the implication of the official response in "possibility one" that the project did use a contract without a back door when the contract was deployed, and that the compilation tool had added a problematic back door when deploying the contract to the main network. But the project does not currently provide any verifiable information, the compilation tools used, or information about the different results of two compilations of the same code.

In any case, the actual code deployed by TronBank's developers is unknown and cannot be verified, and the truth of the matter will have to wait for more convincing evidence from all sides before it can be pieced back together.

At the moment, at least, it is not clear who planted the back door.

What about investors' money?

Under the complicated information above, most players have given up on the truth and are more concerned with recovering the loss.

Wojak was out of touch for more than 12 hours after promising refunds and demanding trading information from lossmaking investors, during which time most of the money in his account was transferred to the coon exchange. Some began to suspect that wojak had no intention of returning the money in preparation for the donation, while others thought it was a theft by the TronBank project, of which wojak was one.

May 3 at 2:44 p.m

On the other side, in the official group of Tronbank, administrator posted on the top of the message is "TRX Pro was attacked by hackers THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH, emergency treatment, development team is currently will be updated timely in the group of news"

May 3 at 9:13 p.m

Wojak reappeared, saying that he had spent more than four hours writing a script to get tronbank's investment data from the chain to compare it to the losses he had collected. Wojak also compare information posted at https://pastebin.com/raw/gMtxCw97.

May 4 at 1:24 p.m

A full day later, the Tronbank project sent out another notification that they were contacting wojak for a refund. If wojak did not respond by 7pm on May 4, the official compensation plan would be offered to the investors.

May 4th from 3:00 PM to 4:00 PM

In response to a promise to provide an analysis of the incident within 24 hours, officials will again delay, saying they will contact security companies, TSC and wave field officials to conduct more investigations. "There are many details that need to be confirmed," he said. "we've never seen anything like this before. It could be a great story."

7 p.m. on the 4th of may & & NBSP;

To the surprise of most people, the Tronbank project announced its compensation plan as promisedInstead of running away, the project promised to collect information within 24 hours and pay the full amount within 72 hoursIf the payments go ahead, it could be the biggest payouts in Dapp's history.

The compensation notice, it can be said to reassure investors, so that the majority of users to discourage"The back door is left by the developers"Doubts. But before the truth above the water, DappReview still keep questioning attitude, waiting for your open more investigation report.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia