nipa icon indicating copy to clipboard operation
nipa copied to clipboard

Determining the permutation?

Open rr- opened this issue 10 years ago • 1 comments

According to nipa.h the substitution table (as in buffer[c]=subst[buffer[c]]-x-i) is derived dynamically. How is it determined? Are the keys game-specific, or rather archive-specific (i.e. derived from key1 and key2 found in the header)?

I tried to find it out myself, but the game I test it on (Chaos;Head) doesn't like being debugged.

rr- avatar Jan 04 '15 18:01 rr-

I finally discovered how to bypass the debugger check. Things I managed to figure out so far:

  • The game starts with some "seed" data, that can be found directly in .exe. In case of Chaos;Head retail, it seems to start with something like this:

    9F 2F D3 1E EB CF 22 DB  92 EC 21 DF 3B 32 41 91
    
  • having it loaded to the memory, the game proceeds to run a loop that mangles this seed (>>= 0x18, >>=0x10, >>=0x8 just like file name encryption, among other basic operations).

  • it seems that the "seed" data in fact serves coincidentally as an array, that gets patched by this loop in-place. I'm not sure whether all of its inital items are important, or just a few ones at the beginning.

  • the first six bytes of this array seem to be unused during the file data decryption stage.

  • the aforementioned loop seems to process the data in chunks of 18 bytes each. While the permutation must be 256 bytes long and 256 != 18 * n (where n is an integer), combined with the previous point, it makes some sense - some bytes are there just to keep the iteration going...?

  • anyway, this isn't even my final array. What I have so far at offsets 6..6 + 255 is used in another loop, to construct the final array that we can see nipa.h... like this:

    for i in 0..255:
        final[array[i]] = i
    

So... looks like these tables are not archive-specific, but rather game-specific, since everything is loaded from the .exe. Please correct me if I'm wrong.

rr- avatar Jan 04 '15 23:01 rr-