Rust fixme 2 picoCTF 2025 Solution

Description

1. Step 1

   Borrow the string mutably

   Observation

   I noticed the compiler rejected the call to decrypt with a type mismatch because party_foul was passed as &String to a function that modifies its argument, which suggested the parameter type and call site both needed to be changed to &mut String and &mut party_foul.

   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 satisfies the type checker at the call site, but the function still receives an owned String rather than a mutable reference, so the signature must also change. More importantly, any appends or modifications the function makes apply to the clone and are discarded after the call returns - the original variable in main is untouched and the flag never 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 type declared in the function signature. If the signature still says &String, passing &mut party_foul is a type mismatch and the compiler rejects it. Both the signature and the call site must be updated 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 2

   Fix the early-return syntax

   Observation

   I noticed the source file used ret; inside the error-check guard, which Rust treats as an unknown identifier rather than a control-flow keyword, and this suggested renaming it to the correct return; keyword so the function can exit early when XORCryptor 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.

   Removing the if res.is_err() { ret; } block means the code falls through to res.unwrap() even when the XORCryptor constructor failed. Unwrapping an Err value causes a panic at runtime, so the program crashes instead of printing the flag. The guard exists for good reason - it just uses a non-existent keyword that must be spelled out in full.

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

   break and continue are only valid inside loops; using them outside a loop is a compile-time error. return is the only keyword that exits the enclosing function early. In this context, return; with no value is correct because the function returns the unit type ().

   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 3

   Declare the string mutable with `let mut`

   Observation

   I noticed the compiler error explicitly stated cannot borrow 'party_foul' as mutable, as it is not declared as mutable, which pointed directly at the let party_foul binding and indicated that adding mut to the declaration was the final fix needed to allow the &mut borrow set up in step 1.

   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 requires mutability to be declared at the variable's binding site as well as at each borrow. A &mut reference to an immutably-bound variable is rejected by the compiler with the message 'cannot borrow as mutable, as it is not declared as mutable'. The let declaration must become let mut even if &mut is already correct everywhere else.

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

   Interior mutability types like RefCell exist for cases where you need to mutate through a shared &T reference - typically in data structures or when working around ownership constraints in complex code. For a simple local variable in a single-threaded function, adding mut to the let binding is the correct and idiomatic solution. RefCell adds runtime overhead and complexity that is completely unnecessary here.

   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.