Encrypted file - any ideas?

[bgbennyboy]

Here is a file from the game Bone: Out from Boneville and here is a file from CSI: 3 dimensions of murder. Both games are by the same developer and I'm pretty sure that the data for both files is the same.

The Bone file though, is encrypted - the CSI one isnt. If you xor the file from Bone with FF, you'll see that the data is the same. However the head and tail of the Bone file is somehow encrypted differently.

Can anyone work out an algorithm to get the head of the Bone file to match the CSI one?

[Strobe]

The data was indeed XORed with 255.

the Tail is not encrypted at all =o ...

and...the header is for now a mystery. Im not even sure that
the header is really XORed, it seems to strange, and does not
have a pattern. (atleast not for 8bit XORs).

possibly ROL/ROR or XOR 16/32 bit.

if you come up with something more, let me now

ive tried using "Inverse" aswell instead of XOR, and that does the same as
XOR 255. one good thing here is that the places in CSI file that are "0000"
have similiar values, but has the bytes flipped somehow,
and when looking at the bits, the seems to be inverted.

example: on the 0000 places of the header in the CSI file, there
are instead F83F , 03F8, 8F83 ? see the similiarities?

almost the same values, but is flipped somehow.

[Strobe]

could you post more BONE encrypted files? =o
i would need more of them too look at patterns.

[bgbennyboy]

I can certainly post more bone files, unfortunately the file that I've already posted is the only one common to both games. I've uploaded some more here

If you want to look at any more, Bone can be downloaded here and the .ttarch archive can be unpacked with my dumper here.

[Strobe]

Ive downloaded some of the files and started looking,
its kinda interesting hmmms....

so, i decoded one of the splash screens using Inversion on all bytes in the file
and came up with an DDS image. however......while the image
is fully readable, it still seems to be something we dont know ...
because, if you look at the image it looks kinda good,
but has small glitches in a pattern, and i suppose the original image is not
looking like this?.

i have made small notes while decoding, and ive found out that there
seems to be a pattern. all blocks are 4096 bytes.
and the extra encoded block is always 64 bytes, however
the gap between the None-coded and encoded varies in size,
but in the end, the encoded+none encoded blocks
always sum up at 4096. so this might be solved soon.

here is my notes i took while decoding the DDS file
{
8C0 = 2240
6C0 = 1728
040 = 64
040 = 64
= 4096
}

Block1
{
FC0 = 4032 (a)
040 = 64
= 4096
}

Block2 {
DC0 = 3520
1C0 = 448
040 = 64
= 4032 (same as a)
+ 040 = 4096
}


i dont know if it makes any sense, i just keep it as reference later so i can
see what i have been doing

[bgbennyboy]

Sorry, yes I forgot to mention that the dds images have that corruption, its very odd - see this thread for more information.

I dont know if the corruption is related to the encrypted file headers. The dds (dxtc) files are the only ones that have this extra encryption.

[mambox]

if i could recommend one thing...post all links before expecting infos it may help people who reverse it.

[bgbennyboy]

Thanks for having a look at this Strobe. I think the image corruption is a seperate issue from the encoded headers - it may just be something implemented in the image decoder since the font files (which are also dds' have it too).

[Strobe]

It is really funny this "format"........i dont understand really one would encrypt the archive header so badly and leave the rest of the file almost
intact with just a Invert byte order, and some patterns encoded?

for the info, some of the patterns are also XOR 255 (or inverted),
, its a combination. i have even tried being desperate and XORed
the encoded blocks with the lenght of the archive. no luck though.

However decoding the images in a dumb way would be just to follow the
pattern and rewrite it without decrypting it. but thats no fun =o

possible theories:
1.The creator of the format was insane and just wanted to mess
with people trying to extract it.

or

2.The "encrypted" patterns actually serves a purpose?


however, im still voting for theory number 1.

and a sidenote, im actually glad you didnt post any information on this
at first, that would have made me bored. Now when ive started figuring
out this by myself im much more triggered to get it done :X

[mambox]

and a sidenote, im actually glad you didnt post any information on this
at first, that would have made me bored. Now when ive started figuring
out this by myself im much more triggered to get it done :X

its masochism

i was just speaking about the re-invent the wheel theory.

[saulob]

Yeah, I was reading the lucasforum post...

Nice, they find the RIGHT encryption on the Bone data.ttarch file...

It's Blowfish. I tried but no luck... who can help on this ?

Thanks.

[aluigi]

I have figured the algorithm today while I was working on the TTARCH files in general.
practically this type of encryption works in the following way:
first are read the 4 bytes at the beginning of the file, it's needed to select 3 parameters:
- size of each block
- after how much blocks is performed the blowfish encryption
- after how much blocks the block is in clear-text

so if the parameters are 0x80 0x80 0x50 the first block is decrypted with blowfish using the same key of the archive, the second one is simply XORed with 0xff and the one at offset 0x2800 is clear.
I have implemented everything in a script altough, obviously, a stand-alone tool is probably a better for this particular complex file format (but I'm too lazy).

[bgbennyboy]

Wow, this thread is a real blast from the past.
As a sidenote - John_Doe figured out the ttarch and file encryptions in 2006, however Telltale asked that the decryption tool not be made public. See here for more.

[Rheini]

however Telltale asked that the decryption tool not be made public

Who cares?

[saulob]

however Telltale asked that the decryption tool not be made public

Who cares?

Well, he did