Speicherbereich einer Anwendung ermitteln

[bundy]

Hy danke für den Code.

lg
Bundy

[Frickeldrecktuxer_TM]

Zitat:

Zitat von brechi

Ja ne ist klar ^^. Wäre ja schlimm wenns nicht so wäre. ModuleHandle = BaseAdresse. Das ist bis XP 100% so.

So, bitte nochmal lesen, was ich geschrieben habe. Niemand garantiert mir, daß das so ist. Ein Handle ist ein Handle ist ein Handle, und kein Pointer. Daß die Zahlenwerte zufällig übereinstimmen ist nichts als reiner Zufall. Das kann sich jederzeit und von Architektur zu Architektur ändern (sollte es mal mehr als eine Architektur geben, die von MS unterstützt wird ;-)). Wenn du dich darauf verlassen willst, daß Microsoft niemals die Implementierung ändern wird, deine Sache, aber ich nehme lieber den Weg, der mir garantiert, daß ich einen Pointer auf die Basisadresse bekomme, und diese Garantie gibt mir die ToolHelp API.

[SnuffMaster23]

Zitat:

Zitat von Frickeldrecktuxer_TM

Nope, dein Weltbild hat gestimmt, aber du bist davon ausgegangen, daß WPM() in den physikalischen Speicher schreibt, bzw man Werte nur im physikalischen Speicher ändern kann.

Erstmal danke dass du mein Weltbild gerettet hast :D
Ich bin nicht von physikalischem Speicher ausgegangen, sondern eher davon, dass jedes Programm sich für das One-And-Only hält, also mit den anderen nichts zu tun hat

Snuffi

[brechi]

Zitat:

Daß die Zahlenwerte zufällig übereinstimmen ist nichts als reiner Zufall.

Da du dich ja anscheinend noch nicht mit der Windows Architektur auseinander gesetzt hast, kannst du mir unter Windows auch kein Gegenteil beweisen. Debug erstmal GetModuleHandle / GetProcAddress die ja beide Handles zurückgeben und schau was die genau machen.

Das Handles von Files/Processen nichts mit einer Addresse zu tun haben ist klar. Ich empfehle dir mal Windows95 Secrets von Matt Petriek, da erfährt man viel über den Aufbau von Windows.

[Frickeldrecktuxer_TM]

Zitat:

Zitat von brechi

Da du dich ja anscheinend noch nicht mit der Windows Architektur auseinander gesetzt hast, kannst du mir unter Windows auch kein Gegenteil beweisen. Debug erstmal GetModuleHandle / GetProcAddress die ja beide Handles zurückgeben und schau was die genau machen.

Nochmal lesen scheint wohl bei dir nicht zu helfen.
Mir ist sche**egal, wie etwas implementiert ist und wie es in der Realität aussieht. Es ist nicht in der API festgelegt, und das ist, was zählt. Microsoft kann in seiner nächsten Version kommen und die gesamte Debug-API umschreiben und die Handles zu Einträgen in irgendwelchen internen Lookup-Tables machen, und schon guckst du in die Röhre, weil dein Handle dir plötzlich nur noch sagt "Eintrag 42" und nicht mehr "Adresse $7411". Laut API ist das erlaubt, weil ein Handle kein Pointer auf die Basisadresse ist. Was aber nicht geht, ist, daß Microsoft in seiner nächsten Version plötzlich ganz andere Zahlen über die TollHelp-API zurückliefert, ganz einfach weil die API so definiert ist. Klar können sie die API ändern, aber davon kriegt man auch etwas mit. Die Sache mit den Handles merkt man entweder, indem man's ausprobiert, oder gar nicht.
Es ist ganz einfach eine Frage, ob ich Code schreiben will, der in irgendeiner Art und Weise definiertes Verhalten zeigt, oder ob er nur zufällig funktioniert und morgen bereits aufhören könnte, zu funktionieren.

[Shaman]

Hey there

Delphi-Quellcode:

uses
  tlhelp32;

function GetFirstModuleInfo(const ProcessId: Cardinal; out uModule: MODULEENTRY32): Boolean;
var
  hSnapShot: Cardinal;
begin
  Result:= False;
  hSnapShot:= CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, ProcessId);
  if hSnapShot <> 0 then
  begin
    uModule.dwSize:= SizeOf(uModule);
    Result:= Module32First(hSnapShot, uModule);
    CloseHandle(hSnapShot);
  end;
end;

// uModule.modBaseAddr enthält die Basisadresse

Gruss
Shaman

[brechi]

Funktioniert nicht unter WinNT.
Leifert unter 9x nicht die Executable des Hauptprogramms.

Code:

 Wenn NT nutze Alternativfunktion anonsten nutze tlhelp32

Code:

  nutze GetModuleHandle, nutze eventl. unter Windows32Bit Betriebsystem was irgendwann mal nach Vista erscheint eine  Alternativfunktion (evntl. tlhelp32)

tlhelp32 ist
1) langsamer
2) funktioniert auf NT nicht
3) umständlich


Zumal GMH auch nahmhafte Firmen/Leute benutzen. Genauso wahscheinlich wie die änderung der Handles ist die Entferung von den tlhelp funktionen, da Microdoft verstärkt Callback funktionen nutzt (EnumProcesses, EnumProcessModules) (Wegen Abwärtskompatibilität wird höchstwahrscheinlich weeder Base = Handle noch tlhelp32 verändert)

Auch hier müsste man dann für 9x/Nt Unterscheidungen machen.

Nun kann ja jeder einzelne sich darüber ein Bild machen, welche Methode er nutzen will.

[himitsu]

Also mit VirtualQuery kann man ja auch die Startposition eines Speicherblocks erfahren, also wäre es doch damit ebenfalls möglich, da die Dateien (EXE/DLL...) als eigenständige Speicherblöcke in dem Arbeitzsspeicher gemappt werden?

Delphi-Quellcode:

Var MBI: TMemoryBasicInformation;

P := irgendwas innerhalb des Moduls (z.B. der Pointer zu 'ner Funktion/Prozedur);
VirtualQuery(P, MBI, SizeOf(MBI));
BaseAddress := MBI.BaseAddress

[Nicodius]

sind trainer überhaupt legal?

:|für welches spiel ist es denn?

[brechi]

@himitsu

Die Idee daran ist nicht schlecht (wenn auch ein bisschen alt ;) ).
Richtig müsste es aber lauten:

Delphi-Quellcode:

  MBI.AllocationBase

Da (so viel ich weiß) MBI.BaseAddress die Base von der Section zurückliefert.

lpBuffer.AllocationBase liefert einen Pointer zurück, mit dem man (meiner MEinugn nach) problemlos in ein DWOrd umwandeln kann um dann z.b. mit GetProcAddress / GetModuleFileName etc. weitere Daten zu ermitteln.

Um aber die Base für einen Trainer umzurechnen, reicht es aber allemal.