This time the .ttarch archive isnt so easily readable. Has anyone had a look at it yet? I've been using Filemon (http://www.sysinternals.com/Utilities/Filemon.html) to at least give me some info on how bone2 is reading the file.

Using it, I've worked out that the 'ttg_splash1.d3dtx' file is at offset 192876178 (perhaps slightly before or after that). I've been trying to glean some information by comparing it to its equivalent in bone1.
The beginning of the file has repeating patterns of 5679 255A 9CC7 101E - the same pattern that forms the 'corruption' in the Bone1 file (when the bone1 file has been xor'ed with FF). The rest of the file is pretty much the same.

So really I havent got anything yet. My guess is that the .ttarch format hasnt changed significantly for Bone2 - its just been encrypted - probably with the same algorithm used on individual files in the first game.

Any ideas anyone?

I had a look on it. Phew :)
The index seems to be compressed somehow as imo the "patterns" look different than in the (patially) encrypted files.
And the Dll is encrypted, too, so REing is not that easy... :(

Some of the file seems to be XORed with FF, while some of it doesn't. If you go to the offset in the DWORD at the beginning of the file (plus 4), you find yourself at some unXORed plain text, while other parts of the file have a suspicious amount of FFs in them.

By the way, has anyone noticed a "!patch_99.ttarch" file in the same folder? It might use the same format. It's also a lot smaller, so it's easier to explore.

Well spotted - that text references Activemark (http://www.trymedia.com/services/services.shtml) which is probably what they use to control the licensing and demo/full version activation.
I noticed the patch_99 file. I dont know if its a proper ttarch though, most of the file is xor'ed with FF - so it could just be a normal file.

I've also attached a txt file with all the visible text from the ttarch (recognised by 10 successive characters) - you can see that there are also compiler logs in there too.

The !patch_99.ttarch seems to be a valid ttarch. If you take the first DWORD, seek to that offset within the file, you get another DWORD with the size of the archive data. So imo these first bytes are the compressed index, other than that it's probably the same structure like the non-encrypted ttarchs.

Oh, Bg, and with "compiler logs", do you mean the "class xxx" text? That's probably their serialization stuff. If you look at the CSI files you can see that there's a list with "class D3DMesh" and similar text depending on the type of file. Imo they open a file and according to the next entry in this list more data is read from the file.

Yeah I meant the stuff starting on line 3645.
You're absolutely right about !patch_99.ttarch, I completely missed that. So its now a matter of figuring out how the index is compressed, which...isn't easy.

They've really gone to a lot of trouble to protect the resource files this time :(

Yeah, but it's understandable since the demo also contains the full version. That's also probably why the CSI game's resources aren't encrypted in any way.

telltale has made a demo of the csi game and placed it on their homepage..............it is only the partial game (the second case)

i do not know if it is encrypted or not..............but it may be worth taking a look at

Rather than start yet another telltale thread:
I've just released two more Telltale-related programs - see here for more info. (http://www.lucasforums.com/showthread.php?p=2138639#post2138639)

While I was making Telltale Explorer, I suddenly remembered Telltale's first game - Texas Hold'em. Sure enough it also uses a .ttarch archive, in Texas Hold'em though - nothing is encrypted. The prefs.prop file in the root folder doesnt have an encrypted header (as it does in other versions) and none of the files in the .ttarch are obscured. Its even got the original lua scripts in there in plain text format.

In the absence of a decrypter for the annoying 'pattern' and header encryption, the files in Texas Hold'em are probably the best starting point for anyone looking at the various file formats.

[Edit] Texas Hold'em also confirms what I suspected - that the voice files are encoded with the speex codec. Unfortunately it seems that the only way to play these back is to embed them into an ogg container - does anyone know of another way of playing speex stuff back?

Older versions of Speex didn't use Ogg as container, iirc I had a DLL somewhere of that old version I used in some of my tools.

I found that "colors.lua" and "colors.lenc" (the lua one from Hold'em, the lenc one from CSI 3) are the same size. But it seems to be something more advanced than a simple xor-based algorithm. Also, I poked around in the disassembly of the mll file and it really seems to be more than xor.

The header of Bone GCR is probably encrypted with the same method.

I'm really excited how Sam 'n Max's format will have changed :)