Experiences with Signedness II

Data that is read from the memory can be treated as signed integer or unsigned integer. It's possible that at some stage of the execution the integer is treated as unsigned integer but other point of the execution it's treated as signed integer. When it comes to write code there could be circumstances when you might not be immediately aware how the integer is treated unless you take an extra care, for example, by looking at the compiled code. This is definitely an attack surface, and the root cause of lots of published vulnerabilities.

In case you want to see some examples what I mean, earlier last year, I wrote a little about experiences regarding signed/unsigned comparisons.

Some time ago, I started developing a Windbg plugin command that has a tracing functionality, and the ability to break in the debugger when a signed comparison is reached. However, if EIP is not in user defined range e.g. due to an API call, the program executes normally. When EIP is in the user defined range again the program resumes tracing.

I was able to trace some function in a Visual C++ project, but it was needed to run l-t command beforehand to step by assembly instructions rather than source lines. Here is how to use Windbg in VS.

This plugin can be extended to work with other signed instructions than signed comparison ones. In addition, the plugin can be extended to execute the program until comparison is reached rather than to trace, in a similar way to the working of the ph command.

One possible area to explore further is to record how the data that is read from the memory is treated in point of signedness. Also, to detect any weak points to attack, or even to detect signedness conversions.