Flash-RAM == /dev/mtd*

[Lemmi]

Aktuelle Infos befinden sich im M740.de Wiki (m740.de/wiki/) unter »Flash-RAM (http://www.m740.de/wiki/index.php/Flash-RAM)«

-----------------------------------------------

Ich habe mal ein paar Infos zum Flash-RAM zusammengetragen:

Bei dem Flash-Ram handelt es sich um eine 16MB Baustein mit der Bezeichnung:
PL127J70BAI00 (Name korrigiert!) // 0439ABC // THAILAND // FASL LLC.
(Info aus Was ist in der Box? (http://www.m740.de/forum/showthread.php?t=52))

Der Chip wird von Spansion (http://www.spansion.com) hergestellt und von AMD (http://www.amd.com/us-en/FlashMemory/TechnicalResources/0,,37_1693_2351,00.html) vertrieben. Dort gibt es auch die Produktbeschreibung als PDF (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/S29PL127_129_064_032J_00_A6.pdf).

Nach der PDF-Beschreibung behält der Flash seine Infos für 20 Jahre ("Data Retention: 20 years typical") und schafft 1 Million Lese-Schreib-Zyklen ("Cycling Endurance: 1 million cycles per sector").

Der Flash-Ram ist wie folgt auf die mtd-Blocke aufgeteilt:



-------------------------------------------------------------------------------
Device Adresse Größe mount Anmerkung (frei nach gambler)
-------------------------------------------------------------------------------

/dev/mtd0 00:0000-ff:ffff 100:0000 16 M gesamter Bereich (mtd1 bis mtd5)

/dev/mtd1 00:0000-5f:ffff 60:0000 6 M / cramfs
/dev/mtd2 60:0000-bb:ffff 5c:0000 5.75M /data jffs2, flash recorder_log, playlists
/dev/mtd3 bc:0000-bf:ffff 04:0000 0.25M speicher mit settings, /var/etc
/dev/mtd4 c0:0000-d7:ffff 18:0000 1.5 M boot-sector (64K) + vmlinux
/dev/mtd5 d8:0000-ff:ffff 28:0000 2.5 M cramfs, backup system

/dev/mtd6 ungültig

Adressen- und Größenangaben in Hexadezimal
Der boot-sector ist wieder eine Mutmaßung von mir. Tatsächlich beginnt vmlinux mit einem Versatz von 64KB.

cat /proc/mtd liefert die folgende Ausgabe:

dev: size erasesize name
mtd0: 01000000 00010000 "Physically mapped flash"
mtd1: 00600000 00010000 "root"
mtd2: 005c0000 00010000 "app"
mtd3: 00040000 00010000 "prod"
mtd4: 00180000 00010000 "boot"
mtd5: 00280000 00010000 "rescue"


Und in /dev/mtd4 findet man passend dazu den folgenden Text:

mtdparts=phys:6m(root),5888k(app),256k(prod),1536k (boot),-(rescue)

Anmerkungen:

/dev/mtd[0-5] sind 'character devices'.
/dev/mtdblock[0-5] sind die dazugehörigen 'block devices'
.
/dev/mtd6 und /dev/mtdblock6 existieren zwar, sind jedoch ungültig.
.
Der Flash-Ram hat eine Größe von 128 MBit, also 16 MB. /dev/mtd0 stellt den gesamten Speicherbereich da und /dev/mtd1 bis /dev/mtd5 disjunkte Teilbereiche hiervon.
.
Die Adressen habe ich anfangs willkürlich hingeschrieben. Sie ergeben sich aber logisch aus der Anordnung der mtd-devices. Eine von mir vorgenommene stichpunktartige Überprüfung hat diese These bestätigt.
.
Die Basis-Infos über die Verwendung der mtd-devices sind von gambler (http://www.m740.de/forum/showthread.php?p=29#post29).
.
In den bereits bekannten Siemens GPL Sourcen (http://now-portal.c-lab.de/project/showfiles.php?group_id=13&release_id=32) befindet sich auch ein Verzeichnis mit dem Namen mtd/, welches neben den Quellen weitere Infos enthält. U.a. befindet sich dort die Datei 'mtd-jffs-HOWTO.txt', die nach dem ersten Überfliegen sehr interessant für uns sein kann.

[Lemmi]

Aktuelle Infos befinden sich im M740.de Wiki (m740.de/wiki/) unter »WSW Datei (http://www.m740.de/wiki/index.php/WSW_Datei)«

-----------------------------------------------

Ich habe mir nochmals die beiden Updates angeschaut und die Daten-Verteilung in den WSW-Dateien analysiert: (Alle Werte in Hex)


FW 1.2 (WSW)
--------------------------------------------------------------------
size info flash device
--------------------------------------------------------------------
00:0588 WSW-Header
60:0000 cramfs und Füllbytes (0xff) für /dev/mdt1
5c:0000 jffs2 und Füllbytes (0xff) für /dev/mdt2
01:0000 boot-sector für /dec/mdt4
17:0000 vmlinux und Füllbytes (0xff) für /dec/mdt4 + 01:0000
28:0000 cramfs und Füllbytes (0x00) für /dev/mdt5
Der boot-sector ist wieder eine Mutmaßung von mir. Tatsächlich beginnt vmlinux mit einem Versatz von 64KB. Außerdem fehlt er in FW 1.18.


FW 1.8 (WSW)
--------------------------------------------------------------------
size info flash device
--------------------------------------------------------------------
00:0588 WSW-Header
60:0000 cramfs und Füllbytes (0xff) für /dev/mdt1
5c:0000 jffs2 und Füllbytes (0xff) für /dev/mdt2
0c:0000 vmlinux für /dec/mdt4 + 01:0000


Zum Vergleich: die /dev/mdt* Tabelle:


Device Adresse Größe mount Anmerkung (frei nach gambler)
-------------------------------------------------------------------------------
/dev/mtd1 00:0000-5f:ffff 60:0000 6 M / cramfs
/dev/mtd2 60:0000-bb:ffff 5c:0000 5.75M /data jffs2, flash recorder_log, playlists
/dev/mtd3 bc:0000-bf:ffff 04:0000 0.25M speicher mit settings, /var/etc
/dev/mtd4 c0:0000-d7:ffff 18:0000 1.5 M boot-sector (64K) + vmlinux
/dev/mtd5 d8:0000-ff:ffff 28:0000 2.5 M cramfs, backup system


Während 1.12.wsw ein volles Update enthält kommt 1.18.wsw ohne ohne boot-sector und ohne rescue-System daher. Außerdem bleiben bei 1.18 die ersten 0x10000 Bytes des vmlinux-Bereich unverändert, die mutmaßlich als Boot-Sektor anzusehen sind.

[Lemmi]

Aktuelle Infos befinden sich im M740.de Wiki (m740.de/wiki/) unter »WSW Header (http://www.m740.de/wiki/index.php/WSW_Header)«

-----------------------------------------------

Ein paar neue Infos zum WSW-Aufbau.

An Adresse 0x006 befindet sich ein zwei Byte Wort mit der Anzahl der Bytes der RSA-Prüfsumme. Dieser Wert ist bisher immer 44. Daher folgen auch 44 Bytes dieser Prüfsumme. Werden diese 44 Bytes dem Programm rsadecode mit dem Schlüssel /etc/.rsapublic via stdin übergeben, dann erfolgt eine stdout Ausgabe der MD5SUM. Die MD5SUM wird dabei ab Adresse 0x400 berechnet.

Ab Adresse 0x488 befindet sich ein 256 Byte großes Feld, welches eine Art Mapping beschreibt. Für jede dem WSW-Header folgende Page (64K) gibt es eine Index-Eintrag, in welche Flash-Ram-Page sie geschrieben werden soll.

Der 4-Byte-Wert ab Adresse 0x484 gibt dabei die Anzahl der Pages im Update an.

Die einzige Stelle, die mir noch unbekannt ist, ist das 4-Byte-Wort ab Adresse 0x47c.
Allerdings ist die Bedeutung der beiden Bytes ab Adresse 0x004 reine Mutmaßung.

Hier eine Hexdump-Gegenüberstellung der beiden bekannten Updates:

1.12.1new2.wsw 1.18small.wsw
----------------------------------------------------------
000: 57 53 57 20 :WSW : 57 53 57 20 :WSW : WSW-Kennung

004: 00 24 :.$: 00 24 :.$: ?? Länge der MD5SUM-Ausgabe inkl. LF
006: 00 2c :.,: 00 2c :.,: Länge der RSA-Prüfsumme

008: ec 4a 6b 75 :lJku: 96 ab b8 20 :.+8 : RSA-Prüfsumme
00c: ef 58 7d f1 :oX}q: bd 01 c6 d9 :=.FY:
010: af 51 40 df :/Q@_: 2e 3b 40 6e :.;@n:
014: e6 13 83 66 :f..f: b3 12 d3 d5 :3.SU:
018: 66 a0 01 55 :f .U: 60 5d d7 d0 :`]WP:
01c: 13 00 9a 9e :....: c6 30 85 c6 :F0.F:
020: a2 3a 6d 66 :":mf: 92 8f 99 79 :...y:
024: a8 2f f0 e3 :(/pc: 91 39 4f 5b :.9O[:
028: 40 a1 ab 10 :@!+.: 40 45 51 d1 :@EQQ:
02c: df 42 ea 1e :_Bj.: 80 96 a1 47 :..!G:
030: 0d a6 3c 00 :.&<.: e9 8f b3 00 :i.3.:

034: 00 00 00 00 :....: 00 00 00 00 :....:
.... (alles 00)
3fc: 00 00 00 00 :....: 00 00 00 00 :....:

Ab hier wird die MD5SUM berechnet!
400: 4d 37 34 30 :M740: 4d 37 34 30 :M740: Name der Box
404: 41 56 00 00 :AV..: 41 56 00 00 :AV..:
408: 00 00 00 00 :....: 00 00 00 00 :....:
.... (alles 00)
43c: 00 00 00 00 :....: 00 00 00 00 :....:
440: 31 2e 31 32 :1.12: 31 2e 31 38 :1.18: Name des Updates
444: 2e 31 6e 65 :.1ne: 73 6d 61 6c :smal:
448: 77 32 00 00 :w2..: 6c 00 00 00 :l...:
44c: 00 00 00 00 :....: 00 00 00 00 :....:
.... (alles 00)
478: 00 00 00 00 :....: 00 00 00 00 :....:
47c: 38 95 ce 53 :8.NS: 67 00 b6 0f :g.6.: ??? Dieser Teil ist mir noch unklar!
480: 41 9d 9b 8e :A...: 41 bb 31 ad :A;1-: (Erstellungs-)Datum (time_t)

484: 00 00 00 fc :...|: 00 00 00 c8 :...H: Längenangabe in Pages (64K)

488: 00 01 02 03 :....: 00 01 02 03 :....: ab hier: Mapping
48c: 04 05 06 07 :....: 04 05 06 07 :....:
490: 08 09 0a 0b :....: 08 09 0a 0b :....:
494: 0c 0d 0e 0f :....: 0c 0d 0e 0f :....:
498: 10 11 12 13 :....: 10 11 12 13 :....:
49c: 14 15 16 17 :....: 14 15 16 17 :....:
4a0: 18 19 1a 1b :....: 18 19 1a 1b :....:
4a4: 1c 1d 1e 1f :....: 1c 1d 1e 1f :....:
4a8: 20 21 22 23 : !"#: 20 21 22 23 : !"#:
4ac: 24 25 26 27 :$%&': 24 25 26 27 :$%&':
4b0: 28 29 2a 2b :()*+: 28 29 2a 2b :()*+:
4b4: 2c 2d 2e 2f :,-./: 2c 2d 2e 2f :,-./:
4b8: 30 31 32 33 :0123: 30 31 32 33 :0123:
4bc: 34 35 36 37 :4567: 34 35 36 37 :4567:
4c0: 38 39 3a 3b :89:;: 38 39 3a 3b :89:;:
4c4: 3c 3d 3e 3f :<=>?: 3c 3d 3e 3f :<=>?:
4c8: 40 41 42 43 :@ABC: 40 41 42 43 :@ABC:
4cc: 44 45 46 47 :DEFG: 44 45 46 47 :DEFG:
4d0: 48 49 4a 4b :HIJK: 48 49 4a 4b :HIJK:
4d4: 4c 4d 4e 4f :LMNO: 4c 4d 4e 4f :LMNO:
4d8: 50 51 52 53 :PQRS: 50 51 52 53 :PQRS:
4dc: 54 55 56 57 :TUVW: 54 55 56 57 :TUVW:
4e0: 58 59 5a 5b :XYZ[: 58 59 5a 5b :XYZ[:
4e4: 5c 5d 5e 5f :\]^_: 5c 5d 5e 5f :\]^_:
4e8: 60 61 62 63 :`abc: 60 61 62 63 :`abc:
4ec: 64 65 66 67 :defg: 64 65 66 67 :defg:
4f0: 68 69 6a 6b :hijk: 68 69 6a 6b :hijk:
4f4: 6c 6d 6e 6f :lmno: 6c 6d 6e 6f :lmno:
4f8: 70 71 72 73 :pqrs: 70 71 72 73 :pqrs:
4fc: 74 75 76 77 :tuvw: 74 75 76 77 :tuvw:
500: 78 79 7a 7b :xyz{: 78 79 7a 7b :xyz{:
504: 7c 7d 7e 7f :|}~.: 7c 7d 7e 7f :|}~.:
508: 80 81 82 83 :....: 80 81 82 83 :....:
50c: 84 85 86 87 :....: 84 85 86 87 :....:
510: 88 89 8a 8b :....: 88 89 8a 8b :....:
514: 8c 8d 8e 8f :....: 8c 8d 8e 8f :....:
518: 90 91 92 93 :....: 90 91 92 93 :....:
51c: 94 95 96 97 :....: 94 95 96 97 :....:
520: 98 99 9a 9b :....: 98 99 9a 9b :....:
524: 9c 9d 9e 9f :....: 9c 9d 9e 9f :....:
528: a0 a1 a2 a3 : !"#: a0 a1 a2 a3 : !"#:
52c: a4 a5 a6 a7 :$%&': a4 a5 a6 a7 :$%&':
530: a8 a9 aa ab :()*+: a8 a9 aa ab :()*+:
534: ac ad ae af :,-./: ac ad ae af :,-./:
538: b0 b1 b2 b3 :0123: b0 b1 b2 b3 :0123:
53c: b4 b5 b6 b7 :4567: b4 b5 b6 b7 :4567:
540: b8 b9 ba bb :89:;: b8 b9 ba bb :89:;:

Hier fehlt /dev/mdt3 (4x64K). Daher auch der Sprung von 4

544: c0 c1 c2 c3 :@ABC: c1 c2 c3 c4 :ABCD: mit (1.12.1) und ohne (1.18)
548: c4 c5 c6 c7 :DEFG: c5 c6 c7 c8 :EFGH: boot-sektor.
54c: c8 c9 ca cb :HIJK: c9 ca cb cc :IJKL: Daher sind die folgenden
550: cc cd ce cf :LMNO: cd ce cf d0 :MNOP: Einträge um jeweils
554: d0 d1 d2 d3 :PQRS: d1 d2 d3 d4 :QRST: 1 Byte verschoben.
558: d4 d5 d6 d7 :TUVW: d5 d6 d7 d8 :UVWX:
55c: d8 d9 da db :XYZ[: d9 da db dc :YZ[\:
560: dc dd de df :\]^_: dd de df e0 :]^_`:
564: e0 e1 e2 e3 :`abc: e1 e2 e3 e4 :abcd:
568: e4 e5 e6 e7 :defg: e5 e6 e7 e8 :efgh:
56c: e8 e9 ea eb :hijk: e9 ea eb ec :ijkl:
570: ec ed ee ef :lmno: ed ee ef f0 :mnop:
574: f0 f1 f2 f3 :pqrs: f1 f2 f3 f4 :qrst:
578: f4 f5 f6 f7 :tuvw: f5 f6 f7 f8 :uvwx:
57c: f8 f9 fa fb :xyz{: f9 fa fb fc :yz{|:
580: fc fd fe ff :|}~.: fd fe ff 00 :}~..:
584: 00 01 02 03 :....: 01 02 03 04 :....:


Der Header als C-struct:


struct wsw_header // big-endian
{
char magic[4]; // Magic: 'WSW '
uint16 md5sum_len; // ?? Länge der MD5SUM-Ausgabe inkl. LF
uint16 rsa_len; // Länge der RSA-Prüfsumme
uchar rsa[0x400-8]; // RSA-Prüfsumme

// MD5SUM wird ab hier bis zum Dateiende berechnet

char box_name[64]; // Name der Box: 'M740AV'
char upd_name[60]; // Name des Updates, z.B.: '1.18small'
char unknown[4]; // ???
time_t timestamp; // (Erstellungs-) Datum

uint32 num_of_pages; // Anzahl der Pages im Update
uchar page_map[256]; // die Page-Map
};

[Lemmi]

Zitat aus anderem Thread:

Es gibt nicht nur eine Prüfsumme, die ist auch
mit RSA digital signiert, der public key dazu
findet sich in /etc/.rsapublic.


Da wir ja jetzt /etc überladen können wir dem System ja eine neue /etc/.rsapublic anbieten um dann ein passendes Selbst-Bau-Update zu basteln. Mit dieser Lösung hätten wir dann für immer das Tor offen!

Leider kenne ich mich mit RSA & co nicht aus. Also: Wer kann mir ein passendes RSA-Key-Paar erzeugen.

Hier ist der Inhalt der Datei /etc/.rsapublic (3 Zeilen)

674A74D2DEA7D3CB4A637
#
CC5250D76B8B8FC0AA13


Ein HexDump der WSW-Datei befindet sich hier (http://www.m740.de/forum/showthread.php?p=2151#post2151).

[Lemmi]

Jetzt habe ich noch was für diesen Selbstunterhaltungs-Thread: :D

In /sbin/update_flash habe ich die folgenden Strings in unmittelbarer Nähe zueinander in dieser Reihenfolge gefunden:


system(%s)
erase flash
/usr/bin/md5sum > /var/tmp/verify.txt
md5sum failed
/usr/bin/rsadecode /etc/.rsapublic > /var/tmp/verify2.txt
/var/tmp/verify.txt
/var/tmp/verify2.txt
signature verify failed
signature verify ok
bad magic
file to small


Freie Interpretation:

erase flash:
Flash löschen
.
/usr/bin/md5sum > /var/tmp/verify.txt
md5 Prüfsumme über Update berechnen und in verify.txt abspeichern
.
md5sum failed
Fehler bei der Bildung der Prüfsumme
.
/usr/bin/rsadecode /etc/.rsapublic > /var/tmp/verify2.txt
Den RSA-Kode überprüfen
.
/var/tmp/verify.txt und /var/tmp/verify2.txt
Beide Datein müssen übereinstimmen ...
.
signature verify failed
... da sonst die Signatur falsch ist.
.
signature verify ok
Das ist das Ziel unserer Bemühungen
.
bad magic und file to small
Zwei andere Fehlermeldungen.


Und jetzt meine Idee:
Durch überladen von /usr/bin können wir neue Versionen von md5sum und rsadecode anbieten, die immer konstante Ergebnisse liefern. Damit wären auch eigene Updates möglich.

Das ganze könnte man testen, indem man nur einen Block im Flash-Ram überschreibt, der derzeit nicht verwendet wird.

[Lemmi]

Hier habe ich alle alle Strings aus /sbin/update_flash zusammengefasst. Insbesondere der untere Teil sieht aus wie ein script im binary:



sizeof(flash_content)=%d
/var/etc/flash_content
open
no flash content!!!
%d.%d
error parsing version
/var/etc
/sbin/flash_archive write
.
..
'/var/etc/%s'
system(%s)
erase flash
/usr/bin/md5sum > /var/tmp/verify.txt
w
md5sum failed
/usr/bin/rsadecode /etc/.rsapublic > /var/tmp/verify2.txt
/var/tmp/verify.txt
/var/tmp/verify2.txt
signature verify failed
signature verify ok
bad magic
file to small
read
block_count = %d
%d->%d
write
/dev/pic
open /dev/pic
Reboot in %ld seconds
PICSetReboot
Poweroff in %ld seconds
/dev/mtd3
ERROR set_bootflag: couldn't open device!
ERROR set_bootflag: no memory left for buffer!
ERROR set_bootflag: verify failed!
ERROR : couldn't open device!
erase flash
usage: %s <update_file> [x1 y1 x2 y2] [bg_hex fg_hex]
raw
installing raw flash file
%x
/sbin/rescue
update from rescue system
/var/tmp
/dev/fb0
mmap
open update_file
not a valid update file
Could not set bootflag to rescue version
pkill -9 wavebox
pkill -9 record
fatal error: read_update_file failed
/var/tmp/noreboot
mlockall
umount /data
umount /pvr/media/USB-HDD
umount /pvr/media/PC1
umount /pvr/media/PC2
umount /pvr/media/PC3
umount /pvr/media/PC4
umount /pvr/media/PC5
/dev/null
rmmod ehci-hcd
rmmod usb-ohci
ifconfig eth0 down
rmmod natsemi
pkill -9 lircd
rmmod lirc_dev_s
/dev/mtd0
fatal error: open /dev/mtdblock0
update done
Could not set bootflag to normal version


Da kann man sich dich gut vorstellen, wie ein Update abläuft.

[tete]

Ich habe mal wavebox von der Telnet-Konsole gestartet. Bei FW 1.12 kann man ja den Start unter /var/etc/rc auskommentieren. Da kommen eine Menge Ausschriften (auch während des Updates von 1.12 auf 1.18), die noch zu anlysieren sind. Man darf das dann beim Update nur nicht unterbrechen.

Leider funktioniert die Umleitung der Ausgabe in eine Datei nicht. Trotz Umleitung (/data/wavebox 2>&1 > /tmp/w.log) werden die meisten Ausgaben auf der Console angezeigt und mein xterm - Puffer war zu klein.

[oth]

Hallo,

ein Tool zur Generieung von RSA-Keys gibt es bei PUTTY.

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Habe ich selbst aber noch nicht ausprobiert.

Der Key auf der BOX erscheint mir außerdem sehr kurz. Ich kenne diese Keys immer nur länger.

Olaf

[oth]

Hallo,

ich habs soeben ausprobiert.

PUTTYgen kann nur Keys ab 256 Bit erstellen. Der Key in der Box ist kürzer.

Olaf

[haraldrt]

@Lemmi
Wenn der von Dir angedachte Prozess tatsächlich so abläuft, dann wäre das bauen eines neuen Updates um vieles "einfacher" als bisher gedacht.


/usr/bin/md5sum > /var/tmp/verify.txt
md5 Prüfsumme über Update berechnen und in verify.txt abspeichern

Da anscheinend anschliessend die Prüfsumme des Updates mit der rsacodiersten fest auf der Box liegenden verglichen wird, muss "nur" dafür gesorgt werden, das mir Hilfe der "Füllbytes" am Anfang, das Update die gewünschte md5 summe erhält.

bad magic und file to small
Dies deutet darauf hin, das die Dateigröße und ein "Magic word" im Header vorhanden sind, die auch einzuhalten sind.

cu Harald

[Lemmi]

@Lemmi
Wenn der von Dir angedachte Prozess tatsächlich so abläuft, dann wäre das bauen eines neuen Updates um vieles "einfacher" als bisher gedacht.


Mir ist der Aufbau des Flash-Rams, der zugehörigen /dev/mdt-devices und des Updates klar. Es darf nur noch ein wenig Forschung um die Prüfsummen auszutricksen.

Ich habe auch schon bei paar Ideen für die nächsten Tests, zu denen natürlich auch andere eingeladen sind:

Ich hatte ja schon vor einiger Zeit ein eigenes 1.18 Update erzeugt, welches das System (wahrscheinlich wegen der Prüfsumme) verweigert. Ich will diesen Vorgang beobachten und mir dann die beiden verify- und weitere Dateien undn Prozesse anschauen.
.
Das Flash-Ram könnte man auch direkt mit einem cramfs-Block beschreiben. Zum Testen des Lösch- und Schreibvorganges wählt man sich eine ungenutze Page aus.
.
'update_flash' ohne Parameter antwortet mit 'usage: update_flash <update_file> [x1 y1 x2 y2] [bg_hex fg_hex]':
Was haben die Parameter für eine Bedeutung?
.
Das Script /usr/bin/update_software ist die Hauptfunktion des Updates. Sie erzeugt eine Kopie des laufenden Systems mit Ziel Ram-Disk Sie und ruft unter anderem /usr/bin/install_kernel 3x mal, für die eigentliche Installation mit chroot auf die Ram-Disk. Nur habe ich bisher install_kernel nicht gefunden: Sie liegt vieleicht im Rescue-Bereich?

Evtl. ist /usr/bin/update_software nur ein Relikt aus Vorgänger-Versionen.
.
Das Script /usr/bin/update_software kann mit der Option -f aufgerufen werden. Damit wird der Test 'install_kernel -check $1' unterdrückt.

[Lemmi]

Neueste Erkenntnisse:

Die MD5SUM wird ab Position 0x400 (Name der Box) berechnet.

Zum Update wurde
# /pvr/bin/update_flash /pvr/media/USB-HDD/firmware/1.18-dc1.wsw 180 275 510 295
aufgerufen.

[bebibaer]

'update_flash' ohne Parameter antwortet mit 'usage: update_flash <update_file> [x1 y1 x2 y2] [bg_hex fg_hex]':
Was haben die Parameter für eine Bedeutung?

War das eine ernsthafte Frage :confused:
Wie wäre es mit einem Fortschrittsbalken, der durch die seine Eckkoordinaten und Vorder- und Hintergrundfarben spezifiziert wird? :D

[Lemmi]

Neue Infos zum Aufbau des WSW-Headers (http://www.m740.de/forum/showthread.php?p=2151#post2151)

An Adresse 0x006 befindet sich ein zwei Byte Wort mit der Anzahl der Bytes der RSA-Prüfsumme. Dieser Wert ist bisher immer 44. Daher folgen auch 44 Bytes dieser Prüfsumme. Werden diese 44 bytes dem Programm rsadecode mit dem Schlüssel /etc/.rsapublic via stdin übergeben, dann erfolgt eine stdout Ausgabe der MD5SUM. Die MD5SUM wird dabei ab Adresse 0x400 der WSW-Datei berechnet.

Der public key lautet: (3 Zeilen)

674A74D2DEA7D3CB4A637
#
CC5250D76B8B8FC0AA13


Ruft man rsadecode mit ungültigen Schlüssel auf, dann liefert das Programm die Meldung:


rsadecode: corrupt keyfile
keyfile format:
<n in hex>
<delimiter> (1 char)
<e/d in hex>
white spaces are ignored


Hier brauche ich Hilfe:
Wer kann mir nun ein Programm nennen/erzeugen/liefern, welches aus einer MD5SUM eine 44 byte lange Prüfsumme erzeugt, die dann mittels 'rsadecode' dekodiert wieder die Prüfsumme ergibt. private und public Schlüssel können hierfür neu erstellt werden.

[Lemmi]

Hier brauche ich Hilfe:
Wer kann mir nun ein Programm nennen/erzeugen/liefern, welches aus einer MD5SUM eine 44 byte lange Prüfsumme erzeugt, die dann mittels 'rsadecode' dekodiert wieder die Prüfsumme ergibt. private und public Schlüssel können hierfür neu erstellt werden.

Das hat sich erledigt: siehe Thread HURRA: Eigenes WSW-Update / RSA überlistet! (http://www.m740.de/forum/showthread.php?p=2346#post2346)

[gambler]

Ich habe mal wavebox von der Telnet-Konsole gestartet. Bei FW 1.12 kann man ja den Start unter /var/etc/rc auskommentieren. Da kommen eine Menge Ausschriften (auch während des Updates von 1.12 auf 1.18), die noch zu anlysieren sind. Man darf das dann beim Update nur nicht unterbrechen.

Leider funktioniert die Umleitung der Ausgabe in eine Datei nicht. Trotz Umleitung (/data/wavebox 2>&1 > /tmp/w.log) werden die meisten Ausgaben auf der Console angezeigt und mein xterm - Puffer war zu klein.

wavebox -h ist ein shutdown ;)
über die ausgabe kann man dann verfolgen wie die box sich herrunter fährt.
ist mir mit wavebox -help aufgefallen.

[Lemmi]

Leider funktioniert die Umleitung der Ausgabe in eine Datei nicht. Trotz Umleitung (/data/wavebox 2>&1 > /tmp/w.log) werden die meisten Ausgaben auf der Console angezeigt und mein xterm - Puffer war zu klein.

Da empfehle ich PuTTY, der automtisch ein LOG-File führen kann. Das benutze ich nämlich bei all meinen Experimentier-Sitzungen, um ggf. nachvollziehen zu können, was ich eigentlich getan habe.

So habe ich z.B. beim ausbaldobern der RSA-Überlistung das Script watch-it auf der Console laufen lassen und dann Updates durchgeführt.

Script watch-it

#!/bin/sh
while true ; do
echo "-----"
date
echo "-----"
ps xa
echo "-----"
ls -l /var/tmp
echo "-----"
cat /var/tmp/verify*.txt
echo "-----"
sleep 1
done

Die Ausgabe brachte dann die erwünschten Infos.

[starblue]

private und public Schlüssel können hierfür neu erstellt werden.

Hallo Lemmi,

das ist garnicht nötig, der Schlüssel ist so klein, daß man den in Nullkommanichts knacken kann:

- erste Zeile in Dezimal umwandeln gibt 7804435597319901870859831
- Faktorizieren mit Calc <http://www.numbertheory.org/calc/krm_calc.html> ergibt

7804435597319901870859831 has the following factorization:

prime factor: 2034114505639 exponent: 1
prime factor: 3836772991729 exponent: 1
2

Das paßt zum Modulus n von RSA, genau zwei fast gleich große Primfaktoren.

- Die dritte Zeile wird dann wohl der öffentliche Exponent e sein, in Dezimal ist er 964881220762341990246931.

- Mit congr(964881220762341990246931,1,78044355973140309 83362464, &x) ergibt das den privaten Exponenten 1307038986519363948733339, der auch bei einem Test mit mpower funktioniert.

Bleibt nur noch das Datenformat für die Verschlüsselung ...

Jürgen

[Lemmi]

das ist garnicht nötig, der Schlüssel ist so klein, daß man den in Nullkommanichts knacken kann:

Das ist natürlich noch besser -- dann kann man Original-Updates bauen ;)

Ich habe nur keine Ahnung von RSA & Co.

Ist das richtig:
Jetzt brauche ich nur noch ein Programm, was aus dem Schlüsselpaar und der MD5SUM eine Prüfsumme erstellt, die dann in das Update geschrieben wird.

[starblue]

Das ist natürlich noch besser -- dann kann man Original-Updates bauen ;)

Ich habe nur keine Ahnung von RSA & Co.

Ist das richtig:
Jetzt brauche ich nur noch ein Programm, was aus dem Schlüsselpaar und der MD5SUM eine Prüfsumme erstellt, die dann in das Update geschrieben wird.

Genau, ist nur die Frage, wie das Datenformat aussieht.
Die Verschlüsselung geht so: verschlüsselt = klar ^ d mod n, dafür gibt's auch Bibliotheken.
Für eine md5-Prüfsumme (=128 Bit) brauchst du wohl mehrere Verschlüsselungen(~84 Bit).

Jürgen

[Lemmi]

der auch bei einem Test mit mpower funktioniert.
....
Bleibt nur noch das Datenformat für die Verschlüsselung ...


Ich beschäftige mich gerade ein wenig mit RSA und habe nochmals genau deinen Beitrag studiert.


Was ist mpower? Ich suche nämlich ein Programm (Linux lieber als Win), welches bei gegebenen Schlüsseln die MD5-Prüfsumme kodiert.
.
Für das Update wird eine MD5-Prüfsumme (Format "123...789 -") mittels RSA verschlüsselt und dann im Binärformat im Update abgelegt. Beantwortet dass deine Frage nach dem Datenformat?
.
Hintergrund:
Am Wochenende will ich ein Update testen. Es wäre toll, wenn es die richtige Prüfsumme hätte.

[starblue]

Ich beschäftige mich gerade ein wenig mit RSA und habe nochmals genau deinen Beitrag studiert.


Was ist mpower? Ich suche nämlich ein Programm (Linux lieber als Win), welches bei gegebenen Schlüsseln die MD5-Prüfsumme kodiert.
.
Das ist eine Funktion in Calc, die genau die gewünschte Potenz-modulo berechnet.
Calc ist leider keine freie Software, eignet sich aber gut als Taschenrechner zum Ausprobieren, und kann auch schnell Faktorisieren.
Aber es gibt genügend andere Software, jede Software die RSA macht, muß das können, z.B. gcrypt.



Für das Update wird eine MD5-Prüfsumme (Format "123...789 -") mittels RSA verschlüsselt und dann im Binärformat im Update abgelegt. Beantwortet dass deine Frage nach dem Datenformat?

Ist zu unpräzise, würde ich sagen. Eine einzelne RSA-Verschlüsselung hat zu wenige Bits, also wird es wohl mehrere geben, in einem bestimmten Format.



Hintergrund:
Am Wochenende will ich ein Update testen. Es wäre toll, wenn es die richtige Prüfsumme hätte.

Muß mir mal die Daten genauer anschauen, hab aber leider im Moment wenig Zeit.

Jürgen

[starblue]

Muß mir mal die Daten genauer anschauen, hab aber leider im Moment wenig Zeit.


Konnte es doch nicht lassen, und es ist viel einfacher als gedacht:
- rsadecode kopiert nach rsaencode
- privater Schlüssel ist

674A74D2DEA7D3CB4A637
#
114C6B9B62204EFED639B

- rsaencode mit privatem Schlüssel auf Ergebnis von md5sum loslassen.
- rsadecode dekodiert das dann mit /etc/.rsapublic sauber

Viel Vergnügen :D

Jürgen

[gambler]

wow, respeckt.... feine arbeit :D
dann steht wohl einem update ohne tricksen nichts mehr im wege.

[Lemmi]

Viel Vergnügen :D


Thanx (Kommentar, weil der Text >=10 Zeichen haben muß :p)

[Lemmi]

Wie wir ja wissen, wird der Flash-Ram-Bereich /dev/mtdblock2 (==/dev/mtd2) unter /data gemounted.

Nun habe ich untersucht, wie sich /dev/mtdblock2 ändert. Dazu habe ich jede Minute eine Kopie gezogen und dann jeweils paarweise miteinander verglichen. Der Vergleich erfolgte blockweise (64K), den der Flash-Ram muß vor jedem Schreiben blockweise gelöscht werden. /dev/mtd2 hat 92 solcher Blöcke.

Es folgt ein Vergleich über >2h, wobei modifizierte Blöcke durch '#' dargestellt werden. Sollte sich von einer zur nächsten Minute nichts geändert haben, dann wird eine Leerzeile dargestellt:


1900:
1901:
1902:
1903:
1905:
1906:
1907:
1908:
1909:
1910:
1911:
1912:
1914:
1915:
1916:
1917:
1918:
1919:
1920:
1921:
1922: #-------------------------------------------------------------------------------------------
1924:
1925: -#------------------------------------------------------------------------------------------
1926:
1927:
1928:
1929:
1930: --##########--------------------------------------------------------------------------------
1931: ------------####-##################################################-------------------------
1933: ------------------##--------------#----------------#----------------------------------------
1934:
1935: --#---------------------------------------------#---##--------------------------------------
1936: --#---------------#---------------#----------------#-------------##-------------------------
1937: --##--------------------------#-------------#--------#--------###-#-------------------------
1939: ------------------------------#-------------#---#--------#####-###-#####--------------------
1940: ------------------------------------------------------------------------####################
1941: -------------------------------------------##-----------#-----#-----------------------------
1942: ------------------------------------------------------##----##------------------------------
1943: ---------------------------------------------#---#-------###--------------------------------
1945: ---------------------------------------------------------#----------------------------------
1946:
1947: --------------------------------------##--##--##--------##----------------------------------
1948: #--------------------------------#-#----##---###-#----##------------------------------------
1949: -----------------------------------#-###--#---#---------------------------------------------
1950: -----------#-----------#-------#-#--#---##--------------------------------------------------
1951: #--------------------#-######--#----####----------------------------------------------------
1953: -----#----######-----##-####-#--#-----------------------------------------------------------
1954: --------##-----#------#------#--------------------------------------------------------------
1955: ----####---##-#-----------------------------------------------------------------------------
1956: -------###-------------------------------------------------------------------------------###
1957: -#-#----------------------------------------------------------------------------------------
1958: -#-##-#---------##--#-----#-----------------------#-----------------------####-#------######
1959: -------------------#------------------------------#----------------------------#------------
2000: ------------------------------------------------------------------------#-------------------
2002: --#--------------###--------------#-------------#-###-----------------###-##--##------------
2003: -------------------------------------------------------------------------#------------------
2004: -------------------------------------------------------------------------#------------------
2005:
2006: --------------------------------------------------------------------------------######------
2007: -----------------------------------------------------#----------------#---------------------
2009: ------------------------------------------------#--------------------#----------------------
2010: --#---------------#---------------#----------------##------------#####----------------------
2011: --#---------------------------#-------------#--------#--------###--###----------------------
2012: -------------------------------------------------------------#-----#------------------------
2013: ------------------------------------------------------------#-----#-------------------------
2014:
2015:
2016: -----------------------------------------------------------------#--------------------------
2017: #----------------------#------##-----#-----##----#----##########-#--------------------------
2018:
2019:
2020:
2021:
2022: #-------------------------------------------------------------------------------------------
2023:
2024:
2025: #-------------------------------------------------------------------------------------------
2026:
2027: ----------##-#------------------------------------------------------------------------------
2028: ---------------#----------------------------------------------------------------------------
2029:
2030: -----#----#-###-----------------------------------------------------------------------------
2031: ---------###---------#----------------------------------------------------------------------
2032: ------###-----##------########-###-#########-###--------------------------------------------
2033: ----##-------------------------------------------#----#####-#-------------------------------
2034:
2035: ---#-#------#-------------------------------------------------------------------------------
2036: -#-------#-#--------------------------------------------------------------------------------
2037: -#-##-####----------#-----------------------------------------------------------------------
2038: #-------------------------------------------------------------------------------------------
2039:
2040:
2041: -----------------#--#-----------------------------------------------------------------------
2042: -----------------#--------------------------------#----------------------#------------------
2043: -------------------#----------------------------#---------------------###-##----------------
2044:
2045: --#---------------##--------------#-------------#-####---------##-#-###-##------------------
2046: ----------------------------------#--------------------------------#------------------------
2047: ------------------#---------------------------------------------###-------------------------
2048: --#--------------------------------------------------#---------#----------------------------
2049: ------------------------------#-------------#--------#--------#-----##----------------------
2050: -----------------------------------------------------------###-#-###------------------------
2051: ------------------------------#---#--------##----------########-------------##--------------
2052: -----------------------#--------------------##-#-#----#-####-#------------------------------
2053: ------------------------------------------##--#--------##-----------------------------------
2054: ---------------------------------#-#-----#---#---#----##----------------------########------
2055: #----------------------------------#--###-#--###--------------------------------------###---
2056:
2057: #-------------------#--#---##--#-#-###-###-------------------------------------------#------
2058: -------------------------##-----#---###-#---------------------------------------------------
2059: ---------------------#-##---#--#------------------------------------------------------------
2100: ----------#--#------------##-#--#-----------------------------------------------------------
2101: ----------------------#---------------------------------------------------------------------
2102: -------------------------#------------------------------------------------------------------
2103: -----#--------##-----#--##---------------------------------------------------------------###
2104: ----------####------------------------------------------------------------------------------
Das ganze fing mit einer ruhigen Phase an. Dich dann veränderten sich mehr oder weniger zyklisch alle Daten.

Im folgenden habe ich die Anzahl der Veränderungen jedes Blockes in dem Zeitraum von 2:04 Stunden zusammengestellt:


Blocks 00..0f: 9 5 9 6 5 7 5 5 5 6 7 8 6 6 6 6
Blocks 10..1f: 1 5 7 6 5 6 5 8 6 7 7 6 5 5 7 7
Blocks 20..2f: 5 6 8 7 6 7 7 7 7 6 6 7 9 7 7 6
Blocks 30..3f: 7 7 6 6 5 8 7 8 8 9 7 7 8 8 7 8
Blocks 40..4f: 6 8 8 6 5 6 5 3 5 5 4 4 3 3 3 5
Blocks 50..5b: 3 3 3 3 3 4 3 3 3 4 4 4
Wie man sieht, wurde jeder Block zwichen 3 und 9 mal modifiziert. Die Rate kann ruchaus höher liegen, da ich ja nur 1x pro Minute nachgeschaut habe. Nach der PDF-Beschreibung behält der Flash seine Infos für 20 Jahre ("Data Retention: 20 years typical") und schafft 1 Million Lese-Schreib-Zyklen ("Cycling Endurance: 1 million cycles per sector"). Diese 1 Million Schreibzyklen werden nach 20 Jahren bestimmt erreicht werden.

Die viele Schreibzyklen liegen übrigens am EPG. Als ich das EPG-Verzeichnis /data/SI für 1 Stunde auf die USB-Platte auslagert hatte und auch keine Timer-Programmierung vorgenommen hatte, wurde /dec/mtd2 nicht mehr modifiziert.

Nach diese Analyse zeigt sich, das die relative wenigen Firmware Up- und Downgrades nichts ausmachen.

[Goblin]

... mit 20 Jahren (Dauerbetrieb) kann ich leben, das würde ich nicht unbedingt Designfehler nennen :-)

[Lemmi]

... mit 20 Jahren (Dauerbetrieb) kann ich leben, das würde ich nicht unbedingt Designfehler nennen :-)Meine ursprüngliche Aussage 'Designfehler' bezog sich auf das ständige Beschreiben des Flash-Rams, für den nur 1 Million Lese-Schreib-Zyklen vorgesehen sind. Da der Flash aber zyklisch beschrieben wird, mindert sich mein zuerst angenommene Verdacht erheblich.

[starblue]

Meine ursprüngliche Aussage 'Designfehler' bezog sich auf das ständige Beschreiben des Flash-Rams, für den nur 1 Million Lese-Schreib-Zyklen vorgesehen sind. Da der Flash aber zyklisch beschrieben wird, mindert sich mein zuerst angenommene Verdacht erheblich.
Die benutzen JFFS2, das ist speziell dafür vorgesehen.
Mit deinen Zahlen kommt man für 1000000 Schreibzyklen auf >20 Jahre.

Also ist alles ok, viele Computerteile halten weit weniger lange (Festplatten, Kondensatoren,...).

[Lemmi]

@drei
Ja, ich bin mir ziemlich sicher, dass die Daten direkt ins Flash geschrieben werden.

@starblue
Ich habe ja meine Assage 'gemindert'.
1.) Zuerste hatte ich nur festgestellt, dass der Flash ständig beschrieben wird.
2.) Dann habe ich festgestellt, dass nur zyklisch einige Blöcke geschrieben werden, was den Zeitraum für die 1 Million Schreibzyklen pro Block erheblich verlängert.
3.) Ich weiß ja, dass das EPG-Update die Ursache ist. Jetzt müßte man überprüfen, wann und wie häufig diese Update stattfinden.

[starblue]

Wissen wir eigentlich genau, was beim Schreiben passiert? Wird DIREKT in den Flash-Speicher geschrieben, oder in einen RAM-Bereich, der dann seinerseits ins Flash kopiert wird?
Such mal nach JFFS2, dort gibt's Doku, mit schönen Diagrammen
(http://sources.redhat.com/jffs2/jffs2-html/node3.html).

Soweit ich das verstehe, wird direkt ins Flash geschrieben.

Solange wir da nicht selbst ständig schreiben wollen, lohnt es sich wohl nicht,
sich darüber den Kopf zu zerbrechen ...

[LinuxDoc]

100 000 Zyklen sind ausreichen ..sagen wie das wir 10 mal am Tag aktualisiert und ich betreibe die Box 365 Tage im Jahr, dann sollte das mehr wie 27 Jahre halten das Flash Rom...

Ich gehe nicht von aus das ich die Box mehr wie 10-15 jahre betreibe ....

[Lemmi]

Ich habe gerade einen 20h-24h Test gestartet, um die Flash-Schreib-Rate besser beurteilen zu können. Dann wird sich zeigen, ob 5/stunde ein realistischer Wert ist.

[Lemmi]

Ich habe über 24 h Stunden den angekündigten Test vorgenommen:

Jede Minute wurde eine Kopie von /dev/mtd2 gezogen. /dev/mtd2 liegt im Flash-Ram und stellt das Verzeichnis /data mit allen Unterverzeichnissen da.
Das Flash-Ram ist in Blocks zu je 6kb (==65536 Bytes) organisiert. Das bedeutet, das vor einer Schreiboperation ein kompletter Block gelöscht werden muß.
/dev/mtd2 ist 92 Blocks groß.
Das schreiben erfolgt unmittelbar oder ein paar Sekunden verzögert, nachdem Daten in /data modifiziert worden sind.
Durch das EPG werden ständig Daten in /data/SI modifiziert.


Hier ist die Anzahl der festgestellen Veränderungen über einen 24h Test. Dieser Test wurde wegen runterfahrens der Box um 6 Minuten unterbrochen. Im Anhang befindet sich der komplette Log.

Blocks 00..0f: 87 79 82 83 87 91 85 85 87 82 82 83 87 73 76 67
Blocks 10..1f: 75 88 77 71 72 76 67 67 70 76 65 69 66 78 73 67
Blocks 20..2f: 73 72 69 65 69 72 74 73 68 75 68 79 67 66 67 73
Blocks 30..3f: 74 70 70 72 68 75 74 66 75 68 76 71 76 71 61 58
Blocks 40..4f: 62 55 58 53 64 71 69 60 57 64 61 54 61 47 56 54
Blocks 50..5b: 55 56 49 59 54 50 55 53 47 42 53 49

TOTAL: 6296


Versuch einer Auswertung:

Ein Block wurde 91 mal modifiziert. Hochgerechnet auf einen 1 Jahres Dauerbetreib bedeutet deses 33215 Schreibzugriffe.
Die erwartete Lebensdauer des Flash-Rams beträgt 1 Million Schreib-Lese-Zyklen. 1 Million Schreibzyklen wären nach 30 Jahren erreicht. Die Hersteller übertreiben häufig um bis zu eine Größenordnung. Den rest kann sich jeder selbst ausrechnen.
Die Auswertung hat mindestens zwei Systematische Fehler:

Ich habe nur jede Minute kontrolliert. Dadurch wurden mehrere Schreiboperatione innerhalb eine Minute nur einmal gezählt.
Wurde der Flash während des Lesens geschrieben, dann wurde evtl. das Schreiben doppelt registriert.

Wem das alles zuviel und zu gefährlich ist, der kann das EPG auf die Festplatte bzw. ins LAN verlegen.

[Lemmi]

Ich habe diesen alten Thread nochmals nach vorne geholt, da ich ein paar neue Infos zum Flash-RAM habe:

Im Bereich /dev/mtd4 befindet sich neben dem boot sector nicht nur ein vmlinux, sondern gleich zwei. Mutmaßlich ist eines für das Normalsystem und das zweite für das Rettungssystem.

WeitereDetails befinden sich im Wiki unter Flash-RAM Abschnitt mtd4 alias boot.

@andreas.koch und Lescho:
Damit sollte sich eure gestrige Idee doch umsetzen lassen.