Author Topic: examples for "TTComp archive compressed" except (bin-4K)  (Read 1821 times)

jenderek

  • Sr. Member
  • ****
  • Posts: 373
examples for "TTComp archive compressed" except (bin-4K)
« on: June 03, 2021, 08:10:24 PM »
Hello trid users,

i am doing inspecting some files which are described by TrID as "TTComp
archive compressed (bin-1K)" by ark-ttcomp-bin-1k.trid.xml. So i take a
deeper look and i need some TTComp compressed samples.

As reference a page on file formats archive team web site about TTComp
archive is mentioned in definitions. All mentioned samples are of type
"TTComp archive compressed (bin-4K)" described by ark-ttcomp-bin-4k.trid.xml
or mentioned URL are dead. I also tried tool TTCOMP.EXE to create my own
TTComp archives. Unfortunately that tool has no option to change dictionary
size or switch for binary or ASCII compression type. And all generated
examples are of binary type with 4K dictionary.

I also search on the net for such samples and software for compresses
archives, but i do not succeed.

So i need non bin-4K examples for TTComp archive compressed examples,
especially for bin-1K variant or software that can produce such
examples.

So thanks for tips and/or examples.

Jörg Jenderek

jsummers

  • Newbie
  • *
  • Posts: 4
Re: examples for "TTComp archive compressed" except (bin-4K)
« Reply #1 on: June 13, 2021, 04:21:30 PM »
I'm not confident that I understand what "TTComp" really is. But everything I've seen is consistent with it just being raw PKWARE DCL-Imploded data.

I've used the Go software at https://github.com/JoshVarga/blast to make maybe-TTComp files with different settings. The software seems buggy, but works for small files. Results of compressing the string "AIAIAIAIAIAIA" in all the possible ways:

Code: [Select]
Binary-1024: 00 04 82 24 25 8f 80 7f
Binary-2048: 00 05 82 24 25 0f 01 ff
Binary-4096: 00 06 82 24 25 0f 02 fe 01
ASCII-1024: 01 04 62 41 f2 08 f8 07
ASCII-2048: 01 05 62 41 f2 10 f0 0f
ASCII-4096: 01 06 62 41 f2 20 e0 1f

For what it's worth, it seems possible to do stricter format identification, because the last 15 bits of the compressed bit-stream should always be 000000011111111 (which would mean "match-length 519" if it weren't a special code). Making reasonable assumptions about padding, that means the last 3 bytes of a file should match one of these 8 patterns:

Code: [Select]
xxxxxxxx 0000000x 11111111
xxxxxxxx 10000000 01111111
0xxxxxxx 11000000 00111111
00xxxxxx 11100000 00011111
000xxxxx 11110000 00001111
0000xxxx 11111000 00000111
00000xxx 11111100 00000011
000000xx 11111110 00000001