What happened
PORNHUB on BNB Smart Chain lets only one hard-coded address move tokens with transferFrom. The function opens with require(from == _owner, "You are not the owner!");, so any transferFrom whose from is a holder other than that address reverts. DEX sells normally pull tokens from the seller into the liquidity pair through transferFrom, so ordinary holders' sells revert, while plain transfer calls between wallets have no restriction.
_owner is a private constant-style address set at deployment (0x7E784333…25aCd0, the deployer) and the source contains no function that changes it. De.Fi's REKT database lists PORNHUB as an Exit Scam/Honeypot dated 2021-05-03 and describes it as a token whose owner could disable the transfer function, restricting users from selling.
How it happened
- The constructor mints the entire
_totalSupplyof 100000000000000000000 base units (decimals 9) to the deployer:balances[msg.sender] = _totalSupply;. - The contract stores a fixed address:
address private _owner = 0x7E784333FBF355fC57De77F9FBe97aA06225aCd0;, which matches the deployer address in the deployment record. No function in the source reassigns it. transferFrombegins withrequire(from == _owner, "You are not the owner!");. The check is onfrom, so it fails for every holder except that address.- A sell through a DEX router calls
transferFromwith the seller asfromand the liquidity pair as the recipient, so it reverts for any holder other than_owner. Buys arrive from the pair bytransfer, which has no check, so purchasing and wallet-to-wallet transfers work. - Because the condition is hard-coded and there is no setter, the source offers holders no on-chain switch that lifts the restriction.
Protocol details
Evidence
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
