Speicher(adressen) von Fremdprogrammen auslesen

[D@nte]

Ich hab mich heut mal rangemacht ein altes 3rd Party Tool nach zu schreiben, da die Entwicklung des Orginals eingestellt wurde und nu nicht mehr mit allen Servern kompatibel ist...

So mein Hauptproblem ist nachdem ich gemerkt hab, dass das Orginaltool reine Änderungen der ini nicht akzeptiert, dass ich wenn ich versuche die Werte die ich benötige, auszulesen nur Mumpitz bekomme...

Code: Alles auswählen

Procedure.l hex2dec(h$)
  h$=UCase(h$)
  For r=1 To Len(h$)
    d<<4 : a$=Mid(h$,r,1)
    If Asc(a$)>60
      d+Asc(a$)-55
    Else
      d+Asc(a$)-48
    EndIf
  Next
  ProcedureReturn d
EndProcedure

SpeicherBuffer = hex2dec("768DB4")

Debug "TEST : " + PeekS(@SpeicherBuffer)

Laut "ArtMoney SE" hat die Speicheradresse 00768DB4 den Wert "Speedelfe" wenn ich den PB Code ausführe bekomme ich als Debug allerdings ein:

TEST : ´

[Scarabol]

Hi,

[zu deinem Original]
erstma ist das @ falsch, denn SpeicherBuffer ist ja schon ein Pointer.

[Edit]
Du bekommst wahrscheinlich nur den Pointer auf nen String zurück
[/Edit]

Gruß
Scarabol

[D@nte]

>[zu deinem Original]
Wie gesagt funktioniert ja so eh nicht mit exterenen Anwendungen hab's nur mal als BSp wie man's nicht macht drin gelassen

>Du bekommst wahrscheinlich nur den Pointer auf nen String zurück
Könntest du (oder wer anders) mir dann mal auf die Sprünge helfen wie die (de)referenzierung eines Pointers in PB auszusehen hat?
Hab das letzte mal in C++ mit Pointer gearbeitet und das ist schon ne ganze Weile her und in PB brauchte ich es bit dato noch nicht...

[Helle]

1701146707 = $65657053 = eepS. Die Stringgröße ist ja bekannt (9) und sollte auch so definiert werden:

Code: Alles auswählen

Name$=Space(9)

ProcessHandle = OpenProcess_(#PROCESS_ALL_ACCESS, #False, ProgID) 
StartLeseAdresse = $768DB4 

ReadProcessMemory_(Processhandle, StartLeseAdresse, @Name$, 9, 0) 

Debug Name$

Sollte so funktionieren.

Gruss
Helle

[Thorium]

So wie es Helle geschrieben hat funktioniert es auf jeden Fall. Will nurnoch was zum allgemeinen Verständnis schreiben, warum man ReadProcessMemory verwenden muss.

Seid Win95/NT verwendet Windows das "Flat Memory Model". Das bedeutet das jeder Prozess seinen eigenen 4 GB großen Speicher bekommt. Dabei spielt es keine Rolle ob wirklich 4GB physikalischer Speicher vorhanden sind oder nicht. Es handelt sich dabei um virtuellen Speicher, nicht zu verwechseln mit dem Swap-File was auch als virtueller Speicher bezeichnet wird. Also virtueller Speicher meint hier das es sich nicht um reale Speicheradressen handelt. Das Betriebssystem legt die Speicheradressen auf physikalischen und Swap-Speicher um. Also ist virtuelle Adresse nicht = physikalische Adresse. Der Vorteil bei diesem Speichermodel ist, das man sich keine Sorgen darüber machen braucht in Speicherbereiche zu schreiben, welche von anderen Programmen genutzt werden. Und man braucht sich auch nicht darum kümmern Daten auf die Festplatte auszulagern, das macht alles das Betriebssystem, sehr feine Sache.

Um trotzdem Zugriff auf den Speicher anderer Prozesse zu bekommen gibt es eine Reihe API-Funktionen: hier und hier

[D@nte]

@Helle
Danke für die Hilfe läuft jetzt

@Thorium
Danke für die genau Erklärung, so genau stands hier noch nirgends

[onny]

Hallo, möchte für meine Frage nicht unbedingt ein neues Topic erstellen.

Laut MSDN wird der ProcessHandle "vererbt", wenn ich den zweiten Parameter auf #True setze:

Code: Alles auswählen

OpenProcess_(#PROCESS_ALL_ACCESS, #True, ProgID)

D.h. alle DLLs oder weitere Executables, die von dem Programm (ProgID) aufgerufen wurden, haben den gleichen, ursprungs Processhandle.
Wenn jetzt bei einem Spiel eine zusätzliche DLL geladen wird, finde ich diese dann im ProcessMemory vom Ursprungsprogramm?
Oder sollte ich den Processhandle der geöffneten DLL nehmen? (Wenns den überhaupt gibt, denn eine geladene DLL hat ja auch keine PID).
Kann es sein dass ich bestimmte Funktionen einer mitgeladenen DLL erst auslesen kann wenn diese aufgerufen worden sind?

Vielen dank schonmal für alle Antworten, gruß oNNy

//achja, noch eine frage zum thema:

habe mir ein programm erstellt wo 3 messagerequesters hintereinander kommen. ich möchte nun mit openprocess die test.exe starten und mit readprocessmemory einen text der 3 boxen auslesen und überschreiben.
funktioniert das rein vom prinzip her?

[AND51]

Das bedeutet das jeder Prozess seinen eigenen 4 GB großen Speicher bekommt. [...]
Der Vorteil bei diesem Speichermodel ist, das man sich keine Sorgen darüber machen braucht in Speicherbereiche zu schreiben, welche von anderen Programmen genutzt werden.

Ist das die Antwort auf meine Frage "AllocateMemory() zu klein » Warum geht das hier?"?
Ich kann also meine 4 GB ausnutzen wie ich will, kreuz und quer im Arbeitsspeicher rumschreiben und so weiter, ohne, dass ich damit einem anderen Prozess in die Quere komme? Und ebenso kann ich auch gefahrlos in zu kleine Speicherbuffer schreiben?

Könnte ich dann nicht auch gleich 1 GB Arbeitsspeicher reservieren und diesen Memory mit Offsets in kleine Bereiche aufteilen, sodass ich z. B. einen sich selbst vergrößernden Network-Empfangsbuffer (siehe Thread) erstellen kann? Und das Danke der Offset-Methode möglichst einfach?

[Thorium]

Das bedeutet das jeder Prozess seinen eigenen 4 GB großen Speicher bekommt. [...]
Der Vorteil bei diesem Speichermodel ist, das man sich keine Sorgen darüber machen braucht in Speicherbereiche zu schreiben, welche von anderen Programmen genutzt werden.

Ist das die Antwort auf meine Frage "AllocateMemory() zu klein » Warum geht das hier?"?

Nicht direkt, nein. Antwort siehe unten.

Ich kann also meine 4 GB ausnutzen wie ich will, kreuz und quer im Arbeitsspeicher rumschreiben und so weiter, ohne, dass ich damit einem anderen Prozess in die Quere komme? Und ebenso kann ich auch gefahrlos in zu kleine Speicherbuffer schreiben?

Nein, du kannst niemals gefahrlos in zu kleine Speicherbuffer schreiben!
Die Sache ist die, das du zwar die 4GB zur Verfügung hast, wobei eigentlich nur 2GB davon zur freien Verfügung stehen. Aber du trotzdem erstemal bei Windows Speicherbereiche innerhalb dieses virtuellen Speichers beantragen musst. Das nennt man allozieren. Dabei wird festgelegt wie groß eine bestimmte Speicherregion sein soll und welche Zugriffsrechte sie haben soll. Nun ist die Sache aber so das Windows immer nur ganze Speicherseiten alloziert, so wie ich das verstanden habe. Das heisst, selbst wenn du nur 1 Byte beantragst, wird die neue Speicherregion mindestenz eine Speicherseite groß. Da kannst du dann natürlich auch reinkritzeln, ist aber unsauber, unsauber und nochmals unsauber sowas zu machen.

Könnte ich dann nicht auch gleich 1 GB Arbeitsspeicher reservieren und diesen Memory mit Offsets in kleine Bereiche aufteilen, sodass ich z. B. einen sich selbst vergrößernden Network-Empfangsbuffer (siehe Thread) erstellen kann? Und das Danke der Offset-Methode möglichst einfach?

Hm, naja ich denke das die 1GB gleich auf realen Speicher + Swap-File gemappt werden, nach dem allozieren. In dem Fall würdest du 1GB Speicher verbraten.