Hello, I'm looking for some further advice in figuring out the binary/archive format to try and actually properly inject translated text for scb. files.
I finished manually script dumping Idolmaster 2's Hibiki route, and once it's translated we wanted to use it as a test.
We have a decrypt and reencrypt tool that's able to handle english text. However, to really streamline the process. In order to do that, we need a program that:
1. updates the pointers in the code that point to the dialogue
2. updates the pointers in the code that point to the numerical value of the size of the dialogue
3. re-encrypts the binary to load back into the game.
The program already does 3. But it seems we have to do 1 and 2 meticulously and manually, any advice?
I'll show the help we got so far below (Thank you faraplay):
"This number is 0x80 less than the size of the file (this is the file mak_w01_01.scb.dec) which suggests a header of length 0x80. sure enough it looks like the SCB bit begins at 0x80"
also these two numbers add up to 0x28E20, so they probably indicate sizes of different parts of the file or something
next up, looking in the bit that begins at 0x80 (let's call it the SCB part) we have a bunch of 3-letter bits that suggest different sub-parts of this SCB part. looking closer at the numbers at 0xF8, 0xFC, 0x118, 0x11C etc, we see we have
8C0 + 150 = A10
190 + A10 = BA0
380 + BA0 = F20
...
so we likely have that 0x8C0 is the size of the CMD part and 0x150 is the offset; 0x190 is the size of the LBL part and 0xA10 is the offset; etc.
and sure enough, at 0x1D0 = 0x80 (SCB part offset) + 0x150 (CMD offset) we have the letters CMD signalling the start of the CMD section if we skip ahead to the MSG part (which is the part we care about the most) at 0x80+0xBA0 = 0xC20 we see this.
the bit with all the 0x30s is of course japanese text, in UTF16-BE. hiragana characters have code points in the 0x3000-0x30FF range which is why we see so many 0x30s, which shows up as the digit 0 in the 'Decoded text' view
this data consists of a bunch of null-terminated strings (the standard way to store text on a computer). see the 0000 highlighted for example. by seeing where these null terminators are, we can see how many strings there are in this data and how long each one is
so:the 1st string has length 0x3E (including the null terminator)the 2nd string has length 0x56the 3rd string has length 0x50the 4th string has length 0x08and so on, up to the fourteenth and final string having length 0x36.we should expect to see all these numbers in the header...
...and we do! the 0x000E highlighted should be the number of strings stored (E is fourteen)
i also suspect that this 0x360 is the length of the MSG data block (includes the string length & offset data as well as the raw string data)
The tools so far for the program are here:
I finished manually script dumping Idolmaster 2's Hibiki route, and once it's translated we wanted to use it as a test.
We have a decrypt and reencrypt tool that's able to handle english text. However, to really streamline the process. In order to do that, we need a program that:
1. updates the pointers in the code that point to the dialogue
2. updates the pointers in the code that point to the numerical value of the size of the dialogue
3. re-encrypts the binary to load back into the game.
The program already does 3. But it seems we have to do 1 and 2 meticulously and manually, any advice?
I'll show the help we got so far below (Thank you faraplay):
"This number is 0x80 less than the size of the file (this is the file mak_w01_01.scb.dec) which suggests a header of length 0x80. sure enough it looks like the SCB bit begins at 0x80"
also these two numbers add up to 0x28E20, so they probably indicate sizes of different parts of the file or something
next up, looking in the bit that begins at 0x80 (let's call it the SCB part) we have a bunch of 3-letter bits that suggest different sub-parts of this SCB part. looking closer at the numbers at 0xF8, 0xFC, 0x118, 0x11C etc, we see we have
8C0 + 150 = A10
190 + A10 = BA0
380 + BA0 = F20
...
so we likely have that 0x8C0 is the size of the CMD part and 0x150 is the offset; 0x190 is the size of the LBL part and 0xA10 is the offset; etc.
and sure enough, at 0x1D0 = 0x80 (SCB part offset) + 0x150 (CMD offset) we have the letters CMD signalling the start of the CMD section if we skip ahead to the MSG part (which is the part we care about the most) at 0x80+0xBA0 = 0xC20 we see this.
the bit with all the 0x30s is of course japanese text, in UTF16-BE. hiragana characters have code points in the 0x3000-0x30FF range which is why we see so many 0x30s, which shows up as the digit 0 in the 'Decoded text' view
this data consists of a bunch of null-terminated strings (the standard way to store text on a computer). see the 0000 highlighted for example. by seeing where these null terminators are, we can see how many strings there are in this data and how long each one is
so:the 1st string has length 0x3E (including the null terminator)the 2nd string has length 0x56the 3rd string has length 0x50the 4th string has length 0x08and so on, up to the fourteenth and final string having length 0x36.we should expect to see all these numbers in the header...
...and we do! the 0x000E highlighted should be the number of strings stored (E is fourteen)
i also suspect that this 0x360 is the length of the MSG data block (includes the string length & offset data as well as the raw string data)
The tools so far for the program are here:
Last edited by BonillaP,
