18 Jul 2017
My hacker summer camp planning posts are among the most-viewed on my blog, and I
was recently reminded I hadn’t done one for 2017 yet, despite it being just
around the corner!
Though many tips will be similar, feel free to check out the two posts from last
year as well:
If you don’t know, Hacker Summer Camp is a nickname for 3 information security
conferences in one week in Las Vegas every July/August. This includes Black
Hat, BSides Las Vegas, and DEF CON.
Black Hat is the most “corporate” of the 3 events, with a large area of vendor
booths, great talks (though not all are super-technical) and a very
corporate/organized feel. If you want a serious, straight-edge security
conference, Black Hat is for you. Admission is several thousand dollars, so
most attendees are either self-employed and writing it off, or paid by their
BSides Las Vegas is a much smaller (~1000 people) conference, that’s heavily
community-focused. With tracks intended for those new to the industry, getting
hired, and a variety of technical talks, it has something for everyone. It also
has my favorite CTF: Pros vs Joes. You can donate
for admission, or get in line for one of ~450 free admissions. (Yes, the line
starts early. Yes, it quickly sells out.)
DEF CON is the biggest of the conferences. (And, in my opinion, the “main
event”.) I think of DEF CON as the Burning Man of hacker conferences: yes,
there’s tons of talks, but it’s also a huge opportunity for members of the
community to show off what they’re doing. It’s also a huge party at night: tons
of music, drinking, pool parties. At DEF CON, there is more to do than can be
done, so you’ll need to pick and choose.
Hopefully you already have your travel plans (hotel/airfare/etc.) sorted. It’s
a bit late for me to provide advice there this year. :)
What To Do
Make sure you do things. You only get out of Hacker Summer Camp what you put
into it. You can totally just go and sit in conference rooms and listen to
talks, but you’re not going to get as much out of it as you otherwise could.
Black Hat has excellent classes, so you can get into significantly more depth
than a 45 minute talk would allow. If you have the opportunity (they’re
expensive), you should take one.
If you’re not attending Black Hat, come over to BSides Las Vegas. They go on in
parallel, so it’s a good opportunity for a cheaper option and for a more
community feel. At BSides, you can meet some great members of the community,
hear some talks in a smaller intimate setting (you might actually have a chance
to talk to the speaker afterwards), and generally have a more laid-back time
than Black Hat.
DEF CON is entirely up to you: go to talks, or don’t. Go to villages and meet
people, see what they’re doing, get hands on with things. Go to the vendor area
and buy some lockpicks, WiFi pineapples, or more black t-shirts. Drink with
some of the smartest people in the industry. You never know who you’ll meet.
Whatever you choose, you can have a blast, but you need to make sure you manage
your energy. I’ve made myself physically sick by trying to do it all – just
accept that you can’t and take it easy.
I’m particularly excited to check out the IoT village again this year. (As
regular readers know, I have a soft spot for the Insecurity of Things.)
Likewise, I look forward to seeing small talks in the villages.
Whatever you do, be an active participant. I’ve personally spent too much time
not participating: not talking, not engaging, not doing. You won’t get the most
out of this week by being a wallflower.
DEF CON has a reputation for being the most dangerous network in the world, but
I believe that title depends on how you look at it. In my experience, it’s a
matter of quality vs quantity. While I have no doubt that the open WiFi at DEF
CON probably has far more than it’s fair share of various hijinks (sniffing,
ARP spoofing, HTTPS downgrades, fake APs, etc.), I genuinely don’t anticipate
seeing high-value 0-days being deployed on this network. Using an 0-day on the
DEF CON network is going to burn it: someone will see it and your 0-day is
over. Some of the best malware reversers and forensics experts in the world are
present, I don’t anticipate someone using a high-quality bug in modern software
on this network and wasting it like that.
Obviously, I can’t make any guarantees, but the following advice approximately
matches my own threat model. If you plan to connect to shady networks or
CTF-type networks, you probably want to take additional precautions. (Like
using a separate laptop, which is the approach I’m taking this year.)
That being said, you should take reasonable precautions against more run of the
- Use Full Disk Encryption (in case your device gets lost/stolen)
- Be fully updated on a modern OS (putting off patches? might be the time to
- Don’t use open WiFi
- Turn off any radios you’re not using (WiFi, BT)
- Disable 3G downgrade on your phone if you can (LTE only)
- Don’t accept updates offered while you’re in Vegas
- Don’t run random downloads :)
- Run a local firewall dropping all unexpected traffic
Using a current, fully patched iOS or Android device should be relatively safe.
ChromeOS is a good choice if you just need internet from a laptop-style device.
Fully patched Windows/Linux/OS X are probably okay, but you have somewhat larger
attack surface and less protection against drive-by malware.
Your single biggest concern on any network (DEF CON or not) should be sending
plaintext over the network. Use a VPN. Use HTTPS. Be especially wary of
phishing. Use 2-Factor. (Ideally U2F, which is cryptographically designed to
Personal Security & Safety
This is Vegas. DEF CON aside, watch what you’re doing. There are plenty of
pick pockets, con men, and general thieves in Las Vegas. They’re there to prey
on tourists, and whether you’re there for a good time or for a con, you’re their
prey. Keep your wits about you.
Check ATMs for skimmers. (This is a good life pro tip.)
Don’t use the ATMs near the con. If you’re not sure if you can tell if an ATM
has a skimmer: bring enough cash in advance. Lock it in your in-room safe.
Does your hotel use RFID-based door locks? May I suggest
Planning to drink? (I am.) Make sure you drink water too. Vegas is super-hot,
and dehydration will make you very sick (or worse). I try to drink 1/2 a liter
of water for every drink I have, but I rarely meet that goal. It’s still a good
goal to have.
Are you paranoid?
Maybe. I get paid to execute attacks and think like an attacker, so it comes
with the territory. I’m going to an event to see other people who do the same
thing. I’m not convinced the paranoia is unwarranted.
Will I get hacked?
Probably not, if you spend a little time preparing.
Should I go to talks?
Are they interesting to you? Go to talks if they’re interesting and timely.
Note that most talks are recorded and will be posted online a couple of months
after the conferences (or can be bought sooner from Source of Knowledge). A
notable exception is that SkyTalks are not recorded. And don’t try to
record them yourself – you’ll get bounced from the room.
What’s the 3-2-1 rule?
3 hours of sleep, 2 meals, and 1 shower. Every day. I prefer 2 showers
myself – Vegas is pretty hot.
07 Jul 2017
If you follow DEF CON news at all, you’ll know that there’s
been some kind of issue with the
But don’t worry, DEF CON will have badges, but so will the community!
What do I mean by this? Well, badge hacking has long been a DEF CON tradition,
but in the past few years, we’ve seen more and more unofficial badges appearing
at DEF CON. This year seems to be a massive upswing, and while I’m sure some of
that was in progress before the badge announcement,
I believe at least some of
it is the community response to the DEF CON badge issue. (Edit:
All of the listed badges were apparently in the works before the DEF CON
announcement. Thanks to @wbm312 for setting me
I’ve tried to collect information about all the unofficial badges I can find,
but I’d imagine there are many more that I haven’t heard about, or whose creator
just isn’t talking about it. I know for a fact at least one such private badge
Know of another badge? Ping me on Twitter (@Matir)
and I’ll update. Sorry I have so many unknowns, but lots of the badges are
Available for Sale
This includes badges that were available for sale at some point, even if now
sold out. Basically, if at any point you could exchange cash, credit, bitcoin,
litecoin, ethereum, gold ingots, or any other form of value for the badge, I’m
putting it here. (I’d call it “commercial”, but most of these are a labor of
love and the money just helps the creator not go broke with their labors.)
AND!XOR DEF CON 25 Indie Badge
2017 WiFi Badge
Mr Robot Badge
The Ides of DEF CON
- Link: https://dc25spqr.com/
- Features: Sub-1GHz Radio, Blinky Lights, Sound, LED Screen
- Availability: Sold Out, Kickstarter Only, Open Source
- Price: $120
Queercon 14 Badge
Beyond Binaries Badge
DEF CON Furs
DEF CON Darknet
- Link: http://nu.llify.com
- Features: LEDs, IR Tag, Open Source
- Availability: Onsite, limited pre-reg
- Price: $60
Private Projects/Little Detail
21 May 2017
I just got a new Raspberry Pi Zero W (the wireless version) and didn’t feel like
hooking it up to a monitor and keyboard to get started. I really just wanted a
serial console for starters. Rather than solder in a header, I wanted to be
really lazy, so decided to use the USB OTG support of the Pi Zero to provide a
console over USB. It’s pretty straightforward, actually.
Install Raspbian on MicroSD
First off is a straightforward “install” of Raspbian on your MicroSD card. In
my case, I used
dd to image the img file from Raspbian to a MicroSD card in a
dd if=/home/david/Downloads/2017-04-10-raspbian-jessie-lite.img of=/dev/sde bs=1M conv=fdatasync
Mount the /boot partition
You’ll want to mount the boot partition to make a couple of changes. Before
doing so, run
partprobe to re-read the partition tables (or unplug and replug
the SD card). Then mount the partition somewhere convenient.
mount /dev/sde1 /mnt/boot
To use the USB port as an OTG port, you’ll need to enable the
dwc2 device tree
overlay. This is accomplished by adding a line to
Now we’ll need to tell the kernel to load the right module for the serial OTG
/boot/cmdline.txt, and after
(insert modules-load=dwc2,g_serial after rootwait)
When you save the file, make sure it is all one line, if you have any line
wrapping options they may have inserted newlines into the file.
Mount the root (/) partition
Let’s switch the partition we’re dealing with.
mount /dev/sde2 /mnt/root
Enable a Console on /dev/ttyGS0
/dev/ttyGS0 is the serial port on the USB gadget interface. While we’ll get a
serial port, we won’t have a console on it unless we tell systemd to start a
getty (the process that handles login and starts shells) on the USB serial
port. This is as simple as creating a symlink:
ln -s /lib/systemd/system/getty@.service /mnt/root/etc/systemd/system/getty.target.wants/getty@ttyGS0.service
This asks systemd to start a
ttyGS0 on boot.
Unmount and boot your Pi Zero
Unmount your SD card, insert the micro SD card into a Pi Zero, and boot with a
Micro USB cable between your computer and the OTG port.
Connect via a terminal emulator
You can connect via the terminal emulator of your choice at 115200bps. The Pi
Zero shows up as a “Netchip Technology, Inc. Linux-USB Serial Gadget (CDC ACM
mode)”, which means that (on Linux) your device will typically be
screen /dev/ttyACM0 115200
This is a quick way to get a console on a Raspberry Pi Zero, but it has
- Provides only console, no networking.
- File transfers are “difficult”.
13 May 2017
This week, I had the opportunity to take Joe Fitzpatrick’s class
“Applied Physical Attacks and Hardware Pentesting”.
This was a preview of the
course he’s offering at Black Hat this summer, and so it was in a bit of an
unpolished state, but I actually enjoyed the fact that it was that way. I’ve
taken a class with Joe before, back when he and Stephen Ridley of Xipiter taught
“Software Exploitation via Hardware Exploitation”, and I’ve watched a number of
his talks at various conferences, so I had high expectations of the course, and
he didn’t disappoint.
Some basic knowledge of hardware & hardware pentesting is assumed. While you
don’t need to be an electrical engineer (I’m not!) being familiar with how
digital signals work (i.e., differential signals or signals referenced to a
ground) is useful, and you should have some experience with at least connecting
a UART to a device. If you don’t have any of this experience, I suggest taking
his course “Applied Physical Attacks on Embedded Systems”
before taking this class. (Which is the same recommendation Joe gives.)
During the course, a variety of topics are covered, including:
- Identifying unknown chips (manufacturers sometimes grind the markings off
chips or cover them in epoxy)
- Identifying unknown protocols (what is a device speaking?)
- “Speaking” custom protocols in hardware
- Finding JTAG connections when they’re obvious – or not
- Using JTAG on devices with unknown processors (i.e., no datasheet available)
- Building custom hardware implants to carry out attacks
- Assessing & articulating feasibility and costs of hardware risks
While more introductory courses typically point you at a COTS SOHO router or
similar device as a target, this course uses two targets: one of them custom and
one of them uses an unknown microcontroller. These are much more representative
of product assessments or red teams as you’ll often be faced with new or
undocumented targets, and so the lab exercises here translate well into these
Joe really knows his stuff, and that much is obvious when you watch videos of
him speaking or take any of his classes. He answered questions thoroughly and
engaged the class in thoughtful discussion. There were “pen and paper”
exercises where he encouraged the class to work in small groups and then we
discussed the results, and it was interesting to see differing backgrounds
approach the problem in different ways.
One of the mixed blessings of taking his “preview” course was that some of the
labs did not go perfectly as planned. I call this a mixed blessing becase,
although it made the labs take a little longer, I actually feel I learned more
by debugging and by Joe’s responses to the parts that weren’t working correctly.
It’s imporant to know that hardware hacking doesn’t always go smoothly, and this
lesson was evident in the labs. Joe helped us work around each of the issues,
and generally tried to explain what was causing the problems at each stage.
I learned a lot about looking at systems that have no documentation available
and finding their flaws and shortcomings. Given the ever-increasing
“Internet of Things” deployments, this kind of skillset will only become ever
more useful to security practitioners, and Joe is an excellent instructor for