Forum: PC Hard- und Software Firmware Update: welches Dateiformat?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von eagle user (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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 Moderator
von Matthias M. (Firma: privat) (quadraturencoder)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Route_66 H. (route_66)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Wie groß in Anzahl von Bytes etwa sind deine Updates?
(rein binär gezählt)

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
> 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

: Bearbeitet durch User
von Raute (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
pptx

von Noch einer (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
> 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.

: Bearbeitet durch User
von Noch einer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Max G. (l0wside) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von juergen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Noch einer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von my2ct (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Georg (Gast)


Bewertung
4 lesenswert
nicht lesenswert
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

von Jan H. (j_hansen)


Bewertung
2 lesenswert
nicht lesenswert
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.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von my2ct (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Patrick J. (ho-bit-hun-ter)


Bewertung
0 lesenswert
nicht lesenswert
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

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Was stört Dich an IHEX?
https://de.wikipedia.org/wiki/Intel_HEX

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
>> 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.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sind eigentlich Dateien ohne Endung praktikabel?

von Georg (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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

von Hans (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hans (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Dumdi D. (dumdidum)


Bewertung
0 lesenswert
nicht lesenswert
eagle user schrieb:
> Ich suche erstmal ein paar Ideen, was Benutzer alles anstellen könnten.

Geraet waehrend des Firmwareupdates aus und anzuschalten.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von eagle user (Gast)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
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.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
> 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.

von Max G. (l0wside) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von eagle user (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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...

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
> 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.

: Bearbeitet durch User
von eagle user (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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/

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
> 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.

: Bearbeitet durch User
von Georg (Gast)


Bewertung
6 lesenswert
nicht lesenswert
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

von Purzel H. (hacky)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mampf unterwegs (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Grmpf
.S37 es muss .S37 heissen, nicht .S38

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?!

von Georg (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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

von eagle user (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Kaj (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ernst (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
3 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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 ...

von Max G. (l0wside) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von BesterProgrammiererVonWelt (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

:)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von BesterProgrammiererVonWelt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von BesterProgrammiererVonWelt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Max G. (l0wside) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
>> 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.

von Bernd K. (prof7bit)


Bewertung
3 lesenswert
nicht lesenswert
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
von guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.