einer variable eine adresse zuweisen

[Chewie]

Zitat von c113plpbr:

Und absolute funktioniert nur bei variablen, die in meinem Quellcode deklariert wurden, und nicht für diese zu denen ich nur einen pointer habe (bzw. eine statische adresse). Ansonsten wäre es perfekt.

Wenn die Adresse statisch & schon zur Laufzeit bekannt ist, dann geht das auch via absolute.

[c113plpbr]

Zitat von Chewie:

Wenn die Adresse statisch & schon zur Laufzeit bekannt ist, dann geht das auch via absolute.

So? Dann sag mal wie ... beide zeilen verursachen den selben fehler:

Delphi-Quellcode:

var
  a : DWORD absolute $01005B24;
  b : DWORD absolute pointer($01005B24);

Compilerausgabe:

[Error] hook.dpr(14): E2088 Variable name expected

ciao, Philipp

[tommie-lie]

Wenn du die Adresse kennst, warum nimmst du dann nicht einen Pointer? Angenommen du willst einen Pointer aus Adresse 12345678 haben, geht das z.B. so:

Delphi-Quellcode:

var
  meineZahl: Integer;
begin
  // die Zahl holen
  meineZahl := PInteger(12345678)^;

  // irgendwas damit machen

  // und zurückschreiben geht auch
  PInteger(12345678)^ := meineZahl;
end;

Da du aber sagtest, daß es nicht in deinem Quellcode ist, schwant mir fürchterliches... Es soll dir gesagt sein, daß du unter WindowsNT nicht ohne weiteres an Speicherbereiche von anderen Prozessen rankommst.

[c113plpbr]

Zitat von tommie-lie:

Wenn du die Adresse kennst, warum nimmst du dann nicht einen Pointer? Angenommen du willst einen Pointer aus Adresse 12345678 haben, geht das z.B. so:
(...)
Da du aber sagtest, daß es nicht in deinem Quellcode ist, schwant mir fürchterliches... Es soll dir gesagt sein, daß du unter WindowsNT nicht ohne weiteres an Speicherbereiche von anderen Prozessen rankommst.

Die von dir beschriebene methode kenne ich, und ich habe weiter oben geschrieben, warum ich versuche diese zu vermeiden.
Lies die anderen Posts, dann weist du warum es geht, und dann wirst du auch herausfinden, warum dir nichts "fürchterliches zu schwanen" braucht. Ich habe meinen Code per DLL in einen fremden Prozess injeziert, womit ich auf alle Variablen die das programm beinhaltet _ohne_ probleme zugreifen kann, und zwar genauso wie das programm selbst. Nun, sag mir nicht, dass dies nicht möglich ist, denn es funktioniert. Leider eben nicht so wie ich das gerne hätte, sprich ohne dereferenzierung eines Pointers.

ciao, Philipp

[tommie-lie]

Zitat von c113plpbr:

Die von dir beschriebene methode kenne ich, und ich habe weiter oben geschrieben, warum ich versuche diese zu vermeiden.

Oha, erste Seite übersehen und dich mit stefan2005 gleichgesetzt, mein Fehler.

Für den Fall fällt mir aber auch nichts anderes ein als der Pointer, wenn die Variable nicht exportiert wird.

[c113plpbr]

Zitat von tommie-lie:

Variable nicht exportiert wird

Wie ist das zu verstehen? Seit wann kann man variablen exportieren? Naja, egal, hat ja nicht wirklich was mit meinem Problem zu tun ...

ciao, Philipp

[Christian Seehase]

Moin Philipp,

wie wär's mit einem varianten Record?

Delphi-Quellcode:

MyValue = record
  case byte of
    0 : (ValueA : DWORD);
    1 : (ValueB : DWORD);
end;

[tommie-lie]

Zitat von c113plpbr:

Wie ist das zu verstehen?

Na, Variable exportieren, genauso wie 'ne Funktion:

Delphi-Quellcode:

library MyLibrary;

uses
  SysUtils, Dialogs;

var
  i: Integer;

procedure Something;
begin
  ShowMessage(IntToStr(i));
end;

exports
  Something, i;

begin
end.

Das ganze hat nur den kleinen Haken, daß Delphi (zumindest 6) noch keine Möglichkeit zur Verfügung stellt, syntaktisch eine Variable auch wieder zu importieren, wie es mit Funktionen über das external-Statement möglich ist. Variablen muss man also mit GetProcAddress() aus der geladenen Bibliothek zusammensuchen.

Zitat von c113plpbr:

Seit wann kann man variablen exportieren?

Keine Ahnung, mindestens seit Delphi 6.


Aber mit absolute geht es nicht, da du keinen Zugriff auf den fremden Code hast, sonst bräuchtest du ja keine DLL. Ein variantes Record ist aus dem gleichen Grund ebenfalls keine Alternative, genauso wenig wie Properties oder sonstiges "Standard"-Zeug der Syntax. Die IMAGEBASE-Direktive bringt hier auch nichts, auch nicht wenn du die relative Adresse einer lokalen Variable wüsstest. Um auf die Variable zuzugreifen, wie man es normalerweise macht mit Variablen, die dazu gemacht sind, zugegriffen zu werden, müsste sie exportiert sein, damit du sie in deiner DLL aus dem Modul laden kannst. Außer dem Pointer fällt mir absolut nichts ein.
Aber warum willst du denn Pointerdereferenzierung vermeiden? Es ist die normale und direkteste Methode auf eine Speicheradresse zuzugreifen, der erzeugte Assemblercode ist so, wie jeder normale Mensch es auch in Assembler schreiben würde: Adresse laden, Wert in die Speicherzelle schreiben, fertig. Wenn du nicht an das Symbol rankommst, wird das wohl die einzige Möglichkeit sein, aber selbst wenn du den Compilerirgendwie doch dazu überreden kannst, eine Variable nicht in dein Image zu nehmen sondern als variable Referenz an irgendeine Speicheradresse anzusehen, wäre ein Pointer sicherlich noch einfacher als die Suche nach der nicht-dokumentierten Compiler-Funktion und Sprach-Feature.
Wenn es dir darum geht, daß du im fertigen Code nicht jedes Vorkommen von Foo durch Foo^ ersetzen willst, kannst du ja die Suchen&Ersetzen-Funktion nehmen. Und unübersichtlicher... also jeder Hack ist wahrscheinlich für jeden anderen komplexer als ein Pointer, den man dereferenziert, und ein einzelnes Zeichen am Namen angehängt ist ja nun wirklich nichts, was einen dermaßen verwirrt, daß man laut zu schreien anfängt und die Tapete von den Wänden kratzt.

Edit: Ergännzt.

[c113plpbr]

@tommie-lie: löl, aber wie gesagt, ich habs ja schon aufgegeben ... ^^ ...

ciao, Philipp

[tommie-lie]

Zitat von c113plpbr:

@tommie-lie: löl

Was war denn an meinem Post so lustig?