Interpretation of pro's analysis on the Cetus Protocol Hacker attack event

Popular version: A simple "translation" interpretation of the tech pro regarding @CetusProtocol

Analysis of Hacker Attack Events:

This attack exposes a classic integer overflow issue, specifically manifested as data truncation during the type conversion process.

Technical details breakdown:

1. Vulnerability Location: The issue arises in the type conversion mechanism of the get_amount_by_liquidity function, where the forced conversion from u256 to u64 leads to the loss of high-order data.

2. Attack Process:

1. The attacker passes a huge liquidity quantity parameter through the add_liquidity function;

2. The system calls the get_delta_b function to calculate the required number of B tokens.

3. During the calculation process, when multiplying two u128 type data, the theoretical result should be of u256 type;

Critical flaw: forcing the u256 result to convert to u64 when returning from the function, resulting in truncation of the high 128 bits of data.

3. Utilization Effect: The liquidity quota that originally required a large number of tokens to mint can now be completed with only a very small amount of tokens. Attackers obtain a huge share of liquidity at a very low cost, and then achieve arbitrage in the fund pool by destroying part of the liquidity.

A simple analogy: it's like using a calculator that can only display 8 digits to calculate 1 billion × 1 billion; the 20-digit result can only show the last 8 digits, while the first 12 digits simply disappear. The attacker is exploiting this "calculation precision loss" vulnerability.

It is important to clarify: this vulnerability is unrelated to the underlying security architecture of @SuiNetwork; the security of the Move language is still temporarily trustworthy. Why?

The Move language does have significant advantages in resource management and type safety, effectively preventing underlying security issues such as double spending and resource leaks. However, the issue that occurred with the Cetus protocol is a mathematical calculation error at the application logic level, not a design flaw of the Move language itself.

Specifically, while Move's type system is strict, it still relies on the developer's correct judgment for explicit casting operations. When the program actively performs a type conversion from u256 to u64, the compiler cannot determine whether this is intentional design or a logical error.

Moreover, this security incident is completely unrelated to Sui's consensus mechanism, transaction processing, state management, and other core underlying functions. The Sui Network only faithfully executed the transaction instructions submitted by the Cetus protocol, and the vulnerability originated from the logical flaws in the application layer protocol itself.

In simple terms, no matter how advanced a programming language is, it cannot completely eliminate logical errors at the application layer. Move can prevent most underlying security risks, but it cannot replace developers in performing boundary checks for business logic and overflow protection for mathematical operations.

Correction:

I further communicated with the pro, and there were discrepancies in the technical analysis of the @CetusProtocol hacking incident regarding specific details, so I would like to correct that.

Previously, it was accurately identified that this is a mathematical calculation overflow vulnerability. The attacker constructs special values, and the core logic of "small bets for big gains" is correct. The answers to everyone's concerns about the security of the Move language are also correct.

I just noticed the phenomenon of mathematical calculation errors and speculated that it was a type conversion issue, but in reality, it was a boundary check problem of other functions. In fact, the Move language has a strict review mechanism for type conversions such as from u256 to u64, and these explicit conversions do indeed have safety checks under normal circumstances.

The specific vulnerability locations and technical implementation mechanisms need to be corrected as follows.

The real issue arises from the overflow check mechanism failure in the get\_delta\_a function:

1. Function Purpose: Calculate the required amount of token A when adding specified liquidity;

2. Key Defect: The overflow check in the checked\_shlw function has a coding error, failing to prevent invalid large liquidity values;

3. Attack Utilization: Hackers construct special liquidity values to bypass validity checks, ultimately allowing the required amount of token A to become 14 through the upward rounding mechanism of div_round.

Attack effect: Mint a large amount of liquidity using 1 token A, and then drain the fund pool.