Manually ripping/reinstering textures in a Playstation game.

[sb iq]

Hello. I am a newbie to the game hacking scene and I would like to know how to rip/reinsert textures in a Playstation game manually using a hex editor. The reason is there are some games out there that do not use the TIM format for textures, so those TIM rippers/reinserters are pretty much useless on those games.

I have looked for comprehensive beginner's guides for this sort of thing but cannot find any. If anyone can link me to a good text or even explain it to me it would be greatly appreciated.

But before you tell me a lot of complicated hax0r terms, keep in mind the most l33t thing I have ever done is pass first semester C++ at a university with a B-. They didn't teach us anything about hex editors or hacking ROMs. -_-

I really would like to learn though, so please excuse me if I ask questions that seem stupid, like what a byte is. Yes, I know the definition is "8 binary digits" but what does that mean in practicality when I am using a hex editor? Is a byte a line of code, etc.? I really don't know.

 

[zAlbee]

A byte is 8 bits. A bit is 1 or 0. The smallest byte is therefore 00000000 (zero) and the largest is 11111111 (255). You can think of a byte as a number from 0 to 255. One character is represented with one byte. This means 256 different characters are available - if more are needed, different character encodings can be used, so the same byte can have several different character meanings depending on the encoding.

An unsigned short int uses 2 bytes (16-bit), which means 65536 integer values are possible (0 - 65535). A signed short int uses half of those numbers for negatives (-32768 -to +32767).

An unsigned int is 4 bytes (32-bit), so has 4,294,967,296 possible values. Again, signed means half are negatives.

long int is 64-bit
float is 32-bit
double is 64-bit (the way floating point works is the first few bytes represent the base, and the rest is the power of 2, eg. 1.2345 x 2^123)

CPUs based on x86 use 32-bit memory addressing, which I believe makes your C pointers 32-bit (correct me if I'm wrong)

 

[Cyberman]

An unsigned short int uses 2 bytes (16-bit), which means
65536 integer values are possible (0 - 65535). A signed short int uses
half of those numbers for negatives (-32768 -to +32767).

Ehhh.. I think you should be a little more precise when you say things.

Standard representation of a short int is a TWOS compliment 16bit
binary string. Then you won't have to say all the other jabber. This is
also compilor dependant. You should say 'depending on your compilor'
because at one time shorts were 8bit values on old machines. Nothing is
simple. The best way to deal with these things is to say BYTE WORD
DWORD QWORD OWORD for 8bit 16bit 32bit 64bit and 128bit values
respectively.

An unsigned int is 4 bytes (32-bit), so has 4,294,967,296 possible values. Again, signed means half are negatives.

No... 0 is neither positive or negative (it's 0 or nothing)
there are 2^31 negative values and 2^31 -1 positive values with signed
values. It is also COMPILOR dependant. You are using incorrect
terminology. Endianess is another thing which adds interesting fun..

long int is 64-bit

float is 64-bit

double is 128-bit (the way floating point works is the first few bytes
represent the base, and the rest is the power of 2, eg. 1.2345 x 2^123)

First long int is compilor dependent so it might be a 32 bit value. A
long long might be a 64 bit number (yes there is the long long ICK).

Second float is ALWAYS a DWORD period it does not change as this is the
standard. If you are not speaking of a ANSI C or C++ compilor then God
only knows what it is.

Third double is ALWAYS a QWORD or 64bits. in ANSI C or C++, a non compliant compilor again caveat empor.



Lastly a 128bit float is quad precision and is supported on some machines.



See here for some terse details on IEEE754 standard and here for many papers related to the standard (IEEE 854 adds handling of decimal numbers).

CPUs based on x86 use 32-bit memory addressing, which I
believe makes your C pointers 32-bit (correct me if I'm wrong)

Hmmm this is now a very complicated issue, since machines had to move
to 64bit within the last 5 years, so this now depends on the what CPU
you are using.



Cyb

 

[Cyberman]

Hello.

Welcome to Emutalk!

I am a newbie to the game hacking scene and I would like to know how to rip/reinsert textures in a Playstation game manually using a hex editor. The reason is there are some games out there that do not use the TIM format for textures, so those TIM rippers/reinserters are pretty much useless on those games.

Don't I know it? There are TMD files which don't necessarily use TIM data. It really depends on what the original game was. If it was made for the PC and ported then .. its not going to have TIM's in it. They used all sorts of screwy formats. Life is inconsistant. Unfortunately Sony really SCREWED UP the PS2 SDK and thus it's even more screwy for various formats as a result. They bought a company to develope support software for there gaming systems as a result of just how screwed up PS2 developement has been (so they are making hopefully a better SDK for the PS3), the learning curve was basically 6 to 12 months before useful code could be put out.

I have looked for comprehensive beginner's guides for this sort of thing but cannot find any. If anyone can link me to a good text or even explain it to me it would be greatly appreciated.

Hmmmm I use to have Pixels site for doing these things to PS1 ISO images. In summary you need to scan the sectors and piece together the data from the sectors. If the textures are compressed (FF7) you are in probably in trouble. Most PS1 games use absolute sectors to reference data. Some use data that's not visible in the ISO9660 tables on the system (Xenogears does this). Others cluster everything into one BIG file (FF8 and FF9). So you need to find the textures on the disk first. I suggest making an ISO image from your original game disks and HACK on that. Do not expect to be able to burn and play the hacked disk on a PS1 you will have to use an emulator due to the copy protection on the PS1. One fortunate thing is most textures are not compressed.

But before you tell me a lot of complicated hax0r terms, keep in mind the most l33t thing I have ever done is pass first semester C++ at a university with a B-. They didn't teach us anything about hex editors or hacking ROMs. -_-

Hex editing is pretty much that it converts byte information into hex digits which you tweak. This is NOT how to modify textures in a game the easy way LOL. First you need to extract the data. Then you need to edit the data. Lastly you need to reinsert that data. That is the easy way. If you want to edit an ISO image directly, this is a VERY difficult thing to do.
I would give you pixels huge work on doing this and util but I don't remember his site and www.romhacking.com is no more (sadly) so this is the best I can do for now it has a brief description of file systems et al.

 

[zAlbee]

Ehhh.. I think you should be a little more precise when you say things.

Standard representation of a short int is a TWOS compliment 16bit
binary string. Then you won't have to say all the other jabber. This is
also compilor dependant. You should say 'depending on your compilor'
because at one time shorts were 8bit values on old machines. Nothing is
simple. The best way to deal with these things is to say BYTE WORD
DWORD QWORD OWORD for 8bit 16bit 32bit 64bit and 128bit values
respectively.

True, I was mainly explaining it in a general way, as I doubt he knows what two's complement is. Also, it is compiler

As for compiler-dependency, I come from a Java background which is standardized cross-platform.... The only two C++ compilers I've used have the same precisions as Java, so that is something I did not know.

No... 0 is neither positive or negative (it's 0 or nothing)
there are 2^31 negative values and 2^31 -1 positive values with signed
values. It is also COMPILOR dependant. You are using incorrect
terminology.

Right, damn math.... Seriously though, for all intents and purposes, if you pretend zero is a positive number, behaviour is no different and it's very easy to remember -- same number of "positive" and negative, as well as unsigned always being "positive". I do believe that 0 is signed in floating point (+0 and -0), which is kind of interesting.

Endianess is another thing which adds interesting fun..

Personally I don't know anything about Endianness, so feel free to elaborate

Second float is ALWAYS a DWORD period it does not change as this is the
standard.

You're right about float/double. I did this from memory and doubled the precisions by accident. :blush: I'll edit my message to prevent confusion.

CPUs based on x86 use 32-bit memory addressing, which I
believe makes your C pointers 32-bit (correct me if I'm wrong)

Hmmm this is now a very complicated issue, since machines had to move
to 64bit within the last 5 years, so this now depends on the what CPU
you are using.

Yup. It's one of those things people might be interested in now that AMD64's are getting popular.

 

[zAlbee]

An unsigned int is 4 bytes (32-bit), so has 4,294,967,296 possible values. Again, signed means half are negatives.

No... 0 is neither positive or negative (it's 0 or nothing)
there are 2^31 negative values and 2^31 -1 positive values with signed
values. It is also COMPILOR dependant. You are using incorrect
terminology.

By the way... I read this again and noticed that i did not use ANY incorrect terminology. Half the values are negative, which is true, I never talked about zero. Suck it.

 

[Cyberman]

Pixels Site Found!

Ok to the orignal poster

Here is Pixels Site.
This is the URL for the CD-TOOL I was speaking about. It's complicated but there are a number of explanations Pixel gives reguarding ISO format etc. This tool is QUITE good it's specifically designed for patching mangling creating twiddling or otherwise playing with an ISO image.

Cyb

 

[sb iq]

Thank you. If you remember my post at romhacking.com, I was looking at Tomb Raider which is a port of the PC game.

I remember you posted some hex code and said that the code meant there was a texture there. What I was wondering is how you were able to recognize that code as texture apart from the rest of the code. What patterns should a newbie look for? What math formulas should I use?

 

[Cyberman]

Thank you. If you remember my post at romhacking.com, I was looking at Tomb Raider which is a port of the PC game.

I remember you posted some hex code and said that the code meant there was a texture there. What I was wondering is how you were able to recognize that code as texture apart from the rest of the code. What patterns should a newbie look for? What math formulas should I use?

Ahhh recognizing bitmaps is an artform.. well not really in general an indexed bitmap (IE one with a palette) does not have the numbers randomly picked. The ussual algorythm sorts the numbers etc by frequency. Ussually the lowest numbers are found first etc. etc. This is important because when you see data if you see a pattern of data that somewhat repeats itself say every 128 bytes. It's obvious there is a pattern, this pattern can be thought of as part of the image when you are looking at the list of symbols representing the image.
Bitmaps commonly have this kind of repeatable pattern and you can recognize for example 'solid' regions of a bitmap this way. Even if the bitmap is 4 bits per pixel The hexdigits will show said pattern.

That's pretty much it. Your eyes get use to spoting patterns of data.

Another example for finding a list of 32bit pointers or offsets you will notice 'banding' in the columns of data. IE

FE830000 C2C10000
etc. etc. this repeats for several lines in the hex view. Obviously it's a list of 32 bit little endian integers

Cyb

 

[sb iq]

So whenever the pattern stops, that is the end of the texture? How many bytes is one line of code when viewing something with a hex editor?

Also, if I use a debugger or GameShark to see what code is being executed whenever I reach a portion of the game that contains a texture I wish to edit, will it give me clues as to where that texture is?

 

[Cyberman]

So whenever the pattern stops, that is the end of the texture? How many bytes is one line of code when viewing something with a hex editor?

Also, if I use a debugger or GameShark to see what code is being executed whenever I reach a portion of the game that contains a texture I wish to edit, will it give me clues as to where that texture is?

I suggest finding the pattern, the begining and end of a texture are the tricky part. I guess you will need to look at the data a lot before recognizing that. As for what is a line of code, I don't know what you are talking about perhaps you've got a few things confused.

Hmmm seems to me you are VERY confused, textures are never embeded into the game code. It's always loaded as data in files. The data files have NO code in them. Using a debugger is not overall useful unless you know exactly where they load data in, (memory that is). Then you need to watch the memory and not the code.

Tomb Raider stores level data and the engine interprets the data. You will not find texture data mingled with executable code. The data files contain the data you are looking for. You won't be easily able to find where the textures are being loaded in etc etc add infinitum on the playstation. Why? because most of the people used low level ISO9660 sector reading routines to do the dirty work.

Cyb

 

[sb iq]

Hmmm. I loaded the level WALL.PSX in TR2 and looked at the hex for hours. The only pattern I could find was that there were zeros for 30 bytes everynow and then. Then I found something peculiar at hex address offset: 92988 [0x00016B3C]

When I have my resolution set at 1024 x 768 and open that file with Hex Workshop (window maximized), I notice a "slope" for the number 3000.

Here is a sample:

3000BF1D34B00D16B1FE06D2FC15E2FB300024F1EC4210DC5120CC4112BD50123000CD6E31CC6E31BD6E02B05DF3C12D3000F5D10D05F1FB25F0EC3400DC43F13000CD52F1CD4211DC4012DD5E02B02F300004D02CF5C20D05C3FC16E1FB06F23000FA2510FA521FEB4200DE3002CF10300023DE1E24CF0E25DF0D24C1EE34D1

Paste that into a blank file, open it in Hex Workshop, window maximized at a 1024 x 768 resolution, and look hard enough to notice the "3000" slope I am talking about.

Could this the beginning of a huge texture? According to my research, in a TR level, somewhere in the hex code there will be one huge chunk that contains all the textures in that level. Could this be the start of it?