Farming Simulator 2013 – .gar file repack fails with QuickBMS

[blood.06s]

Hi,

I'm trying to repack the dataS.gar file from Farming Simulator 2013. I extracted it successfully using QuickBMS and the giants_software.bms script. However, when I try to reimport it (even without modifying any files), the .xml files become completely corrupted after packing.

Even if I reimport the original, unmodified XML, it still gets damaged. I've tried multiple reimport methods and command variations, but nothing works.

After repacking, the game either shows a black screen or displays "MISSING L10N_EN_XML" everywhere.  
This clearly indicates that the repacked .gar file is either corrupted or the localization system (language files) can't be read properly anymore.

Is there any working method, tool, or script to rebuild the .gar file correctly so the game accepts it?

Any advice or help would be appreciated. Thanks in advance!

[shak-otay]

Did you find any hint that repacking is possible using that script, theoretically at least? Reimport works for simple scripts only, afaik.

I couldn't find giants_software.bms, only this one.

So before I share my assumptions could you please confirm it's the same script?

[blood.06s]

Yes, I'm using the same script — it's called "giants_software.bms" and I used it with QuickBMS to extract the .gar files from Farming Simulator 2013.

It works fine for extraction, but I’m not sure if it supports reimport. As far as I can tell, this script only supports extraction, not repacking.

I’d like to repack the .gar files after modifying the contents, but I haven’t found any tool or method that can do this yet.

Do you know if repacking is even possible for this format?

[shak-otay]

Repacking would require to encrypt, I guess. (The only encryption I know what does encrypt/decrypt when applied twice is xoring.)

Quickbms can reverse the compression types it knows (comtype lzma here).

For the dataS.gar of the FS 2013 demo, that I have, the enc_mode is 1 (because of "about secrets"  at offset 0x40 in the gar).

So encryption aes_128_cbc KEY IVEC

is used here. The key is logged in the quickbms window (didn't check that at time of unpacking).

Surprisingly Quickbms knows/supports aes_128_cbc, but I have no idea whether the reimport is clever enough to get the key.

You'll have to ask Aluigi about it (he was active on Zenhax which is down now).

Or you could do some test, see example Encryption aes "0123456789abcdef" "" 1 # encrypt without ivec

in quickbms.txt. (ivec could be another hurdle, but it has zeroes in the script)

edit: (Above mentioned key is in the script.)

Problems on reimport:

Quote

- signature of 20 bytes at offset 0x00000000 doesn't match the one
  expected by the script:

  this one: "<?xml version="1.0" "
  3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31   <?xml version="1
  2e 30 22 20                                       .0"

  expected: "Copyright (C) GIANTS"
  43 6f 70 79 72 69 67 68 74 20 28 43 29 20 47 49   Copyright (C) GI
  41 4e 54 53                                       ANTS

 

btw, for FS2019 huben wrote:

Quote

I tested if the files where reimported correctly, which they were.

but I don't know which bms script he used.

Edited Friday at 12:56 AM by shak-otay

[blood.06s]

The most logical thing to do is to contact Aluigi. How can I get in touch with him?

[shak-otay]

I'm not sure. There's an email address at the top here.

Or emit an issue here. But for this you'll need to sign in to Github, I guess.

On another thought: FS2013 has a modding feature. Is it possible to add a script for example by modding?

Back to bms;

(Seems I misunderstood the script ; gar doesn't use lzma AND aes but lzma OR aes. Right? (ENC_MODE == 2 not taken into account))

Since I don't understand why reimport doesn't work for the gar file (maybe it's a bug in the reimport feature?)

we should try to reimport one file manually, say achievements.xml (a luc, compiled lua would add another level of complexity).

Here's offset and unpacked size of the first two files in dataS.gar (of the demo):

00037000 2862       achievements.xml
00038000 1905       character\chickenAnimalHusbandry.xml

So the task is to aes encode achievements.xml and compare to the original block data

Next problem: the block from 0x37000 to 0x38000 has 4096 bytes. Seems unlikely to me that aes increases the size that much.

 

As a hint:

Quote

Even if some people know how to extract the files, it would be a violation of the accepted EULA/T&C to publish such methods, in other words: illegal.
You can do this for your own private usage, but have to find out yourself.

 

Edited Friday at 09:38 AM by shak-otay