is the Shift-JIS code encrypted in the PC98 ROM

Started by PC98fan, June 25, 2022, 09:31:17 AM

Previous topic - Next topic

PC98fan

Hello,

I am working on the rom translation of an old PC-98 game (Pacific Theater of Operations). Most of the Japanese character can be found in the ROM file, being encoded in Shift-JIS.
A small part of the Japanese character, however, can not be discovered in the ROM.
For instance, I search the character string 'リセット' with its Shift-JIS code 'D8BEAFC4', but can not find it in the ROM.
I wonder if there is another Japanese character encoder used for the PC-98 ROM? Or the Shift-JIS code is encrypted?
Anyone one can help me? Thank you!

KingMike

Don't know what it looks like in the game, but maybe it's a graphic?

Not sure how exactly one goes about editing PC98 graphics.
"My watch says 30 chickens" Google, 2018

PC98fan

I did suspect its graphic as well at beginning. The character's style changes when the PC-98 font file changes. This is a indication that it should be a encoded character in stead of graph.
Want to post a picture, but no idea how to do that. I am new to this fourm  :-[



Quote from: KingMike on June 25, 2022, 09:51:50 AM
Don't know what it looks like in the game, but maybe it's a graphic?

Not sure how exactly one goes about editing PC98 graphics.

[Unknown]

It's possible that some of the text is stored differently, or it is compressed.

Another possibility is that it's being assembled.  This is a bit unlikely with something as short as "リセット", but it could be that it's not a single continuous string.  For example, maybe there's some animation and each letter is drawn separately to allow for it.

-[Unknown]

Sanedan56

First, I would recommend inputting リセット(838A835A83628367) just in case.

Second, how are you accessing the ROM? If you're using something like a hex editor, I would recommend you extract the game files with something like Editdisk first.

If this doesn't work, I recommend getting Neko Project 2 Debugger and search the memory when リセット appears. Set a breakpoint there and you should find how the game does the text.


Editdisk: https://hp.vector.co.jp/authors/VA013937/editdisk/index_e.html
Neko Project 2 Debug: https://github.com/nmlgc/np2debug/releases

PC98fan

Thanks Sanedan56!
I tried searching the リセット but still can not find it. I used the Ediddisk to extract the game files but was still not able to find them. 
Now I am trying your suggetion of using Nelo Proj.2 Debugger. It is a new tool for me. Is there any debug example by using the Nekp Proj. 2? Thx.

grundo1561

I recently ripped the text from a PC98 VN called Nouryokusha. By looking at the debugger, I was able to determine it was decoding the dialogue by pulling from a specific file (in my case it was called NOU_MPX.PDT) into memory and XORing each byte with 0x24. I wrote a quick Java program to do the same thing and write it to an output file, which allowed me to encode/decode the whole file. To re-encode it, you just XOR the output file with 0x24 again.
IDK if that helps at all, but looking at the debugger and memory definitely should

FAST6191

XOR with 24h (0010 0100)? How very odd. We occasionally see some kind of character level encoding/formatting in things that might see a high bit need to be blanked or accounted for but XOR and that pattern... I can only really conclude some form of obfuscation. Very rare to see that outside of PC games.

Sanedan56

The debugger is in Tools menu. There you will find the Dump and Edit menu.  Either dump the memory from Dump menu or search from the Edit menu.

grundo1561

Quote from: FAST6191 on July 02, 2022, 06:05:15 AMXOR with 24h (0010 0100)? How very odd. We occasionally see some kind of character level encoding/formatting in things that might see a high bit need to be blanked or accounted for but XOR and that pattern... I can only really conclude some form of obfuscation. Very rare to see that outside of PC games.

I thought it was really weird too! I'm just learning how to do this stuff (though I have a CS degree) and it was really satisfying to figure out. I had to step through the debugger to see what was actually happening.

This is what loads into RAM from the disk and this is what it looked like after XORing each byte with 24h