uups-checker 1.0.0

package/audits/UnknownToken-decompiled-security-audit-20260324.md

@@ -0,0 +1,647 @@
+# Unknown Token (Decompiled) Security Audit Report
+
+**Contract**: Unknown ERC20 Token (Decompiled Bytecode)  
+**Type**: ERC20 Token with Minting, Burning, Pausing, Capped Supply, Role-Based Access Control  
+**Compiler**: Solidity 0.6.6  
+**Decompiled**: March 12, 2026  
+**Audit Date**: March 24, 2026  
+**Auditor**: Kiro AI Security Analysis  
+
+---
+
+## Executive Summary
+
+**Risk Level**: 🔴 **CRITICAL** (Arbitrary Cap Manipulation)
+
+This is a decompiled ERC20 token based on OpenZeppelin's ERC20PresetMinterPauser with a capped supply mechanism. However, it contains a **CRITICAL VULNERABILITY** that allows MINTER_ROLE holders to arbitrarily change the supply cap, effectively making the "capped" supply meaningless.
+
+**Key Characteristics**:
+1. **CRITICAL FLAW**: `changeCap()` function allows unlimited cap increases
+2. **ROLE-BASED**: Uses OpenZeppelin AccessControl (MINTER_ROLE, PAUSER_ROLE, DEFAULT_ADMIN_ROLE)
+3. **PAUSABLE**: Can pause all transfers
+4. **MINTABLE**: MINTER_ROLE can mint new tokens
+5. **BURNABLE**: Anyone can burn their own tokens
+6. **CAPPED**: Has a supply cap (but it's bypassable via changeCap)
+
+**Purpose**: Appears to be a managed token with supply controls, but the controls are broken.
+
+---
+
+## Contract Overview
+
+**Token Details**:
+- **Name**: Unknown (stored in `_name`)
+- **Symbol**: Unknown (stored in `_symbol`)
+- **Decimals**: Stored in `_decimals` (likely 18)
+- **Total Supply**: Variable (mintable up to cap)
+- **Cap**: Variable (can be changed by MINTER_ROLE)
+
+**Architecture**:
+- Based on OpenZeppelin ERC20PresetMinterPauser
+- Custom `changeCap()` function added
+- Role-based access control
+- Pausable transfers
+- Capped supply (but bypassable)
+
+---
+
+## CRITICAL VULNERABILITIES
+
+### 🔴 CRITICAL #1: Arbitrary Supply Cap Manipulation
+
+**Severity**: CRITICAL  
+**Function**: `changeCap(uint256)`  
+**Impact**: Complete bypass of supply cap mechanism
+
+**Vulnerable Code**:
+```solidity
+function changeCap(uint256 varg0) public payable { 
+    require(msg.data.length - 4 >= 32);
+    require(bool(_getRoleAdmin[keccak256('MINTER_ROLE')].field1[msg.sender]), 
+            Error('ERC20PresetMinterPauser: must have minter role to mint'));
+    _cap = varg0;  // ❌ NO VALIDATION - Can set to ANY value
+}
+```
+
+**The Problem**:
+1. MINTER_ROLE can call `changeCap()` with ANY value
+2. No check that new cap >= current supply
+3. No check that new cap >= old cap
+4. No maximum cap limit
+5. Can set cap to `type(uint256).max` (infinite supply)
+6. Can even set cap BELOW current supply (breaks invariants)
+
+**Attack Scenario**:
+```solidity
+// Initial state: cap = 1,000,000 tokens
+// Current supply: 500,000 tokens
+
+// Attacker with MINTER_ROLE:
+changeCap(type(uint256).max);  // Set cap to maximum uint256
+mint(attacker, 1e30);  // Mint 1 trillion trillion tokens
+// Supply cap is now meaningless
+```
+
+**Impact**:
+- **UNLIMITED INFLATION**: Minter can create infinite tokens
+- **RUG PULL RISK**: Minter can mint unlimited tokens and dump
+- **FALSE ADVERTISING**: Token claims to be "capped" but isn't
+- **INVESTOR DECEPTION**: Users think supply is limited
+- **COMPLETE CENTRALIZATION**: Minter has god-mode powers
+
+**Why This is Critical**:
+The entire purpose of a "capped" token is to limit supply. This function completely defeats that purpose. It's like having a "fixed supply" token where the owner can change the supply at will.
+
+---
+
+### 🔴 CRITICAL #2: Cap Can Be Set Below Current Supply
+
+**Severity**: HIGH  
+**Function**: `changeCap(uint256)`  
+**Impact**: Breaks contract invariants, potential DoS
+
+**The Problem**:
+```solidity
+function changeCap(uint256 varg0) public payable { 
+    _cap = varg0;  // ❌ No check: varg0 >= _totalSupply
+}
+```
+
+**Attack Scenario**:
+```solidity
+// Current state:
+// _totalSupply = 1,000,000
+// _cap = 2,000,000
+
+// Malicious/incompetent MINTER_ROLE:
+changeCap(500000);  // Set cap BELOW current supply
+
+// Now: _totalSupply (1M) > _cap (500K)
+// This breaks the fundamental invariant: totalSupply <= cap
+
+// Result: No more minting possible (DoS)
+mint(user, 1);  // ❌ REVERTS: "ERC20Capped: cap exceeded"
+```
+
+**Impact**:
+- **DENIAL OF SERVICE**: No more minting possible
+- **BROKEN INVARIANTS**: totalSupply > cap (should never happen)
+- **LOGIC ERRORS**: Contract in invalid state
+- **POTENTIAL EXPLOITS**: Other functions may assume totalSupply <= cap
+
+---
+
+## HIGH SEVERITY ISSUES
+
+### 🟠 HIGH #1: Extreme Centralization - MINTER_ROLE
+
+**Severity**: HIGH  
+**Impact**: Complete control over token supply
+
+**The Problem**:
+MINTER_ROLE can:
+1. Mint unlimited tokens (via changeCap + mint)
+2. Change the supply cap arbitrarily
+3. Mint to any address
+4. Dilute all holders
+
+**This is essentially an "owner can mint infinite tokens" vulnerability.**
+
+---
+
+### 🟠 HIGH #2: Extreme Centralization - PAUSER_ROLE
+
+**Severity**: HIGH  
+**Impact**: Can freeze all token transfers
+
+**The Problem**:
+```solidity
+function pause() public payable { 
+    require(bool(_getRoleAdmin[keccak256('PAUSER_ROLE')].field1[msg.sender]), 
+            Error('ERC20PresetMinterPauser: must have pauser role to pause'));
+    require(!_paused, Error('Pausable: paused'));
+    _paused = 1;
+    emit Paused(msg.sender);
+}
+```
+
+PAUSER_ROLE can:
+1. Pause all transfers indefinitely
+2. Lock all tokens (no one can transfer)
+3. Prevent users from selling
+4. Manipulate markets (pause before bad news)
+
+**Attack Scenario**:
+```solidity
+// PAUSER_ROLE sees users trying to sell
+pause();  // Freeze all transfers
+// Users cannot sell, price crashes
+unpause();  // Unfreeze after damage done
+```
+
+---
+
+### 🟠 HIGH #3: Role Admin Can Grant Themselves Any Role
+
+**Severity**: HIGH  
+**Impact**: Single point of failure
+
+**The Problem**:
+DEFAULT_ADMIN_ROLE can:
+1. Grant themselves MINTER_ROLE
+2. Grant themselves PAUSER_ROLE
+3. Grant any role to any address
+4. Revoke roles from others
+
+**This means a single compromised admin key = complete control.**
+
+---
+
+## MEDIUM SEVERITY ISSUES
+
+### 🟡 MEDIUM #1: No Role Renunciation for Admin
+
+**Severity**: MEDIUM  
+**Impact**: Cannot fully decentralize
+
+**The Problem**:
+- DEFAULT_ADMIN_ROLE cannot be renounced for all roles
+- No way to make the contract fully decentralized
+- Admin always has ultimate control
+
+---
+
+### 🟡 MEDIUM #2: No Events for Cap Changes
+
+**Severity**: MEDIUM  
+**Impact**: Lack of transparency
+
+**The Problem**:
+```solidity
+function changeCap(uint256 varg0) public payable { 
+    _cap = varg0;  // ❌ No event emitted
+}
+```
+
+**Impact**:
+- Users cannot easily detect cap changes
+- No on-chain audit trail
+- Harder to monitor for malicious behavior
+
+---
+
+## Code Analysis
+
+### Contract Structure
+
+This appears to be based on OpenZeppelin's ERC20PresetMinterPauser with a custom `changeCap()` function added:
+
+```solidity
+// Standard OpenZeppelin components:
+- ERC20 (base token functionality)
+- AccessControl (role-based permissions)
+- ERC20Pausable (pausable transfers)
+- ERC20Capped (supply cap - but broken by changeCap)
+
+// Custom addition:
+- changeCap() function (CRITICAL VULNERABILITY)
+```
+
+---
+
+### Key Functions Analysis
+
+#### 1. mint() - Controlled Minting
+
+```solidity
+function mint(address to, uint256 amount) public payable { 
+    require(bool(_getRoleAdmin[keccak256('MINTER_ROLE')].field1[msg.sender]), 
+            Error('ERC20PresetMinterPauser: must have minter role to mint'));
+    require(to, Error('ERC20: mint to the zero address'));
+    0x144c(amount, to, 0);  // Checks pause and cap
+    v0 = _SafeAdd(amount, _totalSupply);
+    _totalSupply = v0;
+    v1 = _SafeAdd(amount, _balanceOf[to]);
+    _balanceOf[to] = v1;
+    emit Transfer(0, to, amount);
+}
+```
+
+**Analysis**:
+- ✅ Requires MINTER_ROLE
+- ✅ Checks zero address
+- ✅ Checks cap (via 0x144c)
+- ✅ Checks pause status
+- ❌ But cap can be changed arbitrarily via changeCap()
+
+---
+
+#### 2. changeCap() - THE CRITICAL VULNERABILITY
+
+```solidity
+function changeCap(uint256 varg0) public payable { 
+    require(msg.data.length - 4 >= 32);
+    require(bool(_getRoleAdmin[keccak256('MINTER_ROLE')].field1[msg.sender]), 
+            Error('ERC20PresetMinterPauser: must have minter role to mint'));
+    _cap = varg0;  // ❌❌❌ CRITICAL: No validation
+}
+```
+
+**What's Wrong**:
+1. ❌ No check: `varg0 >= _totalSupply`
+2. ❌ No check: `varg0 >= _cap` (can decrease)
+3. ❌ No maximum cap limit
+4. ❌ No event emitted
+5. ❌ No timelock or delay
+6. ❌ No multi-sig requirement
+7. ❌ Can be called repeatedly
+
+**This function should NOT exist, or should have strict validation.**
+
+---
+
+#### 3. pause() / unpause() - Transfer Control
+
+```solidity
+function pause() public payable { 
+    require(bool(_getRoleAdmin[keccak256('PAUSER_ROLE')].field1[msg.sender]), 
+            Error('ERC20PresetMinterPauser: must have pauser role to pause'));
+    require(!_paused, Error('Pausable: paused'));
+    _paused = 1;
+    emit Paused(msg.sender);
+}
+
+function unpause() public payable { 
+    require(bool(_getRoleAdmin[keccak256('PAUSER_ROLE')].field1[msg.sender]), 
+            Error('ERC20PresetMinterPauser: must have pauser role to unpause'));
+    require(_paused, Error('Pausable: not paused'));
+    _paused = 0;
+    emit Unpaused(msg.sender);
+}
+```
+
+**Analysis**:
+- ✅ Proper role checks
+- ✅ Emits events
+- ✅ State validation
+- ❌ But gives PAUSER_ROLE too much power
+
+---
+
+#### 4. burn() / burnFrom() - Token Burning
+
+```solidity
+function burn(uint256 amount) public payable { 
+    0x1290(amount, msg.sender);
+}
+
+function burnFrom(address account, uint256 amount) public payable { 
+    v0 = _SafeSub('ERC20: burn amount exceeds allowance', amount, _allowance[account][msg.sender]);
+    0xcca(v0, msg.sender, account);
+    0x1290(amount, account);
+}
+```
+
+**Analysis**:
+- ✅ Anyone can burn their own tokens
+- ✅ Can burn from others with allowance
+- ✅ Proper checks
+- ✅ Reduces total supply
+
+---
+
+### Internal Function Analysis
+
+#### 0x144c() - Before Token Transfer Hook
+
+```solidity
+function 0x144c(uint256 varg0, uint256 varg1, address varg2) private { 
+    require(!_paused, Error('ERC20Pausable: token transfer while paused'));
+    if (varg2) {
+        return ;
+    } else {
+        v0 = _SafeAdd(varg0, _totalSupply);
+        require(v0 <= _cap, Error('ERC20Capped: cap exceeded'));
+        return ;
+    }
+}
+```
+
+**Analysis**:
+- ✅ Checks pause status
+- ✅ Checks cap on minting (when varg2 == 0)
+- ✅ Proper validation
+- ❌ But cap can be changed via changeCap()
+
+---
+
+## Risk Assessment
+
+### Rug Pull Risk: 🔴 CRITICAL
+- MINTER_ROLE can mint unlimited tokens via changeCap()
+- Can dump infinite tokens on market
+- Can dilute all holders to zero
+- **This is a rug pull waiting to happen**
+
+### Centralization Risk: 🔴 CRITICAL
+- DEFAULT_ADMIN_ROLE has complete control
+- MINTER_ROLE can create infinite supply
+- PAUSER_ROLE can freeze all transfers
+- Single compromised key = total loss
+
+### Smart Contract Risk: 🔴 CRITICAL
+- changeCap() function is fundamentally broken
+- No validation on cap changes
+- Can set cap below current supply
+- Breaks contract invariants
+
+### Market Risk: 🔴 CRITICAL
+- "Capped supply" is false advertising
+- Supply can be inflated at any time
+- Investors are being deceived
+- Regulatory risk (securities fraud?)
+
+---
+
+## Comparison to Other Tokens
+
+### vs. DomiToken (Previous Audit)
+- ❌ **MUCH WORSE**: DomiToken has no owner, this has god-mode roles
+- ❌ **MUCH WORSE**: DomiToken has fixed supply, this has unlimited
+- ❌ **MUCH WORSE**: DomiToken is safe, this is a rug pull risk
+
+### vs. PAAL AI (Previous Audit)
+- ❌ **SIMILAR**: Both have hidden backdoors
+- ❌ **SIMILAR**: Both have centralization risks
+- ❌ **WORSE**: This can inflate supply, PAAL "only" had tax manipulation
+
+### vs. XFI Staking (Previous Audit)
+- ❌ **DIFFERENT**: XFI Staking had double-counting bug, this has intentional backdoor
+- ❌ **WORSE**: This affects the token itself, not just staking
+
+---
+
+## Exploitability Assessment
+
+### Can MINTER_ROLE Exploit This?
+
+**YES - EASILY**:
+
+```solidity
+// Step 1: Increase cap to maximum
+changeCap(type(uint256).max);
+
+// Step 2: Mint unlimited tokens
+mint(attacker, 1e30);  // 1 trillion trillion tokens
+
+// Step 3: Dump on market
+// Sell tokens, crash price, profit
+```
+
+**This is trivial to exploit and requires no special skills.**
+
+---
+
+### Can PAUSER_ROLE Exploit This?
+
+**YES**:
+
+```solidity
+// Market manipulation:
+pause();  // Freeze all transfers
+// Wait for panic, price crashes
+unpause();  // Unfreeze
+// Buy cheap tokens
+```
+
+---
+
+### Can DEFAULT_ADMIN_ROLE Exploit This?
+
+**YES - COMPLETE CONTROL**:
+
+```solidity
+// Grant themselves all roles
+grantRole(MINTER_ROLE, admin);
+grantRole(PAUSER_ROLE, admin);
+
+// Now has all powers
+changeCap(type(uint256).max);
+mint(admin, 1e30);
+pause();
+// Complete control
+```
+
+---
+
+## Recommendations
+
+### CRITICAL - Fix changeCap()
+
+**Option 1: Remove the function entirely** (RECOMMENDED)
+```solidity
+// Delete changeCap() function
+// Make cap immutable after deployment
+```
+
+**Option 2: Add strict validation**
+```solidity
+function changeCap(uint256 newCap) public {
+    require(hasRole(MINTER_ROLE, msg.sender), "Must have minter role");
+    require(newCap >= _totalSupply, "Cap cannot be below current supply");
+    require(newCap >= _cap, "Cap can only increase");
+    require(newCap <= _cap * 2, "Cap cannot more than double");
+    require(block.timestamp >= lastCapChange + 30 days, "Must wait 30 days");
+    
+    uint256 oldCap = _cap;
+    _cap = newCap;
+    lastCapChange = block.timestamp;
+    
+    emit CapChanged(oldCap, newCap, msg.sender);
+}
+```
+
+**Option 3: Use timelock + multi-sig**
+```solidity
+// Require 2-of-3 multi-sig + 7 day timelock for cap changes
+```
+
+---
+
+### HIGH - Reduce Centralization
+
+1. **Use Multi-Sig for Admin Roles**
+   - Require 3-of-5 multi-sig for DEFAULT_ADMIN_ROLE
+   - Require 2-of-3 multi-sig for MINTER_ROLE
+
+2. **Add Timelocks**
+   - 7-day timelock for role grants
+   - 3-day timelock for pause
+   - 30-day timelock for cap changes
+
+3. **Limit Minting**
+   - Max mint per transaction
+   - Max mint per day
+   - Cooldown between mints
+
+4. **Add Transparency**
+   - Emit events for all role changes
+   - Emit events for cap changes
+   - Emit events for pause/unpause
+
+---
+
+### MEDIUM - Add Safety Features
+
+1. **Emergency Stop**
+   - Separate emergency pause (different from regular pause)
+   - Requires multiple signatures
+   - Time-limited (auto-unpause after 7 days)
+
+2. **Role Renunciation**
+   - Allow admin to renounce all roles
+   - Make contract fully decentralized
+
+3. **Audit Trail**
+   - Log all privileged operations
+   - Make role changes transparent
+
+---
+
+## Code Quality Assessment
+
+**Rating**: 🟡 **MEDIUM** (Standard OpenZeppelin, but with critical custom addition)
+
+**Strengths**:
+- ✅ Based on OpenZeppelin (trusted base)
+- ✅ Uses AccessControl (role-based permissions)
+- ✅ Pausable (emergency stop)
+- ✅ Burnable (deflationary option)
+- ✅ Proper SafeMath (Solidity 0.6.6)
+
+**Critical Weaknesses**:
+- ❌ changeCap() function is fundamentally broken
+- ❌ No validation on cap changes
+- ❌ Extreme centralization
+- ❌ False advertising (claims to be "capped")
+
+---
+
+## Conclusion
+
+**VERDICT**: 🔴 **DO NOT USE - CRITICAL VULNERABILITIES**
+
+This token has a **CRITICAL VULNERABILITY** that allows MINTER_ROLE to arbitrarily change the supply cap, effectively giving them the ability to mint unlimited tokens. This completely defeats the purpose of having a "capped" supply.
+
+**Key Issues**:
+1. 🔴 **CRITICAL**: changeCap() allows unlimited supply inflation
+2. 🔴 **CRITICAL**: Cap can be set below current supply (breaks invariants)
+3. 🔴 **HIGH**: Extreme centralization (MINTER_ROLE = god mode)
+4. 🔴 **HIGH**: PAUSER_ROLE can freeze all transfers
+5. 🔴 **HIGH**: Single admin key = complete control
+
+**For Users**: **DO NOT BUY THIS TOKEN**
+- The "capped supply" is false advertising
+- MINTER_ROLE can inflate supply at any time
+- High rug pull risk
+- Extreme centralization
+- No investor protection
+
+**For Developers**: **DO NOT DEPLOY THIS CONTRACT**
+- Remove changeCap() function entirely
+- Or add strict validation + timelock + multi-sig
+- Reduce centralization
+- Add transparency features
+- Consider making cap immutable
+
+**Exploitability**: **TRIVIAL**
+- Any MINTER_ROLE holder can exploit this
+- No special skills required
+- Can mint unlimited tokens in seconds
+- High probability of exploitation
+
+**Comparison**: This is **one of the most dangerous tokens** we've audited, similar to PAAL AI in terms of centralization risk, but worse because it affects the core token supply mechanism.
+
+---
+
+**Audit Complete** ✓
+
+**RECOMMENDATION**: 🔴 **DO NOT USE - CRITICAL VULNERABILITIES**
+
+This token should not be used in its current form. The changeCap() function is a critical vulnerability that allows unlimited supply inflation. If you encounter this token, **DO NOT INVEST**.
+
+---
+
+## Technical Details
+
+### Function Signatures
+
+Key functions identified:
+- `0x800edb9d` = `changeCap(uint256)` ⚠️ CRITICAL VULNERABILITY
+- `0x40c10f19` = `mint(address,uint256)`
+- `0x8456cb59` = `pause()`
+- `0x3f4ba83a` = `unpause()`
+- `0x42966c68` = `burn(uint256)`
+- `0x79cc6790` = `burnFrom(address,uint256)`
+- `0x355274ea` = `cap()`
+
+### Roles
+
+- `DEFAULT_ADMIN_ROLE` = `0x00` (bytes32(0))
+- `MINTER_ROLE` = `keccak256("MINTER_ROLE")`
+- `PAUSER_ROLE` = `keccak256("PAUSER_ROLE")`
+
+### Storage Layout
+
+- STORAGE[0] = Role data (AccessControl)
+- STORAGE[1] = Balances mapping
+- STORAGE[2] = Allowances mapping
+- STORAGE[3] = Total supply
+- STORAGE[4] = Token name
+- STORAGE[5] = Token symbol
+- STORAGE[6] = Decimals (byte 0) + Paused (byte 1)
+- STORAGE[7] = Cap ⚠️ Can be changed arbitrarily
+
+---
+
+**This is a high-risk token with critical vulnerabilities. Avoid at all costs.** 🔴