De Seca faq? Bedoel jij dit:
(ok? het is gejat van een ander board! )
Met veel plezier is hier dan de lang verwachtte seca2 FAQ:
(Vanwege het vertaalwerk zal deze in gedeeltes geplaatst worden).
Seca2 FAQ
Nader kennis met de ECM/EMM
Als eerste zou ik aan willen geven dat voor het begrijpen van deze FAQ,
allereerst kennis van zaken moet hebben betreffende het seca systeem met behulp van Seca FAQ. Alles wat hier vermeld wordt is uitsluitend bedoeld voor het onderzoek en studie van seca2.
Nieuw in het seca2 systeem
Aan de hand van een log van een ECM is het mogelijk om het eerste karakter-
eigenschap van het nieuwe systeem te realiseren:
C1 3C 01 BE 5C
10 01 CD 99 F1 E7 88 F1 E9 00 50 F9 09 5B 02 43
DD 03 35 39 1B C2 41 97 AF B3 8A A7 F7 9A FA 78
12 C9 BA 23 16 42 99 0E 9A F3 31 72 22 BC B8 C6
62 45 37 F9 7F 68 15 7C BB 7C A7 F2 3D F8 27 82
52 49 54 56 98 0C AB 94 26 95 74 A7 12 B6 83 4D
23 46 03 F1 E1 A5 66 31 05 96 46 48 [90 00]
Bij wijziging van alle bytes, behalve de rode, tussen twee verschillende ECM's, is enig nanocommando onbekend en is er geen spoor van de 'signature' te bekennen: de reden hiervoor is het simpele feit dat de data encrypted is.
Men weet nu dat er bij seca2, twee paren van ecryptie aanwezig zijn:
de SUPERENCRYPTIE (werkt met blokken van bytes) en de SECUNDAIRE SUPERENCRYPTIE (SSE of Envelope), die handelt de data die zijn geintegreerd.
Deze processen van encryptie zijn verplicht voor de data van de ins. 3C/38/40.
Het gebruikte algoritme voor de SSE is vooralsnog onbekend, al verdenkt men dat
er gebruik wordt gemaakt van een decrypt type RSA.
De superencryptie zou anders dan de SSE moeten lijken op die van SECA.
Superencryptie (SECA)
Als men de instructie in zijn geheel neemt (incl. de signature) en deze is
te delen in blokken van 8 bytes, bij elk blok kan men de algoritme van encryptie
met de key aangegeven door P2 toe passen.
Als de bytes die overblijven een nummer minder dan 8 zijn, dan kan de blok niet
compleet gemaakt worden en blijft het gecodeerd.
De structuur van de ins 38/3C/40
De klassieke formulering van SECA is compleet gehandhaafd met respect naar ISO 7816.
C1 38/3C/40 P1S P2 LEN + pakket van data
p1
Bit 0...3 :Aanduiding van de provider naar waar de commando verstuurd wordt.
Bit 4 :Gebruiken van primary key of primary + secundary key.
Bit 5,6 :Geeft begin aan van flashbuffer voor de berekening van de 'signature'
Bit 7 :niet in gebruik.
P2
Bit 0...3 :Aanduiding van de gebruikte key voor decrypten van de SuperEncryptie.
Bit 4 :Betekennis onbekend (moet zijn = 1)
Bit 5,6 :Selecteerd de map voor desencryptie en een eventuele user ALGO (niet actief bij de v7).
Bit 7 :Aanwijzer van de SuperEncryptie (moet zijn = 1)
LEN
Is de lengte van de 'pakketten van de data'
Voorbeeld:
C1 40 01 B1S 5C
10 01 12 08 F5S 56 DE F0 11 12 DOS D8 40 3B 34 7A
EB A5 B7 30 41 50 5F 02 6D B2S 03 ABS 29 2B 29 7A
05 4F AFS 83 18 75 1F 33 49 67 29 0CS C0 22 C7S 44
E3 BA 45 6D 1B 3A F3S 56 07 A9S 89 5D B4S 5E 8A D1
1F 40 F4S 50 D1S 57 D0S 96 88 5B EBS 93 2A 10 CE E8
4D 36 1F 80 A7S 65 A6S 9C 3E 03 78 49
Zoals eerder vermeld, zullen de twee bytes aangegeven in rood, voor alle lengtes van de INS zich hetzelfde handhaven.
Ze vertegenwoordigen enige parameters voor de SSE en 'gedragen' zich verschillend met respect op alle andere data. Ze geven ons de definitie aan van parameters P3 en P4.
Binnen deze data bevind zich een parameter van zeer grote extensie die niet zichtbaar is, vanwege het feit dat deze encrypted is.
Zijn funktie zal ik nader uitleggen, maar als eerste is het genoeg om
zijn extensie, zijn positie (de laatste byte van de data) en de naam (P5)
te weten. Dit wetende kunnen we een nieuwe uitvoering van de structuur
van de INS aangeven:
C1 38/3C/40 P1 P2 LEN P3 P4 + Data Pakket (P5)
