WepMetering

History

Description

So the goal of this experiment is to intercept and log all calls made to the WinSOCK functions send() and sendto() by any process on the computer. We could have chosen any function inside any DLL, but to spy on what the MS Internet Explorer application is sending seems to be fun enough to make it an application.

Before diving into the fun-but-grungy ASM, it would be useful to see the big picture.
To intercept calls that another application makes to a specific DLL, we need to either intercept the call before it is made (which is almost impossible) or instrument the target DLL with a logging function, which is called as it executes the actual DLL code.

Ways to do it

Replace the DLL

Replace the process' Import Address Table

Hook into the remote DLL code

Getting inside

• Use the App_Init registry key. It contains a list of DLLs that the system will inject into any process loaded.
• Use a system-wide message hook. The message hook is really intended for computer-based training (replay of keyboard strokes etc), but works by injecting the hook DLL into every process so a callback function can be called in the process' context.

LRESULT CALLBACK HookProc(int nCode, WPARAM wp, LPARAM lp)
{
   if( bFirstTime ) {
      bFirstTime = false;
      if( ProcessRecognized() ) {
         InjectWinsockHook();
      }
   }
}

Installing the spy

The spy code itself is really all about redirecting the call from the WinSOCK function to our own logging function. Then we return control back to WinSOCK and let it execute its code.

To redirect the WinSOCK function to the logging function, we simply insert a JMP assembler instruction into the first bytes of the target function (WinSOCK.send). Assuming that it's at least 5 bytes long, there is plenty of room to do this. Of course since the JMP instruction will destroy some of the original WinSOCK code, we make a backup of the first few bytes so we can execute them later.

One of the biggest hurdles is that we need to inject the JMP hook right into unknown WinSOCK assembler code. We know exactly how many bytes the JMP instruction requires, but how can we be sure that the backup we make is a valid assembler opcode sequence? We're going to execute the backed up code later, so we better make sure that we don't cut an assembler instruction in half.
A little study of how compilers generate code will tell us that they usually generate some stack frame setup code in the beginning of every function:

WinSOCK.send:
                     ; Stack frame setup
55                   push        ebp
8B EC                mov         ebp,esp
83 EC 10             sub         esp,10h
                     ; The actual function code starts here
33 D2                xor         edx,edx

After injecting the JMP instruction, the code from before will look like this:

WinSOCK.send:
                     ; The injected JMP instruction
E9 D8 3C 00 00       jmp         hook_stub
10                   ; <- This is a left over byte!
                     ;    It's not a valid instruction.
                     ; Here continues the WinSOCK code...
33 D2                xor         edx,edx

We now need to construct the actual logging function. One thing is for sure: when the logging is done, we need to return control to the original WinSOCK code. In fact, we need to start by executing the original code (the stack frame setup stub) that we overwrote with our JMP hook.
Here is an example of how the final ASM code for the hook stub for the send() function will look like:

hook_stub:
         ; Call logging code
         pushad
         call        my_logging_function
         popad
         ; This is a copy of the original
         ; first 6 bytes the WinSOCK function
         ; contained.
         push        ebp
         mov         ebp,esp
         sub         esp,10h
         ; Return control to WinSOCK
         jmp         WinSOCK.send + 6

The logging function itself (here called my_logging_function) is actually not interesting. It can do anything. The only challenge is to extract the actual arguments passed to the send() function. But they are still to be found on the stack, and as long as you take into account the pushad and call instructions and the order in which arguments are passed in the C++ language, then it's relatively easy.

The hook stub code above will be dynamically constructed (using the ::VirtualAlloc() API) on the fly as we hook the function. Using self-modifying code is not something I would usually recommend, but it comes in very handy here.

You may ask why we need to bother with the system wide message hook at all? Why not just load the WinSOCK DLL and inject the hook code once and for all?
The answer to that is the Virtual-Memory protection that Windows uses. It will share the memory pages containing code in any loaded DLL among all processes. But it also has a "copy-on-write" policy: Whenever you modify a shared page it will make a local copy of that page before it applies your modification. So to modify the WinSOCK DLL in a remote process, we must make sure we modify the local copy in that process.

Notes

Source Code Dependencies

Download Files

Source Code (37 Kb)