Bypassing the Windows 8.1 Picture Password feature with a kernel debugger


Let me start this post by stating that the stuff described here is NOT a vulnerability. I just ported the idea of patching the function which validates the Windows logon password (the well-known msv1_0!MsvpPasswordValidate)Ā to the new, password-less login feature of Windows 8 / 8.1: Picture Password (does anyone use it at all? šŸ™‚ ).

It requires a kernel debugger, which grants full control overĀ the machine, so this is NOT a vulnerability.

The trickĀ of patching msv1_0!MsvpPasswordValidateĀ has been known at least since 2006, when Adam Boileau presented his work “Hit by a Bus: Physical Access Attacks with FirewireĀ [PDF]” duringĀ the Ruxcon 2006 conference; for a detailed explanation of how this trick works you can visitĀ the following blogpost: “Silly debugger tricks: Using KD to reset a forgotten administrator password“.

This trick of patching msv1_0!MsvpPasswordValidate in order to bypass the Windows login screen has been integrated into DMA attack tools like winlockpwn (by the very Adam Boileau), and more recently,Ā Inception.

By the way, if you are interested in attacks against these authentication schemes based on picture gestures, you can find the following links interesting:


Continue reading

Defcon 23 CTF Quals 2015 – Babycmd writeup

The babycmd challenge was an x64 ELF binary supporting 4 commands: ping, dig, host, and exit. In the case of ping, dig and host, it just calls the corresponding binary with a user-controlled argument.

This binary uses signal(2) 0xE (SIGALRM – Timer signal from alarm(2)) and alarm() in order to terminate the process after 45 seconds. This was a bit annoying while working on this binary, so I replaced the original argument 0x2d for alert() with a 0; as explained in the alarm(2) documentation, if the seconds argument is 0, no new alarm is scheduled.

Original code:

.text:0000000000001267                 mov     edi, 0Eh
.text:000000000000126C                 call    _signal
.text:0000000000001271                 mov     edi, 0x2d
.text:0000000000001276                 call    _alarm

Patched code:

.text:0000000000001267                 mov     edi, 0Eh
.text:000000000000126C                 call    _signal
.text:0000000000001271                 mov     edi, 0
.text:0000000000001276                 call    _alarm

For all the supported commands, this program does some basic validation of the user-provided argument before calling the corresponding binary. This filter is a kind of blacklist which rejects user input if it contains characters like “&”, “;” and “|”, which may be abused to inject OS commands. You should note that this function also removes spaces (char 0x20) from the user input.


Continue reading

A time-based anti-debugging technique using the Kernel Transaction Manager

Anti-debugging techniques have been known for a long time. One way to detect the presence of debuggers (and also DBI frameworks like Pin, emulators, etc) is by measuring the time taken to execute a piece of code and comparing it against a maximum tolerated amount of time. This way we can detect if our code is being debugged/instrumented/emulated by detecting the latency introduced by the instrumentation tool.

In this Reverse Engineering StackExchange thread you can find a set of time-related functions that are commonly used in Windows environments in order to detect the presence of debuggers using time-checking strategies:

  • GetTickCount()
  • time()
  • RDTSC instruction
  • RDPMC instruction
  • GetLocalTime()
  • GetSystemTime()
  • KiGetTickCount()
  • QueryPerformanceCount()
  • timeGetTime()

You can find more details on these time-based antidebugging tricks on “The Ultimate Anti-Debugging Reference” by Peter Ferrie [PDF].

So a few weeks ago I found one more way to perform time-based debugger detection; the (mildly) interesting thing is that it doesn’t use functions that are directly related to time stuff, so it can be a bit more subtle than those well-known time functions.

The technique is based on the Windows Kernel Transaction Manager, which can be used to implement both transacted file operations and transacted Registry operations.

Continue reading

Analysis of CVE-2014-8476: a FreeBSD kernel memory disclosure vulnerability

One week ago, on November 4th, 2014, the FreeBSD team published security advisory FreeBSD-SA-14:25.setlogin describing an information disclosure vulnerability in setlogin(2) / getlogin(2), which could allow an unprivileged user to disclose kernel memory contents.

This vulnerability (identified as CVE-2014-8476) affects all supported versions of FreeBSD. This is the problem description, taken from the advisory:

When setlogin(2) is called while setting up a new login session, the login name is copied into an uninitialized stack buffer, which is then copied into a buffer of the same size in the session structure. The getlogin(2) system call returns the entire buffer rather than just the
portion occupied by the login name associated with the session.

The code of the vulnerable function (getlogin in FreeBSD 8.4, sys_getlogin in newer versions) is located at /sys/kern/kern_prot.c:

Continue reading

A brief Reverse-Engineering note on Structured Exception Handling after Stack Pivoting

A few days ago Nahuel and me took a look at a piece of shellcode that wasn’t working.
After performing a stack pivoting and successfully executing a ROP chain, the shellcode was supposed to setup an Structured Exception Handler in order to catch memory access errors when scanning the address space of the process. But for some unknown reason, the Exception Handler wasn’t being called when an exception was triggered.

The Test Case

This is a minimal test case to reproduce the issue:

1) allocate some memory for a new stack
2) make ESP point to this new memory region
3) setup a Structured Exception Handler (0x00401040 in this example)
4) generate an exception

Continue reading

A black-box approach against obfuscated regular expressions using Pin

After reading the “Regular Expressions Obfuscation Under the Microscope” blogpost by Axel “0vercl0k” Souchet less than two weeks ago, I decided to try the approach detailed by Jonathan Salwan in his blogpost “A binary analysis, count me if you can“.

[NOTE: You probably want to read the two blogposts mentioned above before continuing reading.]

In the latter post, Jonathan explains how to find the right password in a crackme program with a black-box approach, by instrumenting the program with Intel’s Pin, a Dynamic Binary Instrumentation (DBI) framework. The basic idea of the approach is that (depending on how the target program was coded), you can analyze the execution flow of the program by counting the number of instructions executed when processing different input strings, and based on that instruction count, determine whether the program is accepting or not the input characters. Quoting Jonathan, this approach works for programs that rely “on a simple string-compare function that returns as soon as the function sees a difference” between your input string and the correct string; that is, it works for programs in which “as long as the comparison is correct, the number of instruction executed increases“.

Part 1 – Simple, non-obfuscated regular expression

Let’s take a look at the first C program that accepts the regular expression ā€œHi-[0-9]{4}ā€, taken from the “Regular Expressions Obfuscation Under the Microscope” post:

Continue reading

ForbiddenBITS CTF 2013 – Poir 150 Write up

We were provided with a pcap capture. The capture has mostly HTTP traffic, which seems to be the transfer of a file named key.7z. The HTTP client, which is Python’s urllib, requests the file in very small chunks, using the “Range: bytes=xx-yy” header.

To make things more complicated, the HTTP client requests the byte ranges without any particular order, and it also requests overlapping ranges. These details make it harder to extract the key.7z file from the pcap capture.


So I applied the following filter in Wireshark, in order to show just the HTTP responses from the server:

http && ip.src ==

Continue reading

ForbiddenBITS CTF 2013 – Old 50 Write up

We were provided with a bin.bin file, which size is 512 bytes. Doing $ file bin.bin shows us that the file is a boot sector.

In order to run the boot sector I’ve followed an article from the developers of MikeOS (Note that I’ve linked to the Google Cache copy since the original site appears to be down).

So I downloaded a floppy disk image, renamed it to floppy.flp, and then I copied the boot sector of this challenge to the floppy disk image:

$ dd status=noxfer conv=notrunc if=bin.bin of=floppy.flp

Then I started QEMU using the floppy disk image containing the CTF boot sector:

$ qemu-system-i386 -fda floppy.img

QEMU boots from our floppy disk image, and the boot sector asks for a password:

Continue reading

Burning a bootloader to an Arduino Nano using another Arduino

Recently I have bought a cheap clone of Arduino Nano from the Chinese site Deal Extreme. Unfortunately, that product (SKU 81877) comes without a bootloader. The main sign that indicates you that the Arduino doesn’t have a bootloader is that the “L” LED, next to the Power LED, doesn’t blink when the Arduino is connected to the power source or when the Reset button is pressed.

It is possible to use your Arduino without a bootloader, but it won’t work with the Arduino IDE and you will need an external AVR Programmer like this one in order to upload sketches.

So I needed to follow two main steps in order to get my Arduino Nano working without buying an AVR programmer:

  1. Solder the six ICSP pins. These pins are provided in the same package, but you need to solder them to the Arduino board.
  2. Use another Arduino (a working one) as an ISP programmer in order to burn a bootloader onto the non-working one. I borrowed another Arduino Nano from my friend Nahuel (let me say thank you to him and Dani, who helped me with all of this), but other models shoud work too.

The Arduino board I bought looked like this. Notice that the ICSP header slot, highlighted in red, doesn’t have any pins soldered to it:


Continue reading