Archive for the ‘Internals’ Category

Filter Monitor 1.0.1

Saturday, October 17th, 2009

This week, after months of development of bigger projects, I found some time to windbg “ntoskrnl.exe” and write a utility. It is called Filter Monitor and shows some key filters installed by kernel mode components.

“As you probably all know the Service Descriptor Table has been a playground on x86 for all sorts of things: rootkits, anti-viruses, system monitors etc. On x64 modifying the Service Descriptor Table is no longer possible, at least not without subverting the Patch Guard technology.

Thus, programs have now to rely on the filtering/notification technologies provided by Microsoft. And that’s why I wrote this little utility which monitors some key filters.

Since I haven’t signed the driver of my utility, you have to press F8 at boot time and then select the “Disable Driver Signature Enforcement” option. If you have a multiple boot screen like myself, then you can take your time. Otherwise you have to press F8 frenetically to not miss right moment.

A disclaimer: the boot process can be a bit annoying, but the utility should be used on virtualized systems anyway, as I haven’t fully tested it yet. I doubt that it will crash your system, I guess the worst scenario is that it won’t list some filters. It should work on any Windows system starting from Vista RTM and I have provided an x86 version and an x64 version. But the truth is that I have tested only the x64 version on Windows 7 RTM. Last but not least, I can’t guarantee that this utility will work on future versions of Windows, it relies heavily on system internals.

Now, let’s run it. The supported filters/notifications at the time are these: Registry, Create Process, Create Thread and Load Image. “Registry” stands for CmRegisterCallback filters. “Create Process” for PsSetCreateProcessNotifyRoutine callbacks. “Create Thread” for PsSetCreateThreadNotifyRoutine callbacks. And “Load Image” for PsSetLoadImageNotifyRoutine callbacks.

The “Additional Info” in the list view provides internal information like the address of the callback function.

There are some default filters registered by system components, but, as you can notice, there are also Kaspersky components. That’s because some filters (like the registry filter) are not used by system components and I needed a tool which would make use of these filters for my little demonstration.

The version of Kaspersky I have installed is the latest one available on the internet which is: 9.0.0.463.

I created for this demonstration a little executable called “k-test” (what you see on the desktop are three copies of the same executable) which copies itself in a directory called “borda” in the “Roaming” directory of the operating system. It then creates a value in the Run key of the registry to execute itself at each start-up. Finally, it launches itself from the “Roaming” directory and ends.

This is a typical malware behavior. Beware that the signature of the application itself is not contained in the databases of Kaspersky as I have written it on the fly, but it detects the suspicious behavior, stops execution and deletes the file. And it does this every time I launch the test application.

Now let’s get to the part where I show an additional functionality of the Filter Monitor which is the ability to remove registered filters and see what happens if I remove the filters installed by klif.sys, which is the “Kaspersky Lab Interceptor and Filter” driver. As the name suggests, this driver intercepts and filters: it installs all four of typologies of filters listed by the Filter Monitor. On x86 instead of calling CmRegisterCallback it additionally hooks about 60 functions of the Service Descriptor Table (which is a lot), but that’s no longer possible on x64.

So, let’s remove the filters and re-launch k-test. It works now.

Final disclaimer: It is not my intent to comment on security features of anti-viruses, I just wanted to present my new tool and show its functionalities. I was already familiar with the internals of Kaspersky before writing this utility.

I hope you enjoyed the presentation.”

P.S. A huge thanks goes to Alessandro Gario for providing me with all the different versions of ntoskrnl.exe.

x64 SEH & Explorer Suite Update

Monday, January 19th, 2009

Yesterday I took a bit of time and updated the Explorer Suite. One important new feauture is the addition of the Exception Directory. I’m no longer working on the old CFF Explorer. However, I thought this feature was too important for people to wait for the new CFF Explorer. Here’s a screenshot of the Exception Directory UI:

CFF Exception Directory

If you have no idea how the x64 Structured Exception Handling works, you can briefly read this article on osronline or my article about Vista x64. There’s also a pretty in depth quantity of information in a series of posts on Ken Johnson’s blog. However, don’t hope to find too much information on the web about the real physical layout of the Exception Directory. The MSDN information is incomplete if not wrong and even the SDK doesn’t help. This post isn’t a complete guide to x64 exceptions, I just want to explain how to analyze them inside the CFF Explorer.

In the screenshot above you can see two arrays of tables. The first one is an array of RUNTIME_FUNCTION structures. The last column isn’t part of this structure though: it shows the five high bits of the first byte of the UNWIND_INFO structure refrenced by the UnwindData member of RUNTIME_FUNCTION. This is the declaration of UNWIND_INFO:


typedef struct _UNWIND_INFO {
    UBYTE Version       : 3;
    UBYTE Flags         : 5;
    UBYTE SizeOfProlog;
    UBYTE CountOfCodes;
    UBYTE FrameRegister : 4;
    UBYTE FrameOffset   : 4;
    UNWIND_CODE UnwindCode[1];
/*  UNWIND_CODE MoreUnwindCode[((CountOfCodes + 1) & ~1) - 1];
*   union {
*       OPTIONAL ULONG ExceptionHandler;
*       OPTIONAL ULONG FunctionEntry;
*   };
*   OPTIONAL ULONG ExceptionData[]; */

} UNWIND_INFO, *PUNWIND_INFO;

The flags represent the type of handlers. An exception flag represents __try/__except blocks, while the termination flag represents __try/__finally blocks.

The second is an array of scope records. An UNWIND_INFO can contain more than one scope records. Let’s consider this little code sample:


__try
{
    __try
    {
        // code
    }
    __finally
    {
        // code
    }
   
    __try
    {
        // code
    }
    __finally
    {
        // code
    }
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
    // code
}

As you can see from the screenshot, it results in 3 scope records. The HandlerAddress in a scope record structure can be an RVA to a C_exception_handler function. Or it can be a simple value like EXCEPTION_EXECUTE_HANDLER (which is 1). The last scope record represents the __except statement. Don’t confuse the exception handler (or filter) with its code.

The JumpTarget member, if not 0, is an RVA to the exception code. It’s possible to see if a particular address has an entry inside the Exception Directory by right clicking on the first table and then clicking ‘Is Address Handled’ in the pop-up menu. Nevertheless, remember that exception handlers can be added at runtime with APIs like RtlAddFunctionTable and RtlInstallFunctionTableCallback.

I fixed some minor bugs in the CFF Explorer and one major bug in the Task Explorer. I noticed this bug years ago but never took time to fix it. It showed only when trying to dump the region of an x86 process using the 64 bit version of the Task Explorer. However, x64 is becoming very used and so the bug is now fixed. Also, I thought it would be a good idea on 64-bit platforms to install a 32-bit version of the Task Explorer and a 64-bit one. Thus, the installer now behaves accordingly.

Qt Internals & Reversing

Friday, November 28th, 2008

Today I took a break from the larger article I’m currently writing. To relax, I wrote a smaller article about the Qt framework. I hope you enjoy.

Qt Internals & Reversing

Half of the text of this article comes from my larger paper “Dynamic C++ Proposal”. I decided that it was useful to take the part about Qt internals, put it into another article and extend it by adding a reversing part. Because of its nature, this is not the usual kind of article I write. In fact, I wrote the reversing part in less than a day. So, this is a very easy one. However, I think it is useful for people who need to reverse a Qt application and certainly wouldn’t consider reading my other paper about Dynamic C++, which doesn’t sound like a paper about Qt and, in fact, isn’t a paper about Qt: the paragraph about Qt is only one among many others. Moreover, I haven’t seen serious articles about this subject.

The first thing which needs to be considered when reversing Qt applications is what Qt brought to the C++ language. Events (inside the Qt framework) are just virtual functions, so nothing new there. This is not a C++ reversing guide. What is new in Qt are signals and slots, which rely on the dynamism of the Qt framework.

So, first thing I’m going to show how this dynamism works. The second part focus on reversing and, at that point, I will show how to obtain all the metadata one needs when disassembling a “Q_OBJECT” class.

Microsoft’s Rich Signature (undocumented)

Wednesday, March 5th, 2008

In the last days I’ve been quite sick, so I decided that as long as I had to stay in bed I might at least use the time to do something useful (or quite so). What happened is that someone asked what the Rich Signature was. It might seems strange but in all these years I didn’t even notice it, I just overlooked it as part of the dos stub (incredible but true). Unable to answer, I noticed together with this person that the subject was completely undocumented. It might not even be much important, but you might find it an interesting reading after all.

http://ntcore.com/Files/richsign.htm

Since information about this topic is non-existent, the reader might not know what I’m talking about:

00000070 6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00 mode….$…….
00000080 E7 B3 9D E7 A3 D2 F3 B4 A3 D2 F3 B4 A3 D2 F3 B4 糝ç£Òó´£Òó´£Òó´
00000090 60 DD AC B4 A8 D2 F3 B4 60 DD AE B4 BE D2 F3 B4 `ݬ´¨Òó´`Ý®´¾Òó´
000000A0 A3 D2 F2 B4 F8 D0 F3 B4 84 14 8E B4 BA D2 F3 B4 £Òò´øÐó´„Ž´ºÒó´
000000B0 84 14 9E B4 3A D2 F3 B4 84 14 9D B4 3F D2 F3 B4 „ž´:Ò󴄝´?Òó´
000000C0 84 14 81 B4 B3 D2 F3 B4 84 14 8F B4 A2 D2 F3 B4 „´³Ò󴄏´¢Òó´
000000D0 84 14 8B B4 A2 D2 F3 B4 52 69 63 68 A3 D2 F3 B4 „‹´¢Òó´Rich£Òó´
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
000000F0 00 00 00 00 00 00 00 00 50 45 00 00 4C 01 04 00 ……..PE..L.

The data between the dos stub and the PE Header. It ends with the word Rich. It is produced by microsoft VC++ compilers only and it is encrypted.