Saturday, September 22, 2007

Old Old New Thing

Today I was trying to catch up with all the new entries on Raymond's blog and I found some interesting posts that are worth taking a look.

What do I do with per-user data when I uninstall?

Microsoft says... oh wait... I mean.. Raymond Chen says that we should not touch it! Quick and Easy! I like that :)

Why isn't QuickEdit on by default in console windows?

Because it breaks console mode applications using the mouse.

Does creating a thread from DllMain deadlock or doesn't it?

It does not. Except if you create the lock yourself by waiting for the thread to do something, because it's not going to run until you exit DllMain.

Sunday, September 2, 2007

Handle Format

A couple of posts ago I talked about how to get the list of all open handles. When I started playing with that it did not work at the first try, so I had to use the brute force method to get all the handles in the current process. The code was doing a loop like this:

for (LONG_PTR h = 0; h < 0xFFFF; ++h) {
HANDLE handle = (HANDLE)(h);

The result was unexpected to me. All handles in the process were duplicated 4 times. It looks like the lowest 2 bits in the handle value are ignored.

If the handle to a file is 0x7C then you can use 0x7C, 0x7D, 0x7E or 0x7F to access the file.

Is this documented somewhere?

Updated on 9/3/2007:
I was talking with Ivanlef0u about this and my assumption that the last 2 bits are ignored is right. He showed me the disassembly of the function to lookup the object in the handle table and it looks like this:

mov edi, edi
push ebp
mov ebp, esp
and [ebp+Handle], 0FFFFFFFCh ; Unset the last 2 bits
mov eax, [ebp+Handle]
mov ecx, [ebp+HandleTable]
mov edx, [ebp+Handle]
shr eax, 2 ; Shift right the last 2 bits
cmp edx, [ecx+38h] ; HandleTable->NextHandleNeedingPool
jnb loc_49DDF8

Thanks Ivanlef0u.

Using Visual Studio to debug your token.

For as long as I remember I have been using TokenMaster to be able to see and dump the information contained in my access tokens.
Recently greggm blogged about another way to get this information. This is now integrated in the visual studio debugger. Just type "$user" in the watch window and you will get a complete view of the current token.

Updated on 9/4/2007
Thanks to Marc-Antoine Ruel for the information, Windbg also does that! Just type this command to get the same information:

!token -n

How to list all the open handles?

Recently I had to get the list of all the handles open in a process. I searched on the web to find a good way to do it, and realized that most of the articles I found are wrong.

I guess this is because the documentation in "Windows NT/2000 Native API Reference" by Gary Nebbett is a little bit misleading.

Under the SystemHandleInformation class, the structure defined is:

USHORT ProcessId;
USHORT CreatorBackTraceIndex;
UCHAR ObjectTypeNumber;
UCHAR Flags;
USHORT Handle;
PVOID Object;
ACCESS_MASK GrantedAccess;

One could think that the buffer returned is actually a list of structures like this one. But this is not the case, it's actually returning a structure like this one:

ULONG NumberOfHandles;

Even though the description in the book is misleading, Gary Nebbett is not wrong. There is a remark saying: "The data returning to the SystemInformation buffer is a ULONG count of he number of handles followed immediately by an array of SYSTEM_HANDLE_INFORMATION".

There is another factor making this task a little bit more complex to achieve: The function is really picky about the buffer size.

Usually you can call the function with a NULL buffer and 0 for the size and then get back the size you need to allocate your buffer. This does not work here. The return value is 0xC0000004 : The specified information record length does not match the length required for the specified information class.

If you try with a SYSTEM_HANDLE_INFORMATION buffer, it won't work either. You need to pass to the function a buffer large enough to hold the number of handles and the first handle if you want to get the size needed back. This is a little bit weird.

Finally, the code:

// Get the number of handles on the system
DWORD buffer_size = 0;

NTSTATUS status = NtQuerySystemInformation(
SystemHandleInformation, &temp_info,
sizeof(temp_info), &buffer_size);


status = NtQuerySystemInformation(SystemHandleInformation,
buffer_size, &buffer_size);

printf("nb of handles = %d", system_handles->NumberOfHandles);

Thursday, August 9, 2007

sizeof Cheat Sheet

It's hard to justify why this kind of cheat sheet is necessary. We should all know this information by heart. Unfortunately I realize that sometimes I'm not 100% sure and I have to look it up. If it happens again, then I'll come back here!

The size of the different types is in bytes.

win64 win32
bool 1 1
BYTE 1 1
char 1 1
wchar_t 2 2
WORD 2 2
BOOL 4 4
float 4 4
int 4 4
long 4 4
unsigned int 4 4
unsigned long 4 4
void* 8 4
__int64 8 8
double 8 8
FLOAT128 16 16

Wednesday, August 8, 2007

ThreadHideFromDebugger! But Why?

At BlackHat last week Mark Vincent Yason talked about the art of unpacking. One of the techniques used by some packers is to hide their threads from the debugger so it can't be easily debugged.

It is really easy to hide a thread from the debugger, you just have to call :

NtSetInformationThread(hThread, ThreadHideFromDebugger, NULL, 0);

At this point the debugger will stop receiving debug information or exceptions from this thread. But be careful! If you are debugging the process and you set a breakpoint and it happens to hit in the hidden thread, the process will crash and windbg won't even realize it.

After the presentation I was not able to stop asking myself why did Microsoft implemented this feature. It seems like the only usage is to make "malicious" code harder to debug. Maybe they implemented it to mute some noisy threads? Or maybe they wanted to protect some system threads? If you know the answer, please let me know!

The next thing to do was to check if Microsoft is in fact using this feature. I put a conditional breakpoint on NtSetInformationThread to hit when the ThreadInformationClass is equal to ThreadHideFromDebugger.
Unfortunately it never hit. (Tested on XPSP2 and Vista). There is also the possibility that they are changing the ETHREAD structure manually, but I doubt so. I'll try to check that later.

On the other hand, something interesting came up during this experiment. On Vista it seems like NtSetInformationThread is called really often with an invalid (or undocumented) ThreadInformationClass. I'll try to investigate that and write my results in another post. In the mean time, I dumped the number of occurrences of each ThreadInformationClass during the boot of windows. I haven't found any use for that yet, but anyway:

Windows XP SP2
   4 ThreadPriority
16 ThreadBasePriority
2 ThreadAffinityMask
2069 ThreadImpersonationToken
16 ThreadQuerySetWin32StartAddress
16 ThreadZeroTlsCell

Windows VISTA
  16 ThreadPriority
490 ThreadBasePriority
4 ThreadAffinityMask
6293 ThreadImpersonationToken
71 ThreadZeroTlsCell
1 ThreadPriorityBoost
460 Unknown - 0x16
481 Unknown - 0x18
10 Unknown - 0x19

Monday, August 6, 2007

David LeBlanc @ BlackHat : Practical Windows Sandboxing

One of the main reasons I went to BlackHat last week was for David LeBlanc and his presentation about windows sandboxing. Unfortunately I missed it. I really don't know what happened. David was the last one of a series of three 20minute talks. I was there for the first two but it looked like they cancelled both of them. Thinking that they cancelled the series, I left the room and went to see the fuzzing talk by Pedram Amini (Very interesting by the way).

Fortunately David blogged about his presentation:

Part 1:

This is actually really interesting and it's awesome that restricted tokens and job objects are now used for sandboxing by Microsoft. I really wish I hadn't missed this talk!

Saturday, August 4, 2007

Why you should not trust CreateProcess' PROCESS_INFORMATION

At GreenBorder I was working on a complex multi-process application with a lot of interactions between the processes through IPC and DuplicateHandle. The processes were created with CreateProcess. This call returns a PROCESS_INFORMATION structure containing the process ID of the newly created process, the thread ID of the main thread along with their handles.

I was using the structure to initialize my IPC and was using the process handle to duplicate some others handles into this new process.

Everything sounds good right? Wrong!

The problems started happening the first time I had to debug a complex bug. Since this is a multi-process architecture, the easiest/best solution to debug the child processes is to set the Image File Execution for the process to start your favorite debugger (Windbg in this case) automatically. Unfortunately it turned out to be a lot worse. After a little while I discovered that the PROCESS_INFORMATION structure returned by CreateProcess was not containing the information about my process... but the information about the debugger! All calls to DuplicateHandle were in fact duplicating handles into Windbg.

I can see how I could have refactored the code to not depend on the hProcess, but my case was not that simple. I was in fact calling CreateProcessAsUser with a restricted token. Too restricted for Windbg to be able to run properly!

To solution was to change the way I debug child processes. I'm now using the "Debug Child Processes Also" option in windbg. Oh, and if you don't control the creation of the parent process, you can still attach to it and type the command ".childdbg 1".

Note: While I was writing this post I looked on the web for some references and I found a post about this exact same issue from Raymond Chen posted only 1 month ago. My blog should also be called "The old new thing" :)

First Post!


I'm Nicolas Sylvain, software engineer in the SF Bay Area. This is my first post on this blog and hopefully not my last one. I just got the unexpected motivation to create a blog. I don't know yet how often I'll update this blog; I guess it will depend on what's happening and how much time I have. I'm really curious to see!

The main subject of this blog is Windows Internals and its security. It will be presented from the point of view of the developer. That does not mean that I'm not going to talk about random stuff, but at the end, most of the posts should talk about the security of the Windows operating system.

Why is this called "The Final Stream”? I'm not sure yet. I just think it sounds cool. I might rethink this later :)

Who am I? Well, I'm Nic. I'm from Quebec, Canada so I speak French. Please forgive my English! I moved to Silicon Valley in 2005 to work for a startup called GreenBorder who developed a sandboxed virtual environment to protect the OS and the user data from malicious code running in the browsers or email clients. Recently I joined a much bigger company. I might talk a little bit more about what I'm doing in a later post, but you should not be waiting for that :)