Differences

This shows you the differences between two versions of the page.

--- extraction [2026/02/20 12:45] – ultracomfy
+++ extraction [2026/02/23 09:50] (current) – ultracomfy
@@ Line 1: / Line 1: @@
-{{page>Templates:Page Incomplete}}
 ~~NOTOC~~
 <WRAP column 18% right>
@@ Line 11: / Line 9: @@
 Video game file extraction is the process of ripping assets from a video game's game files. In 2026, video game assets are still stored on the local machine and streamed from the disk. This makes all game assets accessible from the local machines, allowing talented individuals to extract them into their individual parts.
-====== Process ======
+//This page is a documentation on extraction-related concepts and not a tutorial on how to extract assets from video games. For that, see [[Extraction Tutorial]].//
-Some games store their assets plainly, ie. their textures, sounds and many other things are just literal picture and sound files. In this case, "extraction" is as simple as copying the folder's contents elsewhere. [[DEFCON (Game)]] is one such case.
-===== Container Files =====
+====== Video Game Files ======
-However, other games, especially ones that were made using one of the popular [[video game engine]]s like [[Unity]] or - shudders - [[Unreal]] don't make it quite as easy. When baking, these games pack all the assets into engine-specific [[container file]]s. For Unity, these are typically found in the game's "Data" folder with .resource endings. Unreal games come with .pak files in the "Shipping" folder.
+Video games store their assets in bits and bytes on a computer's hard drive. If you hear a sound or see a particular image inside a video game, it is almost certain that this is stored as a file somewhere on your computer((I say that because there can be some internet streaming which can bypass the hard drive entirely)). The task of a user wishing to extract these assets is to know where to look and to understand some fundamental video game concepts, especially in regards to file and file formats.
-These files are a lot like .rar and .zip files. You cannot open them directly, but they can be extracted with tools. For .rar/.zip you would use one of the many tools like WinRAR, 7Zip or such, whereas with Unity's files you will need [[AssetStudio]]. Like WinRAR lets you load .zip files, AssetStudio lets you load the .resource files, view their contents and extract assets.
+===== Plain Files =====
+Some games store their assets plainly, ie. their textures, sounds and many other things are just literal picture and sound files. In this case, "extraction" is as simple as copying the folder's contents elsewhere. [[DEFCON (Game)]] is one such case. As a "dataminer", it's useful to know what is a plain file and what isn't. More on that in a bit.
-Unreal is a lot more proprietary, so it is a lot harder to crack. Unreal is constantly changed and updated so that tool creators have to constantly keep up with Unreal's changes on a shorter timeframe. This leads to tools quickly becoming outdated, which itself leads to many different tools in different stages of production that are compatible with different versions of Unreal to varying degrees. Seriously, I have like four different tools for Unreal games because of that. The standard method is a command line tool called "QuickBMS". On its own QuickBMS is basically just a "launcher" for all kinds of extraction scripts, a list of which can be found [[https://aluigi.altervista.org/quickbms.htm|here]]. When QuickBMS is run, it will ask for a script to run. In our case we would use the Unreal Tournament 4 script. It will then ask for the input files and for an output location. In many cases, games are AES encrypted - an encryption layer on top of the packing method that Unreal already employs - if it asks for an AES Key, that has to be supplied as well. These are game-specific, not computer-specific, so there are resources online with comprehensive lists for a lot of Unity games with keys that work on all machines.
+===== Video Game Engines =====
+While it is possible to build games from a text file - and is in fact how the earliest video games were made - that method is an incredibly tedious and painful endeavor. This is particularly notable when you consider that much of the legwork in video game development is similar to each other, and building completely new systems for //a 2D or 3D renderer, physics engine, audio engine, scripting, animation, artificial intelligence, networking, streaming, memory management, threads, localization support, scene graph, and cinematics//((Copied directly from Wikipedia)) every time you make a game is expensive and wasteful. A game engine provides basic structures for all of these which lets developers focus more on actually making the game.
-Once set, QuickBMS with the script will get to work and extract.
+===== Engine and Middleware Files =====
+Video game engines and plugins tend to use their own, custom file formats for things. For example, a very popular middleware audio plugin called [[WWise]] uses the file format WEM (amongst others), in place of things like MP3 or WAV, for audio. The technical reason for this is that creating your own audio format gives you full control over the features it should have. Your own audio format can be programmed to support audio layering within a single file, to contain data about the context in which it is played, to contain data about the programming [keyword 'Event Data'], other instructions to the audio or the game engine and all kinds of other information and interfaces to the audio that aren't present in more standardized formats like MP3.
-===== Middleware Files =====
+The same applies to the game engine's files. They contain all kinds of information for the renderer, the physics engine, the audio engine, scripting, animation, AI, networking and so on and so forth. It's stored directly within the file. All of this is cool for a developer, but it means that your audio player won't be able to decode these files anymore. It will encounter data in the file it doesn't know what to do with. This will typically require //conversion//.
-Especially when it comes to stuff like game audio (which is what I am mostly interested in), games like to use third party software to help them with the development of the game's audio implementation. It's a bit like a video game engine but for audio, and it's on top of the video game. So when you run these games, you will often also be running a WWise session that tells the game what to do with its audio. Software like WWise have their own specialized formats which, in some cases, are also their own type of container files. Classic examples here are .wem and .bank files. Wem is an audio format, while .bank is a "soundbank", ie. a file containing multiple, individual audio files.
-If you are new to this, you are probably looking for a .wav or .mp3 files, which you consider proper audio files (not at least because most audio players only understand these and similar file formats). In this case, files like .wem need to still be converted, and .bank files need to be extracted. The exact approach here differs based on the exact type of file you're looking at.
+This is why it's useful to know what is a plain file and what isn't. Understanding the type of file you're looking at helps you determine the correct next step. The OGG format, as you will find it in [[Minecraft]]'s assets for example, is not a proprietary format that requires hours of googling to find the right tool to extract from it. It is a standardized audio format that ~~many~~ a considerable share of audio players already support by default or, if not, can be converted easily. It is common inside of video games due to its file size to audio quality ratio but not often seen in the wild.
-For example, there are tools out there that are specially designed to convert .wem files. They come with an input and output folder and basically all you do is running a batch file to convert wem files you pasted into the input folder.
+===== Container Files =====
+When nearing completion, games made in game engines need to be "baked" or "cooked". That means compiling the game so that it no longer is a project file in a developer's game engine but rather a finished product that can be played by players. During that process, many game engines take all the game assets, index them and store them in [[Container File|Container Files]] from where they will be loaded when the game is played by a player. These files are essentially just a bundle of many files, comparable to ZIP or RAR archives. Like ZIP or RAR archives, they cannot be loaded directly and require specialized software to read.
-A more comprehensive solution would be to use [[vgmstream]], which comes with direct decoding capability for a vast array of video game sound formats, including most middleware and proprietary sound formats for platforms like Playstation or Nintendo consoles, but vastly exceeding just this. With vgmstream you can listen to .wem or .bank files directly without even needing to convert. But obviously it still has full conversion capability and lets you convert sounds from its home format to any other format vgmstream supports, including .wav and .mp3.
-vgmstream is technically a command line tool, but also comes as a plugin for [[foobar2000]] and another audio program I don't know the name of off the top of my head. Foobar2000 already provides an immensely useful graphical interface for managing audio in all kinds of way, including playback, conversion, batch renaming, tagging, playlisting and so so much more. The vgmstream plugin for foobar extends it by adding decoding capabilities for a sea of video game audio  types which also means that it can easily convert between all of them (or just listen to them if you want). I've been surprised multiple times in the past that I was able to extract some weird, proprietary audio format from some game I liked, chucked it into foobar and it literally just played the file as if that was completely normal. Hell, you can even drop in .zip or .rar files, and if those archives contain readable audio then foobar //will// play it, no prompting for extraction. At this point it's genuinely more difficult to find a piece of audio that it //cannot// read, decode, playback and convert.
+Middleware does this as well. BANK files are container files generated by [[FMOD]] that contain multiple audio files (typically). Opening them requires knowledge about how those files are structured. To see all of this in action, you should read [[Extraction Tutorial]].