Kleine Anfängerfrage, ich wollte wissen wie oft es möglich ist, MCUs in Verbraucherelektronik auszulesen oder ob die eurer Erfahrung nach immer ab Factory geschützt wurden (Fuses, etc.) Ich meine kleine Gadgets wie elektrische Zahnbürsten, Spielzeuge, Dimmer, etc. keine teuren Sachen. Weil ich würde gerne manche der Schaltkreise nachzeichnen und verstehen wie sie funktionieren, aber die Mühe kann ich mir sparen wenn jedesmal eine MCU als Blackbox in der Mitte liegt :(
Vieles sind maskenprogrammierte Chips, die nicht mal ein Gehäuse haben, sondern einfach nackt auf die Platine gebondet und mit einem Plastikklecks umhüllt werden. Da kannst Du nichts auslesen. Du kannst ja einfach mal einen Taschenrechner oder eine Fernbedienung aufmachen. Mehr als ein Foto wird da nicht drin sein. fchk
Selbst wenn du sie auslesen kannst: -)Wie unterscheidest du in dem Dump Daten und Code? -)Wie machst du aus den nackten Daten Assemblerinstruktionen? -)Wie machst du aus dem Assemblercode was verständlicheres wie C? IMHO kann man selbst ohne Kenntnis des µC-Inhalts einige Funktionsblöcke verstehen, z.B.: einer Halbbrücke ist es ja egal woher ihr Ansteuersignal kommt.
Reving schrieb: > Weil ich würde gerne manche der Schaltkreise nachzeichnen und verstehen > wie sie funktionieren, aber die Mühe kann ich mir sparen wenn jedesmal > eine MCU als Blackbox in der Mitte liegt :( Mumpitz, blackBox-Analyse ist normales Handwerkszeug eines Technikers. Eigentlich jedes Menschen, den man weiß je nie was im Kof seines Gegenübers vorgeht, man steht also auch da vor einer Block Box. Und manche wissen nicht mal, was in ihrem eigenen Kopf vorgeht, ...
ziege schrieb: > -)Wie unterscheidest du in dem Dump Daten und Code? > -)Wie machst du aus den nackten Daten Assemblerinstruktionen? > -)Wie machst du aus dem Assemblercode was verständlicheres wie C? Ja aber hallo, dann wird das Leben doch erst interessant. Opcode Tabellen durchwühlen, Subroutinen identifizieren, so in etwa die Arbeit eines Paläontologen. Bei den kleinen PICs die ich bisher so antreffe wäre das mit vertretbarem Aufwand machbar. Dass es bei den schwarzen Blobs wohl nichts auszulesen gibt habe ich aber vermutet.
Reving schrieb: > Weil ich würde gerne manche der Schaltkreise nachzeichnen und verstehen > wie sie funktionieren, aber die Mühe kann ich mir sparen wenn jedesmal > eine MCU als Blackbox in der Mitte liegt :( Wenn es um Schaltungsteile geht, ist es meistens sogar einfacher, die MCU als Blackbox zu betrachten, als zu versuchen, fremden Quelltext zu verstehen. Die Signalformen an den Pins sprechen oft eine viel deutlichere Sprache selbst als der Quelltext (oder der Programmierer).
Reving schrieb: > Weil ich würde gerne manche der Schaltkreise nachzeichnen und verstehen > wie sie funktionieren, aber die Mühe kann ich mir sparen wenn jedesmal > eine MCU als Blackbox in der Mitte liegt :( Daraus kannst du lernen dass man die Funktionalität heute eben nicht mehr aus der HW ablesen kann, sondern die Magie in der Software steckt.
ziege schrieb: > Selbst wenn du sie auslesen kannst: > -)Wie unterscheidest du in dem Dump Daten und Code? In mühevoller Handarbeit beim... > -)Wie machst du aus den nackten Daten Assemblerinstruktionen? ...Disassemblieren. Ist machbar, aber halt, je nach Image-Größe, zeitaufwendig. > -)Wie machst du aus dem Assemblercode was verständlicheres wie C? Wozu? Um zu verstehen, was es macht, reicht doch der Assemblercode. Zugegeben, je nach verwendetem Kern könnte das etwas eklig werden. Aber nicht unmöglich, vorausgesetzt, man kommt an den Speicherinhalt dran.
Ich würde jetzt erwarten, dass der Code bei Reving schrieb: > elektrische Zahnbürsten, Spielzeuge, Dimmer, etc. eher überschaubar, aber auch wenig interessant ist.
Ich schütze nichts. Kann man theoretisch alles aus meinen Arm-CPUs wieder auslesen. Ich wünsche dem viel Spass, der die 150 KBytes disassembliert, und dann versucht die 20000 C++ Zeilen zu ermitteln auch noch zu verstehen. Ich glaube, dafür muss man schon ich Nordkorea leben.
PittyJ schrieb: > Ich schütze nichts. Kann man theoretisch alles aus meinen Arm-CPUs > wieder auslesen. > > Ich wünsche dem viel Spass, der die 150 KBytes disassembliert, und dann > versucht die 20000 C++ Zeilen zu ermitteln auch noch zu verstehen. > Ich glaube, dafür muss man schon ich Nordkorea leben. Er kann auch einfach die SW 1:1 kopieren und mit seiner eigenen Hardware verkaufen. Plagiate kennst du?
Nachdenklicher schrieb: > ...Disassemblieren. Ist machbar, aber halt, je nach Image-Größe, > zeitaufwendig. Machbar ist es natürlich, aber diese Fragen kommen hier sehr oft von Menschen, die das vollkommen unterschätzen/noch nicht besonders viel Ahnung haben und erwarten, dass das quasi so einfach ist wie kompilieren. Das soll jetzt niemanden davon abhalten, es zu versuchen - der Lerneffekt ist sicher beachtlich - aber es rückt die Erwartungen vielleicht gerade.
Cyblord -. schrieb: > Er kann auch einfach die SW 1:1 kopieren und mit seiner eigenen Hardware > verkaufen. Plagiate kennst du? Dagegen könnte man sich durch Verknüpfung mit bspw. der vom Hersteller vergebenen Controller-ID einfach wehren. Ich stecke in der Chip-Herstellung leider nicht wirklich drin. Wie sicher ist bspw. die fortlaufende ID des Herstellers? Ist diese mit Tricks manipulierbar? Wobei ein Schutz gegen Auslesen ja nicht wirklich etwas kostet, üblicherweise reicht ein Flag. Dass jemand mit genug Energie diesen knacken kann - geschenkt. Aber viele hält so ein einfacher Schutz sicherlich ab. Auf jeden Fall ist Code-Schutz ein interessantes Thema. da gibt es viele "Gemeinheiten" von Herstellerseite (Code in gepuffertem RAM etc.).
Walter T. schrieb: > Wenn es um Schaltungsteile geht, ist es meistens sogar einfacher, die > MCU als Blackbox zu betrachten, als zu versuchen, fremden Quelltext zu > verstehen Es geht nicht um fremden Quelltext, sondern um fremden Binärcode, bestenfalls (richtig) disassambled. Fremder Quelltext ist dagegen noch einfach zu lesen.
Chris D. schrieb: > Cyblord -. schrieb: >> Er kann auch einfach die SW 1:1 kopieren und mit seiner eigenen Hardware >> verkaufen. Plagiate kennst du? > > Dagegen könnte man sich durch Verknüpfung mit bspw. der vom Hersteller > vergebenen Controller-ID einfach wehren. Ja oder einfach die Protection aktivieren. Das ist mal der einfachste und erste Schritt das zu verhindern. > Ich stecke in der Chip-Herstellung leider nicht wirklich drin. > Wie sicher ist bspw. die fortlaufende ID des Herstellers? Ist diese mit > Tricks manipulierbar? Wenn du die SW auslesen und ändern kannst, kannst du mit etwas mehr Aufwand auch die ID die erwartet wird ändern. So wurden in den 90ern die NoCDCracks erstellt. Man musste im Binary nur den Assembler Compare finden und durch ein NOP ersetzen. Eine ID zu finden und zu tauschen ist noch einfacher. Und wie soll das in der Praxis laufen? Woher weiß die SW in jedem Artikel welche ID sie erwartet? Es erhöht den Produktionsaufwand bringt aber nur wenig mehr Sicherheit. Wenn dann muss man gleich Controller mit kryptografischer OTP Region usw. nehmen. Oder gleich Krypto-ICs mit auf der Platine vorsehen. Signed Firmware, Secure Boot gibt es alles. > Wobei ein Schutz gegen Auslesen ja nicht wirklich etwas kostet, > üblicherweise reicht ein Flag. Dass jemand mit genug Energie diesen > knacken kann - geschenkt. Aber viele hält so ein einfacher Schutz > sicherlich ab. Wie immer: 100% Schutz gibt es nicht. Aber deshalb muss man nicht auf jede Sicherheit verzichten. Grade wenn sie nichts kostet. Gegen das kriminelle Superhackergenie wird man sich nicht wehren können. Aber man kann den Aufwand für ein Plagiat recht hoch machen.
:
Bearbeitet durch User
ziege schrieb: > Machbar ist es natürlich, aber diese Fragen kommen hier sehr oft von > Menschen, die das vollkommen unterschätzen/noch nicht besonders viel > Ahnung haben und erwarten, dass das quasi so einfach ist wie > kompilieren. Das stimmt. Ich gebe zu, bei meinem ersten Disassembler-Projekt habe ich das auch leicht falsch eingeschätzt... Daß es mehr ist als kompilieren, war mir klar, aber so ein paar fiese Details habe ich halt nicht erwartet. Aber aus Fehlern lernt man. (naja, die meisten zumindest) ;-)
Cyblord -. schrieb: > Wenn du die SW auslesen und ändern kannst, kannst du mit etwas mehr > Aufwand auch die ID die erwartet wird ändern. > Und wie soll das in der Praxis laufen? Woher weiß die SW in jedem > Artikel welche ID sie erwartet? Die Software kann den gerade zu programmierenden Chip vorher auslesen. Dann hat sie die ID und kann den zu programmierenden Code entsprechend anpassen. Bspw. indem sie die ID als kryptografischen Schlüssel für Teile des Codes verwendet, die erst zur Laufzeit entschlüsselt werden. > Es erhöht den Produktionsaufwand bringt > aber nur wenig mehr Sicherheit. Es verhindert zumindest die Auführung des Codes auf einem anderen Controller. > Wenn dann muss man gleich Controller mit kryptografischer OTP Region > usw. nehmen. Oder gleich Krypto-ICs mit auf der Platine vorsehen. Signed > Firmware, Secure Boot gibt es alles. Ja, das geht natürlich auch - kostet aber wieder. Man muss dann wie immer abwägen. > Wie immer: 100% Schutz gibt es nicht. Aber deshalb muss man nicht auf > jede Sicherheit verzichten. Grade wenn sie nichts kostet. Gegen das > kriminelle Superhackergenie wird man sich nicht wehren können. Aber man > kann den Aufwand für ein Plagiat recht hoch machen. Sehe ich auch so. Ein simples Flag für rudimentären Ausleseschutz kostet nichts.
Chris D. schrieb: > Die Software kann den gerade zu programmierenden Chip vorher auslesen. > Dann hat sie die ID und kann den zu programmierenden Code entsprechend > anpassen. Bspw. indem sie die ID als kryptografischen Schlüssel für > Teile des Codes verwendet, die erst zur Laufzeit entschlüsselt werden. Die Schwachstelle ist dann der Punkt an dem SW die Hardware-ID ausliest. Dort kann man die ID manipulieren so dass die SW immer die gleiche ID bekommt, für welche sie auch funktioniert. > Es verhindert zumindest die Auführung des Codes auf einem anderen > Controller. Es baut eine weitere Hürde ein. Ja.
Cyblord -. schrieb: > PittyJ schrieb: >> Ich schütze nichts. Kann man theoretisch alles aus meinen Arm-CPUs >> wieder auslesen. >> >> Ich wünsche dem viel Spass, der die 150 KBytes disassembliert, und dann >> versucht die 20000 C++ Zeilen zu ermitteln auch noch zu verstehen. >> Ich glaube, dafür muss man schon ich Nordkorea leben. > > Er kann auch einfach die SW 1:1 kopieren und mit seiner eigenen Hardware > verkaufen. Plagiate kennst du? Nö, er braucht noch die komplette optische Spezial-Hardware im Wert von 50K€ dazu. Das bauen nicht mal die Chinesen nach.
PittyJ schrieb: > Nö, er braucht noch die komplette optische Spezial-Hardware im Wert von > 50K€ dazu. > Das bauen nicht mal die Chinesen nach. Naja dann scheint die SW bei euch nicht das teuerste Teil zu sein. Dann kann man sich das in der Tat sparen. Das Argument für den Aufwand der Disassemblierung zieht aber eben nicht. Weil meistens einfach kopiert wird.
Wolfgang schrieb: > Walter T. schrieb: >> Wenn es um Schaltungsteile geht, ist es meistens sogar einfacher, die >> MCU als Blackbox zu betrachten, als zu versuchen, fremden Quelltext zu >> verstehen > > Es geht nicht um fremden Quelltext, sondern um fremden Binärcode, > bestenfalls (richtig) disassambled. Fremder Quelltext ist dagegen noch > einfach zu lesen. Mein Punkt. Fremden Quelltext zu durchforsten ist oft schon mehr Arbeit als die Schaltung in vivo zu sezieren. Beim Disassembly ist es nochmal ein paar Nummern mehr. Das gilt natürlich nur, wenn die Schaltung der Punkt des Interesses ist (was ja die ursprüngliche Fragestellung war).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.