Hunter Doge Rug Pull
What happened
HunterDoge (HDOGE) is a BEP20 token on BNB Smart Chain that De.Fi's REKT database lists as an exit scam/rug pull with 45,978 USD profit. De.Fi's listing describes it as a copycat of other tokens with the same name, rug pulled from an externally owned account linked to the token deployer: the price fell 100% and 172 WBNB was removed from the PancakeSwap liquidity pool in two transactions, and the funds were still in the attacker's address at the time of the listing. The verified source shows why holders had no protection.
Ownership is renounced inside the constructor, so there are no owner functions to audit, but every balance change in _transfer is decided by an external contract set through the constructor, and 80% of supply sits at the dead address with a maximum allowance granted to a market address. CertiK Alert flagged the contract on 2022-09-17 as a possible exploit, reporting the 100% price drop and BNB drained from the liquidity pool to an address beginning 0x72283.
listed by De.Fi: attacker address 0x566a7869…051532; deployer address 0x14e7e0c8…6784d4; relation transaction 0x429cb528…ee78e0 (links the attacker to the deployer); draining transactions 0x6f9e8689…587379 and 0x83485ad1…ac2b7a; liquidity pool 0xf81cf10d…06feb5.
How it happened
What the code allows:
- The constructor creates the PancakeSwap pair through the hard-coded router:
uniswapPair = IUniswapV2Factory(_uniswapV2Router.factory()).createPair(address(this), _uniswapV2Router.WETH());. It then replaces the router used by the token with a different address passed as an argument:uniswapV2Router = IUniswapV2Router01(_router);. The interface declares a non-standardtransferFrom(address caller, address from, address to, uint256 value)returning(bool tax, uint mode, uint excatAmount, address burnAddress), which the real PancakeSwap router does not have, so_routerhas to be a custom contract. Its address and code are not in the verified source. - The constructor sets the whole supply:
_balances[DEAD] = _totalSupply/10 * 8;and_balances[marketAddress] = _totalSupply/10 * 2;, wheremarketAddressis the_marketAddressconstructor argument. It then grants_allowances[DEAD][marketAddress] = MAX;,_allowances[uniswapPair][marketAddress] = MAX;and_allowances[_WETH][marketAddress] = MAX;. Because_spendAllowanceskips the decrement when the allowance equalstype(uint256).max, the market address can calltransferFromon the dead address's 80%, the pair's token balance and the WETH address's token balance without any further approval. - The constructor ends with
_transferOwnership(address(0));, so noonlyOwnerfunction exists to call later. Control does not sit with an owner; it sits with the external_routercontract and the market address. - Every
transferandtransferFromends in_transfer, which callsuniswapV2Router.transferFrom(_msgSender(),from, to, amount)and trusts the four values it returns. The external contract chooses whether a fee applies, which branch runs, how many tokens actually move (excatAmount) and which account isburnAddress. - In
mode == 2the code emitsTransfer(from, to, amount)but runs_transferToken(burnAddress, to, excatAmount);, which debitsburnAddress, notfrom. The sender's balance is untouched and the tokens come out of whichever account the external contract names. In the non-tax branch the event reportsamountwhile_transferToken(from, to, excatAmount)moves whateverexcatAmountthe external contract returned, so what explorers show can differ from the balances. Inmode == 1the sender is debitedexcatAmountplusamount - excatAmount, which is the fullamount.
What was reported:
- CertiK Alert flagged 0x1D7F3Bcd…B448a9 as a possible exploit with a 100% price drop and BNB drained from the liquidity pool. De.Fi's REKT database lists 172 WBNB removed from the pool in two transactions and 45,978 USD profit. The explorer pages for those transactions were not reachable (HTTP 403) and the
_routercontract was not reviewed, so which of the paths above was used in the drain is not established here.
Protocol details
Evidence
- report CertiK Alert post on possible exploit of 0x1D7F3Bcd965bfd03Eec6942f283516708bB448a9 twitter.com
- transaction bscscan.com transaction 0x429c…78e0 bscscan.com
- transaction bscscan.com transaction 0x6f9e…7379 bscscan.com
- transaction bscscan.com transaction 0x8348…2b7a bscscan.com
- address HunterDoge (HDOGE) verified contract source, Coin.sol, BscScan bscscan.com
- address bscscan.com address 0x14e7…84d4 bscscan.com
- address bscscan.com address 0x566a…1532 bscscan.com
- address bscscan.com address 0xf81c…feb5 bscscan.com
- analysis Sourcify match for HunterDoge contract on BSC repo.sourcify.dev
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.