ROI Token Exploit — Missing `onlyOwner` on `transferOwnership` → Reflection-Accounting Mint

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2022-09-ROI_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/ROI_exp.sol.

Vulnerability classes: vuln/access-control/missing-owner-check · vuln/logic/state-update

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that fail to whole-compile, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: ROIToken.sol.

Key info#

TL;DR#

ROIToken is a SafeMoon-style "reflection" (RFI) token. Its Ownable.transferOwnership() is missing the onlyOwner modifier (ROIToken.sol:181-185), so anyone can become owner of the token. As owner the attacker gains full control of the fee parameters (setTaxFeePercent, setBuyFee, setSellFee) and of the reward-exclusion lists (excludeFromReward / includeInReward).

The attacker then weaponizes the token's own reflection bookkeeping. In RFI tokens a holder's balance is stored two different ways depending on whether the holder is "excluded from reward":

• Excluded → balance read from _tOwned[account] (a raw token amount).
• Included → balance read from tokenFromReflection(_rOwned[account]) (a reflected amount that is divided by a global rate).

includeInReward() flips an account back to "included" but zeroes only _tOwned, leaving the inflated _rOwned untouched (ROIToken.sol:655-666). By being excluded while paying a 99 % "tax" on a flash-loaned amount — which credits the attacker's _rOwned with a huge reflected balance — and then calling includeInReward(self), the attacker makes balanceOf(self) jump from 0 back up to ~3.99 M ROI conjured out of the reflection ledger. Those phantom tokens are sold into the pool for 167.9 BNB.

Net result: starting with 5 BNB, the attacker walks away with 168.33 BNB — draining ~158 BNB of real liquidity from the BUSD/ROI pool.

Background — what ROIToken does#

ROIToken (source) is a fork of the SafeMoon "reflection" token family with extra buy-back / auto-LP machinery bolted on. The relevant mechanics:

• Dual balance representation. Total supply is mirrored in a hugely-scaled "reflection" space. _rTotal = (MAX - (MAX % _tTotal)) (:437), and each holder's reflected balance lives in _rOwned. The conversion rate _getRate() = rSupply / tSupply shrinks every time fees are reflected, so an unchanged _rOwned represents more tokens over time. Excluded accounts are carved out of this and tracked in raw _tOwned instead (balanceOf, :567-570).
• Configurable fees. A base _taxFee plus separate buy/sell tax & liquidity fees. The owner can set all of them at will (setTaxFeePercent, setBuyFee, setSellFee, setLiquidityFeePercent).
• Reward exclusion lists. excludeFromReward / includeInReward move an account between the reflected and raw accounting modes.

On-chain parameters at the fork block:

A subtle but load-bearing fact: the token's uniswapV2Pair is the ROI/WBNB pair, but the attacker operates against the BUSD/ROI pair. Because the buy/sell fee branches in _transfer only trigger when from/to == uniswapV2Pair (:755-765), no transfer through the BUSD/ROI pair ever hits removeAllFee() — so the global _taxFee the attacker sets to 99 applies to those transfers verbatim.

The vulnerable code#

1. transferOwnership is missing onlyOwner#

// ROIToken.sol:176-185
function renounceOwnership() public virtual onlyOwner {       // ← guarded
    emit OwnershipTransferred(_owner, address(0));
    _owner = address(0);
}

function transferOwnership(address newOwner) public virtual { // ⚠️ NO onlyOwner!
    require(newOwner != address(0), "Ownable: new owner is the zero address");
    emit OwnershipTransferred(_owner, newOwner);
    _owner = newOwner;                                        // ← anyone can seize ownership
}

renounceOwnership, lock, and every setter carry onlyOwner. transferOwnership does not. This single missing modifier hands the entire admin surface to any caller.

2. includeInReward zeroes _tOwned but keeps the inflated _rOwned#

// ROIToken.sol:655-666
function includeInReward(address account) external onlyOwner() {
    require(_isExcluded[account], "Account is not excluded");
    for (uint256 i = 0; i < _excluded.length; i++) {
        if (_excluded[i] == account) {
            _excluded[i] = _excluded[_excluded.length - 1];
            _tOwned[account] = 0;          // ⚠️ raw balance wiped...
            _isExcluded[account] = false;  // ⚠️ ...but balanceOf now reads _rOwned!
            _excluded.pop();
            break;
        }
    }
}

// ROIToken.sol:567-570  — the balance switch
function balanceOf(address account) public view override returns (uint256) {
    if (_isExcluded[account]) return _tOwned[account];
    return tokenFromReflection(_rOwned[account]);   // ← reads the *kept* _rOwned
}

While an account is excluded its _rOwned is irrelevant to balanceOf. includeInReward flips _isExcluded to false and discards _tOwned, so the account's balance instantly becomes tokenFromReflection(_rOwned). If _rOwned was inflated while the account was excluded, that inflation materializes as spendable tokens the moment it is re-included.

3. The 99 % "tax" credits _rOwned via reflection#

When the attacker (excluded sender, the pair as recipient — neither equal to the token's uniswapV2Pair) transfers ROI with _taxFee = 99, _getTValues computes tFee = 99 % and only 1 % is delivered. _getRValues multiplies through by the current rate, and _reflectFee shrinks _rTotal (:923-947). Shrinking _rTotal raises the value of every remaining _rOwned — including the attacker's, which (because it was credited the full flash-loaned _rOwned on receipt and only debited 1 % on send) is left enormous.

Root cause — why it was possible#

Two independent flaws compose into a clean drain:

1. Broken access control (primary). transferOwnership lacks onlyOwner. Ownership of a live token is a single transferOwnership(attacker) call away. Once owner, the attacker can rewrite every fee and toggle every account's reward-exclusion state.

2. Asymmetric reflection bookkeeping (the amplifier). The standard SafeMoon-derived excludeFromReward/includeInReward pair never reconciles _rOwned against _tOwned on re-inclusion. excludeFromReward snapshots _tOwned = tokenFromReflection(_rOwned), but includeInReward just sets _tOwned = 0 and trusts the stale _rOwned. The accounting is therefore path-dependent: an account that accrues reflection while excluded "double-counts" it on the way back in.

The attacker bridges these with a PancakeSwap flash swap so that no real capital is at risk: borrow ROI from the BUSD/ROI pair, route it so the attacker's _rOwned balloons under a 99 % tax, repay the loan with the 1 %-delivered remainder, then includeInReward(self) to convert the ballooned _rOwned into ~4 M ROI of phantom balance, and dump it for BNB.

Preconditions#

• transferOwnership callable by anyone (no onlyOwner) — always true for this contract.
• Owner-only setters (setTaxFeePercent, setBuyFee, setSellFee, excludeFromReward, includeInReward) — reachable once ownership is seized.
• A pool to flash-loan ROI from and to dump phantom ROI into (the BUSD/ROI pair).
• Working capital: only 5 BNB of seed (to buy the initial 100 k ROI used as a foothold). The ROI used to balloon _rOwned is flash-loaned and repaid in the same transaction, so the attack is effectively self-funded.

Attack walkthrough (with on-chain numbers from the trace)#

All figures are read directly from output.txt. ROI has 9 decimals; BUSD/WBNB have 18. The PancakeSwap Attacker contract is 0x7FA9385b… in the PoC (the historical attacker contract was 0x158af3…). The BUSD/ROI pair is reserve0 = ROI, reserve1 = BUSD.

Why the 99 % "tax" is the mint#

The attacker is excluded during steps 5–6, so the receive (step 5) credits its _rOwned with the full flash-loaned reflection amount, but the corresponding _tOwned increase is what the 1 %-delivered tokens reflect. On the send (step 6) only 1 % leaves. The other 99 % is "reflected" via _reflectFee — which shrinks _rTotal and thereby increases the token-value of the attacker's surviving _rOwned. When includeInReward then discards _tOwned and switches balanceOf to read _rOwned, that inflated reflected balance becomes ~3.99 M real, sellable ROI — none of which corresponds to tokens the attacker actually paid for.

Profit / loss accounting (BNB)#

The widely-reported headline loss is 157.98 BNB (~$44K) (the value extracted from victim liquidity, net of routing through two pools and fees). The PoC's own balance delta is the cleaner mechanical figure: +163.33 BNB, of which ~167.9 BNB came straight out of the BUSD/ROI pool's real reserves in exchange for tokens conjured from the reflection ledger.

Diagrams#

Sequence of the attack#

State evolution (BUSD/ROI pool ROI reserve)#

The flaw chain: access control + reflection bookkeeping#

Remediation#

1. Restore the onlyOwner modifier on transferOwnership. This is the single change that prevents the whole attack:
   SOLIDITYCopy

   function transferOwnership(address newOwner) public virtual onlyOwner {
       require(newOwner != address(0), "Ownable: new owner is the zero address");
       emit OwnershipTransferred(_owner, newOwner);
       _owner = newOwner;
   }
   

   Prefer inheriting OpenZeppelin's audited Ownable rather than a hand-rolled copy that can drop modifiers.
2. Reconcile _rOwned on re-inclusion. includeInReward must recompute and keep a consistent balance, not silently discard _tOwned. The correct SafeMoon-era fix recomputes _rOwned[account] = _tOwned[account] * _getRate() before clearing _tOwned, so the holder's real balance is preserved exactly across the exclude→include round-trip and no phantom tokens can be conjured.
3. Make reward-exclusion changes admin-gated behind a timelock, and never allow the same actor to flip exclusion state and execute a large self-transfer in the same transaction.
4. Decouple fee/branch logic from a single hard-coded pair. Maintain a set of recognized pairs (or detect AMM pairs generically) so fee-exemption logic cannot be sidestepped simply by routing through a different pool than the token's configured uniswapV2Pair.
5. Bound setTaxFeePercent. A 99 % reflection tax is never a legitimate operating value; cap the fee (e.g. require(taxFee <= 25)) so reflection accounting cannot be weaponized even by a compromised admin.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail under forge test's whole-project build):

_shared/run_poc.sh 2022-09-ROI_exp -vvvvv

• RPC: a BSC archive endpoint is required (fork block 21,143,795 is from Sept 2022). Most public BSC RPCs prune that state; use an archive provider.
• Result: [PASS] testExploit(); the attacker's BNB balance goes from 5 → 168.33 BNB.

Expected tail:

[End] Attacker BNB Balance:: 168.331704163647122410

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 26.24s
Ran 1 test suite ... 1 tests passed, 0 failed, 0 skipped (1 total tests)

References:

• BlockSec — https://twitter.com/BlockSecTeam/status/1567746825616236544
• CertiKAlert — https://twitter.com/CertiKAlert/status/1567754904663429123
• QuillAudits — "Decoding Ragnarok ($ROI) $44K Exploit" — https://medium.com/quillhash/decoding-ragnarok-online-invasion-44k-exploit-quillaudits-261b7e23b55

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-09-ROI_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: ROI_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "ROI Token Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.