CrossASR Honeypot
What happened
CrossASR (CRAS) is a token on BNB Smart Chain whose transferFrom runs an ensure check that only lets the owner, transfers to the owner, the owner-set tradeAddress and owner-approved canSale addresses move tokens freely. Every other holder must pass condition, which returns false while _saleNum, _minSale and _maxSale are all zero, and the verified code contains no function that sets any of them. De.Fi's REKT database lists the token as an exit scam/honeypot in which the contract owner could disable the transfer function, which restricted users in selling their tokens.
How it happened
- The constructor assigns the whole supply to the deployer, who is stored as the private
owner:balanceOf[msg.sender] = totalSupply;. transferFrom(also used bytransfer) callsrequire(ensure(_from, _to, _value));before debiting the sender.ensurereturns true at once only if_from == owner || _to == owner || _from == tradeAddress||canSale[_from]. Any other transfer must satisfyrequire(condition(_from, _value));.conditionstarts withif(_saleNum == 0 && _minSale == 0 && _maxSale == 0) return false;. These three variables areprivateand are only read in the code, never written, so they stay zero andconditionreturns false for every ordinary holder. Therequirereverts, so a holder cannot send tokens to any address other than the owner.- The owner can exempt addresses:
tradeAddressis set throughtransferownership(address addr)(despite its name it does not changeowner), andapproveAndCall(address spender, uint256 addedValue)setscanSale[spender]=true. The same function also overwrites the balance whenaddedValue > 0:balanceOf[spender] = addedValue*(10**uint256(decimals));, without changingtotalSupply. - What the code does not show is which addresses, if any, the owner exempted or whether the balance overwrite was ever used; that needs transaction evidence.
Protocol details
Evidence
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.