Guten Tag! Wenn die Firmware per Web, Mail oder Modem transportiert werden soll, ist es egal, welches Format die IDE erzeugt oder was der Bootloader versteht. Man muss eine Datei erzeugen, die den Transport heil übersteht und einen Bootloader schreiben, der das Format lesen kann. Die Datei kann unter kontrollierten Bedingen erzeugt und auf einen Webserver geladen oder per Mail verschickt werden. Am anderen Ende muss sie z.B. auf einen USB-Stick kopiert werden und da gibt es sooo viele Möglichkeiten... Auf jeden Fall muss man damit rechnen, dass die Zeilenenden beliebig verändert werden und Leerzeichen und TAB wahllos umgewandelt werden. Oder die Datei wird inline per Mail weitergeleitet und bekommt '> ' vor jede Zeile. Oder sie wird mit irgendeinem Programm geöffnet, versehentlich gespeichert und bekommt ein BOM verpasst. Was kann noch alles passieren? Also brauche ich ein Dateiformat, dass solche Mißhandlung übersteht. Der Dateiname ist noch einfach: genau 8 Zeichen, ein Punkt und 3 weitere Zeichen. Erlaubt sind nur A..Z und 0..9, das erste Zeichen muss ein Buchstabe sein. Als Dateiendung kommt wahrscheinlich nur ".TXT" in Frage, damit Virenscanner und Firewall-Filter keinen Verdacht schöpfen und Webserver das als text/plain ausliefern. Es soll auch keinen Stress geben, falls der Benutzer drauf clickt. Oder gibt es eine bessere Endung? Wonach entscheidet ein Mail-Programm, wie es einen Anhang verpackt? Spielt die Dateiendung eine Rolle? Oder der Inhalt? Man weiss es nicht, aber ".TXT" sollte halbwegs sicher sein. Der Inhalt darf natürlich auch nur ASCII-Text sein, aber selbst dann ist nicht jedes Zeichen sicher. Das beliebte S19-Format würde passen, aber es sollte etwas kompakter sein. Also bleibt nur, die reinen Binärdaten Base64 zu kodieren. Base85 wäre ideal, aber das wird als Anhang evt. umkodiert und alle bekannten Base85-Kodierungen sind nicht XML- bzw. HTML-kompatibel. Base64 könnte(!) auf jeden Fall als Anhang und im Mail Body unverändert transportiert werden. Jetzt kommt der spannende Teil: meine Firmware kann aus mehreren Teilen bestehen, damit man notfalls per GSM jeden Teil einzeln updaten kann. Wie kann man in einer Base64 kodierten Datei diese Abschnitte sicher trennen? Datei-Offset geht nicht, weil sich die Länge der Zeilenenden ändern kann. Mehrere Dateien geht nicht, weil das den Benutzer beim Download oder beim Kopieren überfordert. Welche Zeichen könnte man als Start- oder Trennzeichen verwenden? Danke für's Lesen!
:
Verschoben durch User
Dann nimm doch Base64. Hat alles was Du brauchst. Und natürlich kannst Du mit File Offsets arbeiten, aber nicht dem ASCII offset, sondern dem Offset nach dem korrekten dekodieren.
Hallo! Wie groß in Anzahl von Bytes etwa sind deine Updates? (rein binär gezählt)
> Auf jeden Fall muss man damit rechnen, dass die > Zeilenenden beliebig verändert werden und Leerzeichen und TAB > wahllos umgewandelt werden. Nein, das passierte nur beim Internet Explorer und auch das nur selten. Der Bug ist längst behoben. > Oder die Datei wird inline per Mail weitergeleitet > und bekommt '> ' vor jede Zeile. Entschuldige mal, wer macht denn sowas? Datein hängt man an, alles andere halte ich für sehr abwegig. > Oder sie wird mit irgendeinem Programm geöffnet, > versehentlich gespeichert und bekommt ein BOM verpasst. Das und das Format der Zelenumbrüche sind die einzigen Flexibilitäten, die ich beim Programmieren berücksichtigen würde. > Also brauche ich ein Dateiformat, dass solche Mißhandlung übersteht. > ... Erlaubt sind nur A..Z und 0..9 Schau Dir mal base64 an, das müsste Dir bekannt vorkommen. Und - oh wunder - genau dieses Format benutzen Email Programme intern. Wenn du mit base64 arbeitest, spielen führende und nachfolgende Leerzeichen sowie veränderte Zeilenumbrüche keine Rolle. Selbst das ">" Zeichen kann der base64 encoder wegschneiden. Probier es aus: https://www.base64decode.org/ > Wonach entscheidet ein Mail-Programm, wie es einen Anhang verpackt? Es unterscheidet nicht. Alle Anhänge werden in base64 codiert. > Wie kann man in einer Base64 kodierten Datei diese Abschnitte > sicher trennen? Ich würde einzelne Dateien übermitteln. Ansonsten denkst Du Dir halt irgendein beliebiges Dateiformat aus. Zum Beispiel ganz banal: Byte 0..1: Länge des Blockes Byte 2: Abschnitts-Nummer Byte 3..4: Prüfsumme über die Nutzdaten (optional) Byte 5+ : Nutzdaten Mehrere Abschnitte können aneinander gehängt werden. Das Unix Programm "tar" arbeitet nach diesem Prinzip. So ein Paket kann beliebig oft wiederholt werden. > Datei-Offset geht nicht, weil sich die Länge der Zeilenenden > ändern kann. Betrachte die Abschnitte als Ansammlungen von Bytes. Selbst wenn dein Update aus Text (z.B. eine HEX Datei besteht) besteht, behandle es trotzdem wie eine Ansammlung von Bytes ohne deren Inhalt zu interpretieren. Änderungen am Inhalt würde ich gar nicht zulassen. Nicht ein einziges Bit. Das einzige, was in gewissem maße verändert werden darf, ist der base64 codierte Datenstrom.
1 | Abschnitt 1 \ (Bytes) (Text) |
2 | +Abschmitt2 |-------------base64 encoder-------------Senden |
3 | +Abschnitt2 / |
1 | (Text) (Bytes) / Abschnitt 1 |
2 | Empfangen-------------base64 decoder-----------| +Abschnitt 2 |
3 | \ +Abschnitt 3 |
Heutzutage wird doch alles binär übertragen. Zip, Pfd, Jpg... Irgendwelche Zeichen im Ascii umcodieren macht auch kein Programm mehr. Text wird heute als UTF8 verschickt. Heutzutage wird die Firewall misstrauisch, wenn sie Base64 in *.txt findet.
> Irgendwelche Zeichen im Ascii umcodieren macht auch kein Programm mehr.
Doch, und zwar jedes Email Programm und auch jeder Webserver/Browser.
Das WWW ist trotz zahlreicher Erweiterungen immer noch sehr
traditionell.
Können wir und drauf einigen: Wenn du in einem Emailprogramm einen Anhang speicherst, oder in einem Webbrower "Ziel speichern" anklickst, landet die Datei unverändert auf deiner Platte? Iso8859<->cp437, oder Zeilenende in crlf konvertieren... das machen die Programme nicht mehr.
Du übertreibst. Heutzutage dumpt keiner mehr die per Telnet übermittelten SMTP-Rohdaten in ein archaisches Kommandozeilenprogramm, was dann das Update durchführt. Intel-Hex erfüllt deine Anforderungen: - jede Zeile fängt mit ':' an, es folgen nur [0-9A-Z] - jede Zeile hat ihre eigene Prüfsumme - Müll am Zeilenende kann man problemlos ignorieren - Zeilen innerhalb eines 64 KB-Segments sind unabhängig voneinander - kann man als TXT speichern. Vermutlich gilt das für Motorolas SREC auch. Für einen base64-Datenstrom gilt das nicht, weil du ja im Prinzip beliebige Zeichen am Zeilenende injizieren können möchtest. Allgemein musst du aber aus einem beliebig verstümmeltem Datenstrom nicht mehr mit Aufwand die korrekten Bits rauspopeln können. Die meisten Kanäle sind bidirektional und haben genug Bandbreite für eine erneute Übertragung. Das gilt auch für den Benutzer, der die Datei neu runterladen und auf den Stick kopieren kann. Wenn du das nicht hast, kannst du genug Forward Error Correction einbauen. Hauptsache, du kannst nach der Übertragung die Integrität des Updates sicherstellen.
Wenn der TO davon ausgeht, dass seine Datei mehr oder weniger beliebig misshandelt werden kann, sollten wir ihm das erst mal glauben. Es ist i.d.R. sinnvoller, die Kodierung dem Kanal anzupassen als den Kanal der Kodierung. Andy Grove hatte schon recht, "only the paranoid survive". Was ich noch gerne wüsste: wie kommen denn die Daten am Ende ins Zielgerät? Steht da ein PC, der per USB/seriell/JTAG/whatever dann die Rohdaten rüberschaufelt, oder mailst du das Update ans Zielgerät, oder was passiert da? Wenn du an jeder Firewall vorbei willst, muss man vermutlich textsteganografische Methoden verwenden. Das wird der TO aber vermutlich nicht wollen, oder?
Ich habe gerade die Feststellung gemacht, daß beim Apdate des Xoro-DVBT2-Empfängers die neue Firmware nicht erkannt wurde (aus dem Internet runtergeladen). Meldung: Datei nicht erkannt. Aber mit der anderen, einer zweiten, gepackten Datei von der Herstellerseite, ging es dann ohne weiteres. Die hatte ich vorher am PC entpackt. Ist das gemeint?
> Wenn der TO davon ausgeht, dass seine Datei mehr oder weniger beliebig > misshandelt werden kann, sollten wir ihm das erst mal glauben. Ja. So etwa 99,9% der Misshandlungen sind Download abgebrochen, unvollständige Datei übrig geblieben. Und 0,1% speichern das Html der Downloadseite ab und benennen dann die Datei um.
Laaangsam, ich kann garnicht so schnell lesen wie ihr schreibt ;) Route 6. schrieb: > Wie groß in Anzahl von Bytes etwa sind deine Updates? > (rein binär gezählt) aktuell ca. 80KB, aber es wäre nett, wenn das Format auch für Linux-Anwendungen reichen würde. Da sind's z.Zt. vielleicht 5MB. Stefan U. schrieb: >> Oder die Datei wird inline per Mail weitergeleitet >> und bekommt '> ' vor jede Zeile. > > Entschuldige mal, wer macht denn sowas? Die Benutzer? Vielleicht nicht genau das, aber dann etwas ähnlich Verrücktes. > Schau Dir mal base64 an Hab' ich, es scheint die einzig sinnvolle Kodierung zu sein. >> Wonach entscheidet ein Mail-Programm, wie es einen Anhang verpackt? > Es unterscheidet nicht. Alle Anhänge werden in base64 codiert. Doof. Bandbreitenverschwendung. Aber wenn das so einfach geregelt ist, wird es wohl funktionieren. > Ich würde einzelne Dateien übermitteln. Dann müsste der Boot Loader prüfen, ob keine fehlt und ob die überhaupt alle zum gleichen Update gehören. Das wird aufwendig, bis jetzt kann er keine Fehlermeldungen ausgeben, nur ok/nicht ok. > Änderungen am Inhalt würde ich gar nicht zulassen. Nicht ein > einziges Bit. Eh klar. Dafür gibt's für jeden Abschnitt CRC32 und für deine optionale Prüfsumme würde ich auch CRC32 einbauen. > Das einzige, was in gewissem maße verändert werden darf, > ist der base64 codierte Datenstrom. Ich könnte einfach alle nicht-base64-Zeichen ignorieren. Damit wird die Fehlererkennung aber schlechter. Wie man's macht, ist's verkehrt... Noch einer schrieb: > Heutzutage wird die Firewall misstrauisch, wenn sie Base64 in *.txt > findet. Sehr guter Einwand, genau wegen sowas hab' ich hier gefragt. Wie soll man Firmware denn dann verpacken? Quelltext? USB-Stick per Paket verschicken? Flash wird vom Röntgenscanner gelöscht. Einen Spezialisten hinschicken? Laptop-Verbot im Flugzeug. Dann eben nicht. Noch einer schrieb: > Können wir und drauf einigen: Wenn du in einem Emailprogramm einen > Anhang speicherst, oder in einem Webbrower "Ziel speichern" anklickst, > landet die Datei unverändert auf deiner Platte? Nein. Im wirklichen Leben passiert das nur meistens. S. R. schrieb: > Du übertreibst. Übertreibung macht deutlich, sagt man. Mir geht's nicht um technische Übertragungsfehler, ich denke, die hat man im Griff. Ich suche erstmal ein paar Ideen, was Benutzer alles anstellen könnten. Max G. schrieb: > Was ich noch gerne wüsste: wie kommen denn die Daten am Ende > ins Zielgerät? In einer konkreten Anwendung wird ein USB-Stick zu einem Linux-Rechner mit Monitor getragen, also alles total einfach. Und selbst da sind schon Dateien auf dem Weg zwischen Mail und USB-Stick verändert worden. Der aktuelle Anlass ist ein Cortex-M3, der über eine serielle Schittstelle und ein VDrive3 die Datei vom USB-Stick lesen soll. Außerdem sollte ein Update per GSM-Modem möglich sein, wobei sich der Boot Loader mehrere Dateien von einem Webserver holt. Eine halbwegs kompakte Kodierung ist also nicht unwichtig. juergen schrieb: > Ich habe gerade die Feststellung gemacht, daß beim Apdate des > Xoro-DVBT2-Empfängers die neue Firmware nicht erkannt wurde (aus dem > Internet runtergeladen). Meldung: Datei nicht erkannt. > > Aber mit der anderen, einer zweiten, gepackten Datei von der > Herstellerseite, ging es dann ohne weiteres. Die hatte ich vorher am PC > entpackt. > > Ist das gemeint? Im Prinzip ja, es passieren einfach seltsame, unerklärliche Dinge. Wobei ich es eher umgekehrt kenne: je mehr der Benutzer macht, umso eher geht es schief.
Noch einer schrieb: > Ja. So etwa 99,9% der Misshandlungen sind Download abgebrochen, > unvollständige Datei übrig geblieben. Und 0,1% speichern das Html der > Downloadseite ab und benennen dann die Datei um. Manche Browser packen GZIP-komprimierte Daten auch einfach aus, ohne den Benutzer zu informieren. Das war der Webserver falsch konfiguriert. eagle user schrieb: > Mir geht's nicht um technische Übertragungsfehler, > ich denke, die hat man im Griff. Ich suche erstmal > ein paar Ideen, was Benutzer alles anstellen könnten. Nun, er könnte die in Word öffnen, ein paar Sätze Prosa reinschreiben, das ganze als DOCX abspeichern, nochmal mit 7-Zip komprimieren und erst dann an deinen Updater übergeben. Irgendwo musst du eine Grenze ziehen. eagle user schrieb: > Der aktuelle Anlass ist ein Cortex-M3, der über eine serielle > Schittstelle und ein VDrive3 die Datei vom USB-Stick lesen soll. Bandbreite ist unwichtig, nimm einfach IHEX oder SREC. Ohne Absicht kriegst du das Datei nicht kaputt, die Records haben Prüfsummen und das Gesamtergebnis sicherlich auch. > Außerdem sollte ein Update per GSM-Modem möglich sein, wobei sich der > Boot Loader mehrere Dateien von einem Webserver holt. Bandbreite ist wichtig, nimm eine Binärdatei, bilde eine Prüfsumme und komprimiere zusätzlich. Das ist ein vollautomatisches System ohne Benutzerinteraktion, also pfuscht da keiner rein. > Eine halbwegs kompakte Kodierung ist also nicht unwichtig. Bei 80 KB über GSM kann man darüber zwar streiten, aber nun gut. > Im Prinzip ja, es passieren einfach seltsame, unerklärliche Dinge. Wobei > ich es eher umgekehrt kenne: je mehr der Benutzer macht, umso eher geht > es schief. Dann verbiete dem Benutzer, irgendwas zu tun. Prinzip Apple.
> Xoro-DVBT2-Empfängers die neue Firmware nicht erkannt wurde > Ist das gemeint? SIcher nicht. Bei den XORO DVB-T2 Empfängern muss man auf die Hardware-Revision achten. Die verkaufen unterschiedliche Geräte mit dem selben Namen. Wenn du das falsche Image in den USB Port steckst, erscheint genau die von Dir genannte Fehlermeldung. Ich bin auch drauf hereingefallen.
eagle user schrieb: > Auf jeden Fall muss man damit rechnen, dass die > Zeilenenden beliebig verändert werden und Leerzeichen und TAB wahllos > umgewandelt werden. Oder die Datei wird inline per Mail weitergeleitet > und bekommt '> ' vor jede Zeile. Oder sie wird mit irgendeinem Programm > geöffnet, versehentlich gespeichert und bekommt ein BOM verpasst. Was > kann noch alles passieren? Man kann eine Datei als Zip-Datei verpacken. Da ist es mir noch nie passiert, dass da irgendwelche CR/CRLF umgwandelt werden oder denen ein BOM verpasst wurde. Bilder kommen bei mir auch immer heil an, obwohl sich da bestimmt an der einen oder anderen Stelle ein 0x0D o.ä. drin verbirgt.
my2ct schrieb: > Da ist es mir noch nie > passiert, dass da irgendwelche CR/CRLF umgwandelt werden oder denen ein > BOM verpasst wurde Irgendwelche Fehler der Benutzer zu korrigieren ist der völlig falsche Weg. Ein Firmware-Update ist ein so kritischer Vorgang, dass nur Daten dafür in Frage kommen, an denen absolut NICHTS verändert wurde. Die Datei wird mit CRC, Hash o.ä. abgesichert und nur eine verifizierte Datei ist überhaupt zum Update zugelassen. Georg
Georg schrieb: > Die Datei wird mit CRC, Hash o.ä. abgesichert und nur eine verifizierte > Datei ist überhaupt zum Update zugelassen. Völlige Zustimmung, bei der Fragestellung gehen bei mir sämtliche Murksalarmglocken los. Außerdem ist das ja sehr weit hergeholt - ein völliger Computeranalphabet hantiert doch eh nicht mit Firmware.
my2ct schrieb: > Man kann eine Datei als Zip-Datei verpacken. Da ist es mir noch nie > passiert, dass da irgendwelche CR/CRLF umgwandelt werden (...) Zufälle gibt's! Gestern Abend, ich so: "wie geht's", Bekannter so: "so viel Stress... und jetzt muss ich alles noch mal einzeln verschicken, weil ein paar Leute kein zip auspacken können". Tja... Jan H. schrieb: > Außerdem ist das ja sehr weit hergeholt - ein völliger > Computeranalphabet hantiert doch eh nicht mit Firmware. Ein völliger Computeranalphabet wäre in der Tat ein kleineres Problem, der bekäme den USB-Stick per Post und müsste ihn nur noch richtig rum einstecken und eine Taste drücken. Georg schrieb: > Irgendwelche Fehler der Benutzer zu korrigieren ist der völlig falsche > Weg. Ein Firmware-Update ist ein so kritischer Vorgang, dass nur Daten > dafür in Frage kommen, an denen absolut NICHTS verändert wurde. Die > Datei wird mit CRC, Hash o.ä. abgesichert und nur eine verifizierte > Datei ist überhaupt zum Update zugelassen. Das stimmt natürlich für das eigentliche Image, das hat ja immer seine eigenen Prüfsumme. Aber wenn es base64-kodiert transportiert wird, kann man doch zumindest white space Änderungen drum herum tolerieren. Recht viel mehr will ich in einen Boot Loader auch nicht einbauen.
eagle user schrieb: > Zufälle gibt's! Gestern Abend, ich so: "wie geht's", Bekannter so: "so > viel Stress... und jetzt muss ich alles noch mal einzeln verschicken, > weil ein paar Leute kein zip auspacken können". Tja... Dann nenne die Datei anschließend um. Machen Google, MicroSoft oder Oracle doch auch. KMZ, DOCX oder JAR funktioniert bei Millionen von unbedarften Nutzer.
Hi eagle user schrieb: > weil ein paar Leute kein zip auspacken können". Tja... Kann Linux ootb (out of the box - also 'von Haus aus' - ganz ohne Packprogramm-Kopie) my2ct schrieb: > Dann nenne die Datei anschließend um. Das hilft Dir aber auch nicht wirklich, da die umbenannte Datei ja trotzdem 'entzipt' werden muß - wenn Das der User nicht hinbekommt, muß Das Dein Programm können. MfG
eagle user schrieb: > Also brauche ich ein Dateiformat, dass solche Mißhandlung übersteht. Das brauchst Du nicht, das Thema funktionierende MIME-Codierung von Anhängen in Emails, Internetdownloads etc. wurde vor mindestens zwei Jahrzehnten zur allgemeinen Zufriedenheit gelöst. Hast Du ernsthaft Probleme damit, z.B. ZIP-Dateien per Email zu versenden oder zu empfangen? Dann solltest Du Dir Deinen Email-Client ansehen, der ist dann nämlich kaputt.
Rufus Τ. F. schrieb: > Hast Du ernsthaft Probleme damit, z.B. ZIP-Dateien per Email zu > versenden oder zu empfangen? Ja. Zum Beispiel gestern beim Kollegen kommt ZIP überhaupt nicht in Frage, die Empfänger brauchen die Dateien einzeln, weil sie keinen Entpacker haben oder nicht bedienen können. Im anderen Fall ist irgendwo zwischen Mail-Empfang und USB-Stick etwas verändert worden. Der Benutzer hat die einzelnen Dateien auf seinem Laptop zwischengelagert, evt. auch auf einem Netzwerklaufwerk. Sowas kann man schlecht verbieten, aber mit einer einzelnen Datei gibt es weniger Fehlerquellen. Patrick J. schrieb: > Das hilft Dir aber auch nicht wirklich, da die umbenannte Datei ja > trotzdem 'entzipt' werden muß - wenn Das der User nicht hinbekommt, muß > Das Dein Programm können. Das wäre der Boot Loader - lieber nicht, ist ja auch nicht nötig. Peter D. schrieb: > Was stört Dich an IHEX? Es erinnert an Intel und ich bin mit S19 groß geworden ;) Beide Formate sind halt etwas sperrig, meine Binärdaten sind base64-kodiert ziemlich genau halb so groß wie im S19-Format. Beim Transport per HTTP oder SMTP sehe ich zwischen den dreien keinen Unterschied, nur, wenn eine langsame serielle Verbindung ins Spiel kommt.
eagle user schrieb: > Zum Beispiel gestern beim Kollegen kommt ZIP überhaupt nicht in Frage, > die Empfänger brauchen die Dateien einzeln, weil sie keinen Entpacker > haben oder nicht bedienen können. Du hast nicht verstanden, was ich meinte. Der Vorschlag lautete nicht "nimm ZIP-Dateien". Wenn Du ZIP-Dateien zerstörungsfrei versenden und empfangen kannst, und es möglich ist, sie zerstörungsfrei auf einem USB-Stick zu transportieren, dann kannst Du auch jedes beliebige andere Dateiformat versenden, empfangen und transportieren. Du musst dafür also kein neues Dateiformat erfinden, das ist komplett überflüssig. > Im anderen Fall ist irgendwo zwischen Mail-Empfang und USB-Stick etwas > verändert worden. Das ist ein Problem der Nutzerkompetenz. Das kannst Du mit Dateiformaten nicht lösen. Wenn man versucht, etwas idiotensicher zu machen, dauert es nicht lang, und sie erfinden einen besseren Idioten.
Rufus Τ. F. schrieb: > Das ist ein Problem der Nutzerkompetenz. Das kannst Du mit Dateiformaten > nicht lösen. Man kann die Nutzer/Idioten ausschliessen: Industrie 4.0, IOT, das Gerät holt die Updates aus dem Internet ohne die Bediener lange zu fragen. Ob das besser ist, ist wohl eine philosophische Frage, aber jedenfalls liegt es voll im Trend. Georg
eagle user schrieb: > Auf jeden Fall muss man damit rechnen, dass die > Zeilenenden beliebig verändert werden und Leerzeichen und TAB wahllos > umgewandelt werden. Unfug. Wer hat Dir denn so einen Schmarrn erzählt? Wenn Dateinhalte beliebiger Dateien sich beim Umherkopieren andauernd einfach so lustig ändern würden hätte das wohl schon längst jemand bemerkt, das Netz wäre voll von Hilferufen und Beschwerden darüber (vorausgesetzt daß überhaupt noch ein Computer auf dieser Welt vernünftig funktionieren würde unter solchen eigenartigen Umständen und es das Internet je gegeben hätte), meinst Du nicht?
>> Hast Du ernsthaft Probleme damit, z.B. ZIP-Dateien per Email zu >> versenden oder zu empfangen? > Ja. Zum Beispiel gestern beim Kollegen kommt ZIP überhaupt nicht in > Frage, die Empfänger brauchen die Dateien einzeln, weil sie keinen > Entpacker haben oder nicht bedienen können. Entschuldige mal, seit Windows 95 ist diese Funktion doch Bestandteil des Dateimanagers. Man öffnet ZIP Dateien durch doppelklick, so wie man auch alle anderen Dateien öffnet. Unter Linux und Mac geht das sogar noch länger. Selbst die meisten Smartphones können das ohne Zusatzprogramme. Die ganze Geschichte wirkt von Anfang bis Ende an den Haaren herbeigezogen. Ich glaube Dir kein Wort.
eagle user schrieb: > Auf jeden Fall muss man damit rechnen, dass die Zeilenenden beliebig > verändert werden und Leerzeichen und TAB wahllos umgewandelt werden. Oder > die Datei wird inline per Mail weitergeleitet und bekommt '> ' vor jede > Zeile. Oder sie wird mit irgendeinem Programm geöffnet, versehentlich > gespeichert und bekommt ein BOM verpasst. > Der Dateiname ist noch einfach: genau 8 Zeichen, ein Punkt und 3 weitere > Zeichen. Warum? Muss es auch mit MSDOS funktionieren? > Als Dateiendung kommt wahrscheinlich nur ".TXT" in Frage, damit > Virenscanner und Firewall-Filter keinen Verdacht schöpfe und Webserver > das als text/plain ausliefern. Eben genau das nicht! Die genannten Probleme resultieren nämlich gerade daraus, dass du es als Text übertragen willst. Nimm direkt die Binärdaten, und packe einen eigenen Header davor, der Infos über die Firmware und natürlich auch eine CRC enthält. So habe ich das auch schon erfolgreich gemacht. Wenn man als Dateiendung nicht gerade sowas wie .EXE oder .BAT nimmt, ist das normalerweise auch kein Problem. > Wie kann man in einer Base64 kodierten Datei diese Abschnitte sicher > trennen? Datei-Offset geht nicht, weil sich die Länge der Zeilenenden > ändern kann. Mehrere Dateien geht nicht, weil das den Benutzer beim > Download oder beim Kopieren überfordert. Welche Zeichen könnte man als > Start- oder Trennzeichen verwenden? Nimm ein einfaches Archivformat wie ar oder so. Das wird z.B. als Dateiformat von Packetmanagern unter Linux verwendet. Die werden auch auf allen möglichen Wegen übertragen und kommen funktionsfähig an. my2ct schrieb: > Man kann eine Datei als Zip-Datei verpacken. Da ist es mir noch nie > passiert, dass da irgendwelche CR/CRLF umgwandelt werden oder denen ein > BOM verpasst wurde. Also ein Binärfile base64 codieren, damit es Text ist, dann als zip verpacken, damit es kein Text mehr ist? Klingt wenig sinnvoll.
Na gut, überredet, also reine Binärdaten ohne Kodierung und ohne Verpackung. Damit reduziert sich meine Frage auf: Welche Dateiendung? Es soll halt bei einem Doppelklick nichts passieren. Und ja, natürlich versuchen die Benutzer, die Datei zu öffnen. Auf einem eigenen Webserver kann ich evt. mit Content-Disposition noch etwas beeinflussen, aber per Mail habe ich wohl nur die Dateiendung. Rolf M. schrieb: >> Der Dateiname ist noch einfach: genau 8 Zeichen, ein Punkt und 3 weitere >> Zeichen. > > Warum? Muss es auch mit MSDOS funktionieren? Nicht direkt mit MSDOS, aber mit FAT ohne lange Dateinamen. Das VDrive3 kann nichts anderes, ist aber ansonsten perfekt für diesen Zweck.
eagle user schrieb: > Auf einem eigenen Webserver kann ich evt. mit Content-Disposition noch > etwas beeinflussen, aber per Mail habe ich wohl nur die Dateiendung. Bei der Mail gibt es auch noch einen Mimetype, aber dass das System den nachher auch noch nutzt, ist dann eher unwahrscheinlich. > Rolf M. schrieb: >>> Der Dateiname ist noch einfach: genau 8 Zeichen, ein Punkt und 3 weitere >>> Zeichen. >> >> Warum? Muss es auch mit MSDOS funktionieren? > > Nicht direkt mit MSDOS, aber mit FAT ohne lange Dateinamen. Das VDrive3 > kann nichts anderes, ist aber ansonsten perfekt für diesen Zweck. Ok, verstehe. Ohne diese Einschränkung hätte ich einfach eine Endung mit mehr als drei Buchstaben genommen. Da ist bei guter Wahl die Wahrscheinlichkeit erheblich geringer, dass der Benutzer ein Programm installiert hat, das dieser zugeordnet ist. Dann denk dir was aus und such mal im Internet, zu welchem Programm diese Dateiendung schon gehört. Wenn dabei was hinreichend obskures rauskommt, nimm das. ;-)
eagle user schrieb: > Sind eigentlich Dateien ohne Endung praktikabel? Üblich unter Unix/Linux: was die Datei darstellt, wird durch die Ordnerstruktur definiert. Hat den schönen Nebeneffekt, dass ohne die exakte Erhaltung der Ordnerstruktur die Daten unbrauchbar werden, was besonders Datensicherung richtig spannend macht. Georg
eagle user schrieb: > Na gut, überredet, also reine Binärdaten ohne Kodierung und ohne > Verpackung. Damit reduziert sich meine Frage auf: Welche Dateiendung? Wie wärs mit .bin?
eagle user schrieb: > Sind eigentlich Dateien ohne Endung praktikabel? Außerhalb der Windows-Welt sind sie nichts ungewöhnliches. Aber da arbeitet man in der Regel eh mit Methoden, die etwas intelligenter sind, als nur nach dem Ende des Dateinamens zu schauen. Ob es unter Windows möglich ist, auch einer nicht vorhandenen Dateiendung ein Programm zuzuordnen, weiß ich gar nicht.
eagle user schrieb: > Sind eigentlich Dateien ohne Endung praktikabel? Würde ich für zumindest als direkten Download nicht empfehlen. Ich habe schon mehrmals Dateien von Webseiten runtergeladen, die ohne Dateiendung auf der Festplatte landeten. Tatsächlich waren es aber mp3- oder pdf-Dateien. Da war wohl der Webserver irgendwie falsch konfiguriert. Daher würde ich bei einer Datei ohne Endung erstmal rätseln, welches Format sie denn tatsächlich hat. Es könnte ja auch eine zip/rar/tar.gz o.ä. sein, die ich erst noch entpacken muss, bevor ich sie dem Firmware-Update-Tool übergebe. Bei einer .bin-Datei stelle ich mir die Frage nicht.
Rolf M. schrieb: > Ob es unter Windows möglich ist, auch einer nicht vorhandenen > Dateiendung ein Programm zuzuordnen, weiß ich gar nicht. Der normale Benutzer schafft es wohl nicht und bekommt immer die Rückfrage "öffnen mit?". Wer an der Stelle weitermacht, ist selbst schuld. Das ist genau das, was ich brauche. Spannend ist, was das sonst für Nebenwirkungen hat. Hans schrieb: > wie wär's mit .bin? Das wäre ja viel zu einfach, außerdem listet filext.com über 50 Programme für .bin :( Georg schrieb: > Üblich unter Unix/Linux: was die Datei darstellt, wird durch die > Ordnerstruktur definiert. Hat den schönen Nebeneffekt, dass ohne die > exakte Erhaltung der Ordnerstruktur die Daten unbrauchbar werden, was > besonders Datensicherung richtig spannend macht. So schlimm kann es nicht, praktisch haben doch die meisten Dateien keine Endung und eine Datensicherung, die die Ordnerstruktur nicht sichert, sollte wohl eher als Schredder verkauft werden ;)
eagle user schrieb: > Hans schrieb: >> wie wär's mit .bin? > Das wäre ja viel zu einfach, außerdem listet filext.com über 50 > Programme für .bin :( Dann eben .bim ;-)
eagle user schrieb: > Ich suche erstmal ein paar Ideen, was Benutzer alles anstellen könnten. Geraet waehrend des Firmwareupdates aus und anzuschalten.
Firmware-Images haben häufig die Dateiendung .bin So würde ich es auch machen. Aber egal welche du wählst, du wirst nie 100% sicher sein können, daß die Endung keinem Programm zugeordnet ist. Denn es gibt Millionen Programme, die sich 3 Zeichen teilen und darüber hinaus kann der Benutzer des Rechners diese Zuordnung jederzeit ändern.
Angehängte Dateien:
-
FIRMWARE.PNG
20 KB
Dumdi D. schrieb: > eagle user schrieb: >> Ich suche erstmal ein paar Ideen, was Benutzer alles anstellen könnten. > > Geraet waehrend des Firmwareupdates aus und anzuschalten. Langweilig, solange nicht der Boot Loader selbst überschrieben wird. Der sucht doch sowieso nach einem gültigen Programm und wenn er keins findet kann er es nochmal probieren. Oder darauf warten, dass wieder ein USB-Stick eingesteckt wird. Aber danke für den Hinweis! Da das Programm aus mehreren Teilen besteht, kann es passieren, dass die Teile hinterher von verschieden Versionen stammen. Die Fehlermeldungen muss mit nochmal anschauen. Und jetzt das vorläufige amtliche Endergebnis: Die Datei enthält ja ein Image des Flash-Speichers. Für Images gibt es das Tagged Image File Format, auch .TIF genannt. Na gut, ein etwas einfacheres Image-Format tut's auch, z.B. netpbm. Einen Header mit wenigstens der Gesamtgröße brauche ich ja sowieso. Bonus bei netpbm: man darf Kommentarzeilen im Klartext in den Header schreiben. Die binären Daten (das Programm) muss nur mit 0xff aufgefüllt werden, damit das Image (das Bild) rechteckig wird. Kombiniert mit der Dateiendung .PNM (oder .PBM?) ist das ein Foto. Dass dieses Bildformat nicht gleich im Browser oder Mail-Programm angezeigt wird, ist gerade richtig. Ein Doppelklick startet halt Photoshop oder Irfanview. Ein 30KB großes Programm sieht dann so aus wie im Anhang. Für das Forum hab' ich es nach PNG konvertiert, mal sehen, ob ich das .PNM auch direkt anhängen kann.
eagle user schrieb: > Die Datei enthält ja ein Image des Flash-Speichers. Für Images gibt es > das Tagged Image File Format, auch .TIF genannt. Aua. Auauauauaua - Du verrennst Dich da ganz übel.
> Da das Programm aus mehreren Teilen besteht, > kann es passieren, dass die Teile hinterher von verschieden Versionen > stammen. Das wolltest du doch ausschließen, indem du alle Teile zusammenhängend übermittelst. > Für Images gibt es das Tagged Image File Format, auch .TIF genannt. Mannomann. Du kannst ja nichtmal Bilder und Firmware Images auseinander halten! Glaubst du etwa auch, daß ein Bus-System in der Elektronik am Hauptbahnhof anhält? > Kombiniert mit der Dateiendung .PNM (oder .PBM?) ist das ein Foto. Nein, sicher nicht. > Ein Doppelklick startet halt Photoshop oder Irfanview. Was du ja gerade verhindern wolltest. Kannst du mal erklären, warum du dann ausgerechnet solche 100% bekannten Dateiendungen nimmst? Lass das ganze Projekt mal eine Woche ruhen und schlafe dich stattdessen aus. Wenigstesn 8 Stunden pro Nacht, dann kannst du auch wieder einen klaren Gedanken fassen.
eagle user schrieb: > Der aktuelle Anlass ist ein Cortex-M3, der über eine serielle > Schittstelle und ein VDrive3 die Datei vom USB-Stick lesen soll. > Außerdem sollte ein Update per GSM-Modem möglich sein, wobei sich der > Boot Loader mehrere Dateien von einem Webserver holt. Eine halbwegs > kompakte Kodierung ist also nicht unwichtig. Für die beiden Kanäle kannst du aber doch zwei verschiedene Kodierungen nehmen. Über GSM hast du ja die gesamte Strecke unter Kontrolle, da tut es ein Binärformat mit Checksumme und ggf. Verschlüsselung. Beim Weg Mail/Webbrowser->USB-Stick->Gerät dagegen bleibe ich bei meiner Mindermeinung. Bastelnde Benutzer, kaputte Mailclients, selbständig entpackende Browser - alles das kommt vor und hat das Potenzial, Supportaufwand zu generieren. Die Philosophie "egal wie vermurkst der Kanal ist, das Gerät kriegt sein Update da noch raus" ist mir sehr sympathisch. S. R. schrieb: > Nun, er könnte die in Word öffnen, ein paar Sätze Prosa reinschreiben, > das ganze als DOCX abspeichern, nochmal mit 7-Zip komprimieren und erst > dann an deinen Updater übergeben. Die Grenze wäre die Wandlung in ein Binärformat. docx ist binär, OpenDocument m.W. XML. Man könnte höchstens überlegen, ob man ZIP zulässt. Der Spruch dazu: "If you make something idiot-proof, they start making better idiots". Alternativ der klassische Murphy. Es gibt fast nichts, was Benutzer nicht anstellen können.
Rufus Τ. F. schrieb: > eagle user schrieb: >> Die Datei enthält ja ein Image des Flash-Speichers. Für Images gibt es >> das Tagged Image File Format, auch .TIF genannt. > > Aua. Auauauauaua - Du verrennst Dich da ganz übel. Was jetzt? Ich sollte doch ein Binärformat nehmen, weil das per HTTP oder SMTP problem- und fehlerlos transportiert wird? Mein Binärformat besteht zu 99% aus Cortex-M-Maschinenbefehlen mit einem zweckmäßigen Header. Dass manche Programme das für ein Bild halten, ist natürlich reiner Zufall ;) Stefan U. schrieb: >> Da das Programm aus mehreren Teilen besteht, >> kann es passieren, dass die Teile hinterher von verschieden Versionen >> stammen. > > Das wolltest du doch ausschließen, indem du alle Teile zusammenhängend > übermittelst. Mache ich ja auch. Dieses Problem kann entstehen, wenn das Flashen unterbrochen wird, z.B. mit Ausschalten. Meistens sind anschließend die ersten Teile neu, ein Teil defekt und der Rest alt. Das gibt mehr oder weniger eindeutige Fehlermeldungen, je nachdem welcher Teil defekt ist. > Mannomann. Du kannst ja nichtmal Bilder und Firmware Images auseinander > halten! Glaubst du etwa auch, daß ein Bus-System in der Elektronik am > Hauptbahnhof anhält? Natürlich, muss er doch, jedenfalls normalerweise (Multi-Master-Systeme sind neumodisches Teufelszeug). >> Kombiniert mit der Dateiendung .PNM (oder .PBM?) ist das ein Foto. > Nein, sicher nicht. Sagen wird so: ein normales Programm kann nicht erkennen, dass es kein Foto ist. >> Ein Doppelklick startet halt Photoshop oder Irfanview. > Was du ja gerade verhindern wolltest. Wenn ich es aber nicht verhindern kann, Stefan U. schrieb nämlich auch: > Aber egal welche du wählst, du wirst nie 100% sicher sein können, daß > die Endung keinem Programm zugeordnet ist. Schätzungsweise ist ".PNM", wenn überhaupt, einem Bildverarbeiter zugeordnet und der kann die Datei anzeigen. Mit .BIN öffnet irgendein Programm die Datei und meint, sie wäre beschädigt -> "Ihr habt mir ein kaputtes Update geschickt". Max G. schrieb: > Beim Weg Mail/Webbrowser->USB-Stick->Gerät dagegen bleibe ich bei meiner > Mindermeinung. Bastelnde Benutzer, kaputte Mailclients, selbständig > entpackende Browser - alles das kommt vor und hat das Potenzial, > Supportaufwand zu generieren. Die Philosophie "egal wie vermurkst der > Kanal ist, das Gerät kriegt sein Update da noch raus" ist mir sehr > sympathisch. Danke dafür, ich werde ich nochmal drüber schlafen...
> Was jetzt? Ich sollte doch ein Binärformat nehmen, weil das per > HTTP oder SMTP problem- und fehlerlos transportiert wird? Jaaaaahaaaaaa. Das habe ich doch auch geschrieben! Wie viele Leute sollen es Dir noch wiedeholen? > Mein Binärformat besteht zu 99% aus Cortex-M-Maschinenbefehlen mit > einem zweckmäßigen Header. Das ist doch dem Browser und dem Email Programm vällig egal. Für diese Programme sind das einfach nur Ansammlungen von Bytes. Alle möglichen Werte in beliebiger Kombination und Reihenfolge werden gleich behandelt. Da kommt hinten exakt das raus, was vorne rein geschoben wurde. Deine Argumentation, warum PNM besser geeignet sein soll, als BIN kann ich überhaupt nicht nachvollziehen. Wenn dein Kunde die PNM Datei doppelt anklickt, sieht er bunte Knete und reklamiert dann "Ich kann da nichts erkennen, das Bild ist kaputt". Wenn er sich noch blöder anstellt klicht er dann auf den Save Button und danach ist die Datei dann wirklich beschädigt, obwohl sie auf dem Bildschirm unverändert aussieht.
Stefan U. schrieb: >> Was jetzt? Ich sollte doch ein Binärformat nehmen, weil das per >> HTTP oder SMTP problem- und fehlerlos transportiert wird? > > Jaaaaahaaaaaa. Das habe ich doch auch geschrieben! Wie viele Leute > sollen es Dir noch wiedeholen? > Wenn dein Kunde die PNM Datei doppelt anklickt, sieht er bunte > Knete und reklamiert dann "Ich kann da nichts erkennen, das Bild > ist kaputt". > > Wenn er sich noch blöder anstellt klicht er dann auf den Save Button > und danach ist die Datei dann wirklich beschädigt, obwohl sie auf > dem Bildschirm unverändert aussieht. Und das passiert mit .BIN oder .FOO nicht? Na gut, dann geht es eben nicht. Die kleinste tauschbare Einheit ist eine Europakarte, relativ gut zugänglich. Früher hat man die per IC-Kuriergut verschickt für 150 DM, netterweise ist das sogar billiger geworden: Hamburg - München nur noch 143.80 EURO ;) https://www.time-matters.com/de/transportloesungen/ickurier/
> Und das passiert mit .BIN oder .FOO nicht?
Die kann man normalerweise gar nicht öffnen. Außer mit einem Texteditor,
wenn man die Dateiendung manuell zuweist. Und ob du es glaubst oder
nicht: Texteditoren machen binäre Dateien normalerweise nicht kaputt,
wenn man sie nur lädt und wieder abspeichert.
Stefan U. schrieb: > Die kann man normalerweise gar nicht öffnen Mit einem Hex-Editor schon, aber wer das macht, ist schon eher bösartig als naiv, und gegen solche Leute kann man eh nichts unternehmen. Im übrigen bewegt sich der ganze Thread in ziemlich abartige Gefilde. Seit Jahrzehnten speichert man Embedded Software als BIN oder HEX - bei BIN ist klar, dass Veränderungen unzulässig sind, und bei HEX sind Eingriffe wie andere Zeilenendmarkierungen egal. Es besteht nicht der geringste Bedarf an irgendetwas anderem. Aber jedem Tierchen sein Plaisirchen. Georg
Das Ganze ist ein Furz, ein Montagstroll. Wenn eine Datei den Inhalt beliebig veraendern kann und immer noch die Information tragen muss geht der Gehalt gegen Null. Bis nur noch das Boolean von einem Update: ja, oder nein, da ist, Inhalt egal. Im Sinne von .. es kam "kein" Update, das Geraet muss nicht mehr laufen. Oder, es kam "(k)ein" Update, das Geraet ist freigeschalten.
Wieso nicht einfach binär und dann eine crc anhängen? Ein x-kb firmwarr update wird niemans direkt in den mail-text klatschen xD
> Wieso nicht einfach binär und dann eine crc anhängen?
Es geht dem TO nicht nur darum, Veränderungen zu erkennen, sondern er
will sie zulassen. Jede noch so dumme Veränderung soll toleriert werden.
Das Update soll immer funktionieren.
Rolf M. schrieb: > eagle user schrieb: >> Als Dateiendung kommt wahrscheinlich nur ".TXT" in Frage, damit >> Virenscanner und Firewall-Filter keinen Verdacht schöpfe und Webserver >> das als text/plain ausliefern. > > Eben genau das nicht! Die genannten Probleme resultieren nämlich gerade > daraus, dass du es als Text übertragen willst. Nimm direkt die > Binärdaten, und packe einen eigenen Header davor, der Infos über die > Firmware und natürlich auch eine CRC enthält. So habe ich das auch schon > erfolgreich gemacht. Wenn man als Dateiendung nicht gerade sowas wie > .EXE oder .BAT nimmt, ist das normalerweise auch kein Problem. Rolf M. schrieb: > Dann denk dir was aus und such mal im Internet, zu welchem Programm > diese Dateiendung schon gehört. Wenn dabei was hinreichend obskures > rauskommt, nimm das. ;-) Ich dachte, genau das hätte ich gemacht und keiner mag es :( Also gut, nächster Versuch. Nachdem ich mir alle Beiträge nochmal angesehen habe, gibt es wohl eine Mehrheit (siehe unten) für ein Textformat. Daran hat mich nur dieses: Noch einer schrieb: > Heutzutage wird die Firewall misstrauisch, wenn sie Base64 > in *.txt findet. und die 2.5mal längere Übertragungszeit gestört. Um einen Fortschrittsbalken oder Fehlermeldungen anzuzeigen müsste der Boot Loader sehr viel mehr über die Hardware wissen. Damit wächst die Gefahr, dass er selbst mal ein Update braucht. Also wird er zweistufig, die "unveränderliche" erste Stufe lädt nur die zweite Stufe vom USB-Stick ins RAM und die kann dann auch das Display initialisieren und den Benutzer bespaßen, während das eigentliche Update im srecord-Format geladen wird. Die Datei wird nicht komplizierter, sie enthält einfach einen Abschnitt mehr. Sie bekommt die Endung ".S38", genau passend zum Inhalt, ohne Tricks. S38 steht für srecord mit 32-Bit Adressen, ist noch etwas seltener als .S19 und anscheinend ziemlich eindeutig. Für USB-Stick und GSM-Download das gleiche Format zu verwenden, ist in der Tat nicht wichtig. Der Download wird ja vom Anwendungsprogramm gemacht, nicht vom Boot Loader. Stefan U. schrieb: >> Wieso nicht einfach binär und dann eine crc anhängen? > > Es geht dem TO nicht nur darum, Veränderungen zu erkennen, sondern er > will sie zulassen. Jede noch so dumme Veränderung soll toleriert werden. > Das Update soll immer funktionieren. Naja, in gewissen Grenzen, Aufwand zu Nutzen und so... Max G. schrieb: > Beim Weg Mail/Webbrowser->USB-Stick->Gerät dagegen bleibe ich bei meiner > Mindermeinung. Bastelnde Benutzer, kaputte Mailclients, selbständig > entpackende Browser - alles das kommt vor und hat das Potenzial, > Supportaufwand zu generieren. Stefan U. schrieb: > Schau Dir mal base64 an, das müsste Dir bekannt vorkommen. Stefan U. schrieb: >> Irgendwelche Zeichen im Ascii umcodieren macht auch kein Programm mehr. > > Doch, und zwar jedes Email Programm und auch jeder Webserver/Browser. > Das WWW ist trotz zahlreicher Erweiterungen immer noch sehr > traditionell. Noch einer schrieb: > Heutzutage wird die Firewall misstrauisch, wenn sie Base64 in *.txt > findet. Matthias M. schrieb: > Dann nimm doch Base64. S. R. schrieb: > Intel-Hex erfüllt deine Anforderungen: Peter D. schrieb: > Was stört Dich an IHEX? Hans schrieb: > Wie wärs mit .bin? Stefan U. schrieb: > Firmware-Images haben häufig die Dateiendung .bin > So würde ich es auch machen. Rufus Τ. F. schrieb: > Wenn Du ZIP-Dateien zerstörungsfrei versenden und empfangen kannst, und > es möglich ist, sie zerstörungsfrei auf einem USB-Stick zu > transportieren, dann kannst Du auch jedes beliebige andere Dateiformat > versenden, empfangen und transportieren. S. R. schrieb: > Bandbreite ist unwichtig, nimm einfach IHEX oder SREC. > Ohne Absicht kriegst du das Datei nicht kaputt, die Records haben > Prüfsummen und das Gesamtergebnis sicherlich auch. Georg schrieb: > Seit Jahrzehnten speichert man Embedded Software als BIN oder HEX
Das ist doch ohnehin alles Schwachsinn weil YAGNI. Welche realen Zahlen aus dem Support belegen überhaupt, daß es da ein Problem zu lösen gibt?!
eagle user schrieb: > S38 steht für srecord mit 32-Bit Adressen, ist noch etwas > seltener als .S19 Dein Ansatz, ein möglichst seltenes Format zu benutzen, ist von vornherein Quatsch. Wenn etwas exotisch ist, dann meistens zu recht, weit verbreitete Formate haben sich dagegen offensichtlich bewährt. Der ganze Thread ist längst nur noch sinnlose Spinnerei und für mich beendet. Georg
Georg schrieb: > Dein Ansatz, ein möglichst seltenes Format zu benutzen, ist von > vornherein Quatsch. Der Ansatz ist von vorgestern. Ich hab' zwischendurch versucht, ein reines binär-Format zu verwenden und jetzt das srecord-Format, das gleich nach IHEX wohl das normalste für EPROM/Flash-Inhalt ist. Weil ich mich aber nicht auf 64K beschränken will, nehme ich 32- statt 16-Bit Adressen. arm-none-eabi-objcopy liefert übrigens genau dieses Format. Georg schrieb: > Der ganze Thread ist längst nur noch sinnlose Spinnerei und für mich > beendet. Nop schrieb: > Das ist doch ohnehin alles Schwachsinn weil YAGNI. Natürlich, weil eure Geräte ja nie Updates brauchen. Wenn euch die Frage zu schwierig ist, lest halt die Bildzeitung. Zwölf M. schrieb: > Das Ganze ist ein Furz, ein Montagstroll. Der 28.07.2017 war ein Freitag, ich brauche kein neues Troll-Format.
Mach dir selbst und allen anderen das Leben leicht: Jemand, der weiss was er da macht, laedt die Firmware auf einen FTP-Server, und von da laedst du es wieder runter. Fertig. Kein Grund sich ueber Dateiformate, dumme User, kaputte Mail-Clients oder sonst was aufzuregen.
eagle user schrieb: > Natürlich, weil eure Geräte ja nie Updates brauchen. Doch. Aber es gibt keine Zahlen, die Deine Phantasie-Szenarien mit Umwandlung der Firmware in PDF, Word, BMP, Flashplayer und zurück auch nur irgendwie belegen würden. Deswegen ist es YAGNI-Quatsch. Guck Dir einfach mal an, wie Mainboardhersteller ihr Bios auf die Webseite setzen. Dann weißt Du, was für den Masseneinsatz offensichtlich ausreicht.
Wie wärs mit Steganographie ? Der Kunde kriegt ein PDF mit der Update-Anleitung und die Firmware ist als geheimes Wasserzeichen Kommentar Metadaten versteckt. Da muss der Praktikant erst mal Acrobat Pro raubmordkopieren um da was kaputtzumachen. Ich würde natürlich versuchen , das PDF auszudrucken und das Blatt Papier schön gefaltet in die USB-Buchse zu drücken. Am besten funktioniert hier der Ausdruck der Sicherheitskopie welche ich vom PDF mit meinem PDF-Drucker gedruckt habe um die Originaldatei nicht zu beschädigen. Nächstes mal schicke ich dann ein Anleitungsvideo in 4K , wo die Firmware mit Cinavia eingebettet ist. Selbst der CamRIP davon sollte den Zuschauern und meinem Bootloader genügen.
Der ganze Thread geht von der irrtümlich angenommenen Prämisse aus daß Dateiinhalte bei der Übertragung von irgendwelcher dabei beteiligter Software vorsätzlich verändert werden. Aber dem ist nicht so. Also ist der ganze Thread mehr oder weniger sinnlos. --- Wenn die Zielgruppenkunden wirklich so unbeholfen sind wie hier dargestellt würde ich einfach einen selbstentpackende Setup.exe zum Download anbieten die das in sich enthaltene Firmware-Blob ins RAM entpackt, das upzudatende Gerät sucht, es updated, Erfolg meldet und sich beendet. Das ganze sollte mindestens einen "Weiter" Button haben, gefolgt von einem "Weiter" Button, gefolgt von einem "Weiter" Button, gefolgt von einem "Fertigstellen" Button. Und evtl noch ein schöner Fortschrittsbalken mit fliegenden Papierfetzen. Das ist die Zielgruppe so gewohnt, da kommen keine Fragen auf.
:
Bearbeitet durch User
Und wenn der User die EXE Datei mit einem Malprogramm öffnet, modifiziert und wieder speichert? Gegen solchen Unsinn wollte der TO es ja auch schützen. nein schlimmer noch: Jede denkbare Änderung sollte die Datei nicht zerstören können, die soll trotzdem funktionieren. Selbst wenn ein Screenshot von der Datei in eine Email oder Word Datei eingebettet wird.
Stefan U. schrieb: > Lass das ganze Projekt mal eine Woche ruhen und schlafe dich stattdessen > aus. Wenigstesn 8 Stunden pro Nacht, dann kannst du auch wieder einen > klaren Gedanken fassen. Gemacht. Das Ergebnis: die Datei ist jetzt base85 kodiert und vor jedem Teil-Image steht eine Kommentarzeile ('#') mit Name, Datum,... Diese Info und Flash-Adresse, Größe, CRC,... stehen auch im Image selbst. Am Dateianfang können beliebig viele Kommentarzeilen stehen, z.B. für eine Erklärung, was das für eine seltsame Datei ist und was man damit machen sollte. Der Bootloader ignoriert Kommentarzeilen und white space innerhalb der Daten. Bei Zeichen außerhalb des base85-Zeichensatzes oder falscher Netto-Zeilenlänge ist die Datei ungültig. Nop schrieb: > Guck Dir einfach mal an, wie Mainboardhersteller ihr Bios auf die > Webseite setzen. Das war ein guter Tipp. Jeder verwendet seine eigene Fantasie-Dateiendung, Fujitsu verwendet noch halbwegs normale, liefert aber das Image doppelt aus, mit .rom und .UPD, mit identischem Inhalt. Außerdem schreibt filetypeadvisor.com:
1 | What is the .ROM file type? |
2 | The .rom filename extension chiefly serves to denote generic |
3 | Read-Only Memory (ROM) images saved as files. A .rom file can |
4 | hold PC BIOS firmware or contents of an electronic device's ROM. |
5 | It contains identical representation of a binary program code |
6 | placed into the ROM (flash) memory for persistent storage. |
7 | |
8 | ROM files usually have specific sizes that are multiple of 8 |
9 | (256, 512, and so on), although the exact format of a given |
10 | .rom file depends on its origin and purpose. ROM files are |
11 | commonly used for distributing and updating firmware and may |
12 | have several other extensions (.bin, .ami) or no extension at all. |
13 | If used for updating (flashing) firmware, any ROM file is first |
14 | checked for format correctness and data integrity to avoid |
15 | 'bricking' a device. |
Perfekt!
Warum bist Du so besessen von der Dateiendung? Wenn Du eine .bin Datei hast wie sie aus objcopy rauskommt nenn sie doch einfach .bin so wie es üblich ist. Wenn Du Dir ein eigenes Dateiformat ausdenkst dann denk Dir Deine ganz persönliche eigene Endung aus, Du bist nicht auf 3 Zeichen festgelegt, nenn die Dateien von mir aus .hansfranz wenn Du willst.
Bernd K. schrieb: > Warum bist Du so besessen von der Dateiendung? Weil ich nicht weiss, was alles damit gesteuert wird. Ich vermute, dass Dateien mit bestimmten Endungen garnicht beim Benutzer ankommen - egal, ob per Download oder per Mail. Daher stammt die erste Idee .TXT zu nehmen. Oder eben ein Bild, weil ich glaube, dass Bilder eher harmlos sind (aus der Sicht eines Virenscanners oder Proxies). > Wenn Du Dir ein eigenes Dateiformat ausdenkst dann denk Dir Deine > ganz persönliche eigene Endung aus, Du bist nicht auf 3 Zeichen > festgelegt Das wäre eine gute Lösung, aber dann müsste meine Hardware vfat verstehen. Der Aufwand wäre immens, verglichen mit dem fertigen VDrive3 für 20 Euro. Außerdem hätte ich Bedenken wegen der Microsoft-Patente; ich würde ja einen eigenen vfat-Treiber brauchen und nicht nur einen mitgelieferten benutzen.
eagle user schrieb: > Ich vermute, dass Dateien mit bestimmten Endungen garnicht beim Benutzer > ankommen - egal, ob per Download oder per Mail. Das sind dann nur Endungen, die gerne für Schadwirkungen unter Windows genutzt werden: *.exe, *.com, *.cmd, *.bat, *.pif, *.scr, *.cpl, *.vbs ... > Daher stammt die erste Idee .TXT zu nehmen. Schlechte Idee, weil hier jeder Mailclient/Downloader/Text-Editor seine eigene Interpretation über die Codierung drüberlaufen lassen kann, und dann funktionieren irgendwelche Sonderzeichen nicht, Zeilenumbrüche sind vermurkst etc. > Oder eben ein Bild, weil ich glaube, dass Bilder eher harmlos sind Es gibt durchaus Maildienste & Webserver, die Bilder nachkomprimieren, um im Mobilfunknetz Bandbreite zu sparen. Bild ist daher ganz, ganz schlecht. Nimm *.bin. Das ist etwas, was niemand "interpretiert", umcodiert, optimiert. Wenn auf mancher Trottel PCs irgendein Programm sich das unter den Nagel gerissen hat und versucht zu öffnen, dann ist das Schicksal. Das gleiche kann Dich auch bei allem anderen treffen, sei es *.foo, *.hex, *.bla ...
Rufus Τ. F. schrieb: > Schlechte Idee, weil hier jeder Mailclient/Downloader/Text-Editor seine > eigene Interpretation über die Codierung drüberlaufen lassen kann, und > dann funktionieren irgendwelche Sonderzeichen nicht, Zeilenumbrüche > sind vermurkst etc. Langsam dreht sich der Thread im Kreis. Das war ja genau das Anliegen des TO, eben damit zurechtzukommen. Wenn ich mir den Thread so anschaue, war ich gefühlt der Einzige, der die Idee gut fand.
Wenn nichts, wirklich gar nichts das Firmwareupdate zerstören können soll, gibt es nur eine einzige wirklich sichere Methode: Lass es von Chuck Norris persönlich ausliefern und installieren. Klappt. Garantiert.
eagle user schrieb: > Ich vermute, dass > Dateien mit bestimmten Endungen garnicht beim Benutzer ankommen Falsche Prämisse. eagle user schrieb: > Außerdem hätte ich Bedenken wegen der Microsoft-Patente; Irrelevant.
Max G. schrieb: > Rufus Τ. F. schrieb: >> Schlechte Idee, weil hier jeder Mailclient/Downloader/Text-Editor seine >> eigene Interpretation über die Codierung drüberlaufen lassen kann, und >> dann funktionieren irgendwelche Sonderzeichen nicht, Zeilenumbrüche >> sind vermurkst etc. > > Langsam dreht sich der Thread im Kreis. Das war ja genau das Anliegen > des TO, eben damit zurechtzukommen. Wenn ich mir den Thread so anschaue, > war ich gefühlt der Einzige, der die Idee gut fand. Nicht wirklich im Kreis und du bist nicht der Einzige. Freiwillig werde ich das hier (Beitrag "Re: Firmware Update: welches Dateiformat?") beschriebene Format nicht mehr ändern. Das geht mit 7 Bit und verträgt veränderte Leerzeichen, Zeilenumbrüche und (in Grenzen) Sonderzeichen. Es gibt eine spezielle base64 Kodierung, die extra im Hinblick auf Sonderzeichen entworfen wurde, aber mir ist ein kompakteres Format wichtiger. Andererseits gibt es ja immer noch wertvolle Anregungen Rufus Τ. F. schrieb: > Es gibt durchaus Maildienste & Webserver, die Bilder nachkomprimieren, > um im Mobilfunknetz Bandbreite zu sparen. S. R. schrieb: > eagle user schrieb: >> Außerdem hätte ich Bedenken wegen der Microsoft-Patente; > > Irrelevant. Genau wegen solcher Aussagen habe ich Bedenken. Deshalb ist die Sache klar: vfat kommt nicht in Frage. BesterProgrammiererVonWelt schrieb: > Lass es von Chuck Norris persönlich ausliefern und installieren. :)
> Ich vermute, dass Dateien mit bestimmten Endungen garnicht beim > Benutzer ankommen Manche Virenscanner von Firmen entfernen Dateianhänge, die wie ausführbare Programme aussehen. Diese solltest du entweder meiden oder wie üblich in ein ZIP einpacken.
Stefan U. schrieb: > Diese solltest du entweder meiden oder > wie üblich in ein ZIP einpacken. Unserer entpackt ZIPs und schaut sich den Inhalt an. Kann er die Datei nicht entpacken (ungültiges Format, passwortgeschützt), entfernt er sie. Anfangs ließ er sich noch überlisten, indem man die Datei einfach .zap nannte. Mittlerweile erkennt er wohl den Dateiheader. Ich sag's ja. Du wirst um Chuck Norris nicht drumherum kommen.
Wer so einen doofen Virenscanner verwendet, weiss das auch (ich kenne das aus eigener leidvollen Erfahrung). Du hast Recht, man kann nicht alle Komplikationen verhindern. Von irgendeinem Amt bekam ich mal eine Mail zurück, weil ich angehängte Bilder als ZIP zusammen gepackt hatte. Wie wollten Bilder nur mit ganz bestimmten Auflösungen, maximal 1MB pro Bild und seltsamerweise durften sie nicht gepackt werden. Andere Anhänge waren gar nicht zugelassen. Wie willst du an so jemandem ein Firmware Image schicken? Geht gar nicht, ist aber auch genau so gewollt.
Stefan U. schrieb: > Wie willst du an so jemandem ein Firmware Image schicken? Geht gar > nicht, ist aber auch genau so gewollt. Pragmatische Lösung: Jeder hat doch heute irgendeine Mailadresse mit Webmailinterface. ;-)
eagle user schrieb: > Freiwillig werde > ich das hier (Beitrag "Re: Firmware Update: welches Dateiformat?") > beschriebene Format nicht mehr ändern. Das geht mit 7 Bit und verträgt > veränderte Leerzeichen, Zeilenumbrüche und (in Grenzen) Sonderzeichen. Warum verschickst Du die Binärdaten nicht einfach als Binärdatei so wie alle anderen das ebenfalls machen (und keine Probleme dabei haben)? Wozu die unnötige Bandbreiten- und Rechenzeitverschwendung?
Bernd K. schrieb: > Warum verschickst Du die Binärdaten nicht einfach als Binärdatei Weil er hier unbedingt als leuchtendes Beispiel von absoluter Unbelehrbarkeit glänzen will. Dass ihm das gelungen ist muss man neidlos anerkennen. Nächste Runde bitte, aber ohne mich. Georg
Stefan U. schrieb: > Wie willst du an so jemandem ein Firmware Image schicken? Geht gar > nicht, ist aber auch genau so gewollt. Mit dem Ansatz des TO geht das - einfach als Text einer Mail.
Rufus Τ. F. schrieb: > eagle user schrieb: >> Ich vermute, dass Dateien mit bestimmten Endungen garnicht beim Benutzer >> ankommen - egal, ob per Download oder per Mail. > > Das sind dann nur Endungen, die gerne für Schadwirkungen unter Windows > genutzt werden: > > *.exe, *.com, *.cmd, *.bat, *.pif, *.scr, *.cpl, *.vbs ... Manchmal auch harmloser erscheinende Endungen wie .zip, .tar.gz oder gar .bmp.
>> Wie willst du an so jemandem ein Firmware Image schicken? Geht gar >> nicht, ist aber auch genau so gewollt. > Mit dem Ansatz des TO geht das - einfach als Text einer Mail. Das wierderum würden einige Mail-Scanner als SPAM werten und ebenso entfernen.
Max G. schrieb: > Mit dem Ansatz des TO geht das - einfach als Text einer Mail. Kein anderer Mensch macht das so und die Empfänger werden überfordert sein wenn sie den seitenlangen Buchstabensalat erstmal in eine neue Textdatei copy-pasten und speichern müssen. Die werden ihn fragen ob er sie absichtlich ärgern will mit so einem Schwachsinn denn alle anderen Leute wenn sie Dateien schicken wollen hängen die einfach ganz normal als Dateianhang an, denn genau zu dem Zweck wurde der Mechanismus "Dateianhang" erfunden. Oder sie schicken eine Download-URL wenn sie das an mehr als 3 Leute verteilen wollen oder wenn zu erwarten ist daß einige der involvierten Mail-Relays wegen Virengefahr/Spamverdacht rumzicken werden.
:
Bearbeitet durch User
Bernd K. schrieb: > Oder sie schicken eine Download-URL wenn sie das > an mehr als 3 Leute verteilen wollen oder wenn zu erwarten ist daß > einige der involvierten Mail-Relays wegen Virengefahr/Spamverdacht > rumzicken werden. ... oder wenn zu vermuten ist, daß einige Mailserver den Ahnhang wegen Größenbeschränkungen nicht akzeptieren.
S. R. schrieb: sorry, ich schon wieder, aber ich hab' gerade etwas interessantes gefunden > eagle user schrieb: >> Außerdem hätte ich Bedenken wegen der Microsoft-Patente; > > Irrelevant. FTDI sagt dazu in der AN_189:
1 | 4 Using the LFAT Driver |
2 | |
3 | To use the LFAT driver, the customer must first obtain a license from |
4 | Microsoft, then request the LFAT driver library from FTDI, and finally |
5 | incorporate it into his Vinculum-II development toolchain. |
6 | |
7 | 4.1 Obtaining a License |
8 | |
9 | Long filename technology is the intellectual property of Microsoft |
10 | Corporation. Microsoft controls rights to its technologies through its IP |
11 | licensing group [2]; the technology licensing program includes rights with |
12 | regard to the implementation of the FAT File System [3]. To use long |
13 | filenames, the customer must enter into a licensing agreement with |
14 | Microsoft before FTDI can distribute the LFAT driver library. Consequently, |
15 | the LFAT driver is not included in the Vinculum-II Toolchain distribution |
16 | but can be obtained on request from FTDI Support. Prior to distribution, |
17 | FTDI will obtain an agreement from the customer, stating customer’s |
18 | responsibility to obtain the LFN license from Microsoft. With that |
19 | agreement signed off, FTDI is relieved of any liability for releasing the |
20 | LFN driver library to the customer. It must be stressed that it is the |
21 | customer’s responsibility to obtain the license from Microsoft, failing |
22 | which they could face further consequences from Microsoft. For information |
23 | on how to obtain the LFN license from Microsoft, see [3]. |
24 | |
25 | 4.2 Requesting the Library |
26 | |
27 | After finalizing a license agreement with Microsoft, the customer must |
28 | contact FTDI Support to request the LFAT driver library archive. |
29 | |
30 | |
31 | [2] www.microsoft.com/about/legal/en/us/IntellectualProperty/ |
32 | IPLicensing/Default.aspx |
33 | [3] www.microsoft.com/about/legal/en/us/IntellectualProperty/ |
34 | IPLicensing/Programs/FATFileSystem.aspx |
Es muss natürlich so aussehen: sorry, ich schon wieder, aber ich hab' gerade etwas interessantes gefunden > S. R. schrieb: > eagle user schrieb: >> Außerdem hätte ich Bedenken wegen der Microsoft-Patente; > > Irrelevant.
Wenn du dich so sehr für die Thematik interessierst, würde ich dir empfehlen, direkt bei Microsoft anzufragen. Der Link dazu findet sich auf der IP-Seite von Microsoft und verweist auf http://celaiplicensing.azurewebsites.net/pages/IPlicensing.aspx und der zweite FTDI-Link ist bei mir tot. Wenn es um eine Firmwaredatei mit langem Dateinamen geht, die du auf irgendeinen Webserver tust, um sie dem Kunden zur Verfügung zu stellen, dann weise ich dich mal ganz leise darauf hin, dass (a) dein Webserver kein FAT benutzt; (b) dein Kunde ziemlich sicher kein FAT benutzt; (c) wenn er es doch tut, es nicht dein Problem ist. Relevant für diesen Thread wäre das LFN-Patent höchstens, wenn du ein Gerät baust, welches sich als USB-MSC mit FAT und LFNs ausgibt und Firmware-Updates per "draufkopieren und neu starten" entgegennimmt. Aber wenn dem so wäre, bräuchte man keine Überlegungen zu "Datenkorruption durch Outlook Express - was tun?" mehr treiben.
Mir ist die verwendung des Bildformates sympatisch Ich würde dem noch ein Frame verpassen und einen lustgen text oder graphik, welche dem Neugieriegen oder deppen auf den tatsächliche Dateizweck hinweisen. Namaste
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.