Forum: Compiler & IDEs wie kommt das _passende_ Update in den uC?


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 Bauform B. (bauformb)


Lesenswert?

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?!

von MaWin (Gast)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Schlaumaier (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Hmmm (Gast)


Lesenswert?

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.

von MeierKurt (Gast)


Lesenswert?

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.

von K. S. (the_yrr)


Lesenswert?

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.

: Bearbeitet durch User
von Schlaumaier (Gast)


Lesenswert?

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 ;)

von Schlaumaier (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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ört

Schlaumaier 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 ..... ;)

von Hmmm (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Hmmm (Gast)


Lesenswert?

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 ä.

von Bauform B. (bauformb)


Lesenswert?

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.

: Bearbeitet durch User
von Hmmm (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

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.

von Hmmm (Gast)


Lesenswert?

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.

von Hmmm (Gast)


Lesenswert?

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.

von Manfred (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Hmmm (Gast)


Lesenswert?

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?

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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.

von Experte (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Hmmm (Gast)


Lesenswert?

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?

von Nop (Gast)


Lesenswert?

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.

von Max G. (l0wside) Benutzerseite


Lesenswert?

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.

von Lotta  . (mercedes)


Lesenswert?

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

von Hmmm (Gast)


Lesenswert?

~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.

von Lotta  . (mercedes)


Lesenswert?

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

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Angehängte Dateien:

Lesenswert?

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.

von Max G. (l0wside) Benutzerseite


Lesenswert?

~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?

von Bauform B. (bauformb)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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. ;)

von Schlaumaier (Gast)


Lesenswert?

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.

von Hmmm (Gast)


Lesenswert?

~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?

von Bauform B. (bauformb)


Lesenswert?

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?

von Schlaumaier (Gast)


Lesenswert?

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.

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.

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