Comments & Questions

[IlyaZ]

Comments:
This tool has great potential and can easily be the best, but there are a few things I would like to comment on:

1. I've got two screens. I can't move the address window to the second screen (not that it matters).

2. I miss the feature that lets you select multiple addresses at a time and set their values to the same at the same time. Like Freeze all. Or delete all.

3. When I attach the debugger and put a read breakpoint games sometimes crash. This is the case for CheatEngine too, but T-search seems to have no problems.

Question:
I got no experience with floating point asm operations, but want to create a teleporter. Here's what I've got:

Original:
66BD66 fld [eax+24]
66BD69 fstp [ecx+24] //[ecx+24] contains the X Coord. Shouldn't eax+24 contain it too?
66BD6C fld [eax+28]

->
Jump:
66BD69 jmp 8f5a6f
66BD6E nop

Code Cave:
8F5A6F fstp [8f5aa0] //Store X Coord at a static pos
8F5A75 push ecx
8F5A76 add ecx, 24
8F5A79 mov ecx, [8F5AA0] //get the fstp [ecx+24] effect back
8F5A7F pop ecx
8F5A80 fld [eax+28] //Restored this
8F5A83 jmp 0066bd6e

The game crashes or closes upon me when I change this. I don't think I have altered any values or registers. I just write a reg to a static mem addy.

[L. Spiro]

I've got two screens. I can't move the address window to the second screen (not that it matters).

I don’t know how to fix this.

I miss the feature that lets you select multiple addresses at a time and set their values to the same at the same time. Like Freeze all. Or delete all.

Select the values you want to modify, right-click them and Modify them. Set the value to whatever you want. Refer to the help file in Demo #19.3.

When I attach the debugger and put a read breakpoint games sometimes crash. This is the case for CheatEngine too, but T-search seems to have no problems.

Use hardware read breakpoints.

The game crashes or closes upon me when I change this. I don't think I have altered any values or registers. I just write a reg to a static mem addy.

The Injection suite in MHS handles most of this for you, in regards to the miscellaneous JMP’ing and copying overwritten instructions. This ensures safety within the redundant operations to allow you to focus on the other things that could go wrong.

I am pretty sure all you wanted to do was:
FST [8F5AA0]

Open the MHS Disassembler.
Click (turns grey) address 0x0066BD69.
Right-click the Disassembler (will make these one operation soon).
Select Inject Code.
If you have a specific code cave you want to use (0x008F5A6F) you can use that, or allow the software to find one for you.
Check “Place Overwritten At End”.
Enter FST [8F5AA0] into the ASM area.
Done.



Educational
FSTP pops from the FPU stack.
You want FST to avoid modifying the floating-point stack (currently not shown in my software but will be soon). P indicates “pop”.

If I understand the intentions behind your code correctly, you were trying to replicate the PUSH effect caused by FLD by pushing ECX, etc.
This won’t work. You are modifying the wrong stack.
Also in this case you are taking the value from [8F5AA0] and storing it into ECX. The very next instruction overwrites ECX, making the whole section of code meaningless, since both the stack and ECX are all what they were before.

Ultimately, because you popped from the FPU stack but didn’t push back onto it (which would be a waste of instructions anyway since you can use FST), the stack was unaligned and the game will crash.

Refer to the help file in Demo #19.3 for information regarding the Injection Manager, under the topic Tools/Injection Manager.


L. Spiro

[IlyaZ]

There are probs with hardware breakpoints. I've got x64 Windows and usually things don't break at all then. Got x86 too but I don't put games there, might do an exception though.

Well, I basically want to copy the top stack value to a location, like with fst. But I also want to make it read from that addy and change it.

The idea: I write the Z coord to a static addy. Then I read it from a trainer, user change the coord = writes to the addy, game then reads from the same addy and updates coord.

Also in this case you are taking the value from [8F5AA0] and storing it into ECX. The very next instruction overwrites ECX, making the whole section of code meaningless, since both the stack and ECX are all what they were before.

Crap, that's true.

[L. Spiro]

Only x86 is officially supported as that is what I have.
So for hardware breakpoints and software crashes, there is really no way I can help.
In fact I am amazed hardware breakpoints work at all on that version.

But I also want to make it read from that addy and change it.

The idea: I write the Z coord to a static addy. Then I read it from a trainer, user change the coord = writes to the addy, game then reads from the same addy and updates coord.

You won’t be able to create such a complicated system this way; they would both be overwriting each other, probably causing a lot of jitter.

You don’t need to store the coordinate to a static address at all.
If your trainer is going to modify it every time that code is executed, send it to the trainer directly and put the modified value onto the stack.

The easiest way is to modify the value before it is even pushed onto the stack.
At address 0x0066BD66, you should get the value at EAX+24, modify it in the trainer, and write the new value back to EAX+24.
You don’t have to modify the FPU stack at all.





Just a note, MHS can do all of this too.
Typically you would want to use a script breakpoint handler for this so you can test your theories before trying to make a stand-alone .EXE trainer, which, needless to say, would require its own attaching mechanism, debugger, and code project.

In the scripts you would have to write a handler function, which works exactly the same way as hotkey handlers. Here is an example:

Code: Select all

VOID On_BP_1( LPVOID lpvAddress, LPPROC_INFO_MHS lpProcInfo ) {
    extern FLOAT e_fThis = { "", lpProcInfo->pcContext->Eax + 0x24 };
    // Modify the float value however we please.
    e_fThis = 90.0f;
}

Then set an execute (software) breakpoint on address 0x0066BD66 and set the Callback as this:
Script Function Parm: 1

The parameter 1 indicates that when the breakpoint is hit, it will call your script function On_BP_1().
So if you set Parm to 2 you would have to write On_BP_2() in the script, etc.



What will happen:
The execute breakpoint at 0x0066BD66 will be hit.
The breakpoint will call the Prolog function, but it is not set so nothing will happen.
Then the breakpoint will call the Callback function. This is set to Script Function so it will take the Parm value (1) and call the script function determined by the Parm (On_BP_1).
Inside your On_BP_1() function you create an “extern” variable as a FLOAT type at address EAX+24 inside the target process. After the extern variable is declared, modifying it will change the data in the target process, so when we set it to 90.0f we are actually writing 90.0f into the target process (at address EAX+24).
The target process will resume after the script function returns.
At this point, it will execute the real code at address 0x0066BD66, which reads the value from EAX+24 and stores it into the FPU stack. This value was modified by us already, so our modified value is now being used by the game as if it was the original value.


L. Spiro

[IlyaZ]

I've used that mem method successfully a few times, but might have worked due to the fact that the games were turn-based.

However, I don't have to read and update the value all the time. Just when I press an OK/Refresh button.

fld [eax+24]
...
fstp [8f5aa0]
add ecx, 24
mov ecx, [8F5AA0]
sub ecx, 24
fld [eax+28]
jmp 0066bd6e
...
fstp [ecx+28] etc (forgot to add this line before)

I'll try your tip about not messing with the float stack, but made a quick fix now. It still doesn't work properly but I hope the idea is a bit more clear now.

Adding a debugger and an attaching mechanism to the trainer would make it a huge complicated project. Seems a bit unconventional.
But yea that might be a solution.

The scripts you are talking about, shoud they be written MHS somewhere?

And thanks for your text!

[L. Spiro]

The script is written in the scripts.

Tools/Script Editor.


L. Spiro

[IlyaZ]

I managed to make the stuff work. ASM code was faulty. But I got a new problem. MHS "crashes" the game (after 10 secs or so) when I attach it to the process. Didn't happen before.

The game closes itself. But the process is still left in mem. And when I try to attach the debugger it says the process might have antidebug features. But it has worked all the time until now?

[L. Spiro]

What version are you using?
You should be using Demo #19.3, which never reports anti-debug problems.

Since you say you get that message, it means you are using an old version of Memory Hacking Software.


As for that message and the things that are different.
The message means something is already debugging the process. You can’t debug with two versions at once, or with any other software. One debugger at a time, law by Windows®.

As for crashing the game at start-up, you should check Tools/Injections and remove any that are incorrect.


L. Spiro

[IlyaZ]

I'm using version 3.0.1.4 .
Downloaded #19.3 now.

Yes, looks like the program crashed due to some code in the tools/injections window.

Anyway now I got a problem with poking lol.
If I write my ASM code manually everything works. But as soon as I poke my addys from my trainer (they are correct, I compared the opcodes), the program crashes. When I try to poke the opcodes to the code cave they aren't inserted there, only the jump opcodes (to the cave) change.

I poke the code cave first, then the jump.

Could it depend on the memory protection of my code cave? The Poke function i use has been used for all other trainers I've made and should be working fine.

[L. Spiro]

If you are allocating a code cave it must be allocated to the same address every time, which you can’t ensure so you can’t use it for trainers.
The code cave used with trainers must either be manually defined at a specific address guaranteed to always be there or found with the auto-find feature which will select a location that is guaranteed to always be the same.

For best results you should be copying from the bottom of the code injector; it already gives you the exact bytes to copy along with a Poke command made for Trainer Maker Kit. Naturally, you don’t have to use that exact format for your needs but you can still copy the address and exact bytes to avoid errors.


L. Spiro

[IlyaZ]

No no, I'm not allocating a code cave. There are big code caves there already.

I'm quite sure the code is equal to what I got in the bottom of the code injector. But I'll try it once more.

Edit:
I scan for code caves. Then I find one and try to push things to it. It doesn't work. It works only if I write the ASM manually through MHS.

Then I try another which is in another memory region and it works. Could it be because of this? Is it possible to change read/write/exe for a mem region?

[L. Spiro]

VirtualProtectEx() changes read/write privilages for a region.
You have to have the correct access rights when you open the process with OpenProcess().
And MHS has debug privilages on a systemwide level, allowing it full access to all programs.


L. Spiro

[IlyaZ]

Ok, so what kind of privileges do I need?

-Write
so I can poke.
-Read
if I want to read (and write) static addy values.

But wouldn't execute too be needed if I want to run the code? Now it looks like it works without execute anyway, but good to know.

[L. Spiro]

Execute does not give privilages to execute code inside the process. Write does, by writing the code into the process.


Just use all privilages, with a minimum of read and write.


L. Spiro

[IlyaZ]

Ok, got another question.

"xlateobj" addresses are called something like xlateobj_ixlate+f63e

According to MSDN it's somethign that has to do with a color palette?? If I enter code there it works on my comp but not elsewhere. I'm quite sure I need another code cave location but just didn't expect that.