Yesterday I have had the opportunity to try this device for my very first time. It’s a nice toy, these buttons are really helpful sometimes. The interesting part is that you can write your own plugin making the device really powerful, shortcuts are useful for most of the applications out there. Art Lebedev offers some plugins but if you want a specific plugin you have to code it by yourself.
It’s really easy to develop a plugin, you can download the plugin skeleton directly from developer’s page to start with. There are some versions, I’ll use the C++ version.
Just to take some confidence with this new device I wrote my first plugin. When I have to learn something new I always start from the basics, the first plugin is a slightly change of the plugin skeleton provided by AL.
My first try it’s a VLC plugin. VLC is my preferred video player and the aim of the plugin is to play/pause a movie simply pressing one of the three mini keyboard buttons. As you’ll see it’s very simple and at the sime very easy to develop.
The core of the skeleton plugin is the file OptPlugin.h. The file contains some define, some macro and the main class definition. Yes, the plugin is class based and the main class is called OptimusMiniPlugin. When you write a plugin you basically define a new class derived from OptimusMiniPlugin implementing the defined methods. The predefined methods are:
- Paint: used to paint the screen
- OnKeyDown: called when the button has been pressed
- GetInfo: your personal “about” system
- GetProperty: allows to get properties from plug-in instance
- SetProperty: allows to set plug-in instance properties
- ShowProperties: shows plug-in properties dialog
- OnEvent: used to control one or more possible events
If you want to write a plugin these are the functions you have to deal with. Obviously you can use them all, delete some of them and so on, it depends on what you want to do with your plugin. I haven’t included all these methods because I’m only interested in some of them, I use:
- Paint
I use the function for showing the current state of the player. At the moment there are two states only: VLC is not running and VLC is running. This method shows the right icon for the current plugin state, nothing more.
BOOL __stdcall Paint(HDC hdc)
{
// VLC is running?
if ((FindWindow(NULL, “VLC media player”)))
{
// VLC is running, do I have to display the new icon state?
if (!running)
{
DoPaint(hdc, IDI_PLAY); // Show the new icon
running = TRUE;
return TRUE;
}
}
else
{
// VLC is not running, do I have to display the new icon state?
if (running)
{
DoPaint(hdc, IDI_NO_VLC); // Show the new icon
running = FALSE;
return TRUE;
}
}
return FALSE;
}
Paint function is called many times and it’s useless to paint the scene everytime. I only let it paint when the state changes, that’s why I use the running member.
- GetInfo
LPARAM __stdcall GetInfo(int index)
{
GET_INFO(INFO_NAME, “VLC player”);
GET_INFO(INFO_DESC, “Simple plugin for VLC player”);
GET_INFO(INFO_AUTHOR, “ZaiRoN”);
GET_INFO(INFO_EMAIL, “zaironcrk@hotmail.com” );
GET_INFO(INFO_HOMEPAGE, “http://www.zairon.wordpress.com”);
return 0;
}
Some info for the about box…
- OnKeyDown
When the button has been pressed (and VLC is running) I have to play (or pause) the video. How to perform such operation from an external application? I don’t know if VLC has a script engine really. With the engine it could be possible to control the player in an easy way but without it the only way is to use the good old SendMessage method. The idea is to send a specific message to VLC. I’ll tell VLC to play and pause a file using SendMessage. First of all let’s see how SendMessage looks like:
LRESULT SendMessage(
HWND hWnd, // The window designed to receive the message
UINT Msg, // The message to send
WPARAM wParam, // wParam, depends on the message
LPARAM lParam // lParam, depends on the message
);
To find out the handle of VLC window is pretty easy, just use FindWindow as I did in Paint function.
What about the message to send? For this purpose I used Spy++, a little (but very useful) program that comes with Visual Studio pack. The tool shows me the message I was looking for. It’s WM_COMMAND with wParam equal to 0×6020. VLC uses the same wParam for both play/pause commands. Here is how my OnKeyDown function looks like:
void __stdcall OnKeyDown()
{
HWND hVLC = NULL;
// Message is sent if and only if VLC is running
if ((hVLC = FindWindow(NULL, “VLC media player”)))
PostMessage(hVLC, WM_COMMAND, 6020, 0); // Start/Pause command
}
Believe it or not this is the core of the plugin! Few lines of code and voilà, the plugin is done.
The plugin is really simple but as you can see it’s really easy to develop a plugin… just use some imagination.
Attached here the source code of the project (About the two icons, they are simply horrible I know… I’m not a graphic designer).
Like this:
Like Loading...
Here are some notes on a rootkit technique called System Service Dispatch Table Hook. The technique is very popular in malware nowadays, that’s because it’s relatively easy to code. It’s dangerous and powerful, but at the same time it’s pretty easy to identify this kind of hook.
The table contains several pointers, each one points to a specific Nt* function. The idea is to hook a function changing the pointer inside the table. This is possible with a simple patch. Almost all the malwares use this kind of hook in order to hide files.
There are so many malwares around using this particular technique, if you want to follow this little article you can download the Haxdoor malware (MD5: ebf923c9845b3a0b1c29f4b845094855), available at http://www.offensivecomputing.com.
From now on I’ll refer to System Service Dispatch Table using the acronym SSDT.
Approaching the malware
As often happens the malware is packed. This is not a big problem because it’s packed by FSG 2 and it’s pretty easy to reach the original entry point in few seconds. I don’t need to unpack the file because the interesting things are inside the files that are created at runtime by the first one. Most of the time the malware contains some initializations only, the real malware is represented by the files that are created at runtime. As often happens the first file creates two new files, a dll and a sys file. I’ll focus my attention on the sys file only because the hook is inside it.
Analysis of the sys file
Load the driver inside a disassembler and start looking inside DriverEntry routine. Focus your attention on the last lines of code of the procedure, it’s the point where the dispatch functions are assigned:
00010821 mov edx, [ebp+DriverObject]
00010824 mov dword ptr [edx+38h], offset sub_105AC ; IRP_MJ_CREATE
0001082B mov dword ptr [edx+70h], offset sub_105AC ; IRP_MJ_DEVICE_CONTROL
The driver handles two IRPs, IRP_MJ_CREATE and IRP_MJ_DEVICE_CONTROL. How do I know such informations? It’s pretty easy when you know the structure involved, driver object structure is defined as:
typedef struct _DRIVER_OBJECT {
CSHORT Type; // +0×000
CSHORT Size; // +0×002
PDEVICE_OBJECT DeviceObject; // +0×004
ULONG Flags; // +0×008
PVOID DriverStart; // +0x00C
ULONG DriverSize; // +0×010
PVOID DriverSection; // +0×014
PDRIVER_EXTENSION DriverExtension; // +0×018
UNICODE_STRING DriverName; // +0x01C
PUNICODE_STRING HardwareDatabase; // +0×024
PFAST_IO_DISPATCH FastIoDispatch; // +0×028
PDRIVER_INITIALIZE DriverInit; // +0x02C
PDRIVER_STARTIO DriverStartIo; // +0×030
PDRIVER_UNLOAD DriverUnload; // +0×034
PDRIVER_DISPATCH MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1]; // +0×038}
DRIVER_OBJECT;
typedef struct _DRIVER_OBJECT *PDRIVER_OBJECT;
#define IRP_MJ_MAXIMUM_FUNCTION 0x1B
The structure is taken from ntddk.h. As you can see the space for the IRPs is defined at the end of the structure definition, I’m referring to the array of 0x1C elements. One elements for each IRP. In this particular case the IRPs used by the driver are taken from _DRIVER_OBJECT+0×38 and _DRIVER_OBJECT+0×70. They are IRP_MJ_CREATE and IRP_MJ_DEVICE_CONTROL. The dispatch routine is only one, but it will handle them without problems.
Hook steps
Now that I know where to look at, I can try to identify where the hook occours. The technique is more or less always the same and it consists in some simple steps:
1. disable write protection
2. locate the necessary structures
3. patch the table
4. enable write protection
The code used to perform these four steps is all included inside a procedure, the driver dispatch routine. There is a lot of theory behind these four points. I don’t want to annoy you with too many definitions and stuff like that, but I’ll take the way I like: “Improvise. Adapt. Overcome”.
1. Disable write protection
This first task is necessary because without disabling the write protection the malware won’t be able to patch the SSDT. To perform the operation you only need few instructions:
mov eax, cr0
and eax, 0FFFEFFFFh
mov cr0, eax
The value of CR0 (one of the control registers) is moved in eax. According to Intel manual #3, CR0 contains system control flags that control operating mode and states of the processor. The register is composed by bits and every bit (or a group of bits) has his own definition. The ‘and’ instruction is used to set Write Protect bit (CR0′s bit_16) to 0. Once disabled you are allowed to overwrite one or more memory byte.
Here is the snippet used by the malware I’m currently checking:
00010521 mov eax, cr0
00010524 push eax ; Push the original state: Write Protection enable
00010525 mov edi, 0FFFEFFFFh
0001052A and eax, edi
0001052C mov cr0, eax
Some more instructions but the result is the same.
2. Locate the necessary structures
As I stated some lines above, it’s all inside a single procedure. Look at the instruction after the CR0 patch, you’ll see three interesting instructions:
0001052F mov eax, offset KeServiceDescriptorTable ; 1
00010534 mov edi, [eax] ; 2
00010536 mov eax, [edi] ; 3
(1) First of all it takes the address of something called KeServiceDescriptorTable. What is it? It’s a table containing 4 pointers. Each element points to a specific structure. The table pointed by KeServiceDescriptorTable is defined as:
typedef struct _SERVICE_DESCRIPTOR_TABLE {
SYSTEM_SERVICE_DESCRIPTOR_ENTRY ntoskrnl; // Entry for ntoskrnl.exe
SYSTEM_SERVICE_DESCRIPTOR_ENTRY win32k; // Entry for win32k.sys
SYSTEM_SERVICE_DESCRIPTOR_ENTRY sst3; // Reserved, not used
SYSTEM_SERVICE_DESCRIPTOR_ENTRY sst4; // Reserved, not used
} SERVICE_DESCRIPTOR_TABLE, *PSERVICE_DESCRIPTOR_TABLE, **PPSERVICE_DESCRIPTOR_TABLE;]
(2) The first entry is taken from KeServiceDescriptorTable. This is the pointer to a System Service Descriptor Entry, the one for ntoskrnl. The structure is defined as:
typedef struct _SYSTEM_SERVICE_DESCRIPTOR_ENTRY {
PULONG ServiceTableBase; // Base address of the SSDT
PULONG ServiceCounterTableBase;
ULONG NumberOfServices; // Number of services described by ServiceTableBase
PCHAR ParamTableBase; // Base address of the table containing the number of parameter bytes for each of the system services
} SYSTEM_SERVICE_DESCRIPTOR_ENTRY, *PSYSTEM_SERVICE_DESCRIPTOR_ENTRY, **PPSYSTEM_SERVICE_DESCRIPTOR_ENTRY;
There are four elements but a malware is always interested in the first one only. The other elements are useful if you want to code a SSDT reader or something like that.
(3) eax points to the SSDT. The table contains NumberOfServices elements and each one points to a dispatch routine. Each element is represented by a single double word containing the address of the service function. If you have a ring-0 debugger you can see all the services inside the table. With Softice a simple ‘u’ followed by the address of the service will reveal the code and the name of the service.
3. Patch the table
Now, the malware has the table’s initial address and it’s ready to install the hook:
00010538 mov edx, dword_10BC2 ; ID of the function to hook: 0×30
0001053E inc edx
0001053F jz short loc_10559
00010541 dec edx
00010542 mov ebx, offset sub_10393 ; New function, it replaces the hooked one
00010547 cmp dword_10BD2, 0
0001054E jnz short loc_10559
00010550 xchg ebx, [eax+edx*4] ; Exchange instruction, perform the hook
A little snippet showing how to install the first hook. The idea is really simple: the malware exchanges the original address of the function ‘x’ with the address of a function ‘y’ (located inside the malware). As you can imagine, when a request for the function ‘x’ is done the system calls the new function ‘y’ and ignore ‘x’. ‘x’ will be executed if and only if ‘y’ calls it. In this specific case the hooked function is NtCreateProcessEx (index 0×30), the function is replaced with the new one located at offset 0×393. I won’t inspect the new function because I’m not interested in it.
4. Enable write protection
And now the last part of the process. The malware enables write protection again. This part is the mirror of part 1. There are some different ways, the malware uses this one:
000105A4 pop eax ; Retrieve cr0′s original status (Write Protection enable)
000105A5 mov cr0, eax ; Restore the original status
In the end
Really easy to identify, really easy to understand… there’s nothing more to say about this type of hook!
Like this:
Like Loading...
