ab origine ... : reversing

Phishing on Saturday ...

V. S. — Sun, 21 Jun 2009 10:41:00 GMT

It’s quite often to happen with average user on the Internet – to recieve spam. Sometimes it advertises some junk, but sometimes it asks user to run some executable which does some magic, for example, it allows to send sms to any mobile operator...(read more)

A case of mysterious BSOD at tcpip!TcpIndicateData+22b

V. S. — Wed, 09 Jul 2008 03:01:00 GMT

1. The causes Recently I was observing strange BSODs on my Vista machine quite periodically when dealing with network applications: [...] Please, read the rest of this post at http://www.shcherbyna.com/?p=117...(read more)

The case of Task Manager that does not kill

V. S. — Thu, 20 Dec 2007 21:42:00 GMT

Quite long time ago, my friend Vadym Stetsiak described a bug of Task Manager , which allows to disallow (!) the killing of a process, if it's name is lsass.exe. In order to test this bug, you can rename any executable file into lsass.exe, run it...(read more)

Undefeatable files & folders in Windows XP SP2 - a bug in SHFileOperationW

V. S. — Sat, 14 Jul 2007 23:01:00 GMT

Recently I was surprised with one interesting behavior of my Windows XP box. I was playing with long name files and noticed that major part of my shell extensions do not work with files, whose path is longer then 260 symbols. I also noticed, that Windows...(read more)

The case of IE7 that would not run

V. S. — Sat, 02 Dec 2006 00:27:00 GMT

Yesterday I met an interesting behavior of IE7. On one of my computer which runs Windows Server 2003 SP1 I was trying to publish a post to my blog ('the power of IDA'). But I failed to do that. IE7 was crashing when I tried to write something in the editor...(read more)

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

V. S. — Fri, 17 Nov 2006 00:01:00 GMT

Recently, I came across an interesting situation.

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:

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.

OllyDbg, Windows XP SP2 (32-bit) and Kaspersky Antivirus

V. S. — Thu, 19 Oct 2006 18:43:00 GMT

I use OllyDbg debugger from time to time. The most wonderful debugger I ever seen: it's light, powerful and does not require installation ... This evening I got a few BSOD's on my Windows XP SP2 after running OllyDbg. So I started the investigations.

Analyzing minidump using WinDbg showed that system went down because of csrss.exe crash. This actually does not answer the question: why exactly OllyDbg causes BSODing. Debugging OllyDbg using WinDbg I found the function where the system dies:

ntdll!KiUserApcDispatcher:
7c90eac0 8d7c2410        lea     edi,[esp+10h]
7c90eac4 58              pop     eax
7c90eac5 ffd0            call    eax
7c90eac7 6a01            push    1
7c90eac9 57              push    edi
7c90eaca e84aebffff      call    ntdll!ZwContinue (7c90d619)

Done! Once I realized it's connected with kernel I remembered that recently I installed Kaspersky Antivirus...Uninstalling antivirus solved the problem.

Sometimes you DO need to invent the wheels

V. S. — Thu, 19 Oct 2006 11:19:00 GMT

There is a well-known approach that states 'there is no need to re-invent the wheel'. In other words, it means that if you decided to implement some functionality in your program, you should googlize to make sure it's not implemented by other people and if it is then just use it and don't waste the time. The time seems to be very important in software development cycle. Sure.

Nice. But in fact there are some problems.

In any operating system to reuse some functionality you need some interfaces to be exposed to communicate with them. Let's say your program should load some library and communicate with it via exported functions. It gives your application the flexibility - you may load/unload the code you want to run any time, the only one problem is that: in most cases you cannot control the code.

I will omit the scenario when the library that contains needed for your program functionality is developed by the developer in your company. I want to tell about the scenario when your application uses different components from different vendors.

So let's say you have the video rendering application. The application takes the video file as the input and produces the screenshots as the output. The application uses COM to communicate with Microsoft DirectShow (DS) 9.0.

This is what I told above: application uses DS interfaces to process the video file. It does not even know what components implement those interfaces - your application really does not care about it... And this causes a lot of problems(all problems refer to using inproc server):

- when your application process video using 3rd party codecs you cannot control memory allocation/dealloaction by the codec

- the 3rd pary component code have an access to your application memory: thus it may cause heap corruption, etc

- exotic situations (like described below)

My exotic case was connected with strange MessageBox I saw when debugging my application. The following call to IFilterGraph->Connect(...) showed message box like this:

The output window contains list of interesting strings:

'console.exe': Loaded 'D:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax', Binary was not built with debug information.
'console.exe': Loaded 'D:\WINDOWS\system32\ddraw.dll', No symbols loaded.
'console.exe': Loaded 'D:\WINDOWS\system32\dciman32.dll', No symbols loaded.
First-chance exception at 0x04eca8ed in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04ec9ed6 in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04eca0e7 in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04eca225 in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04ec7e76 in console.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x04ec7fcb in console.exe: 0xC0000005: Access violation writing location 0x00000000.

Looking at 'D:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax' sections:

answers the question: the dll file is packed using AsProtect protector - the typical behavour of protector is to add 'adata' section. The message box I saw was the protection action of AsProtect. It detects my Visual Studio debugger as WinIce/SoftIce (I don't have none of them installed) and terminate my process.

Now I back to the topic of my post. If somebody invented the wheel for you, make sure it's safe. In this situation I can only deinstall Nero codecs and never install them again...

IE 7 Beta 3 bugs ...

V. S. — Sat, 08 Jul 2006 17:44:00 GMT

I installed yesterday IE 7 Beta 3 (for XP SP2 32bit) and now I realize that it contains a lot of bugs. It crashes mostly when you navigate to "specific urls". Here is the steps to reproduce:

- login to msmvsps.com
- goto http://msmvps.com/ControlPanel/Blogs/articlelist.aspx
- click on "New Article" button
- wait untill IE7 dies

Error report is as always not imformative, I used OllyDbg debbuger to attach to process to see the "details" of a crash. Look at attached screenshot.

P.S. Issue has been submitted here

Finally Microsoft implemented InternetReadFileExW function ...

V. S. — Fri, 07 Jul 2006 15:17:00 GMT

Some time ago I was surprised when noticed that UNICODE version of WinInet function InternetReadFileEx is not implemented. Disassembling wininet.dll gave me the following results:

.text:000007FF7D0D16A0 ; InternetReadFileExW proc near
.text:000007FF7D0D16A0                 sub     rsp, 28h
.text:000007FF7D0D16A4                 mov     ecx, 78h
.text:000007FF7D0D16A9                 call    cs:SetLastError
.text:000007FF7D0D16AF                 xor     eax, eax
.text:000007FF7D0D16B1                 add     rsp, 28h
.text:000007FF7D0D16B5                 retn
.text:000007FF7D0D16B5 InternetReadFileExW endp

So InternetReadFileExW just was calling SetLastError(120); which means that this function is not impelemneted on the target system. The problem is: at that time official documentation stated that InternetReadFileExW is implemented!

I wrote several letters to MSFT about this issue, but they just forgot about me - there were no reply concerning my problem. Now I see that starting with IE7 Beta Microsoft implemented this function as a quick hack - it simply calls InternetReadFileExA:

.text:6302FDC7                 public InternetReadFileExW
.text:6302FDC7 InternetReadFileExW proc near
.text:6302FDC7
.text:6302FDC7 hFile           = dword ptr 8
.text:6302FDC7 lpBuffersOut    = dword ptr 0Ch
.text:6302FDC7 dwFlags         = dword ptr 10h
.text:6302FDC7 dwContext       = dword ptr 14h
.text:6302FDC7
.text:6302FDC7                 mov     edi, edi
.text:6302FDC9                 push    ebp
.text:6302FDCA                 mov     ebp, esp
.text:6302FDCC                 mov     eax, [ebp+lpBuffersOut]
.text:6302FDCF                 push    esi
.text:6302FDD0                 xor     esi, esi
.text:6302FDD2                 cmp     eax, esi
.text:6302FDD4                 jz      short loc_6302FDF3
.text:6302FDD6                 cmp     [eax+8], esi
.text:6302FDD9                 jnz     short loc_6302FDF3
.text:6302FDDB                 push    [ebp+dwContext] ; dwContext
.text:6302FDDE                 push    [ebp+dwFlags]   ; dwFlags
.text:6302FDE1                 push    eax             ; lpBuffersOut
.text:6302FDE2                 push    [ebp+hFile]     ; hFile
.text:6302FDE5                 call    InternetReadFileExA
.text:6302FDEA                 mov     esi, eax
.text:6302FDEC
.text:6302FDEC loc_6302FDEC:

.text:6302FDEC                 mov     eax, esi
.text:6302FDEE                 pop     esi
.text:6302FDEF                 pop     ebp
.text:6302FDF0                 retn    10h
.text:6302FDF3 ; ---------------------------------------------------------------------------
.text:6302FDF3
..text:6302FDF3                 push    57h
.text:6302FDF5                 jmp     loc_63044AE6
.text:6302FDF5 InternetReadFileExW endp