how to change file sizes on ISOs (Annotating SCUS_942.21)

[rixim]

The reason things cannot simply be added to the game is because the data in the ISO is accessed by "offset" not by file name. So when we change the size of a file that changes the offsets of many other files. The way to fix this problem is figure out where all the offsets used to access files are on the ISO  , create a map of the ISO based on this information, then replace every occurrence of file access in the binary when the size of the ISO is changed.  That's not the most detailed explanation, it's more of a review for people who already know what i'm talking about.

The important thing to take away is that if we want ADD something to the game without taking away something that's the same number of bits we need to create a map of every place where files are loaded into ram in the program.

In order to acomplish this goal, I've started doing analysis of the scus_942.21 file using IDA. It's very slowing going because I've only written assembly before, not reverse engineered it. and i've never worked with MIPS before. I guess this post is me asking for help. I have started the reversing process and can explain to people the basics of it. It's not difficult, it's just very time consuming.

It's also worth mentioning that reversing the SCUS is the first step to being able to modify ANYTHING in the game however we want.

suggestions and comments are welcome.

i also have a HTML version of the assembly available upon request. (it's a 10mb file, i might make a torrent of it or something.)

[Vanya]

Might be a good idea to contact Melonhead about this. I imagine that since he made the editor that he has a lot of knowledge about the game's structure already.

[NeXaR]

If you manage to do it, should it be applicable also to PSP? (the main file container of the PSP game have the scus file inside like in PSX, but I don't know if it's used, really)

[karsten]

intersting. i'm looking forward to where we'll be heading

[Vanya]

This IS the biggest barrier to making astoundingly awesome hacks. The only other thing would be more control over editing. And I suspect mastering offsets would go a long way in increasing our editing power.

[Lupus Erectus]

rixim, to find the table of file indexes I suggest to search for their LBA in the game files. They should be in little endian format. The SCUS should be a good place to start, but there may be more in other files too. With the LBA you should find the file size data. It may be specified as exact file size, number of sectors, or file size rounded up to the nearest multiple of the sector size (which is 2048 bytes)

Some files may be indexed differently, for instance in a certain game the first file in a certain folder has the LBA hardcoded in the game program, and subsequent files are indexed by a table that lists simply the size (in sectors) of each file. Leave ASM for cases like this Anyway, doing it only with IDA will drive you insane. Use a psx debugger like pSX or Agemo PCSX. The latter lets you set a break when the CD is read, so you can trace where the LBA for the file being read comes from.

If you're serious about reverse engineering FFT, you should look for the official documentation for the psx SDK (which is copyrighted material...).  IDA has the signatures for that.

If you have more questions, romhacking.net is a good place to ask. Good luck

[Cheetah]

Very exciting stuff. Keep up the good work and I only wish there was more I could do to help.

[sakura]

I would be very interested in helping with this, and I have experience with reverse engineering MIPs code. So far only with N64 games, but I'm sure there won't be too many differences between that and extracted PSX files. If I could at least see the HTML disassembly, that would be great.

[gomtuu]

I know that the .GNS files in the MAP directory reference other files (the other files in the MAP directory) by LBA/sector number.

[CidIII]

Are you still working on this?