Autor Beitrag
tmtmtm
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 22



BeitragVerfasst: Do 04.07.02 14:49 
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
ontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic starofftopic star
Veteran
Beiträge: 6366
Erhaltene Danke: 60

Windows 7, Ubuntu
Delphi 7 Prof.
BeitragVerfasst: 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 22



BeitragVerfasst: Do 04.07.02 17:04 
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
ontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic starofftopic star
Veteran
Beiträge: 6366
Erhaltene Danke: 60

Windows 7, Ubuntu
Delphi 7 Prof.
BeitragVerfasst: Do 04.07.02 18:39 
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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 160



BeitragVerfasst: Do 04.07.02 22:33 


Zuletzt bearbeitet von Pit am Sa 05.10.02 06:58, insgesamt 1-mal bearbeitet
tmtmtm Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 22



BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 160



BeitragVerfasst: Mo 08.07.02 09:55 


Zuletzt bearbeitet von Pit am Sa 05.10.02 06:57, insgesamt 1-mal bearbeitet
tmtmtm Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 22



BeitragVerfasst: Mo 08.07.02 10:20 
Moijn Pit,

Aber wie läuft das dann unter WinNT?
Was ist dort anders?

Gruß Thomas
Delta7
Hält's aus hier
Beiträge: 12



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

_________________
Ein Byte hat 8 Bit. Wer's nicht glaubt, soll seinen Rechner aufschrauben und nachzählen.
Delta7
Hält's aus hier
Beiträge: 12



BeitragVerfasst: Do 11.07.02 20:56 
Nachtrag: ich sehe gerade das es einTtutorial zum Thema hooks gibt. Hätte mir glatt die lange Rede oben sparen können
www.entwickler-ecke.de/viewtopic.php?t=101 :D

_________________
Ein Byte hat 8 Bit. Wer's nicht glaubt, soll seinen Rechner aufschrauben und nachzählen.