Adresse einer privaten Methode bekommen

[Win32.API]

Zitat von mkinzler:

Dann melde es dem Hersteller

Ist schon vor ca. 2 Monaten passiert, bis jetzt leider keine Besserung. Darum wollte ich es nun selber in die Hand nehmen.

[Namenloser]

Delphi-Quellcode:

unit Unit1;

interface

uses
  classes;

type

  TMyClass = class
  strict private
    procedure BuggyMethod;
  end;

  TMyClassHack = class helper for TMyClass
  public
    function GetBuggyMethodAddress: Pointer;
  end;

  procedure Test;

implementation

uses
  SysUtils;

{ TmyClassHack }

function TMyClassHack.GetBuggyMethodAddress: Pointer;
asm
  lea eax, [0+TMyClass.BuggyMethod]
end;

{ TMyClass }

procedure TMyClass.BuggyMethod;
begin
  writeln('hello');
end;

procedure Test;
var
  Obj: TMyClass;
  Addr: Pointer;
begin
  Obj := TMyClass.Create;
  writeln(format('%p',[Obj.GetBuggyMethodAddress]));
  Addr := Obj.GetBuggyMethodAddress;
  asm
    call Addr
  end;
  Obj.Free;
end;

end.

Das funktioniert bei mir. Ich weiß allerdings nicht genau was du damit meinst:

Zitat:

Eine "Hack"/"Dummy"-Klasse kommt in diesem Fall nicht in Frage, da der Code für mehrere Versionen der Klasse arbeiten soll.

[himitsu]

strict private sollte doch eigentlich komplett privat sein, also nichtmal in einer anderen Klasse, der selben Unit.
Und selbt normale private Methoden kann man "eigentlich" nicht von anderen Units aus aufrufen.

Wollte erst fragen, ob du das auch mal mit getrennten Units getestes hast, aber selbst da geht es.

Also dieser Hack ist dann ja richtig böse




Es gibt abner noch einen einfachen Hack, um virtuelle private Methoden zu bekommen ... ohne RTTI- oder VMT-Auslesen und so.

Einfach 'ne Dummy-Klasse, ebenfalls mit diesen virtuellen Methoden (natürlich in selber Reihenfolge) erstellen und rübercasten.

[Namenloser]

Zitat von himitsu:

strict private sollte doch eigentlich komplett privat sein, also nichtmal in einer anderen Klasse, der selben Unit.
Und selbt normale private Methoden kann man "eigentlich" nicht von anderen Units aus aufrufen.

Wollte erst fragen, ob du das auch mal mit getrennten Units getestes hast, aber selbst da geht es.

Nein hab ich nicht, aber ich hatte erst testweise probiert, ob man in einem Class-Helper auf unter strict private deklarierte Methoden zugreifen kann, was nicht ging. Daraufhin hab ich dann mal probiert ob es im Inline-Assembler funktioniert, und da es funktionierte, bin icheinfach mal davon ausgegangen, dass das auch in verschiedenen Units funktionieren muss. Denn bei Strict Private hat die beinhaltende Unit ja im Gegensatz zum normalen private keine Privilegien.

Zitat von himitsu:

Also dieser Hack ist dann ja richtig böse

Danke

[edit]

Zitat von himitsu:

Es gibt abner noch einen einfachen Hack, um virtuelle private Methoden zu bekommen ... ohne RTTI- oder VMT-Auslesen und so.

Einfach 'ne Dummy-Klasse, ebenfalls mit diesen virtuellen Methoden (natürlich in selber Reihenfolge) erstellen und rübercasten.

Aber was für einen Sinn sollte es haben, private Methoden als virtual zu deklarieren? Mann kann sie doch eh nicht überschreiben, weil man in abgeleiteten Klassen keinen Zugriff darauf hat.
[/edit]

[himitsu]

Hättest du das nicht mal vor 'nem knappen Jahr sagen können?

Weil irgendein "Arsch" TApplication.ProcessMessage als Privat deklariert hat, kommt man da einfach nicht ran und so hätte ich mir vel Arbeit und umständliche Alternativen ersparen können.


Hey, jetzt könnte man vermutlich auch Hagens Delay mit einer noch besseren Zeiteinhaltung versehen, selbst wenn viele Messages eintreffen

[mkinzler]

So weit es möglich ist sollte man eh uaf solche Hacks verzichten. Denn diese Lücke könnte irgendwann geschlossen werden

[Namenloser]

Zitat von mkinzler:

So weit es möglich ist sollte man eh uaf solche Hacks verzichten. Denn diese Lücke könnte irgendwann geschlossen werden

Ich bin der Meinung, man sollte lieber darauf verzichten, beliebige Sachen als privat zu deklarieren, wenn es keinen echten Grund dafür gibt.

[himitsu]

Zitat von mkinzler:

So weit es möglich ist sollte man eh uaf solche Hacks verzichten. Denn diese Lücke könnte irgendwann geschlossen werden

Ich hoffe die machen sowas erst dann, wenn sie mal ihre Sichbasrkeitsrichtlinien verbessert haben.

Es gibt z.B. keinen Grund, warum ProcessMessage (drum sind dieses und Delay soein schönes Beispiel) versteckt sein muß.

ProcessMessages bearbeitet immer alle Messages, bis nix mehr da ist.
ProcessMessage verarbeitet nur die nächste Message, also könnte man damit.
Somit könnte Delay hier seine Pausenzeiten besser einhalten, da man die Verarbeitung eher abbrechen könnte und nicht alles sofort verarbeitet.

Zitat von NamenLozer:

Ich bin der Meinung, man sollte lieber darauf verzichten, beliebige Sachen als privat zu deklarieren, wenn es keinen echten Grund dafür gibt.

jupp

Zitat:

Ist schon vor ca. 2 Monaten passiert, bis jetzt leider keine Besserung. Darum wollte ich es nun selber in die Hand nehmen.

Gut, ich hatte hier gerade noch 2 Jahre im Kopf und wollte grade sowas wie "sooo lange keine Antwort? ... is ja nett" sagen (aber )

[Win32.API]

Zitat von NamenLozer:

Delphi-Quellcode:

unit Unit1;

interface

uses
  classes;

type

  TMyClass = class
  strict private
    procedure BuggyMethod;
  end;

  TMyClassHack = class helper for TMyClass
  public
    function GetBuggyMethodAddress: Pointer;
  end;

  procedure Test;

implementation

uses
  SysUtils;

{ TmyClassHack }

function TMyClassHack.GetBuggyMethodAddress: Pointer;
asm
  lea eax, [0+TMyClass.BuggyMethod]
end;

{ TMyClass }

procedure TMyClass.BuggyMethod;
begin
  writeln('hello');
end;

procedure Test;
var
  Obj: TMyClass;
  Addr: Pointer;
begin
  Obj := TMyClass.Create;
  writeln(format('%p',[Obj.GetBuggyMethodAddress]));
  Addr := Obj.GetBuggyMethodAddress;
  asm
    call Addr
  end;
  Obj.Free;
end;

end.

Das funktioniert bei mir. Ich weiß allerdings nicht genau was du damit meinst:

Zitat:

Eine "Hack"/"Dummy"-Klasse kommt in diesem Fall nicht in Frage, da der Code für mehrere Versionen der Klasse arbeiten soll.

Jawoll . Das Zusammenspiel aus Classhelper und Zugriff via Assembler macht es Möglich.

Mit Hack-Klasse meinte ich eine Klasse, die exakt gleich deklariert ist, aber die entsprechende Methode als public deklariert. Somit liegt im Speicher alles an der gleichen Stelle und der Zugriff ist auch Möglich.

Grüße,
Win32.API

[himitsu]

Zitat von Win32.API:

Mit Hack-Klasse meinte ich eine Klasse, die exakt gleich deklariert ist, aber die entsprechende Methode als public deklariert. Somit liegt im Speicher alles an der gleichen Stelle und der Zugriff ist auch Möglich.

Das geht aber nur mit virtuellen oder dynamischen Methoden
und mit Feldern.
Normalte Methoden kann man so nicht zugänglich machen, da diese direkt im Quellcode, bei allen Aufrufen, und z.B. nicht über die VMT des erzeugten Objekts adressiert sind.