Override Windows API calls?

[iamthewalrus(:3=]

I'm interested in writing a Windows application that would have to override certain API calls in some instances. I have a decently good idea of how I could do this destructively (ie, delete the dll that holds the code for the call and write my own), but really, I want to be able to intercept the call and then potentially execute the underlying API call after I execute my own code, so the destructive aspect isn't going to work. I've looked through Microsoft's docs, but haven't found anything in the way of what I want to do (nor do I expect to, as I doubt Microsoft is too keen on letting others rewrite the API to their operating system).

I have no experience programming for Windows. Any veteran Windows programmers want to point me in the right direction of how to learn how to do this?

[samclem]

I'm closing this for the moment. I'm not the computer expert here, but I'm also not sure about the legality of what you're trying to do. I'll refer this one to our experts. IF they approve, I'll reopen. But don't hold your breath.

samclem GQ moderator

[samclem]

I'm re-opening this one, based on an email from Armilla ,who seems to be a most respected computer expert on the boards.

I reserve the right to close if I find different.

[Armilla]

I wouldn't normally interfere, but I'd just finished typing up a reply

Anyway, I saved it and now reproduce it in full for your viewing pleasure:

There are serveral routes by which this kind of thing can be approached. By far the simplest is to write a proxy DLL.

In this method you would create a new DLL with the same name as the one containing the API calls you want to intercept. This new DLL would export a stub function matching all of the functions in the original.

Each stub function would do whatever extra stuff you wanted and then pass execution on to the original DLL, which you'll have to manually load from its full path using LoadLibrary.

There's an article here that contains an example of this kind of proxy.

Another technique is to patch the Import Address Table in the memory image of a running application - this will allow specific API calls to be redirected as required.

Example code can be found in the download section here (look for APISpy32).

Slightly more ambitious is the method of searching for and directly patching calls to an API in the code of an application. This requires some assembler knowedge to implement yourself, but the free Microsoft Detours 1.5 library may provide what you want in an easier framework.

[iamthewalrus(:3=]

Thanks for reopening it, samclem.

I understand your concern, but I highly doubt that this is illegal. All I'm doing is writing a layer of software that sits between other applications and Windows itself, and modifies the system behavior based on that. I'm not trying to crack anything or steal code, just modify the behavior in certain cases.

I probably should have included what I want to do in the OP. I want to make a program that would monitor calls to the sound driver and disable sound to certain programs. I'm getting pretty tired of having annoying websites or application alerts make noise that you can't disable in the program. I looked for programs like this, but couldn't find any.

It's also possible that there's a better way to do this than by overriding the API calls.

On preview, thanks for the highly informative response, Armilla.

[TimeWinder]

I'll second the notion that this isn't necessarily an illicit activity. There are many, many legitimate applications that need to do this - including almost all macro programs, disk utilities, security apps, debuggers....

Walrus, check out SetWindowsHookEx() in the MSDN library (online or on CD) for a starter. In general, what you're looking to do is called an "API Hook Function", and searching on that will get you started.

Not all API functions are hookable, and it's done in different ways for different functions. The easiest ones (that I've given you the pointer to above) are involved in trapping windows messages.

Doing this for processes other than your own is left as an exercise for the reader. I hesitate to dissuade anyone who wants to expand their boundaries, but this isn't something that's going to be easy for someone who has "no experience programming for Windows."

[TimeWinder]

.. or what Armilla said...

[Morbo]

I'm the one that asked samclem that it be closed. I'm a PPT developer and have been so for the last 15 years. My original reading of your OP assumed you wanted to break into a WinOS core DLL (kernel32/user32/gdi32) and re-write APIs directly into those core DLLs and then replace them. I guess I misinterpreted sentence #2. As the App teams have strict guidelines about overwriting system DLLs, (WINSOCK anyone?), I jumped the gun on this one. MS protector and all that. My bad.

A Hook function will do exactly what you want it to do WRT disabling CODEC calls from specific applications. Search the SDK for SetWindowsHookEx().

[CaveMike]

Here is an article from Code Project that deals with three ways of hooking into Windows apps. It includes sample source code.

[Mr2001]

I'm shocked that anyone would ask for this thread to be closed. There's nothing illegal about it; it's the modern day equivalent of hooking an interrupt vector (DOS) or patching a trap address (MacOS). It might be a bad idea, or a bad way to implement a good idea, but it's perfectly legal to intercept, monitor, and reroute the function calls a program is making. It's also perfectly legal to overwrite kernel32.dll with your own code - it's just a terrible idea.

That said, this is an odd request from someone with no Windows programming experience. I suspect that whatever the OP is trying to do, there's a better way to do it than intercepting API calls.

[xash]

See if this explanation helps you in understanding whether API interception suits your needs:

API hooking revealed

[Mr2001]

That link doesn't seem to work.

[Antonius Block]

Originally Posted by Mr2001

That link doesn't seem to work.

Xash's link cleaned up.

[iamthewalrus(:3=]

Originally Posted by Mr2001

That said, this is an odd request from someone with no Windows programming experience. I suspect that whatever the OP is trying to do, there's a better way to do it than intercepting API calls.

Entirely possible. As I said, I'm looking for something to intercept calls to audio devices. If there's a better way to do it, I'm certainly open to it.

Dooku, even if I had planned to do what you suggested, would that actually be illegal, or just a really good way to break my installation of Windows?

[Morbo]

I never said it was illegal (so I'm shocked myself by Mr2001's reaction) and it isn't - I was simply concerned when I read the OP (erroneously, as I have already stated) that we would be giving suggestions about how to "destructively" overwrite API calls in a system DLL. The only issue would be a copyright violation - our specific implementation of them is copyrighted, but we allow people to create a duplicate APIs w/o breaching the copyright. Happens all the time.