News:

11 March 2016 - Forum Rules

Main Menu

SRW Z2 Menu Translation Help

Started by TitanAnteus, July 15, 2012, 12:26:45 PM

Previous topic - Next topic

TitanAnteus

OK so this is the main reason I'm here, and if I say anything stupid please call me out on it.  :-[

I'm trying to translate the menu for Super Robot Wars Z2 Hakai-Hen a PSP game.  I've got the ISO and have taken a look inside.
For those unfamiliar with the PSP game format.  This PSP game looks like this.

SRW Z2.ISO
  > \PSP_GAME
       > \INSDIR (Some games don't have this but this game does. I believe in this game this would be where all the images and sounds are?)
             DATA000.bin
                  |
             DATA020.bin

       > \SYSDIR (I believe this only has launching information with no actual game content)
            >...

       > \USRDIR (This folder changes the most compared to other games)
            >\BTL2(I think this is where most of the data is)
                >...(Other files)
                >SRVC.bin
                >...(Other Files)

            >\HIYAMA(This only has name entry data files)

            >\KURO
                >STG_Z2.bin         (only two mb)
                >STG_Z2_TBL.bin  (1 kb)
            >000001.PMF
            >VEFF2DX.BIN
            >Z2DATA.BIN
       ICON0.png
       PARAM.sf0
       PIC1.png

  > UMD_DATA.bin

The reason I point out SRVC.BIN is because it's fully uncompressed/decrypted.  It looks like this HOWEVER; SRVC.BIN is the text the people shout mid battle ("Don't underestimate the Titans"  ;)).  All other files basically look like this. In a nutshell.

And that's all I know and where I'm stuck  :banghead:.  I was on the IRC yesterday and after speaking with some really good people  :thumbsup: I learned that the files I need might be either compressed or encrypted.  I just want to get to the menu text.  It's not a full game translation.  Please help me.  :)
_______________________________________________________________________

EDIT:
By using UMDGEN I've learned that all the files are uncompressed which can only means they are encrypted.  Also for some reason BOOT.BIN is all 0s in the hex editor. I'm not liking where this is going, but I refuse to give up.

Auryn

Well, sorry to be harsh but from what you write in here, or the people you talk about have no idea about PSP or you didn't understand a thing of what they said.

>INSDIR (install directory): normally you find the file that the game install on the psp memory card to speed up access to the most used data.
If the game don't force you to install anything, you can probably forget about this directory.

>SYSDIR/UPDATE (System directory): it only the actual firmware that the game need to run. Forget about it.

>SYSDIR: you are right, it the first that will be loaded and launched but what you think is this?? Maybe the main/core programming of the game?? Yes, it is and it so important that it will always stay in the RAM till you go back to XMB. This is also the main place to search for your menu.

>USRDIR (user directory): here you will find all the parts of the game that are loaded in memory only when needed. This is the second place where you want to search for the menu.

>USRDIR/xxx: are all custom sub folders created by the game programmer. Normally the name indicate the contenent but you can never bet on it.

>ICON0, PARAM, PIC1: are files used by the XMB. param is the file that say to the PSP what firmware the game wants and check this before it runs the game. The 2 PNG are nothing else as the little and the big image you see in the XMB just before you run the game. There can be a .at3 file (sound) or a .pmf (video file) with them as well.

>STG_Z2.bin         
>STG_Z2_TBL.bin  This pair of files (i believe there are many similar to this in the game) are probably an archive and it pointer table. The contenent is unknow but probably specific to STaGe Z2.

000001.PMF: is a video.

All other files in the game are good candidates and the 3rd place to search for the menu.

Anyway, because I am sure you will be finding something in the EBOOT/BOOT.bin, i can tell you already that you will corrupt the game so google for UMDGEN that contains the solution to this problem.


TitanAnteus

#2
Quote from: Auryn on July 15, 2012, 03:47:21 PM
Well, sorry to be harsh but from what you write in here, or the people you talk about have no idea about PSP or you didn't understand a thing of what they said.

...

All other files in the game are good candidates and the 3rd place to search for the menu.

Anyway, because I am sure you will be finding something in the EBOOT/BOOT.bin, i can tell you already that you will corrupt the game so google for UMDGEN that contains the solution to this problem.

Thanks for all the valuable information, but I don't understand what you mean by "I am sure you will be finding something in the EBOOT/BOOT.bin" and that I will corrupt the game.  Please elaborate.

In the meantime I'll get UMDGEN.
______________________________________________________________________________________________________________

EDIT: Alright so I looked at EBOOT/BOOT.bin and I saw some things. 

First things first though.  I downloaded UMDGEN and saw what it does.  It's a pretty nifty program, but I don't see what I need it for yet, however; when I opened it up and went to the Sector Viewer tab, I learned that all the files are uncompressed as they showed up, and UMDGEN states "NOTE: Only uncompressed files are listed."  That can only mean that all the gibberish is encrypted.  Kinda wished it was just compressed.

BOOT.BIN is actually all 0s as well.  I have no idea why.

I've already done a search for the japanese text I need to no avail on all the files. Any guidance would be appreciated.

Updated the original post with all the information I found.

Auryn

BOOT.bin and EBOOT.bin usually are the same but one is crypted. By changing one of the 2, you will corrupt the game because usually the PSP check both. By right clicking on it in UMDGEN, you can fix that.

You never got the idea to search in google for "PSP Decrypter"??
It's been a while since I have done something on PSP but if my memory isn't wrong, that should help you (be sure to find Vers.2).

Just a little note: usually PSP games use Shift JIS to store japanese text but like all games for all systems, nothing can stop the makers of the game to use a custom coding for their games. This means that you will need to search/create a table to "translate" the custom coding to a standard coding you see on your pc and that you will not see (before you use the table) the text in "clear" like the file you mentioned.
Compression can be another cause because you not see the text in clear. Not because UMDGEN say that it's uncompressed (it's actually telling you that the ISO is not compressed) that the game can't have compression in itself.

TitanAnteus

#4
No I tried googling PSP Game Decrypter.  It's just that I thought it was CFW related stuff because that's all that was mentioned.
Z2 cannot be decrypted by 2 different programs.  It was something about the heading being an unsupported address.

StorMyu

Meh stop with the encrypted/compressed stuff, be sure about what you're saying first.

The only thing "crypted" is maybe the Eboot.bin, if the Boot.bin is full of 0's that's quite normal since it's not used (and they are the same)
Use any hex editor and open your Eboot.bin, if you see ~PSP
then it's crypted, and you have to use something (don't remember the name so google for it)

Then, your data are the usrdir as stated.

And you didn't choose a difficult project, you just haven't learn:
http://www.romhacking.net/start/

TitanAnteus

#6
Quote from: StorMyu on July 16, 2012, 10:48:28 AM
Meh stop with the encrypted/compressed stuff, be sure about what you're saying first.

The only thing "crypted" is maybe the Eboot.bin, if the Boot.bin is full of 0's that's quite normal since it's not used (and they are the same)
Use any hex editor and open your Eboot.bin, if you see ~PSP
then it's crypted, and you have to use something (don't remember the name so google for it)

Then, your data are the usrdir as stated.

And you didn't choose a difficult project, you just haven't learn:
http://www.romhacking.net/start/
I do see ~PSP so I guess it's crypted, however; yoshihiro's decrypter doesn't work on this game for some reason.  Also, I already went through the start thing. It's what I filled my time with before I got accepted here. :thumbsup:

EDIT: YES! A breakthrough!
The file header is no longer ~PSP anymore as well.  It's ELF.  I also found some of the text I'm looking for, however; ALL of the other files start with ~PSP.  I wonder how I'd decrypt those.  I'm just curious.

Oh yeah the 5th program I used (ISO_Tool) worked excellently.

_______________________________________________________________________________________________

EDIT2: Well that was extremely unexpected.  Ok so what I did was I used ISO_Tool to decrypt the EBOOT.bin file on my psp.  Afterwards, I mounted the SRW.iso directly from my psp, opened >SYSDIR>EBOOT.BIN with MADEDIT and I saw the text I needed to translate. Great so far.

So from the mounted ISO I copied and pasted the EBOOT.bin file to my comp(so I can edit it) and... all the text I needed was gone?  It turns out that the two files look completely different (the one before the copy and the one after it...)


It turns out that when I copy pasted and/or extracted the EBOOT.bin, Madedit decided to read the new file with English encoding not Japanese encoding.  I Had to head on up to the view tab to fix that.

_______________________________________________________________________________________________

EDIT3: Alright now my problem is actually editing the files in the iso.  I went into MadEdit and changed some stuff.  Afterwards, I checked the filesize of both before the changes... and after the changes.  There's a file increase of 5 bytes.

Now when I opened UMDGen, replaced the EBOOT.bin with my edited EBOOT.bin, and saved the iso, the filesize of the changed iso was around 70MB smaller. 

To test if UMDGen actually worked I opened the original iso and immediately saved it.  The filesize stayed the same.


It turns out UMDGEN did me a favor making the file smaller.  The game got past the PSP boot screen without error when there was a 70MB difference but all that was waiting for me was a black screen and then a crash...  Maybe it isn't UMDGen but the edit's I made in MadEdit?  I made sure not to overwrite any 00s or 0As... I'm clueless as to what went wrong.

_______________________________________________________________________________________________

EDIT4: It seems that using MadEdit's replace function is dangerous even though all that's happening is that the pointers are getting shifted to the right.  So I made sure to stick to the amount of characters the words have which is kind of painful.

For instance the word Attune is six (six bytes) characters, but the word for attune in Japanese 感応 is only 4 bytes.

Once more even if I stick to the character limit, I still have one problem.  It seems as if Western encoded chars do not appear in the game... at all, and one Western Character in Japanese format Attune is two bytes a letter.  I could shorten attune to atne but not Attune to Au this become's a bigger problem when it comes to descriptions...

Xalphenos

You'll need to edit the pointers so that they point to where there is enough space for the new word.  If there is a pointer table I would dump all the menu text via the table then insert the translation while simultaneously updating the pointers via some sort of program.

TitanAnteus

Quote from: Xalphenos on July 17, 2012, 01:00:06 PM
You'll need to edit the pointers so that they point to where there is enough space for the new word.  If there is a pointer table I would dump all the menu text via the table then insert the translation while simultaneously updating the pointers via some sort of program.
How would I get this pointer table?

Xalphenos

Depends on the game.  Usually above the text and obvious, but not always.

TitanAnteus

#10
Quote from: Xalphenos on July 17, 2012, 06:59:17 PM
Depends on the game.  Usually above the text and obvious, but not always.
What do pointers look like? As in how would I see them in Madedit?  At the start and end of every piece of text is a bunch of 00s. Is that the pointer?

Also, a question on addresses.  I don't fully understand, because whenever I input addresses within other utilities on this site.  I always get file end reached kind of errors or just plain freezes so... do I understand addresses right?

Xalphenos

No.  Pointers are the offsets of the start of the text placed somewhere in the file. Sometimes all together in a table, sometimes not. I'ts IMHO the most basic thing in hacking, though I'm sure others will disagree.  I suggest going through the getting started section and searching the documents section for documents on pointers and on the psp in general. 

I can't really tell you what they are for this game without looking at it myself.

Edit:  Snuck that last one in on me.  No it would be 31547C

TitanAnteus

#12
Quote from: Xalphenos on July 17, 2012, 08:04:59 PM
No.  Pointers are the offsets of the start of the text placed somewhere in the file. Sometimes all together in a table, sometimes not. I'ts IMHO the most basic thing in hacking, though I'm sure others will disagree.  I suggest going through the getting started section and searching the documents section for documents on pointers and on the psp in general. 

I can't really tell you what they are for this game without looking at it myself.

Edit:  Snuck that last one in on me.  No it would be 31547C

OK thanks, I looked in the getting started section and all the documents on tables mention that to increase string Lengths I'd have to move pointers and that pointers are "Beyond the Scope of this Tutorial"

SOOOO I looked in the documentation section.  I'll look through everything there to see if I can learn anything.

EDIT: And TitanAnteus's heart sinks to the bottom of the ocean.   From one of the Documents I found.  To find pointers I need to find the address of the beginning of the text and to that I say  :thumbsup: but then, I'd need to find the address of the same area in RAM.  That means emulator?

EDIT2:Guess not.  I did a physical dump using cwcheat and according to this guy the difference can help find the pointers... OK... so I did that. and the difference between 3 test cases is.

2DAC

Subtract to find pointers it says, don't forget little endien big endien and... nothing.

Xalphenos

Honestly I've never gone through the getting started section.  Seems a slight over site to not have anything on pointers in it though.

Emulator would probably be easiest if there is one that can show or dump memory.  But perhaps there is some home brew app for psp that will dump memory to the card.  Could cw cheat do it?  You could also get lucky and search for the last part of the offset.

TitanAnteus

#14
Quote from: Xalphenos on July 17, 2012, 10:50:55 PM
Honestly I've never gone through the getting started section.  Seems a slight over site to not have anything on pointers in it though.

Emulator would probably be easiest if there is one that can show or dump memory.  But perhaps there is some home brew app for psp that will dump memory to the card.  Could cw cheat do it?  You could also get lucky and search for the last part of the offset.
OK I kind of get it now. 

A pointer's just a hexadecimal number that is the address of a string of text.  It can be shown strangely in the text portion of the of your hex editor.

Xalphenos

Yes I think you got it.  That is of course when the pointers are simple and obvious; which is not always the case.

TitanAnteus

#16
Found them!  ;D

They point to the beginning of each phrase and that's a lot.  You're right I'll need a program to help me here.

But there's a problem.  Neither cartographer or atlas can help for as said by Coldbird
Quote
For pointer table discovery on PSP titles... I highly suggest it...
A lot of PSP games save their japanese texts as S-JIS or UCS-2 (UTF16-LE) and this tool will help you spot them in memory.

My prefered behaviour of doing this is...

1. Make a Partition 2 Dump from your Game (TempAR can do this for example, produces a 24MB memory file).
2. Open it in MadEdit and find your text...
3. Take the texts' starting offset in the file, add 0x08800000 to it's value.
4. Reverse the bytes of that address and search for it in the memory dump as a Hex-String.

And tada... you got the address that stores the pointer to your text, allowing for easy text-hotswapping.

Auryn

I am not sure if i follow correctly but I suggest that you don't work on the eboot for learning the pointers but you take a look at the file you saw some text in your first post. You asked how pointers look like?? Well take a look at your screenshot saveb.png and the first 2 lines you see in Madedit, those are probably the pointers but without hex view, i can't be sure.

Anyway, it's looking like you got them in the eboot and if i did understand right, you have the first pointer that is not 00 but all pointers are relative to an offset...right?? Cartographer (and Atlas) can handle that case perfectly.

TitanAnteus

#18
OK this is where I am at.  I'll try my best to explain so please bear with me.

This is an image of my memory dump.  It shows all of the pointers that I'll need for spirit commands. The address for the starting and end blocks of the pointers then should be:

Start: $318c34 -  the address right at the first thing not 00
End: $318E7F - the address right before the last 00

When I open cartographer in CLI and input the correct arguments, the program runs for about 5 seconds just fine.

Afterwards this happens, but all is not lost because even though the program messed up it still dumps a text file.  I retried reinputing the text back into the program to no avail. It always gives me the same error.

If you're wondering what SRW.txt looks like here it is.

I honestly don't see what I've done wrong.  Some guidance would be greatly appreciated.  :angel:


Xalphenos

That is definitely a pointer table you found there.  So your first string is at 0x08B182C0 in the memory dump?

I've never used cartographer so I can't help with that; its too easy to write a program that can dump from a pointer table.  You don't want to dump text from your memory dump though.  You want to dump it from the main file, Eboot.bin.  So if 0x08B182C0 is the location of the first string, where is that same string in the eboot?