Binary script analysis of quartett!

I was a little slack on the Netoa two days ago. Not for anything else, it is for the analysis of the script that will be mentioned. Although the analysis did not complete, but I think it is enough to use, by the way to say.

Last weekend, Han Gong suddenly told me the topic of ffdsystem, and then someone contacted me to do quartett! of the Chinese. Since with Han Gong and Ming big cooperation to participate in the Chinese, I basically do a script to deal with a lot of related work; the Chinese public solve the problem of cracking, and Ming major finish packing problem, also do Script Editor, depending on the specific division of labor. This time is no exception, the Chinese princess attacked the resource file and resource extraction, resource packaging has not done, the script this piece is temporarily handed to me. In general, if the script is a text that is not processed, then I have nothing to do with it; this time I met with a binary script.

A script file that has been extracted from the Script.dat, I was startled: The file name incredibly is MD5 ... Han gong over there really did not break the resources to perfect. But it doesn't matter, as long as the contents of the document are right and can be started. To be sure, the suffix name of the script (which is exactly the script to my hand) is tkn.

Open one of the first files, 0a69b4afebd6d64527a21e3f1aa993f9.tkn. The contents are as follows:

Java code

Offset      0  1 2 3 4 5 6 7 8 9  A  B  C  D  E  F
00000000   4F 4 B. 4E   tokensetd...v ...
.. the same. 00000010 0C (i) ...   ??????? ..... |ase
00000020   5F for a 0C of  2E 2E 2F   _path ....... /..
00000030 the  6E 6C m ...   ?????? ..... (Nclu
00000040 the  2F   de ..........) ゴcript/b
00000050 6E-A-   aseinstruction.t-  6F 6E 2E-
00000060   The 6D 6F--The  6F 6E   xt ..... [Otion. 
00000070   Bay 4D/6E/All of the other ...   ' Ain. ...?.

It seems very depressing to read (?) In fact, I have been very happy to see so many ASCII characters. You can identify the Tokenset (but at this point you can't tell what that D is), Ase_path, Nclude, and so on. Further observations can be found in those characters that appear to have been clipped, in front of Base_path, include. The editor does not show up simply because a byte larger than 0x7f is interpreted as the first byte of a double-byte character in a double-byte character encoding (DBCS), that is, for example, 0x81 to "eat" the B (0x62) in Base_path.

In the above screenshot range, I have identified these: Base_path, include, Script/baseinstruction.txt, motion, main, and other strings. Observe the rules before and after them: these strings always end in 0 and are standard C strings, which always have a byte greater than 0x7f (note to 0x81 and 0x83), and there always seems to be 3 00 bytes before that byte, preceded by a non 00 byte.

To facilitate the analysis, I wrote a small program to extract the information I am interested in, auxiliary analysis.

Content that corresponds to the above content:

(Format is: The beginning address of a string the contents of the byte string before a strange numeric string)

Java code

0x1c 0xC 0x81 base_path
0x2b 0xC 0x83. /
0x3b 0x16 0x81 include 0x48 0x16 0x83 script/baseinstruction.txt 0x68 0x20 0x81 motion 0x74 0x20 0x81
Ma In