Code Help

[live2play]

The following assembly is used to get Infinite Health in a game.  I can understand the program flow, but what I'm not able to understand is why the write of 46D00000 at 813B4C54 [156(r30)] has to be done in order for infinite health to continue to work.  Watching the value at 813B4C54 using Memory Viewer with "auto update" turned on reveals that the value never changes from whatever value is initially written there.  It seems that the 46D00000 value that is written the first time is not overwritten by any other value during gameplay.  However, if I nop the instruction at 817C3E04 below, infinite health is no longer active.  Why is it that the value at that memory address has to be continually written even though it is not being change once it is intially set?

800085B0:  497BB851   bl   0x817c3e00

817C3E00:  3D6046D0   lis   r11,18128
817C3E04:  917E009C   stw   r11,156(r30)
817C3E08:  819E0010   lwz   r12,16(r30)
817C3E0C:  4E800020   blr

[dcx2]

It could be changing, but it is changed for such a brief period of time that Memory Viewer doesn't show you that it changed.  Set an execute breakpoint on 800085B0.  See when this instruction is executed; it may run every frame, or only when you get hit.  It's probably over-writing the current health value with the full health value.

46D00000 is over 26,000 as a float, and 46D0 is over 18,000 as an integer, so none of those seem like health values...

[live2play]

A breakpoint at 800085B0 is triggered as soon as I set it.

Ok, so the "auto update" feature in Memory Viewer may not always show when a value changes?

[wiiztec]

A value doesn't have to change just because it is being written to, It could simply be writing the same value to that address every frame

[dcx2]

If the execute breakpoint hits every frame, then it's writing the full health value every frame.  It's behaving kinda like an 04-write code, except it's hooking an asm instruction so it has access to a hard-to-get pointer, which is in r30 at the hooked instruction.

This blr technique is dangerous.  You need to pick unused memory for your 07 codetype's destination, and not all asm functions need to push the LR on the stack so it's not always safe.  The C2 code is much easier, because the code handler deals with where to put your ASM and writing the appropriate branches.

Memory Viewer Auto Update only shows 12 frames per second or so.  The game runs at 30 frames per second.  There are plenty of chances to miss a piece of data as it changes from one frame to the next.  In fact, memory can be written to multiple times during the same frame.  The only way to not miss any changes is to use a write breakpoint.