Confusing instruction

A few days ago I was working on the x86 IDA module. The goal
was to have it recognize jump tables for 64-bit processors.
This is routine: we have to add new instruction idioms to the
analysis engine from time to time to keep up with new compilers.
I was typing in the patterns and hoping
that the tests would go smoothly at the first run.

Continue reading Confusing instruction

Sad truth about programming

There is no such thing as a bug free software. Today I stumbled on this:
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
This is an unfortunate and sad truth about programming: regardless of our efforts, software will have bugs; it will crash, it will burn, it will fail. At the same time there is a hope:
http://alloy.mit.edu/
We desperately need code verification tools like this.

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

FOSDEM did not deceive me at all – just the contrary.
There were many interesting things and the talk I liked the most was about valgrind. The very obvious idea after it was “why not develop a security scanner on the top of valgrind?”. Valgrind is a framework to develop simulation-based tools, and MemCheck is just one of them. Valgrind handles the most tedious and demanding part of the job – simulating the processor instructions. It also handles the operating system calls, signals, and the rest, so the developer of a security scanner will be able to concentrate on the essential things.
Just an idea..

Capricious programming

Textbooks on software engineering prescribe to check preconditions at the beginning of a function. This is a really good idea: the sooner we detect that the input data or environment does not match our expectations, the easier it is to trace and debug the application. A nice function with precondition checking refuses to “work” if the preconditions are not satisfied.

Continue reading Capricious programming