246 lines
11 KiB
Plaintext
246 lines
11 KiB
Plaintext
|
|
|
|
I have posted almost anything I know so far in these code observations.
|
|
Furthermore I don't have the time I wish I had to look closer at stuff.
|
|
My observations are mainly based on approx. 2MB of hexdumps containing
|
|
the 32 byte messages from the decoder to the card, logged from various
|
|
stations. If they might be of interest to you please tell me and I
|
|
check how I could most easily make them available to you.
|
|
|
|
Marc
|
|
|
|
|
|
I noticed during the last few days some strange command bytes
|
|
on BSkyB's different channels. Obviously they are doing a lot
|
|
of unsubscribing at the moment. It seems they are using the
|
|
following patter:
|
|
- Messages needed for decoding, i.e. messages starting off with
|
|
0xE8 contain a command byte value of 0x92
|
|
- All other code packets are either subscription/unsubscription
|
|
commands, or the second byte is 0x85 and all four signature
|
|
bytes are wrong.
|
|
|
|
Now, about these subscription/unsubscription commands (and there
|
|
are a lot more unsubscriptions than subscriptions...):
|
|
Why would they want to unsubscribe people from channel IDs 07, 0A
|
|
or 0B? I've never seen any channel use these IDs, nevertheless
|
|
these codes pop up from time to time. Are they trying to destroy
|
|
the 09 cards physically, or what?
|
|
|
|
The code packets with 0x85 as second byte are also interesting.
|
|
Usually all four signature bytes are wrong according to the series
|
|
09 algorithm, the overall checksum seems to be right, and the
|
|
third byte is always between 0x00 and 0x3f. (Usually the third
|
|
byte was between 0x00 and 0x7f and still is with the other code
|
|
packets, but with these 0x85 packets bit 6 is always zero.)
|
|
Byte No.5 is also rather interesting. Although I've recorded
|
|
more than 2000 code packets, byte 5 only had 133 different
|
|
values, where 0x00, 0xFC, 0xFE and 0xFF appeared most often.
|
|
If these packages are an example of the series 10 codes, I'd guess
|
|
they still calculate some command byte using the first 5 to 8
|
|
bytes.
|
|
|
|
If anybody's got any ideas about these, I'd like to hear them.
|
|
|
|
Marc
|
|
|
|
|
|
To whom it may be of interest... I've done some further statistics
|
|
on the codes BSkyB are using at the moment.
|
|
|
|
To be precise: I've logged quite a lot of the code packages BSkyB
|
|
is broadcasting at the moment. Then I looked closer at
|
|
1. All packages with correct checksum and current time index (0x50),
|
|
that are not essential for decoding (i.e. starting with 0xC0)
|
|
I refer to them as "series 09 codes".
|
|
2. All packages with time index 0x85. I refer to them as "0x85 codes"
|
|
|
|
The main thing I did was just checking how often each different
|
|
bytes appears as the nth byte of the message. Thus I found some
|
|
strange statistical features of the 0x85 packages:
|
|
- byte #2 contains only values ranging from 0x00 to 0x3f in 0x85
|
|
codes. I the series 09 codes the value of byte #2 ranges from
|
|
0x00 to 0x7f.
|
|
- byte #3 of 0x85 codes has an almost identical statistical
|
|
signature as byte #6 in the series 09 codes. (That's the byte
|
|
that contains the channel ID in messages with bit 3 of byte #0
|
|
set.)
|
|
- byte #4 of 0x85 codes contains in 67% of all messages either 0x00,
|
|
0xFC, 0xFE or 0xFF. Although almost any other value appeared at least
|
|
once in my logs, these four values cropped up two times out of three.
|
|
- bytes #7 & #8 of the series 09 codes contain only a rather limited
|
|
number of values, around 150. Since these are the first two bytes of
|
|
the (encoded) serial number this is not very surprising. In the
|
|
new 0x85 codes both bytes contain all 256 possible values with
|
|
nearly equal probability.
|
|
- bytes #27 to #30 of the series 09 codes (the electronic signature)
|
|
contain all 256 possible values with nearly equal probability.
|
|
Quite different with the 0x85 codes: So far, there have been exactly
|
|
27 different values for byte #27 and they don't look very random:
|
|
0x00, 0x01, 0x02, 0x03, 0x54, 0x55, 0x56, 0x57, 0xA8, 0xA9, 0xAA, 0xAB,
|
|
0xFC, 0xFD, 0xFE, 0xFF, 0x61, 0x62, 0x63, 0x64, 0x70, 0x76, 0x80, 0x81,
|
|
0x82, 0x83, 0x84
|
|
Byte #30 also has some strange (?) contents. While my logs contain
|
|
almost every possible value at least once, values ranging from 0x40
|
|
to 0x7f, and from 0xC0 to 0xFF appear approximately six times more often
|
|
than the other values.
|
|
|
|
If these 0x85 codes are valid series 10 codes, this then leads me to the
|
|
conclusion that the old scheme of 27 bytes + 4 bytes signature + 1 byte
|
|
checksum is no longer valid. It'll be interesting to see, whether the
|
|
channel ID with appear at position #3 after the switch over.
|
|
|
|
Marc
|
|
|
|
OK, it's the 3rd of October 95. What's new?
|
|
|
|
First of all, the 32 byte messages have the correct new month code
|
|
0x51. Interestingly, the messages with faulty signatures also have
|
|
a new month code: 0x86 instead of 0x85.
|
|
|
|
Second, there is one interesting new command bytes: 0xF1. Although
|
|
it's not brand new, it does something very interesting: it sets the
|
|
internal expiration date of the 09 cards. Originally this date was
|
|
set to 0x51, now they are being reset to 0x5D. This would mean, that
|
|
the 09 cards stay valid for another year. Since they are using
|
|
completely new month codes for the new 10 cards this doesn't necessarily
|
|
mean much, though. Furthermore, they are now using it with the serial
|
|
number 123456... which is quite odd in my opinion.
|
|
|
|
Third, they are fiddling with the channel IDs again. Free (i.e. open,
|
|
not even softencoded) channels are now broadcast with a channel ID of
|
|
0x0F. That means Sky News, the preview for the Disney Channel and
|
|
the first 10 minutes of TVX. On Sunday, Sky One wasn't correctly identified
|
|
by my software, but they have fixed that before I could look into it.
|
|
|
|
Marc
|
|
|
|
Oh, well, you can't turn your back on BSkyB for two days without
|
|
them using some new codes again... ;->
|
|
|
|
The new codes look like this:
|
|
74: C1 02 01 B1 12 34 00 FB 95 X1 X2 00 9F 28 8B 8F
|
|
04 AB 33 90 6B 6B 6B 94 7B 3F 94 6F CE 64 B7 89
|
|
|
|
X1 is a value between 0x00 and 0x7f
|
|
X2 is either 0x22, 0x62, 0xA2 or 0xE2
|
|
|
|
All combinations seem to be possible. The last five bytes are
|
|
series 09 signatures and a checksum byte.
|
|
|
|
[BTW: Either my software has some bug, or the signature bytes are wrong,
|
|
but these messages are certainly series 09 messages.]
|
|
|
|
The command byte has a value of 0x83, which is a kind of patch command.
|
|
It works similarly to the nanocommands, but can modify up to 8 bytes
|
|
of the cards EEPROM contents. To be precise: the code message above
|
|
stores 5 bytes (1b 90 3f a7 04) at address $0BBC of the 09 cards.
|
|
|
|
Now this is nasty. If this code is really accepted by 09 cards
|
|
(I'm not sure because at least I get wrong signatures), then it
|
|
completely destroys the cards ability to calculate nanocommands
|
|
or to process codes with a command byte value of 0x83 correctly.
|
|
Even if BSkyB started sending out nanocommandos again, the card
|
|
would NOT use them. The 5 bytes written to address $0BBC pretend
|
|
a command byte value of 0x90 and prevent the xoring of the bytes.
|
|
This also prevents undoing this command message (!).
|
|
|
|
Furthermore this means: All software relying on nanocommands to
|
|
renumber, write protect/unprotect cards or read out the ROM won't
|
|
work with any 09 card that has accepted the above code messages.
|
|
|
|
Interesting move, though, since it could well mean that the 09 algorithm
|
|
might still be used by some channels, even after the switch-over to
|
|
the 10 cards. Otherwise I can't see much sense in BSkyB's doing this.
|
|
Furthermore, the code sequences last weekend that set the internal
|
|
expiration date of the 09 cards used a month code that would indicate
|
|
October 96 as the new expiration date, assuming that BSkyB will still
|
|
stick to their old scheme for the month codes. (This is perhaps not
|
|
very probable since they are using quite different month codes already
|
|
in some code messages. But perhaps this will be different for some
|
|
channels, or different depending on whether you use VC-I or VC-II.)
|
|
|
|
Ideas, comments, or new insights welcome.
|
|
|
|
Marc
|
|
|
|
Oh darn, so October 31st has been the Black Tuesday....
|
|
|
|
Thus it's time again for some observations of the codes used by
|
|
BSkyB at the moment.
|
|
|
|
First of all it is interesting that the first byte of the 32 byte
|
|
messages is 0xF8, instead of 0xE8, whenever an answer is required.
|
|
As far as I remember this makes no difference from the decoders
|
|
point of view (any experts who know better?), so I have to assume
|
|
that this has something do to with card internals.
|
|
|
|
The second byte is now (Nov, 1st) 0x87. BSkyB obviously still use
|
|
this byte as some kind of month code. Does anybody have any idea
|
|
why they jumped thus far?
|
|
|
|
The third byte still seems to be some random value in the range of
|
|
0x00 to 0x3F.
|
|
|
|
The fourth byte seems to be some channel identification as has
|
|
already been guessed before. But the coding is very strange, as
|
|
there are only 5 values in use at the moment:
|
|
|
|
0x21: Sky Movies, Movie Channel, Disney Channel, Sports
|
|
0x22: Sky One, EBN, Nickelodeon and the stuff on TP47
|
|
(I haven't yet figured out the schedule of THAT transponder..;-)
|
|
0x23: MTV, UK Living, UK Gold, VH1
|
|
0x24: Family Channel, Children's Channel, TLC, Discovery, Bravo
|
|
0x2C: QVC, Sky News
|
|
|
|
Interestingly, all those channels that weren't exactly identifiable
|
|
before the switchover now have ID 0x22 (Except for EBN and some other
|
|
new segm...channels)
|
|
|
|
I guess there has to be some subchannel ID, but I haven't found out
|
|
about it, yet.
|
|
|
|
The fifth byte is also rather interesting. Sometimes it seems to
|
|
contain only random values, but at other times it very consistently
|
|
contains only a few values. These values also seem to depend on
|
|
which channel you're watching:
|
|
Sky One: 01, 80, E4
|
|
MovieChannel: 01, 18, 40, 64, E4
|
|
Sports: FF, 10, 98, 80, 02, A8
|
|
TVX: 00, 40, C0
|
|
|
|
The way BSkyB send out (de-)activation codes while the 09 cards were
|
|
still active, I'd guess that this byte is some internal command byte.
|
|
|
|
Furthermore, in messages that require an answer, the fifth, the third
|
|
and the sixth byte seem to be connected in some way. (Maybe even including
|
|
the seventh byte.) Perhaps this is the hiding place for the subchannel ID.
|
|
For example, these code packets were recorded on Bravo:
|
|
|
|
F8 87 0D 24 FF B5 FA 67 6B C4 2C 25 67 67 1A 75 C4 ...
|
|
F8 87 0D 24 FF B5 FA 7C 62 1F BF FD 97 2F 9D 10 C1 ...
|
|
F8 87 19 24 8F 46 96 13 B1 78 CC EC 14 4F 71 9E 1B ...
|
|
F8 87 19 24 8F 46 96 14 3F A7 55 01 9D 91 B8 83 11 ...
|
|
F8 87 24 24 8D 1A 21 B0 8C AE 97 51 C0 8B A9 69 4C ...
|
|
F8 87 24 24 8D 1A B3 A1 8B 30 5C 76 E3 D8 51 27 37 ...
|
|
F8 87 24 24 D6 40 35 87 C5 CD AD E7 BA 52 24 A0 C0 ...
|
|
F8 87 24 24 D6 40 35 93 99 B2 9C 66 CB F9 1F 93 86 ...
|
|
F8 87 33 24 43 43 3F 06 8E 72 E9 3F C4 C7 C6 D9 66 ...
|
|
F8 87 33 24 43 43 3F B9 E2 65 E0 3F CE 1B 21 A0 A7 ...
|
|
|
|
Note that the value of the sixth byte seems to be defined by the values
|
|
of byte 3 and byte 5. Often, but not always the seventh byte is constant,
|
|
too, in different messages with identical 3rd and 5th byte.
|
|
|
|
BTW: The calculation could still be dependant on the second byte, i.e.
|
|
the month code. These two packages were taken from Sky One:
|
|
F8 86 00 22 80 AA DF 31 02 81 B2 1C E1 4B DA C8...
|
|
F8 87 00 22 80 2E C5 2C 5A 90 27 DA 56 DC 84 B2...
|
|
F8 86 00 22 9A A3 D9 6F 35 63 4F EF D9 69 08 80...
|
|
F8 87 00 22 9A A0 E7 05 04 8B 2E E8 F7 76 A6 0B...
|
|
|
|
Marc
|
|
|
|
|
|
|