Open Source Software (Linux-Kernel) im LCD

Okay. Supi. Da der Aufbau der Anfangsdaten (Main-Header) ebenfalls little-endian ist und phlps wohl nicht 2 endians in einer datei vermischt und ausserdem ihr beide meint bzw. rausgefunden habt, dass die CPUs auf little laufen, halten wir das "little" mal so fest. ^^

Das heisst wir suchen 85h 19h. Überlicherweise folgt danach 03h 20h (Das ist aber KEIN Kriterium!)

Das heisst in FW .14.18 müssten aus 3A44C7F4590EA0D12E65A5B12E678F6D
irgendwie
8519xxxxxxxxxxxxxxxxxxxxxxxxxxxx
werden. Wenn wir Glück haben und der Key ist wirklich innerhalb 220h-2DCh. Haben wir Pech ist er in der Hardware verankert oder mitten im Byte-Wirrwarr. Vielleicht ist der Key aber auch an der Stelle von DWORD 4.
Was unwahrscheinlich ist möchte ich auch mal festhalten: Der Key könnte sich aus dem Dateinamen selbst errechnen lassen. (Unter 5% Wahrscheinlichkeit)
Der Key kann auch nicht in der alten FW sitzen, da von jeder FW auf jede geupdatet werden kann...

Ich werde ein Script schreiben, was die Bytes durchgeht und als Key benutzt. Die Keylänge ist zwar nicht bekannt, aber ich denke mal der wird auch nicht so lang sein. Immerhin wissen wir, dass das Produkt 128-Bit produziert.
Werde wahrscheinlich PHP benutzen, weil's schneller zu proggen ist. Der Geschwindigkeitsvorteil durch Delphi, C, Java würde die mehr investierte Zeit nicht rausholen können oder gibt's da schon was?

Sieht einer eine Möglichkeit irgendwas über die UART einzuschleusen ohne gleich den Fernseher zu schrotten? Z.B. irgendetwas, was beim mounten den Key mit ausspuckt. --verbose scheint's ja schon zu sein...

Aber warum mountet der so viele Images? Hat jemand eine Erklärung dafür?

Weiterhin wären die Hexes von 220h bis einschliesslich 2EBh der einzelnen Firmwares sehr vorteilhaft:
bei .18 (9732d) isses:
3C527A5A5F0BE28B3694E5DBD2F0E43F
C25D50E424D54D64953F061B77FF78A9
43C141ABB71BF7FA1F07A1DBE409699D
1291F40F9D6AFC7F9F606AFD1A0ED8F8
7EE60B693774A6C4A2598E083DB46CC2
C22AC2C6F3ABDC96DAA22240F2CC9A61
FDC5B45C7C46ACC8B019B744F193D78A
0B6F52293D98E6A5905D5D518BC83326
E65C8E6BE9E095DD3C2C24132BE99022
49ECAD9AB766365AA25B6FA90E560882
51353831452D302E36342E31342E3138
5F636F6D6D65726369616C003A44C7F4
590EA0D12E65A5B12E678F6D

habe leider diesen block von der 17er nicht. würde den aber vorziehen, weil wir da schon das verbose vom update haben.

Grüße

Hmm. Also ich hab das PHP-Skript geschrieben. Es probiert die 16 Bytes nach 2DCh mit 2 bis 32 zusammenhängenden Bytes von 220h bis 2C0h als Key zu decrypten.

Ich habe alle 128-bit-fähigen Algorithmen durchprobiert.
(cast-128 gost rijndael-128 twofish loki97 saferplus blowfish-compat des serpent xtea blowfish rc2 tripledes)
Leider hat keiner gematcht mit 85 19. Bzw. hat jede der 3 probierten FWs anders gematcht... bei einer war's Twofish, bei einer kam 2mal rc2 und bei der dritten gar nix... Also alles zufällig bis jetzt. :-(

Dafür kann ich jetzt definitiv sagen, dass eine 128-Bit-Blockchiffre vorliegt! Darauf verwette ich meinen Hintern. Im DWORD 4 steht wirklich die Länge. Es sind aber 0-15 Bytes mehr vorhanden, da immer auf 128-Bit gerundet werden muss.

Ein Savegame wird nicht gehen :D, aber im Netzwerkmodus geht sicher was. Das Teil ist mir schon 1 oder 2 mal abgestürzt wenn was mit den Videodateien nicht gestimmt hat.
Dafür wär's natürlich besser den Code zu kennen...

Ich würde jetzt mal erwarten, dass Philips die Firmware mit einem PrivateKey verschlüsselt und in den Geräten ein PublicKey zu entschlüsseln ist.
Sollten die wirklich den Key im Header mitliefern wäre das sehr fahrlässig...

Hatte nicht mal wer gesagt, man kann über das UART ne cmdline aufrufen oder so irgendwie?

ne commandline nicht. im opensourcepack sieht man bei das cmdline nicht geht.
aber warscheinlich kann man ein binary vom stick ausführen siehe weiter oben - stichwort "jettfiles".
das geht warscheinlich nur bei den neuen modellen.

atzplzw schrieb:

Ich würde jetzt mal erwarten, dass Philips die Firmware mit einem PrivateKey verschlüsselt und in den Geräten ein PublicKey zu entschlüsseln ist. Sollten die wirklich den Key im Header mitliefern wäre das sehr fahrlässig...

Stimmt, das wäre es. Dann hätten wir jetzt auch schon den Key. Naja... Ich hatte auch gehofft, dass ähnlich wie beim TomTom der Key symmetrisch ist (und auch in der Datei steht). Okay.. da war alles ein bissl anders.

Leider hat der 9732D keinen Netzwerkanschluss wie der 9703D. :-/ Aber wenn ein Portscan auch schon nix hervorgebracht hat, dann ist zu mindest das Break-In meiner Meinung nach unmöglich. Oder kennst du eine Attacke atzplzw?

Der logische Schritt wären wohl wirklich die jettfiles (noch nie gehört...)

p)(d sagte, dass im service manual steht: “MemoryTestPNXxxxx.bin” und “autojett.bin” hinein kopieren.
Reicht es, wenn wir die komplett selbst kompilieren oder muss da eventuell auch schon irgendein bestimmtes Format vorliegen? Naja... Werde mich dann mal ranmachen den Stuff zu besorgen für's crosscompiling

Grüße

Wollte nur noch schnell schreiben, dass die 5 Partitionen in der pnx8550.c beschrieben sind im verzeichnis
linux-2.6.10_mvl40x-patchlevel-956\drivers\mtd\nand\

ich geh erstmal schlafen. n8 ^^

Savegames hat der TV zwar (noch;)) nicht, aber eine Channellist, die man auf usb up und downloaden kann. => http://www.hifi-foru...m_id=152&thread=3034

ich habe mir eben bei ebay einen D-Link DUB-E100 USB 2.0 Fast-Ethernet Adapter bestellt.

Laut doku sollte das von der tv520/20 plattform unterstützt werden, IP bezieht er dann wohl über DHCP - mal sehen...

Wenn die Unterstützung in der Firmware noch vorhanden ist, dann sollte es wohl gehen...

wie sieht denn ein image file von einem jffs aus? kann man das anhand der ersten bytes erkennen?

ich habe mir nochmal gedanken um die verschlüsselung des autorun.upg gemacht. es kann definitiv kein aes/des/fish/usw. sein. innerhalb des files kommen zu viele wiederholungen vor. die wiederkehrenden bytesequenzen sind immer 16 bytes (oder vielfaches)

beispiel anhand der firmware 000.064.014.018:

bytefolge: 9F D9 CB 70 A8 AD 78 D0 66 B3 B6 91 89 43 86 D5=> 33 wiederholungen
startadressen:
0000050c 0000056c 0000057c 0000063c 0000067c 0000069c 00000aac 00000abc 00000b0c 0000296c 00002a5C 00002a6c 00002a7c 00002a8c 0040adac 0040adbc 00621ecc 00621eec 00621efc 00621f0c 0183042c 0183043c 0183044c 01834ebc 0183b96c 0183b97c 0183b98c 018e223c 018e224c 018e225c 01950d6c 01950d7c 01950d8c

bytefolge: 05 3A 51 0B 42 16 D7 DD 17 48 FD 1F 03 3C 1A 56=> 11 wiederholungen
startadressen:
000006dc 000006ec 000012fc 0000130c 0000131c 0000138c 0000139c 000013ac 0182f57c 0182f5ac 0182f60c

bytefolge: 4B F1 76 14 16 22 A1 B9 B4 9E 6C AE 68 CE 23 B2=> 28767 wiederholungen

ich habe noch viele weitere wiederkehrende sequenzen entdeckt.


beispiel anhand der firmware 000.064.014.017:

bytefolge: A6 4F 00 9F 70 B1 58 F7 2D C9 30 A9 0A 86 E5 FC=> 33 wiederholungen
startadressen: die ersten 20 startadressen sind identisch zu der ersten bytefolge von 000.064.014.018, die letzten 13 startadressen sind etwas verschoben.


das ganze spiel mit den positionen von wiederkehrenden bytesequenzen kann ich auf allen firmware versionen erkennen.

ich schlussfolgere hieraus, das die verschlüsselung nur ein einfacher algo sein kann.
möglicherweise doch ein 16 byte xor - evtl in kombination mit anderen ersetzungen.

falls jemand noch firmwares miteinander vergleichen will - hier im forum ging schon mehrfach eine download liste herum:

http://rapidshare.com/files/115874622/000.059.019.000.rar
http://rapidshare.com/files/115874625/000.059.028.000.rar
http://rapidshare.com/files/115891685/000.059.031.000.rar
http://rapidshare.com/files/115891687/000.064.014.004.rar
http://rapidshare.com/files/115891689/000.064.014.006.rar
http://rapidshare.com/files/115903153/000.064.014.011.rar
http://rapidshare.com/files/115903154/000.064.014.014.rar
http://rapidshare.com/files/115903155/000.064.014.015.rar
http://rapidshare.com/files/115903156/000.064.014.017.rar
http://rapidshare.com/files/115906003/000.064.014.018.rar

p)(d schrieb:

wie sieht denn ein image file von einem jffs aus? kann man das anhand der ersten bytes erkennen?

Ja! Wie ich schon geschrieben habe, MUSS ein jffs2-Image bei little-endian mit 0x85 0x19 anfangen! (Das sind die Magic Bytes) Jedes weitere INode fängt ebenfalls mit 0x85 0x19 an. Der Aufbau des jffs2-Headers ist simpel und steht komplett beschrieben in
linux-2.6.10_mvl40x-patchlevel-956\include\linux\jffs2.h

Auszug:

struct jffs2_raw_inode { jint16_t magic; /* A constant magic number. */ jint16_t nodetype; /* == JFFS_NODETYPE_INODE */ jint32_t totlen; /* Total length of this node (inc data, etc.) */ jint32_t hdr_crc; jint32_t ino; /* Inode number. */ jint32_t version; /* Version number. */ jmode_t mode; /* The file's type or mode. */ jint16_t uid; /* The file's owner. */ jint16_t gid; /* The file's group. */ jint32_t isize; /* Total resultant size of this inode (used for truncations) */ jint32_t atime; /* Last access time. */ jint32_t mtime; /* Last modification time. */ jint32_t ctime; /* Change time. */ jint32_t offset; /* Where to begin to write. */ jint32_t csize; /* (Compressed) data size */ jint32_t dsize; /* Size of the node's data. (after decompression) */ uint8_t compr; /* Compression algorithm used */ uint8_t usercompr; /* Compression algorithm requested by the user */ jint16_t flags; /* See JFFS2_INO_FLAG_* */ jint32_t data_crc; /* CRC for the (compressed) data. */ jint32_t node_crc; /* CRC for the raw inode (excluding data) */ uint8_t data[0]; } __attribute__((packed));

p)(d schrieb:

ich habe mir nochmal gedanken um die verschlüsselung des autorun.upg gemacht. es kann definitiv kein aes/des/fish/usw. sein. innerhalb des files kommen zu viele wiederholungen vor. die wiederkehrenden bytesequenzen sind immer 16 bytes (oder vielfaches) ... ich habe noch viele weitere wiederkehrende sequenzen entdeckt. ... das ganze spiel mit den positionen von wiederkehrenden bytesequenzen kann ich auf allen firmware versionen erkennen. ... ich schlussfolgere hieraus, das die verschlüsselung nur ein einfacher algo sein kann. möglicherweise doch ein 16 byte xor - evtl in kombination mit anderen ersetzungen.

Das habe ich schon beschrieben. Ich kann es aber gerne nochmal detailiert erläutern (im Klartext ^^).
Das jffs2-Image ist extra für Flash-Speicher geschrieben worden. Das Problem ist das solch ein Chip mit gesicherter Qualität nur eine bestimmte Anzahl oft beschrieben werden kann.
Deswegen wurde das Dateisystem jffs(2) so angelegt, dass das selbe Byte des Speichers so wenig wie möglich oft geändert wird. (Könnte ich noch weiter erklären, aber ihr könnt es ja erstmal so hinnehmen)
Das, was daraus resultiert ist, ein erstmal komisch erscheinendes Bytemuster in den einzelnen Speicherzellen. (Ob jffs2 jetzt in eine Datei angelegt wurde oder direkt auf der Festplatte als Partition existiert, die Bytes auf die man zugreift, sind die Gleichen)
Das "komische" Bytemuster ist eine pro Datei wiederkehrende Folge von 4 Bytes, wenn gleiche Bytes gespeichert werden.
Also noch einfacher erklärt: Wenn ein Platzhalter in der Datei oder eine Datei mit x aufeinanderfolgenden Nullen (0x00) oder 0xFF angelegt/gespeichert wird, dann sieht das physikalisch ungefähr so aus: 4D0E3393 4D0E3393 4D0E3393 4D0E3393. (Oder halt ein anderes Bytemuster, was sich aber immer nach 4 Bytes wiederholt!)

So. Wir sehen jetzt aber keine 4 Bytes, sondern 16 Bytes.

Die Erklärung dafür ist, dass ein 128-bit Blockchiffre-Verschlüsselungssystem über diese Bytes gezogen wurde! Klingt erstmal komisch, aber man muss sich vor Augen führen, dass IMMER 16 beliebige aufeinanderfolgende Original-Bytes zu 16 verschlüsselte Bytes resultieren.
Hier Beispiele, damit du genau verstehst, was ich meine:
Wir haben einen Block mit 16 Bytes, der (in hex) so heisst:
FC03BEBF C78BF968 204BBBDB 519E169B
dieser würde jetzt mit einem Key zu bspw. folgendem resultieren:
3837F001 72F2FB46 8A11FB6A 78A8941D
Falls jetzt der nächste oder übernächste Block wieder GENAUSO aussieht (FC03...), dann würde wieder (3837...) der verschlüsselte Block sein. Sobald aber irgendwas anders ist,
also bspw:
FC03BEBF C78BF968 204BBBDB 513E169B
wäre ein KOMPLETT anderer resultierender Block zu sehen:
D22BDBFA 770BEF3F F521627D 25A4D705
Diese über 28000 gleichen 16-Byte-Blöcke sind als (logischerweise) Platzhalter (z.B.: 0xFF) oder Nullen (0x00) in einer Datei! Aber wirklich nur in der Datei! Denn wie oben beschrieben existieren im Dateisystem jffs2 4-Byte-Blöcke für diese Platzhalter, je nachdem welcher 4-Byte-Block am günstigsten für eine minimale Änderung ist.
Also unsere Platzhalter oder Nullen
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
werden in JFFS2 gespeichert als bspw:
4D0E3393.4D0E3393.4D0E3393.4D0E3393.4D0E3393.4D0E3393.4D0E3393.4D0E3393
und nach der Blockchiffre bspw:
3837F001 72F2FB46 8A11FB6A 78A8941D.3837F001 72F2FB46 8A11FB6A 78A8941D
Der Punkt zeigt an, wo sich der Block wiederholt
An einer anderen Stelle könnten diese Nullen also im JFFS2 (weil's günstiger ist) heissen:
2CDC59EB.2CDC59EB.2CDC59EB.2CDC59EB.2CDC59EB.2CDC59EB.2CDC59EB.2CDC59EB
Dadurch würde mit der GLEICHEN Blockchiffre aber resultieren:
6AFCD538 8C07F36E F9A10B95 47A4BEEC.6AFCD538 8C07F36E F9A10B95 47A4BEEC

Simples XOR kann deshalb ausgeschlossen werden, weil eine Änderung eines einzelnen Bytes (im oberen Bsp das rote E3) nicht den kompletten Block ändern würde.
Eine Komprimierung kann ausgeschlossen werden, weil sonst niemals so viele sich wiederholende 16-Byte-Blöcke existieren würden.
Eine Stromchiffre kann ausgeschlossen werden, da es dort viel seltener ist, dass sich 16 Bytes direkt wiederholen.
128-Bit XOR oder NAND mit Feedback im gleichen Block kann nicht ausgeschlossen werden, ist aber nicht sinnvoll, da bessere Cryptoalgorithmen bereits im Linux-Kernel vorhanden sind. (siehe linux-2.6.10_mvl40x-patchlevel-956\crypto)
Eine andere Verschlüsselungslänge (also 256-bit oder 192-bit oder gar geringer als 128) kann ausgeschlossen werden, da wiederkehrende Muster 16 Bytes lang sind und die Länge des kompletten JFFS2-Contents immer auf 16 Bytes gerundet ist.

Es MUSS also aes/des/fish/usw. oder ein asymmetrisches System wie PGP sein.

(Ich sollte mein Diplom-Thema ändern ^^)

Cryto ist wahrlich nicht meine Stärke. Deshalb werf ich einfach mal so mit der Plaintext Attacke rum?
Immerhin hat ja irgendwer ne xml rausgeholt. Das mit 00 wird wohl nich gehen, wenn jffs die immer anders codiert.

Im Angebot hätte ich Quadcore Xeon Server die ein bisschen Brute-Forcen könnten.

Ansonsten gibts bloß die Möglichkeit, dass ein Elektrogeek sein Gerät mal öffnet und so was wie ne Tweezer Attacke probiert. Auch NAND auslesen wäre toll, das mit dem Kühlen soll ja Wunder wirken.
Oder den Debugport anzapft, sollte ja laut Manual da sein...

Hmm. Theoretisch würde eine Plaintext-Attacke gehen, denn die Dateinamen sind ja meistens leserlich. Ein sinnvoller Algorithmus müsste quasi den ersten Block mit einem beliebigen Key entschlüsseln und wenn die ersten beiden Bytes (also die an 2DCh) 0x85 0x19 sind müsste mit dem gleichen Key nur nochmal geschaut werden ob ein Plaintext(sinnvoller Dateiname) innerhalb der nächsten 3 Blöcke steht.
Das ist jedoch alles viel zu aufwendig, denn wir wissen nicht einmal mit welchem Algo phlps gearbeitet hat. Wir brauchen Insider-Informationen oder Referenz-Produkte. Vielleicht durch Tochterfirmen von phlps oder Auslandsverkäufe.
Erstmal JETTFiles probieren...

wenn es mit den upg-files nicht gibt, dann bleiben uns wohl nur noch die folgenden möglichkeiten:

1. etwas über jettfiles herauszufinden und wie sie aktiviert werden können.

2. gerät öffen - jtag finden und flashroms auslesen. in den service manuals wird ein jtag erwähnt (updates sind auch ohne jtag vom user möglich) - sonst jedoch nichts

3. es gibt "service mode pads" zum aktivieren eines SDM modes (es gibt unterschiedliche SDM modi + SAM + CSM). gerät öffnen und die SDM pads vor der stromzufuhr kurzschliessen. mann kann dann per UART kommandos eingeben. z.b. shift-u für firmwareupload via terminalprogramm. ich weiss leider nicht was es hier sonst noch für möglichkeiten gibt.

4. gerät öffen - flashroms mit heißluft entfernen und mit eprombrenner auslesen (brenner und sockel/adapter hätte ich...)

mein tv ist an einer schweren nussbaum wand angeschraubt - kann da leider nicht so einfach dran.

vielleicht kann ja mal jemand sein gerät öffnen und ein foto von der hauptplatine schiessen.

Wer wird das bei einem so teuren Gerät machen?

Zu hoffen wäre es, aber die Chancen sind nicht sehr gut...

habe heute mein D-Link DUB-E100 USB bekommen. der tv aktiviert das interface nicht => link down.

schade

huhu,
nochmal zum header der .upg files

00000000h: 32 53 57 55 33 54 58 56 DC 02 00 00 E4 C9 9B 01 ; 2SWU3TXVÜ...äÉ›.
00000010h: 01 FA AE B3 00 00 00 60 00 00 00 00 00 00 00 00 ; .ú®³...`........

byte 08 bis 0B ist die startadresse (rückwärts): 00 00 02 DC

byte 0c bis 0f ist die endadresse (rückwärts): 01 9B C9 E4

das ende ist 743 bytes vor dem tatsächlichen dateiende. das ist bei allen firmwares in einer ähnlichen größenordnung, aber nicht gleich.
gehört das byte an adresse 019bc9e4 noch mit zu den daten? oder könnte das die erste adresse des nächsten abschnitts sein?

die nächsten 4 header bytes (adresse 10 bis 13) sind in allen firmwares für mich random. möglicherweise eine checksumme (crc32 ?) - könnte es auch ein 32bit key sein?

hier mal die bytes 10 bis 13 aller firmwares:
000.059.019.000 - CB 38 8D 0E
000.059.028.000 - 5E 83 15 38
000.059.031.000 - AF 9E FA 24
000.064.014.004 - 7E 97 CD 58
000.064.014.006 - 14 B2 E9 EA
000.064.014.011 - 90 C2 8A 7E
000.064.014.014 - 32 86 54 67
000.064.014.017 - 7D FB 75 73
000.064.014.018 - 01 FA AE E3

p)(d schrieb:

2. gerät öffen - jtag finden und flashroms auslesen. in den service manuals wird ein jtag erwähnt (updates sind auch ohne jtag vom user möglich) - sonst jedoch nichts

War etwas fummelig aber ich habe die Kabel angelötet. Ob es auch korrekt funktioniert werden wir leider erst feststellen wenn ich eine passende Software gefunden habe. Scheint aber nichts fertiges zu geben was a) meinen jtag Kabel unterstützt und b) Flash ROMs auslesen kann.

p)(d schrieb:

vielleicht kann ja mal jemand sein gerät öffnen und ein foto von der hauptplatine schiessen.

jtag ist an 1HE0 über den PNX8541.

Grüße,
Florian

zum thema jtag und unseren philips boards habe ich das hier gefunden: http://www.extra.res.../PR-TN2004-00603.pdf

hier werden alle möglichen jtag varianten verglichen und bewertet.

so nebenbei in dem selben ordner mal gestöbert - sind interessante sachen aus der phillips forschung drin

Vielleicht könnte ja mal jemand mit One.zip aushelfen:

EJTAGDownload_Q591X_x.x.x.x.zip
FlashUtils_Q591X_x.x.x.x_commercial.zip

Hi,

good news. Ein bischen was geht schon...


jtag #0
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008 Kolja Waschk and the respective authors

jtag is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for jtag.

WARNING: jtag may damage your hardware!
Type "quit" to exit, "help" for help.

jtag> cable turtelizer2
Connected to libftd2xx driver.
jtag> detect
IR length: 18
Chain length: 1
Device Id: 00010010000010000110000000101011 (0x000000001208602B)
Manufacturer: Philips Semi. (Signetics)
Part(0): PNX8541
Stepping: Ver 1
Filename: C:\PTV\urjtag\data/philips/pnx8541/pnx8541
jtag> print chain
No. Manufacturer Part Stepping Instruction
Register
--------------------------------------------------------------------------------
-----------------------------------
0 Philips Semi. (Signetics) PNX8541 Ver 1 BYPASS
BR
jtag>

mir fällt eben ein, ich habe noch ein altes bdm interface für die dbox 1. könnte das an unserem philips jtag funktionieren?

und wenn ja, mit welcher software?

http://urjtag.org ?

gibt es empfehlenswerte tutorials zu dem thema?

p)(d schrieb:

mir fällt eben ein, ich habe noch ein altes bdm interface für die dbox 1. könnte das an unserem philips jtag funktionieren?

Nein, bdm geht nicht. Eine Übersicht über parallel Kabel gibt es hier:

http://wiki.openwrt..../Hardware/JTAG_Cable

Ich würde zum Wiggler greifen, das DLC5 sollte auch gehen, du brauchst dann aber an PIN einen Pullup nach VCC sonst bleibt der TAP im Reset und es geht nichts.

Ich selbst benutzte ein Turtelizer2 USB Kabel da ich kein parallel Port habe.

p)(d schrieb:

und wenn ja, mit welcher software? http://urjtag.org ?

Ich benutze derzeit urjtag. Prinzipiell sollte jede ejtag fähige Software gehen. Wir brauchen aber NAD Flash support und das bietet derzeit keiner :-(

p)(d schrieb:

gibt es empfehlenswerte tutorials zu dem thema?

Der oben genannte Link ist ein guter Start.

Grüße,
Florian

echt cool, dass ihr schon so weit gekommen seid.
Mein Kauf des 47pfl9703 steht für 10-12/08 an, dann kann ich über den lokalen Philips ServiceTechniker ev. an den ONE.zip ran. Vorher möchte ich mein Glück nicht zu sehr strapazieren...WEITER SO!!!

Hi,

One.zip wird vermutlich auch nicht helfen, da wir dann einen passenden Philips JTAG Programmer bräuchten und wir auch nicht wissen ob man damit überhaupt das Flash auslesen kann oder nur beschreiben kann.

Es gibt leider noch Probleme mit der JTAG Kommunikation, wie oben gepostet wird eine IR Length von 18 erkannt, was eigentlich ungewöhnlich für eine MIPS CPU ist.

Die CPU lässt sich leider nicht in den Debug Mode versetzen, was entweder an der IR Length liegt oder aber an urjtag. Dummerweise gibt es sonst keine Software die mit meinem jtag Kabel umgehen kann. Aber ich bin noch dran, wird schon

Ich habe mittlerweile einen Kontakt zu NXP hergestellt und herausgefunden dass die Upgrade Files nicht nur verschlüsselt sind sondern auch signiert sind.

Grüße,
Florian

Hi,

achso noch was: auf der Platine gibt es einen zweiten Seriellen Port. Hat nicht jemand Lust dort mal ein Kabel anzulöten und zu gucken ob nicht jemand eine Konsole dort aktiviert hat?

Vorzugsweise jemand mit einem 9732 TV da dort Schutzdioden und Widerstände schon onboard sind. Bei meinem 9703er hat Philips die in das Serivce Kabel ausgelagert

Grüße,
Florian

ich habe nur einen einzigen hinweis gefunden, das man per UART eine tastatureingabe machen kann. hierbei muss aber auch gehäuse geöffnet werden.

Upgrade via PC and ComPair interface It will be possible to upgrade the Stand-by software via a PC and the ComPair interface. Check paragraph "ComPair" on how to connect the interface. To upgrade the Stand-by software, use the following steps: 1. Disconnect the TV from the Mains/AC Power. 2. Short circuit the SPI pins [2] on the SSB (see figure “Service mode pads” earlier in this chapter). 3. Keep the SPI pins shorted while connecting the TV to the Mains/AC Power. 4. Release the short circuit after approx. two seconds. 5. Start up HyperTerminal (can be found in every Windows application via Programs -> Accessories -> Communications -> HyperTerminal). Use the following settings: – COM1 – Bits per second = 38400 (9600)* – Data bits = 8 – Parity = none – Stop bits = 1 – Flow control = None 6. Press “Shift U” on your PC keyboard. You should now see the following info: – PNX2015 Loader V1.0 – 19-09-2003 – DEVID=0x05 – Erasing – MCSUM=0x0000 – = 7. If you do not see the above info, restart the above procedure, and check your HyperTerminal settings and the connections between PC and TV. 8. Via “Transfer” -> “Send text file ...”, you can send the proper upgrade file to the TV (e.g. *.hex). 9. After successful programming, you must see the following info (this can take several minutes!): – DCSUM=0xC67E – :Ok – MCSUM=0xC67E – Programming – PCSUM=0xC67E – Finished 10. If you do not see this info, restart the complete procedure. 11. Close HyperTerminal. 12. Disconnect and connect Mains/AC Power again. (*) When having problems with upgrading, use the values between brackets.

evtl gibt es neben dem shift-u noch andere eingaben?


@joltcoke: hast du dir mal PR-TN2004-00603.pdf angeschaut?

Hi,

das dort beschriebene Upgrade ist nur für den 8051 Standby Prozessor.

Ja, das PR-TN2004-00603.pdf habe ich mir schon angeguckt. Dort wird erwähnt das der PNX8550 aus zwei JTAG Modulen besteht, leider verhält sich (mein) PNX8541 anders, obwohl die IR Length ebenfalls vermuten lässt das sich mehrere Module in der Chain befinden.

Grüße,
Florian

joltcoke schrieb:

das dort beschriebene Upgrade ist nur für den 8051 Standby Prozessor.

mir ging es nicht um das upgrade, sondern um die tatsache, das an dieser stelle eine tastatureingabe möglich ist. eventuell gibt es hier noch andere funktionen?


wenn du kontakt zu nxp hast kannst du ja eventuell etwas über jettfiles in erfahrung bringen. das hätte den vorteil, das wir nicht das gerät öffen müssen und per uart/usb zugreifen können. ich hoffe mal, das binarys nicht signiert sein müssen...

gibt es was neues in sachen jtag / ejtag ?
wie sieht es da mit irgendwelchen ansätzen aus?
z.b. ein binary in den speicher laden und ausführen?

oder macht es sinn, die flashroms mal zu sockeln und direkt auszulesen?

Anscheinend hat man das Interesse verloren?!?!

Wie sonst könnte man sich die Leere hier erklären...

NEIN - aber es scheint, dass da keiner die Zeit hat (ev. ja im Winter) ...

ich hab echt keine zeit. demnächst zieh ich auch noch um - also noch weniger zeit.

bei mir sieht es zeitlich auch sehr eng aus.

wobei ich bei der sache momentan kaum chancen sehe.

ohne auslöten der flashroms wird wohl nix gehen, falls joltcoke mit seinem jtag nicht weiterkommt?
und selbst der inhalt der flashroms kann (teilweise/komplett) crypted sein.

one.zip könnte evtl noch von nutzen sein.


p.s. habe meinen 47pfl9732 gegen einen 47pfl9703 eingetauscht. mann gönnt sich ja sonst nichts...

joltcoke schrieb:

Ich habe mittlerweile einen Kontakt zu NXP hergestellt und herausgefunden dass die Upgrade Files nicht nur verschlüsselt sind sondern auch signiert sind. Grüße, Florian

gibts von diesem kontakt noch irgend etwas zu entlocken?

huhu,
ich habe jetzt einen 47pfl9732

eben einen portscan gemacht und herausgefunden, das auf port 8080 ein webserver rennt:



und hier noch ein paar konsole logfiles:
http://rapidshare.com/files/152465190/9703_power_on.log
http://rapidshare.com/files/152465376/9703_update.log
http://rapidshare.com/files/152465507/9703_go_standby.log
http://rapidshare.com/files/152465611/9703_standby_wakeup.log

coooool - bringt uns das weiter ? vermute mal eher auch nicht od. ?

Oh mann ist das spannend. Ich hole mir jetzt auch einen Philips und code mit. Aber welchen soll ich nehmen? Welches aktuell Modell ab 47 Zoll ist brauchbar?

den 9703, wenns denn ein Phil sein soll ...

47pfl9703 oder 52pfl9703 je nach geldbörse

Und? Bin total gespannt auf den Flashrom-Inhalt. Wäre echt stark, wenn den jemand auslesen kann. Nur leider befürchte ich, dass weitere Fallstricke eingebaut wurden. Könnte mir gut vorstellen, dass ein zweiter Chip für die Entschlüsselung sorgt. Ist aber auch echt alles SMD und kleiner auf der Platine, wa?

Kennt sich vielleicht jemand aus mit Seitenkanalattacken ?

@atzplzw: Du sagtest, dass er schon ein zwei mal abgeschmiert ist bei nem Stream? Vielleicht ist das doch der bessere Ansatz. Kann mir gut vorstellen 'ne Rootshell reinzuhauen mittels Buffer-Overflow oder sowas.
Oh man.. das klingt freakig... :-/

Bitte helfen!!

Hallo an Alle! Diesen Beitrag habe ich schon im Bereich:

http://www.hifi-foru...701&postID=3382#3382
gestellt, hoffe jemand kann mir helfen


Habe den 37PFL7603H/10 mit aktueller Software Q582E_0.64.72.0
Ich bekomme gerade eine akute Krise und kann nur alle davor warnen die neuen Softwareversionen ab 12/08 drauf zu spielen!
Warum?
Weil ich seit dem update auf Version Q582E_0.64.70.1 einfach nur noch das kalte Kotzen kriege über die Farbnachzieheffekte die sich seitdem eingestellt haben.
Gesichtskonturen verschwimmen etc......
Besonders wenn die Kamera schwenkt und zb. ein dunkler Schrank vor einer weissen Fläche steht sollte man sich die Konturen angucken.
Wie gesagt ich könnte so kotzen, dass sich meine Ausdrucksweise leider dem unterordnen muss.

Ansonsten falls noch nicht beantwortet:
Ja man bekommt die Kabelkanäle inkl. Anixe HD mit dem Modell.


Aber nun meine Frage, nachdem der Philips Kundendienst von mir Bilder haben wollte, um das Problem zu diagnostizieren, als ob sie selber nicht wüssten was sie da für eine Software auf den Markt gebracht haben.


Kann mir jemand erklären, wie man die alte Software wieder aufspielt?
Muss man sie umbenennen?
Woher kriege ich die alte Software zb. Q582E_0.64.67.3 oder
Q582E_0.64.50.5

Habe damals leider die Software nicht abgespeichert.

Danke an Alle
Grüße omy-

eben einen portscan gemacht und herausgefunden, das auf port 8080 ein webserver rennt

Könnte das dahin führen, dass man den TV übers Web fernbedienen kann? Wäre doch cool....

Dumpfbacke

Danach sieht es aus, aber - außer technischer Spielerei - was brächte es? Bei einem Festplattenreceiver kann ich es verstehen. Mal eben eine Aufzeichnung über das Internet (VPN) programmieren. Aber beim Fernseher? Nachsehen, ob die Kleinen noch vor der Glotze sitzen?

Abgesehen davon scheint Philips die Sourcen von seinen Servern genommen zu haben. Kann jemand die Datei(en) anbieten? Würde mir gerne mal die Versionsstände ansehen. Vielleicht gibt es ja (inzwischen) bekannte Schwachstellen.
Streaming wurde schon angesprochen, evtl. auch über Bilder, MP3 oder eben den Webserver.

Ist mir schon klar: Vom bloßen Wissen über eine Lücke bis zur Ausnutzung ist noch ein weiter Weg. Aber besser als planlos suchen.

Hallo,

kann jemand nochmal die letzten Sourcen für den PFL9703 bereitstellen ? Das Philips die einfach runtergenommen hat ist wirklich

Gruss und Danke
Mike

Hat sich irgendwas getan, gibt es Projekte die Firmware zu modifizieren, zu verändern etc.?
Habe leider nichts gefunden.

Auf dem Port 8080 leider immer noch nur eine Testseit

" Embedded Web Server First Page The value of the test variable is: Hello World!"

Habe heute die Sourcen für den 37PFL9604, FW-Versionen Q5492_0.26.58.5 und Q5492_0.26.29.6 erhalten. Falls Interesse besteht, kann ich die Zips auf Rapidshare hochladen.

Wie Jean-Marc auf jointSPACE inzwischen geschrieben hat, ist wohl mit den Sourcen nicht viel anzufangen:
"...Moreover, the compiler was not public and so could not be distributed for free. We never promoted the feature for those reasons..."

Der Letzte Satz bezieht sich auf die (ursprünglich vorgesehene) Möglichkeit bei den Versionen vor 2009 über den USB-Stick eigene Software zu starten. Inzwischen soll die Softwareentwicklung durch "Dritte" über jointSPACE (jointspace.sourceforge.net) erfolgen - womit auch die Frage von chriux beantwortet ist.

Enthalten sind bei Version 0.26.58.5 nach meinem ersten Überblick:

Linux Kernel (2.6.18) Flash Eraseall Nandwrite Helper Application Libc, libm, Libpthread, Librt, Librt, Libdl, Ld, Libresolv, Libncurses libgcc libstd++ vsnprintf rpc_socket tmDbgInternal SHA1 algorithm. GIF reading routines lzma (4.4.3) Busybox (1.2.1) ezxml (0.8.6) DirectFB Libgphoto Opera Web Browser (fehlt nach meinem ersten Überblick, lediglich Lizenzangaben) Supplicant WPA & Wireless Tools

EDIT: Für andere Versionen Philips in Brügge anschreiben, waren in meinem Fall sehr hilfsbereit.

Also ich finde die Sourcen noch: Download

Hoffe dass irgendwer mal den blöden tV knackt ^^
Ich will neue software drauf haben xD