This is just for learning and fun,u know ,playing with power vu we can dance!
About Scientific Atlanta having a powerful coding as russia has!

Power Vu / Scientific Atlanta Info


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 there, in the USA models, they had the 20 pin SMD chip. Including parts lists of the parts in those 8600x boxes... Yes, from some informations, on the SA8600x boxes, they used a SC21 in the patents, but in the actual boxes, they used a SC24 chip.
It means that 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 it is said, is top secret! Having 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 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... ubernommen ?

Meaning that 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).
It uses a modded T911 glitcher w/ modded newd13 .hex+.XVB script.
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) here is the code sending (in)to 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). (2) means algorithm 2 is used. Ok,at least we know where this come from.nice. Adding some more info about ECM packets.(not from this service ,though,but It seems they are NOT 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?)

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.
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.
There are things known,as you see,problem is there are no keys available.
No DES inside of the powervu chip. 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.
Confusing the DVB part of the decoder itself,algorithm is not know by anybody until now(a little part of it).

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. There're two different algoriymths. seen algorithm 2 and 3 and all share same key at 10A4 but crypto changes.
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. Having 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, maybe 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.

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 does 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.
But now those 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.
I'm sure you could post the files at cardcoders for analysys.
What are you using to log the PIDs(missing something to me?)? 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 means the only way to get video,is to manipulate the ISE,same way you'd do with a DTV card)
It 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

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,maybe) sets the way the ecm will be decrypted. Here's:

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...

+++ to be continued +++