Adresse einer privaten Methode bekommen

[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:

Zitat von mkinzler (Beitrag 1036099)

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:

Zitat von mkinzler (Beitrag 1036099)

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:

Zitat von NamenLozer (Beitrag 1036101)

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 )

[Stevie]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1036063)

Das Ganze scheitert schon am Konzept. Du kannst nicht die Adresse einer privaten Prozedur auslesen. Eine private Prozedur ist vom Konzept her (ähnlich wie protected) nur INNERHALB eines Objektes verwendbar. Du kannst sie also auch nicht von außen aufrufen, weil es so aussieht, als würde sie gar nicht existieren. Somit kann sie von RTTI nicht gefunden werden.

Das stimmt so nicht. Mit Delphi 2010 (welches der TE nutzt) kann man von private bis published alles von einer Klasse über RTTI abrufen, sofern dies eingestellt wurde. Dafür gibt es spezielle Compiler Direktiven. Nützt dem TE natürlich nix, da wahrscheinlich nicht mit diesen RTTI Einstellungen kompiliert wurde und er den Source nicht hat (dann könnte er ja auch gleich die Methode fixen :P)

Zitat:

Zitat von NamenLozer (Beitrag 1036101)

Zitat:

Zitat von mkinzler (Beitrag 1036099)

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.

Imo wird eher andersrum nen Schuh draus, es sollte nur public sein, was man auch von außen aufrufen soll/darf/muss. Und protected nur, was vom Design her dafür vorgesehen ist, in abgeleiteten Klassen modifiziert zu werden.

[Namenloser]

Zitat:

Zitat von Stevie (Beitrag 1036103)

Zitat:

Zitat von NamenLozer (Beitrag 1036101)

Zitat:

Zitat von mkinzler (Beitrag 1036099)

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.

Imo wird eher andersrum nen Schuh draus, es sollte nur public sein, was man auch von außen aufrufen soll/darf/muss.

Nein, natürlich soll man nicht alles als public deklarieren. Ich deklariere auch nur die Sachen als public, die ich in der "offiziellen Anwendungsschnittstelle" haben will. Alles andere deklariere ich aber zum Großteil als protected und nicht als private. Nur in sehr seltenen Sonderfällen, wenn es wirklich einen triftigen Grund gibt, warum Nachfahren keinen direkten Zugriff haben dürfen, deklariere ich Methoden oder Felder als privat.

[Win32.API]

Zitat:

Zitat von NamenLozer (Beitrag 1036086)

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 :thumb:. 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:

Zitat von Win32.API (Beitrag 1036112)

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.