Laberthread - Alphacrypt R2.2 = Maxcam bzw. Unicam bzw. Oxacam oder alles ist Xcrypt

Fragt sich nur, ob Herr Gruber Xcrypt ist oder ob er quasi als letzten Deal seine Alphacrypt-Firmware an die Xcrypt-Hardware angepasst hat und es deshalb diese R2.2 Module gibt.

Die Seriennummern sind jedenfalls Fake, denn

Original Alphacrypt R2.6 hat z.B. 1131 0947 4 xxxxx und ist von SmarDTV bzw. SCM hergestellt. 1131 ist der Platform Typ der Hardware, 0947 das Produktionsdatum und 4 die Factory, die letzten Ziffern sind die eigentliche Seriennummer
Original Alphacrypt R2.4 hat z.B. 1131 0835 4 xxxxx und ist von SmarDTV bzw. SCM hergestellt.

Alphacrypt R2.2 hat z.B. 1131 1001 4 xxxxx und ein anderes Gehäuse. Wenn es Ende 2009 schon die Revision R2.6 und im Herbst 2008 die R2.4 gab, wird es wohl kaum Anfang 2010 noch eine R2.2 in der Produktion gegeben haben.

Ist alles Fake ! In den ganzen Modulen Steckt immer der XCrypt "Capella" Chip. Der düfte so ziemlich in allen aktuellen "Piraterie"-Cams zum Einsatz kommen.

Ich bin ja mal gespannt, ob Fanlashtic da tatsächlich etwas released um die Module für 64-Bit CW fit zu machen.

Jedenfalls steht nun fest, dass die Hardware nicht der limitierende Faktor ist, sondern man wohl lediglich den Xilinx XC9572XL CLPD über die Kontakte auf dem Board mit der geeigneten Software beschreiben müsste. Die CPU enthält definitv keine hartverdrahteten DVB-CSA Logiken. Ansonsten ist da nur ein EEPROM, ein Flashspeicher und ein SDRAM auf dem Board.
-------------------------------------
"-Viaccess Standard-Overcrypt unterstützt - Auswahl per VIAx_DEFAULT - aber beachte, die R2.2 Hardware unterstützt keine 64Bit CSA Verschlüsselung !"

Vermutlich haben die Macher der One4All 2.50 durch diesen Hinweis im Changelog (evtl. sogar absichtlich) Sky erst auf die Idee mit den 64Bit CW gebracht.

Ich glaub es geht eher um den 144 pinner zu ersetzen bzw. ein Kintex.

Fanlashtic schreibt ja, dass der Xilinx für CSA zuständig ist. Der 144-Pin Chip ist eine NXP-CPU. Die Firmware darin bzw. im Flash hätte man auch per Flash-Update für 64Bit fit machen können. Aber vermutlich ist die Logik im Xilinx so proprammiert, dass er mit 48Bit gefüttert wird und die 2 x 8Bit per CRC selbst berechnet. Der Aufwand sämtliche Module einzusammeln, das Gehäuse zu Öffnen, den Xilinx neu zu programmieren und dann eine neues Gehäuse zu montieren, ist vermutlich unwirtschaftlich. Deshalb verkauft man in Kürze lieber neue (alte) Module.

Das Gehäuse so lassen und ein Stück ausfräsen ginge auch.

Sieht nur beim Endkunden nicht so toll aus...
----------------------
By the way - Fanlashtic hat, wenn man sich so seinen Blog ansieht, wohl die Möglichkeit des Hardware Reengineerings bei Chips - könnte wirklich spannend werden.

Kaum veröffentlicht jemand zusammengesammelte und bekannte Infos, schon spielt die Welt verrückt. :blush:

Die Betonung liegt auf veröffentlicht.

Wenn er jetzt noch die CPU aufmacht und deren internen Flashspeicher ausliest, kommt endlich wieder Bewegung in die Sache.
-------------------------------------
@ Fanlashtic: Danke fürs Update - aber mit der ID und Google finde ich da nur 2 Bilder und einen PCMCIA-Treiber

Könnte das Datasheet sich evtl. noch mal ins Netz verirren? ;-)

Und hast Du einen Hint für die SmarDTV-Module - Stichwort Firmware in IDA wg. E-CWPK für CAK6 (Unity) und CAK7 (KDG)?

Schade das auf der Seite nix neues mehr kommt... :-(

Na ja, erst hat er eine Paywall eingerichtet - um sie dann nach ein paar Tagen wieder zu entfernen. Für das was er bis jetzt anbietet, kann er nicht wirklich Geld erwarten. Da muss mehr kommen - z.B. wie reverse ich ein SMiT und ein SmarDTV Cam.

Nette Decap-Photos und ein paar Postings mit dem Inhalt "Ich weiß was, aber sage nichts genaues" reichen dafür nicht.

Bei anderen Sachen liegt er auch falsch: Die 64-Bit CWs scheitern nicht an der alten CPU. Er hat recht, wenn er sagt, dass die 64-Bit CWs von der Karte kommen. Aber danach verwirft die Firmware die letzten beiden Bytes und ersetzt sie durch den "CRC"-Wert über die ersten drei Bytes. Man müsste also nur eine Funktion aus dem Code entfernen, also kann es kein entweder oder sein. Es liegt auch nicht am AES-Algo. Denn den konnte das "Alphacrypt" R2.2 (Changelogauszug O4All 2.5: Overcrypt Algoritmus: (3)DES oder AES müssen nicht vorgegeben werden, dies wird automatisch erkannt.).

Update: Nun macht er ein Nickerchen über den Sommer. Die Kritik scheint ihm nicht so gut bekommen zu sein.