Ripping Tutorial

Let’s start with something simple - we are trying to rip a character sprite. Using nocash PSX VRAM Viewer, we can see the sprite is a complete sprite.

Remember - data need to be read to RAM before it can be transfer to VRAM. So we need to explore RAM for traces of the sprite.

Unfortunately, while nocash psx is very useful, it doesn’t have some necessary features to help us explore RAM. so we use Cheat Engine to workaround its limitations.

The first thing we need to find is the base RAM address. We need to tie Cheat Engine address back to nocash PSX address. So we go to Cheat Engine Scan Settings and turn on MEM_MAPPED.

Now make a Save State at nocash PSX. Then goto RAM 80010000 and edit in byte sequence "41 79 61" (Aya). Use Cheat Engine to search for this byte sequence.

So we get an address b09100 from Cheat Engine, and that is correspond to 80010000 on nocash PSX.

The size of PSX RAM is 2MB, from 80000000 to 80200000. That would translate into Cheat Engine address as:

Now we can use Cheat Engine to explore PSX RAM. We are looking for graphic data, so we open Memory Viewer subwindow, and select View → Graphical memory view.

We will need to look for anything suspicious at address from af9100 to cf9100. Refer Raw Image Data for more details.

We found the graphic data at c9f5a. Using the base address, we can translate it back to PSX address.

Let’s go back to nocash and double-check if we are doing it correctly and looking at the same data.

YES! They are both indeed the same!

Now we can put a WRITE breakpoint to look for the decompression function:

The data is READ from t2 at RAM 8004ef70 and WRITE to a0 at RAM 801a5f50. Now we can use the data at t2 to locate the original game file.

Since the game files still have their original names, the task becomes very easy. The character name is Karin, so obviously the file is data/act/kari.act. The data is then located at offset 0x4f1e9.

With the original game file and the decompression function found, and also have decompressed data to verify against with, we have pretty much everything we need to start coding.

Here is the result with all sprites decompressed and packed into a texture atlas:

It is an alternative method to explore RAM when Cheat Engine is not available, didn’t work or could not be used.

A save state will make a backup for the whole program. It will have a copy of RAM dump in it. So the first step is to find a way to extract the RAM dump from save state.

Luckily, nocash PSX has the option to make uncompressed save state:

Just like Cheat Engine before, we need to find the base RAM address. Goto RAM 80010000, edit in byte sequence "41 79 61" (Aya) and then make a save state.

Since the save state is not compressed, we can simply use a hex editor and look for "Aya" (as string or byte sequence).

We found "Aya" at 99064. Convert it back to PSX RAM address from 80000000 to 80200000:

With that, we can start exploring RAM dump for sprite data. Refer to Raw Image Data for more details.

We discover the graphic data on save state offset 22efe0. Using the base address, we can translate it back to PSX RAM at:

And then we can put WRITE breakpoint to look for the decompression function. Everything is the same after that.

Starting with output data is only possible for visual data. Meta data like texture atlas, hitbox, and animation data, you’ll want to start from input data instead.

The process is mostly the same. Start from a game file (or a section of it), look for it on RAM, and then put a READ breakpoint on the whole thing.

The file is loaded at RAM da8c00. Offsets for each sections are at 0x54 to 0x80. The data we’re interested in is on section[8] (or s8), from offset 0x13b440 to 0x157080 (size = 0x1bc40).

With that, we can put a READ breakpoint on the whole section[8].

By noting down the ASM code on every break, we have a very good idea how the data is read.

Remember - we are looking for relevant function for further analysis later. So write down the ASM address along the way.

Using the ASM address above, we can conclude there are 3 function parsing the data.

Function A seems to be doing End of Animation + Looping check. It also have SFX/voice playback.

Function B seems to be doing math to normalize animation rate from FPS to value between 0.0 to 1.0.

Function C is a rather huge function and seems to be drawing function with a final draw call to GPU.

With the ASM address, we can have a proper understanding how certain things work. For example, data[10] read at ASM address 1724c4 will lead us to 2 if’s and 2 function.

When data[10] is 2 or 1, each will lead us to a function. For anything else, use the current frame only.

Let us examine what these 2 function do:

The function accepts 4 frames as arguments. Based on the code using power of 2 and power of 3, we can guess the intepolation is based on polynomial formula:

Arrange the algorithm from the screenshot according to Polynomial formula above:

Then convert it to matrix form:

The 4x4 matrix is the Characteristic Matrix, and it matched Catmull-Rom Spline [catmull].

We can say for certain - when data[10] is 2, do 4-frames Catmull-Rom Spline interpolation.

This function is a lot more simple. The formula is just:

So when data[10] is 1, do 2-frames Linear interpolation.

Meta data can be something hard to observe with videos and screenshots. And game can lag and skip frame to maintain performance further complicate things. Having the ability to refer to ASM code will help eliminate a lot of these guesswork.

To be able to start from input data, you’ll need to know which files is actually loaded for the scene.

Let’s start by looking for a file list on RAM using a file name from the game

We found the the file at RAM 8aeb410. By observing the pattern, the file entry is an array ["FILE.NAME", int32 LBA, int32 file size] and has fixed 0x1c bytes size.

Looking for where the list begins and ends, we discovered the area for the whole list is from RAM 8ae6ae4 to RAM 8af51e4 (size = 0xe700).

As usual, when we have something we want to inspect, we’ll put a READ breakpoint on the whole thing.

As the game search by file name, the ASM code is about comparing every character for a match. Even PPSSPP able to recognize this function as strcmp() (string compare).

We are no interest for strcmp() itself, but the parent function that called it. We will use "Step Into" until the function returned. We end up at ASM address 89e38e4.

With that, we can use Ghidra [ghidra] to decompile the function.

SUB_001ecdbc is strcmp(), so basically the function is about looping a list of 3000 file entries and return the file entry when it matched.

Since READ breakpoint will always break at strcmp() on every file entries, with a list of 3000 entries, it is no longer usefule for us.

This is where we’ll disable the READ breakpoint. and use EXECUTE breakpoint instead.

We will put EXECUTE breakpoint when the file entry matched and ready for return, at this 2 ASM address:

By keeping track of value at v0, we will get a list of file names the game trying to load. For example, when Gradriel went into Valenadine City Pub, the game will look for these files (in order):

When the file loading order is known, we also reduced the number of files we are working with from 2000+ files to just 7 files.

This technique is also useful on these situations

Some interesting facts about RAM (Random Access Memory)

In essence, image data is like an ASCII art, with 1 character representing 1 pixel. Example:

The ASCII art "BIG" above has 21 characters per line and it has 5 lines. If converted to an image data, you’ll get a 21x5 pixels image, with each letter "B","I","G" is 7x5 pixels image.

Here is an interactive example for raw image data:

Here’s how the same raw image data looks on different apps:

The drawing XY are in space-like coordinates, similar to 3D space. The XY can be from -infinite to +infinite px. So all sprite are aligned with [0,0].

Basically, like 3D models, [0,0] makes the sprite coordinate self-contained. The game can then "transform" the sprite to its in-game entity position.

Some people refer [0,0] as "origin" or "root". I call it "center point". And here is an article referring it as "hot spots" [mckids].

Here is the process how I convert XY from pixel space to canvas position:

From the image above, the drawing XY for sprite is [-130,-160 , -130,10 , 150,10 , 150,-160]

First, we’ll need to prepare a canvas large enough to hold the full sprite. We will use the absolute value [absval] of the drawing XY to calculate the size.

The absolute values for X are [130,130,150,150]. So the canvas width is:

The absolute values for Y are [160,10,160,10]. So the canvas height is:

With that we will prepare a 300x320 px canvas, with [150,160] represent [0,0] in pixel space. The sprite will be drawn at

The result drawing position on the canvas is [20,0 , 20,170 , 300,170 , 300,0].

It is also very simple to revert canvas position back to pixel space - just subtract [150,160].

Since everything is aligned to [0,0] in pixel space, it doesn’t matter what the final canvas size is, they will all align together correctly for animations.