Jump Height

[SKU]

Hello everyone

I just recently started getting into reverse engineering (although you might not wanna call it like that yet..) and was trying my luck on the 'jumping procedure' to track down the height one jumps.

I 'think' that I found the static address that holds the height, but I can't seem to patch it permanently..

0060EFD0   /$  8B81 B8000000     MOV EAX,DWORD PTR DS:[ECX+B8]
0060EFD6   |.  85C0              TEST EAX,EAX
0060EFD8   |.  74 0E             JE SHORT Wow.0060EFE8
0060EFDA   |.  8B40 28           MOV EAX,DWORD PTR DS:[EAX+28]
0060EFDD   |.  A8 04             TEST AL,4
0060EFDF   |.  75 07             JNZ SHORT Wow.0060EFE8
0060EFE1   |.  A9 00020000       TEST EAX,200
0060EFE6   |.  75 0C             JNZ SHORT Wow.0060EFF4
0060EFE8   |>  F741 40 00040000  TEST DWORD PTR DS:[ECX+40],400
0060EFEF   |.  75 03             JNZ SHORT Wow.0060EFF4
0060EFF1   |.  33C0              XOR EAX,EAX
0060EFF3   |.  C3                RETN
0060EFF4   |>  B8 01000000       MOV EAX,1
0060EFF9   \.  C3                RETN

As I said I'm new to this.. but I think this is the innermost function that handles jumping. Setting a breakpoint on it in Olly always causes it to pause as soon as I hit the space bar ingame.

Following back the code trying earlier breakpoints, i came along this line(s):

008D65B1   |.  F7C7 00002000     TEST EDI,200000
008D65B7       EB 08             JMP SHORT Wow.008D65C1
008D65B9   |.  D905 70829A00     FLD DWORD PTR DS:[9A8270]
008D65BF   |.  EB 06             JMP SHORT Wow.008D65C7
008D65C1   |>  D905 6C829A00     FLD DWORD PTR DS:[9A826C]
008D65C7   |>  51                PUSH ECX                                    ; /Arg1 = 0019FBA0
008D65C8   |.  8BCE              MOV ECX,ESI                                 ; |
008D65CA   |.  D91C24            FSTP DWORD PTR SS:[ESP]                     ; |
008D65CD   |.  E8 4EFDFFFF       CALL Wow.008D6320                           ; \Wow.008D6320

Or more specific: this single line:

008D65C1   |>  D905 6C829A00     FLD DWORD PTR DS:[9A826C]

In the Hex Dump, (again, I think..) the address 009A826C holds the height.

To be more exact: [009A826C]=-7.955547 (hex: D8 93 FE C0)

So.. I tried my luck and modified the binary.. I changed the last byte to C1 instead of the normal C0, that leads to quite a change to the float (now being about -31.00f), changed back to WoW and was able to jump quite high.

Now the problem (again, new to this business..): I tried to patch this value via C#. So far I didn't have alot of trouble reading/writing to WoW and doing the 'beginner stuff'.

        private string ChangeJumpHeight()
        {
            IntPtr hProcess = Memory.OpenProcess(Memory.GetProcessIdByProcessName("Wow.exe"));
            Process.EnterDebugMode();
            if (hProcess != IntPtr.Zero)
            {
                Memory.WriteMemory(hProcess, 0x009A826F, 0xC1);
              //  Memory.WriteMemory(hProcess, 0x1F098987, 0xC1);
                byte _4 = Memory.ReadByte(hProcess, 0x009A826F);
                return "SUCCESS";
            }
            else
            {
                return "FAILED";
            }
        }

I'm just trying to patch the last byte of the float and after that immeadiately read it to see my changes.. where I fail, badly. The value seems to pop back instantly because im just reading 0xC0 again. (standard value).

I couldn't find any other references to this address, but found another address that holds the exact same value, no success there either. (the commented one)

(Thanks again Shynd for your great library btw.)

Any ideas how to patch the value permanently or an explanation why my way doesn't work and I suck so much at everything.

Thanks in advance.

[kynox]

In regards to your problem, not sure. However, i will warn you that Warden is actively scanning this offset and will ban you for tampering with it.

[Xarg0]

I'm pretty shure it's a page protection flag problem, the gravity value is stored as readonly so you'll have to change the memory protection flag with VirtualProtect, otherwise you can't write to it.
If you'd use exceptions in your Memory Class you could use try and catch to find errors like this faster, or if your writememory method already returns an error code you should check if the function succeeded and if it didn't post some information about the error.

[SKU]

Thanks for the fast answers and the warning.

As 'circumventing' Warden stuff is way over my head, i'll just leave it for now.

Best regards,
sku

[arigity]

that value is also stored in the player structure. and (as its dynamic) should not trigger warden if modified.

[SKU]

that value is also stored in the player structure. and (as its dynamic) should not trigger warden if modified.

Thanks for the information, I'll try to look into it.

[arigity]

the value in the offset will be 0 if you haven't jumped yet (since last login) and it resets to the value in 9A826C every time you jump (meaning you will either have to patch where the value is moved or repeatedly write to the address)

[SKU]

the value in the offset will be 0 if you haven't jumped yet (since last login) and it resets to the value in 9A826C every time you jump (meaning you will either have to patch where the value is moved or repeatedly write to the address)

Thanks again, I really appreciate it. I'll try my luck.

Update: Got it, thanks again.

uint locPlayer = GetPlayerObj(hProcess);
Memory.WriteMemory(hProcess, locPlayer + 0x877, 0xC1); // standard value = 0xC0

the 'private uint GetPlayerObj(IntPtr hPr)' returns the localObject (player address)

On a side note: As you already mentioned, it's getting 'patched back' by wow, so you actually have to jump and then immediately execute the WriteMemory which results in jumping (veeeery) high. Since I didn't have a better idea and I really wanted to test my finding, I just used a dirty timer with a fast intervall. Worked like a charm. This however doesn't bypass anything else like fall damage, so jumping too high ends up deadly.