RSA-512 Modulus for DT08: IRD comparison / Address Locations

[Nagraman]

BACKGROUND

It is now agreed that DT08 needs to be decrypted using an RSA-512 bit
modulus stored
in IRD firmware somewhere. Once RSA decrypted, we set aside the first 8
byte block as the signature, replace it with 00 00 00 00 + Cam # and
proceed to hash these bytes using IDEA (initial key = Boxkey + IRD# +
inv IRD#). The final hash should match the initial signature. If it
does, we can then process $2A to generate our unique session key.

OBSERVATIONS

Can we get a thread going on the TSOP address location of the RSA-512
bit modulus that we initially need to decrypt the DT08?

Provider: Dish, Bev, etc.
IRD Model:2700, 3100, 4700, 5100, etc.
TSOP address of RSA-512 key


Is this RSA-512 key unique for each IRD type and provider? Some receiver
models don't use DT08 at all...can we shed some light on that too.


Please post your results ONLY if you are absolutely sure about the
location of the RSA-512 bit modulus for your IRD type and know what the
DT08 is all about.

Nagraman

[egoboy]

I don't know what the DT08 is all about but it would seem to me that if you were looking for the location of the RSA 512 private key then couldn't you just set up a program to start pulling series of 128 hex digits out of the tsop and trying them as the RSA private key in whatever function you need to do it?

I don't understand the CEMU code once it gets to the point of responding to the stream commands or else I would try this idea myself. But since you claim to know that you need to decrypt the IDEA key using RSA-512 then you KNOW the length of the RSA private key you need to find in either the TSOP or the CAM. So can't you just step through them all trying each section of 128 hex digits as the key? Just display the starting location of the key on screen and if you happen to successfully decode the Nagra2 stream then you were right. You can speed up the process by eliminating possbile keys that have too many FF or 00 hex digits since there are obvious gaps in the TSOP code and those would most likely not contain valid RSA-512 private keys.

It's not like today's computers couldn't do this in a matter of days. Anyone have the knowledge to recode CEMU to do this type of operation?

egoboy :D

[egoboy]

Reading through the supposed Nagra 2 patent document, if this is correct, then it seems that the ECM keys should be stored on the card and not in the TSOP.

It says that there is 1 management zone created on the card by the provider that controls whether dynamic zones can be created or not, so basically it means that this zone can keep BEV from authorizing DISH subscribers to view channels and visa-versa.

Each provider can create multiple dynamic zones which contain ECM keys and each zone can be assigned a priority. The provider can send down a priority code so the card knows which keys to use to decode the ECM. So this means that based on a changing priority code then DISH can change up the private keys being used to decode the ECMs.

Also new ECM private keys can be sent down and stored on the card by the provider and assigned an obsolesence date so that they expire.

So this is what I gathered from reading the patent that was posted earlier in this forum. Is this really how DISH or BEV is running the system or does the patent just show what can be done if they want to? If that really is the patent and that really is how DISH or BEV is running things then you need to look for the private RSA-512 key to be stored on the card in the zone containing the matching priority code.

egoboy :D

[mylise]

When I change the key, nothing happens until I change channel. At this point screen goes blank. I then change the key back to its original value, after 3 seconds video starts.

It is 64 bytes long with a 16 byte table with numbers ranging from 00 to 0F in different position.

I have also found (1) 16+1 byte that changes every 30s or so and when modified in this 30s, a screen pop up saying that the not allowed to view channel and then goes away when code gets changed.

What sould we do to test validity of these keys.
Any programs out there or people with good math skills?

[egoboy]

mylise,

Can you give the IRD model and firmware version you are using as well as the starting point of this 64 byte key and the 16+1 byte key?

Then we can have someone else verify it.

egoboy :D

[mylise]

I am testing on 2700 bev E509

(public) key found at $401976AC 6410 B71D ..... 1CF2 BDBD
table is after 00 08 04 0C 02 0A 06 0E 01 09 05 0D 03 0B 07 0F

To find 16 + 1 byte key first see table at $40083620

you should see 30360840 00000000 043A1940 last data points where it is.

It seems sometimes to change location so verify. Most of the time is at $40193A04

Happy testing and keep us posted!!!

[Wiesh]

How are you doing this so we can all start trying it?

Thanks

[satanicnazi]

unless you have the proper algorithm to decrypt
you will only hear sound
you will only see till you can channel or timming cycles
since time....delay...channel
is a part of it...you are seeing the public keys on card and imbedded in epprom
key coming down changes with the timing to prevent
glitch - decode
so untill the decode table is sorted out
good luck
>:)
once roken we can dump cards 0 then the fun starts
full sub - dump card - desub block into a atmega

[mylise]

Get JTANGO from one of my previous post, this will give you real time access to memory of IRD.

These keys will NOT give you new channels to watch but it is the starting point to figure out the decryption algorithm.

It would be interesting for others to post if same data is seen at these locations
The 64 byte key should be the same for the same model and REV.

The 16+1 key to be the same should be recorded on the same channel at the same time so coordination will be important!!!!

[Wiesh]

Did a search on your posts and I couldn't find it . can you re post it please

[mylise]

Here it is.

[rush]

mylise can you give me a quick run down on how to use jtango l have a 2700 and 3100 l would lik to test.........

[mylise]

Attach is a proceedure to use JTANGO properly.

I would like for someone to help in figuring out part of $400A6DC table

table at $40A64DC
N2 *** structure : 1st byte = size of command, 2nd byte= command, rest= data for command ***

COMMAND 81
0D 81 E0 000000 0901 0000000000

COMMAND 84 (data for modem??)
09 84 C0 000000080000
58 84 FF C000 0009 0000 133644FD 00000003 00000000 B400 2000 0000 03130013 0000 0E 00000000000000000000000000000000000000000000 0A[18882923059FFFFFFFFF] 14[B0000000000000000000000000000FFFFFFFFFFF]

COMMAND 88 (private key??)
54 88 F0 000000 0801 08FF49 00 (***73bytes of data***)

COMMAND 86
0A 86 E0 000000 0801 2000

COMMAND 87
1A 87 FC 000000 0901 011337A8BE00000000000A00000087FFFFFF

COMMAND 85 (TIER list of card??)
20 85 FF 880000 0901 1100 1775 131 0A8BE 0277 0012DC000037A4A8BE 02DA FF00FF
20 85 FF 880000 0901 1100 177C 131 0A8BE 00D2 0012DC000037A4A8BE 01C9 FF00FF
20 85 FF 880000 0901 0100 17A0 131 0A8BE 1162 0012DC000037A4A8BE 1193 FF00FF
20 85 FF 880000 0901 0100 1778 131 0A8BE 0277 0012DC000037A4A8BE 028C FF00FF
20 85 FF 880000 0901 0100 17CE 131 0A8BE 13E2 0012DC000037A4A8BE 14B4 FF00FF
20 85 FF 880000 0901 1100 0C30 131 AA8BE 0460 0012DC000037A4A8BE 049C FF00FF
1E 85 FF 080000 0901 0100 17CF 131 0A8BE 1572 0012DC000037A4A8BE FF00FF
1E 85 FF 080000 0901 0100 17D0 131 0A8BE 1585 0012DC000037A4A8BE FF00FF
20 85 FF 880000 0901 0100 1716 131 AA8BE 108D 0012DC000037A4A8BE A000 FF00FF
20 85 FF 880000 0901 1100 177E 131 0A8BE 023A 0012DC000037A4A8BE 0276 FF00FF
20 85 FF 880000 0901 1100 1776 131 0A8BE 01EA 0012DC000037A4A8BE 021C FF00FF

COMMAND 80 (IRD information)
2C 80 FF 900000 0801 01ED101001 (***4bytes IRD foward***) (***8bytes of data***) A8BE10 (***4 bytes IRD reverse***) 31324242434F424145353039


DO you recognize any data structure?

[mylise]

Sorry for my big fingers.

The address block is $400A64DC, disregard all other variations above.

[dbDan]

mylise what you are looking at there is the data types loaded from cam into the ird's ram. you are correct on first byte being length but second byte represents the DT. rest of info looks good. there are guides/info out that will assist you in seeing what the DT's are and what the data is within them.

Here's a couple example though for you.

84 ;Data Type
FF ;
C0 ;
00 00 ;
09 ;System ID = Bell ExpressVU
00 00 ;
13 36 ;Next Regular Callback Date = Jun / 19 / 2005
44 FD ;Next Regular Callback Time = 9:48:42
00 00 ;Immediate Callback Date = Jan / 1 / 1992
00 03 ;Immediate Callback Time = 0:00:06
00 00 ;Last Callback Date = Jan / 1 / 1992
00 00 ;Last Callback Time = 0:00:00
B4 ;Callback Retry Period
00 ;IRD Status Byte
20 ;Length of Blackout String + 00's = 32
00 00 00 03 13 00 13 00 ;Blackout Bytes
00 0E 00 00 ;Last byte is local byte
00 00 00 00 ;--\
00 00 00 00 00 00 00 00 ;---\ Key 0 and Key 1 Possibly
00 00 00 00 00 00 00 00 ;---/ Hidden in This Area
0A ;Length of Callback Area = 10
18 88 29 23 05 ;Callback Phone Number
9F FF FF FF FF ;


1A ;Response Data Length = 26
87 ;Data Type
FC ;
00 ;
00 00 ;
09 01 ;System ID = Bell ExpressVU
01 ;IRD Status Byte
13 37 ;Expire Date = Jun / 20 / 2005
A8 BE ;Expire Time = 23:59:56
00 00 00 ;Credit in Cash = $00.00
00 00 0A 00 ;Debit in Cash = $10.00
00 ;
00 87 ;Phone Home Threshold
FF FF FF ;


20 ;Response Data Length = 32
85 ;Data Type
FF ;
88 ;Tier Type
00 00 ;
09 01 ;System ID = Bell ExpressVU
11 ;IRD Status Byte
00 17 75 ;Rights ID = 6005
13 10 ;Expire Date = May / 12 / 2005
A8 BE ;Expire Time = 23:59:56
02 77 ;Low Tier ID = 631
00 ;
12 DC ;Begin Date = Mar / 21 / 2005
00 00 ;Begin Time = 0:00:00
37 A4 ;Rights Date = Dec / 31 / 2030
A8 BE ;Rights Time = 23:59:56
02 DA ;High Tier ID = 730
FF ;Theme
00 FF ;Theme Extension