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
-------------------------------
SHORT             2      2
wchar_t           2      2
WORD              2      2
-------------------------------
BOOL              4      4
DWORD             4      4
float             4      4
HRESULT           4      4
int               4      4
long              4      4
unsigned int      4      4
unsigned long     4      4
-------------------------------
HANDLE            8      4
INT_PTR           8      4
LONG_PTR          8      4
ULONG_PTR         8      4
void*             8      4
-------------------------------
__int64           8      8
double            8      8
LONGLONG          8      8
ULONGLONG         8      8
-------------------------------
FLOAT128         16     16
-------------------------------

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

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:

http://blogs.msdn.com/david_leblanc/archive/2007/07/27/practical-windows-sandboxing-part-1.aspx
Part 2:

http://blogs.msdn.com/david_leblanc/archive/2007/07/30/practical-windows-sandboxing-part-2.aspx
Part 3:

http://blogs.msdn.com/david_leblanc/archive/2007/07/31/practical-windows-sandboxing-part-3.aspx

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!

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!

Hey!

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 :)