ab origine ...

The power of IDA

    You can see the references to objects. A typical example: you have a procedure named 'A' and you want to see the code that invokes A. So, in A you see the XREFs string, which allows you to go to the place where A is invoked. Here is the screenshot:

 

 

Seems like "malware" may have a chance to exist under Windows Vista

Microsoft to give Vista kernel access to security firms - an interesting article that explains why Microsoft is going to publish new API to allow 3rd party security software to access the Vista kernel. This is a really amazing news, because once these gates will be opened to 3rd party security software they can be (theoretically) used by malware to gain the access to kernel.

Why does Windows do not provide more flexible API for Shell Context Menu Handlers?

My PC (XP SP2) was making some calculations. CPU activity was high. I was surfing through my folders and clicked on one of them using right button of the mouse. The context menu appeared after 10-20 seconds … “Why does it takes so long” -  I asked myself? This question leaded me to investigations …

Windows Shell supports so called ‘shell extensions’ which allow extending the functionality of shell. It allows 3^rd party products to write custom menu handlers that append own menu items to shell menu and help user easily use some feature of the product. Typical example of such approach is WinRar, WinZip applications. Shell extension is represented as COM component that implements several COM interfaces. I will concentrate here on IShellExtInit interface mostly.

So, when I click on my folders I see the following picture:

f

As you can see on screenshot I have WinRar shell extension installed on my PC. Seems like there is something inside it’s handler that cause delays.

Each shell extension object implements IShellExtInit interface. According to documentation, IShellExtInit has method named Initialize with the following params:

HRESULT Initialize(LPCITEMIDLIST pidlFolder, IDataObject *pdtobj,
                              HKEY hkeyProgID);

The IDataObject object passed to the method allows obtaining the path of folder user clicked on. One is able to get the handle to structure that contains file names and finally pass that handle to DragQueryFile function to get the path. DragQueryFile function is defined with following parameters:

INT DragQueryFile(HDROP hDrop, UINT iFile, LPTSTR lpszFile,
                             UINT cch);   

I can set breakpoint in WinDbg to DrawQueryFileA/ DrawQueryFileW functions to see where they are called. This gives me ability to check what extensions are calling this function, and what is going on in Initialize method of each extension.

Following commands do that:

0:001> bp DragQueryFileA
0:001> bp DragQueryFileW

Here is what I see in command line after executing “bl”:  

 
Now I am going to click on folder and see where DrawQueryFile is called. I click on a folder, and I see the following places where the rarext.dll calls DrawQueryFile:

; first call
02d0c44d 6a00            push    0
02d0c44f 6a00            push    0
02d0c451 6aff            push    0FFFFFFFFh
02d0c453 ff75d4          push    dword ptr [ebp-2Ch]
02d0c456 e881a90000      call    rarext!DllCanUnloadNow+0xc0ac (02d16ddc)

; second call
02d0c491 6800040000      push    400h
02d0c496 8d85bcfbffff    lea     eax,[ebp-444h]
02d0c49c 50              push    eax
02d0c49d 8bfb            mov     edi,ebx
02d0c49f 57              push    edi
02d0c4a0 ff75d4          push    dword ptr [ebp-2Ch]
02d0c4a3 e834a90000      call    rarext!DllCanUnloadNow+0xc0ac (02d16ddc)

; third call
02d0c4b1 6800080000      push    800h
02d0c4b6 8d85bcf3ffff    lea     eax,[ebp-0C44h]
02d0c4bc 50              push    eax
02d0c4bd 57              push    edi
02d0c4be ff75d4          push    dword ptr [ebp-2Ch]
02d0c4c1 e81ca90000      call    rarext!DllCanUnloadNow+0xc0b2 (02d16de2)

In all cases the intstruction «call rarext!DllCanUnloadNow+address” is mapped to the call to DragQueryFile(A|W). Following code at rarext!DllCanUnloadNow+address shows that:

02d16ddc jmp dword ptr [rarext!__CPPdebugHook+0xc1bc (02d233e8)] ds:0023:02d233e8={SHELL32!DragQueryFileA (7ca73fb3)}

02d16de2 jmp dword ptr [rarext!__CPPdebugHook+0xc1c0 (02d233ec)] ds:0023:02d233ec={SHELL32!DragQueryFileW (7ca1fcee)}

Let me do some explanations on what is going in the code mentioned above. The first call is used to obtain the number of files user selected. It can be seen by the 0FFFFFFFFh value passed to DragQueryFile as iFile parameter. According to documentation:

- iFile
Index of the file to query. If the value of the iFile parameter is 0xFFFFFFFF, DragQueryFile returns a count of the files dropped.

Second call is made to obtain the ANSI version of path and the third call is made to obtain the UNICODE version of path. So pity, that developers of WinRar do not know what MultiByteToWideChar do and that it’s much faster then calling DragQueryFileW function. However, I want to concentrate on another issue.

In IShellExtInit::Initialize handler any shell extension almost always does the same things. It calls DragQueryFile to obtain the number of selected files, and then call DragQueryFile to query the path to a file. Imagine, that I have 10 shell extensions that need to know what file was selected by the user. Most likely they will implement the same functionality in its code. The list of following operations will be performed:

-         call DragQueryFile to get number of selected files

-         call DragQueryFile in a loop for each file to get it’s path

-         do some logics.

Graphically, this can be represented in the following way:

  
From this scheme you can see that most shell extensions do almost the same steps in order to get the list of selected files. I wonder, why Shell team did not make some more flexible and efficient solution that allows to avoid this overhead?

For example, by passing the list of selected files into the Initialize function. This will significantly decrease the amount of code need to be written by shell extensions writers and, on the other side, it will be more efficient because there will be no need to make a huge amount of calls to DragQueryFile for each shell extension module.

www.sysinternals.com is gone

There is no www.sysinternals.com already.

If you try to navigate to Mark's web site you will find that it redirects to http://www.microsoft.com/technet/sysinternals/default.mspx. Since Microsoft acquired Sysinternals in July, 2006 it  already changed the project a bit ...

Developers Days in Kiev, Ukraine. Novermber 10, 2006

If you live in Ukriane you have a chance to visit Microsoft Developers Days that will take place in Kiev on 10-th of November 2006. For more details visit the following link: http://www.microsoft.com/Ukraine/Events/DevelopersDaysAutumn2006/Kiev.mspx

I am not going to visit it because I live in a bit different world now. There is no Ajax, WF, WPF here.

Russian guy in Windows Kernel Team ...

Here is an interesting blog I read from time to time: http://blog.not-a-kernel-guy.com/.

Unfortunately the blog is written in russian, so those of you who does not know it need to use translation tools. The blogger name is Alexey Pakhunov and he works as a developer in Windows Kernel Team.

TDI Filter drivers in Vista: new article is coming

Choosing the undocumented ways when dealing with security. General thoughts.

There is some kind of a struggle in the newsgroups between those who accepts the ‘undocumented’ programming and those who does not. I will try to express my thoughts concerning this issue here.

Nowadays, all popular AntiVirus (AV) software products can be divided into two main groups:

-         those who has protection (and use undocumented staff)

-         and those who does not (and use only documented approaches)

The ‘protection’ in this context is just some logical part of the product which ensures that AV cannot be terminated by malware modules. The protection logics can be implemented only using undocumented approaches, because Windows does not provide interfaces to ensure that some code should always keep running. Instead, Windows API provides flexible way to manage system resources. This of course, means that any entity can obtain access to resources if it has appropriate rights.

Such situation leads to the following scenario.

-         The malware module is able to terminate (any) process if it has appropriate rights.

-         The malwares also can modify the memory, context, PEB, and other properties of a process and make everything it wants in order to … hide its activity.

-         Malware also can be represented as a rootkit – this is even worse, because rootkits have extremely big power, since they operate in kernel mode.

-         …

AntiVirus software also tries to do its best. Those who does not have protection scheme or those who does not use undocumented techniques fall into the limited ability to control the system. In this situation the AntiVirus software tries to fully control and filter all threats that are coming through acceptable for controlling channels.

A typical example of the written above is the powerful heuristics that is used in combination with file system filter driver (fully documented approach), which does not allow malware even to be copied on the target PC. And thus, there is no need to protect AV module – because heuristics will do the job. The disadvantage of this way is that if the system makes error – i.e. it treats malware as a normal executable, it (possibly) has no chances to control the system after the one mistake …

However, there is another approach. Combining documented ways with the undocumented. This involves new challenges and brings new problems. Undocumented is prone to changes. It means that once next build of OS or SP will be shipped AV makers probably will need to rewrite their code. In this case they may even globally change the architecture of the product because some major features can be cut from OS.

The positive side of this approach is that it provides extended challenges to control the OS. Thus, properly written AV that uses protection schemes is almost impossible to bypass by malware. Why I say ‘impossible’? Because software programs are written by the people. People do mistakes. If there is a need to bypass AV the malware writer can use exotic ways to accomplish that. I will discuss these ways later in my next posts.

Summarizing.

‘Protection’ is a set of complex methods that allows controlling different facilities of operating system. These facilities cannot be controlled without interaction with undocumented techniques, because public API gives you a limited ability to control OS. The more directions are controlled the higher possibility that you may catch the bad thing ‘on a fly’ and do not allow it to harm your OS.