Hacking Baka & Test Portable - English Translation Project

[FShadow]

Translation Preview (New!)


About This Project
This project aims to translate Baka to Test to Shoukanjuu Portable for the PSP into English. The translation aims to be as professional-looking as possible. As such, the script will be based on the official English dub of the anime where applicable. Because the game is not a very large game (only ~390MB), this project shouldn't take too long if we can get enough members.

About The Game
Gameplay
The game is a board/adventure game, similar to Monopoly and Mario Party. It features several aspects from the game's source material, such as summoned beast battles, and recovery tests. The story mode consists of several Visual Novel-type scenes that tell the bulk of the story.

Story
(From Wikipedia)
The Principal of Fumizuki Academy, Kaoru Toudou, has implemented a new summoning system in which students put their luck and skills to the test through board gaming in real time. Thus, creating an event that everyone will interact. If a student wins three times in a row without losing, he/she will get to choose a prize of their own desire.

Project Status (as of 12/31/16)
Translation
Percent of Total Scripts Translated: 100%

The basic translation is complete, and is slowly approaching a presentable state. Right now, all scripts are going through the revision process. After the initial translation, scripts go through two major revisions, and smaller corrections may occur later.

Revision
Revision 1: 74/74 story scripts completed.
Revision 2: 22/74 story scripts completed.

Revision 1: 10/10 board game scripts completed.
Revision 2: 0/10 board game scripts completed.

Graphics
A couple graphics need to be re-edited, but graphics are otherwise essentially done.

How You Can Help (as of 12/31/16)
Now that the first Revisions for all of the scripts are completed, we no longer need any new localizers. Though we may need additional help in the future, we do not require any help at the moment.

Project Team (as of 12/8/16)
Current/Active Members
FShadow - Project Leader, Small Translations, Graphics Editing, Script Localizer
DashingBob - Script Localizer
scragged - Script Localizer
---------------------------------
Former/Inactive Members
Zander1995 - Script Localizer
AdanK85 - Translator
NiM1233 - Translator
Tamekichi - Translator
CompCom - Creator of Baka to Test Script/Image Tools, hacking

Screenshots


More will come as more of the game is translated.

Spoiler: Original Post

A while back, a friend of mine introduced me to "Baka to Test to Shoukanjuu Portable", and I recently decided to see if making an English patch would be feasible. At first, I thought it would be a piece of cake, because the game only had 24 files in the ISO that I could see. However, after taking a closer look, I discovered that most of the game's data was contained inside .cpk files that omitted file names. Even after figuring out how to extract the files inside, I could not find any readable text from the game.

Through the corruption of the individual files, I believe that I have deduced the contents of several of the files, but am still unsure of how to read/modify the data within. Opening the files in MadEdit produces nothing but unreadable gibberish, no matter what encoding I used. Example

Below are the files located in /USRDIR/DATA, and the effect that corrupting them had on the game, where applicable:

ed.pmf - Ending credits movie
ICON0.PNG - XMB icon
lt.bin - Unknown, corruption crashed game on boot
MOV_PR.pmf - Short movie that plays during prologue
op.pmf - Opening movie, corruption crashed game at the opening movie
PIC1.PNG - XMB background
pr.bin - Unknown, corruption crashed game on boot
sc.cpk - Probably the story mode script, corruption crashed game upon starting story mode
se.acx - Sound Effects
union.cpk - Unknown, corruption crashed game on boot
vo.cpk - Story mode voices, corruption caused story mode voices to not play

If anybody could help me figure out how to convert the game's files into a readable format, please let me know!

 

[jjjewel]

I don't have this game but the files look pretty much like another game I worked on. So this is my guess based on what I used to see. (It might be right or wrong, but it won't hurt trying. )

- First off, check the end of your extracted files. If it has 16 bytes random codes there, that's the hash check. If you change anything in the file, the game will stop working. You'll need ASM hacking to bypass it, or figure out how the game calculates the hash codes. (I can't do this, so if this is the case, you'll need someone else to work on this part.)

- lt.bin should be your font. (In my cases, one game used 4bpp color mode, and the other game used 2bpp, so it seems to depend on the game.)

- sc.cpk is your script. For the encoding, (this is totally my assumption based on other games, so it might not apply to your game) it is based on Shift-JIS but the codes start with 0x0000 instead of 0x8140. (Like in the picture. The left column is normal shift-JIS, the right is the modified table.)

 

[FShadow]

Thank you very much for your response. As it turns out, each of the script files ends in 16 bytes of random code. So, I suppose that means that I'm going to need to find some help, because ASM hacking is beyond my capabilities.

Unfortunately, the encoding doesn't appear to be the same kind that you described. That said, if anybody would like to assist me and needs the original files, PM me.

 

[thexyz]

Well, it uses the same hash as a certain other game so here's how you calculate it: https://gist.github.com/anonymous/eab53c545c143ec65a4b
Probably easier to just nop the check anyway, which starts at 0x27318, just replace 32 bytes with zeroes.

 

[jjjewel]

Thank you very much for your response. As it turns out, each of the script files ends in 16 bytes of random code. So, I suppose that means that I'm going to need to find some help, because ASM hacking is beyond my capabilities.

Unfortunately, the encoding doesn't appear to be the same kind that you described. That said, if anybody would like to assist me and needs the original files, PM me.

Forgot to tell you that you need to reverse the bytes when you view text. (In CrystalTile2, there's an option to reverse the codes.) Otherwise, if your hexeditor can't do that, your table must be built as 0000, 0100, 0200 instead of 0000, 0001, 0002 as shown in the pic.
(I'm looking at your example pic and it looks super similar to the games I've worked on, so I think my method should apply to it as well.)

Most text will follow bytes 0xF0FF. It goes like
F0 FF, 2 bytes dialog number indicator, Speaker Name, FF FF, Dialog Text, FB FF
(FE FF is a code for new line.)
Speaker name and dialog text are encoded as I explained above.

 

[FShadow]

Well, I nop'd the check like thexyz said, and kept messing around with the encoding. I got the table file to work, and, as a result, I was able to produce this:

So, now that I can modify the script, I need to figure out how to extract/modify/reinsert the texture data. Using the PPSSPP's GE Debugger, I've been able to see that most of the menus store their text in images, rather than in a script. Does anyone know how I could go about finding these files?

Edit: I'm also going to need to modify the font file. Can somebody tell me what tools I'd need for that?

 

[JamRules]

Well, I nop'd the check like thexyz said, and kept messing around with the encoding. I got the table file to work, and, as a result, I was able to produce this:
View attachment 9686
So, now that I can modify the script, I need to figure out how to extract/modify/reinsert the texture data. Using the PPSSPP's GE Debugger, I've been able to see that most of the menu's store their text in images, rather than in a script. Does anyone know how I could go about finding these files?

Edit: I'm also going to need to modify the font file. Can somebody tell me what tools I'd need for that?

Haven't seen the game but the GE Debugger shows the RAM location e.g. 0x0974c560 and also shows the dimensions and CLUT type. A good place to start may be to debug the asm either using breakpoints/IOOpen/IOReads to find which file the game loads. If you get some breakpoint hits then you might be able to trace it back to find where the original is read. (Breakpointing VRAM doesn't seem to work) Otherwise the file may be used as is and you can trace the IO.

I suggests changing your debug settings to log IO at debug/verbose level and output to a txt file by running with "PPSSPPWindows64.exe" --log=mylogfile.txt

Depends on if the game loads many small files or one large archive, but you'll should be able to find the files loaded

INFO hle.IoFileMgrForUser - Application - hleIoOpen filename = disc0:/sce_lbn0x31dc0_size0xa8f0a flags = 1 permissions = 00

(might be more like 4=sceIoOpen(disc0:/sce_lbn0xad020_size0x102cc800, 40000001, 000001ff))

You can either dump the file from debug, extract file or use an LBA list (from UMDGen, etc.) to find the file, for instance this file was
0204224 , \PSP_GAME\USRDIR\DVDROOT\ARCHIVE\TITLE.PKG

Since there are .cpks you might need to look for something like this

350208 = sceIoLseek(4, 55800, 0) - e.g. read start = 350208
sceIoRead(4, 09c67800, 1f800) - sceIoRead(file, RAM location to store to, size)

If the files are uncompressed/non-encrypted you could compare the texture in RAM to the files
(haven't done much research on cpk). If you managed to unpack all the .cpk might be easier to look at the files than try to debug the asm

 

[CompCom]

Well, I nop'd the check like thexyz said, and kept messing around with the encoding. I got the table file to work, and, as a result, I was able to produce this:

So, now that I can modify the script, I need to figure out how to extract/modify/reinsert the texture data. Using the PPSSPP's GE Debugger, I've been able to see that most of the menu's store their text in images, rather than in a script. Does anyone know how I could go about finding these files?

Edit: I'm also going to need to modify the font file. Can somebody tell me what tools I'd need for that?

A font does appear to be stored in the lt.bin like jjjewel said. As for editing it you need to determine the format and either find an editor for that format (Tile editors can sometimes be good for this stuff depending on the format) or a way to convert it to a commonly used format. The union.cpk seems to hold a lot of files, a few GIM/GMO files the ones I saw seemed to be related to the game maps but it might be a good place to start looking for the menu files as the archive seems to hold a majority of the game's files.

In addition I found the in-game names have a text limit imposed but it can be increased with ASM (I don't know how stable it would be though). I also found how to shorten the text width/offset of the dialogue text with ASM although I wasn't able to trace where it was loaded from or find the text width of the in-game name.

Here is an example of my testing:

The tool shown in my screenshot is very rough/buggy but it does seem to work atleast for the first script file. If you are interested in anything I've found please feel free to PM me.

 

[FShadow]

The OP has been updated to reflect the current state of the project. We are looking for translators and someone to make a few new images. If you think you can help with these, contact me via PM.

Any questions about the project? Ask them here! I'd be more than happy to answer any and all questions you have.

 

[BLKMN国人]

What files are being used to do this? I want to help with this project.

 

[FShadow]

What files are being used to do this? I want to help with this project.

Well, for starters, if you want to help out, check out the OP to see what we need help with. As for the files used, the game's ISO contains the following files:

\UMD_DATA.BIN
\SYSDIR\OPNSSMP.BIN
\SYSDIR\EBOOT.BIN
\SYSDIR\UPDATE\PARAM.SFO
\SYSDIR\UPDATE\EBOOT.BIN
\SYSDIR\UPDATE\DATA.BIN
\USRDIR\DATA\ICON0.PNG
\USRDIR\DATA\ed.pmf
\USRDIR\DATA\lt.bin
\USRDIR\DATA\op.pmf
\PIC1.PNG
\ICON0.PNG
\USRDIR\DATA\MOV_PR.pmf
\USRDIR\DATA\PIC1.PNG
\USRDIR\DATA\pr.bin
\USRDIR\DATA\sc.cpk
\USRDIR\DATA\se.acx
\USRDIR\DATA\union.cpk
\USRDIR\DATA\vo.cpk
\SYSDIR\BOOT.BIN
\INSDIR\0000.DNS
\INSDIR\ICON0.PNG
\PARAM.SFO
\INSDIR\PIC1.PNG

As you can see, a few of those files are .cpk files, which are a type of archive that can be extracted using CriPackedFileMaker. However, after extraction, none of the files within the archive contain file names or extensions, so figuring out what they are can be a bit tricky. By corrupting each cpk, I have been able to deduce that sc.cpk contains the game's scripts used during story mode, vo.cpk contains the voices for the the aforementioned story mode scenes, while union.cpk appears to house the game's music and textures. Unfortunately, because these textures are compressed, we need someone with asm experience to help with figuring out how we can edit the files and insert them back into the game.

In the end, unless you're skilled in asm, are an artist capable of making some translated images, or are able to translate Japanese, there's not much to help out with until the textures can be decompressed and the script is translated. After that, some new positions may open up (localizers, editors, etc.), but until then, keep following the project, or try to find someone that can help us! We know that this series isn't too wildly popular, so finding people to help might be difficult.

 

[BLKMN国人]

Well, I may not know asm, but I can definitely help with translating the in-game images. But since those haven't been decompressed yet, there's not much I can do.

 

[jjjewel]

These info, again, are based on other games I hacked that seem to use the same format. (Sorry, I don't have time to look at your game now. T_T)

The graphics should be in 4bpp or 8bpp with RGBA palettes. (Except in some cases, there are some fonts that use 2bpp.)

I don't know asm or debugging stuff, but you should be able to view the graphics with a tile editor, unless it's compressed. (I always use CrystalTile2.)

If you see 1F 8B 08 in your file, the compression is gzip.

Most file sizes or offsets to extract sub-files are listed in Eboot.bin. (I don't know how to find out from debugging, but if you list the sub-file offsets you see from your graphics and then search for those values in eboot.bin, you should find the list.)

 

[FShadow]

)
The graphics should be in 4bpp or 8bpp with RGBA palettes. (Except in some cases, there are some fonts that use 2bpp.)

I don't know asm or debugging stuff, but you should be able to view the graphics with a tile editor, unless it's compressed. (I always use CrystalTile2.)

If you see 1F 8B 08 in your file, the compression is gzip.

Most file sizes or offsets to extract sub-files are listed in Eboot.bin. (I don't know how to find out from debugging, but if you list the sub-file offsets you see from your graphics and then search for those values in eboot.bin, you should find the list.)

Thanks! Using what you said, I've discovered that the compression is in fact gzip, and am currently looking for the files I need. My only problem is that I can't figure out how to view a 4/8bpp image with an RGBA palette in CrystalTile2. I've found something that I think is a texture, because I can see some patterns, but I can't figure out which settings I need to use to properly view the image.

Well, I may not know asm, but I can definitely help with translating the in-game images. But since those haven't been decompressed yet, there's not much I can do.

Well, even though I'm still in the process of finding/extracting textures, if you really want to help, take a look at the files I've attached. They contain most of the menus, and I translated what I could. The lists aren't complete, and contain some blanks, but if you see any menus in-game that aren't on the list, use this to piece together the kanji and add it to the file. It's going to need to be done eventually, and I'll end up doing it later if you don't want to, but it would help speed things up a bit down the line. Also, if you do end up transcribing the text make sure you use a good text editor like notepad++, and set it to UTF-8 encoding.

 

[JamRules]

You might have to separate the pixel data and match it with the correct colour palette.
If it helps the files should be 8bpp.

You could also try TiledGGD

Edit: looks like each pixel data is in its own gzip so no need to worry about separating it.
Problem it trying to find the dimensions (though this could be done via debugging I suppose)


The file (Chunk 1147) has 11 x 256 colour CLUTs (1024 bytes each),
assuming they've done it logically the pixel data for gzip 1 should be for the first CLUT, etc.

Edit:

Should be possible to rebuild the graphics, as an example with the gzip from 0xFC20 and
pallete 2 (from 1032 / 0x400) you get this 512 x 80. Either my gzip doesn't work or they split the texture.

Used the debugger for the sizes but they should be stored somewhere
(or guess the width using powers of 2)

 

[jjjewel]

My only problem is that I can't figure out how to view a 4/8bpp image with an RGBA palette in CrystalTile2. I've found something that I think is a texture, because I can see some patterns, but I can't figure out which settings I need to use to properly view the image.

You can use CrystalTile2's default 'Combo' palette to view 4bpp graphics, and 'Gray DIVISION' for 8bpp. (It's only good for viewing as CrystalTile2 doesn't support alpha channel. If you want to edit graphics, you'll need to extract them anyway.)

This is my game's pr.bin. (With 4 bpp, 32x8.) As for the dimension of the graphic, you can adjust it manually. (I also think that it must be listed somewhere, but I still haven't looked.)

Generally graphics that use 4bpp will use 32x8 tiles, and the ones with 8bpp will use 16x8 tiles.

By the way, if your pr.bin looks like this too, you'll encounter the same problem that I have now. You need to find out how the game load this picture's sprites. It kind of mix and match these blocks of text together. I still have no clue how to work on this graphic. T_T

 

[jjjewel]

Should be possible to rebuild the graphics, as an example with the gzip from 0xFC20 and
pallete 2 (from 1032 / 0x400) you get this 512 x 80. Either my gzip doesn't work or they split the texture.

My game split the texture, so this game might as well.

One of my graphic files in union.cpk looks like this;

The 0x04 at address 0x1800 indicates that the texture is split into 4 sub-files. Next are the sub-file's offsets.

0x0088 (or actually 0x8800) is the size of the decompressed sub-file.

The offset will point to this size so you have to add 0x10 to the offset (plus 0x1800 for absolute address but this value depends on where your data start.)

So read number of sub-file, read offsets, read sub-file data, decompress each sub-file and combine all of them into one big file and you'll get your texture data.

 

[CompCom]

Thanks to the posts by JamRules and jjjewel I was able to create a tool to extract the images from the game's files.

I haven't perfected the reading yet but I have a good idea of what is left to do. I am also currently working on inserting an edited image back into the file.

 

[FShadow]

I'm so glad that so many people are helping out with this project! I can't thank you all enough. Even though I might not have as much technical knowledge, I've been working hard at translating the actual text, some of which can be seen in the text files I attached in my last post. BLKMN国人 has been helping me out, especially with some of the localization aspects. Hopefully, by the time CompCom finishes with the Image Tool, the text will already be ready to be reinserted.

 

[CompCom]

My image tool is now able to insert images back into the game. (It needs to be tested more but is looking promising).

It seems to work with most of the image files however there seem to be a few image files which break the file format pattern for some reason (I haven't been able to determine why yet). However from what I could see most of the in-game text was in images that worked with my tool.

I still need to deal with the palette data and determining colours once the palette is full. At the moment I am just using a distance function to determine the closest colour but I do not feel this is the best solution.

There are a few other issues I need to address but the tool does seem usable for most of the files.