Forum: Compiler & IDEs ATmega16 .hex Code disassemblen Hilferuf


von Udo W. (einstein55)


Lesenswert?

Hallo,
ich bräuchte eine einmalige Hilfe um einen hex Code in der 
Arduino-Umgebung, also als Sketch lesen zu können.

ich möchte aber nicht das komplette Assembling und so lernen, da ich es 
wirklich nur für zwei .hex Dateien mit ca 100 Zeilen, die mir zwar zur 
Verfügung stehen.
Dort ich gerne zwei Umrechnungsfaktoren ändern bei Bedarf.

Hier mal Zeile 11-13 von 100 zur Anschauung was mir leider unleserlich 
zur Verfügung steht.

Code:
:1000A00015BA97E392BB9FE19ABB87BB8CE384BBF5
:1000B00080E381BB84E083BF82E88FBD88E18EBD91
:1000C00080EE91E09BBD8ABD80E483BD87E989BF56

wenn mir jemand den Gesamtcode wieder zum lesen aufbereiten könnte?

Vielen Dank im voraus
Einstein55

von g457 (Gast)


Lesenswert?

> ich bräuchte eine einmalige Hilfe um einen hex Code in der
> Arduino-Umgebung, also als Sketch lesen zu können.

Einfach den Quellcode laden und feddisch.

> ich möchte aber nicht das komplette Assembling und so lernen

Brauchst Du auch nicht, das macht die Toolchain für Dich. Was Du 
augenscheinlich machen willst ist Disassemblieren. Spar Dir die Arbeit 
und such den Quellcode, das ist weniger Aufwand.

> wenn mir jemand den Gesamtcode wieder zum lesen aufbereiten könnte?

Was wäre dann?

von Udo W. (einstein55)


Lesenswert?

Hallo g457

Quellcode wäre super....
der ist leider seit 2013 in den ewigen Festplattengründen.

Einstein55

von Karl M. (Gast)


Angehängte Dateien:

Lesenswert?

Guten morgen,

die Darstellung nennt man Intel-Hex-Format
# https://de.wikipedia.org/wiki/Intel_HEX

Hinter dieser Darstellung verbergen sich die Binärdaten eines 
Assemblerprogramms. Das wiederum aus einer Hochsprache erzeugt wurde.

Man kann das Intel-Hex-Format in Binärdaten umwandeln und dann mit einem 
Disassembler die Assembler Memnomics ansehen.

Ich verwende dazu den Disassembler von LunaAVR.

Mehr kann man nicht erwarten.

von Disassembler (Gast)


Lesenswert?

Ich fürchte das wird nicht ohne etwas höhere Kosten ablaufen, wenn sich 
hier nicht ein Nerd findet, der das zum Spass macht.

Jedenfalls müsste man mal vorher wissen, welche Informationen Du 
insgesamt überhaupt vorliegen hast, damit man abschätzen kann, ob 
überhaupt eine Chance besteht eine Konstante im Code zu identifizieren.

Das man Dir den Sketch wieder herstellt ist eher illusorisch. Allenfalls 
einen Sketch, der genau diesen Assemblercode enthält.

von hp-freund (Gast)


Lesenswert?

Um nichts installieren zu müssen:

https://onlinedisassembler.com/odaweb/

Dort kannst Du deine Datei hochladen, oder auch hier anhängen damit 
vielleicht noch andere mit spielen können.

von Udo W. (einstein55)


Lesenswert?

Danke allen,

das killt jetzt zwar meine Euphorie, etwas schneller zu erledigen, aber 
dann muss ich den Sketch eben neu schreiben.
Ist ja nur eine Steppermotorregelung für einen Motor mit 
Anpassungsfaktor für Durchmesser zu Geschwindigkeitsanzeige.

Und den Atmega16 wollte ich eigentlich schon lange gegen einen UNO 
austauschen.

Einstein55

von pegel (Gast)


Lesenswert?


von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

An den "Sketch", also den C++-Quellcode kommt man damit genauso gut 
wieder heran, wie man aus einem Batzen Hackfleisch die zugehörige Kuh 
rekonstruieren kann.

Man kann das allenfalls in Assembler-Quelltext übersetzen, dem aber alle 
symbolischen Bezeichner fehlen, d.h. Variablennamen, Funktionsnamen etc. 
sind verloren und durch automatisch generierte Bezeichner ersetzt. 
Kommentare gibts natürlich auch keine, und Datentabellen im Code sind 
oft nicht als solche erkennbar.

Das kommt auf die Qualität des verwendeten Disassemblers an, es gibt 
welche, die eine statische Codeanalyse vornehmen, und anhand dessen so 
etwas besser erraten können. Ein Beispiel dafür ist IDA, allerdings weiß 
ich gerade nicht, ob das AVRs kennt.

von Bernd K. (prof7bit)


Lesenswert?

Rufus Τ. F. schrieb:
> Ein Beispiel dafür ist IDA, allerdings weiß
> ich gerade nicht, ob das AVRs kennt.

Kann es: https://www.hex-rays.com/products/ida/processors.shtml

von Norbert (Gast)


Lesenswert?

Udo W. schrieb:
>
> Quellcode wäre super....
> der ist leider seit 2013 in den ewigen Festplattengründen.
>

Das ist doch gar kein Problem,
einfach auf die Datensicherung zugreifen und fertig!

von Yalu X. (yalu) (Moderator)


Lesenswert?

Udo W. schrieb:
> Ist ja nur eine Steppermotorregelung für einen Motor mit
> Anpassungsfaktor für Durchmesser zu Geschwindigkeitsanzeige.

Weißt du noch, wie der Parameter im Originalcode definiert war?

Am einfachsten wäre es, wenn er aus dem EEPROM gelesen würde. Dann
müsstest du die Firmware nicht einmal anfassen, sondern einfach nur die
entsprechenden Bytes im EEPROM überschreiben.

Falls der Parameter als globale Variable definiert wurde, stehen die
Chancen immer noch ganz gut, den Wert im Disassembly zu finden und zu
ändern, zumindest dann wenn man die Funktionsweise und den Ablauf des
Programms noch einigermaßen im Kopf hat.

Meist werden solche Dinge aber per #define definiert. Wenn der Parameter
in arithmetischen Ausdrücken (womöglich sogar in mehreren) verwendet
wird, die vom Compiler bis zur Unkenntlichkeit optimiert worden sind,
wird es schon sehr schwierig, die zu patchende Stelle zu lokalisieren.

Aber damit nicht genug:

Wenn bspw. der ursprüngliche Parameter zufälligerweise eine Zweierpotenz
war, für die der Compiler Multiplikationen zu Shift-Operationen
optimiert hat, muss man diese nun evtl. durch eine echte Multiplikation
ersetzen, d.h. selber ein paar Zeilen Assemblercode schreiben. Dabei
muss man natürlich darauf achten, dass man nicht versehentlich ein noch
anderweitig genutztes Register überschreibt. Und und und ...

Da hast du das Programm sicher schneller neu geschrieben.

Versuch es positiv zu sehen: Ein Programm, das man ein zweites Mal
schreibt, wird meistens sehr viel besser (effizienter, weniger Fehler
usw.).

von Udo W. (einstein55)


Lesenswert?

Yalu X. schrieb:
> Da hast du das Programm sicher schneller neu geschrieben.
>
> Versuch es positiv zu sehen: Ein Programm, das man ein zweites Mal
> schreibt, wird meistens sehr viel besser (effizienter, weniger Fehler
> usw.).

Richtig,

Ich habe jetzt den Parameter gleich mal zusätzlich einstellbar gemacht, 
um nicht bei Abweichungen jedesmal den Sketch ändern zu müssen.
Die Beschichtungen der Rollen nutzen sich ja auch ab und das hatte doch 
schon Längenmessprobleme gegeben.

Danke nochmal
Einstein55

von c-hater (Gast)


Lesenswert?

Yalu X. schrieb:

> Versuch es positiv zu sehen: Ein Programm, das man ein zweites Mal
> schreibt, wird meistens sehr viel besser (effizienter, weniger Fehler
> usw.).

Dieser Aussage würde ich mich fast vollständig anschliessen wollen. 
Klar, bei einer Re-Implementierung wählt man in aller Regel ein besseres 
Konzept zur Umsetzung der Problemstellung und dies sorgt dann dafür, 
dass der Kram am Ende auch effizienter wird.

Aber was die Fehler betrifft, bin ich der Meinung, dass eine 
Re-Implementierung zwar recht zuverlässig alle alten Fehler entsorgt, 
aber dafür auch reichlich Gelegenheit gibt, ungefähr genau so viele neue 
einzubauen...

Man findet sie Dank des besseren Programmkonzepts nur schneller. Allein 
deswegen kommt es einem so vor, als wären es in der neuen Variante des 
Codes deutlich weniger gewesen. Eine objektive Analyse zeigt allerdings 
i.d.R. ziemlich gnadenlos, dass das NICHT der Fall war. Über den 
Daumen gepeilt kann man wohl sagen: Im Mittel waren wieder genauso viele 
Fehler drin wie in der ursprünglichen Variante.

von m.n. (Gast)


Lesenswert?

c-hater schrieb:
> Über den
> Daumen gepeilt kann man wohl sagen: Im Mittel waren wieder genauso viele
> Fehler drin wie in der ursprünglichen Variante.

Ist das Deine Selbstkritik an Deiner Programmierweise?
Mit dem Problem des TO hat das doch überhaupt nichts zu tun, es sei 
denn, Du kennst das ursprüngliche und das aktuelle Programm.

von Dr. Sommer (Gast)


Lesenswert?

c-hater schrieb:
> bei einer Re-Implementierung wählt man in aller Regel ein besseres
> Konzept zur Umsetzung der Problemstellung und dies sorgt dann dafür,
> dass der Kram am Ende auch effizienter wird.
Da haben andere Leute andere Erfahrungen gemacht:
http://wiki.c2.com/?SecondSystemEffect

"* The first time you use a new technology or build a new type of 
system, you know that you're a beginner, so you tend to be naturally 
conservative.
* The second time around, you have experience. You know what you're 
doing. You have success under your belt, so you pull out all the stops 
and do all the things you are afraid to do the first time around.

If your project is the second system for most of your designers, then it 
will probably fail outright. If it doesn't fail, it will be bloated, 
inefficient, and icky."

von Bernd K. (prof7bit)


Lesenswert?

Dr. Sommer schrieb:
> c-hater schrieb:
>> bei einer Re-Implementierung wählt man in aller Regel ein besseres
>> Konzept zur Umsetzung der Problemstellung und dies sorgt dann dafür,
>> dass der Kram am Ende auch effizienter wird.
> Da haben andere Leute andere Erfahrungen gemacht:
> http://wiki.c2.com/?SecondSystemEffect

Das scheint mir eine Fehlinterpretation zu sein. Bei Wikipedia zum 
Beispiel wird das schon wieder ganz anders verstanden:

"The second-system effect (also known as second-system syndrome) is the 
tendency of small, elegant, and successful systems to be plagued with 
feature creep due to inflated expectations.[1]

The phrase was first used by Fred Brooks in his book The Mythical 
Man-Month.[2] It described the jump from a set of simple operating 
systems on the IBM 700/7000 series to OS/360 on the 360 series."

Außerdem halte ich dieses sogenannte "Syndrom" oder die Tatsache daß es 
formuliert wurde für eine Manifestation eines ganz anderen Syndroms, 
nämlich des "Von-Sich-Selbst-Auf-Die-Allgemeinheit-Schließen-Syndrom".

Denn für jedes "zweite System" das schlechter ist als das vorherige kann 
man wahrscheinlich mindestens drei andere nennen bei denen es genau 
umgekehrt war. Und mindestens ebensoviele bei denen erst die dritte oder 
vierte Version schlecht wurde. Oder die fünfte. Oder schon die erste 
floppte jedoch aber die zweite hervorragend funktionierte. Oder die 
Dritte.

Dieses sogenannte "Syndrom" ist IMHO ausgemachter Schwachsinn. Er hat 
viel zu wenig Stichproben genommen bevor er so eine allgemeingültige 
Regel hätte formulieren können, es ist vollkommen übergeneralisiert und 
nicht geeignet den Ausgang von irgendwas anderem vorherzusagen. Man muss 
wirklich nicht jeden Spruch der Fred Brooks mal in der Verbitterung über 
irgend ein in den Sand gesetztes Projekt seiner eigenen(!) Abteilung 
rausgerutscht ist in Stein meißeln und verehren als wäre Brooks ein Gott 
oder ein Prophet.

Ich mach jetzt auch mal eine Vorhersage:
   Die zweite Version wird meistens besser 

Könnt ihr ebenso in Stein meißeln und daneben stellen.

: Bearbeitet durch User
von Udo W. (einstein55)


Lesenswert?

Ich kenne das ganz anders:

Das erste Haus baue für Deinen Feind,
Das zweite Haus für Deinen Freund,
Das Dritte für Dich selbst.

: Bearbeitet durch User
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
Noch kein Account? Hier anmelden.