AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Speicherbereich einer Anwendung ermitteln

Ein Thema von bundy · begonnen am 26. Apr 2006 · letzter Beitrag vom 30. Apr 2006
Antwort Antwort
Seite 3 von 4     123 4   
Benutzerbild von bundy
bundy

Registriert seit: 24. Mai 2003
Ort: Eisenstadt
438 Beiträge
 
Delphi 2007 Architect
 
#21

Re: Speicherbereich einer Anwendung ermitteln

  Alt 27. Apr 2006, 09:58
Hy danke für den Code.

lg
Bundy
+++Glaube keiner Statistik, die du nicht selbst getürkthast.++++
********************
Ein anonymer Statistiker. *
********************
  Mit Zitat antworten Zitat
Frickeldrecktuxer_TM
(Gast)

n/a Beiträge
 
#22

Re: Speicherbereich einer Anwendung ermitteln

  Alt 27. Apr 2006, 10:58
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.
  Mit Zitat antworten Zitat
Benutzerbild von SnuffMaster23
SnuffMaster23

Registriert seit: 13. Feb 2006
Ort: Kempten
253 Beiträge
 
#23

Re: Speicherbereich einer Anwendung ermitteln

  Alt 27. Apr 2006, 17:56
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
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
"Conspiracy is the poor man's mapping of the world" - Fredric Jameson
  Mit Zitat antworten Zitat
brechi

Registriert seit: 30. Jan 2004
823 Beiträge
 
#24

Re: Speicherbereich einer Anwendung ermitteln

  Alt 27. Apr 2006, 19:17
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.
  Mit Zitat antworten Zitat
Frickeldrecktuxer_TM
(Gast)

n/a Beiträge
 
#25

Re: Speicherbereich einer Anwendung ermitteln

  Alt 27. Apr 2006, 19:41
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.
  Mit Zitat antworten Zitat
Benutzerbild von Shaman
Shaman

Registriert seit: 2. Nov 2003
Ort: Schweiz
407 Beiträge
 
Turbo Delphi für Win32
 
#26

Re: Speicherbereich einer Anwendung ermitteln

  Alt 27. Apr 2006, 21:45
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
Daniel Pauli
Looking for answers from the great beyond
  Mit Zitat antworten Zitat
brechi

Registriert seit: 30. Jan 2004
823 Beiträge
 
#27

Re: Speicherbereich einer Anwendung ermitteln

  Alt 28. Apr 2006, 12:46
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.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.014 Beiträge
 
Delphi 12 Athens
 
#28

Re: Speicherbereich einer Anwendung ermitteln

  Alt 28. Apr 2006, 12:58
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
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Nicodius

Registriert seit: 25. Apr 2003
Ort: Graz
2.234 Beiträge
 
Delphi 2006 Architect
 
#29

Re: Speicherbereich einer Anwendung ermitteln

  Alt 28. Apr 2006, 13:00
sind trainer überhaupt legal?

für welches spiel ist es denn?
Nico Müller
  Mit Zitat antworten Zitat
brechi

Registriert seit: 30. Jan 2004
823 Beiträge
 
#30

Re: Speicherbereich einer Anwendung ermitteln

  Alt 28. Apr 2006, 13:20
@himitsu

Die Idee daran ist nicht schlecht (wenn auch ein bisschen alt ).
Richtig müsste es aber lauten:
  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.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:22 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz