Frontfanz Rug Pull

What the code allows (the sources do not show which of these were used):

1. The constructor mints the whole supply to the tokenOwner argument (_mint(tokenOwner, total);) and sets _tokenOwner = tokenOwner;. The deployer becomes _owner through Ownable, and the same code exempts both addresses from fees (excludeFromFees(tokenOwner, true); excludeFromFees(_owner, true);).
2. Only that address can seed the pool: when the pair holds none of the token, if(balanceOf(uniswapV2Pair) == 0){ require(_tokenOwner == from); } blocks every other sender from the first liquidity transfer, so the initial LP tokens go to the project side.
3. Every non-exempt trade calls an external contract: buys run tllcou.addInAmount(to, amount);, sells run tllcou.addOutAmount(from, amount); and plain transfers also run tllcou.addOutAmount(from, amount);. The tllcou address starts empty and is set only through rotctvvcEooicrZeool(IUserAmounttllcou _tllcou) public onlyOwner. Its code is not in the verified source, and any revert inside it reverts the user's trade, so the owner can set a contract that blocks chosen buyers or sellers; until it is set, a call to an address with no code reverts for non-exempt trades.
4. Addresses added with addOtherTokenPair (onlyOwner) bypass the whole rule set: if(_isExcludedFromVipFees[from] || _isExcludedFromVipFees[to]){ super._transfer(from, to, amount); return; }.
5. On buys and sells the code takes a fixed 4%: super._transfer(from, _destroyAddress, amount.div(100).mul(4)); amount = amount.div(100).mul(96);. The holder is debited the full amount, but this is the same 4% on both sides and not owner-adjustable.
6. changeCanSell and maxSellToken (callable by _tokenOwner) write canSell and _maxSell, but neither value is read anywhere in the transfer path, so they do not block sells. startTime is never assigned, so the buy-amount reduction amount = amount.div(1000000000000000) guarded by startTime.add(10) >= block.timestamp is not reachable.
7. rescueToken lets contractSender (the deployer) send any ERC20 held by the token contract to itself; it does not touch pool reserves. renounceOwnership and transferOwnership exist, and the current on-chain owner() read returns 0x00000000…00dead.

What was reported:

8. De.Fi lists 29,990 USDT of liquidity added on Aug 17 and five liquidity removals totalling 128,292 USDT by Aug 19, with the proceeds distributed to several EOAs. De.Fi Security's own post puts the deployer profit at about $30k instead of the listing's 98,302 USDT.