Why is the game crashing when I use a compare opcode?

[Barking Sands]

I'm creating an injection copy script to check my filtering for Cruelty Squad (Godot engine x64):

Code: Select all

[ENABLE]
aobscanmodule(health,crueltysquad.exe,49 89 41 08 48 8B 5C 24 50)
alloc(newmemh,$30,health)
alloc(pointer,8)
label(injecth)
registersymbol(pointer)
registersymbol(health)

newmemh:
//  cmp [rbp+38],00000000000000FE  << Crashes the game immediately (I'm planning on adding jne +x but I'm still working on the next opcode)
  mov [pointer],r9 << Does nothing but return 0s but I can't use "movq" for some mysterious reason
  mov [r9+08],rax  << Original opcodes matching the AOB
  mov rbx,[rsp+50]
  jmp injecth

health:
  jmp newmemh
  nop 4
injecth:

[DISABLE]

health:
  db 49 89 41 08 48 8B 5C 24 50

unregistersymbol(pointer)
unregistersymbol(health)
dealloc(newmemh)
dealloc(pointer)

What am I doing wrong here? The game should be running business as usual except that a broken code (a link to a useful source regarding moving long hex base address values into a 8 byte symbol would help greatly). I tried using PUSHF and POPF to attempt to preserve the C and Z flags but I don't even know if those are the correct opcodes for a 64-bit compare function. A little help?

[DrummerIX]

Usually due to referencing invalid memory. This happens in functions that are shared and have different register values depending on what is calling it. In your example, there are probably cases where rbp is not pointing to the stack but contains some other value.

[Barking Sands]

That makes sense. I was just getting frustrated and didn't think that comparing with an invalid address would cause a crash. Is there a fix for this?

Something like:
"cmp rbp,1FFFFFFFFFFF
jae +x
cmp [rbp+38],FE
jne +y
mov [pointer],r9
etcetera"

I'm also wondering about that "mov [pointer],r9" opcode. Should I break that down into two opcodes that pull 4 bytes each, and if so, how do I pull just the top four bytes from a 64-bit register?

[DrummerIX]

Yeah, comparing it before using it is how you get around it.

The mov [pointer],r9 should be fine to use as is. If your pointer value always stays zero then you have to research your shared code again to find out when you really want to save it to the pointer variable.

[cfemen]

Well, don't even bother with register compare on Godot

Attached is table that will do the following things:
-Dump all objects(nodes) in current level
-Generate player/player-weapon/global-variables - it will generate a bigass list of pointers
-Dump all player functions ( name + pointer to the function object that is containing the script byte buffer )
-God mode example script

some notes:
all player related scripts will only activate if a level is loaded coz my script is getting the player at runtime, that means you need to reactivate them after each level.
you will see a ammo value inside the weapon struct that will not make any sense, the reason for that is that ammo is stored as a VariantArray( my dumper does only support Integers,Floats/Doubles and Strings, everything that is not detected will just show as 4 bytes )
VariantArray means the ammo is stored inside a array with an index for each weapon, I didn't bother to write something to read it out ... probably its possibly to search for the "consume ammo" function and then return it (like I did with the god example script ) but again : I didn't look at that!

Dumper tested on version v21.11.2021 (Godot 3.3)

So yeah thats it, its not a "ready 2 use" table, its just my personal Godot Dumper

The "Goal" on Godot is getting the Viewport, this allows to get all the objects(childrens of the viewport) that are loaded in the current level.
After that Im starting to find the names of the variables and functions, the names are stored inside a <string,int> map ( the int value of the map matches with the index from the vector<variant> that is storing the value )

How to get the Viewport:
A)String search for "bad dynamic_cast" to find the Dynamic_Cast function, Godot is calling this function often so you can easily set a breakpoint to catch all pointers that are returned,every object that is inheriting from Node has the Viewport pointer.

B)String search for "SceneTree" references and then do a 8 Byte Hex search for the function start address, if the result is green ( static ) then you found the vtable, subtract 0x30 and search again 8 Byte Hex = Instance of SceneTree that contains a pointer to the viewport.

C)Memory scan for ANY value, the found address is inside a vector<variant>, a variant is 0x18 byte sized and contains the type and the value, now try to find the first index of the vector.
(first index - 0x4 ) = size of the vector
do a 8 Byte Hex scan for the address of the first index and you will find the ScriptInstance.
ScriptInstance + 0x10 = Owner ( Any Node )

Viewport pointer offset inside a Node depends on the Godot version, every Node contains also:
-class name (vtable + 0x30 )
-node name
-script name ( if a script is attached)

The offsets for the node and script names are depending on the Godot version, but you can always figure out what you are looking at

Okay thats it, a short overview of "how to hack godot" ...Yes Godot is really not a easy Engine for Game-Hacking ...

[Barking Sands]

Thanks for the helpful post; now I'm glad I asked.

I might want your help working with lua (zero experience) to build a script that gives backup ammo instead of disabling the consume ammo function. I like the reloading sounds and mechanics in the game and want infinite ammo but when reloads are still necessary. Faster movement speed without using up the leg slot sounds appealing too (I think I can do that with just hotkeys).

Would it be possible to make every gun in the game able to damage armored enemies?