OpenRCE: Blog

Cross Your Ts and Dot Your Filenames

Thu, 27 Mar 2008 02:55:00 -0500

I was developing some automation code recently and found that a process that I was injecting code into was crashing. At first I thought it was an error in my injected code, but when I looked at the crash-dump, I was amazed to see that the issue was in MFC42.DLL:

MOV EBX,104
PUSH EBX
LEA EAX,DWORD PTR SS:[EBP+szBuffer]
PUSH EAX
PUSH DWORD PTR DS:[ESI+6C]
CALL DWORD PTR DS:[<&KERNEL32.GetModuleFileNameA>
LEA EAX,DWORD PTR SS:[EBP+szBuffer]
PUSH 2E
PUSH EAX
CALL DWORD PTR DS:[<&msvcrt._mbsrchr>]
POP ECX
POP ECX
MOV DWORD PTR SS:[EBP-80],EAX
MOV BYTE PTR DS:[EAX],0 <-- Crash!

The code above is from MFC42.DLL, version 6.2.4131.0 from Windows XP SP2. It effectively does the following:

GetModuleFileName(NULL, szBuffer, MAX_PATH);
*(_mbsrchr(szBuffer, .)) = 0;

The function _mbsrchr(...) returns NULL if the character searched for is not found. This means that if there is no . in the current processs filename (which was the case for the file I was testing) then the highlighted line above will try to write the byte 0x00 to address 0x00000000, which will cause a crash.

I figured that this was some obscure function from MFC42.DLL that most applications dont make use of, however, after a little digging it turns out that this code is in CWinApp::SetCurrentHandles(), which is called by AfxWinInit(...). From http://msdn2.microsoft.com/en-us/library/w04bs753(vs.80).aspx:

"[AfxWinInit] is called by the MFC-supplied WinMain function, as part of the CWinApp initialization of a GUI-based application, to initialize MFC."

In other words, almost every MFC GUI program executes the code snippet above!

AAs surprised as I was by this, I figured that surely this had been fixed for Vista. Believe it or not, the same issue exists! Below is the code from MFC42.DLL version 6.6.8063.0 from Windows Vista Gold:

PUSH 104
LEA EDX,DWORD PTR SS:[EBP+szBuffer]
MOV [EDI+0C],ECX
MOV EAX,DWORD PTR DS:[ESI+6C]
PUSH EDX
PUSH EAX
CALL DWORD PTR DS:[<&KERNEL32.GetModuleFileNameA>
TEST EAX,EAX
JZ LOC_722F1484
CMP EAX,104
JZ LOC_722F1484
LEA ECX,[EBP+szBuffer]
PUSH 2E
PUSH ECX
CALL __mbsrchr
MOV EBX,EAX
ADD ESP,8
TEST EBX,EBX
MOV [EBP+VAR_310],EBX
JZ LOC_7230DB7D
...

__mbsrchr:
MOV EDI,EDI
PUSH EBP
MOV EBP,ESP
POP EBP
JMP DWORD PTR DS:[<&msvcrt._mbsrchr>]

LOC_7230DB7D:
...
JMP DWORD PTR DS:[<&msvcrt.CxxThrowException>]

While the code above checks for the lack of a . in the filename, it still throws an exception and causes a crash if theres no ..

The good news is that it doesnt seem easy to accidentally execute an executable file without a . in the filename in Vista:

C:>copy c:windows
otepad.exe notepad_exe
1 file(s) copied.

C:>notepad_exe
notepad_exe is not recognized as an internal or external command, operable program or batch file.

C:>start notepad_exe
[This opens the "Open With" dialog box in Explorer instead of executing the file.]

However, it is still possible to run non-dotted-files via API functions like CreateProcess(...) to cause the crash described above.

Refreshing the Taskbar Notification Area

Fri, 15 Feb 2008 18:06:00 -0600

I am working on an automation system that involves forcefully terminating a process that creates an icon in the Taskbar Notification Area (no, not the "system tray"). It is the responsibility of the process that creates an icon in the Taskbar Notification Area to remove the icon when the process exits, however, since I am using TerminateProcess(...) to remotely kill the process, the code to remove the icon never gets executed. As such, the icon remains in the Taskbar Notification Area until one moves the mouse cursor over the icon, at which point it disappears.

Since this is an automation system thats being developed, this icon-creating process will get executed many times, and if left unchecked would end up leaving hundreds of icons in the Taskbar Notification Area (one icon per execution). Thats bad.

Despite my best Googling efforts ("refresh notification area", "redraw system tray", etc.), I wasnt able to find elegant code to solve this problem. I found some novel solutions, though. The most common suggestion was to use SetCursor(...) to drag the mouse cursor around the Taskbar Notification Area; while this works, its an ugly hack and is actually quite slow. One of my "favorite" suggestions was to try to associate each icon in the Taskbar Notification Area with a process, then monitoring each process for termination, then deleting the icon once the given process terminates (talk about overkill... geeze).

When a user moves the mouse over a "dead icon" in the Taskbar Notification Area, some window message must get sent to the window to cause it to say to itself, "hey, the mouse is over me, so let me see if the process that created this icon is still alive.... Oh, its not? Let me remove the icon, then." I wanted to find what window message was causing that code to fire so that I could send that message to the window myself.

I started up Microsoft Spy++ and saw the following information for the Taskbar Notification Area and its parent windows:

A useful feature of Microsoft Spy++ is that it allows you to monitor window messages sent to a given window. I started monitoring the window messages getting sent to the "Notification Area" window without moving my mouse over the window and saw the following messages getting sent:

The messages above clearly had nothing to do with me moving my mouse (since I wasnt moving my mouse over the window), so I configured Microsoft Spy++ to filter out those messages. Then I moved my mouse over the "dead icon" in question and saw the following messages:

<00001> 00010056 S WM_NCHITTEST xPos:1491 yPos:1024
<00002> 00010056 R WM_NCHITTEST nHittest:HTCLIENT
<00003> 00010056 S WM_SETCURSOR hwnd:00010056 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00004> 00010056 R WM_SETCURSOR fHaltProcessing:False
<00005> 00010056 P WM_MOUSEMOVE fwKeys:0000 xPos:5 yPos:0
<00006> 00010056 S TB_HITTEST pptHitTest:022BFC18
<00007> 00010056 R TB_HITTEST iIndex:0
<00008> 00010056 S TB_DELETEBUTTON iButton:0
<00009> 00010056 R TB_DELETEBUTTON fSucceeded:True

Aha! So either WM_NCHITTEST, WM_SETCURSOR, WM_MOUSEMOVE, or TB_HITTEST leads to the TB_DELETEBUTTON getting sent. After trying to send each window message manually with SendMessage(...), I found which window message was the catalyst: WM_MOUSEMOVE.

With this new-found knowledge, I was able to whip up the following code to refresh the Taskbar Notification Area:

#define FW(x,y) FindWindowEx(x, NULL, y, L"")

void RefreshTaskbarNotificationArea()
{
    HWND hNotificationArea;
    RECT r;

    GetClientRect(
        hNotificationArea = FindWindowEx(
            FW(FW(FW(NULL, L"Shell_TrayWnd"), L"TrayNotifyWnd"), L"SysPager"),
            NULL,
            L"ToolbarWindow32",
            L"Notification Area"),
        &r);

    for (LONG x = 0; x < r.right; x += 5)
        for (LONG y = 0; y < r.bottom; y += 5)
            SendMessage(
                hNotificationArea,
                WM_MOUSEMOVE,
                0,
                (y << 16) + x);
}

Counting Lines of Source Code

Mon, 17 Sep 2007 20:51:00 -0500

Im reviewing the source code for a rather large project this week and I wanted to update my Facebook status by saying something like, "Jason is reviewing 100,000 lines of Java for security vulnerabilities." However, being the perfectionist that I am I wanted to give the real number of lines of code.

I wasnt aware of any built-in functionality in Visual Studio to do this, and after three minutes of Googling, I found a lot of Visual Studio plugins that could do this but unfortunately I didnt find any instructions on how to do this with just plain Visual Studio. And honestly, I didnt want to install a plugin (see http://blogs.msdn.com/oldnewthing/archive/2006/03/22/558007.aspx :)

I figured I could whip up a short C# program to do this, but even that seemed a little over-kill for such a simple task. Then I realized I could do this from a standard console window command prompt:

cmd /v:on
set lines = 0
for /r %a in (*.java) do (find /v /c "" "%a" > %temp% emp.txt
for /f "tokens=6" %b in (%temp% emp.txt) do (set /a lines += %b))
echo %lines%

The "tokens=6" part is specific to the source code directory structure for this particular project, and if any of the source code subdirectories contained spaces, youd have to tweak the code above a little. But hey, it worked out quite nicely, and it was a much cleaner solution than installing a plugin.

And Im sure theres an even shorter/simpler way to do this from a standard command prompt than with what I have above. Feel free to post cleaner "solutions" :)

(BTW, the actual number of lines turned out to be 348,523... that should keep me busy for a while.)

Investigating Outlooks Single-Instance Restriction (PART 2)

Sat, 01 Sep 2007 00:05:00 -0500

Please see PART 1.

While the return value of FindWindowA is used to determine whether or not Outlook terminates its process, theres another issues when it comes to using a separate profile.

Outlook calls MAPILogonEx without the MAPI_NEW_SESSION bit set. This causes Outlook to try to use an existing MAPI session if it can find one. Because of this, Outlook doesnt present the user with the option to choose a different profile in the second instance of Outlook; it will instead just use the profile that the first instance is using. (Why I didnt hit this issue in PART 1 is not clear.)

As such, to fully overcome Outlooks single-instance limitation, it is necessary to spoof the return value of the FindWindowA call in PART 1 and to set the MAPI_NEW_SESSION bit in the flFlags argument passed to MAPILogonEx.

Stateless Bi-Directional Proxy

Tue, 28 Aug 2007 20:33:00 -0500

After submitting my first patent two years ago to the US Patent Office, it has finally been published online!

You can read all the juicy details here and you can see diagrams here if you have a TIFF-renderer browser plug-in.

This patent was from when I was still on the Firewall team at Microsoft, so its network-related. The other patents of mine that should get published on the web over the next two years are from when I was on the Anti-Malware team at Microsoft, so theyre related to binary analysis... in other words, even cooler than this one ;)