Register

Welcome to the RDI-Board Community.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed.


Donate Now Goal amount for this month: 100 EUR, Received: 100 EUR (100%)
Donate to support this site...

Results 1 to 4 of 4

Thread: 1501-MECM ??

  1. #1
    asdaf
    Guest
    RDI - Board Default Avatar

    Default 1501-MECM ??

    Intrebare puerila poate..

    Asadar, am gasit key bune ( cica ) pentru PREMIERE..
    Dar.. am inteles ca mai trebuie ceva ..

    Si ma intrebam ce sunt MECM-urile astea ? Doar alte secvente de biti , care-mi lipsesc sau sunt gresite.. Sau, ceva dll-uri ?

    Ma rog, sunt in ceata..

    Merci mult pentru orice lamuriri, link-uri.. MECM-uri )

  2. #2
    Junior Member Junior
    RDI - Board Default Avatar

    Join Date
    Jul 2006
    Posts
    6
    Posts Thanks / Likes

    Default

    Sal,

    MECM, din cate-mi aduc aminte dintr-un nfo de nagra2, este o extensie a algoritmului de baza. De principiu se mai face o xorare inainte de a avea DCW1 si DCW2-ul cu o secventa aflata parca in cip (in succesiunea de comenzi intre receiver si card). Eu chiar sper sa-i dea repede de cap (in specificatiile - neoficiale - de nagra2, era descris de o gramada de vreme MECM-ul, si daca e decat un xor, ....).
    Si pe mine ma macina faptul ca nici vplug-ul si nici S2emu nu reusesc, si mai frustrant este ca avem keye buna si tine mult mai mult ca in alte parti.

  3. #3
    asdaf
    Guest
    RDI - Board Default Avatar

    Default :)

    Standard and D+ MECM made simple (I hope) with an example
    Lets assume that, at a given moment, this stream is recieved via ECM PID
    00 81 70 7D 80 7B 41 01 33 31 80 DF DB E3 9D DA E9 04 02 74 CF CE 76 E5 0F 42 BC DA 31 83 39 56 9E D5 F5 AE 29 E0 56 76 E1 A4 2D 9B 0C A0 A3 E0 77 C5 FE E0 D9 C5 13 56 9F 64 07 39 44 40 01 42 70 DF C0 4E CF 22 F5 DC BA 65 C9 27 AA C2 85 4E 8B 69 7F 80 4B C0 D1 F4 EE B5 B5 AA AE 2B 5B 84 2D C8 B8 E2 18 65 D7 21 FE AB C3 EB 69 4C 72 6A D6 C2 BA 23 9F 67 A7 AA 7E 38 AC 85 DB 45 9C 08 46


    This ECM is "poisoned" with MECM... so, instead of just sending CMD$03, the IRD will send a CMD$02 first.

    CMD$02
    21 00 53 A0 CA 00 00 4D 02 4B 40 01 42 00 00 00 00 00 00 00 00 DF C0 4E CF 22 F5 DC BA 65 C9 27 AA C2 85 4E 8B 69 7F 80 4B C0 D1 F4 EE B5 B5 AA AE 2B 5B 84 2D C8 B8 E2 18 65 D7 21 FE AB C3 EB 69 4C 72 6A D6 C2 BA 23 9F 67 A7 AA 7E 38 AC 85 DB 45 9C 08 46

    CMD$03
    21 00 3D A0 CA 00 00 37 03 35 41 01 10 31 05 DF DB E3 9D DA E9 04 02 74 CF CE 76 E5 0F 42 BC DA 31 83 39 56 9E D5 F5 AE 29 E0 56 76 E1 A4 2D 9B 0C A0 A3 E0 77 C5 FE E0 D9 C5 13 56 9F 64 07


    As you may see, both commands are simply a "rehusking" of the information recieved.

    Smartcard will decrypt CMD$02 with the RSA keys presend @ datatype7->0. The relevant info it provides is that a certain virtual internal buffer of 256 bytes should be loaded with "A51EF9793DB16977F4B44AE8868D8B4E" at offset 0xE0.

    CMD$03, instead, is decrypted with the operational keys, in this case, K0. The information it provides is:
    CW1 = CBBBBF6C31A64790
    CW2 = F54356FD3369F3A8
    ... BUT, it also says that CW1 should be XORed with that internal virtual buffer @ position 0xE4 and CW2 with position 0xE2.

    Thus, finally:
    CW1 = CBBBBF6C31A64790 XOR 3DB16977F4B44AE8 = F60AD61BC5120D78
    CW2 = F54356FD3369F3A8 XOR F9793DB16977F4B4 = C3A6B4C5A1E071C





    ---------------------------------------------------------------------------
    -----

    What about D+ Is it that different... oh yes

    ---------------------------------------------------------------------------
    -----


    From the previous example, the CMD$02 decrypted to:
    70 ADDRESS (/2)
    A51EF9793DB16977 MECM DATA
    F4B44AE8868D8B4E MECM DATA
    0000000066E5F03D (PADING)
    99D3DDAA1BB054EB (PADING)
    3C48E7ED25A0DC7F (PADING)
    E3B47EE5CDD97C37 (PADING)
    AE0BC41B (PADING)

    As I said, the important part was by the label of MECM DATA. For D+ forguet it... it's just ignored

    The important part is the PADDING data wich used to be just rubish.
    Lets break the padding data in 2:
    66E5F03D99D3DDAA1BB054EB3C48E7
    ED25A0DC7FE3B47EE5CDD97C37AE0BC41B

    Now, let's pretend the 1st halve is a PK and let's calculate the N1:
    F942100552EF9EA20F9BF2DBE611291A8845D419474F3B4DEF 6207C3F72B66D7CFD4D2B6DC4
    DC678E29F5A89F966FBFC8F6FFD01CB7B654CFE06DC926F9BE 1B4

    Now, let's assume an exponent of "3" and a a base of stupid:
    000102030405060708090a0b0c0d0e0f101112131415161718 191a1b1c1d1e1f20212223242
    5262728292a2b2c2d2e2f303132333435363738393a3b3c3d3 e3f

    ... you gessed it... follows an expomod...

    9D71405C34304BC2D6583E64E3E7F770D3564B65E454B086A6 943E233787C245188013E3151
    9FB760F1D5BAFE79C9863CD630EBA40B93163827F6E34BACC2 773

    Now, the last step, let's XOR the second halve of the PADDING with the first bytes of this last result

    ED25A0DC7FE3B47EE5CDD97C37AE0BC41B XOR 9D71405C34304BC2D6583E64E3E7F770D3 =
    7054E0804BD3FFBC3395E718D449FCB4C8

    ... and here we have the final MECM data (uffff)
    70 (ADDR)
    54E0804BD3FFBC3395E718D449FCB4C8 (MECM DATA)

    which, as you might recall, equates to "put that in 0xE0".

  4. #4
    Safe User Expert
    Join Date
    May 2005
    Posts
    2,956
    Posts Thanks / Likes

    Default Re: :)

    Quote Originally Posted by asdaf
    Standard and D+ MECM made simple (I hope) with an example
    Lets assume that, at a given moment, this stream is recieved via ECM PID
    00 81 70 7D 80 7B 41 01 33 31 80 DF DB E3 9D DA E9 04 02 74 CF CE 76 E5 0F 42 BC DA 31 83 39 56 9E D5 F5 AE 29 E0 56 76 E1 A4 2D 9B 0C A0 A3 E0 77 C5 FE E0 D9 C5 13 56 9F 64 07 39 44 40 01 42 70 DF C0 4E CF 22 F5 DC BA 65 C9 27 AA C2 85 4E 8B 69 7F 80 4B C0 D1 F4 EE B5 B5 AA AE 2B 5B 84 2D C8 B8 E2 18 65 D7 21 FE AB C3 EB 69 4C 72 6A D6 C2 BA 23 9F 67 A7 AA 7E 38 AC 85 DB 45 9C 08 46


    This ECM is "poisoned" with MECM... so, instead of just sending CMD$03, the IRD will send a CMD$02 first.

    CMD$02
    21 00 53 A0 CA 00 00 4D 02 4B 40 01 42 00 00 00 00 00 00 00 00 DF C0 4E CF 22 F5 DC BA 65 C9 27 AA C2 85 4E 8B 69 7F 80 4B C0 D1 F4 EE B5 B5 AA AE 2B 5B 84 2D C8 B8 E2 18 65 D7 21 FE AB C3 EB 69 4C 72 6A D6 C2 BA 23 9F 67 A7 AA 7E 38 AC 85 DB 45 9C 08 46

    CMD$03
    21 00 3D A0 CA 00 00 37 03 35 41 01 10 31 05 DF DB E3 9D DA E9 04 02 74 CF CE 76 E5 0F 42 BC DA 31 83 39 56 9E D5 F5 AE 29 E0 56 76 E1 A4 2D 9B 0C A0 A3 E0 77 C5 FE E0 D9 C5 13 56 9F 64 07


    As you may see, both commands are simply a "rehusking" of the information recieved.

    Smartcard will decrypt CMD$02 with the RSA keys presend @ datatype7->0. The relevant info it provides is that a certain virtual internal buffer of 256 bytes should be loaded with "A51EF9793DB16977F4B44AE8868D8B4E" at offset 0xE0.

    CMD$03, instead, is decrypted with the operational keys, in this case, K0. The information it provides is:
    CW1 = CBBBBF6C31A64790
    CW2 = F54356FD3369F3A8
    ... BUT, it also says that CW1 should be XORed with that internal virtual buffer @ position 0xE4 and CW2 with position 0xE2.

    Thus, finally:
    CW1 = CBBBBF6C31A64790 XOR 3DB16977F4B44AE8 = F60AD61BC5120D78
    CW2 = F54356FD3369F3A8 XOR F9793DB16977F4B4 = C3A6B4C5A1E071C





    ---------------------------------------------------------------------------
    -----

    What about D+ Is it that different... oh yes

    ---------------------------------------------------------------------------
    -----


    From the previous example, the CMD$02 decrypted to:
    70 ADDRESS (/2)
    A51EF9793DB16977 MECM DATA
    F4B44AE8868D8B4E MECM DATA
    0000000066E5F03D (PADING)
    99D3DDAA1BB054EB (PADING)
    3C48E7ED25A0DC7F (PADING)
    E3B47EE5CDD97C37 (PADING)
    AE0BC41B (PADING)

    As I said, the important part was by the label of MECM DATA. For D+ forguet it... it's just ignored

    The important part is the PADDING data wich used to be just rubish.
    Lets break the padding data in 2:
    66E5F03D99D3DDAA1BB054EB3C48E7
    ED25A0DC7FE3B47EE5CDD97C37AE0BC41B

    Now, let's pretend the 1st halve is a PK and let's calculate the N1:
    F942100552EF9EA20F9BF2DBE611291A8845D419474F3B4DEF 6207C3F72B66D7CFD4D2B6DC4
    DC678E29F5A89F966FBFC8F6FFD01CB7B654CFE06DC926F9BE 1B4

    Now, let's assume an exponent of "3" and a a base of stupid:
    000102030405060708090a0b0c0d0e0f101112131415161718 191a1b1c1d1e1f20212223242
    5262728292a2b2c2d2e2f303132333435363738393a3b3c3d3 e3f

    ... you gessed it... follows an expomod...

    9D71405C34304BC2D6583E64E3E7F770D3564B65E454B086A6 943E233787C245188013E3151
    9FB760F1D5BAFE79C9863CD630EBA40B93163827F6E34BACC2 773

    Now, the last step, let's XOR the second halve of the PADDING with the first bytes of this last result

    ED25A0DC7FE3B47EE5CDD97C37AE0BC41B XOR 9D71405C34304BC2D6583E64E3E7F770D3 =
    7054E0804BD3FFBC3395E718D449FCB4C8

    ... and here we have the final MECM data (uffff)
    70 (ADDR)
    54E0804BD3FFBC3395E718D449FCB4C8 (MECM DATA)

    which, as you might recall, equates to "put that in 0xE0".
    Pai asta e procedura simplificata de decodare a nagra 2 si nu are nimic de-a face cu faptul acele chei pt pr*mi*re nu merg.Cei de la kudelski de cand au intreprins atacuri antipiratare prin revizii AC si alte smecherii nu s-au atins de algorithul de decodare al CW-ului.Contramasurile lor se rezuma la folosirea unei noi secvente de Internal OS Protection care "amesteca" continutul memoriilor cartelei pt a nu mai raspunde comenzilor deja cunoscute si protejarea keylor operationale.

 

 

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Key: 00, key OK but Wrong MECM key COBO DOWN ???
    By andreisky in forum Placi DVB
    Replies: 1
    Last Post: 9th November 2005, 00:03
  2. Replies: 25
    Last Post: 15th October 2005, 02:23

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Back to Top