Hallo, nachdem ich seit ein paar Tagen schon fleisig alles zum Heizungssteller Thermotronic gelesen habe war es nun so weit. Eben mal das Moped geöffnet und reingeschaut - und siehe da ein Atmega 169V ist zu sehen. MISO, MOSI etc mit meinem USB-ISP Programmer verbunden - und siehe da, er wird erkannt. Das Hexfile aus dem Flashspeicher lies sich auch auslesen. Meine Frage ist nun wie man aus diesem .hex wieder nachvolziehbaren Code generiert. Also mal davon ausgehend das das Dingens ursprünglich in Assambler geschrieben ist. Benutzen tue ich das AVR Studio 4.xx Vielen Dank für die Hilfe fg Rocco
>Meine Frage ist nun wie man aus diesem .hex wieder nachvolziehbaren Code >generiert. Gar nicht. Das Hexfile ist das, was nach dem Assemblieren bzw. Compilieren übrigbleibt, d.h. es sind keine Labels oder Kommentare mehr drin. Alles was du tun kannst, ist das Hexfile in AVRStudio zu laden und dir das Assemblerlisting anschauen. Sehr aussagekräftig ist das aber nicht; um den Code zu verstehen wirst du eine Menge Zeit investieren müssen.
Danke für die schnelle Antwort. Das ist aber schade... Dachte das vieleicht jemand irgendwelche Erfahrungen mit Disasamblern hatt und die weiter geben könnte. fg Rocco
Hi! Suche mal nach REAVR24. Mit dem habe ich mal sowas gemacht. Stelle es dir aber nicht so einfach vor, weil Konstanten und Texte nicht unbedingt am Ende des Progs stehen müssen. Es braucht sehr viel Zeit um das alles auseinanderzupussementieren. Viel Erfolg, Uwe
"Gar nicht" halte ich für etwas übertrieben, ich sehe es ein wenig anders. Allerdings hat unser Gast Recht, dass es eine Sauarbeit sein kann. Ich habe bzgl. AVRs keine Erfahrung mit Disassemblern, dafür jedoch mit verschiedensten anderen Systemen. Das HEX-File 'besteht nur aus Zahlen'. Jeder Prozessorbefehl kann über so eine 'Zahl' angesprochen werden. Somit stehen in dem Hex-File nur alle Befehle, die abgearbeitet werden sollen (zusätzlich mit weiteren Parametern wie z.B. Werte, die statisch geladen werden). Ein Assembler wandelt die schönen ASM-Mnemonics in die binären Prozessorbefehle. Ein Disassembler macht es halt umgegehrt. Das Problem ist nun, wie Gast schon schrieb, dass alle Labels, Kommentare, etc. weg sind. Statt z.B. "rjump loop" steht dann dort "rjump 0x0A0A" o.Ä. oder statt "add summe, zahl" steht dann dort "add r16, r17". Du musst also alles auseinandernehmen und verstehen. Wenn dich nur ein Teil der Implementierung interessiert (um z.B. einen Bug zu beseitigen), dann finde ich Disassemblieren hervorragend. Sonst ist es, ab einer bestimmten Programmlänge, der Horror.
Bei einem Atmega 169V hat man schlechte Karten. Der ist mit Sicherheit in einer Hochsprache programmiert. Da gibt es unnötig viele Maschinenbefehle(Push/Pop...) und der Code ist sicher sehr umfangreich. Aber prinzipiell geht es. Auch oben genanntes Programm REAVR24 hilft gut. Bei kleinen Speicher und Maschinenprogramm hat man Erfolg. Habe ich schon gemacht. Bedingung sind jedoch gute Kenntnisse in der Assemblerprogrammierung!! Wie groß ist denn die Datei? Evtl. hochladen?
Hallo, das sind ja vilen Antworten - Danke für die Umfangreichen Informationen. Die .hex ist 45kB groß. Ob ich die jedoch hochladen sollte - da bin ich mir nicht so sicher ob das in Ordnung geht - zumindest aus sicht des Herstellers. Gern würde ich jedoch über eine "das näher erklähren". In Assembler habe ich leider nur ganz wenig Erfahrungen - Hatte mal einen Taschenrechner von TI der ein Assembler Programm hatte was ihn befähigte CAS zu können. Da hatte ich damals etwas dran rum optimiert. Ansonsten bin ich dabei mir c++ bei zu bringen. Daher bin ich für jede Hilfe natürlich sehr dankbar. Es gibt ja schon einen laaaangen Thread hier über die Heizungssteller "Rondostat" - also warum nicht auch über diesen Thermotronik. Wen es weiter interessiert - den Schaltplan für den Thermotronik gibts bereits hier im Forum. Danke für eure Hilfe fg Rocco
> Die .hex ist 45kB groß
das sieht mir mehr nach der gesamt größe des Flash aus, wieviel ist
davon belegt?
Poste mal das .hex file. Ich bin mir sicher, daß Du nur einen Dummy-Dump wegen gesetzter Lockbits aulesen konntest. Damit kannst Du nichts anfangen, das sind nur aufeinanderfolgende Zifferngruppen. >Es gibt ja schon einen laaaangen Thread hier über die Heizungssteller >"Rondostat" - also warum nicht auch über diesen Thermotronik. >Wen es weiter interessiert - den Schaltplan für den Thermotronik gibts >bereits hier im Forum. Kennste den: Beitrag "Preisgünstiger Heizungsregler bei Praktiker"
>Die .hex ist 45kB groß. Ob ich die jedoch hochladen sollte - da bin ich >mir nicht so sicher ob das in Ordnung geht - zumindest aus sicht des >Herstellers. Zu bedenken ist eine Veröffentlichung schon. Aber der Hersteller hätte ja den Chip gegen Auslesen schützen können! Also definiert er ihn als "öffentlich". Wie denkt ihr darüber? Ist sicher nicht nur für diesen Fall von Interesse. Übrigens, kann man den EEPROM auch auslesen? Da sind vielleicht Konstanten usw. abgelegt.
> Aber der Hersteller hätte > ja den Chip gegen Auslesen schützen können! > Also definiert er ihn als "öffentlich". Nööö, eine nicht abgeschlossene fremde Tür berechtigt mich noch lange nicht dazu, mich dahinter wie zu Hause zu benehmen. > Wie denkt ihr darüber? Wenn der MC nicht geschützt ist, dann lies ihn aus und ändere daran nach Herzenslust herum, vor einer Veröffentlichung solltest Du aber den Hersteller fragen. Das har jetzt nix mit Recht zu tun, sondern mit Anstand. Ich gehe aber davon aus, dass der Code geschützt ist und Du Blödsinn ausgelesen hast. ...
Hallo, so, habe den Thermotronic wieder an den USB ISP gehangen und nochmal nachgesehen. Folgende Lockbits sind gesetzt: LB Further Programming an Verification disabled BLB0 No Lock on SPM and LPM in Application Section BLB1 No Lock on SPM and LPM in Boot Section Lockbit 0xFC Da ich bisher nur mit den Fuses zu tun hatte weis ich nicht was die Lockbits bedeuten. Sicher weis das einer von Euch. Bei den Fuses ist es so: BODLEVEL Brown out Detecktion disabled Spien "hat ein Häckchen und ein Fragezeichen" BOOTSZ Boot flasch size = 1024 Words Start Adress = $1C00 CKDIV8 "hat ein Häckchen" SUT_CKSEL Int RC Osc.; Startuptime 6CK + 65 ms ^^Interesannt ist das an XTAL1 & 2 ein Uhrenquarz hängt. Wobei ich das mit dem Uhrenquarz eher vermute in der Anahme das alle Uhrenquarze dieses Zylinderförmige Gehäuse besitzen und man sie daran deutlich erkennt. Bitte berichtigt mich fals das totaler Humbug ist. Was des .hex angeht sehe ich es so wie Hannes Lux. Ich denke auch das sich der Hersteller von dem Thermotronik nicht gleich im Kreise dreht wenn ich im stillen Kämmerlein an seinem Gerät herumbastel - anders siht es sicher aus wenn ich den Quelltext einfach mal so offenbare. Ich möchte es deswegen mal so formulieren, wer Interesse hat mir das .hex zu erklähren kann sich gern bei mir per PN melden. Im gegebnteil - ich würde mich sogar sehr freuen wenn sich jemand meldet. Dazu einfach den blauen Link "kaufparkangucker" neben meinem Namen im Kopf dieses Antwortschreibens anklicken. Danke für das Verständniss. Eigentlich kann ich doch bei den Lockbits im AVR Studio wählen was ich da einstellen möchte und im Hinterkopf habe ich da irgend was mit einem Programmer der mit mehr volt - oder so was in der Richtung - auch die Lockbits wieder ändern konnte. Hat da einer einen Schaltplan oder einen Link für so einen Programmer? Ich weis leider nicht mehr wie das Zaubergrät hieß und weis somit gerade nicht wonach ich google fragen soll. Die ganzen Links hier im Forum habe ich übrigens schon gelesen. Einer davon war mehr als mfangreich. Aber leider gings da vorallem um den Honeywll Thermostaten. Hier mal ein Bild von meiner Platine (im Forum gefunden): http://img407.imageshack.us/img407/8021/thermotronicplatinekl2.jpg Und Der Schaltplan (auch hier im Forum gefunden) https://www.mikrocontroller.net/attachment/29357/schematic.png Danke für Eure Ideen fg Rocco
> Folgende Lockbits sind gesetzt: > LB Further Programming an Verification disabled > [...] Dieses Bit bekommst Du nur gelöscht, wenn Du den gesamten Chip löschst. Einzeln lässt es sich durch keine Programmierart rücksetzen. Zu deutsch: Vergiss den Flash-Dump. Du bekommst keinen, der den tatsächlichen Inhalt widerspiegelt.
Die .hex kannst du zB mit avr-objdump nach Assembler umwandeln:
1 | avr-objdump -m avr5 foo.hex -D -z > foo.disasm |
für den ATmega169 (ist Architektur avr5). Allerdiungs ist .hex ein "dummes" Format. Es weiß nicht, was und wo Code und wo Daten sind. Johann
Johann L. schrieb: > Die .hex kannst du zB mit avr-objdump nach Assembler umwandeln: > >
1 | > avr-objdump -m avr5 foo.hex -D -z > foo.disasm |
2 | > |
> > für den ATmega169 (ist Architektur avr5). > > Allerdiungs ist .hex ein "dummes" Format. Es weiß nicht, was und wo Code > und wo Daten sind. > > Johann Habe mir gerade mal eine Einleitung zu avr-objdump angesehen: http://www.rn-wissen.de/index.php/Assembler-Dump_erstellen_mit_avr-gcc Ich hatte ja schon gesagt das ich Anfänger bin - wenn ich das sehe weis ich das ich wohl noch für viele Jahre Anfänger bleibe - weil ich verstehe nur Bahnhof :-( Es will bstimmt auch keiner die.hex mal zum angucken haben oder? - mal abgesehen davon das ich es genau so sehe wie mizch und das .hex so eh nur unsinn enthält. Somit ist wohl löschen und selber ein Code erzeugen die einzige Möglichkeit. Das wird dann sicher ne gute Übung für mich. sollte ich evtl einen neuen Thred mit einem Titel wie "Heizungssteuerung mit dem Thermotronic" aufmachen? fg Rocco >>>>Ach so, noch eine Frage, wenn ich den Atmega lösche kann ich dann das ursprüngliche .hex einfach wieder aufspielen und alles ist so wie vorher?<<<<<<
> sollte ich evtl einen neuen Thred mit einem Titel wie "Heizungssteuerung > mit dem Thermotronic" aufmachen? noch nicht, fang erstmal mit "Wie bringe ich eine LED zum Blinken" an. > Es will bstimmt auch keiner die.hex mal zum angucken haben oder? eigentlich schon, stell doch mal die ersten paar zeilen hier rein, bloss um zu sehen ob es sinnvoll ist daran weiter zu arbeiten.
>>>>>Ach so, noch eine Frage, wenn ich den Atmega lösche kann ich dann das > ursprüngliche .hex einfach wieder aufspielen und alles ist so wie vorher?<<<<<< Da Du die originale .hex nicht hast (wegen des Lockbits), kannst Du auch nichts wieder draufspielen. Beginnen die Daten im .hex denn mit 0c94? Ein typischer Hex-File-Beginn für einen AVR dieser Größe sieht z.B. so aus:
1 | :100000000C9406030C9430030C9430030C94F50408 |
2 | :100010000C9430030C9430030C9430030C94300394 |
Die ersten 0c94 müssen praktisch immer vorhanden sein. (Man könnte theoretisch ohne Sprungvektoren auskommen aber das ist in Realität für größere Programme äußerst theoretisch bis seltsam.)
Mein letzes Projekt war ein Ziehrobotter der mit einer definierten Geschwindigkeit einen Objektträger aus einem Solgel zieht. Also ein LED bekomme ich schon zum Blinken ;-) Hier mal die ersten Zeilen aus dem Flashspeicher: :1000000000000303020203030404070706060707B0 :1000100008080B0B0A0A0B0B0C0C0F0F0E0E0F0F20 :100020001010131312121313141417171616171790 :1000300018181B1B1A1A1B1B1C1C1F1F1E1E1F1F00 :100040002020232322222323242427272626272770 :1000500028282B2B2A2A2B2B2C2C2F2F2E2E2F2FE0 :100060003030333332323333343437373636373750 und hier der Eeprom: :100000000003020304070607080B0A0B0C0F0E0F70 :100010001013121314171617181B1A1B1C1F1E1F60 :100020002023222324272627282B2A2B2C2F2E6F10 :100030003073327334373677787B3A7B3C7F7E7F00 :100040000003020304070607080B0A0B0C0F0E0F30 :100050001013121314171617181B1A1B1C1F1E1F20 :100060006063626364676667686B6A6B6C6F6E6F10
sieht nicht nach einem sinnvollen Programm aus => Kopierschutz
Wie kann man nur so einem Hexedezimalen Zeugs schlau werden?
> Wie kann man nur so einem Hexedezimalen Zeugs schlau werden?
wenn man mit ASM anfängt zu Programmieren, dann lernt man halt noch
jedes byte persönlich kennen. Bei den Atmel kommt als erstes eine
Tabelle mit Sprungmarken für die verschienden Interrupts und die sie
definitiv anders aus.
Wer den Intel-Hex noch nicht kennt, hier: http://de.wikipedia.org/wiki/Intel_HEX Ich komme am besten mit .bin aus. Vielleicht mal in umgewandelter Form hochladen. Und bitte als Datei, denn sonst muß man es ja zu Fuß machen und erst eintippen. Diese Zeit ist bei mir vorbei!
Michael_ schrieb: > Wer den Intel-Hex noch nicht kennt, hier: > http://de.wikipedia.org/wiki/Intel_HEX > Ich komme am besten mit .bin aus. > Vielleicht mal in umgewandelter Form hochladen. > Und bitte als Datei, denn sonst muß man es ja zu Fuß machen und erst > eintippen. > Diese Zeit ist bei mir vorbei! also die .hex in eine .bin konvertieren? Habe das zum ersten mal gemacht und hoffe das das so richtig ist. Habe in der Konsole: avr-objcopy -I ihex -O binary test.hex test.bin ausgeführt.
Rocco L. schrieb:
> Wie kann man nur so einem Hexedezimalen Zeugs schlau werden?
Das geht schon. Und aus dem hier:1 | > :1000000000000303020203030404070706060707B0 |
2 | > :1000100008080B0B0A0A0B0B0C0C0F0F0E0E0F0F20 |
3 | > :100020001010131312121313141417171616171790 |
kann man eindeutig sagen, dass das Müll ist. Im großen Ganzen kommt nichts als die Adresse zurück, mit ein wenig Übersprechen und Verschieben von einem Bit eines Bytes aufs nächste Bit. Das kannst Du getrost vergessen.
Hi Verstehe es doch mal, du hast aus dem Controller nichts sinnvolles ausgelesen. Und das wird als Bin-File auch nicht besser. Mit grosser Sicherheit sind die Security-Bits gesetzt. Denn dann kommt beim Auslesen solcher Müll heraus. MfG Spess
spess53 schrieb: > Hi > > Verstehe es doch mal, du hast aus dem Controller nichts sinnvolles > ausgelesen. Und das wird als Bin-File auch nicht besser. Mit grosser > Sicherheit sind die Security-Bits gesetzt. Denn dann kommt beim Auslesen > solcher Müll heraus. > > MfG Spess Hatte ich schon verstanden. Ich habe sogar schon angefangen ein neues Programm zu schreiben. Hatte ja nur auf Wunsch das .bin erstellt.
He, es geht doch nur um das Prinzip wie man sowas machen kann. Keiner hier wird den Moped-Chip umprogrammieren wollen.
Danke Michael. Über Deine Aussage freue ich mich schon - so kann man zumindest noch was lernen. Vieleicht studier ich ja mal "Reverse Engeneering" lol Letztlich wollte ich mir ja nur etwas Programmierarbeit ersparen indem ich das .hex auslese - nun weis ich zwar das es theoretisch geht - ich aber im speziallen nix mit anfangen kann - das ist eher eine Hilfe für Experten. So alle Pins habe ich schonmal definiert (#define PIN26 PD1). Ich frage mich wie die eine routine geschrieben haben die, wenn man das Thermostat zu ersten mal dran macht das Ventil rein und raus fährt und dabei testet wie weit das ventil überhaupt rein und raus geht. Kann man das so machen das man die Reflexlichtschranke am Motor überwacht und wenn Beispielsweise nicht aller 1 Sekunde ein signal ankommt man davon ausgeht das der Motor steht und somit das Ventil maximal ausgefahren bzw eingefahren ist? fg Rocco
>Ich frage mich wie die eine routine geschrieben haben die, wenn man das >Thermostat zu ersten mal dran macht das Ventil rein und raus fährt und >dabei testet wie weit das ventil überhaupt rein und raus geht. Die Reflexlichtschranke wird abgefragt und in Relation zu Leerlaufdrehzahl wird die Lastdrehzahl, die etwas niedriger ist, ausgewertert und daran der Ventilweg berechnet. Die oberen und unteren Anschläge werden zusätzlich durch Stillstand des Motors angezeigt. Die Abfrage sollte im Interesse eines langen Lebens der Batterien und des Motors deutlich schneller als 1 Sekunde betragen, eher 200ms zur Stillstandsdetektierung. Das Ganze muß allerdings immer dynamisch und relativ zur Leerlaufdrehzahl gemessen werden, da es Exemplarstreuungen gibt und mit abnehmender Batteriespannung alle Drehzahlen logischerweise auch kleiner werden. Ich nehme an, daß die wöchentliche Entkalkungsfahrt auch zum Neuabgleich der Drehzahlen genutzt wird.
Re-Assemblierung Ich bringe mal ein einfaches Beispiel für einen ATMEL, welcher auf einer PC-Hauptplatine war. Also nur zum üben der Re-Assemblierung. Übrigens der 90S1200 war der erste seiner Art, der UrUrgroßvater. Vielleicht kriegt jemand raus, was er gemacht hat.
Michael_ schrieb: > Vielleicht kriegt jemand raus, was er gemacht hat. Da bisher noch niemand einen Kommentar abgegeben hat, werde ich es jetzt tun, wenngleich meine Analyse des Codes sehr lückenhaft ist: Knapp die Hälfte des Programmcodes belegt eine I²C- bzw. SMBus-Slave- Schnittstelle in Software. PD2 ist dabei die Daten-, PD4 die Taktlei- tung. Die Kommunikation wird durch einen über die Datenleitung ausge- lösten Interrupt angestoßen. Die Busadresse lautet 0x19. Über die Schnittstelle kann lesend und schreibend auf die CPU-Register des Controllers zugegriffen werden. Das erste Datenbyte des I²C-Tele- gramms ist dabei die Registernummer, das zweite der Inhalt. Es ist sicher nicht vorgesehen, dass über den Bus auf jedes Register zuge- griffen wird, da einige der Register ja vom Programm selbst verwendet werden, so dass dies zur Fehlfunktion führen würde. Eines der Register (vielleicht sogar das einzige?), das zur Kommunkation genutzt wird, ist R29 und hat die Funktion eines Steuer-/Statusregisters, in dem jedes Bit (außer Bit 5) eine bestimmte Funktion hat. Der Rest der Software besteht aus eine zeit- und zustandsgesteuerten Lesezugriffen der Eingänge PD3, PD5 und PD6 und Schreibzugriffen auf die Ausgänge PB0 bis PB5. Eine Interpretation der Abläufe ist ohne Kenntnis der äußeren Beschaltung des Controllers schwierig. Es finden jedenfalls keine komplizierten Berechnungen statt, aus denen man auf die Funktionen der einzelnen Leitungen schließen könnte. Da sehr viel mit Verzögerungs- schleifen gearbeitet wird, die teilweise im Sekundenbereich liegen, hat das, womit interagiert wird, offensichtlich eine längere Reaktionszeit. Es wäre bspw. möglich, dass an die I/Os Taster und LEDs für die Inter- aktion mit dem PC-Benutzer angeschlossen sind. Die Software ist etwas pfuschig gemacht. So gibt es mindestens eine nicht erreichbare Codezeile, manches ist unnötig umständlich program- miert und einige Rechenergebnisse werden gar nicht weiterverwendet. Zusammen mit den vielen Delays und der Möglichkeit des unkontrollierten Zugriffs von außen auf die CPU-Register werden da komische Erinnerungen wach ... ... ich wage es ja kaum auszusprechen, aber ... Hat da, um den teuren Pentium auf dem PC-Mainboard einzusparen, womöglich jemand versucht, Windows auf den AVR zu portieren? =8-o PS: Was ist den das für ein Mainboard, auf dem du den AVR gefunden hast?
Zu spät, ist schon entsorgt. War aber ein ATX. Er war auf der rechten oberen Ecke. Mit schlampig programmiert wäre ich vorsichtig. In einer Hochsprache ist er nicht programmiert, da er keinen RAM hat und der Stack nur 2 Stufen hat. Mal sehen, ich schau ihn mir noch mal genauer an.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.