Windows API Hooking, Injecting a DLL

[arcker]

Ok no more crash

but still it doesn't work ( not triggered when i copy a file in the explorer )

here are the three files :

main.cpp

main.h

ApiHookExample.au3

BTW , ive modified the cpp source code in main.h that you provided since VC++ returns error when with those lines :

#ifdef BUILD_DLL
    #define DLL_EXPORT __declspec(dllexport) WINAPI
#else
    #define DLL_EXPORT __declspec(dllimport) WINAPI
#endif

in the header, that i've replaced by :

#define DLL_EXPORT __declspec(dllexport) WINAPI

if you can find the solution, because i think it's quite ok now

thx again

[wraithdu]

Glad you fixed the crash (and glad to know it works with system processes).

The sample I gave you was done with CodeBlocks. I have VS2008 also, and it won't let you define the dllimport like CB does. Removing it like you did is fine.

Regarding it not working...how can you tell? Your hooking function simply passes the operation on to the original function without any notification. You need a way to tell if the function is even called. A good way would be to output some info to debug using the OutputDebugString() function, and reading it with DebugView from Sysinternals.

You also have to be sure that your actions in Explorer are actually calling this function to begin with.

Edited January 11, 2009 by wraithdu

[arcker]

i'm sure that this is the function since i've checked with api monitor.

for the outpuddebugstring, do you mean to insert it in the c++ code, or in the autoit code ?

to test i do a simple ctrl+c, ctrl+v on one file in the opened explorer.

[wraithdu]

In the DLL. In the hook function, before you chain to the original function, throw in

OutputDebugString(L"hooked function");

Then monitor the run with Debug View. If the function is hooked, you should see the debug line in DbgView. You can test it first with AutoIt with

DllCall("kernel32.dll", "none", "OutputDebugString", "str", "test debug string")

[arcker]

yeaahhh

the function is hooked when i paste the file. So the hook works :

[1944] hooked function MySHFileOpW

I understand now ... so the hook is inside the dll

what i want is to retrieve those information in autoit and to sendit back to the process.

For example, i want to retrieve the "CopyTo" field to change it, but i need to know what it contains.

Edited January 11, 2009 by arcker

[wraithdu]

IMO, the best way to handle that is inside the DLL / hook function. The AutoIt part is mainly the hooking / injection engine.

If you really need to handle this in AutoIt, or somehow get information back to AutoIt, then you need to come up with a method for interprocess communication. Google that, and you should come up with several possibilities.

The most likely method is using Windows Messages. One idea is to use the WM_COPYDATA message, which is used for this purpose. You could also use a custom message in the same way. Lookup WM_COPYDATA on MSDN, and it will also give you some sample code on how to use it.

I wouldn't bother sending any info back to the hook after that. Decide in the hook how you want to process the call, and if you want to change it in AutoIt, do so and call the SHFileOperation function from AutoIt.

Edited January 12, 2009 by wraithdu

[arcker]

i was afraid of this answer

fortunately i know really well how to use wm_copydata.

can we make a bridge between autoit and the dll ???

I was sure that it was the method that other hook engines uses.

[wraithdu]

Define "bridge"?

Any application using dll injection has to go through this. It's the ony way to get information back and forth. You've injected a DLL which is now running on its own in the target process. The target process was responsible for the actual loading of the DLL (even though you told it to load it), so you have no direct connection with it. Sorry, there's no easy button or magic bullet here.

However once you have the communication system setup, handling things back and forth between the DLL and AutoIt should be pretty straight forward. If you have experience with WM_COPYDATA, I'd say use that.

I won't say there isn't an engine out there that provides a wrapped way of doing this, but I would say there aren't many. Communication like this is very custom to your purpose - what data is sent back and forth, how much, how often, under what circumstances, etc. In your case, you'll want to modify the Get function, or add another function, to also send the HWND of your message receiving AutoIt window to the DLL so it knows where to send WM_COPYDATA.

Edited January 12, 2009 by wraithdu

[arcker]

ok, thx for the explanation

i'm studying supercopier source code and it seems that the author uses IPC for inter_process communication.

That's not stupid, but should be harder than using wm_copydata.

i'll try to make a workable version of my "own explorer copier" and see if i can optimize it.

Thx for making it possible

[wraithdu]

No problem! I'm glad you're finding it useful. Granted, it's really only a foundation, since a lot of the work just has to be done in the DLL. But it was cool learning how it works and making it happen in AutoIt. The fact that it works on core OS processes like Explorer, and doesn't cause any bad crashes, is awesome to hear!

[arcker]

sure ! it opens up some possibilities

[arcker]

Ahhhh ... ok so the limitation is right there.

the solution, like i said, is IPC.

MadCodeHook ( opensource before some hackers use it for malware and so on ) uses this :

Here is the solution for IPC. It's in delphi, so i'll try to readapt the code in autoit.

http://help.madshi.net/IPC.htm

[wraithdu]

Updated UDF, see first post.

[wraithdu]

Updated UDF, see first post.

[wraithdu]

Updated UDF, see first post.

[wraithdu]

Updated UDF, see first post.

[wraithdu]

Workaround to remove the AutoIt >= 3.3.1.0 requirement.

Edited October 6, 2009 by wraithdu

[Grayhat]

How to hook, for example a Kernel32's ReadFile API in a remote process?

I have a program that read a file and load it into a variable...

is possible to remote hook the "ReadFile" to my own ReadFile Function?

I mean, my own readFile needs to replace some chars in the file read, so the 'patched' data should stay in the variable, but modified.

[wraithdu]

No, what you want to do is impossible. Your script and the target process are loaded in different address spaces. What you will have to do is to write a DLL that can be injected into the target process that hooks the API, does whatever you want it to do, and somehow communicates whatever information you need back to your script (WM_COPYDATA messages, pipes, etc, some kind of interprocess communication).

[Grayhat]

but i dont need the information in the script...

I just want to modify the data that the target read itself...

the target structure is:

Main code

gen separator

data code

the main code slipt itself at separator and process the data code... but I want to modify the data code in runtime, so the main code should process the 'patched' code, no the actual code... it need to be made in runtime... possible?