10.09.2012, 01:47
Das ist richtig...
Zu allererst müsstest Du z.B. am einfachsten mit Cheat Engine nachverfolgen ob die Daten so geschrieben wurden wie Du es beabsichtigt hast. Also der Jump zur Codecave und die Codecave selbst.
Ich denke mal das der Jump geschrieben wurde, aber je nachdem wo deine Codecave steht kann es natürlich sein das dein Trainer keine Schreib-/Zugriffsrechte auf diesen Speicherbereich hat. Vom Trainer selbst her würdest Du das wahrscheinlich nicht bemerken, aber mit einem Debugger oder eben dem Dissassembler von CE könntest Du z.B. nachvollziehen ob alles korrekt geschrieben ist.
Wenn das nicht der Fall ist, dann liegts eben daran das der Trainer die Daten zwar vermutlich schreibt diese aber nicht in den Prozess injeziert werden weil eben die Schreibrechte fehlen. Diese Schreibrechte kannst Du dir mit der API VirtualProtectEx zusichern.
[code=MSDN]BOOL WINAPI VirtualProtectEx(
_In_ HANDLE hProcess,
_In_ LPVOID lpAddress,
_In_ SIZE_T dwSize,
_In_ DWORD flNewProtect,
_Out_ PDWORD lpflOldProtect
);[/code]
Zu allererst müsstest Du z.B. am einfachsten mit Cheat Engine nachverfolgen ob die Daten so geschrieben wurden wie Du es beabsichtigt hast. Also der Jump zur Codecave und die Codecave selbst.
Ich denke mal das der Jump geschrieben wurde, aber je nachdem wo deine Codecave steht kann es natürlich sein das dein Trainer keine Schreib-/Zugriffsrechte auf diesen Speicherbereich hat. Vom Trainer selbst her würdest Du das wahrscheinlich nicht bemerken, aber mit einem Debugger oder eben dem Dissassembler von CE könntest Du z.B. nachvollziehen ob alles korrekt geschrieben ist.
Wenn das nicht der Fall ist, dann liegts eben daran das der Trainer die Daten zwar vermutlich schreibt diese aber nicht in den Prozess injeziert werden weil eben die Schreibrechte fehlen. Diese Schreibrechte kannst Du dir mit der API VirtualProtectEx zusichern.
[code=MSDN]BOOL WINAPI VirtualProtectEx(
_In_ HANDLE hProcess,
_In_ LPVOID lpAddress,
_In_ SIZE_T dwSize,
_In_ DWORD flNewProtect,
_Out_ PDWORD lpflOldProtect
);[/code]
Zitat:hProcess [in]
A handle to the process whose memory protection is to be changed. The handle must have the PROCESS_VM_OPERATION access right. For more information, see Process Security and Access Rights.
lpAddress [in]
A pointer to the base address of the region of pages whose access protection attributes are to be changed.
All pages in the specified region must be within the same reserved region allocated when calling the VirtualAlloc or VirtualAllocEx function using MEM_RESERVE. The pages cannot span adjacent reserved regions that were allocated by separate calls to VirtualAlloc or VirtualAllocEx using MEM_RESERVE.
dwSize [in]
The size of the region whose access protection attributes are changed, in bytes. The region of affected pages includes all pages containing one or more bytes in the range from the lpAddress parameter to (lpAddress+dwSize). This means that a 2-byte range straddling a page boundary causes the protection attributes of both pages to be changed.
flNewProtect [in]
The memory protection option. This parameter can be one of the memory protection constants.
This value must be compatible with the access protection specified for the pages using VirtualAlloc or VirtualAllocEx.
lpflOldProtect [out]
A pointer to a variable that receives the previous access protection of the first page in the specified region of pages. If this parameter is NULL or does not point to a valid variable, the function fails.
Irren ist menschlich. Aber wer richtigen Mist bauen will, braucht einen Computer !!!
Traineranfragen per PM werden prinzipiell gelöscht...
Traineranfragen per PM werden prinzipiell gelöscht...