Rust fixme 3 picoCTF 2025 Solution

Description

1. Step 1

   Wrap the unsafe call

   Observation

   I noticed the compiler error call to unsafe function is unsafe and requires unsafe block and that lines 22 and 34 in src/main.rs already contained the correct unsafe { give_flag(); } structure but with // comment markers, which suggested that uncommenting those two lines was the exact fix the challenge was designed around.

   Uncomment the unsafe { ... } block (lines 22 and 34) so the compiler allows the call into the unsafe helper. No other code changes are needed.

   bash

   # Edit src/main.rs and remove the // before the unsafe block, e.g.:
   # unsafe {
   #     give_flag();
   # }

   Copied!

   What didn't work first

   Tried: Write a brand-new unsafe { give_flag(); } block instead of uncommenting the existing one

   The code compiles and runs, but if you add a duplicate call outside the structure the challenge expects, you may introduce a double-invocation or leave the original commented-out lines in place. The simpler correct approach is to remove the two // comment markers already in the file at lines 22 and 34, since the scaffold was intentionally written that way - no new code is required.

   Tried: Mark the give_flag function declaration itself as unsafe fn give_flag() to try to avoid needing an unsafe block at the call site

   Making the function declaration unsafe does not remove the need for an unsafe block; it makes the situation worse. Callers of an unsafe fn are still required to wrap every call in unsafe { ... }. The compiler error call to unsafe function is unsafe and requires unsafe block persists because the obligation falls on the caller, not the function signature. The fix is always at the call site.

   Learn more

   Rust's unsafe keyword is a signal to both the compiler and human readers that the enclosed code bypasses Rust's automatic safety guarantees. Inside an unsafe { } block, five additional operations become legal:

   1. Dereferencing a raw pointer (*const T / *mut T).
   2. Calling an unsafe function (including any C library through FFI).
   3. Reading from or writing to a mutable static.
   4. Implementing an unsafe trait (e.g. Send/Sync on a type that holds raw pointers).
   5. Accessing a field of a union (the compiler can't verify the active variant).

   The unsafe block does not disable the borrow checker or turn off other Rust features; it merely signals that the programmer has manually verified that the enclosed operations are sound. This creates a clear, searchable boundary: every unsafe in a Rust codebase is a location where memory safety was asserted by the programmer rather than the compiler, making audits focused and efficient. In contrast, C has no such boundary; any code can perform unsafe operations without annotation.

   Unsafe Rust is essential for system programming tasks. The canonical example is FFI into a C library: unsafe { libc::strlen(ptr) } calls the C standard library's strlen, which Rust marks unsafe because the caller must guarantee ptr points to a valid, NUL-terminated buffer. Other uses include OS kernel components, hardware memory-mapped registers, and zero-cost abstractions like custom allocators or lock-free data structures.

   The principle is to minimize unsafe surface area and encapsulate it behind safe abstractions. Concretely: std::fs::File::open() is a safe wrapper around an unsafe open(2) syscall and raw file-descriptor manipulation. The stdlib author wrote and audited the unsafe internals, then exposed an API that callers can use without ever typing unsafe themselves. Most application code stays entirely safe by leaning on those wrappers.

2. Step 2

   Rebuild and run

   Observation

   I noticed that the only obstacle was the missing unsafe block and that no other logic or algorithm needed to change, which suggested that a single cargo run after the edit would compile cleanly and print the flag immediately.

   Re-run cargo run and the binary now prints the picoCTF flag immediately.

   Learn more

   Cargo is Rust's integrated build system and package manager. cargo run compiles the project (in debug mode by default) and immediately executes the resulting binary. cargo build --release produces an optimized binary without running it. The distinction matters for performance-sensitive code: debug builds include overflow checks and backtraces but run slowly; release builds apply full LLVM optimization passes.

   Cargo's dependency management (via Cargo.toml and Cargo.lock) is one of Rust's major ergonomic advantages over C/C++. Adding a dependency is as simple as listing it under [dependencies], and Cargo fetches, compiles, and links it automatically. The Cargo.lock file pins exact versions of all dependencies (including transitive ones), ensuring reproducible builds, a critical property for security-sensitive software supply chains.

   The three Fixme challenges collectively introduce the most common Rust beginner stumbling blocks: syntax rules, borrowing, and unsafe. These skills translate directly to reading real Rust security tooling; many modern fuzzing frameworks (cargo-fuzz), memory-safe rewrites of critical utilities (ripgrep, fd, bat), and security research tools are written in Rust. Understanding the basics opens up a growing ecosystem of high-quality software.

Flag

Rust requires explicit `unsafe` blocks around code that might violate safety guarantees, even when the code was provided by the challenge.