Drained MEV Bot: No-Auth Transfers and Unsafe msg.sender.call

We reverse-engineered a drained MEV bot on BSC using EVMDecompiler and found two fatal flaws hidden in bytecode (no published source):

• msg.sender.call{value: amount}("" ) with no validation or recipient checks
• Token transfers to msg.sender without authorization checks

Decompiled fragments

function d3MMSwapCallback(address _token, uint256 _amount, bytes calldata) external {
    IERC20(_token).transfer(msg.sender, _amount);
}

function swapX2YCallback(uint256 amountX, uint256, bytes calldata data) external {
    require(amountX <= 0 || amountX == 0);
    (bool success, bytes memory result) = msg.sender.call{value: amountX}("");
    require(success, "SwapX2Y: ERC20 operation did not succeed");
}

function swapCallback(uint256 amount0, uint256 amount1, bytes calldata data) external override {
    _swapCallback(msg.sender, amount0, amount1, data);
}

Why this is fatal

• Value transfer to msg.sender: using msg.sender.call forwards control and value to an arbitrary caller; with no whitelist or invariant checks this enables theft/abuse and traps funds when called by contracts that revert in fallback.
• Token transfer to msg.sender: directly transferring arbitrary _amount to the caller without auth enables draining tokens held by the contract.

Safer patterns

• Use pull-payments or explicit recipient parameters with strict allowlists.
• Avoid address.call for value; prefer transfer/send with checks or withdrawal patterns.
• Gate callbacks with signed intents, nonces, or trusted router addresses.

Analysis performed from decompiled bytecode; function names reconstructed for clarity.