summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--docs/cronos-research.md30
1 files changed, 27 insertions, 3 deletions
diff --git a/docs/cronos-research.md b/docs/cronos-research.md
index a60d054..d076f0f 100644
--- a/docs/cronos-research.md
+++ b/docs/cronos-research.md
@@ -13,12 +13,19 @@ and a Vocabulary database with another set of these files in a sub directory Voc
13 13
14`CroIndex.*` can be ignored, unless we suspect there to be residues of old data. All words are serialized in little endianess. 14`CroIndex.*` can be ignored, unless we suspect there to be residues of old data. All words are serialized in little endianess.
15 15
16Additionally there are the `CroSys.dat` and `CroSys.tad` files in the cronos application directory, which list the currently
17known databases.
18
19## app installation
20
16On a default Windows installation, the CronosPro app shows with several encoding issues that can be fixed like this: 21On a default Windows installation, the CronosPro app shows with several encoding issues that can be fixed like this:
17 22
18 reg set HKLM\System\CurrentControlSet\Control\Nls\Codepage 1250=c_1251.nls 1252=c_1251.nls 23 reg set HKLM\System\CurrentControlSet\Control\Nls\Codepage 1250=c_1251.nls 1252=c_1251.nls
19 24
20[from](https://ixnfo.com/en/question-marks-instead-of-russian-letters-a-solution-to-the-problem-with-windows-encoding.html) 25[from](https://ixnfo.com/en/question-marks-instead-of-russian-letters-a-solution-to-the-problem-with-windows-encoding.html)
21 26
27Also note that the v3 cronos app will run without problem on a linux machine using [wine](https://winehq.org/)
28
22##Files ending in .dat 29##Files ending in .dat
23 30
24All .dat files start with a 19 byte header: 31All .dat files start with a 19 byte header:
@@ -26,9 +33,13 @@ All .dat files start with a 19 byte header:
26 char magic[9] // allways: 'CroFile\x00' 33 char magic[9] // allways: 'CroFile\x00'
27 uint16 unknown 34 uint16 unknown
28 char version[5] // 01.02, 01.03, 01.04 35 char version[5] // 01.02, 01.03, 01.04
29 uint16 encoding // 1 = KOD, 3 = encrypted 36 uint16 encoding // 0 or 2 = plain, 1 = KOD, 3 = encrypted
30 uint16 blocksize // 0040 = Bank, 0400 = Index, 0200 = Stru 37 uint16 blocksize // 0x0040, 0x0200 or 0x0400
31 38
39Most Bank files use blocksize == 0x0040
40most Index files use blocksize == 0x0400
41most Stru files use blocksize == 0x0200
42
32This is followed by a block of 0x101 or 0x100 minus 19 bytes seemingly random data. 43This is followed by a block of 0x101 or 0x100 minus 19 bytes seemingly random data.
33 44
34The unknown word is unclear but seems not to be random, might be a checksum. 45The unknown word is unclear but seems not to be random, might be a checksum.
@@ -140,6 +151,8 @@ The original description of an older database format called the per block counte
140In noticed that the first 256 bytes of CroStru.dat look close to identical (except the first 16 bytes) than CroBank.dat. 151In noticed that the first 256 bytes of CroStru.dat look close to identical (except the first 16 bytes) than CroBank.dat.
141 152
142 153
154The toplevel table-id for CroStru and CroSys is #3, while referenced records have tableid #4.
155
143##CroBank 156##CroBank
144 157
145CroBank.dat contains the actual database entries for multiple tables as described in the CroStru file. After each chunk is re-assembled (and potentially decoded with the per block offset being the record number in the .tad file). 158CroBank.dat contains the actual database entries for multiple tables as described in the CroStru file. After each chunk is re-assembled (and potentially decoded with the per block offset being the record number in the .tad file).
@@ -204,3 +217,14 @@ some records are compressed, the format is like this:
204 uint8 compdata[size-4] 217 uint8 compdata[size-4]
205 uint8 tail[3] = { 0, 0, 2 } 218 uint8 tail[3] = { 0, 0, 2 }
206 219
220## encrypted records
221
222In files with encoding type #3, records are encrypted.
223
224Several things observed:
225 * in encrypted .dat files, the first record starts at 0x100, instead of the usual 0x101
226 * probably with a fixed key, and no IV. This is likely so because I found several unrelated files where the
227 start of the encrypted data is the same for the first +- bytes.
228 * likely a stream of cipherdata xorred with the plaintext, since I found several records which differ in only a few bits.
229 * so probably: rc4.
230