ReadProcessMemory() im eigenen Prozessraum?



  • Hallo!

    Ich frage mich ob im eigenen Prozessraum ReadProcessMemory() nötig ist oder ob man einfach Zeiger dereferenzieren kann.
    Allerdings geht es mir bei der Frage genauer um einen fremden Prozess in welchen ich meinen Code einschleuse.

    Muss dieser Code dann mit ReadProcessMemory() arbeiten oder kann ich einfach Zeiger auf Adressen anlegen wo ich weiß was drin steht und dann dereferenzieren um den Wert zu lesen?

    Es geht jetzt mal nur um's Lesen, beim Schreiben bin ich mir ziemlich sicher dass ich WriteProcessMemory() verwenden sollte (Multithread issues, ...).

    Danke!
    MfG


  • Mod

    Du hast Dir die Frage selbst beantwortet:

    um einen fremden Prozess in welchen ich meinen Code einschleuse

    Lerne erstmal was über Prozesse, Threads und Speicheraufteilung des Windows OS, bevor Du solche Fragen stellst...



  • Dazu bleibt mir momentan leider keine Zeit.
    Ich gehe nun davon aus dass ich einfach per Zeiger zugreifen kann. Ist auch naheliegend...
    MfG


  • Mod

    Frage10 schrieb:

    Dazu bleibt mir momentan leider keine Zeit.

    Die Antwort ist unsinnig.
    Es macht wenig Sinn drauf los zu programmieren und keine Ahnung zu haben wie die Technik eigentlich geht. In 99% aller Fälle spart es Zeit sich vor dem Programmieren mit Technik und Wissen auszustatten.
    Aber mich wundert nichts mehr...



  • dito, mich wundert hier auch gar nichts mehr.



  • 1. Jeder Prozess hat zumindest unter Windows einen eigenen Speicherraum.
    2. Also kannst du auch darauf schließen dass du der Funktion ReadProcessMemory einen Pointer übergeben kannst um aus dem Prozess, dessen Handle du übergibst, x Bytes ab dem pointer zu lesen.

    http://msdn.microsoft.com/en-us/library/ms680553(VS.85).aspx



  • Du hast die Frage wohl nicht verstanden.



  • Die Frage ist ja auch hohl wie Blumenkohl



  • Frage10 schrieb:

    Du hast die Frage wohl nicht verstanden.

    Alles , was in dem Speichbereich deines Prozesses liegt, kannst du mit Pointern ansprechen. Dazu sind sie ja da.



  • Ja stimmt, war wohl etwas übervorsichtig, so wie immer 🙄



  • wenn du deinen code einschleusen willst und der dann auf deinen prozess zugreifen
    will, musst du ReadProcessMemory nehmen, da der code ja jetzt im prozessraum
    den anderen prozesses liegt 😉



  • moep: die Frage bezog sich, glaub ich, auf den eingeschleusten Code.

    Allerdings freu' ich mich schon auf das tolle Programm.... Wahrscheinlich is deine Zeit einfach wertvoller als meine.



  • Nein, nochmal, genauer...

    Eine DLL wird in einen Prozessraum gemapped, muss der Code der DLL dann ReadProcessMemory() verwenden weil in eben diesem fremden Prozess gerade ein anderer Thread auf den Speicher schreiben könnte...
    Kenne mich mit der tieferen Materie nicht so gut aus, wieviele Zyklen das jetzt braucht, ob mein Code dann Hälfte/Hälfte alten/neuen Wert auslesen würde zB und RPM() verhindert es weil es wartet und atomic ist.. kA

    Gibt's ein gutes Buch über all so Dinge?



  • der Prozeß ist ja nun nicht mehr fremd 🙂

    Die einzige Aufgabe von RPM ist, Speicher aus einem anderen Prozeß zu lesen. Wenn dein DLL in dem fraglichen Prozeß ausgeführt wird, brauchst du's nicht.

    So, und jetzt guck' Dir bitte Speicherverwaltung und Ressourcen unter Windows an.



  • Ja aber... du hast meine Frage nicht wirklich beantwortet und die hat glaube ich nix mit Speicherverwaltung zu tun...
    Der Prozess ist insofern noch "fremd" da ich keine Kontrolle über die anderen Threads habe und die auf den Speicher schreiben könnten während ich lesen möchte...

    Wenn ich zB. 1MB Speicher lese, und knapp vor dem Lesen ein Thread beginnt diesen Speicher zu überschreiben, habe ich dann doch Teils neue Werte, teils alte Werte?!
    Verhindert RPM() dies nicht?

    MfG



  • man wie oft denn noch, DAS EINE HAT NIX MIT DEM ANDEREN ZU TUN. WENN DU EINEN SPEICHERBEREICH HAST, DEN MEHRERE THREADS POTENTIAL GLEICHZEITIG SCHREIBEN KÖNNEN, MUSST DU ENTSPRECHENDE SYNCHRONISATIONS PRIMITIVEN BENUTZEN, UM DIES ZU KOORDINIEREN. DAS IST ABER IN DEINEM EIGENEN PROZESS GENAU DAS GLEICHE. WAS SOLL HIERBEI ReadProcessMemory BRINGEN??!??! LIES HALT MAL DIE MSDN ANSTELLE UNS NOCH 10 SEITEN MIT MÜLL ZU NERVEN. ICH HAB DEINE FRAGE VERSTANDEN BTW.



  • Frage10 schrieb:

    Gibt's ein gutes Buch über all so Dinge?

    ja.
    Windows Via C/C++ | ISBN: 0735624240



  • asdca schrieb:

    WENN DU EINEN SPEICHERBEREICH HAST, DEN MEHRERE THREADS POTENTIAL GLEICHZEITIG SCHREIBEN KÖNNEN, MUSST DU ENTSPRECHENDE SYNCHRONISATIONS PRIMITIVEN BENUTZEN, UM DIES ZU KOORDINIEREN.

    Kann ich aber nicht, da es wiegesagt ein fremder Prozess ist in den ich eine DLL einbette. Ich hab doch nicht die critical section Objekte oder sonstwas von der fremden Anwendung, somit kann ich nicht synchronisieren.



  • Frage10 schrieb:

    Kann ich aber nicht, da es wiegesagt ein fremder Prozess ist in den ich eine DLL einbette. Ich hab doch nicht die critical section Objekte oder sonstwas von der fremden Anwendung, somit kann ich nicht synchronisieren.

    Man kann Threads schlafen legen. Wenn alle schlafen, kann dir niemand über die Daten schreiben, ist doch ne gute Synchronisation 🙂



  • ReadProcessMemory führt keine Synchronisation durch. Punkt.

    SuspendThread ist (fast) überhaupt keine Synchronisation - dir pfuscht zwar keiner mehr zwischenrein, aber da Du nicht weist wann Du den Thread schlafenlegst, kann sich im Speicher inkonsistenter Müll befinden.


Anmelden zum Antworten