DEV Community: Lozi

Why Rust allows many readers but only One Writer

Lozi — Tue, 14 Jul 2026 16:53:23 +0000

While programming in Rust, we stumble across many rules that, at first, are really unfamiliar to begin with.
However, there's a certain rule that, while programming, I face the most: Multiple Mutable References.
It usually happens when you try to pass a variable into a function as a reader, and then pass that same variable as a writer. C or C++ will happily compile and let you run the code, but Rust throws a massive red error in your face!!!.
In order to understand why this happens, we have to look at how C programmers dealt with it.

Pointers

Back in the old days, programming in C was like having everything at your disposal. A pointer was just an address in memory, nothing else. If you wanted to have ten different pointers all pointing at the same byte of RAM (Aliasing) and you wanted three of them for example to simultaneously try to edit that byte (Mutation), the C compiler would say, "Whatever you say, Boss".

But this absolute freedom of memory management created LOTS of bugs that kept devs awake for days!!!

Imagine processing bank transactions: Two Threads (workers), Alice and Bob are running at the exact same time:

Alice is reading your account balance in order to deposit $70
Bob is reading your account balance because you just bought a $30 game

Because C places almost no restrictions on aliasing and mutation, multiple parts of a program can read from and write to the same memory simultaneously. As a result, both workers read your balance and see $100.

Alice says: "Alright: $100 + $70 = $170". And then Alice prepares to write $170
Bob says: "$100 - $30 = $70". And then Bob prepares to write $70

They both put their new numbers into the database. So whichever one writes a millisecond slower OVERWRITES the other. It can make your $70 profit vanish into the void (This is called Data Race)

The Single-Thread

Even if you don't use multi threading. C would still shoot you at your own feet. Imagine like you are reading a list of names, right?. Then you have a pointer looking at the first name (Aliasing). But further down your code, you accidentally tell the program to add a hundred thousand new names to that list (Mutation).

The computer realizes the current memory array is too small to hold a hundred thousand new names, so what it does it silently pick up the entire list, moves it into a bigger space in RAM, and DELETES the old one. But your original reading pointer doesn't know that the program did that!!!!. So then It tries to read the next name and reads literal deleted garbage, causing the program to instantly crash. This behavior is called Iterator Invalidation.

Solution

For decades, language researchers studied these crashes and behaviors. And eventually they realized something profound:

Aliasing by itself is literally harmless: Like if you have a million threads reading a list simultaneously. If nobody changes throughout that time, then nothing breaks.
Mutation by itself is also harmless: If only Bob is allowed in the room to edit the bank account, then the math is always perfect. The crashes only happened when Aliasing and Mutation were combined.

The XOR Gate

When Graydon Hoare started building Rust, one of his goals was to eliminate an entire class of memory safety bugs before a program could even run. Rust achieves this by enforcing a fundamental principle at compile time, commonly summarized as Aliasing XOR Mutation.

Just like the XOR logic gate many of us encounter in our first digital logic course, a piece of data can have aliases (multiple shared references) or it can be mutated (through one exclusive mutable reference), but never both at the same time.

If you didn't get it at first, I'll give you an analogy from a professor that I had at university:

"You can have your wife in the house, or your lover when she's not inside, but not at the same time or it'll be a disaster".

That's essentially what Rust enforces. You can have many readers, or one writer—but never both at the same time.

Option A (Aliasing): You can have unlimited read-only references (&name). But the moment you create one, the compiler locks the data and no one is allowed to mutate it until everyone is done READING.
Option B (Mutation): You can have exactly one mutable reference (&mut name). But in order to get it, you must be THE ONLY POINTER int he room!!.

Global Variables in Rust & C/C++

Lozi — Sun, 12 Jul 2026 20:30:44 +0000

What's a global variable?
A global variable is a variable with global scope, meaning that it visible throughout the program, unless it's shadowed. In compiled languages, global variables are generally static, which means their lifetime is the entire runtime of the program.

Which one's programming languages are actually compiled?
Is a programming language that is usually implemented with a compiler rather than an interpreter.

Why we use them?
Global variables are used to pass information between sections of code that do not share a relation like concurrent threads and signal handlers. Languages (Including C) defines implicitly a namespace for earch global variable inside a certain file so that eliminates most of the problems seen with languages with a global namespace, though problems may persist without their proper encapsulation. Without a proper locking (like mutex) code, using global variables will not be thread-safe except for read only values in protected memory.

Interesting, so using global variables in parallel programs is not the best idea UNLESS we use a proper locking (which is mutex)...
Rust is known as a safe programming language, therefore MAYBE this can be the cause of why I can't declare a global variable that can be edited at runtime: BECAUSE IT'S RISKY.
But my program isn't parallel, then why I can't do it then?

Let's investigate
I stumble upon a thread from stack overflow from a person who had somewhat the same problem that I'm facing currently, and the answer to that manner was to use the "unsafe" type in order to stop fighting with the compiler, but at a certain cost: "Unless your program wouldn't be in te future concurrent, then is perfectly fine to use the unsafe keyword".

But I want in the future make this decryption tool concurrent, so then I can learn more about concurrency in Rust. Thus, I think I might make the global variable "Safe".

But how do we make it "Safe"?
Let's investigate:
I stumble upon a really GOOD diagram explaining what to use depending on what do you wanna do with your global variable in Rust. You can find the diagram here: https://www.sitepoint.com/rust-global-variables/ At Overview section.

The thing that I need now is make my global variable "Safe", so then in the future I can use it without any problem.
For single threading if I wanna store at runtime inside the const, I have to use Rc. But since I've told already that I want to make this in the future a concurrent program. Then I'll use Arc.

What's Arc btw
I made a summary before about this Arc thing, so I might just copy and paste in case someone is interested:

Rc and Arc note:

https://app.notion.com/p/Rc-T-and-Arc-T-39bfcd22531880c1a6c0fb1446359574?source=copy_link

Solution to my problem

This was my code before the refactoring:

// std::array<std::vector<char>, 13> g_tables;
const G_TABLES: [Vec<u8>; 13] = [Vec::new(); 13];

By combining Arc (Atomic Reference Counted) and Mutex (Mutual Exclusion), you create a single, shared source of truth that can be safely accessed and modified from anywhere in your program, even across multiple cores.

In the Rust community, wrapping a type like this is so common it's often jokingly called "the Arc> sandwich."

After:

static g_tables: Arc<Mutex<[Vec<u8>;13]>> = Arc::new(Mutex::new([Vec::new(); 13]));

Ahhhh I'm so close but the Rust compiler is telling me something:

= note: the `Copy` trait is required because this value will be copied for each element of the array
help: create an inline `const` block

But I don't understand why in order to get the Copy trait I have to put the Vec::new() inside a const...

What I found:
Copying vs. Re-running
When I write [value; 13], Rust doesn't run the value code 13 times
Instead, Rust does this:

Evaluates Vec::new() exactly one
Takes that single vector and tries to copy it 13 TIMES in order to fill the array

So this si where the Copy trait comes in. Simple types like u8 or booleans Implement Copy because copying them is just duplicating bits in memory.
But a Vec is: A dynamic data structure that points to a chunk of memory on the heap. So if Rust blindly copied the vector 13 times, you would end up with 13 vectors all pointing to the exact same memory location. So when you tried to add data to one, it would corrupt the others. And when the program ends, Rust would try to clean up the same memory 13 TIMES, causing a massive crash.

Solution: const Block
When we add the const block like the compiler tells us to do: [const { Vec::new() }; 13], we are changing the rules of the array syntax itself!!!.
I'm telling the compiler "Not evaluate this once, copy it instead, treat is as a constant expression, and run it 13 SEPARATE TIMES".

Arc (Atomic Reference Counting) is used to share ownership of a variable when you don't know how long it needs to live. But a static variable lives forever, for the entire duration of the program, and is already globally accessible to every thread.

If it's global, I only need the Mutex to safely mutate it!!!

Final Result:

// std::array<std::vector<char>, 13> g_tables;
static G_TABLES: Mutex<[Vec<u8>; 13]> = Mutex::new([const { Vec::new() }; 13]);

Fat Pointers & Smart Pointers in Rust

Lozi — Sat, 27 Jun 2026 14:55:38 +0000

When transitioning from C or C++ to Rust, the hardest habit to break is how you think about memory. In C/C++, pointers are mostly just memory addresses. Rust adds ownership and richer pointer types to make memory access safe without sacrificing performance.
In order to understand Rust, you have to know 2 key concepts: Smart Pointers and Fat Pointers. The entire decision of which to use depends on one rule: Ownership and Borrowing.

Smart Pointer: Definition

A data structure that acts like a normal pointer, but it comes with a "Property Manager" (Ownership Manager), let me explain:

It owns some resource (commonly heap memory) and knows exactly when that resource is no longer needed.

In Rust, common Smart Pointers have Vec<T>, Box<T>, or String.

Why is it useful?

The CPU Stack is really fast but tiny. So if you try to create a 3000000 byte array on the stack, your program will crash instantly raising a Stack Overflow. Smart pointers allocate their data on the heap.
Some smart pointers, like Vec<T> and String, can dynamically grow or shrink.
No memory leaks: Smart pointers automatically clean up the resources they own when they go out of scope, so you don't need to call free() manually!!!.

The Fat Pointer (Borrower & Viewer)

A Fat Pointer is a "borrowed" reference to a contiguos sequence of memory. Conceptually, a fat pointer is like a small struct containing:

The Address: Where the data starts.
The length: How many elements exist in the data.

In Rust, Fat Pointers are represented as Slices (e.d., &[u8] or &str).

Why is this useful?

Zero-Cost Windows: If you have a 500MB file in RAM, you don't want to duplicate data just to look at the header. A Fat Pointer create a "window" into that existing file. It requieres zero memory allocation or zero copying. Which is very useful.
Bounds Safety: Because the Fat Pointer has it's own length, the Because the fat pointer carries its length, Rust performs a bounds check before doing the indexing. If the index is out of range, the program safely panics instead of reading invalid memory.

Rust vs C/C++

The reason why these concepts feel weird at first is because C & C++ rely almost entirely on Naked Pointers (const u8*)
A naked Pointer is just a note with an address (0x7FFF0042), so it has no conext, length and no context.

First difference: Bounds checking

In C/C++ when you write ptr[500], the CPU does the math (ptr+500) and walks blindly 500 steps past the address. So if your array was only 15 bytes long, you may read unrelated memory from your own process or trigger a segmentation fault.
Rust: When you write slice[500], Rust automatically checks whether 500 is within the slice's length. If it's out of bounds, the program safely stops itself.

Second Difference: Memory Leaks

C/C++: Heap allocations are not automatically cleaned up. Even if a pointer variable goes out of scope, the allocated memory stays alive until you explicitly call free() or delete. If you forget, the program leaks memory.
Rust: By using a Smart Pointer (Vec), Rust automatically inserts calls to drop when ownership ends. As a result, you can't accidentally forget to free memory.

Third Difference: Creating vs. Passing

C/C++: You pass naked pointers everywhere. You pass them in order to create data, and also to read it.
In Rust: You use Smart Pointers (Vec) only when you need to create and own data. So immediately after, you slice them into Fat Pointers in order to pass to your functions so they can efficiently borrow and read the data.

The Ilusion of Arrays: Pointer Casting, and the Danger of memory Reinterpretation

Lozi — Wed, 24 Jun 2026 16:10:34 +0000

When optimizing software to run as fast as possible, developers tend to hit a wall with high-level data structures. To squeeze every inch of performance out of a processor, we have to stop looking at arrays as safe little boxes, and start lookin at RAM for what it really is: a MASSIVE, contiguous strip of single bytes!!!
One of the most powerful optimization tricks in C, C++, and algo unsafe Rust is Pointer Casting, reinterpreting an array of 1 byte-data (u8) as an array of 4 bytes (u32). But this raw pointer comes with a high risk of hardware crashes. Here’s why:

The Optimization: Why the bother of casting `u8` to `u32`?

A processor executes instructions in CPU CYCLES. If you need to read 4 bytes of data, a naive approach processes it through u8 (1 byte) pointer.
Cycles:

Load Byte 0
Load Byte 1
Load Byte 2
Load Byte 3

To optimize this, we change the “glasses” (just to make an analogy) the CPU is currently wearing. By taking the starting address of that u8 array and telling the compiler “Hey, pretend this is actually 🤓 a pointer of u32 data”, we change the memory stride.

Wait, wtf is a memory stride?

A memory stride is the distance in bytes between consecutive elements in memory along a particular dimension of an array.
Let’s make an example:

Array: [10, 20, 30, 40]
Type: uint32 (4 bytes per number)

Inside the memory will be:

Address: 1000   1004   1008   1012
Value:    10     20     30     40

To go from 10 to 20, you have to move 4 bytes
To go from 20 to 30, you move another 4 bytes So: stride = 4

Result when we “change the glasses”

Now when we tell the CPU to read index 0, it uses a 32-bit hardware register in order to swallow Bytes 0, 1, 2, and 3 simultaneously; which leads to:

Cycle 1: Load Bytes 0, 1, 2, and also 3!!!!!!! We just made the memory read almost 400% faster. However, lying to the compiler about the shape of your memory could open two massive failures at a hardware level…

Problem 1: Alignment Fault

Processors are wired to expect certain data types to align with specific memory boundaries:

An u8 (1 byte) can start at any addres
A u32 (4 bytes) is strictly expected to start at an addres that is perfectly dividisible by 4 (0, 4, 8…)

If you have an u8 array, and you decide to put on your u32 glasses starting at Address 1, you just created an Unaligned Pointer.
So, when you ask the CPU to read a 4-byte chunk starting at Address 1, the hardware struggles. Some processors (like modern intel x86) will silently fix the mistake behind the scenes. But processors liek ARM chips found in movile devices, consoles or embedded systems, physically can’t do it. So they will instantly panic and triggfer a Fatal Alignment Fault.

Problem 2: Modulo Trap

Even if your starting Address is perfectly aligned, the overall size of your memory buffer can kill the program if it doesn’t divide perfectly into your new stride.

Let’s imagine that you have a raw u8 buffer which is exactly 17 bytes long. Then you cast the pointer to u32 in order to read it faster

17 modulo 4 = 1...

This means that you have 4 perfect chunks , but 1 trailing byte remaining…
So... when you loop through the memory with your u32 glasses:

Index [0]: Reads bytes 0-3 (Safe…)
Index [1]: Reads bytes 4-7 (Safe…)
Index [2]: Reads bytes 8-11 (Safe…)
Index [3]: Reads bytes 12-15 (Safe…)
Index [4]: Reads byte 16... and bytes 17, 18, and 19 💀💀💀 Since you told the CPU it was reading a 4 byte structure.. It blindly reads past the end of your 17 byte buffer…

If bytes 17, 18, and 19 belong to the Operating System's restricted memory, the OS kills your program with a** Segmentation Fault** for trespassing.
Worse, if those bytes belong to another variable inside your own program, the CPU reads or overwrites them silently. Your program keeps running but with corrupted data… This is the definition of Undefined Behavior (UB). Good luck with that.

C/C++ vs. Safe Rust

In C and C++, the compiler implicitly trusts the developer. If you cast a char* to an int*, the compiler assumes you have manually verified the alignment and modulo math. When human error inevitably occurs, it results in security vulnerabilities.
Rust solves this by splitting the logic:

unsafe Rust: You can still perform raw pointer casting using std::slice::from_raw_parts and pointer casting (as *const u32). But you must wrap it in an unsafe {} block, taking personal responsibility for the math. If it crashes, you know exactly which block of code to blame!!!. 2. Safe Rust (Zero-Cost Abstractions): Instead of manually casting pointers, safe Rust provides methods like .copy_from_slice(), .copy_within(), or .try_into(). When you use these, the Rust compiler checks the alignment and array lengths at compile time or safely handles them under the hood. It compiles down to the exact same hyper-efficient hardware instructions (like memmove or SIMD loads) that a manual C-pointer cast would achieve, but mathematically guarantees you cannot trigger an Alignment Fault or step out of bounds.

From C++ to Rust: When Structure Layout Becomes Part of the Algorithm

Lozi — Thu, 04 Jun 2026 17:49:17 +0000

Have you ever stumbled upon code that works almost like a miracle, entirely because of how the compiler lays out data in memory?

Recently, while I was working on a port of a decryption for executable files (specifically EBOOT.BIN) from the PSP that was originally written in C++, I found a design pattern that brought me different emotions such as "fascination" and "paranoia"...

Today I want to document how a PSP decryption routine relies on contiguous structure layout to treat multiple adjacent fields as a single cryptographic workspace, the challenges of porting this design to Rust, and how I validated the implementation using an integration test with a real EBOOT.BIN file from Lego Batman.

First case: When The Structure Layout Becomes Part of the Algorithm

Let's analyze the original C++ structure I used to map the encrypted executable layout of the PRXType1 format:

struct PRXType1
{
    explicit PRXType1(const u8 *prx)
    {
        memcpy(tag, prx+0xD0, sizeof(tag));
        memcpy(sha1, prx+0xD4, sizeof(sha1));
        memcpy(unused, prx+0xE8, sizeof(unused));
        memcpy(kirkBlock, prx+0x110, 0x40); 
        memcpy(kirkBlock+0x40, prx+0x80, sizeof(kirkBlock)-0x40);
        memcpy(prxHeader, prx, sizeof(prxHeader));
    }

    void decrypt(int key)
    {
        // LOOK AT THIS NOW
        kirk7(sha1+0xC, sha1+0xC, 0xA0, key);
    }

    u8 tag[4];         // 4 bytes
    u8 sha1[0x14];     // 20 bytes (0x14)
    u8 unused[0x28];   // 40 bytes
    u8 kirkBlock[0x90];// 144 bytes
    u8 prxHeader[0x80];// 128 bytes
};

static_assert(sizeof(PRXType1) == 0x150, "inconsistent size of PRX Type 1");

Now u may ask: Where is the trick?

Pay attention to the decrypt fn. It calls the PSP's cryptographic engine (which is kirk7), passing as a source SHA1 + 0xC.

The sha1 array is EXACTLY 0x14 (20 bytes) long
If we move 0xC (12 bytes) FORWARD, we only have 8 bytes left in that specific array
HOWEVER, the third parameter says to process 0xA0 (which is 160 BYTES)

Now that we know that, Why the program didn't crash? Because the fields reside in a single contiguous structure object. (one after another). Although the pointer originates inside the sha1 field, the cryptographic routine processes 160 consecutive bytes. In practice, this means that the operation spans the remaining bytes of sha1, all of unused, and part of kirkBlock. The implementation therefore treats several adjacent fields as a single contiguous cryptographic workspace.

Because the decryption routine depends on a very specific memory layout, changing the declaration order of the fields would alter the 160-byte region processed by kirk7. Such a change would likely corrupt the decrypted data and break the algorithm entirely.

What Does kirk7 Actually Do?

void kirk7(u8* outbuff, const u8* inbuff, size_t size, int keyId)
{
    AES_ctx aesKey;
    u8* key = kirk_4_7_get_key(keyId);

    AES_set_key(&aesKey, key, 128);
    AES_cbc_decrypt(&aesKey, inbuff, outbuff, size);
}

Since the pointer begins at sha1 + 0xC and the requested size is 0xA0 (160 bytes), the operation spans the remaining bytes of sha1, all of unused, and part of kirkBlock.
In other words, the algorithm is not really interested in the sha1 field itself. It is operating on a 160-byte cryptographic workspace whose starting point happens to lie inside sha1.

The Rust Philosophy: Explicit safety without sacrificing performance.

When I decided to port this to Rust, I quickly realized that the original implementation relies on pointer arithmetic spanning multiple adjacent fields. While Rust can express the same behavior through raw pointers and unsafe code, I wanted a solution that made the memory region explicit and remained fully safe. Instead of relying on a pointer that implicitly goes to several fields, I represented the entire workspace as a single byte array and passed the exact range required by the decryption routine.

To solve this, I decided to use a single flat byte array (which is [u8; 0x150) and create read-only views (slices) based on fixed offsets.

Here is my implementation:

pub struct PrxType1 {
    pub data: [u8; 0x150],
}

impl PrxType1 {
    /// Constructs a new PrxType1 from raw file bytes.
    pub fn new(prx: &[u8]) -> Self {
        let mut data = [0u8; 0x150];

        // Reconstruct the layout respecting the original C++ offsets:
        data[0..4].copy_from_slice(&prx[0xD0..0xD4]);         // tag
        data[4..0x18].copy_from_slice(&prx[0xD4..0xE8]);      // sha1 (20 bytes)
        data[0x18..0x40].copy_from_slice(&prx[0xE8..0x110]);  // unused (40 bytes)
        data[0x40..0x80].copy_from_slice(&prx[0x110..0x150]); // kirkBlock part 1 (64 bytes)
        data[0x80..0xD0].copy_from_slice(&prx[0x80..0xD0]);   // kirkBlock part 2
        data[0xD0..0x150].copy_from_slice(&prx[0..0x80]);     // prxHeader (128 bytes)

        Self { data }
    }

    pub fn decrypt(&mut self, key_id: i32) -> Result<(), KirkError> {
        // In C++ the signature was: kirk7(sha1+0xC, sha1+0xC, 0xA0, key);
        // Our 'sha1' starts at offset 4.
        // 4 + 12 (0xC) = 16 (0x10).
        // If we want to decrypt 160 bytes (0xA0): 16 + 160 = 176 (0xB0).

        // Rust allows us to express the exact memory range explicitly and safely:
        kirk7(&mut self.data[0x10..0xB0], key_id)?;

        Ok(())
    }

    // --- Safe Views (Read-only Slices) ---
    pub fn tag(&self) -> &[u8] { &self.data[0..4] }
    pub fn sha1(&self) -> &[u8] { &self.data[4..0x18] }
    pub fn unused(&self) -> &[u8] { &self.data[0x18..0x40] }
    pub fn kirk_block(&self) -> &[u8] { &self.data[0x40..0xD0] }
    pub fn prx_header(&self) -> &[u8] { &self.data[0xD0..0x150] }    

    /// This verifies integrity by recalculating the header hash (it does this in the original decrypt project but I prefer doing it here)
    pub fn is_valid(&self, xorbuf: &[u8]) -> bool {
        let mut hasher = Sha1::new();

        hasher.update(&xorbuf[0..0x14]);
        hasher.update(self.unused());
        hasher.update(self.kirk_block());
        hasher.update(self.prx_header());

        let hash_calculated = hasher.finalize();
        hash_calculated[..] == self.sha1()[..]
    }
}

Why I think this solution is great?

We keep the extreme performance of C++ because we are doing 0 dynamic allocations or array cloning. By passing the range &mut self.data[0x10..0xB0] to kirk7, Rust guarantees via bounds checking that the cryptographic function operates strictly within those 160 bytes. So if we were to miscalculate the offsets, the program would trigger panic rather than silentyly corrupting other memory.

The moment of Truth

To ensure that this implementation was mathematically justified and the offset math was perfect, I wrote an integration test using the actual EBOOT.BIN file from the Lego Batman Game from the PSP.
This test load the specified file, extract the TAG dinamically, looks up to the corresponding hardware key using a key service (allocated into keys_service.rs), it generates the XOR buffer, runs the decryption, and validates via SHA-1 if the resulting bytes match the game's original structure!!!.

#[cfg(test)]
mod tests {
    use super::*;
    use std::fs::File;
    use std::io::Read;

    #[test]
    fn test_lego_batman_type1_valido() {
        // 1. Load the real PSP binary
        let ruta_eboot = "/home/snake/Downloads/lego_batman_game/PSP_GAME/SYSDIR/EBOOT.BIN";
        let mut file = File::open(ruta_eboot).expect("Could not open EBOOT!");

        let mut eboot_data = Vec::new();
        file.read_to_end(&mut eboot_data).unwrap();

        // 2. Map data to our flat structure
        let mut type1 = PrxType1::new(&eboot_data);

        // 3. Extract the crypto Tag (Should evaluate to 0xC0CB167C automatically)
        let tag_bytes: [u8; 4] = type1.tag().try_into().expect("Tag doesn't have 4 bytes");
        let tag = u32::from_le_bytes(tag_bytes); 

        // 4. Fetch the keys for this specific game
        let key_eboot = keys_service::get_tag_info(tag)
            .expect("This game's Tag is missing from the database!");
        let key_id = key_eboot.code as i32;

        let mut xorbuf = [0u8; 144];
        match &key_eboot.key {
            KeyType::U8(key_array) => { xorbuf.copy_from_slice(*key_array); }
            KeyType::U32(key_array) => {
                for (i, &word) in key_array.iter().enumerate() {
                    let start = i * 4;
                    let end = start + 4;
                    xorbuf[start..end].copy_from_slice(&word.to_le_bytes());
                }
            }
        }

        // 5. Decrypt using our safe Rust memory range!
        type1.decrypt(key_id).expect("AES engine failed...");

        // 6. Final validation: Does the calculated hash match the EBOOT offset?
        let es_valido = type1.is_valid(&xorbuf);

        // If this passes, our contiguous memory emulation was an absolute success
        assert!(es_valido, "SHA-1 hash mismatch... Decryption failed!");
    }
}

Result: `TEST PASSED (OK)`

We managed to replicate the exact behavior of the original PSP implementation without inheriting it's dangerous security risks

Conclusion

I am writing this article in order to prevent myself from forgetting this architectural headache as the project continues to scale...
Mastering memory isn't just about programming retro consoles. It's about understanding how data layout, performance, and correctness interact in every system we build.