DEV Community: Lozi

Bounce Buffer | Staging Buffer

Lozi — Tue, 01 Sep 2026 22:58:00 +0000

While I was translating a decryption tool from C++ to Rust, I stumble across a really weird syntax that kept popping me up for hours.

Context

The function that I'm about to show you, it's purpose is to prepare the pointer for the decryption process using the KIRK encryption algorithm:

int kirk1block(const u8 *pbIn, u8 *pbOut)
{
    static u8 g_dataTmp[0x1040] __attribute__((aligned(0x40)));
    memcpy(g_dataTmp+0x40, pbIn, 0x1000);
    int ret = sceUtilsBufferCopyWithRange(g_dataTmp, 0x1040, g_dataTmp+0x40, 0x500, 1);
    if (ret != 0) {
        return ret;
    }
    memcpy(pbOut, g_dataTmp, 0x1000);
    return 0;
}

Ok don't get scared, let's understand what exactly this function was made for. First of all let me introduce a really quick summary what exactly is "kirk".

What is KIRK?

KIRK is a dedicated piece of hardware inside PSP that is respondible for permorfing cryptographic operations, such as encryption, decryption, and hashing.
So instead of having the main CPU from the PSP to perform all of those operations itself, software can communicate with KIRK and ask it to perform a certain cryptographic operation. Then KIRK processes the data and returns a result.
You can think of it as a specialize cryptographic processor rather than a general-purpose CPU.

And this function was made in order to use THAT PSP'S KIRK cryptographic engine.

Since KIRK was built for maximizing speed and not safety, it physically requires memory to be processed in a strict way: hypothetically 64 byte chunks (and also aligned to addresses ending in 0x00, 0x40, 0x80, and so on...). NOW you understand where this is going:

So because KIRK is hardware rather than a simple software function, it contains certain requirements about how data must be presented to it. Therefore some KIRK operations expects their input and outbut buffers to be a 64 bytes aligned and proccessed in a specific block sizes (that's why I say hypothetically, since this is not a universal truth).

This, in other words, means that a buffer might need to start at an address such as:

0x1000 → aligned
0x1040 → aligned
0x1080 → aligned

And because each of these addresses is a multiple of 0x40 (64).

KIRK has a strict memory alignment and block size requirements in order to perform certain operations. So by passing a buffer that doesn't satisfy those requirements can cause the operation to fail or produce incorrect behavior.

Now that we know why we need alignment, we can explain what is Bounce Buffer

So if KIRK is that strict about memory, we could run into a massive problem when we look at our function arguments:

int kirk1block(const u8 *pbIn, u8 *pbOut)

Our encrypted data is being sent throuhg const u8 *pbIn. Since data comes from any adress in the program, we don't have guarantee that pbIn starts at an address that is multiple of 64. Therefore if it starts at 0x1013 for example, and we feed it directly to KIRK, the whole system could crash.
Because of that we can't trust the input address, so we have to create a safe middle-man. In low-level programming, this is known as a Bounce Buffer (or Staging Buffer).

Bounce Buffer | Staging Buffer

In simple terms, a bounce buffer is exactly just like what it sounds like: A temporary but highly controlled workspace. So if you have data being stored in an unpredictable, bad or incompatible spot (like out pbIn pointer), we don't use it directly. Instead we create a new buffer, then "bounce" our data into it, let the hardware do it's job safely and then bounce the clean results to their final destination.

Since we are the ones creating this temporary buffer, we can dictate exactly where it lives inside memory. Therefore we can force it in order to follow KIRK's strict alignment rules!!!
And that's exactly what that weird syntax I faced is doing:

static u8 g_dataTmp[0x1040] __attribute__((aligned(0x40)));

g_dataTmp[0x1040]: We are creating an array of bytes that's sightly larger than the 0x1000 chunk of data that we desire to process (Soon I'll explain why "sightly larger", just follow me)
__atribute__ ((aligned(0x40))): This is us telling to the C compiler a rule!!! We are explicitly telling this (or somewhat...): "I don't care where you put other variables, but this specific array MUST start at a memory address that is multiple of 64!!!".
static: Well, If you know C you'll probably know this, but basically means that the buffer isn't destroyed when the function ends. Therefore it's only created once in permanent memory, meaning that we are not gonna waste CPU time clocks rebuilding that workspace every time we process a block of data.

Then once our aligned workplace is ready, the next step will be moving the data in and then move it to our desired destination once it finishes processing data KIRK.

But why `+0x40`?

Now that our workbench is built, let's look at the actual data movement. Here are the next lines of our function:

memcpy(g_dataTmp+0x40, pbIn, 0x1000);
int ret = sceUtilsBufferCopyWithRange(g_dataTmp, 0x1040, g_dataTmp+0x40, 0x500, 1);

Let's look closely at the first memcpy. Since we aren't copying our encrypted data at the start of our buffer. We are copying it into g_dataTmp + 0x40 (In other words: We are skipping the first 64 bytes!!).

Remember when I told you our buffer was sightly larger (0x1040) than the data we wanted to process (0x1000)? This is the explanation about this manner if you are interested:

The original PSP only had 32 MB OF RAM!!!. And memory was extremely limited because of that. So instead of wasting space by creating a two separated aligned arrays (one por the input and one for the clean output), the programmer used an old-school trick which is called In-Place Decryption. They used the same exact array for both!!!! (I have an article explaining this concept, you should watch it).
But then why a 64-byte gap? Why not just start at 0?

This is because of the Read / Write Race.
If we started at the exact line, we would have a massive problem. Since te Write Head might step on the Read "Rail", therefore it can overwrite a byte of encrypted data just before the hardware had a chance to read it. So the data would corrupt itself!!!

By putting the encrypted data 64 bytes ahead, we are giving the Read Head a massive head start. Instead of hoping for the best and pray it doesn't overwrite encrypted data, we are securing it in a much better way. So that 64-byte empty buffer zone acts as a safety caution, making sure the Write Head always stays safely behind the Read Head while the hardware does its thing.

Traits in Rust

Lozi — Sun, 02 Aug 2026 16:15:45 +0000

In Rust, a trait is a way to define shared behavior. It acts as a "contact" or "label" that you can attach to different structs.

Instead of caring about what struct is, a trait tells the Rust Compiler what a struct can do. So if multiple, completely unrelated structs need to perform the same kind of action, you can group them under a single trait.

Example

Let's make an analogy about USB's into actual Rust code.
A computer doesn't have a separate hole for Mouse, Keyboard, and Webcam. It just has a USB port, right?. So in Rust, we represent these concepts by creating a USBDevice trait.

Definition of Trait and Structs

First, we have to define the trait (the label we've already talked about) and some structs that have nothing in common internally:

// The trait (label)
trait UsbDevice {
    fn connect(&self);
}

// First Struct
struct Mouse {
    dpi: u32,
}

// Second Struct
struct Keyboard {
    mechanical: bool,
}

Implementing the Trait

Then, we have to put our structs into the Trait. So we are proving to the compiler that both of these items can act as USB device:

impl UsbDevice for Mouse {
    fn connect(&self) {
        println!("Mouse Connecteeeeed! And ready to do some clicking");
    }
}

impl UsbDevice for Keyboard {
    fn connect(&self) {
        println!("Keyboard connected! And ready to do some typingggg");
    }
}

Using the Trait inside a function (POLYMOPHISM)

Here is where the "cool thing" happens. We write a function that represents the computer plugging something in. So instead of writing plug_in_mouse(device: Mouse) and plug_in_keyboard(device: Keyboard), we write only ONE function that accepts ANYTHING with the UsbDevice label.

// The "impl UsbDevice" syntax here means that it accepts ANY struct that has this trait!!!
fn plug_into_computer(device: &impl UsbDevice) {
    device.connect();
}
fn main() {
    let my_mouse = Mouse { dpi: 1600 };
    let my_keyboard = Keyboard { mechanical: true };

    plug_into_computer(&my_mouse);
    plug_into_computer(&my_keyboard);
}

But why are Traits so important?

Here I'm gonna point out essential things that you have to consider in order to make yourself understand and start using Traits:

Flexibility: As shown in the USB example, traits allows you to write more generic functions that can handle different types of data. So you build the function 1 time, and it automatically works for any struct that you create in the future AS LONG AS it has the expected trait.
DRY (Don't repeat yourself): Traits allows you to write "default methods". So if 200 different structs share the same logic for a certain function, you can write the function's code inside the trait once. And all of the 200 different structs will INHERIT IT, saving it from copying and pasting code everytime you need an implementation of that function that is the same from the rest of the 200 structs.
Extensibility: You can also implement traits on structs that you didn't even write!!!. Let's make an example: If you import a library that contains VideoPlayer struct, you can write your own custom Trait and attach it to their VideoPlayer.
Unlocking Built-in Rust Features: This one is really important since sometimes you want to use a function inside a crate and sometimes the compiler tells you that method_x is not implemented or some shit. Well... Rust uses standard traits behind for almost everyting!!!. If you wanna print a struct into the screen, you have to implement the Display Trait. And if you wanna copy a struct, you implement the Clone trait. TRAITS are how you "talk" to the rust compiler. Remember this since it's very important...

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.

DEV Community: Lozi

Bounce Buffer | Staging Buffer

Context

What is KIRK?

Now that we know why we need alignment, we can explain what is Bounce Buffer

Bounce Buffer | Staging Buffer

But why +0x40?

Traits in Rust

Example

Definition of Trait and Structs

Implementing the Trait

Using the Trait inside a function (POLYMOPHISM)

But why are Traits so important?

Why Rust allows many readers but only One Writer

Pointers

The Single-Thread

Solution

The XOR Gate

Global Variables in Rust & C/C++

Rc and Arc note:

Solution to my problem

Final Result:

Fat Pointers & Smart Pointers in Rust

Smart Pointer: Definition

Why is it useful?

The Fat Pointer (Borrower & Viewer)

Why is this useful?

Rust vs C/C++

First difference: Bounds checking

Second Difference: Memory Leaks

Third Difference: Creating vs. Passing

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

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

Wait, wtf is a memory stride?

Result when we “change the glasses”

Problem 1: Alignment Fault

Problem 2: Modulo Trap

C/C++ vs. Safe Rust

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

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

Now u may ask: Where is the trick?

What Does kirk7 Actually Do?

The Rust Philosophy: Explicit safety without sacrificing performance.

Why I think this solution is great?

The moment of Truth

Result: TEST PASSED (OK)

Conclusion

But why `+0x40`?

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

Result: `TEST PASSED (OK)`