BBOX Token Exploit — Fee-Engine Burns Tokens Out of the LP Pair and `sync()`s

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2022-12-BBOX_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/BBOX_exp.sol.

Vulnerability classes: vuln/logic/incorrect-state-transition · vuln/defi/slippage

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that do not compile together, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: BBOXToken.sol.

Key info#

TL;DR#

BBOXToken (BBOXToken.sol) is a "share-dividend" deflationary token whose _transfer maintains a state variable pairAmount (intended to track fees that should be removed from the LP pair). On any non-AMM transfer where pairAmount > 0 and the pair's BBOX balance exceeds pairAmount, the engine:

1. Burns pairAmount worth of BBOX out of the LP pair's own balance — _tOwned[uniswapV2Pair].sub(v) (BBOXToken.sol:724-726);
2. Calls IUniswapV2Pair(uniswapV2Pair).sync() (BBOXToken.sol:728), forcing the pair to accept that reduced balance as its new reserve.

This is an uncompensated removal of one side of the pool — BBOX disappears from the pair, no WBNB leaves, so the constant-product k collapses and the marginal price of BBOX explodes. The check is pairAmount < balanceOf(pair) — i.e. it fires whenever the attacker can make the pair's BBOX balance dip just below an attacker-influenced pairAmount. The trigger is a plain transfer() (the PoC's TransferBBOXHelp.transferBBOX()), reachable by anyone.

The attack: flash-borrow 3,043 WBNB from DODO → buy BBOX to inflate the WBNB side of the pool by 1,300 WBNB while shrinking the BBOX side; the buy also seeds pairAmount (3% of every taxed buy/sell is added to it); transfer the bought BBOX to the attacker, which trips the burn-from-pair-and-sync() code path and slashes the pair's BBOX reserve from ~5.20e12 to ~2.25e11; then sell the BBOX back into a now deeply WBNB-heavy pool, extracting ~1,338 WBNB more than the 1,300 WBNB put in. Repay the flash loan and keep ~38.44 WBNB.

Background — what BBOXToken does#

BBOXToken is an ERC20 with a referral/share-dividend scheme bolted on. The pieces that matter:

• AMM pair + router are stored at construction (BBOXToken.sol:484-491). The pair uniswapV2Pair is the BBOX/WBNB PancakeSwap pair.
• Fee engine (BBOXToken.sol:659-678): every taxed transfer splits the amount into _lPFee (20), _burnFee (10), _shareFee (30) of 1,000. LP fees accrue to the token contract (address(this)) and are paid out as "dividends" to LP holders.
• pairAmount accumulator (BBOXToken.sol:746-755): on every taxed buy (ammPairs[from]) or sell (ammPairs[to]), pairAmount += amount * 3 / 100. This is supposed to be a reserve-tracking counter for a later "remove-excess-from-pool" step.
• The kill step (BBOXToken.sol:715-729) runs inside _transfer on every transfer and decides whether to forcibly yank pairAmount out of the LP pair.

On-chain parameters at the fork block (block 23,106,506), read from the trace:

The vulnerable code#

1. The burn-from-pair + sync() block inside _transfer#

BBOXToken.sol:715-729:

if(
    pairAmountChange
    && !isAddLiquidity
    && pairAmount > 0
    && !ammPairs[from]
    && pairAmount < balanceOf(uniswapV2Pair)){

    uint v = pairAmount;
    pairAmount = 0;
    _tOwned[uniswapV2Pair] = _tOwned[uniswapV2Pair].sub(v);   // ⚠️ burn BBOX out of the LP pair
    _tOwned[address(0)]      = _tOwned[address(0)].add(v);
    emit Transfer(uniswapV2Pair, address(0), v);

    IUniswapV2Pair(uniswapV2Pair).sync();                      // ⚠️ ...and force-rebase the pair
}

This fires on any transfer where the sender is not the pair itself and the pair's BBOX balance has drifted above pairAmount. The sender does not need to be privileged and does not need to interact with the pair directly — a plain BBOX.transfer(to, amt) between two EOA-like accounts is enough.

2. pairAmount is attacker-controlled#

BBOXToken.sol:744-755:

if( takeFee && ammPairs[from] ){
    param.user = to;
    pairAmount += amount * 3 / 100;     // ← buy seeds pairAmount
    lastBuyTime[to] = block.timestamp;
}
if( takeFee && ammPairs[to] ){
    param.user = from;
    pairAmount += amount * 3 / 100;     // ← sell also seeds pairAmount
    require(block.timestamp > lastBuyTime[from] + sellSwapTimeLimit,"sell limit time");
    require(amount <= balanceOf(from) * sellSwapLimitRate / 100 ,"sell limit amount");
}

A single large taxed buy pushes pairAmount up to ≈3% of the bought amount. Because the buy also shrinks the pair's BBOX reserve (BBOX is leaving the pair), it is trivial to engineer the post-buy state so that the next non-pair transfer sees pairAmount sitting just under balanceOf(pair).

3. The pair is the BBOX/WBNB PancakeSwap pair#

BBOXToken.sol:488-491:

uniswapV2Pair = IUniswapV2Factory(uniswapV2Router.factory())
    .createPair(address(this), wbnb);
ammPairs[uniswapV2Pair] = true;

token0 = BBOX, token1 = WBNB, so reserve0 is the BBOX side, reserve1 the WBNB side.

Root cause — why it was possible#

A Uniswap-V2/PancakeSwap pair only enforces x·y ≥ k inside swap(). sync() is a privileged escape hatch that tells the pair "your real balance changed through legitimate means; re-sync reserves to actual balances." By burning BBOX out of the pair's balance and calling sync() in the same step, the token contract lies to the pair — it removes one side of the reserves without the matching outflow, collapsing k.

The design errors that compose into a critical bug:

1. The token reaches into the pair's balance. _tOwned[uniswapV2Pair].sub(v) is a direct mutation of the pair's BBOX accounting from the token side. The pair has no way to object — and worse, the token then calls sync() to ratify the theft.
2. pairAmount is decoupled from any honest reserve invariant. It is just a running counter fed by +3% of every taxed swap, so an attacker's own buy dictates how much will be ripped out of the pair a moment later.
3. The trigger condition is pairAmount < balanceOf(pair), which is exactly the state a buy creates: the buy moves BBOX out of the pair (lowering balanceOf(pair)) while raising pairAmount. The attacker just sizes the buy so the two cross.
4. No access control on the transfer path. The burn fires on a plain transfer(); the attacker wraps it in a one-line helper (TransferBBOXHelp.transferBBOX) to dodge the sellSwapTimeLimit / sellSwapLimitRate restrictions that only apply when the pair is the recipient — here the recipient is the attacker itself.

Because the burn is a one-sided reserve deletion, the post-burn pool is WBNB-heavy and BBOX-starved, so the attacker's subsequent sell extracts far more WBNB per BBOX than the buy cost.

Preconditions#

• A working PancakeSwap BBOX/WBNB pair with non-trivial WBNB (pairAmountChange == true, the default at BBOXToken.sol:463).
• Flash-loanable WBNB (the PoC borrows 3,043.12 WBNB from a DODO DVM pool; principal is repaid intra-tx).
• The attacker must route the buy through the router so the fee engine runs and seeds pairAmount — exactly what Router.swapExactTokensForTokensSupportingFeeOnTransferTokens does (BBOX_exp.sol:48-50).

Attack walkthrough (with on-chain numbers from the trace)#

token0 = BBOX, token1 = WBNB. All figures are taken directly from Sync/getReserves events in output.txt. BBOX has 9 decimals; reserves shown in wei.

Final attacker WBNB balance (line 325): 38,435,195,424,700,962,888 ≈ 38.435 WBNB.

Profit / loss accounting (WBNB)#

The profit (38.44 WBNB) is essentially the pool's entire original WBNB reserve (~40.88 WBNB), minus swap fees and rounding. The attacker walked off with ~94% of the honest liquidity in a single transaction while fully repaying its flash loan.

Diagrams#

Sequence of the attack#

Pool state evolution#

The flaw inside _transfer#

Why the magic numbers#

• Buy input = 1,300 WBNB (BBOX_exp.sol:49): large enough to (a) slash the pair's BBOX reserve down to the same order of magnitude as the pairAmount it generates, and (b) leave the post-burn pool so WBNB-heavy that the sell returns more than the input.
• Recipient = TransferBBOXHelp, then transferBBOX() back to attacker: routing the buy output to a separate helper means the next BBOX movement is a clean transfer between two non-pair addresses — exactly the path that triggers the burn. It also sidesteps the sellSwapTimeLimit/sellSwapLimitRate guards, which only apply to sells (pair as recipient).
• Sell input = 90% of balance (BBOX_exp.sol:58): the maximum allowed under sellSwapLimitRate = 90, so the attacker dumps as much BBOX as the cooldown/rate guards permit into the degenerate pool.
• Flash-loan amount = DODO's full WBNB balance (3,043.12 WBNB, BBOX_exp.sol:31): headroom; only 1,300 WBNB is actually consumed by the buy. The rest is repaid untouched.

Remediation#

1. Never mutate the LP pair's balance from the token side, and never call pair.sync() from inside the token's transfer logic. Removing the entire block at BBOXToken.sol:715-729 eliminates the bug. If "removing excess tokens from the pool" is a real product requirement, route it through the pair's own burn() (LP redemption) so both reserves move together and k is preserved.
2. Decouple fee accounting from reserve manipulation. pairAmount is a running counter that any user can inflate via a taxed swap; tying a reserve burn to it hands the attacker the knob. If fees must accumulate, accrue them to address(this) and distribute via a permissioned keeper, never by editing the pair's books.
3. Add a reentrancy/atomicity guard around state that affects AMM pricing. The burn + sync() runs in the middle of a user-initiated transfer, so a single transaction can both deflate the pool and trade against the deflated price. Any operation that changes balanceOf(pair) should be its own gated, non-composable step.
4. Use a TWAP/oracle rather than instantaneous reserves for any pricing or dividend logic, so transient donation/burn manipulation cannot be monetized in the same block.
5. Make sellSwapTimeLimit / sellSwapLimitRate apply to all value-moving transfers toward the pair, not only to literal sells — the helper-contract detour should not bypass anti-dump guards.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to compile under forge test's whole-project build):

_shared/run_poc.sh 2022-12-BBOX_exp --mt testExploit -vvvvv

• RPC: a BSC archive endpoint is required (the fork block 23,106,506 is from December 2022). foundry.toml is configured with a BSC archive endpoint; most public BSC RPCs prune this height and fail with header not found / missing trie node.
• Result: [PASS] testExploit() with attacker net WBNB ≈ 38.44.

Expected tail:

Ran 1 test for test/BBOX_exp.sol:ContractTest
[PASS] testExploit() (gas: 1220366)
Logs:
  [End] Attacker WBNB balance after exploit: 38.435195424700962888

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 41.76s (41.08s CPU time)

References: Ancilia analysis — https://twitter.com/AnciliaInc/status/1599599614490877952 ; attack tx 0xac57c78881a7c00dfbac0563e21b5ae3a8e3f9d1b07198a27313722a166cc0a3.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-12-BBOX_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: BBOX_exp.sol.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "BBOX Token Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.