- a german research group working on irdeto2 decrypt system and they
publish they results till now they expect to hack this system after
one month :
the result translated from german to english:
INTRODUCTION
=============
[Translation by Micheling]
NUMBER OF PROVIDERS
---------------------------
It seems they are 4 instead of 2 (00, 10, 20, 30)
At start, we should have request (through the GET command) of ProvID
for 20 and 30 as well.
// Get ProviderID 00
01 02 03 03 00 00
// Get ProviderID 10
01 02 03 03 01 00
// Get ProviderID 20 **** expected
01 02 03 03 02 00
// Get ProviderID 30 **** expected
01 02 03 03 03 00
Question: how CAM knows that ProvID must be asked 4 times instead of
2 (as in Irdeto1)?
Probable answer: because in the answer to a certain previous get
command the smart card (SC) has passed this information to the CAM
If so, looking at a log, we should identify such parameter
Let's look at the initial exchange of information between CAM and SC
in Irdeto1:
1)Request : Cards ASCII Serial Number [from CAM to SmartCard ]
01 02 00 03 00 00 3F
Answer : Cards ASCII Serial Number [from SmartCard to CAM ]
01 02 00 00 00 03 00 14
3X 3X 3X 3X 3X 3X 3X 3X 3X 3X 43 36 34 32 30 33
41 20 20 20 30
2)Request: Cards HEX Serial Number [from CAM to SmartCard ]
01 02 01 03 00 00 3E
Answer : Cards HEX Serial Number [from SmartCard to CAM ]
01 02 00 00 01 03 00 10
00 17 00 00 01 00 17 00 00 01 02 00 SN SN SN 18
cb
At this point CAM asks for ProvIDs:
Request : Provider ID 00 SMART CARD [from CAM to SmartCard ]
01 02 03 03 00 00 3C
Answer : Cards Provider ID 00 [from SmartCard to CAM ]
01 02 00 00 03 03 00 18
00 p0 p0 p0 00 00 00 00 00 00 03 12 00 00 00 00
00 00 00 00 00 00 00 00 36
Request: Cards Provider ID 10 [from CAM to SmartCard ]
01 02 03 03 01 00 3D
Answer: Cards Provider ID 10 [from SmartCard to CAM ]
01 02 00 00 03 03 01 18
11 p1 p1 p1 00 00 00 00 00 00 03 18 00 00 00 00
00 00 00 00 00 00 00 00 cb
The number of providers could be contained in one of the two byte
included in the answer to request 2. The hypotesis has to be
confirmed.
In fact, it could be the first byte put to 03 that would specify 4
providers (00, 01, 02, 03), or the second byte put to 4 to indicate 4
providers.
COCO
-------
S*T uses 06 04 as Zee
The COCO S*T uses 06 04 like Zee
SIGNATURE
-------------
It is composed by 8 bytes instead of 5 as for Ir**to1.
Remembering that in Ir**to1 8 byte of signature were calculated, but
only 5 were used, this new development should not be significant. We
could assume a calculation similar to Ir**to1 with the utilisation of
all the 8 bytes.
BLOCK DATA
---------------
- Comandi di classe 5:
01 05 INS P1 P2 L1 CH ID KK 00 L2..
L1 : lenght L1 =L2+6
L2 : tenuto conto che in Ir**to1 ? normalmente 1Dh, si dovrebbe avere
minimo 20h
It seems that they are always blocks of 8 bytes. That is, for any
nanocommand sent and for any number of nanos sent, the sum of the
sent byte is always multiple of 8.
It is obvious that will be some bytes filling in order to arrive to
multiples of 8.
The logic of filling could be the same as of Ir**to1 for the
signature.
Since also the signature is 8 bytes, L2 (lenght 2) is multiple of 8
and its hexadecimal will be x0 or x8.
Therefore we will always have:
Commands of class 1: 01 01 INS P1 P2 L1 C3 xx xx xx 00 L2..
L1: length L1 = L2+6
L2: from a minimum of 8 (data) +8 (sign.)=16=10h, and then with
values 18h, 20h, 28h.
Commands of class 2: for compatibility with Irdeto1 they are the
same. Indeed they do not have signature and therefore they will not
be crypted.
Commands of class 5: 01 05 INS P1 P2 L1 CH ID KK 00 L2..
L1: length L1 = L2+6
L2: taken into account that in Ir**to1 is normally 1Dh, at minimum it
must be 20h
ALGO
------
It seems that cards 2.1 use a kind of Suprencription, that is the
instruction is not launched in the clear, but it is sent crypted with
a key.
In order to maintain compatibility with the previous Irdeto CAM, we
have some restrictions with the new cards:
a) the Irdeto commands have the known structure: 01 cla Ins p1 p2 LL -
block given-signature-checksum
b) for compatibility the first 6 bytes will be always in the clear
and they will not have superencription for sure
c) from some published Log on the web it seems that also the
following bytes that specify whether the commando is directed to the
Shx or the provider or to the ProvGroup are not encrypted. Ergo: -
Class 1 directed to the Shex:
01 01 00 00 00 LL1 C3 xx xx xx 00 LL2 KK KK KK..
< -... in the clear < -. criptati...
Class 1 directed to Provid00: 01 01 00 00 00 LL1 03 PP PP PP 00 LL2
KK KK KK..
Class 1 directed to Provid10: 01 01 00 00 00 LL1 0B PP PP PP 00 LL2
KK KK KK..
Commands sent to providers of the same Provgroup have equal blocks,
that means that the encription key is the same one for the same group
Let now think to a possible general system:
>From the theory of great Max we have learned:
- commands directed to Shex are signed with the HMK
- commands directed to ProvId or to ProvGroup are signed with the PMK
- management commands (Class 5) comes signed with the Pkey
If so, the simpler thing to assume is that Ir**to2 works in this way:
- commands directed to the Shx comes encrypted with the HMK
- commands directed to the Prov comes encrypted with the PMK
- commands of class 5 comes encrypted with the PK.
Before proceeding, lets talk of the signature. There are two cases:
a) signature is calculated on the encrypted data block
b) that is the data block is taken in blocks of 8 and is encrypted,
the bytes missing to 8 are completed with filling bytes. At this
point, signature is calculated on the block of crypted ottets and is
added
c) the signature is calculated on the unencrypted command, the data
block is encrypted as before. The overall command comes from the
union of the two strings.
If I had programmed the SW, would have done as in bullett a).
In any case we can assume that the data block is encrypted with the
keys above mentioned.
Knowing the PMK and the PK of a card, we can then proceeded in this
way:
a) to log a command of class 01 directed to the Provgroup (for
example: update of keys)
b) to decrypt the data block considering blocks of 8 byte each
c) to see if an instruction ir**to1 (nano, ll...) comes out.
CLASS 1
---------
SEND OF MASTERKEY
IRDETO1:
For Provider 00:
01 01 00 00 00 1A C3 ss ss ss 00 14 28 0D 00 00 mm mm mm mm mm mm mm
mm pp pp pp xx xx xx xx xx
For Provider 10:
01 01 00 00 00 1A C3 ss ss ss 00 14 28 0D 11 00 mm mm mm mm mm mm mm
mm pp pp pp xx xx xx xx xx
Let's try to transfer it to Irdeto2:
01 01 00 00 00 26 c3 ss ss ss 00 20 <1° block 8bytes encrypted> <2°
block 8bytes encrypted> <3° block 4 bytes data +4 fillings>
Therefore we have 4 blocksx8bytes=32bytes=20h (L2)
L1=26
L2=20
SEND OF KEYS
Send of 1 key
Data Block = 4 (data)+11 (key)= 15 bytes
Blocks= 1 whole block + 1 with fillings= 2 blocks
Signature= 1 block
Total: 3 blocks=24 bytes= 18h
L1= 1E
L2= 18
Send of 2 KEYS
; 01 01 00 00 00 first part of command
; 23 overall lenght
; 02 04 6E 00 00 addressed to the provider group
; 1D residual lenght (1Dh=29 decimal)
; 40 02 04 D0 nano date and date value
; 50 nano key reception
; 52 2 KEYS (18 bytes-> 12H+(2key-1)*40H= 52H)
; 0A 58 4C 8C CF 2E C6 43 91 N° key + KEY (KEY 0A)
; 0C 11 BD 74 3F F7 80 1D BD N° key + KEY (KEY 0C)
; [B4 FD C3 87 75] Signature
; 50 Checksum
Therefore data block: 18h byte =24 byte = 3 blocks to be encrypted
without fillings
Signature= 8 byte
Total : 20h byte
L1= 2E
L2= 20
Send of 3 KEYS
Data Block = 4(data)+29=33 bytes
4 whole blocks + 1 with fillings= 5 blocks= 40 bytes
Signature= 8 bytes
Total: 48 bytes
L1= 36
L2= 30
Send of di N° 4 KEYs with a unique command
; 01 01 00 00 00 first part of command
; 35 overall lenght
; 02 04 6E 00 00 addressed to the provider group
; 2F residual lenght 2Fh=47= 42+5
; 40 02 04 D0 nano date e date value
; 50 nano key reception
; E4 4 keys (36 Bytes-> 24H+(4keys-1)*40H=E4H)
; 0A 58 4C 8C CF 2E C6 43 91 N° key + KEY ( KEY 0A) 00-08 bytes
; 0C 11 BD 74 3F F7 80 1D BD N° key + KEY ( KEY 0C) 09-11
; 0E 87 51 77 75 5D 4B 9F 10 N° key + KEY ( KEY 0E) 12-1A
; 10 92 C7 E1 27 9A E1 79 DE N° key + KEY ( KEY 10) 1B-23
; [B4 FD C3 87 75] Signature
; 50 Chksum
Data Block: 42bytes, Blocks= 5 whole blocks + 1 with fillings =
6blocks
Signature: 8 byte
Total : 38 byte
L1= 3E
L2= 38
CLASS 5
01 02 00 00 02
23 L1
CH ID PP KK 00
1D L2
40 02 DD DD 4 bytes
78 12 . 2+12=14h dati=20bytes
Total data = 24 byte 3 blocks
Signature 1 block
Total: 4 blocks
For Ird**o2 we have:
L1= 26
L2= 20
Here I must stop, more I cannot say without a log.
-
-
ياليت أحد يترجم للعربية ولو بشكل مختصر من أجل أن نأخذ فكرة عن الموضوع ..شكراً للجميع .[flash]http://www.angelfire.com/tv2/samei/images/etha_da3tka_1.swf[/flash] -
الكلام شفناه من شهر بس اخينا صاحب الموضوع لما سالوه الشباب من وين جبته طوحبهم يمين ويسار
بس انا اقلكم جربو اللوج حق ايردوتو 2 وترا المفاتيح فيه جاهزة للارتي والشوتايم والنوفا
بس ابي واحد يجرب ويعطيني خبر صار لي اسبوع وانا ادور لي في الاسواق على نوكيا 9600
وهذا اللنك للي يحب يجرب اللوجر ايردوت 2
مع تحياتي العطرةتعليق
-
ياليت بالعربي
أخواني الأفاضل
تحية طيبه
اخوكم ثقافته روسيه ياليت تكتبون بالعربي ترى إحنا عرب وش لنا بالإنجليزيه0
لكم الشكرإعذريني ترى ماعاد تجدي الحلول...نافذ الصبر لو سلّم سلاحه شجاعتعليق
-
السلام عليكم ورحمة الله وبركاته
________________________
بعد المحبه والسلام00
... -
يمكن ان يعمل بعض قنوات ال ت ب س اذا وضعت ال
i d 00780
Hello guys,...
TPS from JHD
New id: 02260020-11-2004, 11:44 AM -
يمكن ان يعمل بعض قنوات ال ت ب س اذا وضعت ال
i d 00780
Hello guys,...
TPS from JHD
New id: 02260020-11-2004, 08:20 AM -
اصنع توقعيك بنفسك في دقائق مع Signature Maker V2
...
اسم البرنامج
Signature Maker V2
نبدة عن البرنامج -
هذا مانشرته الاخت الغرام
بسم الله الرحمن الرحيم
أعزائي كما وعدتكم دائما...
تعليق