Today I received feedback that several people think the following address is a hacker's address: https://(etherscan.io)/address/0x2c9c959516e9aaedb2c748224a41249202ca8be7 There are constantly stolen accounts, and upon opening them, they are all Transfer *, which includes Input Data. We sampled some TX Input Data and found that the content is mostly of the following three types: 0xd5575982 0xfef0b6fc00000000000000000000000000000000000000000000000000000007d5d9e043 0x6fed1ea700000000000000000000000000000000000000000000000000016bcc41e90000 What the hell is this? The direct solution is definitely to look at the meaning of the 4-byte signature at the beginning, which is helpful for understanding what function operation it is. Therefore, the 4-byte of the three types of Input Data are: 0xd5575982 0xfef0b6fc 0x6fed1ea7 Using common methods https://www.4byte.directory/ Upon inquiry, it was found that it was not a regular 4-byte and there were no results. Usually, Input Data is either a call on the chain or a related operation corresponding to the target smart contract. Then it was discovered that this' hacker address' was also seen on other EVM chains such as BSC/ARB/BASE, etc At this point, the intuition may be that the user did not cut the chain network properly, causing the funds to be transferred to the wrong chain, but which chain is the contract corresponding to this address on? So I looked back at the feedback from one of the users, and it turned out that they were playing a DeFi project called Magma on Monad Testnet. Actually, 0x2c9c959516e9aaedb2c748224a41249202ca8be7 is the contract address deployed by Magma on Monad Testnet. The contract has been open source verified, so we can directly read the source code: https://testnet. ((monadexplorer.com))/address/0x2c9C959516e9AAEdB2C748224a41249202ca8BE7? tab=Contract -> https://testnet. ((monadexplorer.com))/address/0x3CD599D3a9e7aDA3CE77D6Bf674D6eF644fe1BA3? tab=Contract file-StakeManager.sol Blind guessing involves operations related to sedimentMon(), sedimentMon() (uint256-referalId), and withdrawMon (uint256 amount), and verification is also simple. There are two methods: 1. After installing the Foundry environment, simply cast sig and check if 4 bytes are as listed before: cast sig "depositMon()" -> 0xd5575982 cast sig "depositMon(uint256 _referralId)" -> 0xfef0b6fc cast sig "withdrawMon(uint256 amount)" -> 0x6fed1ea7 All discoveries have confirmed blind guessing. 2 will be more troublesome, requiring a hard look at the logs and internal Txns related to tx on Monad Testnet and conducting relevant verification with the source code. Finally, the entire analysis work is considered complete by conducting relevant verification through the front-end of the target DeFi project. The final conclusion is that this 0x2c9c959516e9aaedb2c748224a41249202ca8be7 actually belongs to the Magma project party and is not a real hacker address. As for why many users deposit funds into other EVM addresses other than Monad Testnet, it is because the chain network has not been switched. It is difficult to say whether it is a wallet issue or a problem with the Magma front-end. I did not easily reproduce it in the Magma front-end. One of the users also told me: the probability is not high, but it will happen. This situation also occurs when a certain wallet is on the entire chain. There should also be hope for recovery. The project party can create relevant contracts under the same nonce in other EVM chains to support the relevant fund return mechanism. We won't go into details, just ask the project party directly. The main purpose here is to share with you how to uncover the truth when encountering strange security incidents 😬