Basic Architecture of Game Repacks

February 2, 2023

If you’ve spent any time in PC gaming communities, you’ve run into repacks. Within hours of a game dropping, someone out there, part of a loose, oddly talented underground of people who call themselves repackers, will put out a version of that same game compressed to a fraction of its original size. An 80GB install squeezed into a 20GB download, and the thing still works perfectly when you install it.

To most people this looks like sorcery. If you’ve ever tried right-clicking a game folder and hitting “Add to archive” in 7-Zip or WinRAR, you know the result is usually disappointing. Maybe 5% smaller if you’re lucky. So what are these people doing differently?

The short answer: they’re not just zipping files. What repackers do is closer to reverse engineering than it is to archiving. It’s a multi-stage process that involves tearing apart proprietary file formats, exploiting redundancy that normal tools can’t see, and then throwing serious compute at what’s left. It sits somewhere between data compression theory, systems programming, and a lot of patience.

To make sense of how they pull it off, it helps to start with why games are so bloated in the first place.

Why Games Are So Big

Modern AAA titles aren’t really “programs” in the way most people think of them. The actual executable, the compiled code that runs the game logic, is usually a few hundred megabytes at most. Everything else, the other 99% of that install size, is assets.

Textures and mipmaps
The jump to 4K (and beyond) has made texture files enormous. A single uncompressed 4K texture can easily be tens of megabytes. And most engines also store mipmaps (smaller pre-generated versions of each texture used when an object is far from the camera), which tacks on roughly another third to the total texture storage.
Audio
This one’s a bigger deal than people realize. To keep CPU overhead low during gameplay, a lot of games ship audio in uncompressed or barely-compressed PCM formats. A game with a layered soundtrack, thousands of sound effects, and full voice acting already has a huge audio footprint. Then multiply that by every supported language with its own voice track, and the size grows almost linearly. You might only play in English, but you’re downloading the Japanese, German, French, and Spanish dialogue too.
Intentional data duplication
This one’s a holdover from the HDD era. Mechanical drives are slow at random seeks because the read head has to physically move. So developers would sometimes duplicate the same assets across multiple archive sections, placing each level’s data contiguously on disk so loading screens stayed short. Common textures, shared meshes, that sort of thing, copied dozens of times. SSDs have made this mostly unnecessary, but plenty of games (and build pipelines) still carry the baggage.

Cracking Open the Virtual File System

A repacker can’t just compress the game’s install folder and call it a day. Game engines don’t store assets as loose files sitting in directories. They pack everything into proprietary container formats: Unreal uses .pak, Frostbite has .cas/.cat, Unity wraps things in .assets bundles. These containers act as a virtual file system optimized for fast runtime access, not for storage efficiency.

Worse, the data inside is usually already lightly compressed (LZ4, Oodle Kraken, etc.) and sometimes encrypted. This is a problem. Compression algorithms work by finding repeated byte patterns, and data that’s already compressed or encrypted looks random to a compressor. High entropy. You can’t compress randomness. Trying to zip an already-compressed .pak file gets you basically nowhere.

So the repacker has to get past the container. They need the raw, uncompressed assets underneath.

Reverse Engineering with QuickBMS

This is where QuickBMS comes in. It’s a tool for pulling data out of proprietary archive formats using community-written scripts that describe the container’s internal layout: file headers, offset tables, encryption schemes, the works. The repacker runs the appropriate script, and out come thousands of individual raw files. Textures, audio chunks, meshes, config data, all of it extracted and decompressed.

Now they have something to actually work with.

Solid Archiving

Once the raw assets are laid out, repackers typically use solid archives. In a standard ZIP file, each file is compressed independently. In a solid archive, files are concatenated into a single continuous stream before compression.

This makes a real difference for games. Thousands of XML configs share the same tags and structure. Batches of UI textures have similar color profiles and layouts. When the compressor can look across file boundaries, it finds far more repeated sequences to exploit, and the ratio improves significantly.

Dictionary Size

Most repacks lean on dictionary-based algorithms, usually LZMA2 or Zstandard. These build up a dictionary of recurring byte sequences as they go. When the same pattern appears again later, it gets replaced with a short reference instead of being stored again.

The key variable is how large you make the dictionary. A 1GB dictionary means the compressor can reference matches from up to a gigabyte ago in the data stream. Bigger dictionary, more potential matches, better compression. But it also means the machine doing the decompression needs that much RAM just to hold the lookup table.

Deduplication

Before any of the algorithmic compression even starts, repackers usually run deduplication passes. If the extracted files contain 50 identical copies of the same 10MB texture (thanks to that HDD-era duplication trick), 49 of them just get thrown out. A script is written so that during installation, the missing copies are recreated, either by byte-copying or hardlinking.

This alone can shave off a surprising amount.

Lossless vs. Lossy

Even with all the above, compression algorithms have hard limits. You’re not getting from 80GB to 20GB on lossless math alone. To hit those extreme numbers, repackers have to start touching the actual content, specifically audio and video.

Lossless Repacks

A lossless repack means the installed game is bit-for-bit identical to the original. Every file hashes the same. Nothing is degraded.
The savings here come from re-encoding audio more efficiently. Game engines often use ADPCM or raw PCM WAV stuffed inside middleware containers (Wwise .pck files, for instance). A repacker can pull those out, re-encode them with a more efficient lossless codec for transport, and then reconstruct the originals at install time. No quality loss, just smarter packing.

Lossy Repacks

Lossy repacks go further. They permanently reduce the quality of heavy media.
Pre-rendered cutscenes are a favorite target. A 4K Bink (.bik) video at 50 Mbps gets re-encoded down to 1080p or 720p at maybe 5 Mbps using HEVC (H.265), then converted back into the engine’s .bik format with RAD Video Tools so the game still reads it. That single step can knock 20GB off a modern title.

Audio gets hit too. Downsampled from 48kHz to 32kHz, or re-encoded from PCM to Opus or Ogg Vorbis. The file sizes drop dramatically.

The game is fully playable. But if you’re paying attention, you’ll notice muddier cutscenes and slightly thinner audio. That’s the trade.

What Installation Actually Does to Your Machine

All of this clever packing has a cost, and you pay it at install time. Repackers shift the work from the download onto your hardware. Your CPU, RAM, and storage all take the hit instead.

Installing a heavily compressed repack can be rough. Multi-core CPUs pegged at 100% for an hour or more is normal. Here’s roughly what’s happening:

Memory allocation: The installer loads the dictionary into RAM. A 1GB+ dictionary means 1GB+ of RAM spoken for before anything else starts.
CPU decoding: The processor grinds through the LZMA or Zstd streams, resolving each dictionary reference back into raw bytes.
Disk writes: Decompressed data gets written out to a temp folder.
Recompilation: Scripts reassemble the raw files back into the engine’s proprietary container formats (.pak, .cas, whatever the game expects).
Verification: A CRC or MD5 check runs against every reconstructed file to make sure it matches the original release.

Whatever you think of repacks and the scene they come from, the engineering underneath is hard to dismiss. Repackers are solving a cool problem: optimizing for storage density instead of runtime performance, by dismantling engine-specific containers and wringing out redundancy that off-the-shelf tools can’t reach.