Assembler Offset in Hex

[Rebell]

Hallo.

Da ich mich ja grad mit Debugging beschäftige, habe ich einen symbolischen Debugger gefunden. Das Ding nennt sich Debuggy.

Jetzt habe ich aber ein Verständnisproblem. Die Assembler-Aufrufe innerhalb des Programnmes befinden sich an Offset-Positionen, die ich mit einem einfachen Hex-Editor nicht anspringen kann. Muss man diese irgendwie umrechnen?

Beispiel:

4012E7 CALL 408040

Dann kann ich mit dem Offset 4012E7 nichts anfangen, da es innerhalb der Datei außer Reichweite ist. Anfangs dachte ich, das wäre die Position im Speicher, aber ich habe mir dann mal auf Empfehlung das Programm Hview besorgt, das Ding ist zwar nur ne Demo, zeigt aber genau die gleichen Offsets an wie der Deasm. Also kann ich manuell zur Adresse 4012E7 springen, sehe dort auch meine Anweisung, allerdings klappt der Sprung mittels Offset nicht -> Jump out of file.

Daher meine Fragen: Woran liegt es, dass die Offsets in Hex-Editor und Deassembler unterschiedlich sind, und kann man die umrechnen?

Danke für die Antworten.

[quinte17]

werden so nciht auch funktionen addressiert?
so weit ich weiß, bekommen funktionen ja acuh eine gewisse adresse.. (sonst würde c++ mit überlagerung nicht funktionieren)

greetz

[Firebird]

@quinte17
wenn in maschinencode eine funktion aufgerufen wird dann passiert dass indem an die speicheradresse gesprungen wird wo der code der funktion steht. Und genau das is hier auch der fall.....

Daher meine Fragen: Woran liegt es, dass die Offsets in Hex-Editor und Deassembler unterschiedlich sind, und kann man die umrechnen?

@Rebell
ich weiß weder wie dein hexeditor funktioniert, noch wie dein deassambler funktioniert, aber sofern deine CPU little-endian byte-order benutzt (wie z.b. pentium.... naja eigentlich alle geläufigen pcs) wirst du im Hex-Editor statt einer Adresse A0B0C0 die Adresse C0B0A0 finden. genauso wie auch bei allen zahlen, und soweit ich weiß auch bei befehlen die mehr als ein byte einnehmen. sieht allerdings nicht so aus als ob das in diesem fall viel bringt....