Identifying crypt8 types from cyphertext alone.

For 08hxFFh crypt8's, I've been able to identify them from the family of payload length variants (len 9-15) which share that common first 8 bytes, even in cyphertext. The residue bytes (those beyond those first 8) are not encrypted with the BC, only with the SC xor.

The family of 08hxFFh crypt8 full payload length variants looks typically:



By xor'ing the residue bytes of one length variant together with any of its longer sibblings, you will see 0x00, 0x00... 0x7F. That works in both plaintext *and* cyphertext due to the nature of the SC. So, if you see that pattern in a crypt8's family of length variants, there's a strong chance that's an 08hxFFh crypt8.

There also exist encoders which have residue bytes with trailing 3 x 00h. Here the family is:

and a similar technique can be used to pick out the 08hxFFh C8 with high confidence.

Apparently the v1 rainbow table tool can in some circumstances pick out from that family of B8h triplets x030000, x000300, x000003 a likely B8hx030000h C8, and tag it as such. All members of that triplet family have only one length variant each, so no such tricks with residue bytes can be used. Does anyone have an inkling as to how the v1 tool might do that?

OK, I now have a scheme to identify each of the B8hx030000h triplets in cyphertext. It's a bit messy, but here goes...

For the sake of brevity, I'll label each payload of the triplet set thus:

B8hx000003h - A
B8hx000300h - B
B8hx030000h - C

These are similar packets: 'A' is stuffed with the sequence 00 00 03 00 00 03 00 00 03... & the same pattern shifted 1 byte either way for the other two. The three types arise from a super-sized sequence of '00 00 03' repeated, then cut to fit successive B8h even-length payloads. Thus the pattern is maintained perfectly across the boundary of one ts packet's payload to the next, and we get this ABCABCABC... triplet sequence of similar counts.

The begininning of this super-sized '00 00 03' block occurs most often in the middle of a payload which starts off with video data. And the last part, which doesn't fit the 184 byte payload, is stuffed into an AF packet at the end of the ABC sequence. In the middle ABCABC... or BCABCA... or CABCAB... impossible to tell which is which!

The answer to the problem lies in the adaptation field that follows, allowing us to tag each of the triplet with their plaintext, while looking only at the cyphertext.

Method: we look for a block of these repeating triplets in the ts, then see if it is followed immediately by a ts packet with an AF (and of the type also including a short payload). That small payload is a perfect continuation of the 00 00 03 00 00 03... pattern from the previous B8h packet, but whatever its length, *always* ends 03 00 00 00 (breaking the pattern) on the encoder I studied. Knowing the length of that small payload, we can work backwards filling in with '03 00 00' to discover where the pattern fell in the preceding triplet ts packet(s).

Or, more simply, take that AF length byte, divide by three, then see what the remainder is:

0 - packet prior to AF is triplet A
1 - packet prior to AF is triplet B
2 - packet prior to AF is triplet C <= B8hx030000h

Of course when we know any one of A/B/C, we can label them all, as they always seem to arrive in the order ...ABCABCABC...

One exception to this was a following AF of length 79h where the payload was something other than 00 00 03 padding. Ignore those! Perhaps there are other exceptions, as I've only studied one encoder.

Maybe the V1 rainbow tool uses this same scheme to tag the B8hx030000h, or some other?

(With thanks to Martin Wigston for pointing out that the V1 tool did this tagging, and on what feed/encoder!)

To identify B8hxFFh in cyphertext:

1. First identify the 08hxFFh C8 as per post 1 in this thread: you can safely assume that the preceding packet for the same vpid is a B8hxFFh.

2. Likewise, identify other XXhxFFh C8s by their residue/length variant XOR's: B8hxFFh always precedes.

3. More crudely:
Do we have a block of identical packets before an AF? Yes -> good chance penultimate packet is a B8hxFFh.