Bone "data.ttarch" file format

[Benny]

That sounds like a good idea, I'm downloading the sdk now.

[Benny]

Hmm, I installed the August sdk but it doesnt seem to have installed any of the tools. When googling I couldnt find anything about dumping dx textures.

[john_doe]

It's called PIX: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/directxsdk/Tools/Performance/PIX.asp

[Benny]

I've got it and tried using it with Bone. Unfortunately when I use it Bone runs, but nothing is displayed on screen and I seem to get no results. I'll keep trying.

 

Also, t3.mll is actually a .dll, if you open it with a resource viewer you can see dialogs such as the script debugger and chore tracker.

 

[Edit] Whoops, I forgot that I'd renamed data.ttarch, I'll try again :~

 

[Edit2] Nope, I still cant get it to capture any textures or screenshots.

[Benny]

I've been playing with ttg_splash1.d3dtx - since its mostly white its easy to see the corrupted areas and also to know what colour those areas should be.

Some interesting stuff:

This is what you get when you rip the original dds image

Its DXT1, with no mipmaps and 1024x1024.

 

I went through the file and replaced the obviously corrupt bytes with what they should be (0000FFFF), I then put the file back into the game - this is the result.

As you can see its the corruption on the right that gets altered not the black bands - if you also look at that image, its 800x600, while the dds image is 1024x1024 - the aspect ratio is wrong. The black banding must be caused by the aspect ratio. Its possible that when the image is resized to the correct ratio those black bands line up with the corrupt areas.

[counting_pine]

(I see you're a Paint.NET fan.

Assuming a "square" is 4x4 pixels, it looks like one corruption pattern repeats every 512 squares, while the other repeats every 800 squares.

I'm not sure the corruption is caused by the aspect ratio though. Wouldn't that mean that the game loads, decompresses and scales the image before reversing the corruption?

BTW, what did the image look like in IrfanView after replacing the obviously corrupt bytes?

[Benny]

Like this (looks like I missed a bit).

 

I still think its something to do with the aspect ratio, it would explain why textures like ui_options.d3dtx dont get the black banding - because they are never resized.

 

Right now I'm trying to see if I can work out some algorithm for getting the right value to xor the corrupted bytes by.

[counting_pine]

I would have thought that ui_options.d3dtx.png doesn't get much corruption simply because of how small it is.

 

 

I don't think the corruption is a simple xor.

I tried xoring all the corrupted areas (every 4096 bytes there's another 64 bytes of corruption) with the same value, and I got this.

I think this corruption is actually a mapping. Each possible DWord gets corrupted to a different DWord. For a given file, it's reasonably easy to find what "00 00 00 00" and "FF FF FF FF" map to, and maybe a couple could be worked out from the header, but we don't know what the algorithm is for the mapping.

 

Whatever it is, I suspect it might be "seeded" from somewhere in the first 64 bytes after the header. (If it's seeded by the filename, you could probably show it up by swapping two files, e.g. ttg_splash#.d3dtx, and see if they display correctly.)

 

EDIT: They do, so it's not seeded by the filename. My money would be on the first 4 corrupted bytes. Not much help though, without knowing the algorithm.

 

EDIT2: The first 24 bytes (not including SEBM) seem to be common to every file. I'm not sure what this means, but I guess it means it's not encrypted in the same way.

[john_doe]

Something funny I just found: There's a string in the t3.mll file "CSIEvidence". Seems they've been working on the CSI game for some time

 

Edit: And a lot more of CSI references

[Benny]

I was looking through some files this weekend and I found my notes for the encryption. I'll repost them here in the hope that they can help someone else.

 

I had switched from looking at the textures, to looking at the .prop files and was trying to get somewhere by comparing the files from different games.

 

Prop files:

• Texas Holdem - All prop files unencrypted
  
• CSI - All prop files in the ttarch are unencrypted, but those outside this (such as user_csi3_global_game.prop and prefs.prop) are encrypted
  
• Out from Boneville - All encrypted
  
• Great Cow Race - Prefs.prop file is encrypted - looks largely the same as in other games - but no 4 byte identifier at beginning
  

 

 

An unencrypted .prop file - from CSI

anim_group_colors.prop

 

4  - Identifier 'NIBM'
4  - No of classes (3)
4  - length of next string (17)
17 - string (class PropertySet)
4  - PropertySet params (3811171764)
4  - length of next string (11)
11 - string (class Flags)
4  - Flags params (2073868025)
4  - length of next string (11)
11 - string (class Color)
4  - Color params (2319156233)
4  - ? (0)
4  - ? (8)
4  - ? (0)
4  - Size of rest of file - including these 4 bytes (533)
4  - ? (1)
4  - length of next string (11)
11 - string (class Color)

 

In encrypted files, the first 68 bytes are encrypted, then those after this are xor'ed with FF and then there's usually a few at the end of the file that arent encrypted.

 

An encrypted .prop file - from Out from Boneville

anim_group_colors.prop

4  - Identifier 'NIBM'
64 bytes encrypted data:
3818 F83F B3C9 03F8 9011 7A96 5546 6F82 A914 1E8F D567 34E4 9CB4 274F BC8A 9256 2F51 EC46 
C6A1 CA92 4761 814F CF26 70F6 82B0 8F83 A95A 45B3 F716 70DF E972 E1BC

 

Layout explained:

4  - Identifier 'NIBM'
4  - No of classes - varies between files. 3818 F83F - probably equates to 0300 0000
4  - length of next string - should be 17
17 - should be string (class PropertySet)
4  - should be PropertySet params (3811171764)
4  - should be length of next string (11)
11 - should be string (class Flags)
4  - should be Flags params (2073868025)

**Differences between prop files appear here. Probably because they reference a different class at this point.**

4  - should be length of next string (11)
11 - should be string (class Color)
**Encryption on encrypted files ends 1 byte after this at offset 68**
**xor'ing with FF begins here**

 

That all looks a bit of a mess now, but what I found was that in every .prop file, the bytes at offset 12-52 - were always the same and from looking at unencrypted files, I'm pretty sure this equates to:

'class PropertySet..).....class Flags...{'

'636C 6173 7320 5072 6F70 6572 7479 5365 74B4 DD29 E30B 0000 0063 6C61 7373 2046 6C61 6773 F9B6 9C7B'.

 

In most files the 16 encrypted bytes after this equate to:

4 bytes - string length (11)

11 bytes - (class Color)

In some files though this is different - probably because a different class is referenced there.

 

As usual I've explained this badly, but essentially what it means is that we now have some encrypted values and know what they should decrypt to. The 'class propertyset', 'class flags' and their preceeding string length values are found in every .prop file. I was hopeful that this would enable me to figure out the decryption, perhaps this info might help someone else.

 

Interestingly, when comparing files I found that when bytes 4-8 differ (the number of classes) - then the next 4 bytes (string length) also differ. This may indicate that the encryption works in 8 byte blocks.

[Benny]

The updated version of Out from Boneville now uses the new style .ttarch that The Great Cow Race uses. I think its a pretty safe bet that Sam and Max will use it too.

[john_doe]

After you posted the post before the last I checked the disassembly again but I couldn't even find a piece of code that even remotely looked like a decryption function, it's so messy because of all the C++ stuff. Usually it helps to find the "file read" function and backtrace from there and then check what's done with the buffer that has been read. But with all this C++ stuff it's 100 times more complicated

[Benny]

I remember looking at a function called 'encrypt metastreams' in Bone 1, I guessed that this was what was called when an encrypted file like prefs.prop was saved. I hoped that I could work out how the encryption was done and then reverse it. Unfortunately it was hopelessly ambitious. Since I know next to nothing about assembly, I was just fumbling around in the dark :~

[Benny]

I remember looking at a function called 'encrypt metastreams' in Bone 1, I guessed that this was what was called when an encrypted file like prefs.prop was saved. I hoped that I could work out how the encryption was done and then reverse it. Unfortunately it was hopelessly ambitious. Since I know next to nothing about assembly, I was just fumbling around in the dark :~

[Benny]

As expected Sam and Max uses the new ttarch format, so far it seems like a good game and everyone should buy it There are also 2 .d3dtx files that also feature new encryption (I think they just have a larger encrypted block at the beginning).

 

Regarding 'encrypt metastreams' in my post above - I did a little more digging. The engine creates a 'MetaStreamTemp_0' temporary file in the same folder as the .exe (in all tt games). If you look at this file, it contains the same data as prefs.prop - only unencrypted and not xor'ed. Perhaps that function does indeed produce the encryption in prefs.prop.

[john_doe]

I think I finally found the code that does the decrypting.

As expected, the algorithm seems to operate on 8 byte blocks, it could be Blowfish. There's a function where a rather big table is generated, possibly the password string.

Then it decrypts several bytes, the length depends on the first 4 bytes of each file, then it does the "XOR 255" stuff (actually it simply "NOTs" the bytes).

There's still a lot of stuff besides these two parts I haven't figured out yet and don't know if it's used in the decryption or not.

Well, at least I now know where to look

[Benny]

Well done! It sounds like you're on the way to figuring it out

It'd be brilliant if you could, you've certainly come much closer than anyone else so far.

[john_doe]

Ok, so it's definitely Blowfish. The tables I talked about in my last post are the Blowfish tables. I tried to decrypt the first bytes of the props file but nothing useful came out.

They probably process the data before or after the decryption.

[Benny]

Nice one! So those tables are the key that the data is encrypted with? You're nearly there now!

[john_doe]

No, the tables are specific to the algorithm. The key is 56 random characters.

Also, this is just for the archived files, I don't know yet if it's used to encrypt the archive directory, too.

[tofu-sensei]

looks like you're right about blowfish. voices use the speex codec.

[labass]

Any news on this? I'd just love to get access to the sam&max files.

[john_doe]

Read this news entry from bgbennyboy's site: http://quick.mixnmojo.com/telltale-tools-an-update

[labass]

Oh, I see. What a shame, understandable but still...

[saulob]

oh my oh my....

so no luck... in editing the 'game.langdb' from Bone: Out from Boneville

 

I'm not in the mood for Sam&Max now... but.. the .langdb file from Bone is out there... and nobody was able to edit it ?

 

Ok, John, Blowfish right ? let me check what I can do about it...

 

btw, I know nothing about it...