PreBoot Authentication Password Cracking on a budget

H2HC conference, Sao Paulo, Brasil

Jonathan Brossard, Nov 2009

[email protected]

«A desobediência é uma virtude necessária à criatividade »

- Raul Seixas

Before we start...

Thanks to the organizers, sponsors and volonteers for making this happen in Brasil :)

Thank you for coming.

I'm very happy to be here !



Keyboard internals

Brute forcer design

Experimental results

Conclusion & bonus !

Goals, contributions :

Demonstrate the feasability of brute force attacks on preboot authentication passwords.

Give a pessimist estimation of the cost of password cracking on full encryption software using a generic instrumentation methodology.

Use this metric to adapt password length policy acording with the value of the protected assets.

Juridical environment

Cryptographic software is mostly legalized in both North and South America and Europe.

Wikipedia : « In China, a license is still required to use cryptography. Many countries have tight restrictions on the use of cryptography. Among the more restrictive are laws in Belarus, Kazakhstan, Mongolia, Pakistan, Russia, Singapore, Tunisia, and Vietnam. »

Users of cryptographic software must give either a copy of their keys or plain text equivalent of any text asked by authorities in case of trial, or face prison sentences in most countries.

Crypto software poor reviews

+Governments interrests

+global business communications

+terrorism blah blah

=high risk of (cryptographic ?) backdoors

&privacy threats

Is such a thing credible?

Quoting Wikipedia :

«DES was designed to be resistant to differential cryptanalysis, a powerful and general cryptanalytic technique known to NSA and IBM, that became publicly known only when it was rediscovered in the late 1980s. According to Steven Levy, IBM rediscovered differential cryptanalysis, but kept the technique secret at NSA's request. The technique became publicly known only when Biham and Shamir re-rediscovered and announced it some years later. The entire affair illustrates the difficulty of determining what resources and knowledge an attacker might actually have. »

Technical motivations

Even serious developpers don't test their crypto software enough, if at all (Debian SSL bug : ~32k keys).

Vendors (in particular Truecypt) have adopted policies where they do not cover certain attacks (eg: Plain text password leakage as we presented at Defcon 0x16, or Joanna Rutowska's evilmaid attack) leaving the

More globally

Non tech people will say :

«if it fails just go for bruteforce ».

• Sure.. but how do you do it ?

I couldn't find a public tool myself.

And then I started to wonder...

Keyboard internals

II-1) Boot sequence overview

II-2) BIOS API for user

inputs (1/2)

Interruption 0x16 invoked via functions


ah=0x00 , “Get keystroke” : returns the keystroke scancode in AH and its ASCII code in AL.

ah=0x01 , “Check for keystroke” : idem, but the Zero Flag is set if no keystroke is available in the Bios keyboard buffer.

II-2) BIOS API for user inputs


eg : lilo password reading routine :

II-3) BIOS internals for keyboard


II-4) BIOS keyboard buffer

Remanance... (1/3)

Filling the BIOS keyboard buffer (with the keyboard) :

II-4) BIOS keyboard

buffer Remanence...

Reading the BIOS keyboard buffer (using int 0x16, ah=0x00 or 0x01) :


Simulating keystrokes by

PIC programming (from real mode)


Simulating keystrokes by

PIC programming

(from protected mode under x86 GNU/Linux)

(aka: brute force any GUI)

Exemple of application :

Rebooting a computer protected with a password (assuming you know that password - for now ;), by simulating keystrokes at boot time...

Attack scenario :









I/O Port