Rust fixme 2 picoCTF 2025 Solution

Description

1. Step 1Borrow the string mutably

   Observation

   The call to decrypt fails on a type mismatch: the variable is passed as a shared reference to a function that modifies it. Both the parameter type and the call site need the mutable form.

   Change the function signature to accept &mut String and call it with &mut party_foul so the helper can append to the string.

   What didn't work first

   Tried: Adding .clone() at the call site to give the function its own copy of the string.

   Cloning quiets the type checker at the call site, but the function still takes an owned String rather than a mutable reference, so the signature is still wrong. Worse, every modification lands on the clone and is discarded when the call returns. The original is untouched and no flag appears.

   Tried: Changing only the call site to &mut party_foul without updating the function signature.

   Rust matches the reference type at the call site against the signature. Leave the signature on the shared reference and passing a mutable one is a mismatch. Change both together.

   Learn more

   Rust's ownership and borrowing system is the language's most distinctive feature and its primary mechanism for achieving memory safety without a garbage collector. Every value has exactly one owner. You can create references ("borrows") to a value, either many immutable references (&T) or exactly one mutable reference (&mut T) at a time, but never both simultaneously.

   When a function needs to modify a value owned by its caller, it must receive a &mut reference. Passing &T (immutable reference) to a function that tries to mutate the data is a compile-time error. This forces the programmer to be explicit about mutation intentions at every function boundary, a sharp contrast with C where any pointer can be silently used to modify data.

   This system prevents entire classes of bugs at compile time: use-after-free (the owner drops the value while a reference exists), data races (two threads holding mutable references simultaneously), and iterator invalidation (modifying a collection while iterating over it). These are among the most common and dangerous bugs in C and C++ codebases, and Rust eliminates them without runtime overhead.

2. Step 2Fix the early-return syntax

   Observation

   The error-check guard uses ret, which Rust reads as an unknown identifier rather than control flow. Write return so the function exits early when construction fails.

   The original code uses ret; instead of return; to exit early when the XORCryptor constructor fails. Change ret; to return;. The surrounding is_err() guard and res.unwrap() are already correct and compile fine once the borrow fixes in steps 1 and 3 are applied.

   What didn't work first

   Tried: Deleting the early-exit guard entirely instead of fixing the keyword.

   Delete the error guard and the code falls through to unwrap even when the constructor failed. Unwrapping an error panics, so the program crashes instead of printing the flag. The guard is right; only its keyword is wrong.

   Tried: Replacing ret; with break; or continue; since they also interrupt normal control flow.

   break and continue only work inside loops and are a compile error anywhere else. return is the one keyword that exits a function early, and here it takes no value, because the function returns unit.

   Learn more

   Rust's Result<T, E> type is an enum with two variants: Ok(T) for success and Err(E) for failure. It forces callers to explicitly handle both outcomes, unlike exceptions in Python or Java, which can be silently uncaught. The if let Ok(value) = result { ... } pattern is a concise way to handle the success case and implicitly ignore the error case.

   Other idiomatic ways to unwrap a Result include: .unwrap() (panics on Err, useful in tests and prototypes, dangerous in production), .expect("message") (panics with a custom message), .unwrap_or(default) (returns a default value on error), and the ? operator (propagates errors to the caller). Each has its place depending on how fatal the error is and whether the function itself returns a Result.

   XOR-based encryption is simple but instructive: the same operation (XOR with the key) both encrypts and decrypts, making it a symmetric cipher with trivial implementation. See stream ciphers in CTFs for how key reuse and short keys break this construction in practice. XOR is also the core operation inside ciphers like ChaCha20 and block-cipher modes like CTR and OFB.

   CTF relevance: this exact pattern is why naive XOR ciphers fall in seconds. The same key masks every block, so any known plaintext anywhere in the message immediately leaks the keystream and every other block at that offset decrypts for free. Real stream ciphers fix this by combining the key with a nonce + counter so the keystream never repeats; that nonce discipline is what separates a secure construction from a CTF-grade XOR.

3. Step 3Declare the string mutable with `let mut`

   Observation

   The compiler says the variable cannot be borrowed as mutable because it was not declared that way, pointing straight at the let binding. Add mut and the borrow from step 1 is legal.

   The compiler error reads cannot borrow 'party_foul' as mutable, as it is not declared as mutable. Change the binding to let mut party_foul = ... so the borrow on the previous step is allowed, then rerun cargo run to decrypt and print the flag.

   What didn't work first

   Tried: Fixing only the &mut in the function signature and call site without touching the let binding.

   Rust wants mutability declared at the binding as well as at each borrow. A mutable reference to an immutably bound variable is rejected outright. The let has to become let mut even when every borrow is already correct.

   Tried: Wrapping the variable in a RefCell or Cell to achieve interior mutability.

   RefCell and friends exist for mutating through a shared reference, usually inside data structures or around awkward ownership constraints. For a local variable in a single-threaded function, mut on the binding is the idiomatic answer, and RefCell only adds runtime cost and complexity.

   Learn more

   In Rust, variables are immutable by default. You must explicitly opt into mutability with the mut keyword: let mut x = 5;. This is the opposite of most languages and is a deliberate design choice; immutability makes code easier to reason about and prevents accidental state mutations. The compiler error "cannot borrow x as mutable, as it is not declared as mutable" is one of the most common Rust beginner errors and one of the most educational.

   Immutability by default also has performance implications: the compiler can make stronger aliasing assumptions for immutable data, potentially enabling more aggressive optimizations. In concurrent code, immutable data can be freely shared across threads without locks (Arc<T> instead of Arc<Mutex<T>>), simplifying concurrency logic significantly.

   The combination of skills this challenge reinforces (understanding mut, &mut references, and Result handling) covers a significant portion of Rust's learning curve. Developers who master these concepts find that the compiler becomes a powerful assistant that catches design mistakes before they become runtime bugs, making Rust code unusually reliable despite its initial steepness of learning.

Flag

This task reinforces Rust's borrowing rules, and Fixme 3 builds on the same pattern with a slightly larger project.