Sunday, September 22, 2019

Workshop and Presentation Slides and Materials

All of our previous workshop and presentation slides and materials are available in one location, from Google Drive.

From now on, we are only going to keep the latest-greatest version of each talk/workshop and announce changes on Twitter.

Thursday, September 19, 2019

Hacktivity 2018 badge - quick start guide for beginners

You either landed on this blog post because 
  • you are a huge fan of Hacktivity
  • you bought this badge around a year ago
  • you are just interested in hacker conference badge hacking. 
or maybe all of the above. Whatever the reasons, this guide should be helpful for those who never had any real-life experience with these little gadgets. 
But first things first, here is a list what you need for hacking the badge:
  • a computer with USB port and macOS, Linux or Windows. You can use other OS as well, but this guide covers these
  • USB mini cable to connect the badge to the computer
  • the Hacktivity badge from 2018
By default, this is how your badge looks like.

Let's get started

Luckily, you don't need any soldering skills for the first steps. Just connect the USB mini port to the bottom left connector on the badge, connect the other part of the USB cable to your computer, and within some seconds you will be able to see that the lights on your badge are blinking. So far so good. 

Now, depending on which OS you use, you should choose your destiny here.


The best source of information about a new device being connected is
# dmesg

The tail of the output should look like
[267300.206966] usb 2-2.2: new full-speed USB device number 14 using uhci_hcd
[267300.326484] usb 2-2.2: New USB device found, idVendor=0403, idProduct=6001
[267300.326486] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[267300.326487] usb 2-2.2: Product: FT232R USB UART
[267300.326488] usb 2-2.2: Manufacturer: FTDI
[267300.326489] usb 2-2.2: SerialNumber: AC01U4XN
[267300.558684] usbcore: registered new interface driver usbserial_generic
[267300.558692] usbserial: USB Serial support registered for generic
[267300.639673] usbcore: registered new interface driver ftdi_sio
[267300.639684] usbserial: USB Serial support registered for FTDI USB Serial Device
[267300.639713] ftdi_sio 2-2.2:1.0: FTDI USB Serial Device converter detected
[267300.639741] usb 2-2.2: Detected FT232RL
[267300.643235] usb 2-2.2: FTDI USB Serial Device converter now attached to ttyUSB0

Dmesg is pretty kind to us, as it even notifies us that the device is now attached to ttyUSB0. 

From now on, connecting to the device is exactly the same as it is in the macOS section, so please find the "Linux users, read it from here" section below. 


There are multiple commands you can type into Terminal to get an idea about what you are looking at. One command is:
# ioreg -p IOUSB -w0 -l

With this command, you should get output similar to this:

+-o FT232R USB UART@14100000  <class AppleUSBDevice, id 0x100005465, registered, matched, active, busy 0 (712 ms), retain 20>
    |   {
    |     "sessionID" = 71217335583342
    |     "iManufacturer" = 1
    |     "bNumConfigurations" = 1
    |     "idProduct" = 24577
    |     "bcdDevice" = 1536
    |     "Bus Power Available" = 250
    |     "USB Address" = 2
    |     "bMaxPacketSize0" = 8
    |     "iProduct" = 2
    |     "iSerialNumber" = 3
    |     "bDeviceClass" = 0
    |     "Built-In" = No
    |     "locationID" = 336592896
    |     "bDeviceSubClass" = 0
    |     "bcdUSB" = 512
    |     "USB Product Name" = "FT232R USB UART"
    |     "PortNum" = 1
    |     "non-removable" = "no"
    |     "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
    |     "bDeviceProtocol" = 0
    |     "IOUserClientClass" = "IOUSBDeviceUserClientV2"
    |     "IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}
    |     "kUSBCurrentConfiguration" = 1
    |     "Device Speed" = 1
    |     "USB Vendor Name" = "FTDI"
    |     "idVendor" = 1027
    |     "IOGeneralInterest" = "IOCommand is not serializable"
    |     "USB Serial Number" = "AC01U4XN"
    |     "IOClassNameOverride" = "IOUSBDevice"
    |   } 
The most important information you get is the USB serial number - AC01U4XN in my case.
Another way to get this information is
# system_profiler SPUSBDataType

which will give back something similar to:

          Product ID: 0x6001
          Vendor ID: 0x0403  (Future Technology Devices International Limited)
          Version: 6.00
          Serial Number: AC01U4XN
          Speed: Up to 12 Mb/sec
          Manufacturer: FTDI
          Location ID: 0x14100000 / 2
          Current Available (mA): 500
          Current Required (mA): 90
          Extra Operating Current (mA): 0

The serial number you got is the same.

What you are trying to achieve here is to connect to the device, but in order to connect to it, you have to know where the device in the /dev folder is mapped to. A quick and dirty solution is to list all devices under /dev when the device is disconnected, once when it is connected, and diff the outputs. For example, the following should do the job:

ls -lha /dev/tty* > plugged.txt
ls -lha /dev/tty* > np.txt
vimdiff plugged.txt np.txt

The result should be obvious, /dev/tty.usbserial-AC01U4XN is the new device in case macOS. In the case of Linux, it was /dev/ttyUSB0.

Linux users, read it from here. macOS users, please continue reading

Now you can use either the built-in screen command or minicom to get data out from the badge. Usually, you need three information in order to communicate with a badge. Path on /dev (you already got that), speed in baud, and the async config parameters. Either you can guess the speed or you can Google that for the specific device. Standard baud rates include 110, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200, 128000 and 256000 bits per second. I usually found 1200, 9600 and 115200 a common choice, but that is just me.
Regarding the async config parameters, the default is that 8 bits are used, there is no parity bit, and 1 stop bit is used. The short abbreviation for this is 8n1. In the next example, you will use the screen command. By default, it uses 8n1, but it is called cs8 to confuse the beginners.

If you type:
# screen /dev/tty.usbserial-AC01U4XN 9600
# screen /dev/ttyUSB0 9600
and wait for minutes and nothing happens, it is because the badge already tried to communicate via the USB port, but no-one was listening there. Disconnect the badge from the computer, connect again, and type the screen command above to connect. If you are quick enough you can see that the amber LED will stop blinking and your screen command is greeted with some interesting information. By quick enough I mean ˜90 seconds, as it takes the device 1.5 minutes to boot the OS and the CTF app.


When you connect the device to Windows, you will be greeted with a pop-up.

Just click on the popup and you will see the COM port number the device is connected to:

In this case, it is connected to COM3. So let's fire up our favorite putty.exe, select Serial, choose COM3, add speed 9600, and you are ready to go!

You might check the end of the macOS section in case you can't see anything. Timing is everything.


Welcome to the Hacktivity 2018 badge challenge!

This challenge consists of several tasks with one or more levels of
difficulty. They are all connected in some way or another to HW RE
and there's no competition, the whole purpose is to learn things.

Note: we recommend turning on local echo in your terminal!
Also, feel free to ask for hints at the Hackcenter!

Choose your destiny below:

  1. Visual HW debugging
  2. Reverse engineering
  3. RF hacking
  4. Crypto protection

Enter the number of the challenge you're interested in and press [
Excellent, now you are ready to hack this! In case you are lost in controlling the screen command, go to

I will not spoil any fun in giving out the challenge solutions here. It is still your task to find solutions for these.

But here is a catch. You can get a root shell on the device. And it is pretty straightforward. Just carefully remove the Omega shield from the badge. Now you see two jumpers; by default, these are connected together as UART1. As seen below.

But what happens if you move these jumpers to UART0? Guess what, you can get a root shell! This is what I call privilege escalation on the HW level :) But first, let's connect the Omega shield back. Also, for added fun, this new interface speaks on 115200 baud, so you should change your screen parameters to 115200. Also, the new interface has a different ID under /dev, but I am sure you can figure this out from now on.

If you connect to the device during boot time, you can see a lot of exciting debug information about the device. And after it boots, you just get a root prompt. Woohoo! 
But what can you do with this root access? Well, for starters, how about running 
# strings hello | less

From now on, you are on your own to hack this badge. Happy hacking.
Big thanks to Attila Marosi-Bauer and Hackerspace Budapest for developing this badge and the contests.

PS: In case you want to use the radio functionality of the badge, see below how you should solder the parts to it. By default, you can process slow speed radio frequency signals on GPIO19. But for higher transfer speeds, you should wire the RF module DATA OUT pin with the RX1 free together.

Wednesday, August 15, 2018

How to build a "burner device" for DEF CON in one easy step

TL;DR: Don't build a burner device. Probably this is not the risk you are looking for.


Every year before DEF CON people starts to give advice to attendees to bring "burner devices" to DEF CON. Some people also start to create long lists on how to build burner devices, especially laptops. But the deeper we look into the topic, the more confusing it gets. Why are we doing this? Why are we recommending this? Are we focusing on the right things?

What is a "burner device" used for?

For starters, the whole "burner device" concept is totally misunderstood, even within the ITSEC community. A "burner device" is used for non-attribution. You know, for example, you are a spy and you don't want the country where you live to know that you are communicating with someone else. I believe this is not the situation for most attendees at DEF CON. More info about the meaning of "burner"

Burner phone means it has a throwaway SIM card with a throwaway phone, used for one specific operation only. You don't use the "burner device" to log in to your e-mail account or to VPN to your work or home.
But let's forget this word misuse issue for a moment, and focus on the real problem.

The bad advice

The Internet is full of articles focusing on the wrong things, especially when it comes to "burner devices". Like how to build a burner laptop, without explaining why you need it or how to use it.
The problem with this approach is that people end up "burning" (lame wordplay, sorry) significant resources for building a secure "burner device". But people are not educated about how they should use these devices.

The threats

I believe the followings are some real threats which are higher when you travel:
1. The laptop getting lost or stolen.
2. The laptop getting inspected/copied at the border.

These two risks have nothing to do with DEF CON, this is true for every travel.

Some other risks which are usually mentioned when it comes to "burner devices" and DEF CON:
3. Device getting owned via physical access while in a hotel room.
4. Network traffic Man-in-the-middle attacked. Your password displayed on a Wall of Sheep. Or having fun with Shellshock with DHCP. Information leak of NTLM hashes or similar.
5. Pwning the device via some nasty things like WiFi/TCP/Bluetooth/LTE/3G/GSM stack. These are unicorn attacks.

6. Pwning your device by pwning a service on your device. Like leaving your upload.php file in the root folder you use at CTFs and Nginx is set to autostart. The author of this article cannot comment on this incident whether it happened in real life or is just an imaginary example. 

How to mitigate these risks? 

Laptop getting stolen/lost/inspected at the border?
1. Bring a cheap, empty device with you. Or set up a fake OS/fake account to log in if you really need your day-to-day laptop. This dummy account should not decrypt the real files in the real account.

Device getting owned while in a hotel room with physical access

1. Don't bring any device with you.
2. If you bring any, make it tamper-resistant. How to do that depends on your enemy, but you can start by using nail glitter and Full Disk Encryption. Tools like Do Not Disturb help. It also helps if your OS supports suspending DMA devices before the user logs in.
3. If you can't make the device tamper-resistant, use a device that has a good defense against physical attackers, like iOS.
4. Probably you are not that important anyway that anyone will spend time and resources on you. If they do, probably you will only make your life miserable with all the hardening, but still, get pwned.

Network traffic Man-in-the-middle attacked

1. Don't bring any device with you.
2. Use services that are protected against MiTM. Like TLS.
3. Update your OS to the latest and greatest versions. Not everyone at DEF CON has a 0dayz worth of 100K USD, and even the ones who have won't waste it on you. 
4. Use fail-safe VPN. Unfortunately, not many people talk about this or have proper solutions for the most popular operating systems.
5. For specific attacks like Responder, disable LLMNR, NBT-NS, WPAD, and IPv6 and use a non-work account on the machine. If you don't have the privileges to do so on your machine, you probably should not bring this device with you. Or ask your local IT to disable these services and set up a new account for you.

Pwning the device via some nasty thing like WiFi/TCP/Bluetooth/LTE/3G/GSM stack

1. Don't bring any device with you.
2. If you bring any, do not use this device to log in to work, personal email, social media, etc.
3. Don't worry, these things don't happen very often. 

Pwning your device by pwning a service on your device

Just set up a firewall profile where all services are hidden from the outside. You rarely need any service accessible on your device at a hacker conference.


If you are still so afraid to go there, just don't go there. Watch the talks at home. But how is the hotel WiFi at a random place different from a hacker conference? Turns out, it is not much different, so you better spend time and resources on hardening your daily work devices for 365 days, instead of building a "burner device".

You probably need a "burner device" if you are a spy for a foreign government. Or you are the head of a criminal organization. Otherwise, you don't need a burner device. Maybe you need to bring a cheap replacement device.

Saturday, July 21, 2018

Recovering data from an old encrypted Time Machine backup

Recovering data from a backup should be an easy thing to do. At least this is what you expect. Yesterday I had a problem which should have been easy to solve, but it was not. I hope this blog post can help others who face the same problem.

The problem

1. I had an encrypted Time Machine backup which was not used for months
2. This backup was not on an official Apple Time Capsule or on a USB HDD, but on a WD MyCloud NAS
3. I needed files from this backup
4. After running out of time I only had SSH access to the macOS, no GUI

The struggle

By default, Time Machine is one of the best and easiest backup solution I have seen. As long as you stick to the default use case, where you have one active backup disk, life is pink and happy. But this was not my case.

As always, I started to Google what shall I do. One of the first options recommended that I add the backup disk to Time Machine, and it will automagically show the backup snapshots from the old backup. Instead of this, it did not show the old snapshots but started to create a new backup. Panic button has been pressed, backup canceled, back to Google.

Other tutorials recommend to click on the Time Machine icon and pressing alt (Option) key, where I can choose "Browse other backup disks". But this did not list the old Time Machine backup. It did list the backup when selecting disks in Time Machine preferences, but I already tried and failed that way.

YAT (yet another tutorial) recommended to SSH into the NAS, and browse the backup disk, as it is just a simple directory where I can see all the files. But all the files inside where just a bunch of nonsense, no real directory structure.

YAT (yet another tutorial) recommended that I can just easily browse the content of the backup from the Finder by double-clicking on the sparse bundle file. After clicking on it, I can see the disk image on the left part of the Finder, attached as a new disk.
Well, this is true, but because of some bug, when you connect to the Time Capsule, you don't see the sparse bundle file. And I got inconsistent results, for the WD NAS, double-clicking on the sparse bundle did nothing. For the Time Capsule, it did work.
At this point, I had to leave the location where the backup was present, and I only had remote SSH access. You know, if you can't solve a problem, let's complicate things by restrict yourself in solutions.

Finally, I tried to check out some data forensics blogs, and besides some expensive tools, I could find the solution.

The solution

Finally, a blog post provided the real solution - hdiutil.
The best part of hdiutil is that you can provide the read-only flag to it. This can be very awesome when it comes to forensics acquisition.

To mount any NAS via SMB:
mount_smbfs afp://<username>@<NAS_IP>/<Share_for_backup> /<mountpoint>

To mount a Time Capsule share via AFP:
mount_afp afp://any_username:password@<Time_Capsule_IP>/<Share_for_backup> /<mountpoint>

And finally this command should do the job:
hdiutil attach test.sparsebundle -readonly

It is nice that you can provide read-only parameter.

If the backup was encrypted and you don't want to provide the password in a password prompt, use the following:
printf '%s' 'CorrectHorseBatteryStaple' | hdiutil attach test.sparsebundle -stdinpass -readonly

Note: if you receive the error "resource temporarily unavailable", probably another machine is backing up to the device

And now, you can find your backup disk under /Volumes. Happy restoring!

Probably it would have been quicker to either enable the remote GUI, or to physically travel to the system and login locally, but that would spoil the fun.

Friday, May 19, 2017

Pcap of Wannacry Spreading Using EthernalBlue

Saw that a lot of people were looking for a pcap with WannaCry spreading Using EthernalBlue.

I have put together a little "petri dish" test environment and started looking for a sample that has the exploit. Some samples out there simply do not have the exploit code, and even tough they will encrypt the files locally, sometimes the mounted shares too, they would not spread.

Luckily, I have found this nice blog post from McAfee Labs: with the reference to the sample SHA256: 24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c (they keep referring to samples with MD5, which is still a very-very bad practice, but the hash is MD5: DB349B97C37D22F5EA1D1841E3C89EB4)

Once I got the sample from the VxStream Sandbox site, dropped it in the test environment, and monitored it with Security Onion. I was super happy to see it spreading, despite the fact that for the first run my Windows 7 x64 VM went to BSOD as the EthernalBlue exploit failed.

But the second run was a full success, all my Windows 7 VMs got infected. Brad was so kind and made a guest blog post at one of my favorite sites, so you can find the pcap, description of the test environment and some screenshots here: