Entwickler-Ecke
Sonstiges (Delphi) - Re: Daten direkt aus RAM lesen.
tmtmtm - Do 04.07.02 14:49
Titel: Re: Daten direkt aus RAM lesen.
Moijn Pit,
Nun, wozu brauch' ich das?
Ja, eigentlich brauche ich das nur zum erstellen eines Spiele-Trainers, der mir im Hintergrund läuft und dafür sorgt, daß z.B. bei einem Strategie-Spiel wie Star Trek - Armada ständig die Panzerungs- oder Geld-Werte oben gehalten werden.
Ich hab's zwar schon direkt über die Manipulation der Savegames probiert, komme aber dort nicht weiter, da das Spiel eine Checksumme für die Saves erstellt.
Also Ofen aus!
Und da für Arbeitsspeicherdaten des Spiels bestimmt keine Checksummen erstellt werden, wollte ich's halt da mit Manipulation versuchen.
Gruß Thomas
Übrigens: -dieses STA-Projekt ist genau das, was mir noch fehlt.
Denn in meiner Pascal-Zeit habe ich schon Manipulations-Programme für Descent II, M.A.X. 1, Need for Speed 4, Wolfenstein 3D & Mechwarrior 2 und einen Map-Reader für G.T.A. 1 geschrieben. Es muß doch eine Möglichkeit geben, auf den gesamten Speicher im Win zuzugreifen.
Ich meine, im DOS-Asm ging das mit rund 135 Byte, den konventionellen und hohen Arbeitsspeicher in eine Datei zu schreiben (insges. 1 MB). Es ließ sich sogar wahllos im RAM herumschreiben (Bis auf manche Systembereiche gings zu 90% immer). Im Windows muß das doch auch gehen.
Klabautermann - Do 04.07.02 15:13
Hi,
unter DOS gehörte deiner Anwendung im grunde auch der ganze Rechner.
Mitlerweile ist sogar M$ im Multitaskingzeitalter angekommen und jedes Programm läuft sozusagen auf seinenem eigenen (vituellen)Rechner mit eigenen Speicher. Auf den Speicher deiner Anwendung kannst du zugreifen. Um an den Speicher einer anderen Anwendung zu kommen müsstest du (virtuelle)Rechnerübergreifend Programmieren.
Ich habe es selber noch nicht probiert, hoffe aber schwer, das Windows dir das nicht erlauben wird. Ich schätze da musst du bei deinem Spiel einfach mehr üben ;).
Gruß
Klabautermann
tmtmtm - Do 04.07.02 17:04
Titel: Re: Daten direkt aus RAM lesen.
Ich nochmal!
Also heißt das jetzt, daß jedes Programm vom Start her ein breites Adress-Spektrum von rund 4 GB zugewiesen bekommen kann?
Oder ist es so, das diese Maximalen 4GB den gesamten möglichen Arbeitsspeicher vertreten?
Kann man also über Zeiger:=Ptr(Adresse:Longint); wirklich nur im Speicher der eigenen Anwendung herumkramen?
(Am Ende kommt's doch auf's selbe raus: Alles landet im Arbeitsspeicher.)
Ich kann mir das echt kaum vorstellen, daß da alles so pikobello voneinander getrennt ist. :roll:
MfG T.M.
Klabautermann - Do 04.07.02 18:39
Titel: Re: Daten direkt aus RAM lesen.
tmtmtm hat folgendes geschrieben: |
Also heißt das jetzt, daß jedes Programm vom Start her ein breites Adress-Spektrum von rund 4 GB zugewiesen bekommen kann?
Oder ist es so, das diese Maximalen 4GB den gesamten möglichen Arbeitsspeicher vertreten? |
Beides.
Deine 32 Bit CPU kann (wie dein 32 Bit Betriebssystem) Maximal mit 4GB arbeiten. Also kannst du maximal 4 GB Ram in deinen Rechner Bauen mit denen Windows dann arbeiten kann. Windows wird diesen Arbeistspeier verwenden um (unter anderen) "virtuellen" Arbeitspeicher zu verwalten. Jeder dieser Virtuellen Speicher kann wieder bis zu 4 GB groß sein, muss sich aber nicht (komplett) im RAM befinden.
tmtmtm hat folgendes geschrieben: |
(Am Ende kommt's doch auf's selbe raus: Alles landet im Arbeitsspeicher.) |
Nicht umbedingt so wie du das meinst.
Du kannst jetzt eine Anwendung schreiben, die 4 GB RAM belegt, obwohl du nur 256 MB "echten"-Speicher hast. Windows wird dann zur bereitstellung der Differenz die Festplatte heranziehen. Deine Anwendung wird entsprechend langsammer werden, aber sie läuft.
Richtig ist allerdings, das jedes einzelne Bit (im Blöcken von 32) mindestes einmal durch den RAM gepumpt werden muss um in der Auslagerungsdatei landen zu können und auch wieder reingeladen wird, wenn du wieder damit arbeitest.
Anmerkungen:
Diese äußerungen beziehen sich auf ein "Ideales" System, welches Ideal Konfiguriert ist. Ich habe mich nie mit Speicherverwaltung von Windows im detail auseinandergesetzt, aber das Prinzip sollte stimmen.
Du darfst mich gerne Korrigieren Pit ;))
Pit - Do 04.07.02 22:33
Titel: Re: Daten direkt aus RAM lesen.
tmtmtm - Fr 05.07.02 21:32
Dankeschön Klabautermann und Pit!
Ihr habt mir sehr geholfen!
Durch ReadProcessMemory und WriteProcessMemory bin ich jetzt auf noch viele andere Möglichkeiten zur Prozessverarbeitung gestoßen.
So z.B. auf CreateToolhelp32Snapshot die das Auflisten aller laufenden Prozesse mittels Handle auf eine Liste ermöglicht.
Ich werde jetzt also noch'n bissel tüfteln, um euch irgendwann noch mal 'ne Lösung präsentieren zu können.
Aber erstmal zocke ich noch ne Runde Q3A um 'nen freien Kopp zu kriegen.
Gruß Thomas
Pit - Mo 08.07.02 09:55
tmtmtm - Mo 08.07.02 10:20
Titel: Re: Daten direkt aus RAM lesen.
Moijn Pit,
Aber wie läuft das dann unter WinNT?
Was ist dort anders?
Gruß Thomas
Delta7 - Do 11.07.02 02:14
Aber wie läuft das dann unter WinNT?Aber wie läuft das dann unter WinNT?
Unter NT verhindert im Prinzip das Betriebssystem zuverlässig das Auslesen von fremden Prozessen als teil des Security Konzeptes.
Es gibt trotzdem eine Möglichkeit, aber der Ansatz ist ein anderer.
Die (saubere) Lösung ist eine Dll die von aussen in den Prozess geladen wird und dann im Kontext des prozesses läuft. (Admin Rechte helfen) Dies erreichst Du indem Du ein Programm schreibst, das einen Hook in dem Fremdprozess (das laufende Spiel) setzt. Damit kannst Du erreichen, dass (zum Beispiel bei jedem Tastendruck) eine von Dir definierte Funktion aus DEINER dll aufgerufen wird, und zwar im Kontext des gehookten Prozesses, damit hat diese Funktion Zugriff auf alle Ressourcen des Prozesses, also z.B. RAM Adressraum. Wenn Dich dieses (heikle) Thema näher interessiert, schau Dir doch die
:arrow: API Funktion setwindowshookex näher an.
Nicht vergessen, den hook nach Gebrauch wieder zu entfernen!!
Aber Vorsicht, mit diesen Funktionen kann man eine NT Maschine leicht ins Nirvana schicken......
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!