http://satellite-board.de

..es gibt ein neues Update auf Version 4.71SE.
Dadurch können nun auch die Premiere Karten S01 und S02 im Irdeto Cam gelesen werden.

Dr.Brain

Ja was denn nun, SE4.71, SE4.7N, SEN4.7 ? Verschiedene Dateinamen, pahhh, nur ein Byte soll geändert sein, das ich nicht lache. Spielt euch das ruhig ein, ich warte lieber noch. Mich erinnert das alles an den berühmten Lizenz-Error. Der tauchte genau pünktlich zusammen mit dem offiziellem Update auf. An solche Zufälle glaube ich nicht mehr.

..hm...sicherlich kann man nicht vorsichtig genug sein !
Aber die Quelle würde ich als "vertrauensvoll" bezeichnen !

Einige, die ich persönlich kenne, haben den 4.71SE bereits drauf und es funzt.

Ob ein "Timer" nun drinne ist, kann man noch nicht 100% sagen... es RESTRISIKO gibt es.

Das Ganze passt doch in das Bild der letzten Jahre!

Irgendwo gibt es was Neues. Gerüchte kursieren.
Erste 'Versionen' tauchen in den BadLands auf.
Die gierigsten Lemminge lutschen die Sachen runter ...
(Es sind aber nicht immer die Erwarteten)
Die wildesten Spekulationen kreisen durch den Brutzelwald.

Nach einiger Zeit gibt es, auch wie immer, verläßliche Informationen mit Hinweisen auf sichere Quellen, weil es erfahrene Leute gibt, die sich diese 'Angebote' nicht blind auf ihre Hardware jagen, sondern über passende Werkzeuge verfügen und die auch noch sinnvoll einsetzen können.

Also was soll der Streß, nur weil mal kurzfristig eine Abo-Karte nicht in jedem verfügbaren Schlitz funktioniert?

Janus

edit: syntax

Wenn man das eine Byte in einem sicheren alten 4.7er Image selber ändert gibts eigentlich kein Risiko bezüglich einer Timebomb. Einfach mal einen Hex Vergleich zwischen einem normalen 4.7 Image und dem modifiziertem Image machen. Dann sieht man schnell welches Byte geändert werden muß.
Eine Checksumme oder ähnliches muß nach der Änderung im Image nicht angepaßt werden, da es keinen Check gibt.

Wobei sich allerdings eine geänderte Versionsangabe im Cam-Menü auch nicht schlecht macht...

Janus

In allen Versionen die ich bisher gesehen habe war eigentlich nur dieses eine Byte geändert und die Versionsnummer (4.71SE, 4.7SEN ...). Sonst wurde aber eine Zeile ganz am Ende noch geändert, in allen Versionen gleich (0x3c000). Die Bombe müßte mehr Code haben (?), hat Jemand eine Version mit Bombe zum Vergleich?
mfg Oli

@Janus: Strings tauschen kann doch jeder. So mach ich dir locker aus einem 4.7SE ein 5.0SE

Aber bitte anschließend breitgestreuten Upload nicht vergessen!

Wegen der Hall Of Frame! Oder war es die Hall Of Flame?
Egal - Du weißt schon, da wo die Berühmten alle an der Decke hängen...

Janus

edit vergessen @oli: Letzte 'Zeile' ist die von Lostech schon erwähnte CheckSum (daher zwar anders, aber irrelevant)

noch vergessen: Zur Bombentheorie
Was passiert eigentlich, wenn ein Brutzelkaiser zu Beginn des bin-Files den HexEditor im Insert-Mode benutzt, um aus einem 4.7 se ein 4.71 se oder ein 4.7 sen zu machen?
Jou => unpredictable result.
Die eine oder andere Sprungadresse wird sicherlich nicht in der vorgesehenen Grube enden. Wäre doch vielleicht ein möglicher Ansatz. Hätten wir die Bombe schon entschärft.

An eine Checksumme dachte ich auch, aber in den Verschiedenen Versionen war die 0x3c000 gleich auch wenn unterschiedliches geändert wurde (Strings).
mfg Oli

Bei 0x3C003 wurde wirklich einiges geändert, das ist aber meiner Meinung nach nicht die Checksumme. Das ist möglicherweise irgendein Identifikationsstring ("DV...." -> V kommt im hexadezimalen System nicht vor) oder etwas das vom Compiler herrührt.
Eine Checksumme hat glaube ich wie gesagt das Image nicht. Die Checksummen wurden früher nur bei der IRD106.EXE im Konfigurationfile für das Image abgelegt und nicht im Image selber, so daß im Prinzip nur das Update Programm die Checksummenüberprüfung durchführt und nicht das Modul.
Da das Image immer exakt 256kB groß ist dürfte es sich hierbei um einen kompletten FLASH Dump handeln und nix großartiges was irgendein spezielles Format darstellt mit Checksummen, Offsets, Längenangaben etc.
Anscheinend hat auch das alte IRDETO Modul auch keine richtigen FLASH Programming/Loader Routinen, denn sonst könnte man es eigentlich nicht verflashen. Für mich siehts aus, als ob es direkt an den entsprechenden Adressen im FLASH programmiert wird ohne irgendwelche Überprüfungen. Das Modul lädt höchstens bei der Initialisierung eine kleine Routine in den RAM, die halt den den FLASH direkt programmieren kann und wenn man diese Routine in der Ansteuerung abändert kann man sie nicht mehr aufrufen und das Modul wird verflasht. Da kann man die Timebomb ansetzen lassen. Wenn ich mich Recht erinnere gabs damals für die verflashten 4.6er ein entsprechendes Repair Image bzw. Tool, das dem Rechnung getragen hat.

Bei 0x72E2 müßte auf jedenfalls das entscheidene Byte 0x46 sitzen. Nur ist mir nicht klar warum alle Welt davon spricht, das nur ECMs bis zu einer Länge von bis zu 47 Bytes durchgehen, denn 0x46 ist eigentlich 70 dezimal....

BCD *gg*

Janus

Binary Coded Decimal!?
Wäre ne Möglichkeit obwohl sowas ja eigentlich Speicherverschwendung wäre A bis F nicht zu nutzen...
Deswegen setzt doch sowas niemand mehr ein.

Als ANSI gibt es das V aber schon Meiner Meinung nach ist das ein String!

Binary Coded Decimal!? kommt schon sehr häufig vor, manchmal braucht man nur 99 und das Umwandeln kostet mehr Code. Wobei dann das ändern in 0xFF ausgemachter Blödsinn wäre!
mfg Oli