Dies ist eine mobil optimierte Seite, die schnell lädt. Wenn Sie die Seite ohne Optimierung laden möchten, dann klicken Sie auf diesen Text.

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

@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
 
Zuletzt bearbeitet:
Dazu musst Du wissen, in welcher Sprache es kompiliert worden ist.
Versuch macht klug. Ich bin da nicht der Experte.

MfG
 
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
 
gib dir recht tweety
 
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.
 
Moin Receivermaxe WR auch eine Zeit nicht so oft ihr .....
So wie es aus schaut ist da nix zu machen
 
Das, was alle suchen ist da nicht drinnen. Der Weg zum gesuchten ja, aber das gesuchte nicht...
 
Seit heute morgen ist wieder licht am Ende des Tunnels
 
Das, was alle suchen ist da nicht drinnen. Der Weg zum gesuchten ja, aber das gesuchte nicht...
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
 
Und dein Spam hat was genau mit dem Topic ECM Aufbau zu tun? Kann hier mal einer aufräumen bitte?

-supraracer
 
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!
 
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…