Addresswerte aus anderen Prozessen auslesen und verwenden
-
Also, der Wert den ich angezeigt haben möchte ist eine normale integer Zahl (in meinem Fall: 1631), die zugehörige Addresse ist laut CheatEngine: 05BDBE35
eingesetzt im Code sieht es dann so aus:
unsigned int wert; ::ReadProcessMemory(process, reinterpret_cast<void *> (05BDBE35), // Erwartet nämlich einen Zeiger auf void &wert, sizeof(wert), NULL);wenn ich jedoch compilen will kommt folgender Fehler:
invalid suffix "BDBE35" on integer constant
Wenn ich ein 0x davor mache also so:
unsigned int wert; ::ReadProcessMemory(process, reinterpret_cast<void *> (0x05BDBE35), // Erwartet nämlich einen Zeiger auf void &wert, sizeof(wert), NULL);geht es zwar zum compilen wenn ich dann jedoch den Wert
&wert ausgebe kommt eine komplett falsche Zahl heraus.
-
"&" ist in diesem Falle der Adressoperator. Also ohne "&"...
-
hab beides ausgegeben, also mit &wert und nur wert aber bei beidem kommt was komplett falsches raus und nicht 1631.
(Das Spiel wurde in der Zwischenzeit nicht neu gestartet also die Addresse sollte noch stimmen)
-
Hum, sollte eigentlich gehen. Dann probier es mal so:
unsigned int wert(0); unsigned int adress(0x05BDBE35); ::ReadProcessMemory(process, reinterpret_cast<void *> (adress), // Erwartet nämlich einen Zeiger auf void &wert, sizeof(wert), NULL);
-
hm... will immernoch nicht so richtig, gibt nun 0 aus.
Die Variable Wert bleibt irgendwie immer gleich verändere ich hier
unsigned int wert(0);auf
unsigned int wert(5);wird auch 5 ausgegeben also irgendwie wird der Variable nicht der Wert zugeschrieben den sie bekommen sollte (in meinem Fall 1631)
hier mal der komplette code falls es von belangen sein sollte:
#include <cstdlib> #include <iostream> #include <windows.h> using namespace std; int main(int argc, char *argv[]) { HWND Diablo = FindWindow("Diablo II", NULL); ::DWORD process_ID; ::DWORD thread_ID = ::GetWindowThreadProcessId (Diablo, &process_ID); ::HANDLE process = ::OpenProcess (STANDARD_RIGHTS_REQUIRED | SYNCHRONIZE | 0xFFF, FALSE, process_ID); unsigned int wert(0); unsigned int adress(0x05BDBE35); ::ReadProcessMemory(process, reinterpret_cast<void *> (adress), &wert, sizeof(wert), NULL); if (Diablo){ cout<<"&wert"<<endl; cout<<&wert<<endl; cout<<endl; cout<<"wert"<<endl; cout<<wert<<endl; } else if(!Diablo) { cout<<"Spiel nicht aktiv"<<endl; } system("PAUSE"); return EXIT_SUCCESS; }edit: wenn ich einen Wert aus Minesweeper auslesen lassen will klappt das komischerweise
(eben pobiert)
-
Wieso eigentlich dauernd diese führenden Scope-Operatoren?
::DWORDbringt hier nichts,DWORDtuts genauso. Den globalen Namensraum spezifiziert man eigentlich nur explizit, wenn im aktuellen Namensraum ein gleicher Bezeichner auftritt, oder wenn zumindest ein Verdacht auf Namenskonflikte vorliegt.
-
Du kannst prüfen ob es irgendwo gecrasht ist:
if(ReadProcessMemory(...)) std::cout<<"Success: "; else GetLastError();
-
Kóyaánasqatsi schrieb:
Du kannst prüfen ob es irgendwo gecrasht ist:
if(ReadProcessMemory(...)) std::cout<<"Success: "; else GetLastError();Danke
also es wird aufjedenfall der Teil der Else schleife wiedergeben, nur hab kapier ich das GetLastError(); nicht so ganz ,dass zeigt ja so wie s dasteht nichts an oder?
habs umgeschrieben in cout<<GetLastError(); dann gibt es mir den Wert 6 aus.
6 laut http://msdn.microsoft.com/en-us/library/ms681382(VS.85).aspx bedeutet ungültiges Handle

nur inwiefern soll das Window Handle ungültig sein? Es wird aufjedenfall ein Handle gesetzt denn ich kann mir eines ausgeben lassen mit cout<<Diablo<<endl;
-
Hehe... dann mach mal:
SetLastError(GetLastError);Ansonsten lies mal die MSDN.
-
Kóyaánasqatsi schrieb:
Hehe... dann mach mal:
SetLastError(GetLastError);Ansonsten lies mal die MSDN.
Ja was der Fehlercode 6 bedeutet habe ich nun aus der MSDN schon rausgelesen
(habs oben editiert)Ist denn mein Weg an das HWND zu kommen falsch oder wie kann es sein ,dass das handle als "Falsch" angesehen wird?
HWND Diablo = FindWindow("Diablo II", NULL);
-
const ::HWND Diablo(::FindWindow(NULL, TEXT("Diablo II")));
-
Kóyaánasqatsi schrieb:
const ::HWND Diablo(::FindWindow(NULL, TEXT("Diablo II")));gibt den gleichen Fehler aus.
Seltsamerweise kann ich dem Fenster aber Problemlos Befehle Senden mit SendMessage();.
-
Ok, dann wird es wohl daran liegen das du keine Rechte hast. Ist meistens bei Online und/oder Multiplayerspielen so.
-
Kóyaánasqatsi schrieb:
Ok, dann wird es wohl daran liegen das du keine Rechte hast. Ist meistens bei Online und/oder Multiplayerspielen so.
hmm... wie kann man denn trotzdem werte auslesen? Also wirklich nur ablesen nichts umschreiben sondern nur ablesen.
Cheatengine oder Tsearch zb liest ja auch den Wert ab.
Tut mir leid für die vielen "dummen" Fragen , bin jedoch sehr interessiert

edit: hab da glaub was verwechselt, der Fehler erscheint ja wegen dem process handle und nicht wegen dem Window handle oder?
Denn das window handle wird ja garnicht benötigt bei readmemoryprocess sondern nur das process handle. Scheint wohl da etwas nicht zu stimmen .
-
Habs nun zum laufen gebracht mit:
bool EnableDebugPrivilege() { TOKEN_PRIVILEGES priv; HANDLE hThis, hToken; LUID luid; hThis = GetCurrentProcess(); OpenProcessToken(hThis, TOKEN_ADJUST_PRIVILEGES, &hToken); LookupPrivilegeValue(0, "seDebugPrivilege", &luid); priv.PrivilegeCount = 1; priv.Privileges[0].Luid = luid; priv.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED; AdjustTokenPrivileges(hToken, false, &priv, 0, 0, 0); CloseHandle(hToken); CloseHandle(hThis); return true; }klappt auch alles wunderbar, nur jedes 2te oder 3te mal kommt die fehlermeldung beim compiler:
Permission denied
ld returned 1 exit statusund dann wenn ich den compiler neustarte gehts auf einmal ohne ,dass ich etwas am sourcecode verändere.
-
dann nimmst du jz einfach den quellcode und postest im winapi forum mal dein problem und die können dir bestimmt weiterhelfen... klingt doch vernünftig, im richtigen forum zu posten, oder!?
im übrigen kann vermutlich jede fkt, die du aufrufst irgend nen fehlercode zurückgeben - du testest nicht einmal darauf... nen paar kommentare könntest du auch da rein bauen - aber vll verstehen die winapi geeks es auch so ;o)
also, bye^^