One of the readers of my visual novel hacking tutorial has asked me to check on the protection of «Kimi ga Aruji de Shitsuji ga Ore de» (君が主で執事が俺で). Here goes a brief technical overview and some handy files to help in the translation of this game for those who're interested.

Update: thanks to someone's comment it's now clear that Kimi uses an industrial cryptography which is the same both on its .nsa archives and nscript.dat. Here is located the tool for decrypting them – run it as shdecrkansa.exe arc.nsa decoded.nsa and use any standard NSA extractor like NSAOut from Insani.

nscripter.dat can be decoded in a similar manner except that you'll need to use a hex editor to apply bitwise XOR by key 0x84 on each of the decoded file byte.

And since this is symmetrical cryptography you can encode the edited files back into original format by passing it to decrkansa again.

Tech stuff

Kimi ga Aruji (Kimi for shortness from now on) is an NScripter-powered visual novel (English page on Insani.org) – this means all of its script data is contained in nscript.dat and resources like images and music – in different .nsa archives.

Unlike original NScripter Kimi uses symmetrical XOR encryption on its nscript.dat which is ridiculously complicated.

Code points

Below follows a list of code blocks of interest in the disassembled listing based on my game copy with the MD5 hash of きみある.exe being 3F76E89BB6FB8F4ADD5F532BE063875F (663552 bytes in size).

• script initialization is performed in 0x00444420 subroutine which starts by calling _rand() several times and then checking for existence of 0.txt, 00.txt and, eventually, nscript.dat. Only the latter is decoded so the first two are probably for debugging raw scripts but code for initializing those was apparently removed during the compilation phase (this routine is passed a parameter which is always 0).
• the above subroutine gets called from a more generic initalization function which gets called almost directly by WinMain().
• after the first subroutine allocates a code block of the same size that nscript.dat it passes control to the general decoder function located at 0x0044BF70. It initializes encryption tables, opens and reads the file (at 0x0044C198) into the passed preallocated block of memory, then closes the handle and starts working on the file contents alone.
• the main action happens around 0x0044C230 in the same subroutine; Kimi uses objects to decode 1-Kilobyte chunks using several enigmatic loops in 0x0045CF20 subroutine which I decided not to explore completely. I can only say that it involves XOR-ring of script bytes and some extra tables.
• after the general decoder returns the buffer contains partly decoded script (in asmESI). I say partly because immediately after this the script initialization routine applies simple «wind XOR» on it with constant key 0x84 (loop at 0x00444530). Maybe it's default NScripter protection, who knows.

Finally, now asmESI contains the script in plain text form. Note that there's a global Pointer variable at 0x5DC5D8 that must point to the decoded buffer – the script initialization subroutine sets it after allocating the buffer and it has the same value as asmESI by the time it gains control back.

After this point script initialization subroutine works with raw script creating game window by checking for ;modeXXX comment in the beginning of it. Execution continues as normal.

Unprotection

So how can this roublesome XOR-ring be worked around? I've decided to simply remove the protection code and replace it with simple reading of the raw nscript.dat provided it's unencrypted (it's easy to obtain by setting a break point after the last XOR loop – e.g. at 0x00444539 and then using a memory dumper like LordPE to save the buffer contents.

Nice feature of symmetric encryption is that you can encrypt the script back using the same approach – put raw nscript.dat, set a break point after the loop, dump the memory and you'll get the protected nscript.dat's contents which can be used with the original (unpatched) EXE file.

No more necessary – see the update on top of the article.

Handy stuff

Hopefully now you feed ready to contribute to the community and translate the game. You need a decoded nscript.dat (download) and the unprotected きみある.exe (download). Drop both into the game install directory. Note that original きみある.exe won't run with the replaced nscript.dat and unprotected.exe won't run with the original nscript.dat.

The .dat file is a simple text file in Shift JIS encoding. Standard Windows Notepad is able to open and edit it successfully if your system works in Japanese locale – the only problem is line endings which are in Unix style (LF) instead of Windows (CR LF). For this reason if the script looks like a single long line when you open it in your text editor you need to convert line endings; there are two ways:

• using online convertor:
  1. Open this page and select your nscript.dat in the box Text to process, then click Process – you should be prompted for a download. Save the new file (sometimes it might take 1-2 minutes) – it's now openable by Windows Notepad or another editor.
  2. The game won't start with the new file so to convert it back use this page, download the file, rename it to nscript.dat and put into the game's folder. unprotected.exe should now run fine.
• using hex editor with Search & Replace function – for example, free and fast XVI32.
  1. To convert to Windows line endings press Ctrl+R, Search for 0A and Replace with 0D 0A.
  2. To convert back Search for 0D 0A and Replace with 0A.

This should cover it. If you have questions feel free to ask in the comments. You can also check my Visual Novel tools page for other useful utilities.