Und dann natürlich ein Beispiel, bei dem die Chancen für diese Art des Angriffs wegen der geringen Komplexität der Anwendung naturgemäß relativ schlecht stehen.
Warum hast du als Beispiel nicht gleich ein Programm der Art:
.CSEG .ORG 0 main: rjmp main
gewählt? Ich meine, dann wäre deine Beweisführung, daß nicht sein kann, was nicht sein darf, doch gleich so richtig wasserdicht. Ich würde mir dann jedenfalls nicht mehr trauen, einen Gegenbeweis zu führen.
Allerdings: Je simpler die Anwendung und je weniger Eingangssignale, desto schneller führt wiederum der brute force-Angriff zum Ziel, der ohne jede Sicherheitslücke auskommt.
Klar ist aber, daß ich eigentlich µC mit deutlich komplexeren Anwendungen meinte, bei denen das Auslesen überhaupt _lohnend_ erscheint. Für ein bissel Portgeklimper reißt sich niemand den Arsch auf. Das ist viel schneller selbst programmiert als reverse engineered.
Schon da gibt es allerdings möglicherweise einen Angriffspunkt. Sowas ähnliches hatte ich schonmal: Ein BCD-Encoderschalter als Eingangssignal. Schalter durch DIP-Switches ersetzt, illegalen BCD-Code erzeugt und... Bumm.
Der Herr Programmierer hatte die Einsprünge für die legalen BCD-Codes als Adresstabelle organisiert und ist dann in feinster Profimanier mit push, push, ret gesprungen. Bloß war die Tabelle halt bei 9 zu Ende und ein Abfrage zu dieser Grenze schien ihm wohl überflüssig, der Schalter konnte ja schließlich keine anderen Codes erzeugen. Meinte jedenfalls dieser Möchtegern-Profi. Tatsache ist nämlich, daß beim normalen Umschalten des Schalter schon oft genug 1111b an den Eingängen lag und das Programm nur deshalb nicht schon im normalen Betrieb abgestürzt ist, weil die Entprellung, die er immerhin vorgesehen hatte, diesen Code "geschluckt" hat. Jedenfalls wenn man den Schalter nicht absichtlich langsam gedreht hat...