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