CreateRemoteThread() fails on protected AV process c++???
Pages: 12
closed account (13bSLyTq)
Hi,
Null you do know compiler can sometimes cut these and optimize it right? And something like mov can change.
Null you do know compiler can sometimes cut these and optimize it right? And something like mov can change.
Okay,
back to the topic,
Im hooking NtOpenProcess in user mode.
And in the unhook function you gave me, why do you do
XOR ecx, ecx?
wont that be 0 ?
Please explain.
back to the topic,
Im hooking NtOpenProcess in user mode.
And in the unhook function you gave me, why do you do
XOR ecx, ecx?
wont that be 0 ?
Please explain.
closed account (13bSLyTq)
Hi,
You should start testing before you ask a question like this, likewise learn before questioning.
Anyway, I use XOR ecx, ecx becuase the original NtOpenProcess uses XOR ecx,ecx therefore we use the exact same command. The idea of unhooking is to clear up our mess and leave the function same as it used to be. The reason unhooking properly is extremely important is effectively because each API function whether it be Wow64SystemServiceEx or Sleep.
They each consist of their own size in the memory and this size boils down to the original instruction sizes and in Windows changing these instructions to our choice would mean a cataclysmic diaster in Windows as we will be overwriting instructions of the other functions as all functions have a pattern in which the reboot both with ASLR enabled or ASLR disabled and if you change the instructions you will change the sizes and therefore mess up the process API calling conventions.
Next, using original instructions would guarantee us that we don't cause rare disturbance for memory scanning applications or rootkit detectors. As they will complain because of the "unseen" instructions being placed.
You should start testing before you ask a question like this, likewise learn before questioning.
Anyway, I use XOR ecx, ecx becuase the original NtOpenProcess uses XOR ecx,ecx therefore we use the exact same command. The idea of unhooking is to clear up our mess and leave the function same as it used to be. The reason unhooking properly is extremely important is effectively because each API function whether it be Wow64SystemServiceEx or Sleep.
They each consist of their own size in the memory and this size boils down to the original instruction sizes and in Windows changing these instructions to our choice would mean a cataclysmic diaster in Windows as we will be overwriting instructions of the other functions as all functions have a pattern in which the reboot both with ASLR enabled or ASLR disabled and if you change the instructions you will change the sizes and therefore mess up the process API calling conventions.
Next, using original instructions would guarantee us that we don't cause rare disturbance for memory scanning applications or rootkit detectors. As they will complain because of the "unseen" instructions being placed.
Okay, so hooking if not done correctly, will cause problems,
so in the hook function why are you protecting 7 bytes, can this be 10/anything?
LOL. (just asking).
so in the hook function why are you protecting 7 bytes, can this be 10/anything?
LOL. (just asking).
| Hi, Null you do know compiler can sometimes cut these and optimize it right? And something like mov can change |
closed account (13bSLyTq)
@Null I did not mean to be rude, anyway you provided me with valuable resource as well
In case you'll need full reference, see Intel manuals http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
closed account (13bSLyTq)
Hi,
As for the original topic questions.
The idea is right, if hooking (patching bytes) is not done correctly even with a slight flaw in instruction placements expect a problem such as:
- access violation: Mostly due to incorrect jmps
- memory corruption: Mostly due to messing up the stack
- buffer overflow: Due to the size of instructions overwriting other information
- buffer underflow: Similar reason to that of buffer overflow
- more!
These error may not arise nor even be detectable when debugging as these nasty bugs appear during normal runtime. As modern CPU can execute 1,000,000+ (1 Million) instructions per second and these instructions would mean some may do complicated calls and such to the "target" function we hooked and wrongly doing things can lead to these complicated functions messing up OR wrong results.
As for the other question, I actually built the function from scratch for someone on IRC network and the protection level is just amount of bytes you want to make eligible for changing or interaction with memory.
I normally try limit the unprotection to bare minimum when it comes to hooking and such. 5 bytes should be the minimum for normal hook however functions like KiFastSystemCall may arise which require more work and may require more than merely allocating 5 bytes. Therefore to summary my answer, a unprotection can be however many bytes you like but the main thing you need to remember when trying to unprotect is the unprotection should start at target address you desire to place a detour to.
GL
As for the original topic questions.
The idea is right, if hooking (patching bytes) is not done correctly even with a slight flaw in instruction placements expect a problem such as:
- access violation: Mostly due to incorrect jmps
- memory corruption: Mostly due to messing up the stack
- buffer overflow: Due to the size of instructions overwriting other information
- buffer underflow: Similar reason to that of buffer overflow
- more!
These error may not arise nor even be detectable when debugging as these nasty bugs appear during normal runtime. As modern CPU can execute 1,000,000+ (1 Million) instructions per second and these instructions would mean some may do complicated calls and such to the "target" function we hooked and wrongly doing things can lead to these complicated functions messing up OR wrong results.
As for the other question, I actually built the function from scratch for someone on IRC network and the protection level is just amount of bytes you want to make eligible for changing or interaction with memory.
I normally try limit the unprotection to bare minimum when it comes to hooking and such. 5 bytes should be the minimum for normal hook however functions like KiFastSystemCall may arise which require more work and may require more than merely allocating 5 bytes. Therefore to summary my answer, a unprotection can be however many bytes you like but the main thing you need to remember when trying to unprotect is the unprotection should start at target address you desire to place a detour to.
GL
Okay,
thankyou for the explanation!
Now 23h for NtOpenProcess
Isnt that '23h' change with every new service pack/update?
How can I cope with that?
thankyou for the explanation!
Now 23h for NtOpenProcess
Isnt that '23h' change with every new service pack/update?
How can I cope with that?
closed account (13bSLyTq)
Hi,
You can cope with it fairly easily as you can use a char array to store all the ordinals for whatever NT** function you are deciding to install a detour. Then compare against the OS version (XP, Vista, 7, 8).
I suspect the array would be minimal in size as most of the ordinals don't change with every service pack but every new Operating System:
http://theundead.atspace.com/Blog/Windows%20System%20Calls.htm
The above link has a entire list of NT** functions and their call ordinals listed by OS by OS. Do be aware the only real "careful" matter you must note is that XP SP3+ OS are only OS which can be hooked normally and are normal in terms of system call stubs and such.
GL
You can cope with it fairly easily as you can use a char array to store all the ordinals for whatever NT** function you are deciding to install a detour. Then compare against the OS version (XP, Vista, 7, 8).
I suspect the array would be minimal in size as most of the ordinals don't change with every service pack but every new Operating System:
http://theundead.atspace.com/Blog/Windows%20System%20Calls.htm
The above link has a entire list of NT** functions and their call ordinals listed by OS by OS. Do be aware the only real "careful" matter you must note is that XP SP3+ OS are only OS which can be hooked normally and are normal in terms of system call stubs and such.
GL
Thankyou very much for that really nice explanation!
Now I made a callback for NtOpenProcess():
LOL!
GL!
Now I made a callback for NtOpenProcess():
|
|
LOL!
GL!
closed account (13bSLyTq)
Hi,
You have copy pasted this example NOT made it your self:
http://theundead.atspace.com/Blog/CNtOpenProcessDrver.txt
The callback does not work not to mention the entire hook callback would crash the process entirely if incorporated into your "app". As you are using local functions and even if you did use global functions which may derive from ntdll.dll it would yet still crash the process as VS uses call-gates rather than use direct calls to the address
You should understand that hooking requires multiple patches of groups of bytes to the callback to efficiently work and not crash the process.
This is beyond ridiculous.
GL
You have copy pasted this example NOT made it your self:
http://theundead.atspace.com/Blog/CNtOpenProcessDrver.txt
The callback does not work not to mention the entire hook callback would crash the process entirely if incorporated into your "app". As you are using local functions and even if you did use global functions which may derive from ntdll.dll it would yet still crash the process as VS uses call-gates rather than use direct calls to the address
You should understand that hooking requires multiple patches of groups of bytes to the callback to efficiently work and not crash the process.
This is beyond ridiculous.
GL
Last edited on
Sorry to waste your time.
I should have to make the callback for OpenProcess() not NtOpenProcess() , right?
and Im not using VS, lol!
I should have to make the callback for OpenProcess() not NtOpenProcess() , right?
and Im not using VS, lol!
closed account (13bSLyTq)
Hi,
I have no idea of what function API you are detouring therefore I cannot answer the question; when you ask a question be sure to check thrice if you are present information correctly needed to answer the question, else you will most likely look like a skid & will lose vital credibility in field of programming.
I have no idea of what function API you are detouring therefore I cannot answer the question; when you ask a question be sure to check thrice if you are present information correctly needed to answer the question, else you will most likely look like a skid & will lose vital credibility in field of programming.
Hi,
I am trying to hook NtOpenProcess and Im not using VS Im using MINGW !
And will that callback work?
Im doing this in User mode!
I am trying to hook NtOpenProcess and Im not using VS Im using MINGW !
And will that callback work?
Im doing this in User mode!
closed account (13bSLyTq)
Hi,
I would advise you to stick with detouring NtOpenProcess to protect your process, because majority of the rootkit and malware developers would easily bypass your OpenProcess hook fairly easily. On that note even NtOpenProcess hook can be bypassed fairly easily however it takes a bit more work.
Example trick to bypass NtOpenProcess Hook (Ring3):
x64 Systems:
x86 Systems:
As you see with these few tricks we would completely avoid a trace of the detour and yet still behave and function like the real NtOpenProcess.
However we can hook System Call stubs which means nothing in user mode can bypass nor remove the detour. There are two system call running in x86 before switching or entering kernel mode stubs in Windows:
- KiFastSystemCall (Located ntdll.dll)
- X86SwitchTo64BitMode (Located TEB+0xC0)
Nevertheless, it still does not matter what compiler you are depending on as the processes itself needs to posses the libraries in which your function derive from one way or another. I would be pretty skeptical with that as it not many processes which uses say, MsRdc.dll, this means not all code can be run without the process being short of a single or more dynamic link libraries. Therefore it is not a viable method to do "instant" injections using GCC or MINGW.
As for the callback, I would say it would terribly fail leaving all processes crashed, as supposed to it being used in Device Drivers.
Hope I helped,
OrionMaster
I would advise you to stick with detouring NtOpenProcess to protect your process, because majority of the rootkit and malware developers would easily bypass your OpenProcess hook fairly easily. On that note even NtOpenProcess hook can be bypassed fairly easily however it takes a bit more work.
Example trick to bypass NtOpenProcess Hook (Ring3):
x64 Systems:
|
|
x86 Systems:
|
|
As you see with these few tricks we would completely avoid a trace of the detour and yet still behave and function like the real NtOpenProcess.
However we can hook System Call stubs which means nothing in user mode can bypass nor remove the detour. There are two system call running in x86 before switching or entering kernel mode stubs in Windows:
- KiFastSystemCall (Located ntdll.dll)
- X86SwitchTo64BitMode (Located TEB+0xC0)
Nevertheless, it still does not matter what compiler you are depending on as the processes itself needs to posses the libraries in which your function derive from one way or another. I would be pretty skeptical with that as it not many processes which uses say, MsRdc.dll, this means not all code can be run without the process being short of a single or more dynamic link libraries. Therefore it is not a viable method to do "instant" injections using GCC or MINGW.
As for the callback, I would say it would terribly fail leaving all processes crashed, as supposed to it being used in Device Drivers.
Hope I helped,
OrionMaster
Then if you bypass the hook,
like that, why should I hook?
Anyways this thread is not getting me anyware,
I am terribly upset!
Anyways thankyou for your valuable help!
Im gonna mark this thread as solved, (for now)! LOL!
GL
like that, why should I hook?
Anyways this thread is not getting me anyware,
I am terribly upset!
Anyways thankyou for your valuable help!
Im gonna mark this thread as solved, (for now)! LOL!
GL
Last edited on
| Anyways this thread is not getting me anyware, |
All your threads will not give you anywhere because you just keep asking without writing any code on your own :)
closed account (13bSLyTq)
exactly, I agree with modoran.
I have helped you, actually I did previously suggest that hooking this is not too brilliant, but I would suggest you hook NtOpenprocess still as not many Malware use NT** on Userland that too using the tricks I presented to you.
I have helped you, actually I did previously suggest that hooking this is not too brilliant, but I would suggest you hook NtOpenprocess still as not many Malware use NT** on Userland that too using the tricks I presented to you.
Topic archived. No new replies allowed.
Pages: 12