Hook relative jmp address overflow

[EaSy]

Hi again ,
we have discovered another rare issue in you code. This time it is located in the APIHook code.

This is a rare case that happens only on one of our physical testing machine W7 64b in sqlservr.exe from MSSQL from Microsoft. Luckily It crashes all the time, so I could exactly identify the issue.

We hook "NtQuerySystemInformation" on this 64b system. We call your API HookAPI with this function specified...

1] Among the first things you code does is a allocation of data for your stub routines.
The addres of "NtQuerySystemInformation" is 0x77681670, the address of your stub data is 0x27c000000, addres of InUseStub is then 0x27c010036.

alloc.png (22.67 KiB) Viewed 4749 times

2] Remember, we are on 64b system. You must compute the relative address. Since the relative size you use in here is only 32b, the result for relative jump is computed as a 0x4B8E9C0.

jmp.png (12.38 KiB) Viewed 4749 times

3]Here is the result. You can see that address is wrong:
base address is: 0x77681676 = 0x77681670 ("NtQuerySystemInformation" address) + 6 (jmp size)
offset is: 0x4B8E9C0
wrong result: 0x7C010036 = 0x77681676 + 0x4B8E9C0
right result: 0x27C010036 = 0x77681676 + 0x204B8E9C0

address.png (16.88 KiB) Viewed 4749 times

Your jmp code experienced an overflow, because "mpSparePage = VirtualAlloc2(2048, mpHookedFunction);" allocated too distant address (dunno why).
Application crashes once it calls hooked "NtQuerySystemInformation".

Thanks.
PP

EDIT: fixed title

[madshi]

This should definitely not happen. The 2nd parameter of the VirtualAlloc2() call tells VirtualAlloc2() where to allocate the new memory. Basically the call "VirtualAlloc2(2048, mpHookedFunction)" tells VirtualAlloc2() to allocate memory as near to "mpHookedFunction" as possible. It seems that this fails on your one PC for whatever reason. Would you mind stepping through VirtualAlloc2() to see why this fails? The only thing that would make sense to me is if sqlservr.exe had allocated (or reserved) all the memory from 0x80000000 up to 0x27bffffff. That would be kinda weird, though. Why would sqlservr.exe do that?

[EaSy]

Yes, it actually does.

screenshot.png (81.2 KiB) Viewed 4740 times

[madshi]

Argh. To be honest, I didn't expect THAT. Probably the proper solution in a case like this would be to search below the wanted address instead of above it. I'll look into that...

[madshi]

A quick fix is in here:

http://madshi.net/madCollectionBeta.exe (2.7.4.16)

I think it should work, but I haven't fully tested it. Basically the memory allocation is now tried above the needed address first, and if that fails (or is too far away), allocation is done instead below the needed address.