uallcollection - GetRealModule Handle win speicherverwaltung

[Arnulf]

Hallo
Speziell zur function getrealmodulehandle von der uallcollection hätte ich ein zwei Fragen.

Delphi-Quellcode:

function GetRealModuleHandle(addr: pointer): cardinal; stdcall;
var h, i: cardinal;
    buf: array[0..255] of char;
begin
  h := cardinal(addr) and $FFFF0000;
  repeat
    i := GetModuleFilename(h,buf,255);
    dec(h,$10000);
  until (i <> 0) or (h = 0);
  if (h = 0) then
    result := 0 else
    result := h+$10000;
end;

warum wird hier binär addiert?
cardinal(addr) and $FFFF0000; und danach $10000 hex abgezogen?
dec(h,$10000); mir ist ist bei der ganzen funktion einfach nicht klar, wie die den "RealModulHandle" ermittelt?
Auch warum die funktion dann mit ntdll.dll verglichen wird ist mir einfach unverständlich.

Delphi-Quellcode:

if GetRealModuleHandle(addr) <> GetModuleHandle('ntdll.dll') then
              result := false;

Hoffe jemand hilft mir bei dem puzzle .
Arnulf

[NicoDE]

Zitat von Arnulf:

warum wird hier binär addiert?

Boolsche UND-Verknüpfung ist keine Addition.
Sinn der Zeile ist es, die Bits im niederwertigen Wort los zu werden (bzw. die Bits im höherwertigen Wort übrig zu lassen - je nachdem wie man es sieht). Ein HiWord(x) hätte das gleiche Resultat...

Gruß Nico

[Arnulf]

ok entschuldigung ich hab mich falsch ausgedrückt.
addition ist falsch klar, aber es wird bitweise verglichen und die bits je nach true oder false umgedreht ( 0 false / 1 true ).
ungefähr weiß ich schon was passiert ist nur schon jahre her daß ich das gelernt hab .

Die eigentliche Frage ist aber warum?
Das ist eine procedure adresse - jetzt wird von dem doubleword sozusagen das high word weiterverwendet - also von den 32 bit nur die oberen 16.

Arnulf

[NicoDE]

Zitat von Arnulf:

Das ist eine procedure adresse - jetzt wird von dem doubleword sozusagen das high word weiterverwendet - also von den 32 bit nur die oberen 16.

Um es mit anderen Worten zu sagen: die Adresse wird auf ein Vielfaches von $10000 ab"gerundet" (da die unteren 16 Bit "entfernt" werden), da die Module nur an Adressen geladen werden, die ein Vielfaches von $10000 sind.
Kurz, eine Optimierung um die (Brute-Force-)Suche zu beschleunigen...

[brechi]

GetRealModuleHandle gibt dir von einer speicherstelle die "darunterliegende" library zurück.

Es sollte nur für einen Speicherbereich benutzt werden der auch in einer dll liegt.
Es wird in dem Fall von dir mit der ntdll verglichen da es um das weiterleiten einer Importierten funktion geht.
Unter NT können imports weitergeleitet werden, z.b. exportiert die kernel32.dll funktionen die gar nicht in der eigenen dll liegt sondern in der ntdll.dll. Es ist mit auch nur in den speziellen fällen bekonnt. wenn du jetzt nen exporttablecheck machst ob eine funktion in der dll liegt, und sie liegt ausserhalb, dann muss diese funktion noch lange nicht "gehookt" sein da, spieziell bei der kernel32.dll das forwarding genutzt wird, d.h. einige funktionen liegen NIE in der kernel32.dll sondern in der ntdll.dll. d.h. in den fällen sind die funktionen auch nicht gehookt.
es ist aber glaub ich besser nen check zu machen ob eine bestimmte funktion weitergeleitet wird. Ich selber hab mir noch nicht angeschaut welcher flag etc. gesetzt ist, bzw wie das genau funktioniert.

[NicoDE]

Zitat von brechi:

Ich selber hab mir noch nicht angeschaut welcher flag etc. gesetzt ist, bzw wie das genau funktioniert.

Wenn die RVA der exportierten Funktion in das Export-Directory zeigt, dann handelt es sich um einen Forwarder-String (module.function).
Siehe http://www.luckie-online.de/Develope...Exports2_0.zip

[Arnulf]

Oh das ist mal echt informativ .
damit ist das mal klar:

Delphi-Quellcode:

if GetRealModuleHandle(addr) <> GetModuleHandle('ntdll.dll') then
              result := false;

@nicoDE
was meinst du mit RVA? vielleicht verstehe ich dann den ganzen satz hoff ich.
Mit forwarder string meinst du, daß die function nicht in der .dll liegt die sie exportiert hoff ich ..?

Bitte nicht für blöd halten, aber das ist alles neu für mich und es sickert alles nur langsam in mein hirn.
Das ganze ist also nur ein spezialfall check?
die source ist ja eigentlich so:

Delphi-Quellcode:

        if (integer(addr) < moduleh) or (integer(addr) > moduleh+integer(INH^.OptionalHeader.SizeOfImage)) then
           if GetRealModuleHandle(addr) <> GetModuleHandle('ntdll.dll') then
              result := false;

hier wird überprüft ob die import adresse im bereich des moduls liegt wenn nicht wird mit getrealmodulehandle nach dem eigentlichen modul gesucht und nochmal überprüft ob nicht dieser spezialfall mit ntdll.dll zutrifft.
jetzt will ichs aber genau wissen.

Zitat:

da die Module nur an Adressen geladen werden, die ein Vielfaches von $10000 sind.

das heißt windows verwaltet die module so, daß sie immer oberhalb von hex 10000 liegen.

Wie schaft es windows dann von meiner function dann mit getmodulefilename den functionsnamen zu bekommen?
genügt der api einfach nur eine adresse die im adressbereich der function liegt um den namen des moduls zurück zu liefern?
und warum gibt es ein dec hex 10000 als suchfunktion?
    dec(h,$10000); Danke auf jeden Fall mal - jetzt ist mir der Sinn der function mal verständlich
Arnulf

[brechi]

die adresse liegt irgendwo in der dll

d.h. z.b. an 00411234 mit dem and bekommt man dann 00410000 raus, darauf wird dann en GetModuleFileName ausgeführt -> ist es ein gültiger dll handle (also gültige dll base, da es das selbe ist) dann bekommt man nen pfad zu der dll zurück.
ist der rückgabewert 0 dann muss man 100000 abziehen und das wieder holen d.h. in obigen fall würde man dann getmodulefilename auf 00400000 ausführen was dem handle der exe entspicht, jetzt würde man halt den pfad zu der exe bekommen und man hat nen gültiges handle/imagebase gefunden.

[Arnulf]

AAAAAHHHHHHH - der groschen ist gefallen

jetzt bleibt nur noch das übrig:

Zitat:

was meinst du mit RVA? vielleicht verstehe ich dann den ganzen satz Smile hoff ich.
Mit forwarder string meinst du, daß die function nicht in der .dll liegt die sie exportiert hoff ich ..?

Jetzt denk ich bekomm ich den check auch remote hin weil ich endlich kapier was da gemacht wird.
@Brechi
Da du ja weißt was ich genau mache...
Im prinzip kann ich mir den stress ja auch sparen, weil ich ja nur überprüfen müsste, ob ein modul opengl32.dll überhaupt importiert. Wenn ja ist es eh fast sicher ein cheat ( sicher fraps oder tso würde dann auch erkannt aber das kann ich vorher schon abfangen).
Allerdings gibt es hald process hide programme und da hilft mir auch die ishook von uall als remote funktion nicht viel.

Jedenfalls freu ich mich diese kryptischen sourcen endlich zu kapieren

Arnulf

[Arnulf]

Ach ich habs gefunden - RVA heißt relative virtual adress
Trotzdem hat sich der satz nicht geklärt.
Wo steht die adresse in der funktion? - am Anfang der function?
Das klingt interessant.
Und die RVA soll dann in die exportierte function zeigen?
Wenn man mir wortfetzen zuwirft, dann muß ichs einfach wissen so bin ich hald

Arnulf