Format IDX

Extraction and unpacking of game archives and compression, encryption, obfuscation, decoding of unknown files
cover1995
Posts: 15
Joined: Sun Nov 02, 2014 9:17 pm

Re: Format IDX

Post by cover1995 »

And the other way?
And could you clarify at what point to use gzip?
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Format IDX

Post by aluigi »

With the first script you can't reimport at all.

With the second way you can and you are subject to the file size limits.

With the second method you must use gzip as last step to create the cnt archive, I posted a whole step-by-step for the operation.
cover1995
Posts: 15
Joined: Sun Nov 02, 2014 9:17 pm

Re: Format IDX

Post by cover1995 »

I Thank Aluigi for help and cooperation! The unpack and repack of resources works perfectly, but the problem is that unpacked text files are unreadable for some reason.
Here is the example of such compressed file http://rghost.ru/59165766
Here is the example of the same unpacked txt file from the old version which was not compressed and is readable [http://rghost.ru/59166445

Is it possible to decompress this unreadable file as it was in the previous version?
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Format IDX

Post by aluigi »

As I already said some posts ago, those text files are not compressed but they are compiled (basically they are the binary representation of the original text).
I can't help with decompilers.
cover1995
Posts: 15
Joined: Sun Nov 02, 2014 9:17 pm

Re: Format IDX

Post by cover1995 »

We unpacked resources in order to translate the texts and names of subjects and objects from chineese into another language. But the problem is chineeze words and sentences have much less symbols than the same English or Russian ones. So after the process of translation the size of these files has been enlarged and it became impossible to reimport these enlarged files. So it is of no sense to unpack and translate the files.

Do we need to unpack, translate, change the size and try to repack the definite files? My experience shows that it all is in vain. So is it possible to create a new archive which will have the same file structure but will not dictate the definite file size? I mean, we could unpack all the archive files, change them (enlarge their size) and then create a new (but in fact it will be just the same) archive which would have the same structure and the same list of files.

data.cnt http://rghost.ru/59275513
data.idx http://rghost.ru/59275522
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Format IDX

Post by aluigi »

Any solution is not easy but "probably" the simplest one is:

1) finding the exact part in the uncompressed IDX file where are located the OFFSET and SIZE field.
You can use quickbms -V -0 (zero) to find the offset in the IDX file where are located these two fields, for example:

Code: Select all

. 00112233 get     OFFSET     0x00004455 4
  |                |          |          |
  |                |          |          size of the field (4 is long)
  |                |          value
  |                name of the field
  offset of the field in the file


2) take note of the current size of the CNT archive, it will be the new OFFSET field.

3) append the new modified file to the CNT one by using a hex editor or a script like the following:

Code: Select all

get SIZE asize
append
log "data.cnt" 0 SIZE
open FDSE "data.cnt"
get OFFSET asize
math OFFSET -= SIZE
print "new OFFSET %OFFSET|x%"
print "new SIZE   %SIZE|x%"
quickbms script.bms new_file c:\folder_of_the_game

4) open the IDX file with a hex editor and go to the position where are located the OFFSET and SIZE field of the new file you appended and replace these values with the new ones

I think it's easier than what it seems.
cover1995
Posts: 15
Joined: Sun Nov 02, 2014 9:17 pm

Re: Format IDX

Post by cover1995 »

Unfortunately I appeared to be too dumm to follow your instruction. I don't understand why it doesn't work.
I can describe my actions step by step.
We have 3 files: "data.idx" "data.cnt" and "data" (we've unpacked the last file from "data.cnt" with the help of 7zip).
1) According to step 1 I am to find offset and size of the needed file.
quickbms -V -0 script.bms data.idx .\ > INFO.txt (in your message it was script.bms on the previous page)
I create file INFO.txt and seek information about the needed file inside it (FONTS.INI):
Image
Do I understand it properly? This is the information about the location of FONTS.INI inside of "data".

2) According to step 2 I am to note the CNT archive's size, but for what? Did you mean the size of "data.cnt"? May be you meant the size of "data"?

3) Format CNT ("data.cnt") is absolutely unreadable as well as rar or zip. On the contrary I can read "data" as a txt file.

I've stuck ((( I cannot execute neither step 2 nor 3 ((
Would you please make the instruction a little bit more detalized?
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Format IDX

Post by aluigi »

Basically the idea of this trick is appending your modified file at the end of the archive and so you must modify the OFFSET and SIZE values on the index file so that instead of reading the old file it will read the new one without problems of size.

In your example 0xc4c is the position of the index file where is located the OFFSET field of the file you extracted.
So you must replace that value in IDX with the current size of DATA (not data.cnt) because it will be the new offset.

Append your file.ini at the end of DATA.
Go to offset 0xc50 of IDX and write the size of file.ini

Save IDX and DATA, compress DATA as DATA.cnt and you should be fine.


PS: in my previous description I forgot that the cnt file is compressed and not the idx one, that's the reason about the IDX, CNT and no-extension confusion.