[C++] Geheugen adres veranderd steeds

[anoniem]

Ik heb hier een code voor een programma dat een waarde uit een bepaald adres leest, het werkt prima. Maar nu is het de bedoeling iets uit het geheugen van een spel te lezen (het health), met t-search vind ik dat het adres, maar als ik het spel weer uit doe en weer opstart is het adres weer veranderd van het health. Dus is er een manier om daar iets aan te doen, om elke keer dat ik het spel opstart het programmaatje gewoon het health uit een adres kan lezen? Bvd Btw, dit is de code nog ;). [code:1:d0b7cb04f8]#include <windows.h> #include <iostream> using namespace std; int main() { STARTUPINFO si; PROCESS_INFORMATION pi; ZeroMemory (&si, sizeof(si)); si.cb=sizeof (si); if (! CreateProcess( "spel.exe", 0, // command line 0, // process attributes 0, // thread attributes 0, // inherit handles CREATE_NEW_CONSOLE, // creation flags 0, // environment 0, // cwd &si, &pi ) ) { cout << "Kan het process niet starten!\a" << endl; } cout << "Druk op enter!\n"; int buf; int addr = 124213; DWORD dummy; if (! ReadProcessMemory( pi.hProcess, (void*) addr, (void*) &buf, 4, &dummy) ) { cout << "Fout tijdens lezen van het geheugen adres!" << endl; } cout << buf << endl; cin.get(); WaitForSingleObject(pi.hProcess,INFINITE); return 0; } [/code:1:d0b7cb04f8]

[anoniem]

Nee

[anoniem]

Raar, want er zijn bvb ook trainers voor het spel, en daarmee kun je ook het health aflezen. Hoe kan dat dan :-? .

[anoniem]

Ik had ook iets gelezen, als je dat spel vanaf dat programma opent dat je voor het starten iets met de offsets kan veranderen. Weet iemand daar iets meer over?

[anoniem]

Je probleem zit er in dat iedere keer dat je je spel start, het op een andere plaats in het geheugen wordt geladen. Als die 'health' ergens 'tussen' de programma code staat, zal die dus ook telkens op een andere plaats staan. Je OS bepaalt die plek voor je. Je zult moeten zien uit te vinden waar het programma geladen is. Dan bepaal je waar de info staat die je wilt hebben. Het verschil is waarschijnlijk wat met [i:7cfed73c3e]offset[/i:7cfed73c3e] bedoeld wordt. Om wat voor spel gaat het overigens? Of mogen we dat niet weten. Of het allemaal kan, weet ik niet; heb er geen ervaring mee.

[anoniem]

Het zal wel kloppen wat je zegt, maar ik vind het vreemd. Want bvb het aantal kogels van een bepaald wapen staat altijd in hetzelfde adres (heb het op 4 computers uitgetest), en het health veranderd steeds.

[anoniem]

Je probeert een trainer / cheater te maken voor een spel? ;) Kan wel hoor, maar je zult dan eerst het geheugenadres van het proces moeten opvragen waar het spel gestart is (zijn windows API calls voor). Als je vervolgens de lay-out van het geheugengebied weet, dan kun je bij dat adres de offsets optellen van attributen die je weet, zoals b.v. de health. Uiteraard wil jij die waarde veranderen, want je probeert unlimited health handmatig in te stellen. In dat geheugengebeid zul je dan vervolgens de juiste hex-waarde moeten zetten. Ik weet niet hoe andere trainers dit doen, maar ik denk dat Windows niet toestaat dat een proces in het geheugengebied van een ander proces gaat schrijven (memory protection). Daar zul je dan even wat meer info over moeten lezen. edit: ik lees net dat je het spel(proces) zelf ook opstart. Dan mag je er misschien bij :)

[anoniem]

Er is een mogelijkheid die je toe kan passen die gewoon neerkomt op het injecteren van een DLL in de process-space van het spel. In dat geval krijg je toegang tot het gehele proces en dus ook het geheugen van het spel. Het eerste wat je zult moeten bepalen is in welk geheugengebied het spel initieel data opslaat. Het zogenaamde data-segment. Relatief vanaf het begin van dit data-segment zal dan ook de score en andere gegevens worden bijgehouden. Je zult even moeten uitzoeken hoe je deze positie exact bepaald want het kan zijn dat niet de score maar een pointer naar de score in het data-segment wordt opgeslagen. Of erger, een pointer naar een pointer naar een pointer naar ...etc... Een goede trainer weet dit vrij eenvoudig te bepalen omdat de makers van de trainers niet alleen het geheugen inspecteren maar ook de struktuur kennen van hoe de gegevens worden opgeslagen. En dat laatste is dus vrij belangrijk.

[anoniem]

Ok, ik zal zoeken naar die API calls. Maar van bvb de kogels is het adres steeds het zelfde en met Writeprocessmeory kan ik ook gewoon in het geheugen schrijven. Maar hoe bedoel je, het injecteren van een DLL bestand ( dat programmaatje waar het mee kan wat bestaat zet ook een dll bestand in de map van het spel neer ). Maar bedankt, ik zal zoeken! :P Btw, het is niet echt een trainer (soort van ;) )

[anoniem]

Ok, ik ben nu bezig met een tutorial te lezen over DLL injection :P, ik hoop dat ik er wat wijzer van word ;).

[anoniem]

Kwam dit een paar dagen terug tegen: http://codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767/ 3 manieren om code te injecteren.

[anoniem]

Thnx :) , ik zal hem morgen gaan lezen.

[anoniem]

Met welke API Calls, kun je het geheugenadres van een proces opvragen? :oops:

[anoniem]

Niet zo vreemd hoor dat het adres elke keer kan veranderen. Bijvoorbeeld: myAddres = LocalAlloc(LPTR,8); Het maakt tijdens de ontwikkeling helemaal niet uit of het adres altijd hetzelfde is of constant veranderd.

[anoniem]

Foutje :oops:

[anoniem]

Huh, kun je met die functie zien wat het begin adres is van een ander proces :-? .

[anoniem]

Iemand misschien :), ik hoef alleen die api call te weten ;).

[anoniem]

Iemand? :(

[anoniem]

Met Delphi kan je gewoon kijken naar de .caption (text/label) van een/dat object. Dat moet in C++ toch ook wel kunnen? Lijkt me wat makkelijker, heb je gelijk geen gedoe met geheugen e.d....

[anoniem]

[quote:19a7352ca5="turbo-pascal"]Met Delphi kan je gewoon kijken naar de .caption (text/label) van een/dat object. Dat moet in C++ toch ook wel kunnen? Lijkt me wat makkelijker, heb je gelijk geen gedoe met geheugen e.d....[/quote:19a7352ca5] Het probleem is dat je zulke truuks alleen bij je eigen programma kan doen omdat je dan alle benodigde type-informatie weet/kunt achterhalen. De enige manier om bij een 'vreemd' programma makkelijk informatie te achterhalen is als je weet hoet het werkt (en welke taal gebruikt is, want dat kan verschil uit maken). In theorie zou je ook kunnen proberen om het programma te debuggen, maar dan ben je afhankelijk van het feit of het programma debug-info bevat of je moet heel goed assembly kunnen lezen ...