RSA Key extraction?

Lmao

On N3 no way

If They got old N2 card then mayb
But uk vm went N1 to N3 straight


yes on n3 you can use a card reader to get the cam_n from a n3 card without touching box. but there is a few thinks you will need.

1: dt08 response from card
2: ird from card
3: camid from card
4: and the most important part the 128 byte rsa key

used mostly on older boxes like pace
 
Those old pace boxs are like hens teeth

Even the sammy 2100c is pretty hard to find

Most are TiVo / Cisco
 
Search the cable forum

I made a tut for sammy 2100c

I have the BK and ird from it still from the old days of N2 cable, and I have *hit loads of software tuts programmers etc mate..... can the box still work with todays new system?
 
The ird is same

Bk for N3 is different
Also u need rsa too
 
I came across this while doing some surfing....

Kudelski N3 bits and pieces, plus thoughts on key / rsa extraction from flash.
N3 Notes mostly from forum posts by TheCoder

These are notes for future reference more than anything else, so please no excited emails about how its wrong, or right, or can I h*ck your box.


There are three different pairing methods used N3 boxes presently. These are DT06, DT08 and Secondary key.

The DT06 method transfers a compressed form of an rsa pq keyset from which the CAM public/private rsa keyset and its associated modulus can be derived.

The DT08 method transfers the cam modulus along with the IRD number of the married box. The public rsa key is not transferred but it is implied that the box already knows this value.

The Secondary key method does not involve a transfer. It imples that the box already knows the cards matching CAM modulus and rsa public key value.

Various boxes, depending on make/model, may use any of the above pre-pair key transfer methods but it could be useful to know which box uses which method.

Instructions:
1 Stick your N2/N3 card in your card reader
2 Run NagraEdit – DO NOT ATTEMPT TO READ YOUR CARD !!!
3 Select the Comm Tab. This should give you an upper and lower text pane
4 Cut/Paste the scriptt below into the top pane
5 Press the “Send D2C” button/icon
6 Results should appear in bottom pane
7 Interpret your results based on info below.
Script – Read DT06/DT08
Code:

rs
tx 21 C1 01 FE 1F
rx
tx 21 00 08 A0 CA 00 00 02 12 00 06 55
dl 02 00
rx
dl 02 00
tx 21 00 09 A0 CA 00 00 03 22 01 7E 00 1C
dl 02 00
rx
dl 02 00
mg *
mg *** DT06 info ***
tx 21 00 09 A0 CA 00 00 03 22 01 06 13 **
dl 02 00
rx
mg DT06 response1
dl 02 00
tx 21 40 09 A0 CA 00 00 03 22 01 86 13 **
dl 02 00
rx
dl 02 00
mg DT06 response2
mg *** End DT06 info ***
mg *
mg *** DT08 info ***
tx 21 40 09 A0 CA 00 00 03 22 01 08 13 **
dl 02 00
rx
mg DT08 response1
dl 02 00
tx 21 00 09 00 00 03 22 01 C8 A0 CA 55 **
dl 02 00
rx
dl 02 00
mg DT08 response2
tx 21 40 09 A0 CA 00 00 03 22 01 88 55 **
dl 02 00
rx
mg DT08 response3
dl 02 00
mg *** End DT08 info ***
*******
Just to clarify :
The important bits your looking at are the DT06/DT08 responses (the bits that start with Rx: )
ie RX: 12 00 15 A2 11 08 E0 00 00 00 5E 01 20 00 00 00
00 00 00 00 00 00 90 00 B3
RX: 12 40 15 A2 11 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 90 00 64
RX: 12 00 15 A2 11 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 90 00 24
and
RX: 12 40 57 A2 53 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 90 00 64

If the responses vary significantly from the above, with the 00's replaced with some varying data, then its likely your card had the specified tier and is probably using the corresponding pairing method.

If the DT06 response contains lots of 00's then its NOT DT06 pairing
If the DT08 response contains lots of 00's then its NOT DT08 pairing
If its not DT06 or DT08 then its probably secondary key.

For non DT08 cards (mostly the newer boxes) each box has a unique cam_n already built into its firmware – this can only be extracted from the actual box itself.

About the Algorithm,

N2 encrytion was based on the following algorithm ->
decrypted message = ( (IDEA( ( (EncryptedMsg ^ 3)Mod N1) ,IdeaKey) ) ^3) Mod N1
Thats 2 distinct algorithms. An RSA algorithm (performed twice) and an IDEA algorithm.
The key for the RSA algorithm is something like -
RSA EMM-G = 15A811B2065DF39CD48C9C958E7B406345295B09D0E9A18A 9B92C5FD7761CAAFAB830880F1F06B4E4477F157EA10D0AFC3 FDDB1ED2E7E83E89F03FF81237047DB76F79D6A2CFD75A7255 D72E52E7F47B96C2DFBDEBFC80CE927F6AD351FDF0BF8DA13F F62295BFBAF29035A230136D0B4AA99D38DD8B0465F2C709FC 8818173C
Which, as you can see, is a 128 byte (1024 bit) number. This is the main encryption key for EMM decryption.
The IDEA algorithm, which acts as an inner layer to the RSA has a standard 16 byte (128 bit) IDEA key.
There is no algorithm in N2 (or N3) that only uses an 8 byte (64 bit) key although some providers have opted to use 3DES rather than IDEA as an inner layer. This uses three separate 8 bye (64 bit – only 56 bits used) keys to form an amalgam 168 bit DES algorithm.

If Using DT08 (0a) on the card :
The Dt08 (0a datatype on card) is created by the provider and sent to the card at sub time.
The dt08 contains the Cam N public rsa key along with ird/boxkey.
The dt08 is IDEA encrypted with the Idea Key made from ird/boxkey/inverted ird.
The dt08 is RSA encrypted using Ird N (public rsa key) and Ird D (private key and uknown by anyone but provider).
Ird N = N1 xored N2
Ird N1 = A4E9B585932F90282FD70C908176E8605E6B2CE629335A0FC1 5B31DAB0BFC6FEEB88CFC69649994CD3FE039C9965C620C4D5 828E9153998EE4AE0E8C25644DF3 xor
Ird N1 = 237280AAB36BE4B21FC71FBF08218E532A545E744D7B007FF8 69BA426831C4AC653F3825ADE9358FCD1F0239EC447CBC2765 CC0AEBE437AF2270FC461C2FA042
Ird N = 879B352F2044749A3010132F89576633743F729264485A7039 328B98D88E02528EB7F7E33BA0ACC31EE101A57521BA9CE3B0 4E847AB7AE21C6DEF2CA394BEDB1
The Ird N1,N2,Ideakey exist in the tsop.
Ird E = 3
Ird D = UKNOWN, this is the reason you can’t create your own dt08 without changing the N1/N2 on the tsop, you must know Ird D.

DT08 (0A) = IdeaEncrypt(CamN/Ird#/Boxkey/Idea Signature,Ird_Ideakey) ^ D mod Ird N.

IRD requests DT08.
Card sends back the dt08 (0a)
Ird decrypts the dt08.
Decrypted dt08 = IdeaDecrypt(DT08,Ird_IdeaKey) ^ 3 mod Ird N.
It checks the ird # and boxkeys in the Decrypted 08 if they match what is on ird,
it stores the Cam N in the decrypted 08 in ird memmory.

If Using Secondary Key (SK) on the Ird.
Ird checks for SK exists on the ird, if it does, the dt08 will never be requested/ignored from the card.
Ird validates the SK with idea signature in the SK (using IIIIIIII01924314051647990A9C4E1 where I = irdnumber).
Ird takes the Cam N in the SK and puts it in ird memmory
Note : Cam N is not even encrypted in the sk, very weak method compared to dt08.

Later, establish session key (0C datatype on the card):
Ird requests 2a data from card.
Random 2a is sent from card to ird.
Ird performs some Idea signing (leave it to you to look up 2a/2b routines)
Ird comes up with session key from the 2a message sent from Cam.
Ird encrypts the session key with rsa.
Encrypted 2B = (2B data with 16 byte session idea key) ^ 3 mod Cam N.
Sends encrypted data back to card in 2b message.
Cam decrypts 2B with Cam N, Cam D. Decrypted 2B = (Encrypted 2B) ^ Cam D mod Cam N.
If valid, store session key in ram and on card for later use.

This all happens as ird boots.
When you select a channel.
Ird sends Cmd 07 ECM message with control words encrypted.
Cam decrypts the control words rencrypts them with Idea encryption using the session key established above.
The ird then requests the control words.
The Cam sends them back in the 1C response.
The ird decrypts the control words with with Idea encryption using the session key established above.
Sends the control words to the mpeg decoder.
8 seconds of video.
Repeat 07/1C process over and over.

——–

and pay special attention on CMD$2A ??

it should reply the CAMID serial number + 64 bytes random key generated and then shortly after encrypted with the CAM(AKA Conditional Access Module or SmartCard) RSA primary 96 bytes from the card… the so famous RSA modulus keys 96bytes at eeprom $8xxx on the ROM110 days.. From the card (this cmd is also the first step of the SessionKey negotiation)

shortly after the receiver receives this card reply.. and will decrypt it using the Secondary Key which is also 96bytes, this key is build up by using the following information stored in the receivers flash..

YES YES YES YES ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ 00 03 F1 F1
F1 F1 F1 F1 F1 F1 SK SK SK SK SK SK SK SK SK SK
EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN
EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN
EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN
SK SK SK SK SK SK F2 F2 F2 F2 F2 F2 F2 F2 CR CR

total 96 bytes..

IR = Receiver serial number
XX = Unimportant
EE = RSA public exponent for STB
F1 = SK signature 1 used to calculate the box key
F2 = SK signature 2 used to calculate the box key
SK = RSA public modulus N
CR = CRC Checksum
BB = BoxKey result from xoring F1 with F2 keys stored in the flash firmware from the receiver

once we decrypt the cmd2A we extract from inside the original 64byte random key generated in the card, then we will apply the IDEA encryption algo on the first 32bytes from the 64 byte random key to hash out the session key.

So this first 32 bytes are extracted from the 64byte random key and will be encryted using the IDEA SIGNATURE key… this key will be generated by the following information

IdeaKey generation
BB BB BB BB BB BB BB BB + CC CC CC CC + CA MI DC AM

BBBBBBBBBBBBBBBB = Boxkey resulting from F1 F2 XOR
CCCCCCCC = IRD number from receiver stored in Flash firmware
CA MI DC AM = CAM ID or Smart Card serial number converted in HEX, which can also be extracted by simply sending INS CMD$12 to the card..

so the IDEA signature key for encrypting the first 32bytes extracted from the 64 random seek key is

BBBBBBBBBBBBBBBBCCCCCAMIDCAM

once applied the IDEA encryption we will have the result 16 byte sessionkey.. which will be stored in the receiver flash for a few hours… to be more precise around 5 hours..

Now going back to the calculation done before, the receiver decrypted the cmd$2Aencrypted by the card with the RSA primary 96 stored in the card.
once decrypted it simply just extracted the first 32bytes of the 64 byte seed key generated by the card. this 32 bytes were used for calculation of the 16byte sessionkey..

but, before the 32byte keys was taken for the idea signature encryption.. the receiver.. re-encrypted the 64byte random key using the SECONDARY KEY RSA 96 stored in the receiver flash, which i just stated above how to get this key…
and will send it back to the card on cmd$2B

the card will receive the cmd$2b and will decrypt it using the PRIMARY RSA modulus key 96.
and will extract just the first 32bytes.. and by using the BOXKEY+IRD+CAMID stored in the card, the card will also calculate the same 16 byte session key.

in orde to make the card pairing , u need to know the RSA_N+BOXKEY+IRD NUMBER+CARD SERIAL number or CAMID…

then with them all together we can start comunication between the card.. and on the CMD$2A and $2B we will have the SessionKey negotiation which i just explained previously.

if for example on one side or the other we have different BKand RSA… we will a session key failure.. and without this Sessionkey we will not be able to decrypt the CM$1C or $9C related stuff

this means that if negotiation of session key succeds, then the receiver will send the ECM$07 to the card, which will then be decrypted by simply just using the ECM RSA modulus key and the ECM IdeaKey to decrypt the Control Words / CWs.

once they are decrypted the card will send them to the RECEIVER.. this is normally done via CMD$1C obviously this CMD is encrypted with the Sessionkey 16 BYTES described above.. once it arrives at the Receiver end, you will use the same Sessionkey 16byte to decrypt that CMD$1C and extract the REAL DCWs Decrypted Control Words to open up the Video and Audio stream related for that XX amount of seconds…

Now this Session key is refreshed every 5 hours.. this means that every 5 hours a new session key is produced.. so every 5 hours the card generates another 64byte random seed key using other RSA algo inside the card.., and will then send this 64 byte seed key to the receiver again.

Shortly followed by all the procedure described above to extract the new session key again.

—————-

Given that ==================================================
SK 96 BYTES
==================================================
11111111 <4 bytes ---------------------------- FIRST ---- IRD
XXXXXXXXXXXXXXXXXXXX <- NEXT 10 bytes ---- unknown
1111111111111111 <-------- 8 bytes Y1 ---- --- Wright DOWN
==================================================
11111111111111111111111111111111-_
11111111111111111111111111111111-_-_"N" 64 Bytes
11111111111111111111111111111111-_-
11111111111111111111111111111111-
==================================================
1111111111111111 <8 bytes ------- ----- --- Y2 Wright DOWN
XXXX<-------------------2 BYTES--- CHECKSUM
==================================================
Y2 Xor Y1 = BOXKEY
==================================================

006e convert from hex gives you 110 bytes block cipher

ird 4 bytes
bk 8 bytes
sk 96 bytes

leaving us with 02bytes used to encrypt, decrypt above.

eg:

6. 00 00 00 34 0D 20 03 03 1C 70 80 24 5a 8. Dede
E2 da ac cc a4 A6 86 91 29 18 23 0B A6 6d lighthouse c4
1b 20 97 05 7F ECB 0c 19 39 2F 1st B3 9b cb 67 4d
ed 10 f5 65 C7 35 0D ec ac F0 B8 b0 89 51 59 22
69 85 93 48 7a 84 D5 f1 b4 6th 1f 24 83 79 db 02
B0 8b 9c 4d 5e df 89 57 87 51 cc 9a 9c 5a 7F 3b
15 6b 15 cc c4 2f 4f 24 75 66 E7 E6 F2 07 85 0D
db b0 3d E2 E9 64 dd 54 77 60 e7 ad 8f A6 A6 Cd
46 C3 B8 lighthouse E4 6a 2F 2D 51 e7 95 68 56 78 34 B5
6b B8 48 38 87 95 17 c4 e5 b0 41 2c 95 24 E1 aa
4b 2a 8c 6F 90 53 29 B5 A9 6b 3d 0a 92 95 ec 1c
72 b9 54 a9 99 f5 f3 dd f4 0f 60 c3 25 5b 5b 81
E8 79 C5 22 89 2b 3c eBay 8f 8a ad below 27 c2 b0 F7
b1 D5 4f 08 37 2a 97 07 9D 99 F0 C5 C7 eBay 8a A9
cf 5a C5 45 25 43 81 95 7a thats 1st ed 22 33 93 74

Gives:

00 00 00 63 (length)

0D 20 03 03 70 80 1c 5a 8. dd (unknown)

24 a4 A6 E2 da ac cc 86 (Y1)

91 29 18 23 0B A6 6d lighthouse c4
1b 20 97 05 7F ECB 0c 19 39 2F 1st B3 9b cb 67 4d
ed 10 f5 65 C7 35 0D ec ac F0 B8 b0 89 51 59 22
69 85 93 48 7a 84 D5 f1 b4 6th 1f 24 83 79 db 02
B0 8b 9c 4d 5e df 89 (64 bytes)

57 9a 9c 5a 7F cc 87 51 (Y2)

Y2 = Y1 XOR xor 0x579c5a7f9acc8751 0x24accca4a6e2da86 = 42 12 8C 39 39 55 F2 FA

So, a flash dump would be helpful..

Possible Scenario's -
BGA, TSOP, TLGA etc .. desoldering for Flash.
Put in a socket. eg from
htxx: //shop37051047.taobao.com/ golds htxx: //shop34694309.taobao.com/? search = y

Pop flash back onto something else, read, dump. eg
htxx: //item.taobao.com/item.htm? id = 7422440993

Get box key, rsa key (if req. based on a check of DT type from the actual subbed card)
Pop flash back in socket.

Been there, done that for data recovery on faulty flash drives, plus most of the places I know down at QJlu have SMD / BGA desoldering capability or better.

Bunnies blog is fairly good at explaining the basics (albeit for xbox) – htxx://www.xenatera.com/bunnie/proj/anatak/xboxmod.html

Most boxes use ARM based SoC’s for things. Also possible to just throw up a dev board, and interface to that.

Although most boxes also have some form of OS running, so just as feasible to dump flash that way also assuming serial or jtag access and a bootloader is available.

Amusing that people like htxx://www.flashbackdata.com/blog/?p=195 claim this is hard – there are plenty of tools for this already out there eg softcenter, pc3000, plus all the local chinese stuff. Semi ok forum here talking about flash recovery, although not as technical as I’d like.

htxx: //forum.hddguru.com/hard-disk-d...forum-f12.html

Once key(s) are had, then I can use my own decoder rather than the crappy one the broadcaster uses.
 
@kid_warrior don't forget to credit original author.. :)

All the credit goes to TheCoder....for this and he knows what he is doing and talking about (not like me)

I just copied and paste to help people in the know, and people like myself to guide us through it
 
Last edited by a moderator:
I haven't looked at cable cs for ages - when I last thought about it there wasn't even a pay server around ! Can you pm me some of the sites you mentioned ?
 
so if it can be read for cable, why has no one tested a sky box? the chip is there to take out.
but again no public info on anyone to test or guide

And who's to say that the BGA chip on sly has not been dumped already (GL512P10FFCR1). Plus just for information the chip also has a hidden part that can't be dumped. But there's nothing stopping you riverrat or anyone else maybe you could also dump/glitch the cpu since most sly hd boxes are pre-2005 and might:p have a way in.

tr
 
i got two thomsons here not used for CS no more , ripped out the hard drives.

i dont have a clue now more about cable or dumps no more since i gave up telewest installs and sky and techwatch site i was on, i just stick to oscam and csp :)

well all the BIG sites i know and have read on say no one has and no one offers HD on sky CS.

just because it not on all these so called big cs sites don't mean it don't exist.
there's plenty of very smart people that don't visit these so called cs sites.

There is rumors of the nagra rom been dumped but you not see or hear of that on cs sites either.

plus the pictures you have posted or from a thompson box now everyone knows that nds/sly won't don't update them boxes to receive HD as they can easy be dumped you be better of dumping the DRX8xx

102_1750.JPG
 
just because it not on all these so called big cs sites don't mean it don't exist.
there's plenty of very smart people that don't visit these so called cs sites.

There is rumors of the nagra rom been dumped but you not see or hear of that on cs sites either.

plus the pictures you have posted or from a thompson box now everyone knows that nds/sly won't don't update them boxes to receive HD as they can easy be dumped you be better of dumping the DRX8xx

View attachment 88668

i have one for all the RSA people

(sorry not been here a while )

i heard you can use a xbox to connect to a cable box like UPC and read the keys in a few mins? any truth?
 
I came across this while doing some surfing....

Kudelski N3 bits and pieces, plus thoughts on key / rsa extraction from flash.
N3 Notes mostly from forum posts by TheCoder

These are notes for future reference more than anything else, so please no excited emails about how its wrong, or right, or can I h*ck your box.


There are three different pairing methods used N3 boxes presently. These are DT06, DT08 and Secondary key.

The DT06 method transfers a compressed form of an rsa pq keyset from which the CAM public/private rsa keyset and its associated modulus can be derived.

The DT08 method transfers the cam modulus along with the IRD number of the married box. The public rsa key is not transferred but it is implied that the box already knows this value.

The Secondary key method does not involve a transfer. It imples that the box already knows the cards matching CAM modulus and rsa public key value.

Various boxes, depending on make/model, may use any of the above pre-pair key transfer methods but it could be useful to know which box uses which method.

Instructions:
1 Stick your N2/N3 card in your card reader
2 Run NagraEdit – DO NOT ATTEMPT TO READ YOUR CARD !!!
3 Select the Comm Tab. This should give you an upper and lower text pane
4 Cut/Paste the scriptt below into the top pane
5 Press the “Send D2C” button/icon
6 Results should appear in bottom pane
7 Interpret your results based on info below.
Script – Read DT06/DT08
Code:

rs
tx 21 C1 01 FE 1F
rx
tx 21 00 08 A0 CA 00 00 02 12 00 06 55
dl 02 00
rx
dl 02 00
tx 21 00 09 A0 CA 00 00 03 22 01 7E 00 1C
dl 02 00
rx
dl 02 00
mg *
mg *** DT06 info ***
tx 21 00 09 A0 CA 00 00 03 22 01 06 13 **
dl 02 00
rx
mg DT06 response1
dl 02 00
tx 21 40 09 A0 CA 00 00 03 22 01 86 13 **
dl 02 00
rx
dl 02 00
mg DT06 response2
mg *** End DT06 info ***
mg *
mg *** DT08 info ***
tx 21 40 09 A0 CA 00 00 03 22 01 08 13 **
dl 02 00
rx
mg DT08 response1
dl 02 00
tx 21 00 09 00 00 03 22 01 C8 A0 CA 55 **
dl 02 00
rx
dl 02 00
mg DT08 response2
tx 21 40 09 A0 CA 00 00 03 22 01 88 55 **
dl 02 00
rx
mg DT08 response3
dl 02 00
mg *** End DT08 info ***
*******
Just to clarify :
The important bits your looking at are the DT06/DT08 responses (the bits that start with Rx: )
ie RX: 12 00 15 A2 11 08 E0 00 00 00 5E 01 20 00 00 00
00 00 00 00 00 00 90 00 B3
RX: 12 40 15 A2 11 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 90 00 64
RX: 12 00 15 A2 11 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 90 00 24
and
RX: 12 40 57 A2 53 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 90 00 64

If the responses vary significantly from the above, with the 00's replaced with some varying data, then its likely your card had the specified tier and is probably using the corresponding pairing method.

If the DT06 response contains lots of 00's then its NOT DT06 pairing
If the DT08 response contains lots of 00's then its NOT DT08 pairing
If its not DT06 or DT08 then its probably secondary key.

For non DT08 cards (mostly the newer boxes) each box has a unique cam_n already built into its firmware – this can only be extracted from the actual box itself.

About the Algorithm,

N2 encrytion was based on the following algorithm ->
decrypted message = ( (IDEA( ( (EncryptedMsg ^ 3)Mod N1) ,IdeaKey) ) ^3) Mod N1
Thats 2 distinct algorithms. An RSA algorithm (performed twice) and an IDEA algorithm.
The key for the RSA algorithm is something like -
RSA EMM-G = 15A811B2065DF39CD48C9C958E7B406345295B09D0E9A18A 9B92C5FD7761CAAFAB830880F1F06B4E4477F157EA10D0AFC3 FDDB1ED2E7E83E89F03FF81237047DB76F79D6A2CFD75A7255 D72E52E7F47B96C2DFBDEBFC80CE927F6AD351FDF0BF8DA13F F62295BFBAF29035A230136D0B4AA99D38DD8B0465F2C709FC 8818173C
Which, as you can see, is a 128 byte (1024 bit) number. This is the main encryption key for EMM decryption.
The IDEA algorithm, which acts as an inner layer to the RSA has a standard 16 byte (128 bit) IDEA key.
There is no algorithm in N2 (or N3) that only uses an 8 byte (64 bit) key although some providers have opted to use 3DES rather than IDEA as an inner layer. This uses three separate 8 bye (64 bit – only 56 bits used) keys to form an amalgam 168 bit DES algorithm.

If Using DT08 (0a) on the card :
The Dt08 (0a datatype on card) is created by the provider and sent to the card at sub time.
The dt08 contains the Cam N public rsa key along with ird/boxkey.
The dt08 is IDEA encrypted with the Idea Key made from ird/boxkey/inverted ird.
The dt08 is RSA encrypted using Ird N (public rsa key) and Ird D (private key and uknown by anyone but provider).
Ird N = N1 xored N2
Ird N1 = A4E9B585932F90282FD70C908176E8605E6B2CE629335A0FC1 5B31DAB0BFC6FEEB88CFC69649994CD3FE039C9965C620C4D5 828E9153998EE4AE0E8C25644DF3 xor
Ird N1 = 237280AAB36BE4B21FC71FBF08218E532A545E744D7B007FF8 69BA426831C4AC653F3825ADE9358FCD1F0239EC447CBC2765 CC0AEBE437AF2270FC461C2FA042
Ird N = 879B352F2044749A3010132F89576633743F729264485A7039 328B98D88E02528EB7F7E33BA0ACC31EE101A57521BA9CE3B0 4E847AB7AE21C6DEF2CA394BEDB1
The Ird N1,N2,Ideakey exist in the tsop.
Ird E = 3
Ird D = UKNOWN, this is the reason you can’t create your own dt08 without changing the N1/N2 on the tsop, you must know Ird D.

DT08 (0A) = IdeaEncrypt(CamN/Ird#/Boxkey/Idea Signature,Ird_Ideakey) ^ D mod Ird N.

IRD requests DT08.
Card sends back the dt08 (0a)
Ird decrypts the dt08.
Decrypted dt08 = IdeaDecrypt(DT08,Ird_IdeaKey) ^ 3 mod Ird N.
It checks the ird # and boxkeys in the Decrypted 08 if they match what is on ird,
it stores the Cam N in the decrypted 08 in ird memmory.

If Using Secondary Key (SK) on the Ird.
Ird checks for SK exists on the ird, if it does, the dt08 will never be requested/ignored from the card.
Ird validates the SK with idea signature in the SK (using IIIIIIII01924314051647990A9C4E1 where I = irdnumber).
Ird takes the Cam N in the SK and puts it in ird memmory
Note : Cam N is not even encrypted in the sk, very weak method compared to dt08.

Later, establish session key (0C datatype on the card):
Ird requests 2a data from card.
Random 2a is sent from card to ird.
Ird performs some Idea signing (leave it to you to look up 2a/2b routines)
Ird comes up with session key from the 2a message sent from Cam.
Ird encrypts the session key with rsa.
Encrypted 2B = (2B data with 16 byte session idea key) ^ 3 mod Cam N.
Sends encrypted data back to card in 2b message.
Cam decrypts 2B with Cam N, Cam D. Decrypted 2B = (Encrypted 2B) ^ Cam D mod Cam N.
If valid, store session key in ram and on card for later use.

This all happens as ird boots.
When you select a channel.
Ird sends Cmd 07 ECM message with control words encrypted.
Cam decrypts the control words rencrypts them with Idea encryption using the session key established above.
The ird then requests the control words.
The Cam sends them back in the 1C response.
The ird decrypts the control words with with Idea encryption using the session key established above.
Sends the control words to the mpeg decoder.
8 seconds of video.
Repeat 07/1C process over and over.

——–

and pay special attention on CMD$2A ??

it should reply the CAMID serial number + 64 bytes random key generated and then shortly after encrypted with the CAM(AKA Conditional Access Module or SmartCard) RSA primary 96 bytes from the card… the so famous RSA modulus keys 96bytes at eeprom $8xxx on the ROM110 days.. From the card (this cmd is also the first step of the SessionKey negotiation)

shortly after the receiver receives this card reply.. and will decrypt it using the Secondary Key which is also 96bytes, this key is build up by using the following information stored in the receivers flash..

YES YES YES YES ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ 00 03 F1 F1
F1 F1 F1 F1 F1 F1 SK SK SK SK SK SK SK SK SK SK
EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN
EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN
EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN EN
SK SK SK SK SK SK F2 F2 F2 F2 F2 F2 F2 F2 CR CR

total 96 bytes..

IR = Receiver serial number
XX = Unimportant
EE = RSA public exponent for STB
F1 = SK signature 1 used to calculate the box key
F2 = SK signature 2 used to calculate the box key
SK = RSA public modulus N
CR = CRC Checksum
BB = BoxKey result from xoring F1 with F2 keys stored in the flash firmware from the receiver

once we decrypt the cmd2A we extract from inside the original 64byte random key generated in the card, then we will apply the IDEA encryption algo on the first 32bytes from the 64 byte random key to hash out the session key.

So this first 32 bytes are extracted from the 64byte random key and will be encryted using the IDEA SIGNATURE key… this key will be generated by the following information

IdeaKey generation
BB BB BB BB BB BB BB BB + CC CC CC CC + CA MI DC AM

BBBBBBBBBBBBBBBB = Boxkey resulting from F1 F2 XOR
CCCCCCCC = IRD number from receiver stored in Flash firmware
CA MI DC AM = CAM ID or Smart Card serial number converted in HEX, which can also be extracted by simply sending INS CMD$12 to the card..

so the IDEA signature key for encrypting the first 32bytes extracted from the 64 random seek key is

BBBBBBBBBBBBBBBBCCCCCAMIDCAM

once applied the IDEA encryption we will have the result 16 byte sessionkey.. which will be stored in the receiver flash for a few hours… to be more precise around 5 hours..

Now going back to the calculation done before, the receiver decrypted the cmd$2Aencrypted by the card with the RSA primary 96 stored in the card.
once decrypted it simply just extracted the first 32bytes of the 64 byte seed key generated by the card. this 32 bytes were used for calculation of the 16byte sessionkey..

but, before the 32byte keys was taken for the idea signature encryption.. the receiver.. re-encrypted the 64byte random key using the SECONDARY KEY RSA 96 stored in the receiver flash, which i just stated above how to get this key…
and will send it back to the card on cmd$2B

the card will receive the cmd$2b and will decrypt it using the PRIMARY RSA modulus key 96.
and will extract just the first 32bytes.. and by using the BOXKEY+IRD+CAMID stored in the card, the card will also calculate the same 16 byte session key.

in orde to make the card pairing , u need to know the RSA_N+BOXKEY+IRD NUMBER+CARD SERIAL number or CAMID…

then with them all together we can start comunication between the card.. and on the CMD$2A and $2B we will have the SessionKey negotiation which i just explained previously.

if for example on one side or the other we have different BKand RSA… we will a session key failure.. and without this Sessionkey we will not be able to decrypt the CM$1C or $9C related stuff

this means that if negotiation of session key succeds, then the receiver will send the ECM$07 to the card, which will then be decrypted by simply just using the ECM RSA modulus key and the ECM IdeaKey to decrypt the Control Words / CWs.

once they are decrypted the card will send them to the RECEIVER.. this is normally done via CMD$1C obviously this CMD is encrypted with the Sessionkey 16 BYTES described above.. once it arrives at the Receiver end, you will use the same Sessionkey 16byte to decrypt that CMD$1C and extract the REAL DCWs Decrypted Control Words to open up the Video and Audio stream related for that XX amount of seconds…

Now this Session key is refreshed every 5 hours.. this means that every 5 hours a new session key is produced.. so every 5 hours the card generates another 64byte random seed key using other RSA algo inside the card.., and will then send this 64 byte seed key to the receiver again.

Shortly followed by all the procedure described above to extract the new session key again.

—————-

Given that ==================================================
SK 96 BYTES
==================================================
11111111 <4 bytes ---------------------------- FIRST ---- IRD
XXXXXXXXXXXXXXXXXXXX <- NEXT 10 bytes ---- unknown
1111111111111111 <-------- 8 bytes Y1 ---- --- Wright DOWN
==================================================
11111111111111111111111111111111-_
11111111111111111111111111111111-_-_"N" 64 Bytes
11111111111111111111111111111111-_-
11111111111111111111111111111111-
==================================================
1111111111111111 <8 bytes ------- ----- --- Y2 Wright DOWN
XXXX<-------------------2 BYTES--- CHECKSUM
==================================================
Y2 Xor Y1 = BOXKEY
==================================================

006e convert from hex gives you 110 bytes block cipher

ird 4 bytes
bk 8 bytes
sk 96 bytes

leaving us with 02bytes used to encrypt, decrypt above.

eg:

6. 00 00 00 34 0D 20 03 03 1C 70 80 24 5a 8. Dede
E2 da ac cc a4 A6 86 91 29 18 23 0B A6 6d lighthouse c4
1b 20 97 05 7F ECB 0c 19 39 2F 1st B3 9b cb 67 4d
ed 10 f5 65 C7 35 0D ec ac F0 B8 b0 89 51 59 22
69 85 93 48 7a 84 D5 f1 b4 6th 1f 24 83 79 db 02
B0 8b 9c 4d 5e df 89 57 87 51 cc 9a 9c 5a 7F 3b
15 6b 15 cc c4 2f 4f 24 75 66 E7 E6 F2 07 85 0D
db b0 3d E2 E9 64 dd 54 77 60 e7 ad 8f A6 A6 Cd
46 C3 B8 lighthouse E4 6a 2F 2D 51 e7 95 68 56 78 34 B5
6b B8 48 38 87 95 17 c4 e5 b0 41 2c 95 24 E1 aa
4b 2a 8c 6F 90 53 29 B5 A9 6b 3d 0a 92 95 ec 1c
72 b9 54 a9 99 f5 f3 dd f4 0f 60 c3 25 5b 5b 81
E8 79 C5 22 89 2b 3c eBay 8f 8a ad below 27 c2 b0 F7
b1 D5 4f 08 37 2a 97 07 9D 99 F0 C5 C7 eBay 8a A9
cf 5a C5 45 25 43 81 95 7a thats 1st ed 22 33 93 74

Gives:

00 00 00 63 (length)

0D 20 03 03 70 80 1c 5a 8. dd (unknown)

24 a4 A6 E2 da ac cc 86 (Y1)

91 29 18 23 0B A6 6d lighthouse c4
1b 20 97 05 7F ECB 0c 19 39 2F 1st B3 9b cb 67 4d
ed 10 f5 65 C7 35 0D ec ac F0 B8 b0 89 51 59 22
69 85 93 48 7a 84 D5 f1 b4 6th 1f 24 83 79 db 02
B0 8b 9c 4d 5e df 89 (64 bytes)

57 9a 9c 5a 7F cc 87 51 (Y2)

Y2 = Y1 XOR xor 0x579c5a7f9acc8751 0x24accca4a6e2da86 = 42 12 8C 39 39 55 F2 FA

So, a flash dump would be helpful..

Possible Scenario's -
BGA, TSOP, TLGA etc .. desoldering for Flash.
Put in a socket. eg from
htxx: //shop37051047.taobao.com/ golds htxx: //shop34694309.taobao.com/? search = y

Pop flash back onto something else, read, dump. eg
htxx: //item.taobao.com/item.htm? id = 7422440993

Get box key, rsa key (if req. based on a check of DT type from the actual subbed card)
Pop flash back in socket.

Been there, done that for data recovery on faulty flash drives, plus most of the places I know down at QJlu have SMD / BGA desoldering capability or better.

Bunnies blog is fairly good at explaining the basics (albeit for xbox) – htxx://www.xenatera.com/bunnie/proj/anatak/xboxmod.html

Most boxes use ARM based SoC’s for things. Also possible to just throw up a dev board, and interface to that.

Although most boxes also have some form of OS running, so just as feasible to dump flash that way also assuming serial or jtag access and a bootloader is available.

Amusing that people like htxx://www.flashbackdata.com/blog/?p=195 claim this is hard – there are plenty of tools for this already out there eg softcenter, pc3000, plus all the local chinese stuff. Semi ok forum here talking about flash recovery, although not as technical as I’d like.

htxx: //forum.hddguru.com/hard-disk-d...forum-f12.html

Once key(s) are had, then I can use my own decoder rather than the crappy one the broadcaster uses.


Works this similarly with NDS Videoguard (Sky germany, V14 card) ?
Or is it not possible?
 
Back
Top