Four Meme’s $120k Attack Analysis

Overview of the Attack

The exploit on the Four Meme token stemmed from a vulnerability in its liquidity mechanism, which allowed the attacker to bypass transfer restrictions and manipulate the liquidity pool pricing.

By leveraging an uncreated PancakeSwap Pair address, they were able to initialize liquidity at an unintended price, effectively draining funds from the pool.

This attack was possible due to a flaw in the transfer function, which allowed unlaunched, untransferable tokens to be moved freely to any address, including the predicted LP address.

As a result, the attacker front-ran the launch transaction, adding liquidity and then immediately extracting profits.

This report breaks down the funds flow, contract interactions, and laundering methods used in the attack.
 

Attack Execution Details

Step 1: Pre-Launch Token Acquisition

• The attacker acquired a small amount of Four Meme tokens before the official launch via the 0x7f79f6df function.
• Instead of holding or transferring them traditionally, they sent the tokens to a non-existent PancakeSwap Pair address.
   

Step 2: Exploiting the Liquidity Pool

• Since this Pair had not yet been created, the attacker was able to initialize it themselves.
• They then added liquidity without triggering the pre-launch transfer restrictions (MODE_TRANSFER_RESTRICTED).
• This allowed them to set liquidity at an unintended price, effectively enabling them to steal the liquidity pool’s funds.

Flow of Funds

Step 3: Funding the Attack

• Three days prior, the attacker withdrew 69 BNB from a FixedFloat hot wallet:

  0x4727250679294802377dD6cA6541B8E459077c95.

• Deployed six contracts to facilitate the exploit:
  • 0x1d8ae12ffc8204b703ad3c169892bf64575016c6
  • 0xac2e52064a5a7ec6850bb1958450d304c2a5b28b
  • 0xf5c08af4a53110a0c605f7cf84a3cf78689332fb
  • 0x18096D7001A207E8DbB502446c4d0B4A7E0996f2
  • 0x3934172C644858D5C6E53d93483D0d6101C70409
  • 0x0b4443A7b8CDB315fB72D7a93C2BD3D25110D2fe
     

Step 4: Extracting Funds from the Pool

The attacker repeatedly called function 0xe564bedd on contract 0xfAfAf651A418D82686705eF8E798c57dBA929804 to drain liquidity from the pool.
 

Step 5: Moving the Stolen Funds

The stolen funds were then distributed as follows:

• 67.3 BNB → 0x4cDdb635d276d262029E0529AB26c3830393805
• 205 BNB → 0x889d83489FDAD90Dd76Eb0308d466C723322B456

Address 0x889d8348… further split the funds:

• 50 BNB → 0x1EC4e58CB8784836F560B9e896B38958332e92fa
• 50 BNB → 0xaffda528759DB3407A32f9f0c1Bc4b20c088d51f
• 100 BNB → 0x54Ab3ff483Be26d106daC3901825d5a2EfE66D73
• 5.8 BNB → 0x6a761c9E18D1C49bBBFeAFc88ea5c908D10c29D9
   

Step 6: Laundering via PancakeSwap

The attacker used contract 0x4cDdb635d276d262029E0529AB26c3830393805 to swap stolen funds via PancakeSwap’s $BROCCOLLI 3 contract (0x086d707a…):

• 192 WBNB was swapped and further split:
  • 186 WBNB → PancakeSwap DCA 32 (0x77C1dF8…)
  • 181 WBNB → Pancake LP contract (0x9C8c3F1…)
  • 174 WBNB → PancakeSwap MuBrocolli (0xcaC54d89…)
  • 167 WBNB → WWC 36 (0x78Cc2bFb…)
  • 160 WBNB → PancakeSwap 4mubarak (0x87B67269…)
  • 153 WBNB → PancakeSwap cocoro 104 (0x232f6a17…)
  • 146 WBNB → PancakeSwap AADAAB (0x22a84067…)
  • 137 WBNB → PancakeSwap mpc 123 (0x41Fb5Fa1…)
  • 129 WBNB → PancakeSwap minimubara (0xcCeD1B73…)
  • 121 WBNB → MCP 32 (0x75a4Ec99…)
  • 114 WBNB → PancakeSwap 47547148 (0x97b16429…)
  • 104 WBNB → PancakeSwap SBL 43 (0x6b9AE141…)
  • 95 WBNB → PancakeSwap couple 3 (0x2A1ab3cb…)
  • 87 WBNB → PancakeSwap mubara king (0x3Ade31b5…)
  • 77 WBNB → PancakeSwap autopen 2 (0x43006C39…)
  • 67 WBNB → PancakeSwap mbrocolli 2 (0x738be9F1…)
     

Decompiling one of the attack contracts…

Here are some things we found while decompiling 0x4cDdb635d276d262029E0529AB26c38303938055

Multiple "Owner" Variables

The contract maintains ownership across multiple storage slots (owner_4 to owner_b), which is unusual. This could be an attempt to obscure control or distribute permissions among different addresses.
 

Function Selector Mapping with Block Number

The ___function_selector__ mapping uses the current block number as a key. This could be a way to dynamically assign function selectors or track execution, potentially to evade detection.
 

Hidden Liquidity Pool Interactions

• There are interactions with PancakeSwap (getPair, createPair) involving 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c, which is the WBNB token contract on BSC.
• The function 0x17a8 appears to check if a liquidity pool exists and creates one if not.
• The contract later deposits BNB into WBNB (deposit().value(v43)). This could be a method to convert and obfuscate fund flows.
   

Memory Manipulations and Self-Calls

Functions like 0x1097 and 0x124c perform complex memory operations and self-calls (address(this).call). These are often seen in laundering contracts to fragment transactions and make tracing harder.
 

Potential Access Control Bypass

• function 0x124c() loops through array_0 and array_1, seemingly verifying ownership before calling 0x1097().
• This might be an unconventional access control check where approved wallets are dynamically set.
   

Key Takeaways & Security Implications

1. Pre-Launch Vulnerabilities

• Tokens should restrict pair creation to prevent unauthorized liquidity additions.
• Pre-launch restrictions must cover all possible transfer methods, including function calls that interact with liquidity pools.
   

2. Liquidity Manipulation Risks

• Unauthorized liquidity pool creation can give attackers control over pricing and extraction mechanisms.
• Projects should consider using whitelisted liquidity providers or delayed pool activation mechanisms.
   

3. FixedFloat as an Exit Strategy

• Attackers frequently use FixedFloat to obfuscate the origins of stolen funds.
• Monitoring repeated interactions with FixedFloat addresses could help track exploiters before cashout.
   

4. On-Chain Laundering via PancakeSwap

• Instead of direct withdrawals, attackers often mix funds through multiple PancakeSwap pools before exiting.
• Advanced liquidity tracking tools can help identify patterns of fund obfuscation.
   

5. Private RPC usage

If Four meme used private RPC, they could have concealed the launch transaction, preventing front-running.