Download Deviare Download Sourcecode Download PDF

Contents

• Introduction
• Research
  • Direct Sound Capturing
  • Monitoring Skype Conversations
• Implementation
  • Deviare Python Wrappers
  • Wave Tools
  • COM Type Libraries
  • Virtual Table Finder
  • Hooking Direct Sound
• Running Sound Capture
  • Easy Steps
  • Registration
• What’s next
  • Optimizations
  • Wave API Hooking
  • Hook DirectSoundCapture And Listen To Full Conversations
  • Inspect More COM Interfaces

Introduction

Today we are going to see how easy it can be to capture audio with Deviare. From players like Windows Media Player, instant messaging applications like Skype & Windows Live Messenger, to any application using DirectSound. The wave output will get captured by us. Deviare is indeed a powerful framework. Built to resolve most complex tasks in the simplest way. With a few lines of python, all our hooking is done and running. Today performance is extremely important, yet Deviare proves itself as the best. It allows you to also take advantage of the full power of Python

Research

Direct Sound Capturing

I must be honest, I’ve never used the DirectX API in my life, so I was a bit uncertain of how difficult this could be. I started by looking at MSDN documentation onIDirectSound and IDirectSoundBuffer. The first goal was to find a safe place to read its sound buffers. I found out that IDirectSoundBuffer::Unlock could serve my intentions well. At this point, the user is telling DirectSound that he has finished writing his wave output and the locks may be released. So, if we step in between, we can safely read the buffer. The user is no longer writing to it, and DirectSound has not yet taken control of it. I tested it on many applications and it turned to be the right choice. It works perfectly for WMP, Windows Live Messenger, and many others. No problems showed up until I stepped with Skype…

Monitoring Skype Conversations

This might be the way many applications handle their sound output, but it was the first application I have seen and I named the case after it. Later, I found a few articles describing it in detail. So, to my surprise, I was not seeing any data being written to the sound buffers after the unlock was called. How the hell is it writing its wave, and how am I supposed to read it?!. It kept me thinking for a while, until I noticed an interesting and constant call to IDirectSoundBuffer::GetCurrentPosition. Then I realized that this writing method depends on constant reading of the play and write buffer pointers. That’s because DirectSound, as most stream based implementations, works with a Circular buffer. Capturing its wave output requires that we keep track of changes in the write pointer. Once we know it has moved forward in the buffer, we can read its steps. Since here we don’t know how much the user has actually written to it, we must know the full size and location of the buffer. Unless we want to read garbage, but I’m sure that’s not the case .

Implementation

Deviare Python wrappers

Before we get our hands dirty, let me introduce you to something new in Deviare: Python Wrappers. As you already know Deviare is exposed through a series of COM interfaces. To save ourselves from the work of writing a whole new set of bindings, we used the well known project PyWin32. It’s very friendly to be used directly, as you may see in py_deviare_objects.py, just not enough to me. So I built these wrappers on top of it and made them as transparent as possible. You’ll find the use of the interface very similar to the way it’s done in our C# examples and in compliance with the python way of life, of course.

Wave Tools

I wrote these tools to help me write down the captured wave data. This may be obvious to people working in audio projects, but for me I cannot believe there is no native support in Windows to read-write Wav files! Yes, there is native support to write RICH content but come on! Luckily for me, I found a small sample C++ class inside the DirectX SDK. This was good enough for me to write my own in Python. As you may see, my WaveFile class only supports the write operation. Though, adding a read member should be easy enough for you . I have also added a lock to it, to ensure our data does not get corrupted by multiple thread operations. You may use it safely. The structures used were defined exactly as found in DirectSound and WinMM headers. Some of them are used by DirectX to specify the format of the wave content.

COM Type Libraries

By default, DirectX installations do not register their library types. Since we need that information, so Deviare can hook them, I created my own definitions with the interfaces we are interested in. To prevent any collision with previous installations, I used a different GUID. There is a python script that takes care of its registration and it’s automatically ran on demand by our example. Again, definitions are exactly as found on DirectX SDK.

Virtual Table Finder

To obtain the virtual tables for the interfaces, we basically have two options. Either we wait for its instantiation by the target process, or we find them ourselves on our own. Our first option is known to work for sure, yet we delay our installations until these events rise. This may also place us in a race and we may not capture all the output. The second one allows us to hook our targets immediately. Yet, in this case, we depend on the library (dsound.dll) being loaded in the same address space of our target. I have placed the two options in our example. If the current one is not working for you, uncomment the other at py_deviare_directsound.py

.

Hooking Direct Sound

The first thing we need, is to know every time a sound buffer is created. For that we are going to intercept calls to IDirectSound::CreateSoundBuffer. If the calls succeed, we look-up the table location inside the returned instance. From there we are going to hook four members of IDirectSoundBuffer:Initialize, SetFormat, Unlock and GetCurrentPosition. The first two, are used to obtain the wave format that the user is writing to the buffer. We also need to watch details from the call that creates the sound buffer, in case it is specified there. The Unlock member, as our research told us, is used in most applications to notify DirectX that the buffer is written and ready to be played. So we read the buffer pointers and size, to use Deviare’s memory interface to copy all content. We need to be careful, and see if the call actually succeeded. Only then can we save the wave data, else we must discard our buffers. With applications that keep track of the play and write cursors, we are going to monitor their calls to GetCurrentPosition. As explained earlier, with this method, I need to know the full size of the buffer and its location. So I save it from the first call to Unlock. Then I virtually divided my buffer in N segments, and filled it with the wave data as the write cursor moves forward in the buffer. Once my buffer contains enough data, I write it down to the wave file. To prevent false positives, in the creation of sound buffers, I delay the creation of my file until I have real data stored. In case we are monitoring the creation of IDirectSound in the target process, we also need to hook DirectSoundCreate and DirectSoundCreate8 from dsound.dll. There we can obtain the virtual table for IDirectSound, and follow our quest.

Running Sound Capture

Easy Steps

Execute the run_me.py located among the deployed files, and you’ll be prompted with a window to type the complete name of the process you want to start monitoring. For example: Skype.exe. Once the program starts capturing, the wave files will be written in the same folder. Once you are done, click OK on the dialog box to stop recording. Now you can open the .wav files generated, and listen the capture. Do not open them before closing the example as the data may not be readable by then.

Registration

The first execution of our example, will automatically register its interfaces and data types. It will also generate a file labeled .deviare_types_registered to prevent registration on the following executions. You can safely remove the file at any time you want the registration to be run again.

What’s Next

Optimizations

At any point of our handling, performance is essential. Any delay is highly punished by the sound output. So we must be careful about any operation we do inside the function call. This example tries to cache enough data before doing a write operation to disk. In case you need to improve its performance, you should read the data and release the call as soon as possible. Then in a different thread, or in a non punitive call, flush our data to the wave file.

Wave API hooking

This example could be very easily adapted to capture wave data from applications using WinMM API. Most browsers, Flash, and Google Talk use it to throw their sound output.

Hook DirectSoundCapture And Listen To Full Conversations

You should have noticed, when capturing from Skype, that your own voice is not heard. That’s because the application is not echoing its capture from the microphone. To get that too, it is necessary to hook IDirectSoundCaptureBuffer and proceed the same way to read its buffer.

Inspect More COM Interfaces

If you want to discover a lot more about the internals of DirectSound, then Deviare will be very valuable for you. Inspecting COM object is very easy indeed. Simply define one of its interfaces (if its not already registered in the system) and hook them the simpler way. If you are wondering what other interfaces may be useful for you, try our Deviare COM Console to discover them. It comes with source code, and you are free to adapt it to your needs! And That’s All Folks, hope you find it useful, enjoy!

Deviare Services

Deviare is a very specific tool and it can take a special effort to get acquainted with its mechanism. We have a team of professionals that can help so Just ask.

• Examples of interception code
• Parameter retrieve and change
• Ad-hoc interception techniques for complex problems
• COM Interception (with or without the interface)
• Interception of undocumented API
• 64 bits interception
• Debug server with interception techniques
• Server monitoring
• Sever performance boost

More information in Deviare Services

Download messagespy_demo.zip – 250 KB

Download messagespy_src.zip – 249 KB

Deviare Message Spy

Contents

• Introduction
• So, what’s the good news?
• Deviare Message Spy
  • Finding a Window: The Spy++ Style Window Finder
  • Hooking
  • The XML
  • The Cast
• Using Deviare Message Spy
• Requirements
• Known Issues
• Resources

Introduction

This article presents you with a different perspective of how to inspect window messages, to see how applications are communicating and managing their controls. We are not going to explain what window messages are or what they are used for in this article, so we suggest that you read these excellent articles to understand them: Handling Window Messages (Part 1, Part 2, Part 3). In this article we are going to monitor the Message API from the inside by hooking the target process.

So, what’s the good news?

As a first step when developing, to inspect windows, we open the Spy++ application and start the tedious work of following messages as they are printed in their hundreds. This is helpful most of the time, as we usually want to know what our windows are seeing and receiving. Yet, what happens when we want to know exactly how an application is communicating with its controls (what calls it makes to the message API) or want to see if our messages are getting filtered by someone else? As you may know, Spy++ installs 3 global hooks to receive every Send, Post and Call to a window message handler. The information provided by these methods is not enough to know what messages are coming from our application or if any of them have been filtered by a hook installed earlier in the call chain.

Do not panic, Deviare comes to rescue. What we are going to do is intercept all the Message APIs from the process that the window belongs to and monitor its calls. From there, we can be sure of what messages are being sent from the application to its controls and if any of them are missing from the ones that Spy++ is reporting, then we will know if someone else is watching us…

What happens with the messages not known by Spy++? How are we going to see them? Look what happens with many of the messages used by the standard ListView in windows. Spy++ does not know anything about them if the window is subclassed (for example ATL:SysListView32), and cannot trace its content. Try following LVM_GETNEXTITEM in Outlook Express and you will only see unknown 0×100C messages. The same goes for custom user messages that you may know and want to follow. We need an application that can be customized to our needs!

Deviare Message Spy

To probe our theory, we have built this message spying application. We have added to it a way to lookup windows handlers, hook the process owning it, and correctly report the messages and structures.

Finding a Window: The Spy++ Style Window Finder

To pick the target window and the process we wanted an interface like the one used in Process Explorer and Spy++. Thanks to Mark Belles this was an easy task. He has a great article on how to implement a nice Window Finder, in Code Project.

Hooking

In order to install a hook, first we need to identify our target process. After obtaining a window handle from our Window Finder, we can use GetWindowThreadProcessId to identify which process owns the window. From there we use the .Net API to access it and tell Deviare which process we wish to hook.

Win32.GetWindowThreadProcessId(hWnd, out _processId);
_txtProc.Text = Process.GetProcessById(_processId).MainModule.ModuleName

For our monitoring we have divided the API in 2 sets: the Dispatch group, and the Sent and Post group. Monitoring messages that arrive to the first group will provide us with a very similar view of what Spy++ sees. This is because these messages arrived to the application and have not been filtered by any hook. With our second group, we will identify direct and asynchronous calls to the Message API.

Let’s see how we install the hook for one of these functions:

procs = _mgr.get_Processes(0);
procs = _mgr.get _Processes(0)
proc = procs.get_Item(_processId)
IPEModuleInfo mod = proc.Modules.get_ModuleByName("user32.dll");
IExportedFunction fnc = mod.Functions.get_ItemByName("PostMessageW");
_hook = _mgr.CreateHook(fnc);
_hook.Attach(proc);
_hook.OnFunctionCalled += new Deviare.DHookEvents_OnFunctionCalledEventHandler(_hookPst_OnFunctionCalled);
_hook.Properties = (int)DeviareCommonLib.NktHookFlags._call_before;
_hook.Hook();

As you see, we easily pick our target process by Id and select its Module and Function by name. The module name is not important, as it is always going to be “user32.dll”. If you have doubts, you can use Spy Studio to watch the process modules and exported functions.

Once the hook gets installed, we will receive notifications on our handler. From there we parse the function parameters transparently with the interface provided. (These parameters are actually in the target process, and Deviare copies them to our process on our demand and handles all the communication).

int returnVal = callInfo.ReturnValue;
IParams pms = callInfo.Params;
IEnumParams enm = pms.Enumerator;
IParam pm = enm.First;
IParam recvMsgHndl = pms.get_Item(0);
IParam recvMsgParam = pms.get_Item(1);
IParam recvWParam = pms.get_Item(2);
IParam recvLParam = pms.get_Item(3);

After reading all the data we require from the call, we will use our generated Xml to identify the message and properly cast it to its structure and show it properly.

The XML

The XML document in this application was created specifically to link together the message names, values and parameters. As messages like WM_LBUTTONDOWN are predefined as 0×201 we can place this in a XML file containing information on the parameters WPARAM and LPARAM.

<message value="0x201">
<name>WM_LBUTTONDOWN</name>
<return value="">
<returninfo></returninfo>
<returnmisc></returnmisc>
</return>
<wparam value="">
<wname>wParam</wname>
<wmisc>wParam Indicates whether various virtual keys are down. This parameter can be one or more of the following values.
MK_CONTROL
The CTRL key is down.
MK_LBUTTON
The left mouse button is down.
MK_MBUTTON
The middle mouse button is down.
MK_RBUTTON
The right mouse button is down.
MK_SHIFT
The SHIFT key is down.
MK_XBUTTON1
Windows 2000/XP: The first X button is down.
MK_XBUTTON2
Windows 2000/XP: The second X button is down.</wmisc>
</wparam>
<lparam value="">
<lname>lParam</lname>
<lmisc>lParam
The low-order word specifies the x-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area.
The high-order word specifies the y-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area.&amp;amp;amp;amp;lt;/lmisc&amp;amp;amp;amp;gt;
</lparam>
<misc></misc>

We could not find any database with this information, so we generated an XML document with the messages that we were interested in knowing about. As you can see, it is easy to simply add any message you want. In the process of building this XML, we used a very nice tool called ApiViewer from ActiveVB.de. Just search for the message names you want and you can evaluate the message values from the names.

The Cast

Now that we can identify the structures used on messages, we need to tell Deviare. Basically we are telling it to interpret our parameter, not as a simple LPARARM or WPARAM type, but as the complex structure we know is there. This is the case for messages like WM_DRAWITEM. So, to read it’s structure contained within the LPARAM we need to cast it as follows:

IParam pm = pms.get_Item(2); //LPARAM
pm = pm.CastTo(“LPDRAWITEMSTRUCT”); //Now our IParam is read as a pointer to DRAWITEMSTRUCT
pm = pm.Evaluated; //Resolve the pointer indirection
//Ready to use IParam as the structure sent by the OS.

It is possible to do this with all of the structures you can find defined in the windows headers. So, you should be able to cast and read any of them that are used in within these messages.

Using Deviare Message Spy

Deviare Message Spy in Action

Above we have our Deviare Message Spy in action. We selected the contacts list window from Outlook Express (at the bottom left) to spy on. You can see all the message values that were sent via Post and Send Message APIs. LVM_HITTEST has been expanded to show the full values received. As LPARAM is a pointer to the LVHITTESTINFO structure we can find all relevant information contained within.

Hope you enjoyed this article, and found it useful. Let us know what you think!

Requirements

• Deviare API Hooking

Known Issues

Many messages have the same Hex Address, such as TB_GETITEMRECT and TTM_UPDATE. Both of these messages have the value of 0×41d but are very different messages.

The TTM_UPDATE Message Forces the current tool to be redrawn. It does not use the wParam and lParam where as TB_GETITEMRECT Message Retrieves the bounding rectangle of a button in a toolbar.

TB is a Toolbar message and TTM is a Tooltip message. As our Spy++ style window finder already finds the window class, such as SysListView32 and ToolbarWindow32, It would be easy to use the class name to tell the program with Xml message is the correct one.

Resources

• Deviare API Hooking
• Message Lookup: ApiViewer
• Spy++ from the Microsoft Windows SDK

We are comparing our hooking engine Deviare with some of the other products available, so that you can get an idea of what each engine can provide.
Here is a comparison of Deviare against Easy Hook.

Functionality	Deviare	EasyHook
Database with Functions and Data Types	Yes	No
Intercept multiple functions with a single handler	Yes	No
Selective Handler for each Function	Yes	Yes
Relocation of Relative ASM Instructions (RIP)	Yes	No
Save & access Call Function Context	Yes	No
Access registers & flags	Yes	No
Access return address	Yes	Yes
Get/Set win32 last error	Yes	Yes
Monitor COM Objects creations	Yes	Partially
Hook COM Objects	Yes	No
Provides COM Interfaces accessible from any language	Yes	No
Enumerate process’ modules	Yes	Yes
Enumerate module’s exported functions	Yes	No
Get module path and info	Yes	Yes
Automated call of original function	Yes	No
Thread Deadlock Block	Yes	Yes
64 bits support	No	Yes
Thread Safe Hook Install	Yes	No
Native Support	Yes	Partially
Inter-Process Communication	Yes	Partially
Custom Library Injection	Yes	Yes
Stealth Support	No	Yes
Kernel Mode Hook	No	Yes
Driver Installation	No	Yes
Relocation of Instruction Pointer	Yes	No
Requires .Net Framework	No	Yes
Use System Runtimes (CRT)	Yes	No
Hook Terminal Sessions	No	Yes
Full unload before target termination.	Yes	No
Execute As Service	No	Yes
Prevent execution inside OS Loader	No	Yes
Thread selection filter	No	Yes
StackTrace	Yes	Yes
User-mode Wide Hook	Yes	No

We all remember when Ole Automation came out. We were all impressed how simple it was to implement a few COM Interfaces, place a toolbar and interact with the office package. Soon the competition began to show who could create the best and most creative Add-on. How many times did you wonder how that other plug-ins “did that”? What if now you can even know how Outlook, or any Office application operates? Well, my friend, take a closer a look…

This Deviare example is implemented as an Outlook Add-on. We have used C# .Net, but you can use any language that supports Component Object Model.

We are using 2 threads to avoid freezing the application. The first one is the standard thread where Outlook report its events to us. The second is our worker thread where we create an output window to print our messages and a Deviare Event Proxy to process functions’ calls.

From the events Outlook provides us to work with we are only interested in OnStartupComplete. Here we know that Outlook is done with all its initialization and we can start hooking its interfaces. As a regular plug-in we ask for the Outlook Application, Active Explorer, CommandBars and create a CommandBarButton. We are going to intercept all of them and see how their members are used.

Notice that to obtain the interface we don’t use the class implementation, but the underlying interface definition. That’s why, when calling HookInterface, we send the Type of Outlook._Application and not Outlook.Application. The second one, is the .Net wrapper, and the first one is the Ole Interface.

To intercept these objects, Deviare needs some information. The necessary elements are the COM Object Interface (that would be its virtual table), which members we are interested in (specified by index), and the name of the Interface. Identifying the interface by name, will let Deviare find all the information it needs during the call, so you can handle its parameters the same way we did with any function hook. To gather all this the .Net Framework provides us with marshaling facilities (System.Runtime.InteropServices.Marshal), this makes our lives pretty easy .

And that’s all. We print our calls, and see our results:

Cheers, and happy coding!

Today we have released a console for monitoring and spying on applications using Microsoft’s Component Object Model. This technology is used in many professional applications and now you are able to watch them in action too!

Deviare’s last integration is the ability to intercept COM interfaces. Using this technology and heuristics to discover this interfaces, the console lets you see which interfaces are being used by an application, and how they made their calls.

Here is an example monitoring the Windows Live Messenger:

As you have seen, we found the instantiation of IwebBrowser2. Since we don’t know what we want to see yet, we hooked every member except IDispatch (not necessary here). Then, the console printed calls for Navigate2 (among others), and we could see where the little browser at the bottom of messenger was getting its Adverts from.

The console is open source, so feel free to contribute on it. In this first release, it contains only one method to discover the creation of interfaces, but many others may be added. Go chase them .

Download Deviare COM Spy Console

Everyone has a lot of questions about Chrome.  Some people say that it is spyware because each and every character you enter is sent to Google.  Hundreds of comments like this can be found on the web, like this one that says “Chrome spends nearly as much time phoning home to Google as it does talking to other Web servers.”  On the other hand, you can also find on the web the opposite opinion that claims “If you do not wish this data to be sent to your search provider, you have a number of options: Use incognito mode, turn off search suggestions permanently or change your search provider.”

Who is correct?  What kind of information is really traveling between Chrome and Google?  What data about you is being sent to the web?  Is it true that Google’s browser sends details about everything you do?  Is it an unsafe browser?  What happens behind Incognito mode?

The first thing we want to know is “What information does Chrome send about visited sites to Google”? Many different opinions can be found on the web, and some are really alarming.  One person says that toolbarqueries.google.com collects everything the browser sends to it.  This is indeed true, and you can see in metrics_service.cc [chromium.org], what information about visited websites is being sent.  Although this only happens if you selected it in Chromes ‘Under the Hood’ (Options -> “Help make Google Chrome better by automatically sending usage statistics and crash reports to Google”) this option is not selected by default, you have to specifically select it during the Chrome installation.  Using SpyStudio you can be 100% certain about this by checking and un-checking the option, and watching all the ’send’ function calls.  So, does Google Chrome send information about every website you visit to toolbarqueries.google.com?  The answer is no, it does it only if you request it to.  This doesn’t mean that other information, like the one send to google-analytics, is not being sent anymore.

However it is interesting to notice that this behavior is exactly the same under Incognito mode.  This means that if the option of sending usage statistics is checked, it doesn’t matter what mode Chrome is running, the statistics are sent anyway.  We know that the only differences between normal and Incognito modes are the logging of websites visited, files downloaded, download histories and cookies.  So this feature is local to the machine, and nobody has said that statistics are not sent under this mode.  Although I think for many of us, we implicitly assume to be anonymous while running Chrome under Incognito mode.  So we better keep the limitations of this feature in mind!  Again, this only applies when sending statistics option is selected.

The other feature we want to inspect is the suggestion made by the address bar: “When you type URLs or queries in the address bar, the letters you type are sent to Google so the Suggest feature can automatically recommend terms or URLs you may be looking for.”  This is highly controversial, we want to know about this feature when using Incognito mode (in which the suggest feature seems to be automatically disabled). Again we can use SpyStudio to make sure.  You can see that Chrome does not send any information to Google about your key strokes when using Incognito mode.  You can also watch calls to GetAddrInfoW function, which provides protocol-independent translation from a Unicode host name to an address.
When you are not running on Incognito, you can turn this off by right clicking on the address bar and selecting “Edit search engines…” Then uncheck the check box at the bottom labeled “Use a suggestion service to help complete searches and URLs typed in the address bar”.

We can now safely stop all the paranoia about Chrome.  We can see the information that Google Chrome sends to Google using SpyStudio and we know that this depends on the options you choose.  So Chrome is not spyware that sends everything you do to Google.   I also believe it is important to understand what features the Incognito mode provides and not assume things about it.

Watch Google Chrome

See for yourself the information that Google Chrome sends to Google.  Use Nektra’s SpyStudio to monitor Chrome’s behavior.  It is very easy:

1. Download SpyStudio from Nektra’s website free of charge and install it.
2. Replace the database ‘deviare.fdb‘ with a new version.  You will find ‘deviare.fdb’ in the path you installed SpyStudio: \SpyStudio\bin
3. Download the script chromewatcher and then add the path where you saved it to SpyStudio.  Edit -> Preferences -> Python
4. Run SpyStudio and import the module chromeWatcher by typing “import chromeWatcher” in the Python console.  Then start monitoring by calling the Begin() function by typing “chromeWatcher.Begin()”.
5. Now watch SpyStudio while using Google Chrome to find out what information is sent by Chrome.

What does the ChromeWatcher script do?

The ChromeWatcher module was specially made to capture calls to the Winsock functions ‘send‘ and ‘WSASend‘. To know where the information is going, a socket connections track must be kept.  So it is necessary to hook ‘connect’ and ’select’ functions too.  The idea behind ChromeWatcher is to hook ’send’ and ‘WSASend’ calls that are made to Google and show them to you.
To understand better this script you can see SpyStudio documentation on: \SpyStudio\doc

Introduction

In this article we analyze Windows Live Messenger 8.5, that is the last version of MSN Messenger.Windows Live Messenger does provide a plugin api (Messenger, Add-ins, and more…) but the features exposed are a very limited subset. Also, this plugin support is not enabled by default and requires the user intervention.Moreover, as of January 3rd 2008 Windows Live Messenger Add-In API this interface is no longer supported.

Hooking

As messenger lacks of a public api we need a way to inject our code in it. There several way to do this, we will be reviewing only two of them.

System wide Hook

We need a hook dll injected in every process of the system. This can be achieved using a CBTProc that creates a system wide window hook. This proc has to check if we are inside Messenger and if it is true, load our dll that contains the code that we want to inject. The advantages of this method are that we are not modifying the installation of Messenger and we are using documented functions, so this approach is likely to work on every version of Windows. On the other hand, our hook dll will be injected in every process and updating requires a reboot that may look suspicious to Anti-Virus software.

Proxy DLL

The idea is to create a proxy dll that will have the same name that other dll used by Messenger. This proxy dll will load our dll when is loaded and will forward all the calls to the original one. In order to avoid renaming or moving system dlls, we can use the trick of placing our dll in the folder where msnmsgr.exe is located so according to Dynamic-Link Library Search Order it will be loaded before the original one placed in system32 folder. The advantage of this method is that affects only Messenger and does not requires to load a dll in every process. The disvantage is that it is associated to a specific version of Messenger.This trick is used by MsgPlus and its dll name is msimg32.dll How was Plus! done?.

Inside MSN Messenger

UI Controls

Previous version of Messenger used standard windows controls to display its UI, but in the latest versions they are using custom controls. Using Spy++ we can see that there is only one window with class name “DirectUIHWND”.

We can see in the picture that this windows lacks of any child window. There was some speculation about they were using windowless controls. These type of controls implement IAccessible interface so if we can obtain such interface we can query the object to look for other interfaces implemented. Unfortunately, most of the interfaces required by the windowless controls are not implemented here. The only interesting interface exported is IOleWindow, but instances of this interface return always the same DirectUIHWND window that is useless.Using Dependency Walker we can check what dlls are used and what is used of each one. One of them is msncore.dll that exports a bunch of C++ functions like DirectUI::NativeHWNDHost::NativeHWNDHost(void). This seems to be the dll used by messenger to display its UI. Further inspection of this dll reveals that it exports DllRegisterServer function. It looks as a COM server, but luckless executing ‘regsvr32 msncore.dll’ from the command line throws an error. After verifying in its resources, we did not find any TLB, so it will require much more research to see if we can get any useful interface from this ’server’.

Resources

The only known way to customize messenger UI is modifying the resources that it uses. These resources are placed in msgsres.dll, that is located in messenger folder. There are lots of sources of information about this type of solution such as How to skin WLM 8.1.This approach can be implemented in two ways: modifing the original file or changing the resource in memory. The first method is easier but has some problems: if the file is updated our changes are lost and antivirus software may warm the user about this modified file. The other method is more complex but lacks of these problems. Resources are usually loaded using LoadResource, LoadImage, etc.; if we can make Messenger get our modified resources instead of the original ones we have reached our goal.

Messenger Plugin Demo

Hooking with Deviare

In order to make Messenger load our modified resources we need to hook the following functions calls: FindResource, LoadResource, LockResource, SizeofResource. We are going to use Deviare API to easily install our hooks.We must know that UI resources are loaded the first time Messenger is loaded. So we need Deviare to notify whenever a new program is started. After creating our SpyManager instance, we can specify that we want to be notified of process creation in this way:

_spyManager->PutReportProcessCreation(_create_process_hook_and_polling, 0)

When OnProcessStarted event is triggered we check if msnmgr.exe was started. If the new process is messenger, we initialize our ResourceManager that installs our hooks. The code that install our hooks is in FunctionHook::Init in the file FunctionHook.h. Only function’s name and function’s module are needed (these are customized using template parameters, in our demo look at DECLARE_FUNCTION_HOOKED).

Managing Resources

ResourceManager receives the events of the hooked functions and modifies the resources we want to customize. It is very simple, it keeps a state of each resource we have to modify, and when requested we return our modified copy.The following call order FindResource → LoadResource → LockResource → SizeofResource is expected for each customized resource.

Adding a Button

We need to add our button to resource 4004:923 (resource type:resource id). This is done when we insert our string.

<Button cmdid=123 id=atom(nktbtn) AccRole=57 Class="TransparentButton" Layout=flowlayout(0,2,0,2)
Active=MouseandKeyboard|NoSyncFocus Padding=rect(5,4,5,4)>
<element class="ToolbarIcon" ID=Atom(ai402)/>
</Button>

To customize the aspect of our button we need to modify resource 4005:923.

Button[id=atom(nktbtn)]
{
accdesc:rcstr(3488);
ShortcutString:rcstr(3489);
AccName:rcstr(3490);
}
element[ID=Atom(ai402)]
{
content:rcimg(3000);
}

Customizing Resources

While customizing resources 4004:923 and 4005:923 is simple because they already exists, returning resources that do not exist is much trickier. Also, strings resources are grouped in 16 strings, check The format of string resources for more info.We customize these resources allocating memory inside Messenger using VirtualAllocEx and returning this address whenever our custom resources are requested. Our hook handler is called after the function fails trying to get invalid resource ids (that are the customized resource addresses). A more robust implementation should place the hook handler before the original function and skip calls when we detect our custom resources are requested.

Enhancements

• Resources are initialized multiple times, when only once will be enough.

Final Result

Demo source code

Requirements

• Visual Studio 2005.
• Windows Live Messenger 8.5.

Source code

Download plugin demo

Services

Nektra offers development services focused in Windows MSN Messenger Plugin Development

We have released the first version of Deviare. A free trial is available for download.Deviare is a component for ‘easy hooking’ of Windows DLLs. Now you don’t need to be an expert to incercept operating system functions because you use a COM object abstracting many of the complexities.To show the power look at the following code snippet in CSharp (.NET):

DeviareTools.IProcesses procs = _mgr.get_Processes(0);
DeviareTools.IProcess proc = procs.get_Item("msnmsgr.exe");
DeviareTools.IPEModuleInfo mod = proc.Modules.get_ModuleByName("ws2_32.dll");
DeviareTools.IExportedFunction fnc = mod.Functions.get_ItemByName("send");
hook = mgr.CreateHook(fnc);
hook.Attach(proc);
hook.OnFunctionCalled += new Deviare.DHookEvents_OnFunctionCalledEventHandler(hook_OnFunctionCalled);
hook.Properties = (int)DeviareCommonLib.HookFlags._call_before;
hook.Hook();
void hook_OnFunctionCalled(DeviareTools.Process proc,DeviareParams.ICallInfo callInfo, Deviare.IRemoteCall rCall)
{
DeviareParams.IParams pms = callInfo.Params;
DeviareParams.IEnumParams enm = pms.Enumerator;
DeviareParams.IParam pm = enm.First;
pm = enm.Next;
object[] args = new object[1];
string msg = "Transmition -> ";
msg += pm.Value;
msg += "\r\n";
args[0] = msg;
txtOutput.Invoke(new AppendHandler(Append), args);
}

With this simple code you hook the send function in the WinSock dll for the Messenger process and our own function hook_OnFunctionCalled is called before the ‘real send’The code can be written in any COM friendly programming language like: C++, C#, VB, Java, Python, Perl, Ruby and many others. API Hook examples in C++, C#, VB.Many applications can now be built on Deviare Technology like Spy Studio a tool to monitor Windows API and available for free.

As you may already know, Nektra core skills & knowledge can be briefly summarized in system internals & problem solving, innovation and creativity. We were working hard to introduce new products in the market and it’s very stimulating when you receive “Wows!” from people who can appreciate the complex stuff we have made.

Our next play is Spy Studio, Deviare, OEAPI for Vista & NKTWAB license change to LGPL:

Spy Studio is a new tool for hooking microsoft windows applications, it has an intuitive interface and you don’t need to be an expert in assembler or reverse engineering to insert hooks into different API’s or DLL’s. It has many interesting applications like seeing what your software is doing internally, and from the business perspective it’s very useful for monitoring, isolating processes access to some API or DLL, debugging, litigation & software forensics, support, software engineering blackbox testing, etc. You can download it now from here. We would be very glad to receive you comments in our forums

Deviare is the component to do your own applications and the framework used to develop Spy Studio. You can do your own hooking application with it, and extends Spy Studio’s possibilities to your own requirements, for example your own api monitors, administration tools, themes/skins/gui (i.e: scrollbar issues), posture agents, intrusion detection at the application level, etc.

OEAPI has been growing and now supports Vista’s Windows Mail in addition to Outlook Express. We are currently at the version 3.1.2 and 3.2.0 will be released very soon. OEAPI has really improved in demos, documentation, performance and capabilities. There is an updated list at What’s new section.

NKT WAB is now LGPL and it shows how to implement features not available or documented in the microsoft windows api. This component is useful for accessing the WAB (Windows Address Book), creating groups & folders and now supports Vista’s contacts too.

There is new stuff coming, but the most important thing is that our customers continue expressing their Wows!