Recon 2010: Intro to Embedded Reverse Engineering for PC reversers

In July I had the honor to speak at the Recon conference in Montreal, Canada. It was my first conference but I really liked the experience. I hope I’ll be able to attend it in future.
The presentations were recorded and hopefully will appear on the Recon site soon but for now you can check out the slides (ODP, PDF). I have also uploaded some of the tools I mentioned, most notably various filesystem extractors compiled for Win32 (download).

PDF file loader to extract and analyse shellcode

One of the new features in IDA Pro 5.6 is the possibility to write file loaders using scripts such as IDC or Python.
To illustrate this new feature, we are going to explain how to write a file loader using IDC and then we will write a file loader (in Python) that can extract shell code from malicious PDF files.

Continue reading PDF file loader to extract and analyse shellcode

Blackhat USA 2008

Sometimes names just do not reflect the nature of things. Sometimes it is our fault to attribute a wrong meaning to names. I do not know which of the above holds for Windows ASLR. After Alex Sotirov and Mark Dowd’s talk at Blackhat I know that ASLR is not that random despite of its name.
The ASLR abbreviation contains “randomization”, which is enough (at least for me) to deduce that EXEs and DLLs get loaded at randomly chosen addresses. I was wrong to think that this makes it hard for the attacker to guess the loaded addresses. As it turns out, binaries get loaded to somehow predictable addresses.
While I understand that there were some technical difficulties and compatibility issues, the implementation choices made for ASLR effectively weakened it a lot to the point that it failed to deliver the promised.
Another revelation of this talk was that IE happily loads any .NET DLL provided by the web server using the plain old LoadLibrary function. The ramifications of this are enormous because the system is essentially accepting raw binary data (a file of the PE file format) and runs it on the user’s computer. No need to talk about GS, SafeSEH and any other protections mechanisms after this.
The outcome of these two choices is also predictable, as Alex and Mark demonstrated to us: anyone visiting a malicious web site with IE can be easily owned.
There were other interesting talks at Blackhat, no way I can mention all of them here. Just one more pointer: I was amused and amazed by Hovav Scacham’s Return-Oriented Programming. As it turns out, pieces of “good” code in standard libraries can be used to build a turing-complete machine. This machine is programmable by the attacker using a byte code which does not require the X (execute) bit in the page permissions. This defeats W^X or DEP protections.
My talk on decompilers was received well. If you missed it, find the white paper here.
Heading to DEFCON now, for more interesting talks!

MRXDAV.SYS and Hex-Rays Decompiler

I wanted to present you a new plugin today. It was about switch idioms (jump tables). I spent a few hours trying to find a problematic x86 sample file but could not locate anything impressive. All jump tables were nicely recognized. This certainly does not mean that IDA handles them perfectly, but rather that my search methods must be improved.
Anyway, things were going nowhere and I decided to make a micro-break. It really helps to unblock the thought process (sometimes my entire working day consists of innumerable micro-breaks :)

Continue reading MRXDAV.SYS and Hex-Rays Decompiler

ZERT patch

I think you have noticed that the site was down for a while. My web hoster again played the same trick: shut down the site with no notice. I’m leaving them.

While I was busy with all this stuff, the ZERT group has created a patch for the VML vulnerability. These guys did a really great job. Gil Dabah, who programmed the patch, deserves a special mention for his fast coding speed and the robustness of his code.

We all know that third party patches should be taken with caution. They can not be thoroughly tested in many environments as the official patches are. Yet the availability of such a patch is a good thing: at least you have a choice and can protect yourself today, without waiting the preprogrammed patch day.

If you use the Internet Explorer then either unregister vgx.dll (as Microsoft advices it) or install the unoffcial patch. It can be downloaded from http://isotf.org/zert.
UPD: Since the official patch is available, please use it: http:/update.microsoft.com.

IE6 vulnerabilty patch

If you are one of unfortunate users still forced to use the Internet Explorer, consider installing this temporary patch from Determina:
http://www.determina.com/security_center/security_advisories/securityadvisory_march272006_1.asp
Just do not forget to reboot your computer after applying the patch, the installer seems not to insist on it. If you can not reboot the computer, then at least close all IE6 windows to get rid of the vulnerable copies in the memory.
The patch is nice and clean. It does not modify the system files on the disk.
If you continue to use IE6 by inertia, consider switching to another browser. Diversity is good for security.

On uninitialized variables

Quite busy week, sorry for being silent.
I wanted to talk about an annoyance I discovered with all my C/C++ compilers.
Here is quite interesting presentation from Halvar Flake:
Attacks on uninitialized local variables
After reading it I wanted to verify my compilers and created a small C file. I wanted to check if the compilers would warn me of a potential uninitialized variable. The source code was pretty simple:

void const_ptr_acceptor(const int *);
int control_func(void)
{
int x;
return x + 1; // compiler emits a warning
}
int check_func(void)
{
int x;
const_ptr_acceptor(&x); // we do not modify x here!
return x + 1; // compiler does not emit a warning
}

We have two functions, they both use an uninitialized variable. The only difference is the call to const_ptr_acceptor() which promises not to modify ‘x’. I compiled this source code with all warnings turned on. I was expecting two warnings from the compiler: the first warning about ‘control_func’ and the second warning about ‘check_func’. However, there was only one warning:

E:\hex\const_ptr>cl /Wall /c const_ptr.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50215.44 for 80×86
Copyright (C) Microsoft Corporation. All rights reserved.
const_ptr.cpp
e:\hex\const_ptr\const_ptr.cpp(6) : warning C4700: uninitialized local variable ‘x’ used

I tried with all available compilers, but they were unanimous in their behavior: as soon as we pass a pointer to a variable, the compiler thinks that it is initialized. We explicitly specify with the const specifier that the function does not modify the variable, but the compilers seems to ignore it.
I compiled the code with Microsoft Visual Studio, Borland BCB6, GNU C, Intel compilers.
Still have no explanation why all compilers behave this way.

FOSDEM

Each year in Brussels, Belgium there is a conference called FOSDEM. It is organized on the last weekend of February. There seem to be some interesting talks about security and program developement this year. The development track is almost fully dedicated to various CVSes. The choice of CVS is an object of faith like the choice of the editor so it doesn’t hurt to go and see what others use…
I’ll also attend the the talk about valgrind by Julian Seward. I loved the tool from the first time I used it.
See you there :)