.sdf files(Ground Control, Ground Control Dark Conspiracy, Ground Control II)

[AnonBaiter]

so i found out some .sdf files out of what were basically Massive Entertainment's first games ever(see topic title for details).
anyway i was about to post the sample files needed to open this request thread with for about several months back then but for some reason i decided not to. now here they are:
[filecutter-8mb]ground_control.7z
[filecutter-8mb]ground_control_2.7z

in the meantime i found a bms script that covered a similar format like this but didn't actually work with those samples in the end. it's this script by the way.

[aluigi]

sdf reminds me the sdf + sdf.sdftoc archives used in some ubisoft games:
http://aluigi.org/bms/ubisoft_sdf.bms

[AnonBaiter]

you mean recent ubisoft games.
although to be honest i never had the chance to compare these .sdf files i posted here as "samples" and the sdf.sdftoc/sdfdata files as used in Tom Clancy's The Division between each other.

[aluigi]

You should have toc files with the same basename, otherwise it means that the files you posted have an encrypted header at the beginning.
I see "RYS", one byte, sdf size and random data followed by all the files, which is a variant of the format used in WIC (as you correctly noticed), that random data may be the TOC. No idea about what may be the encryption

[AnonBaiter]

I see "RYS", one byte, sdf size and random data followed by all the files, which is a variant of the format used in WIC (as you correctly noticed), that random data may be the TOC. No idea about what may be the encryption

correct. it's all in these .sdf files, believe it or not. if i'm lucky i might even "find" the key used for encrypting these headers anyhow, though any hints of encryption as used in those games might be in the exe.

this is where the .sdf files were stored in Ground Control by the way

[Ekey]

Download SDK: here. In Archive you can find WinSDF tool.

[aluigi]

In the meantime I have made a script for Ground Control Demo, so it doesn't work with the provided samples:
http://aluigi.org/bms/ground_control_sdf.bms

With some patience and the executable it's probably possible to support other games because one of the problems are the keys (half problem since they can be partially guessed) plus some differences in the format.
That's all for the moment.

[AnonBaiter]

OK, i'll keep that saved. thanks for your help.
also, thanks for that one ekey!

[aluigi]

GC2 uses the same format of WIC, the only difference is the compression algorithm: lzma instead of zlib.
The full folder names where stored very easily inside the TOC, I don't know why I didn't handle them in the script.
Script 0.2 with full support for GC2 and folders:
http://aluigi.org/bms/world_in_conflict.bms

In gc.exe I found a different KEY1 and implemented it in the ground_consol_sdf.bms script but it's still not compatible with the samples you provided.

[AnonBaiter]

it's still not compatible with the samples you provided.

oops
maybe i can provide you my copy of gc.exe if you want, or maybe i can provide entirely new samples to go along with it too.

(although my attempt at finding at key was through the archives themselves - the result was 0x92c51ceb)

[AnonBaiter]

okay, let me just start over
[new_samples_filecutter_8mb]ground_control_sdf.7z

right now it contains only the "DARKCONS" archives and gc.exe itself.
sorry for being a bit too lazy for this.

oh yeah, the key is basically the same as your exe:

if you need the full graph out of this, let me know

[aluigi]

I rechecked everything and found the mistake, script 0.2

[AnonBaiter]

huh, now it's fixed. thanks.

[AnonBaiter]

okay so this is something i've been keeping to myself for a while now. for this one i tried to go for a "compartible" script by merging both ground_control_sdf.bms and world_in_conflict.bms while modding a few lines of code in between so the script doesn't spazz out when it finds an "uncompressed" file(GC1).

[aluigi]

There are only 3 modifications in that script:

• enabling the world_in_conflict.bms code with TYPE 9 and 10, I thought about the same but I don't know what's the minimum version from which this second version of the format starts, I guess it's 8 (7 is for sure mode 1 so...) but I don't have samples confirming that exact number and if version really depends by it
• handling the compressed files from their first 2 bytes is very bad, checking TYPE is the correct way but I don't know what's the checked bit (7 is 3 bits), let me know if you have samples not covered by my script and I will check them trying to find the correct "TYPE & 0x?" if exists, in my samples 7 was for compressed files
• why did you decide to ignore the INFO_INFO field provided by the format? it's not that useful but it's part of the format and worked perfectly with all my samples

For me it's ok to merge the 2 scripts once every doubt is solved.

[AnonBaiter]

enabling the world_in_conflict.bms code with TYPE 9 and 10, I thought about the same but I don't know what's the minimum version from which this second version of the format starts, I guess it's 8 (7 is for sure mode 1 so...) but I don't have samples confirming that exact number and if version really depends by it

well i only have the Ground Control 2 demo at the moment and from what i saw the "second version" of this SDF format seems to start at 9 so...

handling the compressed files from their first 2 bytes is very bad, checking TYPE is the correct way but I don't know what's the checked bit (7 is 3 bits), let me know if you have samples not covered by my script and I will check them trying to find the correct "TYPE & 0x?" if exists, in my samples 7 was for compressed files

this was the only way i could think of so the script could check if this file is compressed using the zlib algorithm or not, come to think of it this might as well be the only way to make the script "decompress" the files on-the-fly if such compression exists. anyway i just delievered at least one sample archive file in which literally no compression algorithm is used. here.

why did you decide to ignore the INFO_INFO field provided by the format? it's not that useful but it's part of the format and worked perfectly with all my samples

uhh where is this "INFO_INFO" you just mentioned?

[aluigi]

So, apparently, there is no field in the format telling if one or all the stored files are compressed or not, the only thing I noticed is that here the original TYPE field is 0x07 while in other compressed samples the 0xc0 KEY3-mask was set (for example 0xc7).
In the new WIC format the compressed files are identified by 2 high bits in the ZSIZE field, this solution is not used in the old format.
I would like to avoid to use work-arounds, maybe I will return on the game to confirm if KEY3 has any meaning in identifying compressed files.

My typo about INFO_INFO, I meant INFO_OFF.

[AnonBaiter]

My typo about INFO_INFO, I meant INFO_OFF.

oh yeah, for GC2 and beyond i kinda used it like this

Code: Select all

get FILES long MEMORY_FILE
for i = 0 < FILES
   get DUMMY long MEMORY_FILE
   get INFO_OFF long MEMORY_FILE
   savepos TMP2 MEMORY_FILE
   goto INFO_OFF MEMORY_FILE
   get DUMMY long MEMORY_FILE
   get SIZE long MEMORY_FILE
   get ZSIZE long MEMORY_FILE
   get OFFSET long MEMORY_FILE
   get PATH_OFF long MEMORY_FILE
   get NAME string MEMORY_FILE
   get DUMMY long MEMORY_FILE
   goto PATH_OFF MEMORY_FILE
   get PATH string MEMORY_FILE
   string NAME p "%s/%s" PATH NAME
   callfunction DUMPFILE 1
   goto TMP2 MEMORY_FILE
next i

as far as i'm aware though, i don't really remember ignoring any "crucial" variable.

[aluigi]

Ah gotcha, yeah that has sense because the array part is not necessary if the commented code (the one of "# useless, full paths are already available") remains commented

Now we have only to solve the mistery of the compressed files in the old format.

[AnonBaiter]

oh, that...
in case you want (or need) another sample i already have it delivered. here it is.