As I mentioned in this post the last four livestreams on my YouTube channel were done by Artem "honorary_bot" Shishkin (github) and were on the quite anticipated and demanding topic of Windows kernel debugging with a healthy dose of both x86 from a system programming perspective, and an unexpected but very welcomed venture into the world of hypervisors. The series came to an end, therefore I would like again to thank Artem for both reaching out to me offering to do the streams and actually doing them in such a spectacular fashion - speaking for myself, I've learnt a lot!

All the videos are already uploaded on YouTube (links below), so in case you've missed them, nothing is lost (well, maybe for the ability to ask question, but I guess one can always reach out to Artem on Twitter). Please note that the links that Artem visited during the livestream are available for your convenience in each of the video descriptions on YouTube (if I missed anything please let me know).

• Windows Kernel Debugging - Part I, in which Artem shows how to configure your kernel debugging environment in several different ways, both including a virtual machine (with/without VirutalKD) and a second PC (controlled using Intel AMT and connected using various means, e.g. USB, Firewire or ethernet).

• Windows Kernel Debugging - Part II, during which Artem shows how to work with and configure WinDbg.

• Windows Kernel Debugging - Part III, in which Artem goes through the meanders of virtual memory and navigating through it using WinDbg. He also goes into the details of what's in a process and kernels virtual memory.

• Windows Kernel Debugging - Part IV, in which Artem showcases the physical memory and explains why a physical address is not always equal to RAM address, as well as ventures into the land of ACPI tables (if you're thinking about OSDev, you should check out this part regardless of whether you're interested in Windows kernel debugging or not). Artem also demos a hypervisor-level system debugger of his making.

It's a real pleasure for me to announce that the next four livestreams will feature Artem "honorary_bot" Shishkin (github), who will do an introduction into a long awaited topic of Windows Kernel Debugging. Artem, in his own words, is a fan of Windows RE, debugging and low-level stuff. He's been using WinDbg for kernel debugging for several years now for fun, customizing BSODs, building Windows kernel source tree or boot dependencies graph. Sometimes he might also accidentally discover such things as SMEP bypass on Windows 8 or how to disable PatchGuard in runtime. Being a great fan of Intel and specifically VMX technology he maintains his own bicycle debugger based on a bare metal hypervisor.

When:
• 2017-08-02 (Wednesday), 8pm CET
• 2017-08-03 (Thursday), 8pm CET
• 2017-08-09 (Wednesday), 8pm CET
• 2017-08-10 (Thursday), 8pm CET

Where:
My YouTube livestreaming channel: www.youtube.com/c/GynvaelEN/live (or
gaming.youtube.com/c/GynvaelEN/live if you prefer darker theme).

How to not forget:
• Subscribe to the YouTube channel and allow notifications.
• Subscribe to Gynvael Hacking Livestreams calendar (also: ICS, calendar ID: pjta7kjkt1ssenq7fi9b6othfg@group.calendar.google.com).

Since I expect some technical problems (first time we'll be doing livestreaming with a guest in a remote location) I'll skip the usual news/announcements/mission solutions part of the streams to save some time (I'll probably do a dedicated stream for mission solutions later on). However DO expect new missions after each episode :)

See you Wednesday!

Some time ago I was reading a random Python JSON parsing library which was partly implemented in C. At one point I thought I spotted a bug in custom float number parsing - I've written a short PoC to trigger it and it worked (i.e. crashed Python), but behaved differently than I expected it to and seemed to work only on Windows. So I got back to looking at the code and in the end decided it was only my imagination - there was no bug. So… why did that PoC actually work? It turned out that in some cases the library fell back to using the good-old strtod for float parsing instead and yes, there was a bug - in the underlying msvcrt.dll strtod implementation.

(Collaborative post by Mateusz "j00ru" Jurczyk and Gynvael Coldwind)
A few days ago we (j00ru and I) gave a talk during the SyScan'13 conference in the fine city of Singapore, and as promised (though with a slight delay), today we are publishing both the slide deck and a white paper discussing memory access pattern analysis - a technique we recently employed with success to discover around 50 double-fetch vulnerabilities in Windows kernel and related drivers (Elevation of Privileges and Denial of Service class; see Microsoft Security Bulletins MS13-016, MS13-017, MS13-031 and MS13-036 released in February this year. Also, stay tuned for more security patches in May and June).

DLL shared sections have long been infamous for introducing security problems. A few months ago I decided to take a look if one can still find applications that use PE modules with shared sections in an insecure way (or using them at all). Today I'm releasing research notes, some tools and a demo of a Cygwin local privilege escalation (it's already fixed).

After the CVE-2010-4398 (win32k.sys stack-based buffer overflow aka "UAC bypassing exploit" published on Code Project) was published a discussion appears on the net (at least on the Polish side of the net) whether the bug is exploitable on Windows XP. The problem on XP is that it has stack cookies (/GS cookies) which in this case were not present in other Windows versions. With j00ru we've looked into this issue, and found that the high entropy of the /GS cookies is questionable (at least in case of Windows drivers). Today, we publish the results of our research.

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).

The videos from some CONFidence 2010 lectures have been published. Inter alia, the video from my and j00ru's lecture "Case study of recent Windows vulnerabilities" is available. The video is in a downloadable form (i.e. no online player is currently available).

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.

Just a short (almost copy-pasted from j00ru's blog) post with the original advisories of the vulnerabilities we've talked about on CONFidence (and earlier on Hack In The Box Dubai), with slides used by as on the CONFidence conference. The advisories contain most of the technical details we've discussed during the lectures (and some time even more ;>).

Just a redirect-post for all you Windows researcher: Matthew has published a CSRSS opcode table on his blog - go and take a look - http://j00ru.vexillium.org/?p=349&lang=en :)

I've already written, in February, about the first vulnerability found by our team (that would be j00ru and me). Today, Microsoft has published reports about 5 more (well, there were 6 actually, but Microsoft decided to merge two into one, because of the way both of them could be fixed by the same change in the code) :)

About a month ago I've sent a CFP submission for the Hack In The Box 2010 Dubai conference, and yesterday I've officially got informed that my lecture was accepted! So, it looks like I'll be speaking in Dubai, 21th or 22th of April, about recent Windows vulnerabilities found by j00ru and me :)

Today is Exploit Wednesday, so it means that yesterday was Patch Tuesday. So, as every month, Microsoft published Microsoft Security Bulletin Summary (for February 2010) and a couple of patches. One of the vulnerabilities included in the summary (there are 25 altogether) was researched by j00ru and me (in this exact order - j00ru has found it, and we cooperated in researching the possibility of a successful exploitation) - it's the csrss.exe one, which could allow, inter alia, local privilege elevation or information disclosure.

As promised, It's time to reveal the technical story behind the Syndicate Wars Port. The story is divided into two parts - the first, and the second attempt to port this game. Comments are welcomed!

Syndicate Wars is a game published in 1996, created by Bullfrog. The game was written in C (Watcom) for the DOS4GW DOS extender. And of course it has stopped working natively (i.e. without emulators like DOSBox) when the modern operating systems, like GNU/Linux or Windows NT series, emerged. A few years ago my friend, Unavowed, told me about proposition of a project to create a port of Sydicate Word for modern OS'es like the two previous one I've mentioned. The port was to be done by decompiling the original executable file, locating all the functions from the standard C library, locating the DOS4GW and I/O (sound, keyboard, gfx, mouse, etc) dependencies, replacing them with modern native libc function call and libSDL/OpenAL libraries (sometimes using simple wrappers, other times by creating converters), and finally, recompiling it all to form native executables for the modern systems. Yesterday, we've (it was Unavowed who was the clear leader of this project) finished this project, and we've published executables, not only for GNU/Linux and Windows, but also for Mac OSX :)

A few weeks ago j00ru has visited me, and, as one can figure out, some more or less interesting ideas came to be. One of such ideas was to use the Call-Gate mechanism in kernel/driver exploit development on Windows, or, to be more precise, to use a write-what-where condition to convert a custom LDT entry into a Call-Gate (this can be done by modifying just one byte), and using the Call-Gate to elevate the code privilege from user-land to ring0. The idea was turned into some PoC exploits, and finally, into the paper presented below.

Just a quick info. j00ru has published on his blog a syscall number/name table for the Win32k syscall shadow table (user32.dll, gdi32.dll and DirectX use it) - http://j00ru.vexillium.org/win32k_syscalls/ (it's very similar to the Metasploit one, however the one on the Metasploit page contains only kernel syscalls, and this one contains only win32k syscalls). If you like digging in the low level stuff, this is definitely something worth checking out!

(Be sure to checkout the demonstration video at the bottom of the page). Two months ago I've written about banker troyans, that some change DNS settings, other add a list of domains (used by financial institutions) to the c:\windows\system32\drivers\etc\hosts file. Of course both mentioned behaviors result in redirecting the user to some evil phishing site (sometimes an unlucky user might loose some money in effect).

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.

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!

I'm sorry, but the slides are, again, in Polish (well, the source codes and demo videos don't have Polish in them, mostly because they don't have any text at all). I've been informed that a video from the lecture will available, so I'll take my time and attach English subtitles if anyone will be interested in it (let me know if you are interested).

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...

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

I've made a few more compares between exports in DLLs in Windows Vista SP1 and Windows 7 Beta.

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 ;>

Finally You can download the official Windows 7 Beta release (unofficially You could do it for some time now). So I've downloaded it, installed it (looks cool), and started to play...

Today post is for all You Batmans out there ;>

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

I've caught in my hands some malware, that had a very interesting idea about using one of Windows's entrypoint for making sure it would be run after a reboot.

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.

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...

Some time ago I've analyzed a piece of malware, which was protected using an interesting schema...

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.

It looks like that on 13th of October the first phase of this years Hacker Challenge starts - it's a tournament for RE organized by some unknown company from the USA. Well, I see that they cut down on the prizes this year, it must be the crisis. Anyway, since all the places in the tournament have some prize with it, I encourage REs to take part.

Yesterday another method of making Google Chrome automatically download a file was posted on bugtraq. Of course an old discussion was restarted - is automatic file download a bug, feature, or a vulnerability?

A short info. Someone (Le Duc Anh - SVRT - Bkis) posted on the FD list about a Remote Buffer Overflow in Chrome, needing a little interaction from the user - the user needs to click 'Save as...' (the buffer overflow is related to the handling of the <title> while saving files). The researcher has provided two PoC exploits, one is said to run a calculator (on XP SP2, but it didn't work for me), and the other is just a DoS. It must be noted that that both the renderers and browser processes are crashed, so the vuln is located either in the browser, or is magically transfered from the renderer to the browser.

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.