Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determining the permutation? #2

Open
rr- opened this issue Jan 4, 2015 · 1 comment
Open

Determining the permutation? #2

rr- opened this issue Jan 4, 2015 · 1 comment

Comments

@rr-
Copy link

rr- commented Jan 4, 2015

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-
Copy link
Author

rr- commented Jan 4, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant