Some of Our Favorite Features in Android 5.0 Lollipop

Android 5.0 Lollipop is the latest major revision to Google’s mobile operating … more

Sony SmartEyeglass SDK Developer Preview Released

A little over a month ago in Tokyo, Japan, Sony unveiled its new SmartEyeglasstechnology. … more

XDA and Leaseweb: Server Trial/Moto 360 Contest (Winners!)

About a month ago, we held a contest along with XDA’s host, Leaseweb, to … more

Updated Android Lollipop Preview Images – XDA TV

The Android Lollipop Preview Images are now available! That and much more news is … more
Post Reply

Windows Hooking question

OP Toxickill

30th April 2014, 03:06 PM   |  #1  
OP Member
Thanks Meter: 34
 
76 posts
Join Date:Joined: Apr 2013
Is it possible to create an application that would hook all api calls to windows and be able to accept or deny the call? How trivial would this be?
Last edited by Toxickill; 1st May 2014 at 02:09 AM.
30th April 2014, 06:01 PM   |  #2  
Recognized Developer
Flag Seattle
Thanks Meter: 2,708
 
5,725 posts
Join Date:Joined: Jan 2011
More
All calls, for all apps? Very damn hard. You'd basically need to shim the entire standard libraries. The shims could probably be programmatically generated, but you'd need to write the program to create them. Then you'd need Admin access to install them, and then...

Why don't you explain what you're trying to do? This is a very complicated thing to attempt, and it might not be the right approach at all,
1st May 2014, 02:09 AM   |  #3  
OP Member
Thanks Meter: 34
 
76 posts
Join Date:Joined: Apr 2013
Quote:
Originally Posted by GoodDayToDie

All calls, for all apps? Very damn hard. You'd basically need to shim the entire standard libraries. The shims could probably be programmatically generated, but you'd need to write the program to create them. Then you'd need Admin access to install them, and then...

Why don't you explain what you're trying to do? This is a very complicated thing to attempt, and it might not be the right approach at all,

Due to recent program vulnerabilities *cough cough* IE exploit, I want to create a program to minimize and effectively stop the exploits, by blocking reading api calls from programs that have the vulnerability and determining if the call should be made or not.
1st May 2014, 03:06 AM   |  #4  
Recognized Developer
Flag Seattle
Thanks Meter: 2,708
 
5,725 posts
Join Date:Joined: Jan 2011
More
There's already tools like EMET, which blocked that (and may other) exploits.
Have you ever looked at the output generated by procmon on a typical Windows application? Even for just the subset of system calls that it monitors, the log scrolls too fast to read, much less to make a decision about each call. Something as simple as opening a single static HTML page in IE would require an incredible number of clicks. Your typical modern page, which has dozens of separately-requested elements, generates considerable traffic to log files and cookies and so forth, and may contain rich content requiring a bunch of additional functions... Yeah, not practical at all.
2nd May 2014, 01:53 AM   |  #5  
OP Member
Thanks Meter: 34
 
76 posts
Join Date:Joined: Apr 2013
Quote:
Originally Posted by GoodDayToDie

There's already tools like EMET, which blocked that (and may other) exploits.
Have you ever looked at the output generated by procmon on a typical Windows application? Even for just the subset of system calls that it monitors, the log scrolls too fast to read, much less to make a decision about each call. Something as simple as opening a single static HTML page in IE would require an incredible number of clicks. Your typical modern page, which has dozens of separately-requested elements, generates considerable traffic to log files and cookies and so forth, and may contain rich content requiring a bunch of additional functions... Yeah, not practical at all.

For educational purposes and further knowledge could you show me what I would have to do to hook one api call from a process? it does not have to be a global hook.
3rd May 2014, 09:32 PM   |  #6  
Recognized Developer
Flag Seattle
Thanks Meter: 2,708
 
5,725 posts
Join Date:Joined: Jan 2011
More
There's a handful of possible approaches.

If you *wanted* to do it globally, and didn't mind doing so only at the kernel syscall layer (meaning any purely user-space code wouldn't get caught, but since anything that can go between processes in any practical way involves the kernel anyhow...) you could create a driver that filters the relevant system calls. Filtering the entire system call interrupt at one place is possible if you can mess with the relevant interrupt service routine, but I believe that's protected by PatchGuard. There may be some all-in-one place anyhow, but it would be tricky. Anyhow, this is how tools such as Process Monitor (which only handles a relative handful of system calls) work.

If you want to modify the behavior of a bunch of programs, you could create modified versions of the system libraries, and put them where the programs would load them (usually the application directory would work, but sometimes you would need to replace the system copy). This approach is a lot of work, though not completely impractical; you simply need to shim all the exported functions (or at least, the ones you care about) with a version that filters the call before passing it through to the "real" version, but you would need to cover all the exported functions without breaking their ABI. Doable, but a lot of work.

If you only want to get one function, the easiest way would be to re-write all calls to that function in the process memory such that they go to your filter instead. This is how the Detours library (http://research.microsoft.com/en-us/projects/detours/) works; you can find code samples of using it online. I believe that is also how Microsoft's application compatibility shims work. There are registry keys which will cause a given program to be loaded in a debugger (which can be mostly non-interactive, and just make this change for you) or I *think* there's a way to specify an arbitrary DLL that a given program must load (and run its DllMain function) when it starts up too, which would also do the trick.

Bear in mind that the second and third methods can be bypassed by an attacker who knows what you're doing; the attacker just (re-)overwrites the function tables to point at the real versions of the APIs, or alternatively makes the relevant system calls directly (Win32 programs basically never do this, instead letting the Win32 subsystem translate their Win32 function calls in NT system calls and invoking the wrapped syscall, but there's nothing *stopping* them). The first approach can't be bypassed by an attacker with less than Admin privileges (assuming you did it right; I can think of a couple of potential gotchas you'd need to avoid) but you would need Admin yourself in order to install that driver in the first place, and if you want to *interactively* filter the API calls you would need the entire interaction path including the UI to protected against tampering by less-privileged processes.

With all that said, a real Mandatory Access Control that gives finer-grained control than Windows' Mandatory Integrity Control would be a really cool thing (something more like SELinux or AppArmor). It would probably be more effort on NT than on Linux though, due to NT not (so far as I know) having any equivalent of http://en.wikipedia.org/wiki/Linux_Security_Modules (a good place to start reading about the topic).
5th May 2014, 01:14 PM   |  #7  
OP Member
Thanks Meter: 34
 
76 posts
Join Date:Joined: Apr 2013
Quote:
Originally Posted by GoodDayToDie

There's a handful of possible approaches.

If you *wanted* to do it globally, and didn't mind doing so only at the kernel syscall layer (meaning any purely user-space code wouldn't get caught, but since anything that can go between processes in any practical way involves the kernel anyhow...) you could create a driver that filters the relevant system calls. Filtering the entire system call interrupt at one place is possible if you can mess with the relevant interrupt service routine, but I believe that's protected by PatchGuard. There may be some all-in-one place anyhow, but it would be tricky. Anyhow, this is how tools such as Process Monitor (which only handles a relative handful of system calls) work.

If you want to modify the behavior of a bunch of programs, you could create modified versions of the system libraries, and put them where the programs would load them (usually the application directory would work, but sometimes you would need to replace the system copy). This approach is a lot of work, though not completely impractical; you simply need to shim all the exported functions (or at least, the ones you care about) with a version that filters the call before passing it through to the "real" version, but you would need to cover all the exported functions without breaking their ABI. Doable, but a lot of work.

If you only want to get one function, the easiest way would be to re-write all calls to that function in the process memory such that they go to your filter instead. This is how the Detours library (http://research.microsoft.com/en-us/projects/detours/) works; you can find code samples of using it online. I believe that is also how Microsoft's application compatibility shims work. There are registry keys which will cause a given program to be loaded in a debugger (which can be mostly non-interactive, and just make this change for you) or I *think* there's a way to specify an arbitrary DLL that a given program must load (and run its DllMain function) when it starts up too, which would also do the trick.

Bear in mind that the second and third methods can be bypassed by an attacker who knows what you're doing; the attacker just (re-)overwrites the function tables to point at the real versions of the APIs, or alternatively makes the relevant system calls directly (Win32 programs basically never do this, instead letting the Win32 subsystem translate their Win32 function calls in NT system calls and invoking the wrapped syscall, but there's nothing *stopping* them). The first approach can't be bypassed by an attacker with less than Admin privileges (assuming you did it right; I can think of a couple of potential gotchas you'd need to avoid) but you would need Admin yourself in order to install that driver in the first place, and if you want to *interactively* filter the API calls you would need the entire interaction path including the UI to protected against tampering by less-privileged processes.

With all that said, a real Mandatory Access Control that gives finer-grained control than Windows' Mandatory Integrity Control would be a really cool thing (something more like SELinux or AppArmor). It would probably be more effort on NT than on Linux though, due to NT not (so far as I know) having any equivalent of http://en.wikipedia.org/wiki/Linux_Security_Modules (a good place to start reading about the topic).

I want to write open sourced code that will be like super user and permissions for windows so you can have the open feeling of windows but a secure feeling as well with little to no anti-virus's. This would not be like windows rt's locks, you can run any program you like.
5th May 2014, 10:53 PM   |  #8  
Recognized Developer
Flag Seattle
Thanks Meter: 2,708
 
5,725 posts
Join Date:Joined: Jan 2011
More
You're not the first person to have this idea, but I don't think you understand the magnitude of what you're asking for. Even if such a system were created, it would be a lot of work to create all the rule sets for every program you want to protect. Besides, you'd still be vulnerable to malicious code that runs as Admin (i.e. most installers, etc.) since they could unload or modify your driver.

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes