CNWSCombatRound__StartCombatRound Possible issue with core API about unified HOT 2 CLOSED

.text:000FA5F7 E8 A4 8E F2 FF call sub_234A0

->

.plt.got:000234A0 FF A3 E0 01 00 00 jmp dword ptr [ebx+1E0h]

Crash because ebx+0x1E0 is null. Not sure why yet.

from unified.

So, GCC implements ASLR by:

1. Call __x86_get_pc_thunk_ax (ax replaced with the register) at the start of each function, which simply moves [esp+0] into the register above. esp+0 at the start of a function call is the return address. So - what it's doing here is capturing the address of the next instruction after where the call is.
2. Add a magic number to this value, depending on the function in question. The function I'm looking at adds 0x37177E, for example.
3. Generate thunks to call ASLRised functions - which takes the value above, and adds an offset, which equals the end function pointer. The crash I'm currently investigating adds the offset 0x1E0.
4. It now has the function pointer, and can call it.

This is usually fine for us - but some functions have the call to __x86_get_pc_thunk_ax within the first five bytes of the function. Because of that, the call actually happens in a different memory location - the trampoline - and [esp+0] returns the next instruction in the trampoline - meaning resolving the ASLR causes a crash (in the best case).

I'm going to try to fix this by attempting to detect calls to the thunks in the trampoline, and if detected, rewrite the call to move the correct value into the register in question instead.

from unified.