Hallo,
Gerade habe ich eines meiner Programme Disassembliert mit dem
'objdump' (gnu) und mir fiel etwas auf was fuer mich nicht
nachvollziehbar ist:

Die Adressen fuer Daten oder Sprungziele entsprechen nicht dem
offset der Ausfuehrbaren Datei.

Beispiel:
40101f: 6a 40 push $0x40
401021: 68 00 20 40 00 push $0x402000
401026: 68 1c 20 40 00 push $0x40201c
40102b: 6a 00 push $0x0
40102d: e8 0e 00 00 00 call 401040 <_MessageBoxA@16>

Zu beachten sind '$0x402000' und '$0x40201c' aus Zeile 2 und 3 aus
meinem Beispiel. Das was ich daran nicht verstehe ist dass die daten
auf die diese Adressen zeigen eigentlich an der Position 0x600 bzw.
0x61c in der Datei anzutreffen sind.
Ausserdem beginnt der Programmcode des Beispiels sich nicht an der
Position 0x40101f, sondern beginnt bei 0x41f.

Es liegt also auf der Hand dass es sich hierbei nicht um die Positionen
der Daten in der Datei handelt, sondern um etwas anderes.

Ist vllt. jemand in der lage mir zu erklaeren was diese Adressen zu
bedeute haben und wie sie sich nachvollziehen lassen?

lg, Manuel

--
Wer den Kopf in den Sand steckt, darf sich nicht wundern
wenn er in den Hintern getreten wird.

Manuel Ems schrieb:
> [...]
> Gerade habe ich eines meiner Programme Disassembliert mit dem
> 'objdump' (gnu) und mir fiel etwas auf was fuer mich nicht
> nachvollziehbar ist:
>
> Die Adressen fuer Daten oder Sprungziele entsprechen nicht dem
> offset der Ausfuehrbaren Datei.

Diese Entsprechung gibt es selbst bei den einfachsten Executable-
Formaten nicht. COM-Programme unter DOS werden z.B. an den Offset
256 geladen, d.h. man muss alle Adressangaben innerhalb der Datei
um den Wert korrigieren.

> [...]
> Ist vllt. jemand in der lage mir zu erklaeren was diese Adressen zu
> bedeute haben und wie sie sich nachvollziehen lassen?

Auf modernen Systemen wie Linux werden die einzelnen Segmente eines
Programms (so wie die aller beteiligten Shared Libraries) per mmap(2)
an virtuelle Adressen eingeblendet.

http://www.muppetlabs.com/~breadbox/software/ELF.txt

--
Ich kenne die Mißverständnisse-FAQ, und sie wird oft mißverstanden.
-- Andreas M. Kirchwitz <slrne144uq.gdg.amk@krell.zikzak.de>

Manuel Ems wrote:

>Ist vllt. jemand in der lage mir zu erklaeren was diese Adressen zu
>bedeute haben und wie sie sich nachvollziehen lassen?

Die Position des Codes in der Datei hat so gut wie nichts mit der
späteren Position im Speicher zu tun.

Wo am Ende was landet, regelt der Loader. Dazu benutzt er die
Informationen, die im Executable stecken. Wenn du Details wissen willst,
mußt du dich also mit den Details des Exe-Formats beschäftigen.

Im übrigen muß der Loader sich nichtmal sklavisch an die Vorgaben aus
dem Executable halten. Er kann nämlich auch Codeblöcke an eine andere
Position laden als ursprünglich vorgesehen. Dann muß er allerdings auch
noch nachträglich sämtliche betroffenen Adreßbezüge anpassen. Das nennt
man relozieren. Auch das kann er unter Verwendung der Informationen aus
der Exe-Datei.

Tja, und letztlich handelt es sich bei den Adressen natürlich um
virtuelle Adressen. D.h. sie haben rein garnichts mit der Position im
physikalisch vorhandene Speicher zu schaffen.

Alexander Bartolich <alexander.bartolich@gmx.at> wrote:
> Diese Entsprechung gibt es selbst bei den einfachsten Executable-
> Formaten nicht. COM-Programme unter DOS werden z.B. an den Offset
> 256 geladen, d.h. man muss alle Adressangaben innerhalb der Datei
> um den Wert korrigieren.

Ja, das ist mir bekannt, Dos-Assemblercodes beginnen ueblicherweise
mit 'org 0x100'.

Habe im msdn gefunden was ich suchte. Danke fuer den Tipp, auch an
Heiko N.

lg, Manuel

--
Wer den Kopf in den Sand steckt, darf sich nicht wundern
wenn er in den Hintern getreten wird.