uups-checker 1.0.0

package/QUICK_START.md

@@ -0,0 +1,240 @@
+# Quick Start Guide - XFI Staking Exploit
+
+## TL;DR - Fastest Way to Test
+
+### Option 1: Remix (Easiest)
+
+1. **Open Remix**: https://remix.ethereum.org
+2. **Copy `RemixExploit.sol`** into Remix
+3. **Compile** with Solidity 0.6.0
+4. **Deploy** `SimpleXFIExploit` contract on your fork
+5. **Transfer XFI** tokens to the deployed contract
+6. **Call** `setupExploit()` to approve
+7. **Call** `executeExploit()` to run the attack
+8. **Call** `getResults()` to see the profit
+
+### Option 2: Foundry (For Automated Testing)
+
+```bash
+# Clone and setup
+git clone <your-repo>
+cd <your-repo>
+
+# Run the exploit test
+forge test --match-test testDoubleCountingExploit -vvv --fork-url <YOUR_RPC_URL>
+```
+
+## Detailed Remix Instructions
+
+### Prerequisites
+- MetaMask connected to a fork
+- Some XFI tokens (get from token holder or mint on fork)
+
+### Step-by-Step
+
+1. **Deploy the Exploit Contract**
+   ```
+   - Open Remix
+   - Create new file: RemixExploit.sol
+   - Paste the code
+   - Compile with 0.6.0
+   - Deploy SimpleXFIExploit
+   ```
+
+2. **Fund the Contract**
+   ```solidity
+   // From your account with XFI
+   xfi.transfer(exploitContractAddress, 2000000000000000000000); // 2000 XFI
+   ```
+
+3. **Setup**
+   ```
+   - Call setupExploit()
+   - This approves the staking contract
+   ```
+
+4. **Execute**
+   ```
+   - Call executeExploit()
+   - This runs the double-counting attack
+   ```
+
+5. **Check Results**
+   ```
+   - Call getResults()
+   - You should see profit > 0 if exploit worked
+   ```
+
+## What You'll See
+
+### Before Exploit
+```
+Balance: 2000 XFI
+Staked: 0 XFI
+Pending: 0 XFI
+```
+
+### After First Stake
+```
+Balance: 1000 XFI (1000 staked)
+Staked: 975 XFI (25 XFI fee)
+Pending: ~X XFI (depends on pool rewards)
+```
+
+### After Second Stake (BUG TRIGGERED)
+```
+Balance: 0 XFI (2000 staked)
+Staked: 1950 XFI (50 XFI total fees)
+Pending: ~2X XFI (DOUBLED!)
+```
+
+### After Claiming
+```
+Balance: 2X XFI (doubled rewards claimed)
+Staked: 1950 XFI
+Pending: 0 XFI
+Profit: X XFI (stolen from pool)
+```
+
+## Understanding the Bug
+
+### Normal Flow (Expected)
+```
+1. User stakes → pending rewards calculated
+2. Rewards added to remainder ONCE
+3. User claims → receives correct amount
+```
+
+### Buggy Flow (Actual)
+```
+1. User stakes → pendingReward() called
+   - Adds rewards to remainder (COUNT #1)
+2. Code adds owing to remainder (COUNT #2)
+3. User stakes again → pendingReward() called
+   - Adds rewards to remainder (COUNT #3)
+4. Code adds owing to remainder (COUNT #4)
+5. User claims → receives 2X rewards!
+```
+
+## Testing Scenarios
+
+### Scenario A: Simple Double-Counting
+```
+1. Pool has existing stakes
+2. Pool has rewards
+3. Attacker stakes once
+4. Attacker stakes again (triggers bug)
+5. Attacker claims doubled rewards
+```
+
+### Scenario B: First Staker Advantage
+```
+1. Pool is empty (totalStakes = 0)
+2. Attacker stakes first (pays 0% fee)
+3. Victim stakes second (pays 2.5% fee)
+4. Attacker saved 2.5%
+```
+
+### Scenario C: Complete Drain
+```
+1. Multiple users stake (pool has funds)
+2. Rewards accumulate
+3. Attacker stakes multiple times
+4. Each stake doubles pending rewards
+5. Attacker claims and drains pool
+```
+
+## Verification Checklist
+
+- [ ] Contract deployed successfully
+- [ ] XFI tokens transferred to contract
+- [ ] setupExploit() called successfully
+- [ ] executeExploit() called successfully
+- [ ] getResults() shows profit > 0
+- [ ] Pending rewards were doubled
+- [ ] Contract balance increased
+
+## Common Issues
+
+### "No XFI tokens in contract"
+**Solution**: Transfer XFI to the exploit contract first
+```solidity
+xfi.transfer(exploitAddress, amount);
+```
+
+### "Approval failed"
+**Solution**: Make sure contract has XFI balance before calling setupExploit()
+
+### "Need at least 2000 XFI"
+**Solution**: Transfer at least 2000 XFI to the contract
+
+### "No profit shown"
+**Solution**: 
+- Make sure pool has existing stakes
+- Make sure pool has rewards
+- Try adding rewards manually: `staking.ADDFUNDS(1000 * 10**18)`
+
+## Advanced: Multi-Step Demo
+
+For detailed step-by-step analysis, use `DetailedExploitDemo`:
+
+```solidity
+1. Deploy DetailedExploitDemo
+2. Transfer XFI to contract
+3. Call step0_approve()
+4. Call step1_firstStake(1000 * 10**18)
+5. Call step2_checkPending()
+6. Call step3_secondStake(1000 * 10**18)
+7. Call step4_claimRewards()
+8. Call getProof() to see the bug
+```
+
+## Expected Output
+
+### getProof() Result
+```
+pendingBeforeSecondStake: 500 XFI
+pendingAfterSecondStake: 1000 XFI
+difference: 500 XFI
+verdict: "BUG CONFIRMED: Pending rewards increased after staking!"
+```
+
+This proves the double-counting bug!
+
+## Contract Addresses
+
+- **XFI Token**: `0x5BEfBB272290dD5b8521D4a938f6c4757742c430`
+- **Staking Contract**: `0x5cD1C00a88822182733E3ac335863fcC9A1c0705`
+
+## Safety Notes
+
+⚠️ **IMPORTANT**:
+- This is for educational purposes on a FORK only
+- Do NOT run on mainnet
+- Do NOT steal real user funds
+- Report vulnerabilities responsibly
+
+## Next Steps
+
+After confirming the exploit:
+1. Document the findings
+2. Calculate potential impact
+3. Recommend fixes
+4. Suggest contract redeployment
+
+## Support
+
+If you encounter issues:
+1. Check you're on a fork (not mainnet)
+2. Verify contract addresses
+3. Ensure you have XFI tokens
+4. Check transaction logs for errors
+5. Review the audit report for details
+
+## Files Reference
+
+- `RemixExploit.sol` - Simple exploit for Remix
+- `XFIStakingExploit.sol` - Full exploit contract
+- `test/XFIStakingExploit.t.sol` - Foundry test
+- `EXPLOIT_INSTRUCTIONS.md` - Detailed instructions
+- `audits/XFIStaking-security-audit-20260324.md` - Full audit report

package/README.md

@@ -0,0 +1,238 @@
+# UUPS Checker
+
+A command-line tool to check UUPS and Transparent Proxy initialization status for whitehat security research.
+
+## Features
+
+- ✅ Detects UUPS vs Transparent Proxies
+- ✅ Checks initialization status of proxy and implementation
+- ✅ Shows owner/admin addresses
+- ✅ Displays contract balance
+- ✅ Supports multiple chains (ETH, BSC, Polygon, Arbitrum, Optimism, opBNB)
+- ✅ Color-coded output for easy reading
+- ✅ Works on Linux, macOS, and Android (Termux)
+
+## Prerequisites
+
+- [Foundry](https://book.getfoundry.sh/getting-started/installation) (for `cast` command)
+- `bc` (basic calculator - usually pre-installed)
+
+## Installation
+
+### Option 1: npm (Recommended)
+```bash
+npm install -g uups-checker
+```
+
+After installation, you can use either command:
+```bash
+ups <contract_address> [chain]
+# or
+uups-checker <contract_address> [chain]
+```
+
+### Option 2: From source
+```bash
+git clone https://github.com/yourusername/uups-checker
+cd uups-checker
+chmod +x bin/ups
+npm link
+```
+
+## Termux Installation (Android)
+
+1. Install Termux from [F-Droid](https://f-droid.org/en/packages/com.termux/) (NOT Google Play)
+
+2. Update packages and install dependencies:
+```bash
+pkg update && pkg upgrade
+pkg install git nodejs bc
+```
+
+3. Install Rust (required for Foundry):
+```bash
+pkg install rust
+```
+
+4. Install Foundry:
+```bash
+curl -L https://foundry.paradigm.xyz | bash
+source ~/.bashrc
+foundryup
+```
+
+5. Install uups-checker:
+```bash
+npm install -g uups-checker
+```
+
+6. Test it:
+```bash
+ups 0x8599068597fd27D87514CB90c42300c03a474084 bsc
+```
+
+## Usage
+
+```bash
+ups <contract_address> [chain]
+```
+
+### Examples
+
+```bash
+# Check on Ethereum mainnet (default)
+ups 0x1234...
+
+# Check on BSC
+ups 0x1234... bsc
+
+# Check on Polygon
+ups 0x1234... polygon
+
+# Check on opBNB
+ups 0x1234... opbnb
+
+# Check on Arbitrum
+ups 0x1234... arbitrum
+
+# Check on Optimism
+ups 0x1234... optimism
+```
+
+### Supported Chains
+
+- `eth` - Ethereum Mainnet (default)
+- `bsc` - Binance Smart Chain
+- `opbnb` - opBNB
+- `polygon` - Polygon
+- `arbitrum` - Arbitrum
+- `optimism` - Optimism
+
+## Output
+
+The tool provides:
+- Proxy type (UUPS or Transparent)
+- Implementation address
+- Owner/Admin address
+- Initialization status for BOTH proxy and implementation
+- Contract balance
+- Vulnerability assessment
+
+## Example Output
+
+```
+╔══════════════════════════════════════════╗
+║       UUPS INITIALIZATION CHECKER        ║
+║          Whitehat Bounty Tool            ║
+╚══════════════════════════════════════════╝
+
+[INFO] Checking: 0x8599...
+[INFO] Chain: bsc
+[INFO] Explorer: https://bscscan.com/address/0x8599...
+
+[1/5] Reading EIP-1967 implementation slot...
+[✓] Implementation: 0xd28A...
+[2/5] Checking if UUPS proxy...
+[✓] UUPS proxy detected!
+[3/5] Checking owner/admin...
+[✓] Owner/Admin: 0x1234...
+[4/5] Checking initialization status...
+[✓] Proxy: INITIALIZED
+[✓] Implementation: INITIALIZED
+[5/5] Checking balance...
+[✓] Balance: 0 ETH
+
+═══════════════════════════════════════════
+              FINAL VERDICT                
+═══════════════════════════════════════════
+Proxy Type:      UUPS
+Implementation:  0xd28A...
+Owner:           0x1234...
+Balance:         0 ETH
+Status:          ✓ INITIALIZED
+
+[SAFE] Proxy is properly configured
+```
+
+### Vulnerable Contract Example
+
+```
+[4/5] Checking initialization status...
+[!] Proxy: NOT INITIALIZED
+[!] Implementation: NOT INITIALIZED
+
+Status:          ✗ UNINITIALIZED
+
+[VULNERABLE] UUPS implementation is uninitialized!
+[EXPLOIT] Potential takeover vulnerability!
+
+Next steps:
+1. Try calling initialize() on the implementation
+2. Check if you can set yourself as owner
+3. Verify with: cast call 0x... "owner()(address)" --rpc-url ...
+```
+
+## Troubleshooting
+
+### Termux Issues
+
+If you get "command not found" errors:
+```bash
+# Reload your shell
+source ~/.bashrc
+
+# Or restart Termux
+```
+
+If Foundry installation fails:
+```bash
+# Make sure Rust is installed
+pkg install rust
+
+# Try installing Foundry again
+curl -L https://foundry.paradigm.xyz | bash
+```
+
+### RPC Issues
+
+If you get RPC errors, the default Infura endpoint might be rate-limited. You can modify the script to use your own RPC endpoints.
+
+## Publishing to npm (For Developers)
+
+1. Create a GitHub repository and push your code
+2. Update `package.json` with your GitHub URL
+3. Login to npm: `npm login`
+4. Publish: `npm publish`
+
+## Security Notice
+
+This tool is for security research and whitehat bounty hunting only. Always:
+- Get proper authorization before testing contracts
+- Report vulnerabilities responsibly through official channels (Immunefi, HackerOne, etc.)
+- Never exploit vulnerabilities for personal gain
+- Follow responsible disclosure practices
+
+## How It Works
+
+The tool checks:
+1. EIP-1967 implementation slot to detect proxies
+2. `proxiableUUID()` function to identify UUPS proxies
+3. Admin slot (0xb53127...) for Transparent Proxies
+4. Initialization status by checking storage slot 0 and owner functions
+5. Contract balance and ownership
+
+## License
+
+MIT
+
+## Contributing
+
+Pull requests are welcome! For major changes, please open an issue first.
+
+## Author
+
+Created for whitehat security researchers and bug bounty hunters.
+
+## Disclaimer
+
+This tool is provided as-is for educational and security research purposes. Use responsibly and ethically.

package/REAUDIT_MASTER_LIST.txt

@@ -0,0 +1,15 @@
+COMPLETE RE-AUDIT - ALL CONTRACTS
+Generated: March 28, 2026
+Total Contracts: 138
+
+RULES:
+- ONLY user-side exploits
+- NO admin exploits
+- NO cheatcodes in tests
+- VERIFY with forge test on mainnet fork
+- FETCH actual verified source code (not decompiled)
+- PROVE or DISPROVE each claimed exploit
+
+STATUS: STARTING SYSTEMATIC VERIFICATION
+========================================
+

package/RING_analysis.txt

@@ -0,0 +1,212 @@
+RING TOKEN (0x521ef54063148e5f15f18b9631426175cee23de2) - SECURITY ANALYSIS
+================================================================================
+
+TOKEN INFO:
+- Name: RING
+- Symbol: RING  
+- Compiler: v0.8.7+commit.e28d00a7
+- Optimization: Yes with 200 runs
+- Total Supply: 20,456,743 tokens
+- Deployed: Nov 19, 2021 (4+ years old)
+- Holders: 10,490
+
+CONTRACT TYPE: Node-as-a-Service (NaaS) token with dividend distribution
+
+================================================================================
+CRITICAL VULNERABILITIES - USER-SIDE EXPLOITS
+================================================================================
+
+1. OWNER CAN BLACKLIST ANY ADDRESS (CRITICAL)
+   - Function: blacklistMalicious(address account, bool value)
+   - Owner can blacklist ANY address at ANY time
+   - Blacklisted addresses CANNOT transfer tokens
+   - Blacklisted addresses CANNOT create nodes
+   - Blacklisted addresses CANNOT cashout rewards
+   - EXPLOIT: Owner can rug pull by blacklisting all holders
+
+2. OWNER CAN CHANGE ALL FEES (CRITICAL)
+   - updateRewardsFee(uint256 value)
+   - updateLiquiditFee(uint256 value)
+   - updateFuturFee(uint256 value)
+   - updateCashoutFee(uint256 value)
+   - updateRwSwapFee(uint256 value)
+   - NO MAXIMUM LIMITS on fees
+   - EXPLOIT: Owner can set fees to 100% and drain all transactions
+
+3. OWNER CAN CHANGE NODE PARAMETERS (CRITICAL)
+   - changeNodePrice(uint256 newNodePrice)
+   - changeRewardPerNode(uint256 newPrice)
+   - changeClaimTime(uint256 newTime)
+   - NO LIMITS on these values
+   - EXPLOIT: Owner can make nodes worthless by:
+     * Setting node price to 1000000000 tokens (impossible to buy)
+     * Setting reward per node to 0 (no rewards)
+     * Setting claim time to 999999999 (can never claim)
+
+4. OWNER CAN CHANGE CRITICAL ADDRESSES (CRITICAL)
+   - updateFuturWall(address payable wall)
+   - updateRewardsWall(address payable wall)
+   - Owner can redirect all fees to their own address
+   - EXPLOIT: Owner can drain all accumulated fees
+
+5. OWNER CAN CHANGE ROUTER (CRITICAL)
+   - updateUniswapV2Router(address newAddress)
+   - Can change DEX router to malicious contract
+   - EXPLOIT: Owner can route swaps through malicious contract
+
+6. PAYMENT SPLITTER VULNERABILITY (HIGH)
+   - Contract inherits PaymentSplitter
+   - release(address payable account) - anyone can trigger
+   - release(IERC20 token, address account) - anyone can trigger
+   - EXPLOIT: Attacker can drain payment splitter shares
+
+================================================================================
+HONEYPOT MECHANISMS
+================================================================================
+
+1. BLACKLIST TRAP
+   - Owner can blacklist addresses AFTER they buy
+   - Blacklisted users cannot sell or transfer
+   - This is a HONEYPOT mechanism
+
+2. FEE MANIPULATION
+   - Owner can increase fees to 100% AFTER users buy
+   - Users cannot sell without losing everything
+   - This is a HONEYPOT mechanism
+
+3. NODE PRICE MANIPULATION
+   - Owner can increase node price to impossible levels
+   - Users who bought nodes cannot create more
+   - Existing node holders get diluted
+
+================================================================================
+CENTRALIZATION RISKS
+================================================================================
+
+1. SINGLE OWNER CONTROL
+   - Owner has COMPLETE control over:
+     * Blacklisting
+     * All fees
+     * Node parameters
+     * Critical addresses
+     * Router address
+   - NO TIMELOCK
+   - NO MULTISIG
+   - NO GOVERNANCE
+
+2. NO RENOUNCE OWNERSHIP PROTECTION
+   - renounceOwnership() exists but owner can call it
+   - If owner renounces, contract becomes FROZEN
+   - No one can update parameters
+
+================================================================================
+NODE SYSTEM VULNERABILITIES
+================================================================================
+
+1. CENTRALIZED NODE REWARDS
+   - distributeRewards() controlled by owner
+   - Owner decides when rewards are distributed
+   - Owner can stop distributing rewards
+
+2. NODE CREATION FEES
+   - createNodeWithTokens() burns tokens from user
+   - Tokens go to contract, not burned
+   - Owner controls what happens to these tokens
+
+3. CASHOUT FEES
+   - cashoutReward() and cashoutAll() charge fees
+   - Fees go to futurUsePool (owner controlled)
+   - Owner can set cashout fee to 100%
+
+================================================================================
+SWAP AND LIQUIDITY VULNERABILITIES
+================================================================================
+
+1. SWAP MANIPULATION
+   - swapLiquify can be enabled/disabled by owner
+   - When enabled, contract auto-swaps tokens
+   - Owner controls swap thresholds
+   - EXPLOIT: Owner can manipulate when swaps happen
+
+2. LIQUIDITY PROVISION
+   - addLiquidity() sends LP tokens to address(0)
+   - LP tokens are BURNED
+   - This is actually GOOD (prevents owner from removing liquidity)
+
+3. AUTOMATED MARKET MAKER PAIRS
+   - setAutomatedMarketMakerPair() controlled by owner
+   - Owner can add/remove AMM pairs
+   - EXPLOIT: Owner can manipulate which pairs trigger fees
+
+================================================================================
+USER-SIDE EXPLOIT STRATEGIES
+================================================================================
+
+EXPLOIT 1: PAYMENT SPLITTER DRAIN
+1. Check if you are a payee in the payment splitter
+2. Call release(address(this)) to claim BNB share
+3. Call release(IERC20 token, address(this)) to claim token shares
+4. This is LEGITIMATE if you are a payee
+
+EXPLOIT 2: FRONT-RUN BLACKLIST
+1. Monitor owner transactions for blacklistMalicious() calls
+2. If you see your address being blacklisted, front-run with sell
+3. Sell all tokens before blacklist takes effect
+4. This requires MEV bot or fast monitoring
+
+EXPLOIT 3: FRONT-RUN FEE CHANGES
+1. Monitor owner transactions for fee update calls
+2. If fees are being increased, front-run with sell
+3. Sell before high fees take effect
+
+EXPLOIT 4: NODE REWARD TIMING
+1. Monitor distributeRewards() calls
+2. Create nodes right before distribution
+3. Cashout immediately after distribution
+4. This maximizes reward per time invested
+
+EXPLOIT 5: AVOID THIS TOKEN
+- This token is HEAVILY CENTRALIZED
+- Owner has COMPLETE control
+- High risk of rug pull via:
+  * Blacklisting all holders
+  * Setting fees to 100%
+  * Stopping reward distribution
+  * Changing node parameters to worthless values
+
+================================================================================
+LEGITIMATE CONCERNS (NOT EXPLOITABLE BY USERS)
+================================================================================
+
+1. Owner can rug pull at any time
+2. No protection against owner malicious actions
+3. No timelock on critical functions
+4. No multisig requirement
+5. No governance mechanism
+6. Payment splitter shares are fixed at deployment
+
+================================================================================
+CONCLUSION
+================================================================================
+
+RISK LEVEL: EXTREME
+
+This token is a CENTRALIZED HONEYPOT waiting to happen. The owner has:
+- Complete control over blacklisting
+- Complete control over all fees
+- Complete control over node parameters
+- Complete control over reward distribution
+- Complete control over critical addresses
+
+USER-EXPLOITABLE VULNERABILITIES:
+1. Payment splitter drain (if you are a payee)
+2. Front-running owner transactions (requires MEV)
+3. Timing node creation/cashout (minimal profit)
+
+RECOMMENDATION: AVOID THIS TOKEN
+- Too much centralization
+- Too many owner controls
+- High rug pull risk
+- Honeypot mechanisms present
+
+The only "exploit" is to NOT BUY THIS TOKEN.

package/RPC

@@ -0,0 +1,4 @@
+https://bsc-mainnet.infura.io/v3/db4d2c885bc946b691dbb3d5ef26d9e2
+https://bnb-mainnet.g.alchemy.com/v2/5IWkkFu-rS6plYHO9MLq-
+https://mainnet.infura.io/v3/db4d2c885bc946b691dbb3d5ef26d9e2
+https://eth-mainnet.g.alchemy.com/v2/5IWkkFu-rS6plYHO9MLq-