Recently on my Polish livestreams I've been writing a somewhat simple raytracer (see screenshot on the right; source code; test scene by ufukufuk), with the intention of talking a bit on optimization, multithreading, distributed rendering, etc. As expected, there were a multitude of bugs on the way, some more visual than others. My favorite one so far was a mysterious buffer overflow resulting with a C++ exception being thrown when rendering in 4K UHD (3840x2160) but not in 1080p (1920x1080). While trying to find the root cause I also run into a standard C library bug with the sqrt function (though it turned out not to be related in the end), which made the run even more entertaining.

Just to be clear, this post is not going to be about the float vs. float comparison. Instead, it will be about trying to compare a floating point value with an integer value in an accurate, precise way. It will also be about why just doing int_value == float_value in some languages (C, C++, PHP, and some other) doesn't give you the result you would expect - a problem which I recently stumbled on when trying to fix a certain library I was using.

In September last year I received a programming question regarding multi-level multiple same-base inheritance in C++, under one of my video tutorials on YouTube. I started playing with some tests and went a little too extreme for the likings of Microsoft 32-bit C/C++ Optimizing Compiler (aka Visual C++), which crashed while trying to compile some of the test cases. After some debugging, it turned out that it crashed on a rather nasty memory write operation, which could be potentially exploitable. Given that I was occupied with other work at the time, I decided to report it immediately to Microsoft with just a DoS proof of concept exploit. After 9 months the condition was confirmed to be exploitable and potentially useful in an attack against a build service, but was not considered a security vulnerability by Microsoft on the basis that only trusted parties should be allowed to access a build service, because such access enables one to run arbitrary code anyway (and the documentation has been updated to explicitly state this).

I've never given too much thought to the problem of initialization of a local variable with static storage in C++ (and C). I just blindly assumed that the static variable works identically to a global variable, but is directly accessible (using language provided means) only in the block of code (and its child blocks) in which it was declared/defined. This is partly true - the big difference is that the global variable is initialized either at compilation time (constant/zeroed) or before the entry point, and the static variable is initialized either at compilation time (constant/zeroed) or when the execution first reaches it's declaration/definition. The interesting parts here are "how does the variable know if it has been initialized?", "can initialization fail and need to be rerun?", "what about concurrent multi-threading?" (the latter has some minor stability/security consequences). Let's take a look at GCC and Microsoft Visual C++ and how do they handle these issues...

While discussing a few days ago a piece of code with aps, we've encountered some interesting (imho) differences in the implementation of atoi and [sf]scanf between different versions of msvcrt (Microsoft C-Runtime Library), glibc (GNU C Library) and the libc used on OSX. The said differences are observed when a number in the provided string cannot be represented as an integer, i.e. it's larger than INT_MAX (which is 0x7fffffff, or 2147483647 decimal) or smaller than INT_MIN (0x80000000, -2147483648 decimal).

Recently I'm working on some C++ code that (ab)uses many language features in a deep way, and hence, I found it necessary to do some digging to check if a given behavior is a result of standard fulfillment (i.e. it's defined in the language standard), defined compiler behavior (i.e. it's defined in the compiler (GCC in this case) documentation, but not necessarily in the language standard) or it's totally UB (i.e. it's not defined in any official documentation and cannot be relied on in any other version or compiler). So, this post is basically a data dump about some feature (preprocessor macro resolving to be exact) and probably seasoned programmers can skip it.

Well, this was supposed to be another "Random" post, but as the typing went on, it grew quite long, so I've decided to post this as a normal post. So, today's post will be about some new (i.e. new for me) extensions in GCC I've dig up, and a random rant on what I still miss in C/C++ (and no, I don't have templates of templates of templates in mind ;f).

After this years CONFidence I came to conclusion that it would be fun to play with the old-school hardware/software solutions, like ANTIC, P/M, HAM6, etc. So, how to do that?

Looking through my directories I've found some tools that I've kept hidden in my desk, unpublished for some strange reasons. I'm thinking about finalizing the basic functionality of these, and finally putting them online. Anyways, one of such tools was HiperDrop - a simple command line process memory dumper for Windows.

Below I present the download links for the slideshow (PDF) from my "Practical security in computer games" lecture, and a 0.0.1 alpha version of SilkProxy. A few more words about that last position: it's a multi-tunnel written in C++, scriptable in Python, that can be used for a few various things like protocol analysis, network traffic fuzzing or as a proxy/tunnel for some application. The version I publish is the version I've used while doing research for my lecture, and it's an alpha version - it means that not everything works as I would like it to work, the python API is undocumented, and some functionality is still (like replaying packets/network traffic and application-replay tunnel) missing - so, currently it might interest some curious programmers, but it's not yet usable for most of the researchers. However, I encourage you to take a look at it anyway (see the http.py script for a simple usage example; you run it by typing ./SilkProxy script.py, however the script is optional; to compile it you need to have Python installed with libs/headers, and GCC compiler (MinGW is OK)) ;>

For some random reasons my blog became quiet recently, but don't worry, it's only temporary. It's time to catch up, and write about this and that.

The previous Sunday I decided to play a little with graphical interpretation of files again. Graphical interpretation, or visualizations as one may call it, is a large topic, there are even some interesting sites dedicated to that, in which the authors present colorful bitmaps representing files, that are commonly made moving file bytes directly to Red, Green and Blue channels. However, in my case, the bytes will not be mapped to RGB, instead, I choose to map them to X and Y.

At last! A technical post!.. in which, I'll describe the ESET crackme from this years edition of the CONFidence conference. The CONFidence crackme (made especially for the conference - it was NOT their old crackme that is available on the ESET website for some time now) is available for download below, so one can try to break it (it's a "recover the password" type of crackme) himself:

Two days ago j00ru informed me that my cmd.exe add-on (the one that adds the ultra important feature - colors!) does not work on Windows 7 RC - so I decided to have a look, and so version 0.004d came into being!

Recently I've been working on a function written in assembly (NASM dialect) that was to be compiled and then loaded and executed at runtime by an Objective C application. The function was to search in a library image (in memory, MACH-O) for the address of a given method from a given class (using Objective C export sections), and it was composed of a 4 level loop. And, as one my figure, it didn't work as it should. At first, I tried to debug it by hand, but since it was a four level loop, with a ton of iterations, I soon gave up, and switched to a more automagical method - which I now describe to you (later I found out that the mechanics my function used are invalid, but thats a story for another day).

Sunday, from 5pm till 8pm, another gamedev.pl compo took place. This time, it was a 3 hour compo during which one had to create a 'game that has both a cow and a pig' (a strange topic I must say). I don't have to much time recently, but I've figured that 3 hours is a period I can manage to find, especially Sunday. So, after I got a 'go' from my beloved wife, I took part in the March GDPL 3h Compo.

The story starts as usual. I've been writing a certain application, that generates some test files. The files were very similar in structure, so I took the common factor out, and created a function that creates the common base of the file, and then, made a few functions that make modification to this base, and then the file is written (file shared, only in GF 15200 GTX! ;>). Of course, every modification function that I made, I had to add to a list of function in another part of the source file. And I've added each 'shader' function I created to that list. After 38th function I've grew tired of this...

There is a tool, created by j00ru and me, that I was supposed to publish online a long time ago. However, I judged that the code is not-pretty, and (one might add "as always") there was no time to prettify it. Until the previous weekend, when, while visiting my parents/brother, I opened the laptop and finally rewritten the code.

Todays post will be contain some technical security stuff - I'll write about a technique called "return-oriented programming" or "return-oriented exploiting" or "ret-to-libc without returning to functions" or "ret-to-anything" (or by some other names as well). As always, I'll write about this technique from my point of view - meaning that, like always, I used this technique before reading any papers about it (it's related to my habit of reinventing the wheel).

Yesterday I've finally got some time to finish the changes in the new version of ExcpHook. So, version 0.0.5-rc2 (rc2 of alpha ;p) is ready for download, and might be even usable ;D

Todays post won't be about cmd.exe and BAT, for the moment, I have exhausted that topic. Instead, I'll write about drawing cool-looking "pictures" using sin and cos functions, in C++.

Long, long time ago, in the DOS times that is, one could configure the command prompt to be colorful, one could echo colorful messages, etc. And one could do all that thanks to the ANSI escape codes - short commands echoed to the "screen" (stdout/stderr that is) that caused the colors to change, the cursor to move, or the screen to be cleaned. ANSI escape code well working quite well in DOS, and they even worked in Windows 95/98. However, with the arrival of the NT family, the ANSI support in the console ceased to exist (well, it was still available in the command.com interpreter, but it's 16-bit running under NTVDM, what makes it not the best choice, not to mention that the NTVDM is not available in the 64-bit Windows versions). (A short offtopic: on *nix systems ANSI escape code well available almost always, and they are still available today).

Today's post will be, as promised, about OpenGL in .BAT scripts. At the very beginning, I would like to remind you (I was told that the correct form of 'you' is written with a lower 'y') that .BAT scripts have nothing to do with speed - they are just plain slow ;>

Waiting for my new programmer (which will arrive "at the end of the week") I decided to dump RAM from my new Amstrad to my PC. But there was a problem - how to do it without having any cables to connect them, without floppies, etc? Well, I found a funny way to do it ;D

Sitting in my hotel room at the Polish edition of PyCON, I started to think what would happen, if a normal Windows process wipes out (almost) all of it's memory. By "wipe out" I mean to free/unmap what is possible (VirtualFree and UnmapViewOfFile), and overwrite with zeroes the rest. I've started to experiment with this, wanting to know how will the system, and other applications, react to this uncommon process condition. Below I describe the creation of a test application (I've found a few interesting (imho) problems), and a funny thing OllyDbg does while attaching to such a process.

About a half year ago I decided that I need an animated (as in "generated realtime") desktop wallpaper. I thought it should not use 3D acceleration (no OpenGL/D3D), the FPS should not be to high (2-3 frames per seconds were totally fine with me), and if possible, it should use more then one core (up to 4). I've started to write code, and, as always, didn't finish it. However, something does show on the screen, and imho it ain't all bad, so I decided to write a little on what is it, and how does it work - maybe someone will find it interesting ;> (the images are clickable, except the heightmap; the code for Windows/Mac/Linux and a short video is available at the bottom of the post).

Recently I've talked with my teammate oshogbo about the format bug (aka format string attack), and when we got to testing a sample code, a thing that should work - the %n tag, didn't work at all. What's more interesting, this behavior was Vista specific, since everything else worked well on XP. I've decided to take a look inside, and here's what I've found out...

Todays post will be an out of order one, and it will be dedicated to the function gettimeofday on the Windows system, or to be precise, the lack of this function.

Inspired by noglorps post on OpenRCE I've finally decided to play with Windows fibers, and I found out that it's quite an interesting topic.

Recently I was creating in C++ (MinGW g++) a small library for runtime-patching. A need came to create an assembler-only functions, without any additions from the compiler - a "naked" function. However, even if compilers from Redmond support __declspec(naked) attribute for the x86 [Visual C++ Language Reference - naked (C++)], GNU compilers don't - they only support "naked" in ports for ARM, AVR, IP2K and SPU [Using the GNU Compiler Collection (For GCC version 4.3.0) - Function Attributes]. The problem had several possible solutions: