AVR (hex) reverse engineering (radare2)

[D a v i d K. (oekel)]

Hi,

hat von euch jemand Ahnung von radare2 und ob ich damit eine hex 
einigermaßen lesbar machen kann?

Letzendlich ist es mein eigener Code, doch mir ist die Versionierung 
abgeraucht und die aktuelle Implementierung läuft an einer Stelle noch 
nicht so rund, wie sie es einmal war (Atmega88 PWM über timer1).

Ja vermutlich werden nun wieder einige aufschreien und sagen, das 
Projekt kennen wir doch bereits, aber ich sehe den Fehler einfach nicht.

Grüße David

PS: Ich kann kein ASM

[Kalle (Gast)]

D a v i d K. schrieb:
> PS: Ich kann kein ASM

Dann hast du sowieso schon verloren. Der einfachste Weg wäre es, sich 
den Assemblercode mit gcc-objdump ausgeben zu lassen (vllt sind ja 
Symbole in der elf) und dann die entsprechende Funktion zu untersuchen, 
die paar Assemblerbefehle kannst du ja auf google nachschauen.

[Tim T. (tim_taylor)]

Stell mal das Hex und deinen C(?) Code hier ein.

[K. S. (the_yrr)]

D a v i d K. schrieb:
> Ja vermutlich werden nun wieder einige aufschreien und sagen, das
> Projekt kennen wir doch bereits, aber ich sehe den Fehler einfach nicht.

Stell mal den Code rein, da können die komischten Dinge Probleme 
verursachen. eventuell fällt ja jemandem hier was auf. gerade bei 
Timern/PWM kann es Probleme mit aktualisierung der Register geben, wenn 
du nicht alles beachtest.

z.b. hatte ich auf einem tiny zwischen CTC und PWM umgeschaltet (was das 
OCR register zwischen buffered/direct access umschaltet), was bei 
falscher Reihenfolge der Initialisierungen dazu führte dass der Code 
nach 1 1/2 Durchläufen hängeblieb, aber nur wenn OCR zu einer bestimmten 
Zeit unter 26 war.

[Markus (Gast)]

Du kannst mit avr-objcopy das hex file in eine elf file konvertieren und 
dieses dann in radare2 öffnen. radare2 wird dir den Assemblercode 
anzeigen, aber dazu z.B. die Sprungmarken/-Pfeile und es kann nach 
versuchen Funktionen zu erkennen (wird angesprungen und endet mit ret). 
Namen von den Symbolen bekommst du so natürlich nicht, die sind beim 
Übergang elf->hex weggefallen.

[Tim T. (tim_taylor)]

Alternativ kann man sich mit avr-objdump auch schon das disassemblierte 
Programm anschauen und braucht nicht mal radare dafür (obwohl es 
komfortabler ist).

avr-objdump.exe -j .sec1 -d -m avr5 input.hex > output.dasm


Den Namen der Section (.sec1) kann man bei Bedarf mit avr-objdump.exe -h 
input.hex ermitteln (war bei mir aber immer .sec1, warum auch immer).

[D a v i d K. (oekel)]

Git sei dank, habe ich mir die "noch lauffähige" version querry-picken 
können :)

Trotzdem würde den wissenhungrigen Part in mir interessieren, wie ich 
nach dem compilieren bestimmte Werte im Hex wiederfinde.

Kann ich gewisse Dinge beim programmieren ändern, damit es leichter 
wird?
(Vermutlich compilerflag komprimiere=0?)

[Rufus Τ. F. (rufus)]

D a v i d K. schrieb:
> Kann ich gewisse Dinge beim programmieren ändern, damit es leichter
> wird?

Ja, Optimierung abschalten. Dann entspricht das Assemblat eher Deinem 
Programm.

[Mathias M. (matjes)]

Ich würde mir auch mal Ghidra angucken. Das ist ein von der NSA 
entwickeltes Reverse engineering Tool vergleichbar mit IDA Pro. Das 
kommt auch mit decompiler für zig Prozessorarchitekturen und ist damit 
deutlich einfacher verwendbar für Leute, die nicht so ASM affin sind. 
Klar ist reverse engineering immer noch Arbeit, aber für mich klar 
einfacher, wenn ich mir nicht alle ASM compare und Jump Befehle merken 
muss.

Radare hat zwar auch nen decompiler, aber ich bin insgesamt nie mit 
Radare warm geworden.

[Ralf C. (Gast)]

Rufus Τ. F. schrieb:
> D a v i d K. schrieb:
>> Kann ich gewisse Dinge beim programmieren ändern, damit es leichter
>> wird?
>
> Ja, Optimierung abschalten. Dann entspricht das Assemblat eher Deinem
> Programm.

Würde ich nicht machen. Optimiertes Assemblat ist viel lesbarer als 
unoptimiertes.
Das gilt meistens auch für C vs. Assembler: Wer sich schon mal den glibc 
C-Code angeschaut hat und mit dem Asm verglichen hat, wird den Asm 
bevorzugen (mit Optimierungen)

[Rufus Τ. F. (rufus)]

Ralf C. schrieb:
> Würde ich nicht machen. Optimiertes Assemblat ist viel lesbarer als
> unoptimiertes.

Wenn man das Assemblat ohne Bezug zum C-Quellcode lesen will, 
vielleicht. Möchte man aber die Zusammenhänge erkennen, eher nicht.