Doorlaten updates: hoe C1 commando uit EMM?

[Gast]

Momenteel speelt erg de vraag of bepaalde cams en softcams de kaartupdates van CD “doorlaten”. De kreet “doorlaten” hierin is enigszins misleidend, want het is geen kwestie van doorlaten, maar er moet in de betreffende cam/softcam expliciet voor zijn geprogrammeerd.

 

Laten we eerst even in het kort kijken wat er in de software gebeurt wanneer we een gecodeerd programma bekijken. Daarbij hebben we het dus nog niet over het bijwerken van de abonnementsgegevens op de kaart. De software moet voor het door ons geselecteerde programma in de transportstream kijken op welk pidnummer de zogenaamde ECM’s (Entitlement Management Message) van dit programma worden verzonden. Deze ECM’s bevatten namelijk de controlwords waarmee ons programma is gescrambled. De software moet deze ECM’s dus op dit pidnummer gaan filteren. Alleen zijn de controlwords in de ECM’s encrypted met in ons geval het seca algoritme. De software geeft daarom deze ECM’s door aan de smartcard, en deze ontsleutelt (decrypt) met behulp van keys en hashtables de controlwords en geeft deze terug aan de software. Met deze decrypted controlwords kan de software ons programma descramblen en hebben we gedurende een aantal seconden beeld, tot het controlword weer verandert. En terwijl we nu dus wel beeld hebben, staat dit volledig los van het bijwerken van abonnementsgegevens op de smartcard.

 

Om de kaart van bijgewerkte abonnementsgegevens te voorzien, moet er namelijk een hoop extra gebeuren. De software moet, los van het door ons gekozen programma, voor de betreffende codering, in ons geval seca, in de CA-table op pidnummer 1 uitzoeken op welk pidnummer de kaartupdates van deze codering worden verzonden. Voor alle duidelijkheid, dit is een ander pidnummer dan dat waar de ECM’s van ons programma op worden verzonden. Vervolgens moet hij tegelijkertijd naast de ECM filtering ook op dat pidnummer gaan luisteren (filteren) naar de zogenaamde EMM berichten (Entitlement Management Message) waarin de updates worden verzonden. Het kaartnummer moet worden opgevraagd bij de kaart, en vervolgens moeten de EMM’s die voor deze kaart worden ontvangen, worden omgezet naar C1 commando’s voor de smartcard. De overige EMM’s worden genegeerd. Dit alles is best een aardig lapje programmatuur, wat in bepaalde camsoftware gewoon niet of niet volledig zal zijn geprogrammeerd. Dat is dus de verklaring waarom de ene (soft)cam de update wel “doorlaat” en de andere niet. Dat sommige software wél bijvoorbeeld de maandelijkse update “doorlaat” maar niet de eerste activering, wijst in de richting van andersoortige C1 commando’s die niet worden ondersteund door deze software.

 

Het zijn met name vragen over de vertaling van de EMM’s naar C1 commando’s waarom ik dit draadje heb opgestart. Want hoe moet deze vertaling plaatsvinden? Zilverster en ik denken al aardig wat stukjes van de puzzel te hebben gevonden, en misschien kunnen we in dit draadje gezamenlijk proberen de puzzel compleet te krijgen. Misschien zijn er zelfs al mensen die alles al weten?

 

We bespreken onze bevindingen aan de hand van een seca EMM die in totaal uit 112 bytes bestaat:

 

82006D010203040506006A00B0100136DC9723299DD0233205CA249D17FEB43C8059B3DB73D1FA6C7A8D8E06415921C4F929B6CE3F33A8

2D04AD34CD9DECF2CDE42AAF12030F2A38F57D73E42D6B60B332E0FAE583BA6D64DE6425CBAF3981FDBC7B4E0593B39B1B276193FEDBB5DF23

 

Dit is dus een hexadecimale weergave van een EMM zoals die door de software uit de transportstream wordt gehaald. We hebben alleen het kaartnummer veranderd in 123456 (010203040506).

 

Omdat we met Wallbanger kunnen zien dat de laatste 99 bytes altijd rechtstreeks worden doorgegeven aan de smartcard, kunnen we de EMM beschouwen als bestaande uit twee delen, een eerste deel van 13 bytes en een tweede deel van 99 bytes. Uit het eerste deel kan de ontvanger bijvoorbeeld het kaartnummer halen. Als het serienummer in de EMM overeenkomt met het serienummer van de kaart, stelt vervolgens de software een C1 commando header samen en stuurt het tweede deel van 99 bytes, voorafgegaan door de instructieheader naar de smartcard.

 

Deze EMM is dus te splitsen in twee delen:

 

Deel 1, 13 bytes:

82006D010203040506006A00B0

 

Deel 2:, 99 bytes: 100136DC9723299DD0233205CA249D17FEB43C8059B3DB73D1FA6C7A8D8E06415921C4F929B6CE3F33A82D04AD34CD9DECF2

CDE42AAF12030F2A38F57D73E42D6B60B332E0FAE583BA6D64DE6425CBAF3981FDBC7B4E0593B39B1B276193FEDBB5DF23

 

Dit tweede deel wordt dus door de ontvanger/cam doorgegeven aan de kaart, voorafgegaan door de volgende C1 instruction header:

 

C1 40 01 B0 63

100136DC9723299DD0233205CA249D17FEB43C8059B3DB73D1FA6C7A8D8E06415921C4F929B6CE3F33A82D04AD34CD9DECF2

CDE42AAF12030F2A38F57D73E42D6B60B332E0FAE583BA6D64DE6425CBAF3981FDBC7B4E0593B39B1B276193FEDBB5DF23

 

De eerste drie bytes van een EMM zijn gestandaardiseerd en de beschrijving hiervan kan worden gevonden in ETR289_E1:

 

Omschrijving, aantal bits

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

Table id, 8

Section syntax indicator, 1

DVB Reserved, 1

ISO Reserved, 2

CA Section length, 12

Databytes: het aantal bytes dat is aangegeven door CA-section length

 

Dat betekent voor ons het volgende. Table-id=82, een EMM dus. De volgende drie velden zijn voor ons niet interessant. De CA section length, het aantal bytes achter de eerste drie bytes) wordt aangegeven door de tweede vier bits van het tweede byte en het derde byte samen. De tweede vier bits van het 2e byte zijn vier nullen (tweede byte is namelijk 00). Het derde byte is 6D, en dat is decimaal 109. En inderdaad komen achter het lengte byte 6D nog 109 bytes. Het totaal aantal bytes is namelijk 112, minus de eerste drie bytes is 109. (De beschrijving van deze eerste drie bytes is overigens ook van toepassing op ECM’s die als Table id 80 en 81 hebben)

 

Hiermee zijn de eerste 3 bytes van de EMM verklaard. Direct aansluitend, op positie 4 tm 9 vinden we de zes bytes van het kaartnummer.

 

Dan blijven er in deel 1 de laatste vier bytes over: 006A00B0

Hiervan zouden 00 6A kunnen staan voor provider 00 6A en van 00 B0 hebben we nog geen idee wat ze betekenen.

 

Nu gaan we kijken naar de seca instructieheader die op basis van deze EMM wordt gemaakt. Deze informatie is met Wallbanger verkregen.

 

C1 40 01 B0 63

 

Deze instructieheader is gestandaardiseerd in het ISO7816 protocol en bestaat altijd uit 5 bytes: Instruction class, Instruction (uit de class), Parameter P1, Parameter P2, Lengthfield en mogelijk een aantal databytes. In ons geval:

 

C1 is de instruction class (CLA), standaard altijd C1 bij seca. Dit is altijd hetzelfde en hoeft dus niet uit de EMM te worden gehaald. Seca software kan hier dus altijd C1 voor invullen.

 

40 is de instruction (INS). Deze lijkt echter niet uit de EMM voort te komen. Maar hoe moet de software in de (soft)cam/ontvanger weten welke waarde aan dit veld in de header moet worden gegeven? Of is dit altijd 40? En wat betekent deze instructie?

 

01 is parameter P1. Dit zou bijvoorbeeld het 15e byte van de EMM kunnen zijn, maar dat is een gok. Meer logwerk zou moeten uitwijzen of altijd zo is. En wat betekent deze parameter?

 

B0 is parameter P2. Dit zou het 13e byte uit de EMM kunnen zijn, vooropgesteld dat deze data uit het eerste deel van de EMM zou worden gehaald. Wat verder onderzoek zou moeten aantonen dat dit altijd het geval is. En wat betekent deze parameter?

 

63 is parameter P3, De lengte van de op de header volgende data. Hex 63 is deciaal 99 en dit zijn de 99 bytes van deel 2 van de EMM, die rechtstreeks worden doorgegeven aan de smartcard.

 

Als er universele seca ontvangers zijn, die voor iedere provider zouden werken, dan zou het toch zo moeten zijn dat er een universele manier is hoe een C1 commando moet worden samengesteld op basis van een ontvangen EMM. Maar wat is nu die formule?

 

Kloppen onze conclusies en aannames?

 

Er zijn hier op het board ongetwijfeld mensen met voldoende kennis om hier de nodige antwoorden op te geven. Het zou leuk zijn deze materie voor 100% helder te hebben.

[Böllke]

@Hermanator

 

Ik heb hierbij een stukje ingevoegd van Seca FAQ versie 3.1. Deze heb ik tijdens het seca1 tijdperk gevonden op een Duits forum, misschien dat je er wat aan hebt:

 

Citaat:

C1 40 P1 P2 LEN

 

Die Abonnementverwaltung erfolgt durch die Instruktion 0x40. Mit dieser ist es den Providern möglich, Vorgänge wie Ende des Abonnements, Erweiterung des Abonnements, PPV Events Verwaltung, PPV Jetons Verwaltung, Keyupdate etc. abzuwickeln. Dies fällt in die Kategorie EMM (Entitlement Management Message).

 

Adressierungen können an einzelne Karten (über UA / Card Serial), an alle Karten oder an zu spezifizierende Karten einer Gruppe erfolgen. Bei der letzteren Möglichkeit kommt die bereits bekannte Shared Address sowie das CUSTWP-Byte zum Tragen. IRDETO-erfahrene Leser werden jetzt an die CB20-Matrix denken: es wird eine CUSTWP-Bitmap aus max. 256 Bits (32 Bytes) gebildet, ist das erste Byte gesetzt, bedeutet dies, daß die erste Karte der über die SA angegebenen Gruppe angesprochen wird usw.

 

Folgende Nanos können mit der 0x40 zur Anwendung kommen, bei den noch von der Bedeutung unbekannten ist Vorsicht angeraten!

a) NUR für Provider 00 (SECA) gültig

 

0x18 + 1 Byte Daten löscht einen AX-Record (sowohl mit INS 0x40 Nano 0x33 als auch durch INS 0x3C angelegte); übergeben wird das erste Byte des AX-Records; siehe: Nano 0x33

 

0x1D +1 Byte Daten schreibt das übergebene Byte in das EEPROM ab Position E01A. Protection Flag, kann den Wert 00, 55 oder FF haben.

Ist E01A auf 00, kann er mit dem Wert 00 auf 55 gesetzt werden, oder mit einem Wert ungleich 00 auf FF.

Ist E01A auf 55, kann er mit einem Wert ungleich 00 auf FF gesetzt werden, 00 hat keine Wirkung mehr.

Ist E01A auf FF, kann der Wert nicht mehr verändert werden.

Der optimale Wert ist 55, da hier die Protection ausgeschaltet ist.

 

0x1E + 1 Byte Daten schreibt das übergebene Byte in das EEPROM ab Position E018. Protection Flag, schützt die Instruktionen 0x50 und 0x54. Werte siehe bei Nano 0x1D.

 

0x1F + 1 Byte Daten schreibt das übergebene Byte in das EEPROM ab Position E019. Protection Flag, schützt die Instruktion 0x56. Werte siehe Nano 0x1D.

 

0x23 + 2 Bytes Daten fügt den durch die zwei Bytes spezifizierten Provider hinzu

 

0x24 + 2 Bytes Daten prüft, ob der durch die zwei Bytes spezifizierte Provider vorhanden ist und bewirkt, daß die folgenden Nanos auf diesen Provider angewendet werden

 

0x25 + 2 Bytes Daten entfernt den durch die zwei Bytes spezifizierten Provider

 

0x26 + 2 Bytes Daten ermöglicht/verhindert das Anlegen neuer Records für den aktuellen Provider

 

Beispiel:

26 FF FF

FF FF = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 = 16 Bit

^----- a (1-10)-----^

^ b (11)

^ c (12)

^-^ d (13-14)

^ e (15)

 

a) max. Anzahl der Recordbytes für diesen Provider

muß für Nano 0x32 gesetzt sein

c) muß für Nano 0x80 gesetzt sein

d) muß für die Nanos 0x30, 0x42, 0x43 gesetzt sein

e) muß für Nano 0x01 gesetzt sein

 

0x33 + 3 Bytes Daten  legt einen AX-Record an, wenn noch nicht vorhanden, enthält einen Zähler

über das erste Byte kann der Record angesprochen und verändert werden

 

gelöscht wird dieser AX-Record durch Nano 0x18; verringert wird der Zähler durch Nano 0xD1 der geschützten Instruktion 0x44

 

die Anlage eines AX-Records als PPV Preview Record erfolgt in der Regel durch eine INS 0x3C mit Daten für die Preview-Phase, also muß dieser AX-Record einem anderen Zweck dienen

 

wurde der Record über Nano 0x33 angelegt, erfolgt Löschung durch jede beliebige INS 0x3C, wenn das dritte Byte den Wert 00 angenommen hat

 

man kann einen bestehenden, durch INS 0x3C angelegten AX-Record verändern, indem man (durch Ansprache über das erste Byte des Datums) das zweite Byte des Datums sowie das erste Byte der PPV-EventID neu schreibt

 

 

restliche

 

0x01 schreibt 0xFF in den Provider-Struktur bei Offset 0x1B;

Provider kann dann auch nicht mehr über Nano 0x24 angesprochen werden

 

0x02 schreibt 0x00 in den Provider-Struktur bei Offset 0x1B;

Provider kann wieder über Nano 0x24 angesprochen werden

 

0x03 setzt den PIN auf Null.

 

0x10 + 1 Byte Daten löscht den im Byte spezifizierten Key vom aktuellen

Provider

 

0x11 + 1 Byte Daten löscht einen SECA Record des im Byte angegebenen Typs

 

0x17 + 1 Byte Daten schreibt das übergebene Byte in die Provider-Struktur bei Offset 0x18; Regionalcode

 

0x21 + 2 Bytes Daten Setzt Datum für Abonnementende

 

0x22 + 2 Bytes Daten Prüft Datum für Abonnementende

 

0x28 + 2 Bytes Daten löscht AX-Record

 

0x30 + 3 Bytes Daten PPV Verarbeitung; setzt vermutlich eine Art von Kredit (Film kann ohne erworbene Jeton gesehen werden)

 

0x32 + 3 Bytes Daten PPV Verarbeitung; wird an die Karte gesendet, wenn ein PPV Event geordert und bezahlt wurde (2 Bytes PPV-EventID + 1 Byte Counter, dieser gibt an, wie oft ein PPV-Event an dem betreffenden Tag gesehen werden darf)  legt BX-Record an (Provider PPV Record), Datum noch auf FF FF

 

0x40 + 4 Bytes Daten löscht PPV Records im Datumsbereich der vier übergebenen Bytes (aabb bis ccdd)

 

0x41 + 4 Bytes Daten schreibt PPUA

 

0x42 + 4 Bytes Daten a) schreibt erworbenen Jetons auf die Karte (2 Byte Datum + 2 Byte Anzahl der Jetons, siehe: Provider PPV Credit Records, Verändern der Jeton-Anzahl)  legt DX-Record (Provider PPV Credit Record) an

 

42 FF FF 00 00 löscht den Provider PPV Credit Record

 

0x43 + 4 Bytes Daten ändert erworbene Jetons auf der Karte (2 Byte Datum + 2 Byte Anzahl der Jetons, siehe: Provider PPV Credit Records, Verändern der Jeton-Anzahl)

 

0x80 + 8 Bytes Daten es folgt Package Bitmap für den Provider; mit [8*FF] wird komplettes Programmpaket freigeschaltet

 

0x82 + 8 Bytes Daten es folgt Signatur

 

0x87 + 8 Bytes Daten schaltet geschützte Instruktion 0x44 frei, 8 Bytes Daten müssen mit mF0E (INS 0x06) identisch sein; initialisiert den Cryptbuffer für nachfolgende INS 0x44

 

0x90 + 9 Bytes Daten es folgt Keyindex sowie verschlüsselter Primary Key

 

0x91 + 9 Bytes Daten es folgt Keyindex sowie verschlüsselter Secondary Key

 

0xB0 + 11 Bytes Daten schreibt einen SECA Record des in den Daten angegebenen Typs (z.B. Aktivierungs-Record)

 

0xD0 + 16 Bytes Daten es folgt ProviderID String

 

0xF0 + 32 Bytes Daten es folgt CUSTWP-Bitmap

 

 

Wichtig ist, das wir beim Senden dieser Instruktion die Option „from CAM to Card“ in unserem Programm aktivieren, da diese Daten zur Karte gesendet werden. Die Länge des Befehlsstrings ist variabel.

 

Beispiel:

[es wird der Primary Key 02 und (wenn gespeichert) der Secondary Key 02 für Provider 09 verwendet, siehe: Verwendung von Keys; wird an alle Abonnenten gesendet, Superencryption wird verwendet, Hash-Buffer mit [8*00] initialisiert; Erklärungen: siehe weiter unten in diesem Abschnitt]

 

Instruktion an die Karte : C1 40 19 82 35

Datenteil (wird, wie immer im großen Feld „Instruction“ eingetragen):

96 E8 5D 3B 97 26 6E B1 82 0F 87 17 D3 5C 87 47 34 5E 39 79 2F 8E 84 4C 16 E2 3A 6A A3 40 30 C9 05 5F BB 01 56 11 7C 4F BF 1F C3 32 21 BD 13 D9 60 53 25 CB 9E

 

Erst dann den Befehl senden.

 

Echo der Karte:

40 96 E8 5D 3B 97 26 6E B1 82 0F 87 17 D3 5C 87 47 34 5E 39 79 2F 8E 84 4C 16 E2 3A 6A A3 40 30 C9 05 5F BB 01 56 11 7C 4F BF 1F C3 32 21 BD 13 D9 60 53 25 CB 9E 90 00

 

Wir sehen kein erkennbares Muster! Der Grund hierfür liegt in einem „Superencryption“ genannten Verfahren, welches aber anscheinend nicht alle Kartenversionen beherrschen. Im String an die Karte übergebene verschlüsselte Daten (z.B. Operation Keys) werden unter Verwendung des in P2 spezifizierten Keys für den jeweiligen in P1 spezifizierten Provider nochmals verschlüsselt, bevor diese übermittelt werden, beginnend beim ersten Byte und einschließlich einiger Bytes der Signatur. Dieses Verfahren wäre auch für 0x3C möglich, wird aber zur Zeit nicht verwendet! Erst Karten ab Softwareversion Num40 beherrschen die Superencryption für ECM’s!

 

P1 beinhaltet sowohl den Provider (im Beispiel oben Provider 09), ebenso wird die Verwendung von Primary und Secondary Key geregelt (siehe: Verwendung von Keys, fünftes Bit). P2 gibt den Keyindex (im Beispiel Key 02) an, sowie ob die Superencryption verwendet wird oder nicht:

 

Ist das achte Bit (wie immer von rechts nach links gezählt) von P2 gesetzt, wird die Superencryption verwendet. Hier leistet uns wieder der Windows-Taschenrechner im wissenschaftlichen Modus gute Hilfe: rechnen wir z.B. die Hex-Zahl 82 in Bit (bin) um, so erhalten wir: 10000010. Wir sehen, das achte Bit ist gesetzt (1 statt 0), die Superencryption wird verwendet.

 

P1 gibt auch noch an, wie der Hash-Buffer bei der Berechnung der Signatur initialisiert wird. Was das genau ist und wie dies funktioniert, kann in den bereits genannten Unterlagen zum Algo nachgelesen werden.

Zur Verwendung kommt wieder die Bitstruktur von P1, und zwar die oberen drei Bits wie folgt:

 

a) 001x xxxx Hash-Buffer initialisiert durch: 6 Bytes UA (Card Serial) + [2*00]

010x xxxx Hash-Buffer initialisiert durch: 4 Bytes PPUA + [4*00]

c) 011x xxxx Hash-Buffer initialisiert durch: 3 Bytes SA + [5*00]

d) alles andere Hash-Buffer initialisiert durch: [8*00]

 

Seltsamerweise interessiert das höchste Bit nicht. Auch wird derzeit nur die Initialisierung über [8*00] von den Providern verwendet. Unter Berücksichtigung der bit-definierten Inhalte von P1 (Provider 0-F; Primary / Secondary Key - Regelung sowie Hash-Buffer Initialisierung) ergeben sich folgende Wertebereiche für P1:

 

a) 0x20 – 0x2F (bei PK, PK) – 0x3F (bei PK, SK)

0x40 – 0x4F (bei PK, PK) – 0x5F (bei PK, SK)

c) 0x60 – 0x6F (bei PK, PK) – 0x7F (bei PK, SK)

d) 0x00 – 0x0F (bei PK, PK) – 0x1F (bei PK, SK)

 

Die Daten werden ja vom CAM an die Karte weitergeleitet. Die Karte überprüft nun, ob der Hash korrekt ist und bei positiver Überprüfung wird die Meldung verarbeitet. Damit ergeben sich folgende Arten von EMM’s:

 

a) an alle Abonnenten = EMM-G (engl.: „General“)

an bestimmte Karten einer adressierten Gruppe, spezifiziert durch SA + CUSTWP-Bitmap) = EMM-S (engl.: „Shared Group of Customers“)

c) einen einzelnen Abonnenten, über UA / Card Serial = EMM-U (engl.: „Unique“)

 

Die Technik der Superencryption soll das Analysieren der Daten erschweren. Die Karte entschlüsselt jeweils 8-Byte Blöcke mittels des Algo. Es wird jeweils in Blöcken (8 Byte) verschlüsselt. Bleiben weniger als acht Byte übrig, wird der Rest nicht verschlüsselt.

 

Es gibt eine Vielzahl möglicher EMM’s, diese variieren in Sendeintervall, Wechsel des Codes und Länge.

 

Groetjes

Böllke

<img src="/forums/images/graemlins/xyxthumbs.gif" alt="" />

899921-SecaFAQDuits.zip

[Gast]

Hartelijk dank voor deze enorme lap Duitse tekst. Mijn kennis van de Duitse taal is helaas erg beperkt. Het grootste deel lijkt mij echter te gaan over de werking van het seca protocol. Dat is niet de reden voor mij om dit draadje te starten, want ik denk dat daar al echt kwalitatieve topics over lopen zoals bijvoorbeeld “de zoektocht naar het algoritme”. Ik denk dat gesprekken over het algoritme, nano’s, hashtabellen e.d. beter daarin kunnen (blijven) plaatsvinden.

 

Waar het mij om gaat is hoe de ontvangen EMM moet worden vertaald in een C1 commando naar de smartcard. Dit vereist geen kennis van de (geheime) werking van het seca protocol. Het gaat er alleen maar om te ontdekken hoe het commando wordt samengesteld op basis van de inhoud van de EMM, dus bijvoorbeeld dat P2 wordt ingevuld met (bv) de 15e positie van de EMM.

 

Maar ik denk wel dat er wat interessante informatie inzit in het kader van bovengenoemde doelstelling.

 

Citaat:

Die Abonnementverwaltung erfolgt durch die Instruktion 0x40.

 

1) 40 is kennelijk altijd de instructie voor een EMM

 

Citaat:

P1 beinhaltet sowohl den Provider (im Beispiel oben Provider 09), ebenso wird die Verwendung von Primary und Secondary Key geregelt (siehe: Verwendung von Keys, fünftes Bit). P2 gibt den Keyindex (im Beispiel Key 02) an, sowie ob die Superencryption verwendet wird oder nicht:

 

2) P1 is kennelijk de provider én de verwijzing naar primary en secundary key

3) P2 is de keyindex en of superencryptie is toegepast of niet (eerste bitje gezet of niet)

 

Blijft natuurlijk de vraag hoe de waarde van deze parameters kan worden bepaald op basis van de inhoud van de EMM.

 

Citaat:

Die Daten werden ja vom CAM an die Karte weitergeleitet. Die Karte überprüft nun, ob der Hash korrekt ist und bei positiver Überprüfung wird die Meldung verarbeitet. Damit ergeben sich folgende Arten von EMM’s:

 

a) an alle Abonnenten = EMM-G (engl.: „General“)

an bestimmte Karten einer adressierten Gruppe, spezifiziert durch SA + CUSTWP-Bitmap) = EMM-S (engl.: „Shared Group of Customers“)

c) einen einzelnen Abonnenten, über UA / Card Serial = EMM-U (engl.: „Unique“)

 

4) Er zijn dus 3 soorten emm’s. Resulteert dit dan ook in andere C1 instructies of heeft dit uitsluitend te maken met de adressering van één of meerdere kaarten tegelijkertijd en blijft de instructie 40?

 

Citaat:

Es gibt eine Vielzahl möglicher EMM’s, diese variieren in Sendeintervall, Wechsel des Codes und Länge.

 

Ook dit doet de vraag reizen of er meerdere instructies dan 40 volgen uit een ontvangen EMM.

 

Iemand?

[hd196]

010203040506 = UA (unique address,kaart nummer)

006A = Provider

B0 = key

 

het C1 40 commando geeft in P1 de provider index door (tabel met providers word ingelezen zodra je de kaart in de ontvanger/cam stopt)

in P2 de te updaten key.

 

table id 84 is een update op basis van een groep smartcards(1e 3 bytes van UA).

alleen nu is de volgorde van velden in de header van de seca-EMM

2 bytes provider

3 bytes adres (SA)

1 byte key

deze word ook als een C1 40 doorgegeven aan de kaart. De cam zend de update alleen door als de 1e 3 bytes van de UA overeen komen met de SA.

 

dus ja, C1 40 blijft, alleen cam filtert op basis van het (eerder) gelezen smartcardnummer(UA)

[Zilverster]

@hd196,

 

Citaat:

table id 84 is een update op basis van een groep smartcards(1e 3 bytes van UA).

 

 

Heb jij misschien een totaal overzicht van deze tabel ID's bij de hand en zo ja, valt er dan iets te regelen <img src="/forums/images/graemlins/wink.gif" alt="" /> .

 

 

@All,

 

Zoals het lijkt zou je er vanuit kunnen gaan dat de commando's zoals C1 40 enz. dus opgeslagen liggen ergens in het geheugen van de ontvanger of cam en dus op deze manier worden "overgezet" naar een instructie die begrijpbaar is voor de kaart.

 

Dit zou de evt. problemen die zich nu voor doen bij de update's van de kaarten met de div. cam's zoals de Aston 1.05 dus kunnen verklaren <img src="/forums/images/graemlins/blush.gif" alt="" /> , gr.

 

Zilverster.

[Gast]

En met welke C1 wordt dan één enkele kaart uitgezet?

Avensis

[Zilverster]

@avensis,

 

Ik ga er vanuit dat dat ook een C1 40 is in combinatie met serial/ppua.

 

Ik praat hier ook niet over uitschakelen van kaarten, maar meer over het niet doorlaten van de nieuwe activatie datum op de Aston 1.05 cam's en kan mij voorstellen dat de 31 hier het probleem geeft ( leest : C1 40 31 B1 65 ).

 

De achter liggende gedachte hier is dat bij de oudere cam's misschien minder informatie is opgeslagen die bij de wat nieuwere cam's al wel is aangepast ( misschien uitbreiding van commando's seca 2 ), ik denk hier aan de of. + goed gekeurde apparaten <img src="/forums/images/graemlins/biggthumpup.gif" alt="" /> , gr.

 

Zilverster.

[Gast]

Dag,

Hier in het midden van Afrika heb ik ook last van het hiet niet updaten van de kaart op de seca2 provider. De seca2 provider is 006E en zit op NSS 7, 22 West op de Ku band. Naam van de provider is Canal Satellite Horizon, die ik verder zal afkorten tot CSH

 

Nu raadt CSH aan om alle materiaal bij hem aan te schaffen, dus de decoder met kaart en abonnement samen met schotel en lnb. Men heeft heeft men de mogelijkheid om ook enkel een kaart en abonnement te nemen, dus voor hen die reeds over een geschikte decoder beschikken en daar wringt nu het schoentje.

Ik log regelmatig de volledige emm stream met vgrabber en de nokia en stel nu hetvolgende vast :

- de updates worden allen via tabel 82 gedaan, dus via het serialnum van de individuele kaart.

- voor sommige kaartnummers geschiedt de update meerdere malen per dag,en dit gedurende de ganse maand. Mijn vermoeden is dat deze kaartnummers aan packages CSH gekoppeld zijn.

- voor kaartnummers die aan geen CSH verbonden zijn is er soms een enkele update per maand, en dikwijls moet er specifiek om gevraagd worden. De reden die dan opgeven wordt door CSH is dat sommige decoders de updates niet doorlaten.

Nu kan ik stellig beweren dat dit onzin is, omdat een ganse maand loggen mij liet zien dat mijn kaartnummer niet in de updates voorkwam. Vroeg ik een manuele update aan, dan kwam mijn kaartnummer keurig in de logfile en werd de kaart naar behoren aangepast.

 

Kan iemand eens een uurtje of drie vier de volledige emm stream loggen en kijken of men nog steeds tabel 84 gebruikt,

of dat men ook naar 82 is overgeshakeld.

Tabel 82 is update via serialnum

Tabel 84 is update via ppua-group.

 

Hier zie ik ook nog tabel 86 en die geeft dan persoonlijke berichten weer die op de kaart komen, zoals verjaardagwensen of dat het abonnement moet verlengd worden.

 

Groeten

[Zilverster]

@Rodajo,

 

Op dit moment lijkt het er op dat alleen tabel 82 in gebruik is en dat men kaart voor kaart bij langs gaat ( serial dus ), later deze week komen we hier op terug.

 

Zou je evt. kunnen posten hoe de C1 40 van nu bij jou er uit ziet, gr.

 

Zilverster.

[magellan]

dus heb ik slechts een verklaring wat er op het ogenblik aan de gang is:

 

men gaat iderdaad kaart voor kaart de update versturen. die updates is van bijna alle hardware verwerkt. Even wachten dus, totdat je aan de beurt bent.

 

tegelijkertijd zijn ook updates op de "oude" manier verstuurd: tenzij je hardware hebt, die als "goedgekeurd" herkend is, is het niet wachten op je nummer.

 

ik had mijn ontvanger 24 uur per dag aan met een seca 1.03, 1.07 een een magic 1.20. geen updates.

 

ik probeer een paar cams in een sat-winkel en met een mrev na 5 minuten een update. Zeg maar niet, dat juist op dit moment "mijn" nummer verstuurd werd. Dit soort toevallen zijn er niet.

 

magellan

[Zilverster]

@magellan,

 

Je zou best eens gelijk kunnen hebben, maar het starten van dit draadje door @Hermanator is natuurlijk niet in eertse instantie bedoeld om dit probleem op te lossen, hoewel we dit wel meenemen, bedankt voor je RE <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" /> , gr.

 

Zilverster.

[Gast]

@hd196,

 

Geweldige informatie, dankjewel!!! <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" /> <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" /> <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" />

Even kijken of ik er chocola van kan maken…

 

Deel 1, 13 bytes:

82006D010203040506006A00B0

 

82006D = Table-id en lengte EMM.

010203040506 = kaartnummer (UA, Unique Adress)

006A = Provider

00 = ?????

B0 = key

 

Conclusies:

1) Een EMM wordt dus altijd vertaald in een C1 40.

2) Een EMM met table-id 82 is zoals boven omschreven (eerste 13 bytes)

3) Een EMM met table-id 84 is hetzelfde als een 82, maar heeft op positie 4-5 de provider, 6-8 SA (eerste drie posities van het kaartnummer) en op positie 9 de key (dit dus in plaats van het kaartnummer in de EMM-82).

4) De provider (006A) wordt aan de hand van een tabel op de kaart vertaald naar een provider index op de kaart en in P1 gezet.

5) Bij een EMM-82 gaat byte 13 naar P2

6) Bij een EMM-84 gaat byte 9 naar P2

 

Er wordt een C1 commando samengesteld voor de kaart als:

 

1) het een EMM-82 is en byte 4-9 overeenkomen met het kaartnummer

2) het een EMM-84 is en byte 4-6 overeenkomen met de eerste drie posities van het kaartnummer

 

Een C1 commando wordt dan als volgt wordt samengesteld:

 

CLA: Altijd C1

INS: Altijd 40

P1: vertaling van byte 10 en 11 bij een EMM-82 en byte 4 en 5 bij een EMM-84 naar een provider index op de kaart. Tabel op te vragen op de kaart.

P2: Byte 13 van een EMM-82 en byte 9 van een EMM-84

P3: Lengte datasection

Datasection: EMM-82 vanaf byte 14, en EMM-82 vanaf byte ??

 

Om het echt te kunnen "zien" zou ik dus inzicht moeten hebben in hoe zo'n providertabel eruit ziet als je hem opvraagt aan de kaart. Daar zal dus een C1 commando voor moeten zijn, net als voor het opvragen van het kaartnummer.

 

Bij een emm-84 vinden we dus de provider op byte 4 en 5, maar mogen we er dan vanuit gaan dat ze in een emm-82 altijd op byte 10 en 11 te vinden zijn? En zo ja, hoe ziet een emm-84 er dan uit op die posities? Staat het er dan dubbel in, of zou het eerste deel korter zijn? Maar goed, dat kan ik ook wel eens gaan loggen. Of heb jij een totale omschrijving van de emm’s? Dan zijn we er direct helemaal uit! <img src="/forums/images/graemlins/grin.gif" alt="" />

 

En wat betekent de 00 op positie 12 van een EMM-82?

 

@Rodajo,

Man wat had jij ze dan leuk aan hun taas met die totale emm-log! <img src="/forums/images/graemlins/grin.gif" alt="" />

Ik zal van de week eens een totale log doen op een seca emm pid. Eens kijken wat we nog meer voor tabelletjes voorbij zien komen. Wordt vervolgd!

 

@Magellan,

Ik denk dat jij best gelijk kunt hebben. Als ze in een emu dus bijvoorbeeld de 84’s niet filteren (net als ik dat niet had gedaan) en ze alleen de 82’s pakken dan klopt je stelling. Ik wist ook niet van de 84’s af en zou dit dus ook niet hebben geprogrammeerd.

 

@Zilverster,

Werk aan de winkel! <img src="/forums/images/graemlins/grin.gif" alt="" />

[Gast]

Uitzetten van een kaart is dus eigenlijk een update van.

Alleen wordt hier dan WEL het serienummer(lees uniek adres) gebruikt.

We hebben het er nog wel over.

 

Hermanator

er zijn meer commando´s als de C1 40 die bepaalde(dezelfde) zaken bewerkstelligen.

Weet even niet meer uit mijn hoofd welke maar ze staan in de doc(seca2 faq). die je hebt.

Avensis

[Zilverster]

@avensis,

 

Citaat:

Hermanator

er zijn meer commando´s als de C1 40 die bepaalde(dezelfde) zaken bewerkstelligen.

Weet even niet meer uit mijn hoofd welke maar ze staan in de doc(seca2 faq). die je hebt.

Avensis

 

Dat begrijp ik, maar we houden het wel even op NM en niet op HPM, zoals de 50 hoop ik <img src="/forums/images/graemlins/grin.gif" alt="" /> , gr.

 

Zilverster.

[Gast]

Dit is een voorbeeld van de emm's op een willekeurige kaart :

 

82 00 66 xx xx xx xx xx xx 00 6E 00 B0 10 01 43 C2 E7 A5 82 A4 9F 27 D1 1B 1D 9C 96 7C 2C 02 89 FD D8 03 40 F0 FA 0B BB C4 52 FA C9 52 29 FC 8C FB 35 09 3A A8 49 11 86 43 E2 6E 3C 15 AC B8 75 97 8D 5D 95 7C 1F 6E 59 BA A5 3E E3 1A 95 EF D9 DB A9 2B BA C7 7D 10 04 F6 C4 AB AB 5E AF 04 47 80 37 9E D3 B5 00 F3 10 18

 

en geeft dan deze C1

C1 40 01 B0 5C 10 01 43 C2 E7 A5 82 A4 9F 27 D1 1B 1D 9C 96 7C 2C 02 89 FD D8 03 40 F0 FA 0B BB C4 52 FA C9 52 29 FC 8C FB 35 09 3A A8 49 11 86 43 E2 6E 3C 15 AC B8 75 97 8D 5D 95 7C 1F 6E 59 BA A5 3E E3 1A 95 EF D9 DB A9 2B BA C7 7D 10 04 F6 C4 AB AB 5E AF 04 47 80 37 9E D3 B5 00 F3 10 18

 

Ook heb ik soms

C1 40 01 B0 65 10 01 enz....

 

Ik laat mijn binfile door seca_emm_ex1.25 van JosyFun verwerken.

 

groeten

e