You are right. This makes is possible to decompress the file and it looks exactly like kapR. It means that GE only reads the file after those 4 bytes, and nothing else; this finding makes GE obsolete.Delete 4 bytes from the beginning of NAM_1.dat and you will be able to decompress it.
This script, written by aluigi, extracts only decompressed NAM_1.dat from .str (the file has the same name as the .str archive - dac49de4 in this case):
Code: Select all
comtype dk2 goto 0x34 get SIZE long goto 0x44 get ZSIZE long savepos OFFSET get NAME basename clog NAME OFFSET ZSIZE SIZE
The decompressed NAM_1 (and/or kapR) starts with 4C 43 48 32 (LCH2). The compressed one extracted from .str has B8 FF 01 00 10 FB 03 65 DF E2 (¸˙...ű.eßâ) before this string, and it cannot be decompressed without removing B8 FF 01 00.
Using dk2 as comtype parameter in bms script for decompression makes the data fully readable; xrefpack gives an error "the uncompressed data is bigger than the allocated buffer"; and ct_refpack crashes QuickBMS.
The compression results are different. For example, "Skarsvaag" string is compressed as "Skŕvaag" in the original file and as "Sűkŕvaag" in dk2 or ct_refpack comtype script; the strings before LCH2 are also different - BC FF 01 00 E0 10 FB 01 FF 06 05 BC E0 FB 0A 05 BC FB FB E4 B8 FF 01 00 10 FB 03 65 DF E2 (Ľ˙..ŕ.ű.˙..Ľŕű..Ľűűä¸˙...ű.eßâ) for ct_refpack and 10 FB 01 FF BC E4 BC FF 01 00 E0 10 FB 01 FF 06 05 BC E0 FB 0A 05 BC FB FB E4 01 13 B8 FB 10 FB 03 65 DF E2 (.ű.˙ĽäĽ˙..ŕ.ű.˙..Ľŕű..Ľűűä..¸ű.ű.eßâ) for dk2. Using xrefpack for compression gives an error "unsupported compression -1 in reimport mode". The B8 FF 01 00 part is present only in ct_refpack compression.
The data compression for dk2 and ct_refpack is similar, and the "gap" from 0001b3c0 to 0001ffbc is present for both comtypes. The last byte in the original file is at offset 0001ffbb, and it's part of compressed data.
An important question is: are dk2, ct_refpack and xrefpack the only refpack comtypes?