What happened
The transferFrom function of this token reverts for any holder whose allow flag is false, and only one hard-coded address can change that flag. The constructor sets allow for the deployer only, so ordinary holders can receive tokens and call transfer, but any sale that pulls their tokens with transferFrom fails. De.Fi's REKT database lists the contract owner as able to disable transfers, which restricted users from selling their tokens.
The same hard-coded address can also overwrite any account's balance with mint. The code shows these powers; it does not show when or whether they were used.
How it happened
- The constructor whitelists only the deployer:
allow[msg.sender] = true;. Every other address keeps the default valuefalseinmapping(address => bool) public allow. transferFrombegins its checks with the token owner's address as_fromand containsrequire(allow[_from] == true);. A sale that moves a holder's tokens throughtransferFromtherefore reverts for every address that is not whitelisted.transferhas no such check (it only requires a non-zero recipient and enough balance), so tokens can still be received and sent directly. Holders can acquire tokens but atransferFromsale reverts.- The whitelist is controlled by
function addAllow(address holder, bool allowApprove) external onlyOwner. The modifier ismodifier onlyOwner() {require(msg.sender == address(1080614020421183795110940285280029773222128095634));_;}. That literal equals 0xbd486897…439192, which is not the deployer 0x839C95f4…ed7bAA, and the modifier never reads theownervariable, sotransferOwnershipdoes not change who can calladdAllow. function mint(address miner, uint256 _value) external onlyOwner { balances[miner] = _value; }assigns a balance instead of adding to it and leavestotalSupplyunchanged. The same address can therefore set any account's balance to any value.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
