Grundsätzlich prüft (soweit ich das lesen und beurteilen kann) Oscam vor dem schreiben ob die EMM länge mit der echten EMM länge übereinstimmt. Sonst wird verworfen.
ja welches Byte nimmt dafür oscam zu grunde? wenn es das erste - also in dem fall die 9c - nimmt, dann stimmt es ja, das gesamte EMM is genau ab dem 9c 156 bytes lang. wenn das die einzige prüfung ist und oscam dann schreibt schreibt es ja vermutlich das gesamte emm.
Für MICH sieht es im Code so aus als ob Oscam das komplette EMM schreibt, denn im DVB api wird die länge des EMM durch ermitteln mit "size of" gesetzt. Was wohl passieren würde wenn man den überflüssigen quatsch hinter der im EMM angegeben länge wegschneidet und auf eine Karte bügelt.
Im prinzip ja, aber wundert mich 0xA3 ist die gesamtlänge des EMM inkl. aller Header vorne dran (82 70 ...). Ich hätte erwartet dass die Karte selbst eigentlich nur die Payload bekommt, also das nach der Seriennummer oder nach LL 90 LL :emoticon-0138-think
Für MICH sieht es im Code so aus als ob Oscam das komplette EMM schreibt, denn im DVB api wird die länge des EMM durch ermitteln mit "size of" gesetzt. Was wohl passieren würde wenn man den überflüssigen quatsch hinter der im EMM angegeben länge wegschneidet und auf eine Karte bügelt.
Man sollte jetzt aber dazu vielleicht mal jemanden fragen der sich im Oscam auskennt und noch ein paar debugs einbaut. Dann könnte man sogar ohne zu echt zu schreiben sehen was an die Karte übertragen werden würde.
Bei der V13 scheint derselbe Fehler aber nicht zu stören:
2016/05/29 17:44:04 0000000000000000 8270A00102009C90206002 [..] 34
2016/05/29 17:44:05 0000000000000000 8270A00102009C90206001 [..] 88
Die sind im global zu finden und kamen im unique Format letztes Jahr schon zu der Zeit wo ich das F0 erhalten habe. Hab die aber nicht geschrieben seinerzeit...
Das müßte aber eine Zweikompontenen-Bombe sein, denn der A0 wirkt ja auch im Orig-Rec geschrieben, und bleibt uns mit seinen Problemen erhalten. Korrekt?
Man sollte jetzt aber dazu vielleicht mal jemanden fragen der sich im Oscam auskennt und noch ein paar debugs einbaut. Dann könnte man sogar ohne zu echt zu schreiben sehen was an die Karte übertragen werden würde.
Da ist der Code der das EMM schreibt... Ist leider nicht so selbsterklärend wie ich mir das vorstelle
Die variable "offs" beschreibt einen offset ab dem das EMM geschrieben wird. Ich blick nur nicht ganz durch auf welchen Wert die am ende steht Aber ich denke >0 ... ich denke schon dass der Header vorne abgeschnitten wird bevor es an die Karte geht... Ist da jemand tiefer drin?
also eigentlich bröuchte man nun jemand der weiss wie oscam tickt und ob hier mehr als nur die erste "Zählernummer" kontrolliert wird
mal noch was anderes: kann auch sein dass die softwareprogrammierung noch in einem anderen global steckt? dass zb die shy hardware aufgrund des falschen rest-byte zählers den A0 gar nicht verwertet, und das nur ein Oscamproblem ist das der geschrieben werden kann ? quasi: n trojanisches pferd?