Mahlzeit!
Man habe mehrere unterschiedliche Geräte mit z.B. STM32L412. Irgendwann
kommen per E-Mail zwei s19-Dateien mit Firmware-Updates. Dateinamen und
-Datum gehen auf dem Weg ja gerne verloren. Trotzdem möchte man sie
nicht verwechseln. Wie macht "man" das?
Mein halber Plan sieht z.Zt. so aus:
1
# version -- wird von elf2srec in jeden image_header eingebaut.
2
3
version = V01.06
4
product = 110174
5
board = 510353
6
boardrev = -
7
pcb = 510331
8
pcbrev = A
9
10
# version die Version der Firmware
11
# kann durch LOCAL_VERSION überschrieben werden,
12
# das ist z.B. für tzdata nützlich.
13
#
14
# product die Sachnummer auf dem Typenschild
15
# Wenn die gleiche Firmware für mehrere Varianten gut ist,
16
# gibt es eine zweite Sachnummer auf einem Zusatzaufkleber
17
# "eingestellt für $Anwendung".
18
# Das Programm muss diese Nummer nicht kennen, sie ist ja
19
# von den Einstellungen abhängig. Vordefinierte Presets
20
# mit bekannter Sachnummer sind natürlich machbar.
21
#
22
# board die Sachnummer der bestückten Platine
23
#
24
# boardrev Revisionsstand der Bestückung
25
# Bauteiländerungen, Aufputzdrähte usw.
26
# '-', 'a', 'b'... fängt bei neuem Layout wieder bei '-' an
27
#
28
# pcb die Sachnummer der unbestückten Platine
29
#
30
# pcbrev Revisionsstand der Platine
31
#
32
# Das Flash-Programm soll prüfen, ob die Firmware zur Hardware passt.
33
# Auf der Baustelle muss alles außer 'version' übereinstimmen.
34
# In der Werkstatt reicht weniger, man darf die Platine auch für ein
35
# anderes Gerät verwenden.
36
#
37
# Die 'version' muss sich wahrscheinlich bei jeder Änderung der Hardware
38
# ('pcbrev', 'boardrev') ändern, auch wenn die Änderung kompatibel war.
39
# Der Flashloader muss ja den neuen Stand erfahren. Wenn diese Info
40
# in den s19-Files stehen soll (mehrere S0-records), ist eine neue
41
# Firmware-Version reine Routine und alles andere ein Krampf.
42
#
43
# Ein extra File, in dem nur diese Metadaten stehen, könnte man evt.
44
# nachträglich im alten Firmware-Verzeichnis speichern. Aber dann gibt
45
# es alte und neue Versionen von einer Version! Und, wie kommt diese
46
# Datei zum Flashloader? Und zwar passend zu den s19-Files?!
Bauform B. schrieb:> Das Flash-Programm soll prüfen, ob die Firmware zur Hardware passt
Du ahnst nicht, wie erfinderisch Anwender sind.
Wenn der Anwender entdeckt, dass sich die firmware nicht mit den
speziellen flash-loader brennen lässt, oder er das spezielle
flash-loader Programm irgendwie verbummelt hat, dann nimmt er eben einen
anderen flash-loader der mehr taugt, mit dem das nicht so ein Krampf
ist, z.B. das Original vom Chiphersteller, das geht immer.
Bauform B. schrieb:> Mahlzeit!
Mahlzeit,
> # Das Flash-Programm soll prüfen, ob die Firmware zur Hardware passt.> # Auf der Baustelle muss alles außer 'version' übereinstimmen.
was ist den das Flash-Programm? Wenn das eh selbst geschrieben ist,
würde ein eigenes Datei-Format nehmen und nicht s-records. Was ist auf
der anderen Seite des Flash-Programms? (Bootloader, ST-Bootloader,
SWD-programmer?)
schöne Grüße,
Torsten
Bauform B. schrieb:> Dateinamen und> -Datum gehen auf dem Weg ja gerne verloren.
Na und. Schau halt in den Eigenschaften nach. Das Erstellungsdatum steht
da drin. Und wenn die halbwegs gepflegt sind auch Versions-Nr. und ä.
Jedenfalls unter Windows.
Nachtrag: Auf der Geräte Seite prüft man einfach mit ein Sicherheitscode
und wenns edel wird mit ein HASH ob die Daten i.o. sind. BEVOR man
anfängt sie zu flashen. Und selbstverständich ist DATUM Version etc
ebenfalls in der Firmware verschlüsselt.
Einige Gerätehersteller erlauben nämlich kein Downgrade. Was mich schon
zu mehren nicht sehr netten Wutausbrüchen kommen lies. Das schlimmste
war ein Bios-Update eines Asus-Laptop wo danach der Lüfter nur noch eins
kannte. VOLLGAS. Der Krach hat mich dazu gebracht ein neuen Laptop zu
kaufen aber nicht mehr von Asus.
Schlaumaier schrieb:> Na und. Schau halt in den Eigenschaften nach. Das Erstellungsdatum steht> da drin. Und wenn die halbwegs gepflegt sind auch Versions-Nr. und ä.> Jedenfalls unter Windows.
Sag mir bitte, dass Du ein Troll bist. Ein normaler Mensch kann nicht so
viel Unsinn reden.
1. Das Erstellungsdatum kommt vom Filesystem, das geht schon beim
Versand als Mail-Attachment verloren.
2. Die Versionsinformationen, die Du meinst, sind in den
Windows-Resources untergebracht, und die findet man in Windows-Binaries,
hier geht es um Firmware-Files.
Schlaumaier schrieb:> Bauform B. schrieb:>> Dateinamen und>> -Datum gehen auf dem Weg ja gerne verloren.>> Na und. Schau halt in den Eigenschaften nach. Das Erstellungsdatum steht> da drin. Und wenn die halbwegs gepflegt sind auch Versions-Nr. und ä.> Jedenfalls unter Windows.
Es geht eher darum, was kann ich auf Empfängerseite tun, um zu
verhindern, dass irgendwer (z.B. sogenannte Schlaumaier) irgendwas als
Update draufflasht, was da nicht hingehört.
MeierKurt schrieb:> Es geht eher darum, was kann ich auf Empfängerseite tun, um zu> verhindern, dass irgendwer (z.B. sogenannte Schlaumaier) irgendwas als> Update draufflasht, was da nicht hingehört
bootloader mit Usb/ UART oder was auch immer, der wie schon erwähnt den
Hash überprüft bevor er die neue Version flasht. Ohne Bootloader,
sondern mit Programmieradapter hast du da keine Chance, dann nimmt
"irgendwer" notfalls halt nen anderen. Am besten das normale
Programmierinterface mit Fuses/Lock Bytes oder was auch immer vorhanden
deaktivieren. Meist kann man diese durch Löschen des Controllers
zurücksetzen.
daher würde ich so vorgehen:
- Programmierinterface deaktivieren
- uC gegen Auslesen schützen
- Bootloader schreiben ( usb, uart ...)
- Update + Metadaten + Hash Verschlüsseln
- Bootlader entschlüsselt, prüft Metadaten und Hash, flasht erst wenn
alles stimmt
wurde aber auch fast alles erwähnt.
Hmmm schrieb:> 1. Das Erstellungsdatum kommt vom Filesystem, das geht schon beim> Versand als Mail-Attachment verloren.>> 2. Die Versionsinformationen, die Du meinst, sind in den> Windows-Resources untergebracht, und die findet man in Windows-Binaries,> hier geht es um Firmware-Files.
Schwachsinn.
Ich ändere das Datum und da passiert NIX.
Unter Eigenschaften im Reiter Allgemein stehen 3 Datums.
ERSTELLT // GEÄNDERT // LETZTER ZUGRIFF
Im Reiter DETAILS Stehen die Versions-Informationen und sonstige Infos
die uns der Ersteller Freiwillig o. unfreiwillig mitteilt.
Bei eine Foto einer Kamera stehen da z.b. Gerät Serien-Nr Auflösung/
Blende u.s.w.
Darunter findest du ein "Link" mit den du besagte Infos auch löschen
kannst.
Ach übrigens den Typ der Harry-Potter damals vor Veröffentlichung ins
Netz getan hat, haben sie über die Daten gefunden ;) Ob der auch so ein
ICH WEISS ALLES TYP war wie du.
Kleiner Test falls du mir nicht glaubst. Ändere mit z.b. den
Total-Commander die Datei-Attribute. Schau dir das Datum dann im
Explorer an und in den Eigenschaften ;)
Nachtrag:
Ich überprüfe auf die Weise meist das alter der Treiber-Dateien. Das
Datum was mir der Explorer anzeigt interessiert mich nur nebenbei. So
merkt man schnell ob man von irgend ein Anbieter verarscht wird und ob
der wirklich was gemacht hat o. nur ein neues ZIP-Päckchen.
K. S. schrieb:> MeierKurt schrieb:>> Es geht eher darum, was kann ich auf Empfängerseite tun, um zu>> verhindern, dass irgendwer (z.B. sogenannte Schlaumaier) irgendwas als>> Update draufflasht, was da nicht hingehörtSchlaumaier schrieb:> Nachtrag: Auf der Geräte Seite prüft man einfach mit ein Sicherheitscode> und wenns edel wird mit ein HASH ob die Daten i.o. sind. BEVOR man> anfängt sie zu flashen. Und selbstverständich ist DATUM Version etc> ebenfalls in der Firmware verschlüsselt.
Du machst ergo genau das. Du verschlüsselst die Datei. Im Gerät wird der
erste Block entschlüsselt. Die Daten gelesen und danach entschieden was
Sache ist.
Somit verhinderst du das ein Schlaumeier (wie ich) einfach ein
HEX-Editor nimmt und das Datum Version zurück Hoch setzt. Und somit
das Gerät überredet alles zu fressen was es bekommt. (Hab ich sogar vor
20 Jahren mal so gemacht).
Falls du die eine einfach BIT-Verschlüsselung nicht zutraust ..... ;)
Schlaumaier schrieb:> Schwachsinn.
Jetzt wird's amüsant, der Möchtegern-Profi legt los.
Schlaumaier schrieb:> Unter Eigenschaften im Reiter Allgemein stehen 3 Datums.
Daten.
Schlaumaier schrieb:> Im Reiter DETAILS Stehen die Versions-Informationen und sonstige Infos> die uns der Ersteller Freiwillig o. unfreiwillig mitteilt.
Die kommen bei EXEs aus den Windows-Resources, wie schon gesagt.
Schlaumaier schrieb:> Bei eine Foto einer Kamera stehen da z.b. Gerät Serien-Nr Auflösung/> Blende u.s.w.
EXIF-Informationen in JPEG-Files, andere Baustelle.
Schlaumaier schrieb:> Kleiner Test falls du mir nicht glaubst.
Weder Windows-Resources noch EXIF-Daten helfen ihm bei seinem
STM32-Firmware-Image in irgendeiner Weise weiter.
Du beweist wieder einmal, dass Dein "Wissen" allenfalls etwas an der
Oberfläche kratzt, Dir aber die technischen Hintergründe völlig fremd
sind.
Hmmm schrieb:> Du beweist wieder einmal, dass Dein "Wissen" allenfalls etwas an der> Oberfläche kratzt, Dir aber die technischen Hintergründe völlig fremd> sind.
Du musst erst einmal lernen zwischen 2 Unterschiedlichen Systemen zu
Unterscheiden. ICH tue das nämlich.
SYSTEM 1 = WINDOWS
Will ich unter Windows wissen welchen Version ich habe, benutze ich oben
genannte Eigenschaften einer Datei. Und die stehen nicht in irgend
welchen
Windows-Resources sonder schlicht und ergreifend im Header einer Datei.
Woher soll DEIN Windows sonst wissen, wann irgend ein Programmieren ich
China die Datei ERSTELLT hat und wann das letzte mal geändert.
Exif-Daten sind nix anders wie mehr oder weniger so genormte Daten das
andere Programme sie möglicherweise nutzen können (für Datenbanken z.b.)
ABER es sind nur Daten, genau wie alle anderen auch.
SYSTEM 2 = DIE HARDWARE.
Da funktioniert das grundsätzlich genau so. Die Datei(Firmware) bekommt
einen Header im 1. Block. Diesen Block liest du Upgrade-Routine zuerst,
Entschlüsselt sie falls nötig. Nun liest sie alle Infos die sie braucht
z.b. Gerätetyp, Version, Datum etc. Danach entscheidet die
Upgrade-Routine ob sie das Upgrade durchführt oder sie verweigert.
Und da man Header manipulieren kann, war mein Vorschlag den selbigen zu
verschlüsseln.
https://de.wikipedia.org/wiki/Metadaten <- Mach dich einfach mal schlau.
Schlaumaier schrieb:> Will ich unter Windows wissen welchen Version ich habe, benutze ich oben> genannte Eigenschaften einer Datei. Und die stehen nicht in irgend> welchen> Windows-Resources sonder schlicht und ergreifend im Header einer Datei.
Das ist Unsinn. Einfach mal nachlesen:
https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource
Und vielleicht einfach mal davon ausgehen, dass hier nicht alle Frickler
sind, die etwas mit BASIC rumfummeln, sondern viele deutlich tiefer in
der Materie stecken als Du.
Schlaumaier schrieb:> ABER es sind nur Daten, genau wie alle anderen auch.
Und jetzt kommst Du mit der Ausrede "Sind alles Daten, also hatte ich
irgendwie recht", schon klar.
Schlaumaier schrieb:> Da funktioniert das grundsätzlich genau so. Die Datei(Firmware) bekommt> einen Header im 1. Block. Diesen Block liest du Upgrade-Routine zuerst,> Entschlüsselt sie falls nötig.
Ja, wie schon von anderen gesagt wurde, während Du so einen Unsinn
geredet hast:
Schlaumaier schrieb:> Na und. Schau halt in den Eigenschaften nach. Das Erstellungsdatum steht> da drin. Und wenn die halbwegs gepflegt sind auch Versions-Nr. und ä.
MaWin schrieb:> Du ahnst nicht, wie erfinderisch Anwender sind.
erstens das und zweitens unterstelle ich eher Dummheit als böse Absicht.
Ja, danke, so wird das also nichts.
Torsten R. schrieb:> was ist den das Flash-Programm? Wenn das eh selbst geschrieben ist,> würde ein eigenes Datei-Format nehmen und nicht s-records.
Jetzt benutze ich einmal ein "genormtes" Format und schon ist's auch
wieder falsch ;)
> Was ist auf der anderen Seite des Flash-Programms? (Bootloader,> ST-Bootloader, SWD-programmer?)
Idealerweise sollte das alles funktionieren, lieber mache ich Abstriche
bei meinem Extrawünschen. Leider ist es nicht nur eine Hilfe für
Benutzer mit 10 linken Daumen. Das uC-Programm muss sicher sein können,
dass es auf der richtigen Hardware läuft. Wenn die Hardware-Unterschiede
klein genug sind, brauche ich dafür eine explizite Info.
Schlaumaier schrieb:> Schwachsinn.Schlaumaier schrieb:> Die Datei(Firmware) bekommt einen Header im 1. Block. Diesen> Block liest du Upgrade-Routine zuerst, Entschlüsselt sie falls nötig.> Nun liest sie alle Infos die sie braucht z.b. Gerätetyp, Version,> Datum etc. Danach entscheidet die Upgrade-Routine ob sie das> Upgrade durchführt oder sie verweigert
jetzt hast du gerade noch die Kurve gekriegt :)
Es wird sowieso so gemacht wie du sagst. Aber heute ist mir eingefallen,
dass es n verschiedene Hardware und m Firmware-Versionen geben kann. Die
Upgrade-Routine braucht also eine Liste mit kompatibler Hardware.
Weil die theoretisch beliebig lang werden kann, wäre es nett, wenn sie
nicht mit ins Flash müsste. Aber das scheint jetzt das kleinere Übel zu
sein. Also so eine Liste und eine eindeutige Hardware-ID in den
OTP-Bytes. Das finde ich zwar auch nicht so toll, aber es könnte einfach
und übersichtlich funktionieren.
Edit: die Liste muss mit ins Flash, damit das Anwendungsprogramm die
Ausführung verweigern kann.
Bauform B. schrieb:> Die> Upgrade-Routine braucht also eine Liste mit kompatibler Hardware.
Wenn Du bei der Kommunikation zwischen Update-Tool und MCU flexibel
bist, lässt sich das lösen.
Das Update-Tool bekommt zusammen mit dem Image eine Liste der Targets,
für die es geeignet ist. Es fragt das Target, was es gerne hätte, und
wenn die Firmware dafür geeignet ist, schickt es einen dafür angepassten
Header mit. So müssen die Geräte nur ihren eigenen Typ kennen.
Das könntest Du sogar noch verfeinern, indem Du ein File baust, das aus
mehreren Images besteht, jeweils mit der Tabelle der davon unterstützten
Targets - das Update-Tool sucht dann das jeweils passende aus.
Hmmm schrieb:> s fragt das Target, was es gerne hätte, und> wenn die Firmware dafür geeignet ist, schickt es einen dafür angepassten> Header mit. So müssen die Geräte nur ihren eigenen Typ kennen.
Wow.
Er sagt mal was sinnvolles. Ich bin beeindruckt. Wollte was ähnliches
schreiben. Immerhin mach ATI / AMD das selbe mit den Grafikkarten. Einer
für alle, und das Tool entscheidet selbstständig.
Aber du brauchst keine Liste in der Hardware führen. Du musst einfach
nur die Liste der Hardware in die Firmware übertragen und die Hardware
muss in der NEUEN Firmware nachschauen ob sie drin steht. Die Liste in
der Firmware kann Endlos sein. Ist das Upgrade halt 1 GB groß. Wayne. ;)
Und wenn du es so machst brauchst du auch kein Extra Tool. Den einfachen
Job kann die Upgrade-Routine in der Hardware machen.
Hmmm schrieb:> Das Update-Tool bekommt zusammen mit dem Image eine Liste der Targets,> für die es geeignet ist. Es fragt das Target, was es gerne hätte, und> wenn die Firmware dafür geeignet ist, schickt es einen dafür angepassten> Header mit.
Das ließe sich machen. Ein Trick dabei wäre, dass der Header "im Flug"
erzeugt wird und in der Datei nur Null steht. Wer dann mit einem
"illegalen" Tool flasht, bekommt ein Programm, das zu keiner Hardware
passt. Da lohnt es sich, eine besonders sorgfältig formulierte
Fehlermeldung auszugeben :) Das hört sich fast zu gut an...
> Das könntest Du sogar noch verfeinern, indem Du ein File baust, das aus> mehreren Images besteht, jeweils mit der Tabelle der davon unterstützten> Targets
so fein muss es ja garnicht werden
Schlaumaier schrieb:> Und wenn du es so machst brauchst du auch kein Extra Tool. Den einfachen> Job kann die Upgrade-Routine in der Hardware machen.
Eigentlich wäre es ja egal, ob das Spezialprogramm nun da oder dort
läuft. Aber nur eine der Möglichkeiten funktioniert auch mit komplett
gelöschtem Flash. Da fällt die Wahl leicht.
MaWin schrieb:> Bauform B. schrieb:>> Das Flash-Programm soll prüfen, ob die Firmware zur Hardware passt>> Du ahnst nicht, wie erfinderisch Anwender sind.
Ich hatte damals(tm) für ein Produkt den Bootloader inklusive
Firmware-Update-Mechanismus mittels USB und TFTP geschrieben. Der
Bootloader prüfte dabei, ob die Informationen in dem übertragenen Header
kompatibel zu dem aktuellen Produkt waren und wies bei Inkompatibilität
die Firmware ab. Da das RAM ziemlich beschränkt war und auch nicht
genügend Flash zum Zwischenspeichern des gesamten Updates zur Vefügung
stand, musste ich den Flashinhalt schon während der Übertragung löschen
und überschreiben.
Bei der Firmwaregenerierung entstanden zwei Binärdateien, in denen
jeweils der Flash-Inhalt für die geraden und ungeraden Bytes enthalten
war. Wir wählten dieses Format, da es so von der Fertigung zum
Vorprogrammieren der Flashes benötigt wurde. Diese Dateien wurden aber
auch durch ein Skript in eine Firmware-Update-Datei mit entsprechend
zusammengefügten 16 Bit-Werten konvertiert. Ich überlegte damals noch,
ob ich in der Firmware noch irgendwelche Vorkehrungen gegen Vertauschung
der Flash-Inhalte treffen sollte, verwarf aber diese Überlegung wieder,
da mir kein entsprechendes Szenario einfiel.
Ein Händler, der u.a. unsere Produkte vertrieb, entwickelte unter
anderem auch Firmware-Update-Programme für MacOS. Hierdurch konnte er
zum einen Apple-Kunden dazu bringen, die Produkte bei ihm zu kaufen.
Aber die Nachfrage war recht groß, so dass er die Update-Programme auch
einzeln (für DM 50,-?) verkaufte. Natürlich erhielt der Händler von uns
eine genaue Beschreibung des Dateiformats und Update-Protokolls. Das
Programm lies den Header unserer Firmware-Update-Dateien ein, wertete
die daran enthaltenen Versionsinformationen aus, zeigte sie an und
startete das Firmware-Update. Mein Bootloader prüfte den übertragenen
Header und war auch glücklich. Die Versionsinformationen waren in der
Update-Datei x86-typisch im Little-Endian-Format gespeichert. In der
Protokollspezifikation für die Kommunikation war die Byte-Reihenfolge
für den Update-Header auch genau definiert.
...
Dann wurden die Flashinhalte übertragen und somit ein Stück
Elektronikschrott produziert.
Auf Macs mit 68xxx und PowerPC wurde die Firmware-Datei beim Einlesen
nach Big Endian konvertiert, so dass der Header korrekt angezeigt werden
konnte. Das Firmware-Update-Protokoll war byteweise definiert, so dass
es hier auch keinen Fehler gab. Allerdings wurde auch der Flashinhalt
nicht eins zu eins übertragen, sondern ebenfalls dessen "Endianess"
konvertiert.
Schlaumaier schrieb:> Aber du brauchst keine Liste in der Hardware führen. Du musst einfach> nur die Liste der Hardware in die Firmware übertragen und die Hardware> muss in der NEUEN Firmware nachschauen ob sie drin steht. Die Liste in> der Firmware kann Endlos sein. Ist das Upgrade halt 1 GB groß. Wayne. ;)
Hast Du schonmal ein 1GB-File mit XMODEM o.dgl. über eine langsame
UART-Verbindung geschoben? Und nach Murphy's Law ist das jeweils
benötigte Flash-Image immer am Ende des Files.
Schlaumaier schrieb:> Und wenn du es so machst brauchst du auch kein Extra Tool.
Zeit is(s)t Geld.
Off-topic:
Schlaumaier schrieb:> Wow.> Er sagt mal was sinnvolles.
Sowas ausgerechnet von Dir?
Schlaumaier schrieb:> Wollte was ähnliches schreiben.
Klar.
Allmählich bin ich fast überzeugt, dass Du ein Teenager bist, der seine
ganzen "Vor 20 Jahren"-Stories von seinem Vater erzählt bekommen hat.
Das würde auch den Schreibstil und den infantilen Spitznamen "Pucki"
erklären.
Bauform B. schrieb:> Das ließe sich machen. Ein Trick dabei wäre, dass der Header "im Flug"> erzeugt wird und in der Datei nur Null steht.
Entweder das, oder das Firmware-File enthält Header für jede
Zielhardware, und zwar mit einer Signatur über Header und Flash-Image.
So kann man nur exakt die Hardware/Firmware-Kombinationen flashen, die
vorgesehen sind, und man bekommt aus dem Update-Tool kein
Schlüsselmaterial raus, mit dem man gültige
Header/Firmware-Kombinationen erzeugen könnte.
Bauform B. schrieb:> per E-Mail zwei s19-Dateien mit Firmware-Updates. Dateinamen und> -Datum gehen auf dem Weg ja gerne verloren.
Als erstes packt man die Dateien in ein .zip, das kann Windows seit XP
mit Bordmitteln auspacken. WinZip baut intern eine Checksumme ein, wenn
ein Byte verbogen ist, wird das Auspacken verweigert. Wird aufgrund
inkompatibler Zeichensätze der Dateiname des Archivs verbeult, tut das
nicht weh - der Inhalt behält seine Namen.
Bei gepackten Files bleibt auch das Änderungsdatum unverändert, wo ist
also Dein Problem?
Bei per Mail oder Browser übertragenen Dateien ist das Erstelldatum
immer der Beginn des Downloads, das Änderungsdatum ist gerne ein paar
Sekunden später, so lange, wie der Download gedauert hat. Auch beim
Auspacken eines Archivs werden Erstelldatum und letzter Zugriff auf den
Zeitpunkt des Entpackens gesetzt.
Egal, was Du machst, zumindest unter Windows hast Du "Erstellt am" und
"Letzter Zugriff" nicht unter Kontrolle.
Also: Archive versenden und eindeutige Dateinamen wählen, ich habe jede
Menge Files durch die Welt bewegt und kann Deine Grundporblem nicht
nachvollziehen.
Den Schwachsinn von Herrn Schlaumeier kann man nur ignorieren, der
schnallt es nicht - außer, dass er mal wieder seinen Nick ändern
sollte.
Hmmm schrieb:> Hast Du schonmal ein 1GB-File mit XMODEM o.dgl. über eine langsame> UART-Verbindung geschoben? Und nach Murphy's Law ist das jeweils> benötigte Flash-Image immer am Ende des Files.
Hat ja kein Mensch gesagt das ich das Muss.
Ich lese die Datenbank aus. Notfalls eine Indexdatei vorher.
Dann greife ich auf den Datenblock zu wo die Info steht. Wenn Ja, dann
greife ich auf den Datenblock zu wo das passende Flash liegt.
Diese Technik habe ich schon vor über 40 Jahren benutzt.
Etwas moderner arbeitet heute jede Datenbank.
Manfred schrieb:> Egal, was Du machst, zumindest unter Windows hast Du "Erstellt am" und> "Letzter Zugriff" nicht unter Kontrolle.
Saug dir irgend ein Treiber. Und schau dir die Eigenschaften an. Die
"erstellt" + geändert Eigenschaften der Datei sind NICHT verändert.
Schlaumaier schrieb:> Ich lese die Datenbank aus. Notfalls eine Indexdatei vorher.> Dann greife ich auf den Datenblock zu wo die Info steht. Wenn Ja, dann> greife ich auf den Datenblock zu wo das passende Flash liegt.
Es geht hier um einen STM32, was glaubst Du, wie der seine
Firmware-Updates bekommt? Auf einer USB-Festplatte?
Schlaumaier schrieb:> Diese Technik habe ich schon vor über 40 Jahren benutzt.
Mit was für Hardware hast Du da gearbeitet?
Warum hast Du mit 40 Jahren Berufserfahrung so erschreckend wenig
Ahnung?
Und warum schreibst Du mit 40+x wie ein 12jähriger?
An Deinen Stories ist etwas faul.
Schlaumaier schrieb:> Saug dir irgend ein Treiber. Und schau dir die Eigenschaften an. Die> "erstellt" + geändert Eigenschaften der Datei sind NICHT verändert.
Und wie ich Dir schon mehrfach erklärt habe, geht das NICHT mit
beliebigem Dateien. Du hast offensichtlich nicht die geringste Ahnung,
woher diese "Eigenschaften" im Windows-Explorer kommen.
Muss ich Dir jetzt auch noch erklären, was bei MIME-Attachments alles an
Informationen (nicht) übermittelt wird? Oder zitierst Du jetzt eh wieder
nur ein paar Satzfragmente und ignorierst alles, was Deinen Unsinn
widerlegt?
MeierKurt schrieb:> Es geht eher darum, was kann ich auf Empfängerseite tun, um zu> verhindern, dass irgendwer (z.B. sogenannte Schlaumaier) irgendwas als> Update draufflasht, was da nicht hingehört.
Wenn's hart auf hart kommt und man die Resourcen hat, dann mit einer
digitalen Signatur des Updates und einem entsprechenden Bootloader,
wobei der Rest des µC zugenagelt sein muss.
Zu den benötigten Ressourcen gehören nicht nur entsprechende
CPU-Leistung bzw. ein Hardware Accelerator und Speicher im µC, sondern
auch die Verwaltung des geheimen Schlüssels in der Firma und vernünftige
Produktionsabläufe zum signieren der Updates.
Bevor man das Fass aufmacht sollte man sich überlegen ob es wirklich,
wirklich, wirklich nötig ist, oder ob man doch mit einem einzigen
Schlaumeier-Idioten pro 10000 Kunden leben kann.
Schlaumaier schrieb:> Saug dir irgend ein Treiber. Und schau dir die Eigenschaften an. Die> "erstellt" + geändert Eigenschaften der Datei sind NICHT verändert.
Oh man. Jetzt fängst Du wieder mit diesem Mist an.
Dir ist offensichtlich der Unterschied zwischen Datei-Attributen und dem
Datei-Inhalt nicht klar, und kannst Dir irgendwie nicht vorstellen, dass
der Windows-Explorer eben bei bestimmten Dateien, z.B. DLL, EXE, JPG
etc. den Dateiinhalt interpretiert. Und dieser Dateiinhalt ist eben
genau nicht ein Datei-Attribut, wie Erzeugt, Geändert, letzter Zugriff.
Aber zwecklos, Du wirst es nicht verstehen.
Experte schrieb:> Dir ist offensichtlich der Unterschied zwischen Datei-Attributen und dem> Datei-Inhalt nicht klar, und kannst Dir irgendwie nicht vorstellen, dass> der Windows-Explorer eben bei bestimmten Dateien, z.B. DLL, EXE, JPG> etc. den Dateiinhalt interpretiert.
Da wird nix interpretiert. Der liest einfach nur die Metadaten der
Datei. Und die werden auch automatisch geschrieben, von JEDER Datei die
Windows in die digitalen Finger bekommt.
Experte schrieb:> Aber zwecklos, Du wirst es nicht verstehen.
Davon gehe ich auch aus.
Schlaumaier schrieb:> Da wird nix interpretiert. Der liest einfach nur die Metadaten der> Datei. Und die werden auch automatisch geschrieben, von JEDER Datei die> Windows in die digitalen Finger bekommt.
Was für ein Unsinn.
Created, Modified und Accessed unter "General" kommen vom Filesystem.
Daraus kannst Du je nach Übertragungsweg (insbesondere Mail-Attachments)
nur ableiten, wann die Datei bei Dir lokal gespeichert wurde.
Selbst Dein "Saug Dir einen Treiber"-Beispiel funktioniert nur dann,
wenn a) das Änderungsdatum bis zum Webserver überlebt hat, b) der Server
dieses Datum als Last-Modified-Header mitliefert und c) der Browser das
beim Speichern der Datei (als "Modified") übernimmt.
Die Angaben unter "Details" sammelt Windows aus mehreren Quellen
zusammen. Da tauchen teilweise die o.g. Filesystem-Daten wieder auf, und
je nach Dateityp kommen noch weitere Informationen - z.B. aus Resources
(bei EXEs) oder EXIF-Daten (bei JPGs) - dazu.
Bei einer Datei, die nicht unter diese Sonderfälle fällt, kannst Du Dich
nicht darauf verlassen, an irgendeiner Stelle das Datum der
ursprünglichen Erstellung oder Veränderung zu finden.
Warum hörst Du nicht einfach mal auf Leute, die sich auch unter der
Haube mit sowas auskennen, und argumentierst pausenlos mit
fehlinterpretierten Windows-Explorer-Informationen?
Schlaumaier schrieb:> Einige Gerätehersteller erlauben nämlich kein Downgrade. Was mich schon> zu mehren nicht sehr netten Wutausbrüchen kommen lies. Das schlimmste> war ein Bios-Update eines Asus-Laptop wo danach der Lüfter nur noch eins> kannte. VOLLGAS. Der Krach hat mich dazu gebracht ein neuen Laptop zu> kaufen aber nicht mehr von Asus.
Mit etwas Google-Fu hättest Du "AFUDOS" gefunden und das Problem gelöst:
https://rog.asus.com/forum/showthread.php?99490-Flash-any-most-Asus-motherboard-Bios-in-DOS-with-USB-tutorial-Intel-AMD-roll-back
Das Programm gibt's natürlich schon lange - das ist jetzt nur ein
zeitgenössischer Treffer.
Hannes J. schrieb:> Wenn's hart auf hart kommt und man die Resourcen hat, dann mit einer> digitalen Signatur des Updates und einem entsprechenden Bootloader,> wobei der Rest des µC zugenagelt sein muss.
Genau das gibt es in verschiedenen Härtegraden. Die von dir beschriebene
Methode ist der ganz große Hammer, statt digitaler Signatur kann es auch
ein Hash tun.
Hier entwickelte (aber nie in Serie verwendete) Methode: Vor das Hexfile
kommt ein Header, der u.a. Länge und Checksumme enthält. Das Resultat
wird komprimiert und verschlüsselt, und davor kommt noch mal Länge und
Checksumme des verschlüsselten Codes (+ ein Magic, um den größten Mist
auszufiltern). Es gibt sehr fixe Verschlüsselungsverfahren, Stichwort
Blockcodes.
Die Frage ist aber: will man trantütige User an Unfug hindern, der
Konkurrenz den Code vorenthalten oder das Ganze NSA-sicher machen? In
der Regel dürfte es um #1 und #2 gehen.
Eine weitere Möglichkeit wäre, dass das Update-Programm sich den
passenden Code von einem Server holt (mit oder ohne Verschlüsselung
usw.). Immer eine Frage des Anwendungsszenarios.
Max G. meinte:
> Das Resultat wird komprimiert und verschlüsselt,
Ich würd aber nur veschlüsseln, nicht komprimieren.
Sonst kann die NSA nen Angriff "auf wahrscheinliche Wörter" machen.
Der Packer hätte ja ne bekannte Struktur, egal was Du nimmst.
mfg
~Mercedes~ . schrieb:> Ich würd aber nur veschlüsseln, nicht komprimieren.> Sonst kann die NSA nen Angriff "auf wahrscheinliche Wörter" machen.
Das funktioniert bei einer unkomprimierten Firmware deutlich besser.
Zum einen schickt man üblicherweise keinen ZIP-Header o.dgl. mit, zum
anderen hast Du in komprimierten Dateien eine relativ gleichmässige
Verteilung ohne auffällige Häufung bestimmter Zeichen.
Hey!
Guten Morgen, Hmmm!
Hmmm meinte;
> Zum einen schickt man üblicherweise keinen ZIP-Header o.dgl. mit, zum> anderen hast Du in komprimierten Dateien eine relativ gleichmässige> Verteilung ohne auffällige Häufung bestimmter Zeichen.
Nö.
Wenn Du ne Datei mit einem guten Cryptoalgo verschlüsselst,
hast Du ne Datei mit glichmäßigem "Rauschen". Die
ist dann so zufällig, das Du sie nicht mehr packen kannst.
Der Cracker weiß nicht mehr, was Du verschlüsselt hast.
Packst Du die Datei aber vorher, hat die Datei ne bekannte Struktur
und ist nicht zufällig.
Der Packer sucht in der zu packenden Datei ja die Häufigkeit
der Symbole und baut ne Symboltabelle zum wiederentpacken auf,
ne Baumstruktur mit Metadaten.
Die kennt der Cracker, die sind ja bekannt, wenn der Packalgo
bekannt ist. Und schon hat er (oder das weiße Karnickel?) wahr-
scheinliche Wörter, wo er ansetzen kann.
Also -- Nicht packen, nur verschlüsseln!!
mfg
Die angehängte Format-Skizze beschreibt das Update Format, dass ich für
meinen nrf52 Bootloader verwende. In einem unverschlüsselten header
steht die Version der Software, um was für eine Software es sich handelt
und auf welcher Hardware sind lauffähig ist. Verschlüsselt / Signiert
ist das mit einem privaten Schlüssel, der mit im Bootloader liegt. Zur
Verschlüsselung / Signierung wird AES/CGM verwendet, dass ist relativ
einfach zu implementieren (auch in Software).
Der unverschlüsselte, aber signierte header erlaubt, Meta-Informationen
auch vom Flash-Program zu lesen. Leider wurde die Readout-Protection vom
nrf52 geknackt. Wer etwas Geld in die Hand nimmt, kann das einfach
umgehen. Da Du Deine Firmware ja aber auch nicht verschlüsseln wolltest,
hindert eh niemanden daran, die Firmware direkt mit JTAG/SWD auf die
Hardware zu spielen.
Die SHA2 Checksumme um das ganze Packet ist nur für das Flash-Program,
um einfache Beschädigungen am Packet zu erkennen.
~Mercedes~ . schrieb:> Packst Du die Datei aber vorher, hat die Datei ne bekannte Struktur> und ist nicht zufällig.
Hexfiles sind in der Regel alles andere als zufällig, da gibt es
reichlich Stoff für Known Plaintext Attacks. Beim ZIP-Algorithmus
beginnt die gepackte Datei (wenn man den Header weglässt) identisch zur
ungepackten und verweist dann bei bereits bekannten Abschnitten zurück.
Abgesehen vom möglicherweise erhöhten Vorkommen des jeweiligen
Escape-Zeichens (für das man das ansonsten am wenigsten genutzte Zeichen
nimmt) reduziert sich so einfach nur die Entropie. Anders gesagt: die
Datei wird rauschförmiger.
Wenn natürlich ein festes Dictionary am Anfang der Datei steht, sieht es
anders aus. Aber auch da ist wieder die Frage: will man die NSA
raushalten, den Wettbewerb oder einfach nur sich gegen DAUs absichern?
Manfred schrieb:> Bei gepackten Files bleibt auch das Änderungsdatum unverändert, wo ist> also Dein Problem?
Praktische Erfahrung ;) Packen hilft auch nur bis zum Auspacken, danach
kann man Name und Datum vergessen. Weil der Benutzer natürlich nichts
gemacht hat, muss wohl Magie im Spiel sein. Aber das ist für diese
Aufgabe hier auch ziemlich egal; alle Daten, die zusammen gehören,
müssen in einer einzigen Datei stehen und fertig.
Hannes J. schrieb:> ...Verwaltung des geheimen Schlüssels in der Firma und vernünftige> Produktionsabläufe zum signieren der Updates.>> Bevor man das Fass aufmacht sollte man sich überlegen ob es wirklich,> wirklich, wirklich nötig ist, oder ob man doch mit einem einzigen> Schlaumeier-Idioten pro 10000 Kunden leben kann.
Kann man, bzw. muss man. Signierte und/oder verschlüsselte Updates
helfen gegen Übertragungsfehler und Verwechselungen, aber das geht auch
viel einfacher. Gegen mutwillige Manipulationen hilft nur
schreibgeschützte Hardware. Die ist dann Schrott, wenn ein Update nötig
wird.
Andererseits reichen für eichfähige Geräte ein bis drei bessere
Aufkleber über den Gehäuseschrauben. Updates sind dann zwar möglich,
aber von außen sichtbar. Wenn man diese Art Sicherheit in Firmware
nachbauen wollte, darf die nicht auslesbar sein und könnte per
challenge-response nachweisen, dass sie echt ist. Updates wären aber
trotzdem manipulierbar und eine gute Fälschung wäre nicht nachweisbar :(
Max G. schrieb:> Die Frage ist aber: will man trantütige User an Unfug hindern, der> Konkurrenz den Code vorenthalten oder das Ganze NSA-sicher machen? In> der Regel dürfte es um #1 und #2 gehen.
Erstmal geht es hier nur um #1.
Nop schrieb:> Mit etwas Google-Fu hättest Du "AFUDOS" gefunden und das Problem gelöst:> https://rog.asus.com/forum/showthread.php?99490-Flash-any-most-Asus-motherboard-Bios-in-DOS-with-USB-tutorial-Intel-AMD-roll-back
Hätte ich vielleicht. Habe ich aber leider nicht. Wobei ich nicht sicher
bin ob ich auch das richtige alte Bios gefunden hätte. Naja der Lappi
Liegt seit einigen Jahren in der Ecke herum. (lief damals + heute mit
XP).
Ich habe mir einfach für 50 Euro + Festplatte ein besseren bei
Ebay-Kleinanzeigen gekauft. (Musste nur den Plastikschalterhebel neu
ankleben + eine Festplatte einbauen). Dafür habe ich jetzt ein Laptop
mit Raid-System und (abgeschalteten DVD-T) Fernsehempfang. ;)
Max G. schrieb:
> Die Frage ist aber: will man trantütige User an Unfug hindern, der> Konkurrenz den Code vorenthalten oder das Ganze NSA-sicher machen? In> der Regel dürfte es um #1 und #2 gehen.
In meinen Augen will man verhindern das Leute mit einer manipulierten
Firmware irgendwas freischalten.
Rein rechtlich gesehen reicht es nämlich wenn die Update-Routine
erkennt, ob die Firmware für das Gerät geeignet ist. Dazu reicht ein
passender Code im Gerät und man muss halt im schlimmsten Fall für jedes
Modell die passenden Firmware auf den Server legen.
Der Rest hier, ist nur Diskussion um irgendwas z.b Freischaltfunktionen
die man teuer bezahlen muss o. Software die die Chinesen nicht
nachmachen sollen o. was auch immer zu schützen.
Da geht es rein um die Interessen des Anbieters NICHT um trantütige
User.
Davon abgesehen machen 98% der Anwender keine Firmware-Updates. Inkl.
mir. Ich sehe absolut kein Grund ein Gerät was läuft und sein Job macht,
mit irgendwelchen Unsinn voll zu müllen, und dabei das Risiko zu tragen
das es bei einen Fehlschlag ein Türstopper wird.
Obwohl es ja heute üblich ist, das der User als Betatester für
schlampige Software-Entwickler arbeitet. Und wenn ich mir einige
Aussagen hier im Forum lese, wundert mich das nicht.
Ich mag ja in Basic schreiben. Aber ich habe noch NIE für eine Software
ein Update herausgegeben wegen eines Programmfehler bzw. fehlerhafte
Funktion.
Ich gebe meist nur UPGRADES heraus, es sei den es haben sich Daten des
Datenbestandes (gut gefüllte Datenbank meist mit Preisen) geändert.
~Mercedes~ . schrieb:> Wenn Du ne Datei mit einem guten Cryptoalgo verschlüsselst,> hast Du ne Datei mit glichmäßigem "Rauschen". Die> ist dann so zufällig, das Du sie nicht mehr packen kannst.
Jetzt bringst Du etwas durcheinander.
Es ging darum, ob man die Firmware vor dem Verschlüsseln komprimieren
sollte oder gar nicht. Nach dem Verschlüsseln geht das
selbstverständlich nicht mehr, das produziert nur Overhead.
~Mercedes~ . schrieb:> Packst Du die Datei aber vorher, hat die Datei ne bekannte Struktur> und ist nicht zufällig.
Ein gepacktes Binary (natürlich ohne Header mit Magic Number o.dgl.) ist
deutlich "zufälliger" als ein ungepacktes. Guck Dir einfach mal die
Verteilung bei einem EXE im Vergleich zum gleichen EXE in einem ZIP an.
~Mercedes~ . schrieb:> Die kennt der Cracker, die sind ja bekannt, wenn der Packalgo> bekannt ist.
Es ist wesentlich effizienter, einen Block zu entschlüsseln und beim
Resultat die Verteilung zu analysieren, als auf irgendeine Komprimierung
zu prüfen, von der man vorher nicht einmal weiss, ob sie existiert.
Aber wer genug Ressourcen hat, würde ohnehin nicht versuchen, einen
(evtl. nicht mal bekannten) Algorithmus zu brute-forcen, sondern würde
einfach das Update flashen und danach den Chip öffnen.
Und jetzt nochmal zum allseits beliebten Schlaumaier/Alexander/Pucki:
Schlaumaier schrieb:> mir. Ich sehe absolut kein Grund ein Gerät was läuft und sein Job macht,> mit irgendwelchen Unsinn voll zu müllen, und dabei das Risiko zu tragen> das es bei einen Fehlschlag ein Türstopper wird.
Besonders bei Geräten mit Internetanbindung ist es enorm sinnvoll, keine
Updates einzuspielen. Einige nette Unternehmer freuen sich immer über
soziale Menschen, die Rechenzeit und Internetanbindung für den Versand
von Mails mit wertvollen Produktinformationen zur Verfügung stellen.
Schlaumaier schrieb:> Ich mag ja in Basic schreiben. Aber ich habe noch NIE für eine Software> ein Update herausgegeben wegen eines Programmfehler bzw. fehlerhafte> Funktion.
Ja, Du bist der einzige "Entwickler", der nie Fehler macht. Wir sind so
stolz auf Dich, Puckilein, dafür darfst Du Dir auch einen Kinderriegel
aus der Schublade nehmen.
A propos, Du hattest ein paar Fragen noch nicht beantwortet:
Hmmm schrieb:> Schlaumaier schrieb:>> Diese Technik habe ich schon vor über 40 Jahren benutzt.>> Mit was für Hardware hast Du da gearbeitet?> Warum hast Du mit 40 Jahren Berufserfahrung so erschreckend wenig> Ahnung?> Und warum schreibst Du mit 40+x wie ein 12jähriger?
Schlaumaier schrieb:> In meinen Augen will man verhindern das Leute mit einer manipulierten> Firmware irgendwas freischalten.
Du denkst an Oszilloskope, bei denen man Bandbreite(!) freischalten
kann? Das ist Kapitalismus im Endstadium.
Ich bin froh, dass sich das hier auf natürliche Weise regelt. Zum
Beispiel: manche Sachen kann der Benutzer selbst in der Konfig
freischalten. Nur bringt ihm das nichts ohne zusätzliche Hardware, die
per Spedition kommt und von 2 Monteuren installiert wird.
> Ich gebe meist nur UPGRADES heraus
Ist das so ein Unterschied wie Haarspalterei zu Wortklauberei? Ein
aktueller Fall: man kann die Uhr normal nicht von Hand stellen, weil man
ja sowieso NTP hat. Jetzt möchte jemand, dass es immer geht. Bug oder
Feature? Ist das dann ein Update, Upgrade oder doch ein Downgrade?
Hmmm schrieb:> Ja, Du bist der einzige "Entwickler", der nie Fehler macht.
Quatsch. Ich gebe Beta-Versionen an ausgewählte Tester heraus. Damit
habe ich jede Version im Griff. Die melden mir Fehler zurück. Nach einer
längeren Zeit gebe ich dann die richtige Version heraus und die ist
immer Fehlerfrei gewesen.
Aber ich habe auch kein Termindruck. Kenne meine Schwächen und habe
schon früh mein Chefs klar gemacht das eine nicht sauber getestete
Version auf den Ruf der Firma zurück fällt.
Wenn der Ruf aber erst mal Versaut ist. oder man so eine Macht hat wie
MS ist es eh schei** egal.
Ich bin einfach nicht so arogant und behaupte ich keine mache. Ergo
lasse ich vernünftig testen. Das ist alles. Und das nicht nach
irgendwelchen Regeln sondern nach den DAU-Verfahren = Nimm, installiere
und sag mir was passiert. Auf die Weise weiß ich auch ob ich
Design-Konzepte ändern muss.
Thread beobachten
Seitenaufteilung abschalten