Bypassing the Windows 8.1 Picture Password feature with a kernel debugger

Introduction

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

Advertisements

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

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