Mixing up 32-bit and 64-bit code

Back in the days of Windows 3.11, Microsoft provided a special layer that made it possible for 16-bit and 32-bit code to interact with each other.The technique used for such interface is called thunking, which allowed both sides to be blissfully unaware that they are not quite compatible.

Massive SQL injection, anyone?

Last weekend I found a number of entries in the HTTP server logs indicating SQL injection attempts. The SQL targeted MS SQL Server and used the CAST function to decode a long hexadecimal sequence used to bypass code quote-escaping code on the server side.

SET @S=CAST(0x4445434C4152452040542...736F7220 AS VARCHAR(4000));
Mangling user agents is a good thing!

User agent strings come in all shapes and sizes and showing full user agent strings in reports results in too much fragmentation, as every little detail, such as a service pack or a minor version change results in a new user agent string in the report.

MangleAgents is a configuration parameter that has been around for a while and is designed, despite its name, to tidy up user agent strings and leave only those parts of the user agent string that are interesting from the analysis point of view.

64-bit optimization gone wrong

I was working on a 64-bit VC8 project and the executable built in release configuration kept crashing at run time with evident traces of stack corruption. A debug build or even a release build with all optimizations disabled worked fine and so did a fully-optimized 32-bit build.

The problem with debugging optimized release builds is that many variables are passed through registers and stack frames are omitted, making it more difficult to trace parameters and local variables. Debugging x64 builds is even more difficult because the optimizer heavily uses additional 64-bit registers and hardly puts any parameters on stack.