💾 Archived View for gemini.spam.works › mirrors › textfiles › phreak › 0ainfo.txt captured on 2023-01-29 at 10:23:32.
⬅️ Previous capture (2020-10-31)
-=-=-=-=-=-=-
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