POWER Vu KEYS Many thanks to djangel912 Last edited by djangel912; Today at 09:25:15 waiting for software support for receivers- work in Opticum 4000c tested 00E00 00 2EF2C2E12DF295B069407C8D8A01AD97 ; National Georaphic Channel Hun SIRIUS 5*E 00E00 01 33729C2DAE85D63742722BA84205042B ; National Georaphic Channel Hun SIRIUS 5*E 00E00 02 5DAABF727775CFE15727DB34C7033E31 ; National Georaphic Channel Hun SIRIUS 5*E 00E00 00 D3853129CA9EDEF6DBE946851958E325 ; Discovery Channel Europe Hun SIRIUS 5*E 00E00 01 EA90F91B8F58A23C9C2BDBFBD2491B79 ; Discovery Channel Europe Hun SIRIUS 5*E 00E00 02 FC2087CCAE1E747AF6797D0966F05EA7 ; Discovery Channel Europe Hun SIRIUS 5*E 00E00 00 E2BC1F42544941E9A83ECCABE55682D7 ; Hallmark Channel Estern Europe Hun HOT BIRD 13*E 00E00 01 D9175082F3FEF042381DF063454E4720 ; Hallmark Channel Estern Europe Hun HOT BIRD 13*E 00E00 02 9B90614C29AE2262D35B6343B1FC2004 ; Hallmark Channel Estern Europe Hun HOT BIRD 13*E no external links, pls Power Vu / Scientific Atlanta Info full dump of powervu rom/eeprom from D9234 receiver~ Code: Motorola SC27 Smartcard processor (simular to Dave F c*rd) 256 ram 3k eep (unique areas have been replaced with FF) 16k rom glitchable: yes, vcc+clk glitch work to overwrite stack. frequency: internal = external 1:1 max freq: chip run at 6 mhz no problem. era: 1993 algorithm: Stream cipher, k*ys are 56 bits each. poi: $0540 = key sets [7 bytes each] $0768 = crypto entry $10FA = 4 byte ISE # $4005 = reset vector $44C1 = getchar $4500 = putchar wit parity = 1 $4501 = putchar wit parity = 0 $46F3 = eeprom erase 4 bytes at location in (3D:3E) $4714 = eeprom write 4 bytes at location in (3D:3E) swi call = chip reset chip infos: 16 pin dip. 185 310-052 (C) 1993 0D41JZREAK9642 (data code packaging) register 0x08 may contain RomPage(ROMPG) bit may not likly. ;/* Memory Map: +--------+ */ ;/* | Regs | 0x00 - 0x0F */ ;/* +--------+ */ ;/* | RAM | 0x10 - 0xFF */ ;/* +--------+ */ ;/* | | */ ;/* | EEPROM | 0x500 - 0x10FF */ ;/* | | */ ;/* +--------+ ;/* | ROM | 0x4000 - 0x7FFF ;/* | | ;/* +--------+ 0x7FF8 - 0x7FFF ROM User Vectors */ ;/* ;/* 2B00-3FFF same as 6B00-7FFF Re: POWER Vu KEYS Motorola put a SC24 (smart card) chip, "top secret", not much out there on the internet, they removed many of the publications they had previously, it was placed into the SA8600X series of boxes. In the South America versions, it had the 16 pin dip chip, similar to what you have here, in the USA models, they had the 20 pin SMD chip. I have some info on it, including parts lists of the parts in those 8600x boxes... Yes, from my information, on the SA8600x boxes, they used a SC21 in the patents, but in the actual boxes, they used a SC24 chip. (translated) further reading said, that Sky P9 and the F-Card of DirecTV uses the 68HC05SC21. I have found some Info at google about 68HC05SC27 (In the SA8600X boxes, they are using a 68HC05SC24 chip, which as I said, is top secret! We have found that this chip, contains everything you need! If you have a box, that is 100% subscribed, and you remove this chip, and substitute it into another dead SA8600X box, it immediately becomes alive, and now has the same serial number and ESN number that was in the legal box! Therefore, the secret is to read this chip, if you can! I has the secret! If you can duplicate it, or substitute it with a Microchip Pic chip, you have turned on the SA8600X box, and may have also turned on other SA boxes as well!!!) Wurde nicht die Motorola Smartcard Produktlinie von Atmel als AT05SC... übernommen ? (translated) has not atmel taken over Motorola`s smartcard product line as AT05SC... ? (they have licensed Atmel to produce this same Motorolaa 68HC05SC24 and other SC21 and SC27, and other SCxx chips. I have some material on this chip. Like I said, it is "top secret" chip!!!) I hav edone extensive work on this. I use a modded T911 glitcher w/ modded newd13 .hex. Will post .XVB script soon for everyone. You have to glitch the check on the length. Immediately after sending in the first byte [length], it is checked if greater than 0x23. I glitched this using my newd13 glitch with their special 32 bit io to overwrite the stack. glitch this instruction: Code: cmp #023h ; 4434 A1 23(2) If LEN > 0x23, error bhi mot4478 ; 4436 22 40 (3) <error> here is the code i send into the card: Code: // dumps memory 0xFC, // checksum cant be calc so ignore FF then data comes out 0x11,0x12,0x13,0x14,0x15,0x16,0x17, 0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x1E,0x1F, 0xA6,0x5A,0xAD,0x15,0xC6,0x05,0x00,0xAD, 0x10,0x3C,0x26,0x26,0x04,0x3C,0x25,0x27, 0x06,0x5F,0x5A,0x26,0xFD,0x20,0xED,0x20, 0xFE,0xCC,0x45,0x00, 0x0C,0x0D,0x0E,0x3F, 0x40,0x01,0x02,0x03,0x04,0x05,0x06,0x37, 0xf0, 0x0D, // this is length till finished 0xf2,0xf3,0xf4,0xf5,0xf6,0xf7, 0xF8,0xF9,0xFA,0xFb,0x00,0x20, //sp=0x0020 0x55, // fake checksum messy but works. if you glitch good after giving the "0xFC" length, you receive 0xFF 0x5A then dump from 0x500 on. eeprom dump is from 1.05(2). I think (2) means algorithm 2 is used. Ok,at least we know where this come from.nice. Let me add some more info about ECM packets.(not from this service ,though,but I don't think they are different). Down there is a partial breakdown of the raw packets. Code: 80 30 56 30 37 20 0e 00 00 00 00 cf b2 00 25 9c ea 99 c6 c6 76 b1 ad 8d c9 ec 2c 39 00 00 d0 00 00 78 b1 a5 fe 31 fc c6 47 9b 17 d5 9b 19 97 5f df 0f 3d 51 fb a3 6c d7 23 73 2b 09 30 17 23 0e 00 00 00 b0 00 73 5a e6 0c c9 4c 0c 42 82 79 e9 f1 b8 64 45 79 e0 52 ca 4b 80 30CA table 56 data lenght 30 37section lenght 20tag 0e 00CA id 00 00 00 security level 37 some type of counter (maybe continuity??) b2 00Encrypted base CW will be send via command 00 to the xSE.If bit 6 of the first byte is 0 it will be send to the ISE (the default).If it is 1,then it will be send to the OSE (the smatcard). 73 a6 97 0c 75 dd ac 83 d2 07 9e 7e e2 21encrypted base cw 00 [00 d]0program number 00 00 da 05 3f 68 f0 6e c3 d7 31 15 a4 70 51 96 0c 30 53 3f a7 0f f2 4b 07 62 11 bb 18 encrypted cw seeds for video (and audio also?) 30 17 23 0e 00 Ca id 00 00 b0 00 82 f9 c5 42 fa 93 61 3f ae f6 2d ce 77 9b aa 20 91 3f 19 c1 encrypted cw seeds for (audio?) I can't actually aim to that specific sat,but i'll ask somebody that can. We need to see the original packets for the service in question,since the keys in the eeprom would only decrypt those. dumped a few different ones and the table of keys at $0544 is always different. there is a common key in rom and this same common key is in the rear of the eeprom around $1020 area. it has $41 in it. audio is not encrypted. it is simply being blocked like Dave. did you even disassemble the code yet? No,not yet,but.... The way to decrypt the emm and ecm is known since last year,I posted a little bit of it. And the docs have more than that,so,this is the same as nagra,or other encryption:if you don't have a keyset to decrypt the emm and ecm to make some tests,having the full eeprom dump not necesarily mean you will be able to have anything of clean video. We can get about 2000 powervu encrypted channels in the domestic arc,and if we don't get their specific keys for them,there is no point to open a thread about it.(some only video encrypted,some also audio) And I fully understand the privacy of all this. But I also know nothing is possible without the keyset. Actually,you can see the keys are 7 bytes,but des need 8 byte keys. The ird expands this 7 byte key to 8 bytes by inserting an odd parity bit after each 7th bit. I mean,there are things known,as you see,problem is there are no keys available. No DES inside of the powervu chip sorry. Running a stream cipher if you looked at the code you would see this. It has a permutation on the key and a sbox type lookup but it is NOT DES. you confusing the DVB part of the decoder itself. algorithm is not know by anybody until now. Code: mot10A0: .db $21 mot10A1: .db $05 ; Minor version mot10A2: .db $04 ; # of keys present (max key ofs) mot10A3: .db $02 ; Algo version ; 56 bit key to be loaded into 4F-55 from here or 4094 ; ; keys are currently the same (rom and eeprom) ; mot10A4: .db $41,$56,$9A,$76,$59,$FA,$26 ; 10A4-10AA Code: brclr7 05Eh, mot683A ; 67E7 0F 5E 50 (5) if 5E.7 = 0, skip decrypt stage ;- - - - - - - - - - - - -; ;- - - - - - - - - - - - -; ;- - - - - - - - - - - - -; brset5 012h, mot67FF ; 67EA 0A 12 12 (5) if 12.5 = 1, key is unique from 500 area ;- - - - - - - - - - - - -; ldx #006h ; 67ED AE 06 (2) Load 7 bytesmot67EF: lda mot10A4, X ; 67EF D6 10 A4 (5) brset4 012h, mot67F8 ; 67F2 08 12 03 (5) if 12.4 = 1, use 10A4 key ;- - - - - - - - - - - - -; lda mot4094, X ; 67F5 D6 40 94 (5) <- rom keymot67F8: sta 04Fh, X ; 67F8 E7 4F (5) Store into key[x] decx ; 67FA 5A (3) bpl mot67EF ; 67FB 2A F2 (3) ;- - - - - - - - - - - - -; bra mot6827 ; 67FD 20 28 (3) Skip 67FF & go straight to decrypt.. disassemble the code and examine the code at $0768. this is the stream-cipher entry point. registers controlling the cipher are: $4F-$55 = 56 bit key X points on data to decipher $57 control how many rounds per byte decrypted $59 controls total number of rounds to execute. cmd $00 is some type of ird key to prevent chip swapping to your friends box. cmd $00 is most likely random data from the ird into the card. the common key for decryption appear to be at $10A4. i dont think they have ever changed their key. i seen two different algoriymths. seen algorithm 2 and 3 and all share same key at 10A4 but crypto changes. Ok,this is a lot. Let's see what comes out after dissa. n another note. Do you see powervu using csa to encrypt Video/audio?? If not,then all the work will be limited to use their own ird. Humm. Can you answer that? they are dvb compliant but audio is not encrypted. I have the audio coming through when flipping through the menu for a second then it becomes muted. The control word is generated using the stream cipher. Each time the stream-cipher is called, it falls through a key permutation and then some rotates and finally xor's your input byte against a byte of the result from above. Some of the instructions call the crypto using only 2 rounds while the main ins00 calls it 8 times before xor'ing against your input data. Again, I believe ins00 is to create a type of session key between the ird and ise. I bet you 1 peso the keys of your ise are also in your stb code. did you glitch into your chip yet? They have a way to mask the audio so it appear encrypted but is not. In many sats,this same thing happen. What i see is they use 8190 as pcr pid sometimes,so,changing this value to 8191 (null pid),gets the audio good,with any dvb ird. In other cases you need to make the video pid 8191,to hear the audio. The general idea is not to use their own ird,but any other dvb options,like dvb cards. For this,the main video/audio encryption should be done using csa.(this becasue people could get the channels with other means,more accessible) If powervu do not use csa at all,then uses its own system,and most probably we won't be able to have any other solution but to use their own irds. Personally,I won't be going that route,but now that the chips can be read,and if possible to write,maybe cloning is possible. My only intention is to understand the algo to decrypt the ecm/emm,with the hope they use csa. But nobody can cartify this yet. I'm sure you could post the files at cardcoders for analysys. More things will come out from this,i'm sure. interesting. what are you using to log the PIDs? The receiver has STi3520 MPEG-2 decoder. Any DVB pci card will lock into a powervu feed and could log the ecm/emm from the stream. What's very curious about powervu scheme,is that they seem to be able to encrypt audio and video with different control words,while in dvb,is generally only one for both,so the csa(if they use csa at all),is been fed differently. Maybe you are not aware of csa encryption. Simply put,most all feeds are encrypted primarily using csa algo.(this imply all irds have a csa hardware module inside) This algo use 8 bytes seed keys to encrypt. The provider must send this 8 bytes keys hidden in the stream,thus a second encryption is made,namely nagravision,viaccess,irdeto,etc. Now,in the case powervu use csa as primary encryption,if we get to decrpty the ecm to get the plain control words,we would be able to open the powervu cannels using dvb cards and other irds non powervu. This is the importance of knowing if powervu uses csa or not. If they don't,then the only resource is to use a powervu ird exclusively to get any video.(this mean the only way to get video,is to manipulate the ISE,same way you'd do with a DTV card) Now,if you have knowledge of the way the ird decrypt the ecm/emm,will save a lot of time if you post the code. I know some people will help dissasembling and understanding the rom/eeprom posted,but will take some time to get a hand on things yet. For me,is only worth if they use csa,not everybody will be able to glitch the chip and read and write to it,which would be the only mean to get video. Code: 82 CA table (emm) 3 09B packet lenght (the other packet lenght is 04B,see above) include CRC 10 tag 99 data lenght 01 010E00 ca id 0000068F data lenght (include only one byte of crc) other packet lenght is 3E,see above 0027E519 ird# (unique address) if this don't match the ISE,emm is not proccessed 00000380 encryption flag (80 mean is encrypted,00 unencrypted,there is a lot more about the bits in this byte) E490FF38CC828AA4777B00C6BA1C0EA469F2AD77B00C20554B 4680E4924E669658D5224B3D7 F8 D04E669658D5224B3D7F89E6DA20B80E491A9761930D2CF562 9261DF45CC718B98477629261 144 8BB5880E493FE7F176894228B3F3F9F2FE7F176894228B3F3F 93EEE93BC80E4955F844E62D4 606D 7F2651A1F844E62D4606D7F2651A3A91BD encrypted data F942CD41 CRC I know many people interested,just not posting in the thread, I actually know some others are taking a look at the dissa,but you can't ask to be done fast,most of people do not have a powervu ird.I had some irds some time back. Ok,this is the important part of the encryption,where things become a little cumbersome. Code: 0081303D3037200E00000000BA A0 this is the encryption flag 003DE2F955754282D2D3036027F856 The encryption flag (we can compare to key select byte to nagra 2) sets the way the ecm will be decrypted. We have here A0 If bit 7 of the first ecm byte is 0, then its not encrypted. If bit 6 of the first byte is 0 it will be send to the ISE (the default).If it is 1then it will be send to the OSE (the smatcard). Bit 5 = Use ROM/EEP key(0) / Use other key (1),which could come in the EMM. Bit 4 will set to use key from eeprom (1) or from rom (0). Bit 3 will set to use table 0 or table 1. Bit 4 will set to use key from eeprom (1) or from rom (0). So A0=10100000 ,mean Is encrypted,use the ISE,use EMM key(not the eeprom one),use key in eeprom (key buffer),use table 0. It makes it clear all providers using Ax as encryption flag,are using private keys that are not listed in the eeprom provided,so no way to decrypt any packet. The only way for this eeprom rutine to work,is when the encryption flag is 80 or 00 (unencrypted),which is not frecuent (I would say would never happen). This is only some research made by some people.