Ecm Aufbau Erklärung Und Nds Status Byte Meldungen Der V13/v14 Karte

Hallo Leute,

da hier recht wenig über die Status Meldungen oder über den ECM Aufbau geredet wird, man vielleicht sogar wenig darüber weiß, werde ich euch hier mal etwas mehr im Thema NDS aufrischen.

Was ich euch hier zeigen werde sind, von mir und anderen, Informationen die für das weiter lernen vom Pairing sehr hilfreich sein können.

ECM Struktur:

Wie vielen schon bekannt ist, gibt es verschiedene ECM Längen, dennoch aber immer eine Struktur. Diese sieht folgendermaßen aus:

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Der Nano Killer wird in manchen Ländern eingesetzt und bringt die Karte in einen Error status, diese entschlüsselt dann garnichts mehr und muss ausgetauscht werden. Bekannte Länder sind: Italien, Indien und China


NDS Status Byte Meldungen:

Wer nicht weiß was die SW Status Meldung ist, das ist die Meldung der Karte ob:

Eine INS,EMM richtig/falsch geschrieben worden ist,
Filter geschlossen oder geöffnet sind,
IRD Flags gesetzt worden sind oder nicht
und ob das EEpromgeupdatet worden ist oder nicht.

​

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Das sind die bis jetzt mir bekannten Status Meldungen und die aktuelle ECM Struktur.

Um mal kurz noch die Zukunft vorher zu sagen.

NEXT STEP FROM SKY:

Es wird der Descrambler Aktiviert, dies schneidet dann alle Karten aus, die noch für CS oder bessergesagt unsere Publik EMUs funktionieren.

Dieser verändert das Standard Decrypt in ein Provider gebundenes Decrypt. Dazu wird der oben genannte null byte in der ECM einen Wert bekommen der dem Descrambler übergeben wird, dieser weiß dann wie er fortzufahren hat.

Wer weiß vielleicht wurden genau aus diesem Grund die ECM Verlängert.

Lösungen hierzu?

Sky Hardware studieren, auslesen, EMUs anpassen.

Ist alles schwerstarbeit und braucht viel Wissen um wirklich etwas damit anzufangen.

So das wars von meiner Seite aus, hoffe ich kann hiermit einigen einen kleinen Einblick verschaffen und vielleicht allen daran arbeitenden etwas mehr Wissen vermittelt haben.

Grüße

amassidda

 

[HarryHase]

Ultraedit zum Beispiel kann gut mit binären Dateien umgehen.

 

[esel08]

@Derek Buegel

Kann man das bin file nicht decompilieren ?
Bei C++ wäre doch wenigstens disassemblieren drin und man würde Assembler Code bekommen.

Grüße Jens

 

[Derek Buegel]

Dazu musst Du wissen, in welcher Sprache es kompiliert worden ist.
Versuch macht klug. Ich bin da nicht der Experte.

MfG

 

[Fourty2]

Files sind Linux-ELF, CPU: MIPS, Little Endian, 32 Bit.
Compiler war GCC: (GNU) 4.2.0 20070124 (prerelease) - BRCM 8ts-20080520

Man nehme RetDec (Online), Snowman (mit MIPS Support) oder RecStudio.
Die Assembler-Fans nehmen IDA Pro (ggf. mit Snowman-MIPS Plugin)
Das "File of Interest" wäre /NDS/bin/C...

Leider bräuchte $"gearschter Kunde" die etwas sparsamer getaufte neuere Version.
Aber zum Selbststudium, wieso nicht...

42 +/- 1

 

[dia]

gib dir recht tweety

 

[djnemo]

ok

 

[ReciverMaxe]

Hallo
so habe mich hier mal ganz neu angemeldet, da ich einige Fragen habe. Bin leider auch so ein Pairing Opfer, aber vielleicht kann ich ja doch etwas beitragen, zum Thema Firmware. Also ich habe die Firmware vom Pace TDC866NSDX Version 1.3.4 vom 7.Sept. 2015.
@Fourty2 Du meinst wahrscheinlich die /NDS/bin/CA_Process Datei oder?
Wo könnte man denn in dieser Datei was interessantes finden?
So weit ich das jetzt auf die schnelle im Dissasambler überblicke ist das nur der Userspace Teil, der das Kernelmodul vom Kartenleser überwacht und steuert.... ist aber auch nur eine Vermutung in blaue.
Ich hatte mich bis jetzt immer auf die /lib/modules/2.6.18-7.4-brcmstb/reader_TDC866NSDX.ko konzentriert.

 

[djnemo]

Moin Receivermaxe WR auch eine Zeit nicht so oft ihr .....
So wie es aus schaut ist da nix zu machen

 

[Tweety_2000]

Das, was alle suchen ist da nicht drinnen. Der Weg zum gesuchten ja, aber das gesuchte nicht...

 

[djnemo]

Seit heute morgen ist wieder licht am Ende des Tunnels

 

[ReciverMaxe]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Da bin ich der Selben Meinung. Wenn S*y es uns soo einfach gemacht hätte, dann hätte das Pairing bestimmt niemals soo eine Welle geschlagen ;-)
Aber irgendwo muss man ja auch mal anfangen oder?
Und dabei ist es natürlich nicht zielführend, zu sagen was NICHT da ist, besser wären weitere konstuktive Vorschläge, worauf man sich konzentrieren sollte.
@Tweety_2000 wäre cool zu erfahren, wenn Du etwas weißt, was wir noch nicht wissen

 

[supraracer]

Und dein Spam hat was genau mit dem Topic ECM Aufbau zu tun? Kann hier mal einer aufräumen bitte?

-supraracer

 

[kautz8953]

Ich glaube das sich da wer verirrt hat oder

 

[djnemo]

Klar

 

[Miese.Ratte]

Geiler Thread, wenn man mal von dem unsäglichem seuchenartigem OT-Geblubber absieht.

Es fliegt hier viel von Spekulationen über den Einsatz von AES herum. Das kann durchaus sein, aber nicht so!

Warum?

AES ist eine Blockchiffre. Die arbeitet mit 16-Byte-Blöcken. Es gehen 16 Byte und der Key rein. Raus kommen wiederum 16 Byte. Das gilt für beide Richtungen.

Beim Verschlüsseln kann man kürzere Daten wie z. B. das CW einfach auffüllen ("padding"). Zum Entschlüsseln braucht man aber den kompletten 16 Byte langen Chiffre-Block. Krümmt man auch nur einem Bit ein Haar, kommt kompletter Salat raus. Das ist der Gag an einer guten Crypto.

Ein CW hat aber nur 8 Byte. Will ich das in AES verschlüsselt ausliefern, muss ich 16 Byte Chiffre anschleppen und nicht nur 8. Da steckt der Hase im Pfeffer. Wo sind die restlichen 8 Byte?

Die normale Payload einer INS 54 schleppt selbst nach INS 7E auch für eine "gepairte" V14 nicht genug an. Entweder ist es kein AES oder die restlichen 8 Byte werden woanders her beschafft. Dann steht die Frage: Woher?

Beim Astrokey z. B. kommen die restlichen 8 Byte aus dem Tag 56. Das gibt es aber bei SkyDE nicht und es gibt auch kein anderes Tag, das infrage kommen könnte.

Quintessenz: Mit einem solo 8 Byte CWE kann das nicht klappen!

Sehr wundersam erscheint auch der angebliche Code für Viasat (

Du musst dich Anmelden oder Registrieren um diesen link zusehen!

). Da steht an der Chiffre einfach schnöde "cw" dran. Ohne konkreten Kommentar sind das nur 8 Byte. Das wird so nichts!

Weiterhin geistert die Behauptung herum, dass das Tag 90 der EMMs mit AES verschlüsselt ist. Auch daraus wird nichts. Sonst müssten die EMM-Längen um ein Vielfaches von 16 Byte springen. Das tun sie aber bekanntlich nicht. Also nix AES! Das kann nur eine Stream-Chiffre sein.

Ansonsten: Geiler Thread. Danke!