Hacking PS2 game files - Extracting images?

Hey Gang,

Is anyone here experienced with hacking/extracting PS2 game files? Specifically, reversing odd graphics formats used to store images with on disk?

The reason I ask is because I agreed to help a friend figure something out and I'm stumped. On a hunch, from what I can tell, the images on the PS2 disk seem to be stored in a binary which contains multiple images appended together. The image format appears to be in some kind of header-less palette + raw BMP data format? But I can't seem to unscramble the images, let alone figure out a way how I can easily separate the images from one another.

If anyone is experienced in this kind of hacking, please do send me a PM. I'd be willing to offer a free Dreamcast SD card reader as a reward for anyone who is skillful enough to figure it all out.

Thanks,

EDIT: Here is a sample people can download to try and figure out.

As you can see from my initial investigation, it appears that the first 1204 bytes are palette information (Or I'm totally wrong and it's some other kind of meta data) and then raw BMP data appears. I know the image under it is a larger portrait of some kind for this character, but I have no idea how to unscramble it.

 

not an expert and can tell you this for free:
they're not ALL a standard. i've tried with various images, and failed.
it's true they're in a container file, but it's custom per game basis usually. (some game devs may use the same format if from the same house or a game series, but NOT always, a shot in the dark really)
one game on the ps2 i was able to get the CDDA files of was alien hominid, couldn't expand the other data, sadly.
a user on here was extracting some picture images from RECV. (iirc)
...
good of you to offer an item for help though.
all the best achieving objective. :smile-new:

 

Maybe the file headers are embedded into the game's main ELF file?

 

@amiga1200: Well, I know the images are appended together, and I know at least some images are stored as raw BMP data because when I open a file, It appears (to layman eyes) that the first 1024 bytes are palette information and the following is image data. Ie. You can actually see the image using something like GIMP. the only problem is, even after applying the right color palette to the image it still looks really off. So there is something I am missing. It also doesn't help that the other images in the same file don't even show up correctly. Maybe the are in a different raw format or something I'm not aware of.

@root670: I don't think so. Even if they were (I looked using a Hex editor) I don't know if I would be able to tell or not.

 

If the file contains several separate images of varying sizes, you will not be able to view all of them at once. You need to separate each of them and view them individually, as their widths are different.

At worst, you need to disassemble (a hex editor will not do!) the game to find out how it deals with these images.

 

Yep, I understand this. I tried adjusting for width to see if anything would appear in any meaningful way, but it still looks all jumbled. Sometimes you can kind of make out faces and things, but it's still terribly distorted. There must be something I'm missing.

 

Id go and have a look at the file (Im kind of in the same situation, except my files are from a konami game, which makes things FUN), but unfortunately its 403d, so may I kindly ask for a mirror/reup?

 

Hey. Thanks for the catch. I fixed the link so have another go at it. Hopefully you can make more of it than I can.

 

Hrm, could you post a screenshot of the graphic when its displayed ingame? That might help with the palette things.

 

Sure, I can do it later tonight when I get home. However, it still won't solve the problem of decoding the other images. The first image is just a palette issue, while the other larger images just don't show at all. As you can see from my screenshot, they just look scrambled, regardless of the width settings and offsets I use.

 

I'm not sure whether or not it'll help, but this is what it looks like when you assemble the rest of the 256 pixel wide rows from the end of the file into 768 pixel wide strips. I also overlaid each of the 4 copies of the image with photoshop and they look identical. I'm no expert by any means, but to me it kind of looks like 2-4 frames of an animation vertically interleaved and maybe one color channel + alpha; since there are 4 copies of it.

 

Ah, that's interesting. How did you end up laying it out in 768 strips? Is there an automatic way of doing that, or did you do it by hand? If I had to guess, the little lines in between images (which look the same) are palette data?

As for the images themselves, we can start to make things out at 768, but even if it were colorized, the graphics still look rough and incomplete. Perhaps the images are being squished/stored in a special way for rendering on the PS2 we're not aware of? Or perhaps it's just we're reading in the data wrong?

 

I did it all by hand, but I'm willing to bet there's way to automate it using imagemagick. It's also worth noting that the white space between the last two images wasn't actually in the data, I just added that to make everything line up better. Maybe this is just the save icon or something, that could explain why it's so low quality. It's also possible that the image is encrypted using ECB (see here), maybe that'd explain why it looks so bad.

 

I only take a look at 2 images. The first one is 8bit indexed image with 32bit RGBA pallete. Pallete size is 1024 and starts before image data. The main problem is no information about image resolution. With trial and error I found that first image is 256x128.



Next one is also 8bit indexed image with 32bit RGBA pallete but resolution is 64x672. Image data is swizzled and image is cut in parts.



Best way to extract images is by finding file with informations about resolution and etc.

Sorry for my bad English.

 

Wow! Nice job, that looks awesome!

 

Wow, that is amazing! Are all the palette information the same for each image (1024 bytes)? Also, how are you applying these palettes to images? A de-swizzle tool would be useful as well, but I can always write something for that.

EDIT: I'm trying to use GIMP to decode the image but I am not successful. Do I need to cut all the images out first, then attempt to guess the image Width and Height? What tool are are using to generate the images you created? Maybe more information on how you assembled your final pictures would be great.

 

Ok, so without the original poster replying as to how they got the image ripped, I wrote a little java program to read in the palette data and BMP data to create a PNG. However, it still appears to be messed up as my colors are not as good. This is what I am seeing:



Some of the colors look ok, but some are not. I assume there are 4 bytes per each color palette. That is, one byte for red, green, blue, and alpha? And then in the BMP data section, each byte represents the integer index number for the palette?

Maybe I'm parsing the color palette wrong? Hopefully I don't need all of this if there is an automatic way to do this (Using imageMagick) or someting, but I figured I'd ask if anyone knows what I'm doing wrong.

EDIT: My code could very well be bugged as well. Crossing fingers that conan14 has a simple program, tool or method to reproduce what he did.

EDIT: I don't understand! In the original image posted by conan14, the first pixel is clearly almost black (0, 0, 8). However, if I read the BMP data the first palette index is '17' hex, which as an unsigned int is 23. And at that palette index, the color is #57348a which is purple? Is the first set of '00 00 00 00' supposed to be dropped and not included as a palette entry (Ie. it was a header)?

EDIT: So far I have been ignoring the alpha value for the color palettes because it always gives me this semi-transparent look over the whole image which appears to be wrong? For example, in the 2nd palette color you can see the hex '6C 91 99 80'. Currently I ignore '80' since I assume that is the alpha value. But because they are specifying it, I suppose I should be using it? Perhaps I'm applying it wrong to my image?

 

I just extracted image data and pallete and added tim2 header with specific parameters. Then I converted it to png and ignored alpha channel. There is a tool to swizzle and unswizzle called ezSwizzle and some code in c too. It's using tim2 file format. As I wrote better way to extract those images is by finding headers with needed informations. If there are more pictures to extract it will be hard to do this by hand. In attachment there are those images in tim2 file format. Your image looks like it has wrong colours order. Pallete index starts from 0.

 

I figured out what was wrong with my first image. The palette in yours has a few rows which are swapped. That is, first 8 palette is ok, then next two blocks of 8 are swapped with each other, next 8 palettes are ok, then next two blocks of 8 are swapped, etc. After fixing my code to copy that method, the image shows up just fine!

However, for the 2nd Image. I'm not sure about what format that would be. I tried to read the 1024 byte color palette (offset 33792), then apply it to the BMP data (offset 34816 + 43008 bytes (64x672 size)) but it doesn't look like your image. In addition, I tried to take your TIM2 header + BMP data + palette to re-create the file you provided, but it ends up being much smaller than your sample file.

It seems like your sample image "image2_swizzled.tm2" has much more BMP data than mine? Where did this come from? Do you know what the TIM2 header specs are? Right now I am just copying your header to guess. But for the first picture, I can render it fine using my own Java code. But I suspect the same method won't work for swizzled image.

Please let me know! If anyone else knows more, please let me know too!

EDIT: Oh, TIM2 file reads 32-bit depth, not 8bit. So when I increase the size to 172032 I can add the header and copy the sample image.

@conan14: So using the TIM2 headers you provided I was able to de-swizzle all the same images from that file and extract them successfully. However I do have potentially other images I'd need to rip. Do happen to have the specs for the TIM2 header so I can create my own modifications for that? How did you end up guessing what resolution you needed to make for the 2nd image since it was swizzled? If you had the proper header, would it be possible to just randomly take: Header + BMP + Palette, and see how it looks opened? Or will swizzling make the image look unrecognizable until it is de-swizzled? I guess the big issue for me now is that I don't know the TIM2 header format so I have no idea how to specify how big or small an image should be.

EDIT: I tried looking for the source code for ezSwizzle to see if it has header information for TIM2 files, but the main website is down. Anyone have a mirror?

 

Strange, I just copy it without any swap.

Just read what swizzling is. 64x672 resolution is after swizzling and image is treated as 32bit. Since pallete is 32bit we can know that image was 8bit indexed. After unswizzling image data is changed. Now it can be read as 8bit indexed with doubled resolution.