gelöst ORF EMM Verlängerungs-Problem bei 0D98 Crypto-Karten - (NEU: ohne needsglobalfirst)

[pehedima]

Das Logfile bestätigt, dass das Problem im cryptoworks-reader liegt.
Ich mache mal eine Änderung und schicke ein neues Binary zum Testen. Das ist dann keine Indizien Version, sondern sollte schon mal richtig getestet werden.

The new version is coming soon

Wir sollten doch noch einen Test vorher durchführen, damit wir an der richtigen Stelle die Änderung vornehmen:

Testet mal bitte, ob beim abgeschaltetem emmcache (emmcache 0,0,0,0) eine Verlängerung der Karte nur mit SHARED-EMMs möglich ist.
Dazu alle EMMs bis auf die Shared-EMMs blocken.

Das mal laufen lassen. Das EMMs geskipped werden ist dabei normal. Der debug_level kann auf 0 stehen bleiben.
Das sollten diejenigen Testen, bei denen das Verlängern nur mit Shared-EMMs nicht läuft.

 

[janni1]

Hi,
@pehedima
vielleicht hilft dir das PDF (Cryptoworks FAQ By SlayraCkEr) ein wenig weiter, wenn du es nicht schon hast.
94 04 scheint ja sowas wie - Anweisung von der Karte abgelehnt (FILE nicht gefunden, kein Datensatz gefunden)- zu bedeuten, wenn ich das richtig versteh.

 

[FANATLA]

Bei mir läuft der Test. Ich drücke öfter mal auf Refresh Entitlements. Heute haben sich die Entitlements noch nicht verändert. Auch scheint es so als werden heute laut Übersicht alle geskipped. Sicher bin ich mir nicht seit wann es so ist aber jetzt hatte ich 27 skipped und 0 written bevor sie mit dem Refresh wieder auf 0 gesetzt wurden.

Gesendet von meinem SM-G930F mit Tapatalk

 

[pehedima]

Die Karte lehnt die EMMs ab.
Wie bereits gestern im Logfile ersichtlich antwortet die Karte mit: 94 04

Lt. Doku von oben:

94 04 - It find by card - instruction rejected ( FILE, it find ) kordu

Heißt eigentlich, dass die Karte den Inhalt bereits kennt und die Anweisung skipped.
Kommentar im Source-Code an der Stelle: // emm already written before, entitlement / key is already up to date -> skipped

Bei Erfolg antwortet die Karte mit 90 00:

90 00 - Errand executed, OK

Es könnte sein, dass die Karte dann irgendwann einfach komplett zu macht und alle Shared-EMMs rejected.
Lass das erstmal weiterlaufen.

Evtl. können das auch noch andere Testen und das Ergebnis hier posten. Danke.
Und immer schön die Shared-EMMs speichern.

 

[janni1]

Hi
hier mal ein Zitat von @theparasol aus dem SB

It looks like same as with viaccess class entitlement. If chid already up to date it throws a 9404.

Beim SC-plugin und acamd wird es übrigens so ausgewertet
[core.smartcard] 0: File not found (status: 94 04)

hier mal noch ein interessantes Zitat aus diesem Thread:
ORF emm!s global, share und unique

...
Wenn man danach z.B. emm-unknown, emm-u und emm-g blockt, so werden bei den Shared EMMs manche erfolgreich geschrieben,
und manche tauchen im LOG als "skipped" auf - was nicht ganz korrekt ist. Schaut man sich die EMM-s im LiveLog an, so werden
manche mit 9000 (EMM akzeptiert) geschrieben und auf die unter "skipped" vermerkten EMM-s antwortet die Karte mit
9404 == "FID not found, record not found or comparison pattern not found" was prinzipiell nicht schlimm ist, und nur ein Zeichen
ist, dass die Karte im Gruppenfilter des verschlüsselten EMM-s Anteils nicht enthalten war (vermutlich ist das auch gut so, über
die entsprechenden EMM-s können CHIDs auch gelöscht werden)...

 

[pehedima]

Danke @janni1
Hört sich doch alles gut und logisch an.
Hoffen wir mal das unsere Karten hier das auch so sehen, denn dann müssten ja die entsprechenen Shared-EMMs auch korrekt geschrieben werden und die Verlängerung der Karte darüber problemlos erfolgen.


Auch interessant ist der nachfolgende Teil in dem von @janni1 oben verlinkten Beitrag:

Spoiler

Wie oben schon bemerkt, werden aber selbst durch die geschriebenen EMM-s (Antwort 9000) die CHIDs nicht weiter verlängert.

Im Prinzip lässt das den Schluss zu, dass die EMM-G eine entsprechende Systemzeit oder einen Zeitstempel aktualisieren.
Wenn dann der entsprechende EMM-S kommt, werden vermutlich die CHIDs relativ zu dem über den EMM-G gesetzten
Zeitstempel verlängert.

Als kleines Experiment:

- Karte vollständig aktualisiert - alle EMMs blocken und einen Tag warten
- am Folgetag nur die EMM-S freigeben ... es gibt EMM-S mit 9000 und welche mit 9404
- die Freischaltung wird nicht aktualisiert

Nächster Schritt:

- Alle EMMs blocken und nur die EMM-G freigeben
- einen halben Tag warten und 2000+ EMM-G auf die Karte schreiben
- danach alle EMM blocken und nur die EMM-S freigeben
- die EMM-S mit 9000 verlängern nun die Entitlements

Ich denke derselbe Mechanismus kann u.a. verhindern, dass man die Karte mittels Replay quasi mit alten EMM Daten versorgen kann

Bin mal auf die Testergebnisse hier gespannt, ob das so bestätigt wird.

 

[Smiley007]

Ich stehe auch gerne zu umfassenden Tests zur Verfügung.

Ich habe ja die folgende Konstellation:

- PI B+ mit Oscam (mit dvbapi Unterstützung) 11353 oder 11272 und CCcam Protokoll (cs378x auch eingerichtet)
- Karten: V14, ORF C841 (Irdeto), HD01, MTV
- als AU Client dienen wahlweise DM900, GigaBlue Quad und DVB Viewer per dvbapi über den PI

Wegen der besseren Überwachung der User bezüglich der zu sendenden EMM‘s haben die Client‘s für jede Karte am Pi einen separaten Reader. (Configs dann später)

Ansich rennt der Pi absolut stabil. Nur mit den EMM‘s für die verschiedenen Karten gibt es immer wieder sich veränderte Probleme, die ich nie endgültig lokalisieren könnte.

Wenn ich in die Tests mit einsteigen soll, besser in einem neuen Thread?

 

[janni1]

Hi,
@pehedima
das ist wirklich sehr interessant.
Ich denke aber auch, dass die EMM-G eine Voraussetzung irgendeiner Art mitbringen/Auslösen, die uU. das Schreiben der EMM-S bzw. das Verlängern der Entis erst ermöglicht.

 

[pehedima]

Das sieht zumindest so aus.
Würde gerne genau wissen welche EMM-G evtl. als Vorbereitung für die Verlängerungs EMM-S zuständig sind. Evtl ist das ja auch nur ein Global-EMM.
Mit einer speziellen Update-Funktion für 0D98 Karten könnte man das dann von oscam automatisch erledigen lassen.
Mal sehen was da rauskommt.

@Smiley007
Denke das Problem tritt nur bei CAID 0D98 (cyptoworks) auf. Da deine Karte im Irdeto-Mode läuft, kannst du das Problem sicher so nicht nachstellen.
Lasse mich aber auch gerne eines bessern belehren.

 

[Smiley007]

OK, dann mache ich das später mal als neuen Thread auf.

 

[pehedima]

Mach das bitte.
Denke deinen Fall sollten wir separat zu diesen Aktionen hier analysieren.
Bleibt dann übersichtlicher.

 

[FANATLA]

Es könnte sein, dass die Karte dann irgendwann einfach komplett zu macht und alle Shared-EMMs rejected.
Lass das erstmal weiterlaufen.

Evtl. können das auch noch andere Testen und das Ergebnis hier posten. Danke.
Und immer schön die Shared-EMMs speichern.

Genau so scheint es zu sein. Bis jetzt seit heute Früh wurden alle Shared geskipped (laut Übersicht, trotzdem steht immer ACTIVE bei au), nach Refresh haben sich auch die Entitlements nicht geändert. Alle Shared seit gestern vormittag sind geloggt, Speicherverbrauch gerade mal 274kB, kann ich gern weiterlaufen lassen. Wir werden die Lösung schon finden. Nachdem die Enties immer gute 8 Monate gelten kann man zur Not ja mal kurz Globals durchlassen.

Es wäre der Hammer wenn wir das Global-EMM (oder mehrere) finden das die Shared wieder durchlässt und das Verlängern wieder automatisieren könnten ohne alle Globals durchzulassen was die ECM-Zeiten teilweise erhöht.

Trotzdem wundert es micht dass manche behauptet haben es reichen die Shared. Entweder sind sie noch nicht draufgekommen (wie ich am Anfang) oder es funktioniert mit manchen Karten doch, oder es waren nicht alle 0D98.
Ob es nur beim Raspi so ist (Threadtitel) wissen wir auch noch nicht.

 

[d2z]

Meine Karte 0D98 sieht seit ich sie habe nur die shared Emms. Keine Probleme mit der Verlängerung.
Allerdings kein RPI.

 

[pehedima]

Ich kann mir nicht vorstellen, dass der RPI hier das Problem sein soll.

@d2z
- Wie ist der emmcache eingestellt?
- Bei Verwendung von emmcache 0,0,0,0 werden bei dir dann noch Shared-EMMs geskipped?
- Welche oscam Version hast du auf welcher Kiste laufen?

 

[d2z]

Mein alter Server ist ein Igel 5/4 oder so, Oscam 11420.
emmcache = 1,1,2,0
Schrieb problemlos die Shared Emms.

Habe seit einer Woche ca. einen neuen Server, einen Dell Optiplex 740 mit Oscam 11424.
Gerade Mal nachgesehen, habe vor zwei Tagen neu gestartet, seit dem wurden die shared Emms nur geskipped.
Muss mal beobachten, ob sie dort auch geschrieben werden.