+- Sinisterly (https://sinister.ly)
+-- Forum: Coding (https://sinister.ly/Forum-Coding)
+--- Forum: C, C++, & Obj-C (https://sinister.ly/Forum-C-C-Obj-C)
+--- Thread: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) (/Thread-API-Hooking-Differing-across-APIs-NtQuerySystemInformation-Hook)
Pages:
1
2
API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - Rodaxoleaux the Lab Rat - 09-22-2012
Okay. So. I'm kind of doing what that first smiley on the left of this New Thread post is doing, banging his head against a brick wall. I'm working with an NtQuerySystemInformation hook to hide a process (Ring3 obviously. A fully fledged kernel driver isn't necessary for this project (yet.)) And I have gotten myself to understand API trampolines over a few hours of reading and looking at code. I've finally coded my own and it worked for hooking MessageBoxA. Everything went off without a hitch. Since the only thing we're doing is 'jmp'ing to a specific address, I really thought that it wouldn't matter what function I hook, so long as I do it. But here's what I'm talking about:
Code:
oNtQuerySystemInformation = (NTQSI_Type)GetProcAddress(GetModuleHandle(L"ntdll.dll"),"NtQuerySystemInformation");
if (oNtQuerySystemInformation != NULL)
{
BYTE tmpJMP[6] = {0xE9,0x00,0x00,0x00,0x00,0xC3}; //jmp,A,D,D,R,ret
memcpy(JMP,tmpJMP,6);
DWORD Addr = ((DWORD)func - (DWORD)oNtQuerySystemInformation - 5);
VirtualProtect((LPVOID)oNtQuerySystemInformation,6,PAGE_EXECUTE_READWRITE,&oldProtect);
memcpy(oldBytes,(LPVOID)oNtQuerySystemInformation,6);
memcpy(&JMP[1],&Addr,4);
if (!WriteProcessMemory(GetCurrentProcess(),oNtQuerySystemInformation,(LPCVOID)JMP,6,NULL))
std::cout << "Unable to write to process memory space" << std::endl;
//memcpy((LPVOID)oNtQuerySystemInformation,JMP,6);
VirtualProtect((LPVOID)oNtQuerySystemInformation,6,oldProtect,NULL);
return 0;
}
return 1;This works fine for a MessageBoxA function in a program built by me, but when I try hooking NtQSI, Process Hacker immediately crashes with a stack overflow error. Not sure why. Any ideas?
RE: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - Frooxius - 09-23-2012
Can you provide more information about the error? Where exactly does the stack overflow occur? Can you examine the stack at the point of stack overflow? If some data are pushed into it by mistake or if SP is changed inappropriatelly or maybe something else.
If I had to take a wild guess, it might be some security measure that prevents you from doing that on system libraries (have you tried any others?). Self modifying applications (even if it's writing just one instruction) can be suspicious.
What's "func"? Is a pointer to the function you're trying to jump to? And JMP is the address of the old jump instruction that you're overwritting? I think a larger chunk of code would be good too, as it's not entirely clear to me what it's this trying to do. May I also ask when and how is the overwritten JMP instruction executed?
RE: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - 1234hotmaster - 09-23-2012
Doesn't this... Move the process into memory rendering it invisible?...
RE: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - Rodaxoleaux the Lab Rat - 09-23-2012
Yes. I've tried it on user32.dll with MessageBoxA. No other important system libs. func is the location of the trampoline function. It fails when I write the jmp to the first 5 bytes of the original function. (I have changed it a bit. I removed the ret instruction at the end of the jmp.)
@hotmaster No. This hooks onto the function that things like the task manager use to enumerate processes running on the system. Its name is NtQuerySystemInformation.
RE: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - ArkPhaze - 09-24-2012
So you're trying to create a global hook on Windows process changes/events/etc...? Like a process watch(er)? Or hooking everything with NtQuerySystemInformation?
RE: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - Rodaxoleaux the Lab Rat - 09-24-2012
Here's what happens. Let's say I ran the task manager. It enumerates all processes by using the user-mode function Process32First/Process32Next. These and any other way of finding the processes running on a Windows computer go through NtQuerySystemInformation, a kernel mode function found in ntdll.dll. If I hook on to this function by writing an unconditional jmp to a hooked function that I created myself, and erase the entries containing the name of the process, that process will never reach NtQuerySystemInformation, and therefore, will not be seen.
RE: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - Frooxius - 09-24-2012
ArkPhaze: If I understand it correctly (he provided just a small snippet), he's trying to alter the behavior of NtQuerySystemInformation by making it bounce to his own code at some point (the JMP instruction) which will erase the information about the process he wants to hide (so when TaskManager queries all the processes from the system, the hook will "call" (not CALL call apparently) his code, which will make sure that his process isn't in the list, so the TaskManager doesn't display it.
However I think that it doesn't work simply because system prevents such changes (hence it causes stack overflow when he tried to overwrite the instruction data) for security reasons, so you might want to do this in ring 0 instead of ring 3. Basically that's how a rootkit behaves, it hooks and tampers with the results of various API functions to hide its presence.
Though stack trace would be still nice to provide, I don't understand why it would actually cause stack overflow, so it might be nice to see what's actually nice in the stack when it happens.
RE: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - Rodaxoleaux the Lab Rat - 09-24-2012
I just switched to MSVC so I'm a little confused as to how. I ran it through the debugger and didn't find much wrong but then again, I'm not the best at reading assembly. I was really hoping I wouldn't have to do this at the kernel level. I'd rather just close the task manager on open (since this isn't a virus. It can just act obvious.)
Edit:: Just tried ZwQuerySystemInformation since you mentioned ring0 so I wanted to make sure I was using a ring3 function. It didn't work.
RE: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - Frooxius - 09-24-2012
I'm not saying that you shouldn't try to investigate this problem further, but what about trying to replace the task manager itself? Or at least making sure some modified version of it is launched when the key combination is pressed or if taskmgr is launched? Process Explorer can register itself like that, so maybe you can do it with your modified version of taskmgr too (where you put the hiding code directly to it).
Anyway, maybe ring0 vs ring3 doesn't matter, it's just that you can't do that with any WinAPI function, or at least these that could be potentially exploited like that.
RE: API Hooking Differing across APIs? (NtQuerySystemInformation Hook) - Frooxius - 09-26-2012
(I'm posting another post to notice you that I added new info)
Rodaxoleaux the Lab Rat: I read now your post again (last time I just came home from Bratislava from EUCYS where I was the whole day) and I have another question:
What do you mean by "how"? How to get the stack trace? Doesn't Visual Studio provide you with more information when the problem occurs? Maybe if you could provide more code, it would be possible to test it ourselves and look at it, it might be also possible that the problem is caused somewhere earlier in the code, but only shows up once you do the write.
It's still odd that it behaves like that, even if the system would prevent writing to that from security reasons (and think it actually does).
I looked up WriteProcessMemory documentation and another problem might be if you're trying to write to a 64-bit process from a 32-bit one. What system are you even using? Can you provide us any details about the environment?
EDIT: I've found an interesting paper on this issue, you might give it a read too: http://seclists.org/fulldisclosure/2010/Mar/att-553/Windows-DEP-WPM.txt