DistrictCon Junkyard 101

At DistrictCon 0x01, I competed for the first time in their Junkyard competition - a novel End-of-Life Pwnathon. It was a blast, and I’m really happy I pushed myself to compete in it.

During the conference, I had a ton of people come up to me and express interest, but either felt short on time or were unsure how to get started. Let’s break down what it takes to make that possible.

Here’s how we’ll approach it: what Junkyard is, why it’s worth it, and how to actually get started. I’ll even go through the process for my submission.

What is Junkyard?

Junkyard is an End-of-Life (EOL) Pwnathon - think Pwn2Own, but for software and hardware that is no longer supported by the vendor and (theoretically) not in use in the real world.

At its core, Junkyard is about showing and telling. Presentations are lightning rounds (8-15 mins) of exploit demonstration and education, and are encouraged to be as silly and unhinged as possible, covering:

• The target and why it matters
• A demonstration of the bug, explaining how it works and the impact
• Unique, clever, and creative bits about the exploit development process

Some of my favorite personal shenanigans:

• A wormable Command & Conquer: Generals RCE that received overwhelming community support to patch it.
• noperator popping a network-connected surge protector to turn on a disco ball and play “[Watt] is Love”
• DOOM running in a Rollercoaster Tycoon save game exploit
• A dance contest between one of the judges and competitors on a Dance Dance Revolution-esque arcade machine
• A random audience member being selected to be walked through hacking the JACE-600E embedded controller/server platform for the competitor (because It’s So Easy, Anybody Could Do It!✨)
• An exploit being demonstrated live on the nearest treadmills
• (Definitely no bias) my quacking barcode scanner presentation clicker sending the audience rolling every slide

If you want to see all the entries, watch the Year 0x00 entries and read Casey Ellis’ overviews on Year 0x01.

Why should you compete (or watch)?

So now that you know what Junkyard is - why should you actually compete?

Short answer: it is one of the most approachable (and fun!) ways to get into this space.

It’s a lower barrier to entry

No need to stock up a number of browser and OS 0-days! Just find a bug in an EOL device and make a silly presentation out of it.

It’s fun

Engaging and silly presentations are REQUIRED in Junkyard.

It’s novel

It breaks away from the endless fields of IoT cameras, printers, and routers, and demands the weirdest, and most unexpectedly impactful software and devices.

It’s educational

Competitors are required to not only explain their research methodology and exploit(s), but boil it down to 8-15 minutes. No longer will you be left wondering about how an exploit works from a “pop calc” demo.

Selecting a Target

Alright, so now you want to compete in Junkyard, but how do you actually pick a target to work on? This is where most people get stuck, but it’s simpler than it looks. You don’t need the perfect target - just one that you can work with. Think of this less as a checklist, and more of a set of guidelines with tradeoffs.

Personal Goals

Start here: What do you want out of your Junkyard submission? Are you gunning for a win, or learning something new? Staying in your comfort zone vs. exploring new territory will change your target selection.

At a high level, remember that you’re balancing three main things: what you want to learn, what’s feasible, and what’s interesting.

Firmware Accessibility

If there’s firmware, how easy is it to get at the firmware on the device? Is it available on the vendor’s website, can you intercept it from updates, or will you have to get at it from the hardware angle? If you can examine firmware before buying the target, can you find likely bugs just from static analysis? Internet Archive is a great resource for searching for firmware on old devices!

Prior Work

Is there prior work on this target? If there’s work into vulnerability research and exploiting your target, it may be best to pick a different target. Or you can gamble on if you can find something new and cool enough to do the trick. If prior work is limited or focused on reversing or development, it may still be okay to select this target.

Target Novelty

Is this something frequently seen at Pwn2Own? (e.g. routers, printers, cameras, modern browsers) Junkyard aims for novel EOL submissions, so you may find it hard to be accepted if you go with these.

And of course, don’t forget how reasonable it is to get the target!

Budget

Is the device or software something you can get for free or relatively cheap? Do research ahead of time to make sure you’ll be able to afford your target!

Buyability

Can you realistically buy the device (or similar ones) on eBay, thrift stores, auctions, or liquidation sales? If you can’t buy it, you won’t have anything to work on!

Example: Quacking Between the Lines

Here’s how this process actually played out for me in practice.

I had the following goals for DistrictCon:

• Learn something new: I wanted to focus on physical devices. I ended up looking more into Windows CE platforms, as I’d never messed with them before.
• Firmware is ideally available online: I didn’t want to deal with extracting firmware from hardware for this submission. This also meant I could triage firmware for bugs/research paths before committing to a device. Before committing to a device, I made sure I was able to extract files from the firmware.
• Pick something novel: I tried to pick types of devices that wouldn’t be at Pwn2Own, and had little to no research.
• Devices were network-connected: I wanted devices with an obvious remote attack surface.

I initially considered the ViewSonic v210 wireless tablet/display, as I was able to find old firmware via Internet Archive, and they seemed to be frequently available on eBay. There was some prior work in hacking the v110 and v150s to expand functionality, but otherwise not much. Unfortunately, the devices sold out on eBay just as I stopped faffing and went to buy them.

Other interesting options would’ve been medical devices, notebooks, phones, and more.

I ended up with Zebra Motorola MC2180 barcode scanners, as there were tons on eBay for a reasonable price with all the accessories. I managed to find recent firmware on Zebra’s website, and was able to unpack it, so I went ahead and bought them.

Once I had the devices in hand, the first thing I wanted to do was map out the attack surface. This is usually my starting point: figure out the remote attack surface, and then work backward from there. MC2180s come with a stripped-down cmd.exe, which conveniently has netcat!

Seeing what’s exposed immediately gives you a set of services to investigate.

\> netstat -n

TABLE

Loc Addr   Loc Port   Rem Addr   Rem Port   State
0.0.0.0    80         0.0.0.0    12460      LISTEN
0.0.0.0    443        0.0.0.0    12503      LISTEN
0.0.0.0    4122       0.0.0.0    28830      LISTEN
0.0.0.0    48873      0.0.0.0    61540      LISTEN

Once I knew what was listening, the next step was to figure out what each service was. This netcat doesn’t have a way to associate listening ports to PIDs or process names, so I ended up searching through firmware files to connect the dots.

My first clues ended up in dwhttpd HTTP, JS, and XML files, leading to me digging at the service files and binaries.

Port 48873: dwhttpd.exe (DataWedge HTTP server)
Example URLs:
 * http://localhost:48873/dwui/index.html?mode=basic
	 * Scanner input/KeyStroke output, Basic format, About, Exit
 * http://localhost:48873/dwui/index.html?mode=advanced
	 * Profiles/Settings/About/Exit

Once I had an idea of what data the service expected, I could use tools like Insomnia to send my own variations. Within 24 hours of receiving the devices, I had proved out a remote file write bug! At this point, I knew I had a viable target - and something worth crafting a submission around.

All bugs were properly disclosed to the vendor, Zebra Technologies via their HackerOne VDP. Unfortunately, Zebra decided the reported bugs were out-of-scope for their VDP. 🤷‍♀️

This is where the real work started. From here, it was about seeking out the limitations of the bugs, and then crafting a chain. With every step, I posed the research as questions to answer to help guide my work.

Reverse engineering of the service binary let me find additional bugs as workarounds to the limitations of the file read/write bugs I had.

Like most projects, the biggest time sinks weren’t where I initially expected them. The biggest time sinks by far were crafting an exploit chain that worked around the bugs’ limitations, and putting together a development environment.

A few things became clear going through the process of putting together and executing a presentation:

• Practice the presentation many times to make sure it flows well, makes sense, and is within the time limit. You do not realize how short 15 mins is until you fail the first dry run.
• Set up a separate network to avoid network connectivity woes. My partner suggested this setup with a small travel router early on, and it was instrumental in having a ready-to-go setup that worked with all my devices. (Thank you 🥰)
• Funny and unhinged entertains the crowd and gives you the momentum to feel comfortable presenting.

A Note For the Students

If you’re a student out there reading this - yes, it’s absolutely worth it - and you should compete in Junkyard! It’s a great no-stakes opportunity to learn new technologies, plus up your vulnerability research skills, and - if successful - present at a conference.

Work your Junkyard research into your curriculum to prevent workload overload! Does your university support “independent studies” that let you do projects as a class for credits/units? If so, find a faculty member to sponsor you and propose your Junkyard work! If not, think about how you could spin your Junkyard work into a full-on research thesis. Could your Junkyard project be part of a larger research effort into developing novel tooling or examining technology in a way that hasn’t before?

Find a mentor! Is VR hard? Yes. Is competing and presenting scary? Yes. But there’s tons of people in the security community that are willing to mentor! Your school’s faculty members and computer/security clubs are likely great starting points. DistrictCon 0x01 also advertised a mentoring program, so keep an eye out for future opportunities!

Conclusion

Start with something you’re curious about, map out the attack surface, and see where it takes you.

If you’ve been on the fence about competing, this should be your sign - go find the weirdest, silliest thing and break it!