The dark night is approaching, DApp rivers and lakes staged a realistic version of "Wolfman Kill"

There is a rule in the "Wolfman Kill" game. "Wolfman" can kill people at night in the night. In the daytime, he can evade the identification of "civilians" through eloquence, and eventually win the victory of all "civilians" on both sides.

In the past two days, DApp has produced a real version of "Wolfman Kill". A DPC called TronBank Pro was ransacked by 26.6 million TRXs, and the project investor "civilian" suffered nearly 5 million yuan in property damage. However, who is the "werewolf"? The community has started to have a heated discussion.

So far, there have been three seemingly plausible story lines:

1. The project party "supervised and self-stealed" has a "back door" in its contract code. The reason is that the open source code of the project side is not consistent with the code actually executed. Sending the 0.011911 TRX withdraw() operation to the contract triggers the reserved backdoor and removes the contract balance. Although TronBank Pro issued an announcement denying this claim, so far, there is no reasonable explanation for why there is a "back door".
2. The project side is subject to the third-party verification service platform TSC "calculation". According to the in-depth analysis of blockchain security company PeckShield, as a third-party service platform, TSC discovered the "back door" as early as April 28, before the project contract went live, and successfully implemented the attack test. However, the user of the hacker code name wojak has not found any connection with TSC, and the truth of the matter has been confusing. But it can be concluded that the third-party service platform TSC is difficult to clarify the relationship with this matter.
3. The hacker staged a wonderful drama of "Hunting the oriole in the back". There is a possibility that TSC hit the "back door" early, but because the fund pool has not yet grown up, it has not been started, but the hacker wojak hiding in the dark also found the "back door" and took the lead in implementing the attack. The paradox is that wojak even said afterwards that he promised to return the stolen funds. However, for various reasons, wojak quickly refused to return and disappeared. Such a wayward and cute hacker is rare.

The PeckShield digital asset tracking platform is involved in this major "security incident" on the Tron platform (two types of accidents: one is a natural disaster, one is a man-made disaster), and the tracking restores the ins and outs of things, as much as possible through technical analysis. The victim "civilian" finds the truth.

• Tether Chronicles
• Zhu Jiaming: The Digital Economy Fifty Years, From "Singularity" to "Big Bang"
• Market Analysis on May 5: A Brief Talk on the Similarities between the Current Market and the Beginning of the 17th

As for the following, it is about natural disasters or man-made disasters, leaving the readers to judge for themselves.

background

Friends, have you heard of TronBankPro? A blockchain investment product with a fixed daily income of 1.8% – 4.8%, our contract code is open source, and the contract is verified by the "well-known" verification agency tronsmartcontract.space (TSC) and the data on the chain. Although we were attacked by the BTTBank counterfeit currency incident, we are a responsible team, we will not, run the road…

Xiaobai investors believe that since the TronBank team had a security incident before, it is necessary that the contract review work should be done this time. Users can see from their official website that the team is still doing things, compared to other For the open source DApp, the project party actually announced the source code, "still trustworthy."

Unprofessional TSC

Due to the lack of an official certification platform, some DApp developers have a “responsible to the user” attitude. Most DApp contracts on the Tron platform use the contract consistency check service of the third-party platform TSC (currently Tron officially does not introduce such a standard. Service, only available in the market https://tronsmartcontract.space). In-depth analysis by PeckShield security personnel found that TSC can help DApp developers verify some basic security guarantees, but the TSC service code itself is not complete enough to guarantee the reliability of the verification results. Of the 278 contracts that TSC has approved so far, the contract source code is only 85 consistent with the Tron chain, and the unqualified ratio is as high as 70%. How can such a high percentage of disqualification be recognized by users and DApp developers? ?

After the PeckShield security personnel contacted the TSC developer, the other party also admitted that the service was still in the early stage of construction and could not guarantee the reliability of the audit results. In addition, Tron officials did not acknowledge, nor recommended that the community adopt and trust the verification results of tronsmartcontract.space, see Tron Sun's Weibo content:

Ghosted TSC

PeckShield security personnel analyzed the TSC official website to find out if there was any hacking clues on the site. When accessing the site's "contract verification" function, it was found that TSC was shut down for some reason at this critical time. After PeckShield security personnel and TSC maintainer KhanhND69 asked about the matter, the other party said that the previous audit log was recently deleted. The "contract verification" function was closed due to the current development of the new version of the feature, this old feature has been offline. As for when the new features are online, the other party did not expressly indicate.

As for whether the TSC statement is logical, whether the motivation is simple or not, it is reserved for the readers to taste.

Since TSC is just an "independent" code verification platform, what does he have to do with TronBankPro being stolen?

Open source backend validation code on GitHub:

It can be known that the verification process is as follows:

1. The bytecode createByteCode of the contract is obtained from the Tron chain by the specified contract address;
2. The bytecode reCompileByteCode is obtained by compiling the given contract source code and compiler version;
3. Get the equal-length createByteCode according to the length of reCompileByteCode, and then compare the difference between the two by byte;
4. If the number of bytes difference between the two is < 64, then the two are considered to be consistent, otherwise the verification fails.

The above verification process is simple and practical. Xiaobian has re-verified the TronBankPro contract, which is the TSC open source TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ source code, and found that the two cannot match, the difference is very large, it is impossible to meet the conditions in the code. .

Here, Xiao Bian thinks that TSC is very likely to not follow the routine in this "accident" (what is the routine? I don't understand, manual black face).

In addition, Xiaobian accidentally discovered the following doubts:

1. TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ contract verification time in Beijing time 2019-04-28 22:51:32; and on the same day TSC deleted all git commit history of all verified contracts open source on GitHub, known as Db backup, verified after deletion One contract is TronBank Pro's TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ contract, which seems to be doing things:

The TSC#author page shows that the donor address for this platform is TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr:

it's dark

It’s dark, everyone please close your eyes, the werewolves come out to kill…

Careful analysis of other address information with TTX5N… This address, found some interesting stories, please listen to Xiaobian slowly.

The timeline of the entire "accident" is roughly divided into several parts:

1. Preparation period
2. Incubation period
3. Harvest time
4. Cashing period

Look at the official, please see the complete storyline:

Preparation period

1. 4.28 17:35 + UTC8 TSC donors to address TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr created trouble contract bytecode and later TronBankPro almost exactly the same TBPro contract, the contract addresses TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz, the hash for the corresponding transaction b20242bbabfc357f4e6f5d31641d350670c7be1a6536eef1133f344a29972f53, ask TronBank Pro contract was not on the line, then How does TSC know the content of a contract that is not online?
2. 4.28 22:48 +UTC8 TronBank project side deploys TBPro contract, contract address is TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ, transaction hash is 267a8671989e5e0cf30cc9a32eb8a74cfb0c106209dd8ac462211687280419b5;
3. According to the time specified in tronsmartcontract.verify/TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ/info.json at master · TSC/tronsmartcontract.verify, we know that TBPro deployed by TronBankPro is in 4.28 22:51 +UTC8 "Verification Pass"; (The previous small series uses various computers Knowledge can't be verified at all, then how is TSC verified? Ghost knows);
4. 4.28 23:00 +UTC8 TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr Send the withdraw() command to the TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ contract deployed by TronBankPro, carrying 0.011011TRX, and the corresponding transaction hash is d6d89713ebdb98402ddfd1d454be394a5521c83b7d385ce2c394924a2b923c89. As you can see from the block browser, this transaction was REVERT, according to PeskShield security analysts, because the sent withdraw() command carried TRX, which is understandable: withdraw() is used to contract Retrieving the previously invested TRX, then the transaction with the TRX is considered "misoperation", REVERT is reasonable:

   

Incubation period

Waiting for user investment to swarm, the contract funds pool has grown.

1. 4.30 10:12 +UTC8 TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr For the TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz contract deployed by itself, the withdraw() command carrying 0.011011TRX is also sent, and the corresponding transaction hash is 4b8dd07afa029126f16c192e8eb8a158f883e80a6be1eceaa432247bb06ef6ab, the same operation, the transaction is REVERT;
2. 4.30 10:12 +UTC8 In the next few blocks, TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr also sends a withdraw() command carrying 0.011911TRX to the TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz contract deployed by itself. The corresponding transaction hash is 87bf173c126c4873ad333c02d4e352bacda9bfaae4d91d0bce156eb64bd5219f, but this time it succeeded:

   This time, not only succeeded, but also transferred 100.011911TRX from the TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz contract to the initiator TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr.

At this point, it seems that there are not many stories happening, but the good show has just begun…

Harvest time

5.1 Holidays are always so rushing. In the time when Xiaobian is still at home, the TronBankPro contract has attracted nearly 1600+ users with nearly 30,000,000 TRX investments:

The current market price is $700,000 .

Seeing that it is in the harvest period, 05.03 04:12 +UTC8 has a hacker named THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH. By the same operation as TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr (withdraw() carrying 0.011911TRX), it is half-cut and successfully retrieved 2600W+TRX . As for who the wojak hacker is, no one knows it. The specific transaction hash is as follows:

Based on this, PeckShield security personnel believe that the TCK TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr deployment of the TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz contract and the TronBankPro deployment of TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ contract have backdoors , as to how the back door is inserted, who is inserted, it is not known.

After the PeckShield security personnel reversed the TYZ4oPdPmwZS9xTUXhnFtQkPFFTi2iAydz and TW9AE7u5QADp2uej9xdaNVTYtqsRuJZNxJ contract reverse code, the following piece of code was found in the withdraw() logic:

It is not difficult to see that withdraw() is divided into three cases according to the size of TRX carried by msg.value:

1. 0x2B03 == msg.value

Converting hexadecimal 0x2B03 to decimal is 11011Sun (since TRX == 10^6 Sun), equivalent to 0.011011TRX. This value is just the TRX value carried in the above TSC TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr test.

Under this branch, the status is not changed, the transaction output is OK, and finally exits with REVERT. This behavior is consistent with the return information of the above transaction. PeckShield security personnel believe that this branch code is the debugging function deliberately left by the developer to confirm the contract. The logic is in line with expectations.

0x2E87 == msg.value:

Converting 0x2E87 in hexadecimal to decimal is followed by 11911 Sun (since TRX == 10^6 Sun), equivalent to 0.011911TRX. This value is equal to the value of the TTX5N2wxLeyWBSNE6UeaBjCFZbpa2FH6jr and THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH calls.

Under this branch, all the TRX balances in this contract will be transferred to the call initiator, nothing left.

In other cases, the normal withdraw() retrieve operation.

Here, PeckShield security personnel believe that the "misoperation" returned by the above 0.011011TRX with REVERT is actually the test before the hacker attacks.

Cashing period

After the hacker THeRTTCvN4SHEVYNqcLVLNGGVsWLR4smyH gets 2600W+TRX, it starts to transfer assets in batches:

Among them, a total of 1,4000,000 TRX was transferred to the Binance Exchange at 2019-5-5 19:00 Beijing time.

Its daybreak

The analysis of the above pure technology shows that two points have been fully verified:

1. The third-party verification service platform TSC is not professional. Most of the contracts it has served have the inconsistency between the contract source code and the bytecode on the Tron chain, which proves that the TronBank Pro project party has a large omission to find the TSC for consistency check service.
2. The third-party verification service platform TSC is hard to avoid. It found a contract vulnerability before the TronBank Pro project went live. However, it did not urge the project to adjust the problem in time. Instead, it implemented the attack test instead. After being attacked, how can TSC stay out of it?

Of course, even if PeckShield has already tracked the ins and outs of technology through technology tracking, in the virtual world of the blockchain, it is still difficult to determine who is the werewolf in this "wolfman killing" drama. Before the project party does not pay for the damage funds, it is difficult to escape the responsibility; the third-party service platform TSC is currently the biggest "ghost", but is the relationship with the project party really clear? As for the arbitrarily and somewhat irritating hacker wojak, is it really a person, or is it just a small vest in the whirlpool? Who can tell the truth and make it clear?

The code is verified, and it is human nature that cannot be guessed!

PeckShield is the world's leading provider of blockchain data and security services. Business and media cooperation (including smart contract audit requirements), please contact us via Telegram, Twitter or email ([email protected]).

We will continue to update Blocking; if you have any questions or suggestions, please contact us!