Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   [asm]JMP bei Delphi-Inline-Assemlber (https://www.delphipraxis.net/72631-%5Basm%5Djmp-bei-delphi-inline-assemlber.html)

himitsu 4. Jul 2006 13:40

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
Zitat:

Zitat von Flocke
Der Opcode für einen direkten unbedingten Sprung ist $E9

nö, dat is der Opcode für einen direkten short jump oder wie dat nochmal hieß.
Also einen sozusagen ein relativer Sprung, von der Stelle aus, wo er steht.

Den Opcode für einen absoluten Sprung hab ich auch gerade nicht im Kopf ... könnte höchstens mal heut abend nachseh ^^


Zitat:

Zitat von SirThornberry
Desweiteren bin ich davon ausgegangen das "ptr" angibt das es sich um einen Pointer handelt.

im Grunde gibt das PTR (Pointer) ja auch an, daß es sich um einen solchen handelt, aber dieses muß nicht immer angegeben werden, wenn klar ist, worum es sich handelt.

Es ist so ähnlich wie mit Flocke's Code...
Delphi-Quellcode:
mov eax, $11223344
jmp eax
so ginge es ja auch
Delphi-Quellcode:
mov eax, dword $11223344
jmp eax
da [] eh auf 'nen Pointer hinweißt, ist es also nicht nötig ... genauso wie das dword, da im Win32 doch eh alles erstmal als LongInt/LongWord/32-Bit-Pointer angesehn wird.
Delphi-Quellcode:
// das ist also dat "Selbe"
mov eax, dword ptr [$11223344]
mov eax, ptr [$11223344]
mov eax, [$11223344]

// wohingegen das mal was Anderes ist ^^
mov eax, byte ptr [$11223344]
Zitat:

Zitat von SirThornberry
@Flocke: Bei E9 wird die Differenz angegeben? Das heißt man nimmt keinen "dword" mehr sondern einen Integer? Ist dabei sichergestellt das der Wertebereich des Integers auch groß genug ist?

Na ja, es gibt verschiedene Varianten ... also mit auch solche mitr ShortInt und SmallInt.
Ist praktischer, weil die ja weniger Speicher verbrauchen, man kann damit allerdings nicht so weit springen ... was aber och klar sein sollte ^^


Zitat:

Zitat von SirThornberry
Ich bin in asm nicht so bewandert. Delphi hat immer rumgemeckert wenn ich die "[]" vergessen hab.

Wie gesagt ... syntaktisch würde es stimmen, aber wie Nico schon sagte will der Delphi-ASM sowas nicht. :zwinker:
Also ich kann höchstens dann nochmal nachgucken was der richtig Opcode hierfür wäre oder du nimmst den indirekten Weg :roll:


Aber was ich mich bisher immer grfragt hab ... woher will eigentlich Windows wissen was ein Pointer ist und ob der eventuell gefixt werden muß?
Weil oftmals ist es ja nicht gerade eindeutig, was einer ist, oder ob der schon gefixt wurde.

z.B.
Delphi-Quellcode:
JMP EAX
Windows kann doch shcließlich nicht wissen was das für ein Wert in EAX ist :gruebel:

SirThornberry 4. Jul 2006 13:45

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
über das Fixen von Windows hab ich mir bisher gar keine Gedanken gemacht. Aber so wie du das schreibst würds mich auch interessieren woher windows weiß was gefixt werden muss und was nicht. Wobei Windows das früh oder Später ja ausführt und von daher schon wissen sollte was durch die Befehle passiert.

himitsu 4. Jul 2006 13:53

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
aso
Zitat:

Zitat von SirThornberry
benötigt hab ich das ganze für folgendes:
http://www.delphipraxis.net/internal...=573675#573675

OK, an dieser Stelle wäre natürlich der direkte Sprung nicht schlecht ^^
Obwohl du dort natürlich auch relativ springen könntest

Code:
JMP (neueFunktion - aktuellePosition)
also in etwa:
Delphi-Quellcode:
lBuffer : Array[0..4] of Byte;
...
PByte(@lBuffer)^ := $e9;
PCardinal(@lBuffer[1])^ := Cardinal(ANewFunction) - Cardinal(AOldFunction);
PS: wenn du es schon so aufschlüsselt, dann wäre es so wohl "richtiger" ;)
Delphi-Quellcode:
lBuffer : Array[0..(2 + 4 + 4) - 1] of Byte;

himitsu 4. Jul 2006 14:01

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
[ä bissl OT]
Zitat:

Zitat von SirThornberry
Wobei Windows das früh oder Später ja ausführt und von daher schon wissen sollte was durch die Befehle passiert.

gerade da ligt ja z.B. eines der Probleme ... es kann es eben nicht wissen.
wenn ich z.B. irgendwo im Quellcode einer Variable einen hardcodierten Wert übergeben, welcher z.B. die Position einer Funktion ist,
Delphi-Quellcode:
Variable := @Funktion;
(wenn funktion eine eigene Funktion im eigenem Programm ist, dann wird der Wert ja vom Compiler hardgecodet)

dort vielleicht noch ein bissl rumrechne
Delphi-Quellcode:
Variable := Variable + irgendwas;
und dann wohinspringen will,
Delphi-Quellcode:
JMP &Variable
dann muß hier gefixt werden, wenn die der Programmcode nicht an seiner vorgesehenen Position ist.

Wenn ich das ganze aber mit aktuellen Werten aus dem laufenden Programm mache, dann sind die Positionen ja schon gefixt (da dort die verwendete Funktion schließlich bereits verschoben wurde) und müssen demnach ja nichtmehr gefixt werden. o.O

SirThornberry 4. Jul 2006 14:18

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
@Himitus: das "JMP &Variable" muss eignetlich nicht gefixt werden da der Inhalt der Variablen bereits vorher gefixt wird. Der Inhalt von "Variable" ergibt sich ja aus anderen Adressen und diese sind bereits gefixt.

brechi 4. Jul 2006 14:36

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
es gibt keinen assembler befehl für einen 'absoluten' jump so wie du ihn suchst.

entweder

Delphi-Quellcode:
mov eax, addr
jmp eax
oder

Delphi-Quellcode:
push addr
ret
nehmen oder den Umweg über eine globale/lokale variable machem.

Delphi-Quellcode:
jmp [variable]
und 0xE9 ist kein relative short distance jump, das wäre 0xEB

und wenn du die einen relativen jump brauchst, die berechnung wäre zieladresse-vonadresse-5

Boombuler 4. Jul 2006 15:00

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
PS: http://faydoc.tripod.com/cpu/jmp.htm
Merke: Der Link ist natürlich nur für x86

Wenn ich das nu Spontan Richtig sehe wäre also ein FF ein direkter Jump auf die Addy!

(Nich hauen wenns falsch ist ;) )

Greetz
Boombuler

SirThornberry 4. Jul 2006 16:34

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
ich habs jetzt erstmal mit dem ablegen auf dem Stack, und dann mit "ret" zur Adresse "zurück" springen gemacht. Das spaart im Gegensatz zu meiner Ursprünglichen Variante schon ganze 4 Byte.
Den Link werd ich mir gleich mit ansehen.

[Edit]
Ein reines FF reicht nicht aus. Und sobald 1 Byte mehr dazu kommt bin ich wieder bei der gleichen Anzahl wie bei der Variante mit push + ret

Die Variante mit push + ret sieht so aus
$68$33$22$11$00
$C3
[/Edit]

himitsu 4. Jul 2006 16:39

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
Delphi-Quellcode:
Variable := @Funktion;
entspricht
Delphi-Quellcode:
MOV &Variable, $00123456
hier kann nichts von windows gefixt werden, denn für Windows ist es nur eine "normale" Zahl, welche in irgendeinen peicherbereich kopiert wird ... und da es nicht wissen kann, daß es eigentlich ein Pointer ist, kann es dort definitiv nicht fixen und später fixen ginge och nicht, da dort Windows eigentlich nicht wissen kann, ob gefixt werden muß, oder nicht, da es ja nicht weiß was für ein Wert in der Variable drinsteht, also ob das schon ein gefixter ist, oder eben noch ein ungefixter (aus 'nem hardgecodeten Pointer).

denn wenn ich sowas mache, dann würde ja ein "gefixter" Wert in die Variable geschrieben, da ja die Adresse der bereits verschobenen Prozedur zurückgegeben wird.
Delphi-Quellcode:
Variable := GetProcAddr('irgendwas');
also liebe als letztes nur noch der Jump-Befehl, wo windows fixen könnte, aber da es ja nicht weiß was in Variable für ein Wert ist ... woher soll es denn dann wissen, was es machen soll?
Delphi-Quellcode:
JMP &Variable

brechi 4. Jul 2006 16:58

Re: [asm]JMP bei Delphi-Inline-Assemlber
 
Delphi-Quellcode:
Variable := @Funktion;
in dem Fall weiß der Compiler, dass er einen Eintrag in die Relocation Table packen muss

Delphi-Quellcode:
MOV &Variable, $00123456
in dem Fall nicht. Wer auch immer nu Recht hat, wollte das nur noch mal sagen.


Alle Zeitangaben in WEZ +1. Es ist jetzt 15:06 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz