@kmdw

A few fixes here and there. Some refactors, caching externally loaded playlists in savedata, and fixing a deadlock when clearing the items cache. And for some reason the decal option was missing from the items list picker.

I made a standalone web-based swapper for the people who don’t want to download an entire app. A lot of people had broken packages after the last update but didn’t want to install a dedicated program just for a few swaps. So, I used the asset swapper backend of rlbuddy to make this thingamabob which runs entirely in the browser!
First, I had to find out how to actually share rlbuddy’s asset swapper with other projects. Turns out Cargo has a cool thing called workspaces where you can have multiple crates in the same repo! So I moved the dedicated UPK/AES etc. stuff into a new crate and added it as a dependency in regular rlbuddy.
Then, I whipped up a small wasm-compatible eframe app with the template, and included the new crate as a dependency. I made a big state machine of the steps meaning it’s impossible to have an invalid state, which is really nice. The only problem was that Rust’s ownership system isn’t smart enough to deal with it, so the code is a bit repetitive in places but it’s definitely worth it.
The WASM restrictions were super annoying, mainly do to with filesystem access and requiring async. I ended up using the egui-async crate and spilling Binds all over the place within the state machine. I couldn’t even figure out how to get the actual swap procedure to run in a different thread.
I also spent like 30 minutes debugging why in the world asset swapping was just broken. Even when I verified the same binary data were going in to the Upk object in the webapp and rlbuddy, for some reason the output upk was just different. Turns out I used chosen_replacement.name instead of chosen_replacement.package.name(). Isn’t that great? Anyways, it works fine now and I’m planning on posting it on r/RocketLeagueMods and possible r/RocketLeague.

Not much in terms of super-cool stuff this time. Highlights are:

1. make sure dynamic playlist loading uses the latest cache file (and also fix its loading on normal people’s rocket league installs)
2. loading the cache file on another thread so it doesnt freeze the whole app for a second on the first lazy lock access
3. searching for items in the item swapper
4. moved the error handling of the map loader to anyhow

So no ultra-exciting things to talk about. anyhow is really cool though, it really simplifies error handling everywhere in the app, and I’m a big fan of its bail! macro. I’m also using Cow a lot more. Moo!

I got licensee version 34 (encrypted payloads too) to swap finally!
Okay, so this was awesome. Rocket League’s been having a bunch of updates lately, which breaks the packages of people trying to get free stuff. So, in a Reddit thread, I ended up dishing out a bunch of swapped asset files for people in this situation. There’s a new boost which everybody wanted really bad since it was really rare (but they decided to make it unlockable at rocket pass lv99 so it doesn’t even matter anymore), and it was UNSWAPPABLE for three reasons:

1. it was encrypted specially
2. i hadnt encountered specially encrypted packages meaning their handling was wrong
3. aes keys werent out for it yet (or so I thought)

I’ll start with 3. I had written a tool which looks in the games cache for AES keys, and dumped them, and it worked great. What I didn’t expect is the filename to change between versions. So, I was super confused since yesterday since the AES key for the boost was just… missing. Thankfully, the geniuses at the RLMM discord got it and helped me figure out that the file I was reading from was just outdated. Great!
Anyways, not too big of a deal, just a big delay. Now it’s time for the real challenge: figuring out how the hell to handle this type of package.
First, I did some research. The twelve bytes of padding in files with licensee version >=33 before the summary are actually a nonce/aes iv, not just padding. Then, the header is encrypted with AES-CTR with the twelve first bytes of the iv just being the nonce. And the compressed chunks are encrypted too here: each one is also AES-CTRed with their own nonces in FCompressedChunkInfo.
Thing is, I don’t have an implementation to really go off anymore, meaning there’s a lot more trial and error. For the original implementation, there were one or two existing asset swappers (though they were vibecoded meaning more of a puzzle to figure out what they’re even doing), but this time I was mostly relying on emii’s fork of UEViewer. Anyways, after spending a while figuring out what exactly I had to masquerade (payload, key, swap nonces) I finally got it to work!

rlbuddy now loads additional playlists straight from the game’s cached webconfig, instead of hardcoding them all! This means that the list of playlists will basically never go out of date.
There are actually quite a few services which rely on game files (eg. auto stats api setup, custom maps, asset swapper). So, the first thing I did was to refactor it so make all of these load from the same global value.
Then, for playlists, I made it read from a specific file in the game’s http cache directory which contains a bunch of configuration. Then, it parses it into a JSON object, grabs all the values with Class PlaylistSettings_TA, and then extracts the title and playlist id!
There are still a bunch of built-in Playlists, since those have internal things like going from a casual playlist type to its respective competitive one or having the hard-coded list of singleplayer playlists. But, all the other ones, like ltms are dynamically loaded. Yay!

I made a ton of improvements to the asset swapper! And fixed a bug with the music player which is cool technically, so I’ll start with that. The player uses the GSMTC api, which is async, but egui doesn’t really like async. So, I made it so that every time you wanted to run some command on the current session, it would start up a new thread. This was less than ideal for a few reasons:

1. terrible performance
2. race conditions could happen just… in Windows itself

The main problem was 2: for example, if you skipped a replay too fast, the Play command from the end of the replay might actually reach Windows before the Pause command from the replay start, leaving your music paused.
So instead, it starts one dedicated worker thread which has a channel which receives a Box<dyn FnOnce(Session)>, and executes at most one command every 50ms (only one command per loop, fixed loop time of 50ms). It’s really interesting because you actually end up sending a closure through a channel, which feels funny but when you really think about it it’s just ownership semantics. But, that’s working great now!
On to swapper improvements! First, I moved most of the swapper module to anyhow handling (it’s heaven!), and I also modernized the upk api a bit since it was basically dragged directly from the proof-of-concept repo, meaning it was not really application-ready. Also, it previously looked at the game’s webcache to decode the AES keys for header decryption, but now it uses the wonderful Toga-Files repository along with a really nice caching layer for it to load items and their associated API keys.
Having access to the actual item data is also way better since you don’t have to manually type in a package name which is kinda weird for any normal person. Now, you can select it from a dropdown instead! I love UX.

rlbuddy now has item swapping! Basically, making one item appear like another to use items you don’t actually own. These hours were spent on a few different things. Firstly, I optimized the thing a bunch! There were a few places that were pretty slow since the original repo was mainly for testing. For example instead of decrypting the entire header and rechecking it to find the right key, it only loads the first 4 blocks and attempts to decrypt the first FString. If it fails, that means the AES key isn’t valid. Also, I improved the error handling with anyhow. It actually makes it so much easier to deal with things and was pretty useful when debugging the move over to the actual app. Now I’m just going to work on polishing the panel UI a bit more, since it’s still kind of ugly.

Apparently there are a bunch of different AES keys rocket league uses, not just one. You can get a list of them from the psynet config url, and then do some weird crc stuff to change them from “content keys” to aes keys. I discovered the rocket league mapmaking discord today and I’m blown away by the amount of information on there, and also apparently my whole thing about the unknown bytes when licensee version > 32 was straight up wrong, which is funny.
Anyways it works for all items now, which is great. I’m gonna work on actually putting it in rlbuddy now, hopefully that goes well

IT WORKS WHEN THE HEADER EXPANDS NOW YAYAYYAYAYAYYAYAYYAYAYAY

I’m gonna be honest, the problem might just have been that my testing package was corrupted. I was debugging my deserialization logic, which I thought might have some parsing issue near the header extraction, and noticed that once the encrypted region deserializer’s Cursor reached the end of the region, it was actually FARTHER than the package summary’s total_header_size - by 6 bytes! That’s pretty bad, and I don’t know how something like that even happened. Anyways, I repaired the game and brought over the shiny new upk and… it worked.

I’m pretty sure that I only accidentally did this while tidying up my workspace a few hours ago, but if this has genuinely been the thing holding me back for the past few days -

I also finally made the poc code public, at https://github.com/kalilamodow/rl-upk-testing/

IT SWAPPED IT SWAPPED IT SWAPPED AHAHAHHAHAHAHHAHAHAHAHHA FINALLY

Okay now I gotta make it work for other pairs of boosts. If WHEN that works, I’ll actually put it in rlbuddy.

I removed all the code relating to changing offsets to try to give myself a minimal workspace to tinker in, with as little side effects as possible. So, all the current code does is 1. open them 2. replace the name table entries and package guid. Surprisingly simple. Once I make it a bit more generic, I can extend it to support more swaps.

If I’m really unable to get it to work for more combinations, I’ll probably end up just publishing the poc repo and not adding swapping to rlbuddy at all.

This is a great motivation boost, though. I was honestly dreading coming home to work on it today because I was done with failing over and over, and considering giving up.

I got a name swap! It doesn’t work properly, but I’m glad the game didn’t crash. These hours have been by far the most frustrating because the only way to test is against the real game since it’s really picky, but the game takes like 30 seconds to start, and if it crashes, it gives a cryptic error log, and if it freezes, it doesn’t give any log at all. I spent most of the time messing with moving different offset values forward and backwards, and ended up reverting to a simpler version with no overwriting when the header size changes just to test things.
So far, I’ve mostly gleaned that name renaming is possible, but only up to a point. If the name grows too much, the game crashes, and if the name shrinks too much, the game freezes. Additionally, for some reason, total_header_size changes by the padded header size instead of the encrypted header size, which I still don’t understand.
It’s seriously weird. I serialize each name properly, and yet the game reads it wrong. This game really does need a new codebase. When UE6 comes out, either the game’s gonna be so good it doesn’t need mods, or it’ll be relatively easily moddable. Or neither, which is the most probable based on Epic Games’ track record.
Anyways, enjoy the beautiful screenshot.

I figured out what comes after export tables! And it took way too long, since I DISCOVERED IT MYSELF! At least, as far as I know. I couldn’t find any information online about this portion of the header, so it was basically luck that I noticed a pattern. Before, I was just copying everything after the export table and pasting them back in afterwards, but as you can guess, that stopped working if I adjusted anything within the encrypted region.
Compressed chunk info is a known part, and I figured out the AES padding pretty easily, so most of the time was spent trying to figure out what in the world those 24 bytes were.
The first four bytes in the compressed chunk info are how many chunks they are. Here, in the Bubbles boost package, there are two (little endian), with 24 bytes of ???. And in Flamethrower, there are three, with 36 bytes of ???.
I noticed that the ??? was always n chunks * 12 bytes (actually, it’s lucky that I didn’t test any which ended up having 0, otherwise I probably wouldn’t have figured it out). Since this probably had something to do with chunks, I made a guess that each chunk had some extra data stored in this array, 12 bytes of info per chunk. Using HxD’s highlight-bytes-and-get-the-decimal-value feature, I noticed a pattern where the first 8 bytes looked like an i64 offset and the last 4 looked like an i32 size, which the compressed chunk infos were also like for their matching counterparts.
So, I deserialized it as [i64; i32] * n chunks and was able to read it better. These additional chunk infos seem to kinda sorta match up to uncompressed header offsets, but I don’t really understand what they are (and they’re marked as such in the code, lol).
So, with that working (and some fiddling with broken serialization of TArrays which I’m surprised I didn’t catch earlier), I now understood the ENTIRE package header! Hooray!
Let’s look at another example. body_grain_SF, the Fennec, has 4 chunks. Guess how many bytes of ??? it has. That’s right, zero!
For some reason, a few packages just don’t have those things. After going through a bunch of them, I found that if licensee version was 32, there was no ???. But if it was 33, there WAS ???. I basically just added an if statement and it was fixed.
I’m going to try to work on figuring out the padding in between the package summary and the start of the name table, but if I can’t, I suppose I’ll finally get to actually doing package swapping. Later!

I JUST DESERIALIZED AND RESERIALIZED A UPK. OMAIGOD IM SO HAPPY. my brain is so tired. Alright so the payload still doesn’t get transferred but that’s pretty simple, it’s just Vec::extend.
What a challenge! Deserialization actually ended up being the easy part, which is opposite of what I expected from starting the project. It went (relatively) fast since there are a few existing implementations which I could kinda just “borrow” structure parsing from.
But, mine is unique in that it almost completely reserializes the package itself. I might’ve been able to “borrow” reserialization, but the impl I’ve been looking at is STRAIGHT ai slop and it’s more annoying to read that than to just do it myself. It was useful though, so I have to respect it.
The first problem: basically, the first byte of an FString determines how many parts it has, NOT how many bytes it has. Which wasn’t a problem for parsing, since I had some word-based helpers which worked so I didn’t think much about it. But, when reserializing, I made two mistakes: 1. forgot to add the null terminator (which shouldn’t even be necessary) and 2. I accidentally put the wrong offset.
I have no clue why there’s a null terminator for FStrings. The format is [n chars][the char bytes], meaning it should already be known how long the string is. Pretty stupid, but whatever. Anyways, when reserializing you’re supposed to include the null terminator in the string length marker. So, my logic was that I should offset it by two since unicode characters are two bytes. Bleh! I should’ve only incremented by one, since it’s in terms of utf16 chars rather than bytes.
Yay, that worked! I don’t know how to summarize the next problem, so I’ll explain the reasoning. The package header is file summary + tables + something else (we’ll get to that later). Anyways, there’s some mysterious padding in between the summary and tables. Parsing, it’s easy to skip over because the summary includes the tables start offset (name_offset, the name table is the first one). But when reserializing, you gotta keep those offsets intact. Well, I’m not totally sure if you actually have to keep them, but just for the sake of simplicity I tried to (which ended up adding more complexity, which I’ll see if I can remove now). So, I serialize/push the summary to the big Vec. Then, I make a new Vec and serialize the name table at (name_offset - summary_size), since the new Vec has to be encrypted and then appended to the big Vec. I do the same thing for imports/exports (placing the table at import/export _table_offset - summary_size).
Oh no! Since name_table_offset isn’t equal to summary_size, there’s some padding in between, which is expected. HOWEVER! The previous logic would skip over it in the table Vec creation, meaning the table Vec would have some 0-padding at the start. This padding needs to be in the SUMMARY part instead, and the name_offset should basically be the ZERO of the tables Vec!
I doubt I would’ve been able to solve this part without the beautiful tool HxD. It’s really easy to use and is always helpful when I’m figgling around with binary.
So, it does some more math, calculates the spacing, adds it to the big vec, and removes it from the tables Vec. Then, it re-encrypts the tables Vec and pushes it onto the big Vec! Okay, now that’s done. NOPE! There’s a mysterious structure for some reason at the end of the real table part? Yep, it’s that something else I said we’ll get to. I actually still have no idea what it is. From some research, I gathered it must be the dependencies table, but it’s really poorly documented. So, I ended up just cutting the bytes out from after the export table to the end of the tables part, and “pasting” it back before re-encryption.
I do hope this devlog was readable. Now I’ll get to including the actual package payload and hopefully simplifying reserialization offsets. See you soon!

I’ve been putting this off for a while, but I’ve finally decided I’m going to add asset swapping. There’re a few existing implementations, so I’m reading those as well as some pdfs about the upk format. So basically credit to this document and this implementation. All it can do for now is parse the file summary.

The implementation wasn’t too bad since I had Google as well as the C# implementation I just talked about. I basically have

trait Deserializable: Sized {
    fn deserialize(reader: &mut impl Read) -> AnyResult<Self>;
}

Then implement that for the various parts (eg. FGuid, a generic TArray). Then, I use byteorder to read out numbers into each struct. For example,

#[derive(Debug)]
struct FCompressedChunkInfo {
    uncompressed_offset: i64,
    uncompressed_size: i32,
    compressed_offset: i64,
    compressed_size: i32,
}

impl Deserializable for FCompressedChunkInfo {
    fn deserialize(reader: &mut impl Read) -> AnyResult<Self> {
        Ok(Self {
            uncompressed_offset: reader.read_i64::<LittleEndian>()?,
            uncompressed_size: reader.read_i32::<LittleEndian>()?,
            compressed_offset: reader.read_i64::<LittleEndian>()?,
            compressed_size: reader.read_i32::<LittleEndian>()?,
        })
    }
}

I originally prototyped it in Python and then moved to Rust once I got tired of python’s byte shenanigans.

I did lots of performance improvements and also IT WORKS ON LINUX NOW!!!

Let’s talk about performance first. Anyways, it has been using around 4% and 220MB of ram, which isn’t really what you’d expect from an overlay! So, I used things like DHAT to profile the memory, and noticed that fonts were doing some shenanigans. So I removed egui_system_fonts and loaded directly from C:\Windows\Fonts\segoeui.ttf and RAM usage dropped to 30mb. That was what the previous devlog was about.

I then changed the default logic update rate from 10ms (100/s) to 65ms (15/s approx). This reduced idle cpu usage to under 0.2%. But, doing anything with the UI would spike it to 4%, which is still pretty bad.

So, I used a method I found in an egui issue thread where I’d count the frametime since the last render, then sleep until the target frametime was finished. For example, if the frame rendered in 2ms but I want 16ms frametime, it would sleep for 14ms. That way, I could limit how often the UI rendered! This made it stay under around 1% CPU forever!

Okay, Linux time! Rust is mostly cross-platform, so support was mostly dealing with dumbass design decisions. Since Music relies on GSMTC, I had to feature-gate the entire thing (as well as the windows/windows-future crates) behind cfg(windows) :(

I also had to fix Linux font loading (since like I said earlier, it’s hardcoded to segoe ui). So I install fontdb on Linux and search for some popular fonts from there to load instead.

Finally, I fixed up the storage paths since it could only load from AppData. I also made it use AppData\Local vs. AppData\Roaming instead of putting everything in Roaming.

I first got it working through WSL! ! It took some messing with my GPU drivers but I got it to render. Now was the real challenge: getting it to build on an ACTUAL Linux machine.

I had an old, basically broken Surface Pro 3 that I had put Debian+GNOME on for shits and giggles a few months ago. The perfect target! The main problem was getting Rocket League to even launch. I set up Legendary (goated launcher btw, check it out) and tried to run it. I installed Wine, got Wine Mono, and it failed with a weird cryptic error about the CreateWindow function. The obvious solution to a graphical error: disable EAC. Yay, it launched!

Then to get it to build. First I had to fix some filepaths since Linux is case-sensitive (nerds) while I don’t care about case on Windows. Then, rust-lld gave some weird error about simd or something which I didn’t care about. I just ran cargo clean and rebuilt it and it worked fine.

Then to run, and it actually worked first try! It’s cool because I went into it expecting to debug a million socket errors, but it actuallly connected and ran. Awesome sauce! Now Linux users can use rlbuddy. More minions to contr- I mean cool users! Cya in the next one! ;)

If you check out the rl perf overlay in the screenshot, you’ll be able to guess why this is the laptop I decided to put Linux on.

I’ve been debugging high memory for the past month or so. It was egui_system_fonts. Why would fonts take 170mb of ram????????????????????????????????? help!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I hate external dependencies!!!!!!!!!!!!!!!!!!!!11

I owe my life to DHAT now. go star https://github.com/nnethercote/dhat-rs

More gamepad overlay buttons!!! Yay!!!

In not-so-awesomely-exciting news, I also added a table of contents to the readme (as well as a generator for it). The script’s in Python (I’m sorry for not using Rust) meaning the repository is now 0.5% Python. Takeover incoming?

I overcomplicated the script a lot, but it’s really easy to read. There are three whole comments, aka 6% of lines in the whole file! It’s not technically interesting in the slightest. I was thinking of building a tree-like structure before outputting the string, but realized I can just use the header level (h1 vs h2 vs h3 etc) as the amount of spaces / 2.

I also refactored it not to use magic PanelIds for the default panel list. I kinda rushed that part when I made it, I’ll be honest. But now each Panel can implement fn open_by_default(&self) -> bool (returns false by default) and if it does it keeps it open when savedata doesn’t exist yet.

I don’t get how an entire hour n 27 minutes was spent on like 7 not-even-that-big commits. At least it was a good use of my math class. We reviewed limits for some reason (which everyone should already know for one because they took the prereqs?), and the teacher managed to extend her lecture for the ENTIRE class time. rlbuddy development saving the day, I guess (just like it will in your rocket league games btw, so you should download it)

I’ve mostly been working on smaller features, improvements, and bugfixes. A cool one I did is fixing weird glitchy movement with the gamepad overlay window!

Basically, the window needs to persist its position across disabling it/enabling it. And egui is immediate mode. So, every time it rendered the viewport, it would both set and get its position. So, moving it would update the current position, but because of the weird interop between setting the position in a ViewportBuilder and getting it from the viewport info, it would glitch back and forth, especially when my laptop is lagging.

I fixed it by only calling the ViewportBuilder‘s “with_position” method when the overlay had just been enabled (!was_enabled && currently_enabled). That way, it only sets it once externally, and lets it move freely while it’s open. Then, while it’s moving, it continues to update the saved position. And upon closing and then reopening it, it sets it again (but only once!)

Relatively simple fix but it’s kind of funny. I mainly noticed it when I added a feature that would auto-unmaximize the overlay when the user maximizes it, and it would go crazy and fly around the screen. Very fun!

I also fixed a pretty old bug where it would incorrectly detect the local player. Basically, the stats api doesn’t actually tell you who the local player is. So, we have to guess based on who the camera is targeting right now. Usually, it’s on the local player, but during goal replays or spectating a bot when joining a casual game, it would be improperly set at the start and then stay like that.

So, I made sure that it always updated as long as the match is 1. in progress 2. not in a replay. It also fixes a thing with inconsistent match toasts, since the toasts only fire if the scoring player is the local player (and if it thinks the wrong player is the local player, everything’s messed up).

I’m planning on revamping hotkeys next, to allow you to bind to any controller button and even do custom quickchats in-game. Later!