Hacker Camp: Confirming My IoT Obsession at BruCon

The last few days I attended BruCon 0x12. Not just the conference like last year, but also three whole training days together with Roman Steuhler. Even though my passion is hacking websites, IoT is really getting a special place in my heart. And this training really did confirm that I want to keep improving myself in this field. There are so many possible targets and so many very nice tools. That is pretty much what is cool about it. Voiding that warranty sticker, looking, probing, soldering for a way in, and once you're in, you can start hunting for code flaws that will give you, in the best case, an RCE.

In this blog post, I'm gonna take you along on some bits of the training, some cool stuff I got my hands on and how the conference itself gave me cool new insights.

Day 1

Firstly a small disclaimer: Roman did covered a lot more in those three days, and he put a lot of effort in it to make a very complete and comprehensive course. If you ever have the chance, I can definitely recommend it. He also has some very cool videos on his YouTube channel.

Roman described this day as the boring day. I kinda see where he's coming from, but I would disagree. Some of the students had never had a serial terminal open, so going over the very basics like how to operate a multimeter, Ohm's Law, different protocols, staying away from alternating current and so on is important.

Other interesting topics included:

1. Hardware pulls the current it needs, but does not like more voltage than it's rated for. So if you power up a PCB, you need to provide the exact voltage needed, but the amps can be higher than needed. The device will only draw what it needs anyway.
2. Pull-up and pull-down resistors are important to counter floating lines. If you need a signal to be ON or 1, you can use a pull-up resistor (like 10k) on the positive side. If you need it to be always DOWN or 0, you can use a pull-down resistor on the negative/ground side.
3. How multilayer boards can make our work a bit more complex.
4. Practicing on reading datasheets.
5. Count pins counterclockwise!
6. MISO can be referenced as (S)DO.
7. MOSI can be referenced as (S)DI.

After that, you also need to verify if the enormous amount of hardware we got also worked. Targets and tools need to be configured and tested before we can come to the 'spicy stuff', as Roman so elegantly put it.

I also got the opportunity to work with tools I only saw in YouTube videos of people who actually know what they are doing. Playing around with the PCBite probes made me feel like I was an elite hacker. We only hooked them up to a logic analyzer and calculated the baudrate, but that was very, very cool.

So how do you know the baudrate based on the signals from a logic analyzer?

The first thing you need is the smallest time gap you can find on your graph. Then you need to consider this equation.

B = 1/T

B = 1/T

In this equation, the baudrate equals 1 divided by the time.

In the picture above, we can see that the smallest timing is 6.65 microseconds. When we divide 1 by that number, we'll get our approximate baudrate. In all fairness, it is usually 115200, but hey, the cool thing is that you can now do it.

At the end of the day we also had a short, nowadays obligatory, discussion on how LLMs are changing the world, and how you always have to be careful with law (enforcement). Even though pretty much everyone I encountered in the hacker scene wants to make the world (and the internet in particular) a better place, the judge might see this differently.

Day 2

The second day, we got to the 'spicier' stuff. We dumped the firmware in-circuit from our cameras. Admittedly, not everything worked without a bump, but you really cannot expect a hardware hacking class with 10+ students to go without any hiccups.

Importantly, everybody got their firmware dumped. We did this with a Pico flashed with serprog, but yours truly had an issue with his clip. So my Pico did not do what I wanted. Luckily, the whole class was very proactive in helping out, so I got my dumps eventually with the Pico. I also got some backup dumps done with my CH341A, just to be sure.

An important part of dumping firmware is to not expect that you just dump it without errors. You should always dump it at least twice and either check the checksum with md5sum *, or use the command diff dump1.bin dump2.bin. If they differ, dump it again until you have two dumps that don't differ. Keep one of those, and you're good to go with the next steps.

Now for the cool stuff. We used our PCBites to get into a UART shell, and the root password was on 'the Google', but that's not really fun, right? So what we did was, after dumping the firmware, we unpacked it and modified the /etc/shadow file like this.

So after we did that, we packed it all up again, made sure the file had the same size as before, and flashed it on the camera again. And guess what? No more password 😊

Another cool trick I learned was the -E flag on binwalk. If you do this on a binary, you will get a chart representing the entropy of the file. With that you can conclude whether a file is encrypted, compressed and so on.

And last but certainly not least

Connect everything you want to connect on your devices BEFORE you plug it into a power source.

Day 3

The last day was a bit of a what do you guys want kinda day. Personally I was very interested in power glitching and Roman did spend quite some time theoretically explaining how that works, what you're looking for in the datasheets and how it all comes together. With the material I got, I'll definitely be following along with this video.

After that he gave us a crash course on reverse engineering on the firmware we dumped from the camera. Not gonna lie here, this was a bit much for me. I kinda got what he was saying because of my programming background, but binary is a different beast.

Most important part is that you're looking for some keywords. system, popen and execv are the things where you should pause and really try to understand what is happening.

Another term I encountered was ASLR, meaning address space layout randomization. In essence, this makes sure that your firmware scrambles the addresses so buffer overflow hacks get a lot harder. Luckily most vendors know about ASLR but don't realize they also need to compile PIE (Position Independent Executable) to make that work.

To be fair, a lot of this manual labor can be handled quite easily by an LLM now, so maybe put in a little effort learning it, but not too much.

After the explanation he showed us how you could exploit that in real life on the target itself. The most important thing here was to set up a local environment for your IoT devices. Don't let them go out on the internet was the reasoning. I still want to learn a bit more on this, because it seems logical, but somewhat not if you want to, for example, pentest the mobile app. I figure you do need to have some kind of real internet access, but I will be looking into that. Let me know if you have some suggestions!

Conference — Day 1

Pretty beaten up by now already, and the conference hadn't even started yet. But I was excited to arrive for my fourth day at Mechelen. After the registration I was very very happy to see this year's badge. A full blown electronic badge. Pretty quickly discovered that you had to tap it to get different cycles of colors, but it also became very clear that it was more than just that. I was able to check the firmware chip, saw that there was a Raspberry Pi chip on there. Long story short, I had just learned all the techniques and received all the tools to totally pwn this thing.

I went to two talks. The keynote was a very interesting one from a management perspective. And the main consideration I got from this talk was that we as security people will need to adapt more quickly than ever before and, if you're on the blue team, you will have to get comfortable with let the village burn in order to protect the city, which boils down to that we will have situations in the future where we will have to decide to take a part of the infrastructure down, without having had the opportunity to understand the attack and whether it would have been necessary in retrospect.

The second talk was about a team that did research into a well-known home assistant application for the 'pwn2own' competition. They found a way to go through an official plugin and ultimately became root outside the docker container. Very cool attack path with a lot of research and a lot of reading documentation.

What struck me was that these guys didn't read documentation like I usually do. If I read Python documentation, I read about what certain functions can do. Those guys read it to see how the behaviour of those features can help them get RCE.

For example, an import statement will execute Python code. Well, duh, that's the whole point. But it also does that if a new process is started, even one you wouldn't think to call "importing" anything. By triggering a new process, those guys were able to execute code. Very cool approach, and I would never have gotten that from reading the documentation the way I normally do.

Between all that I played some Mario Kart, met some awesome people, hacked into my badge, and taught people some lockpicking. All in all, a very cool first day.

Conference — Day 2

The keynote of the second day was by Maddie Stone. This was without a doubt the coolest, most inspiring talk. Not a technical exploit, not a crazy zero day, but a talk about how our lives are on the verge of changing into a shape we don't fully understand yet, and how we should embrace that instead of resisting it. Trying new things, at work and in hobbies (but sorry, no knitting for me though), doesn't mean you have to be good at it right away, it's actually better if you suck at first. The security landscape in the age of AI will need people who try new stuff and aren't afraid to make mistakes.

The most important slide from her talk was definitely this one:

The second talk I attended was a talk about how 'easy' it is to hack into payment terminals used in South Africa. The talk was very clear and explained the vulnerability and attack path very well. But I need to be honest that some of that stuff went over my head. Mobile exploitation isn't my strong suit and that is cool. Even though it wasn't my field of expertise, Conner explained it in a way that even I could understand it, so kudos are definitely justified.

Other than that, I hung around with my instructor from the course, played some more retro games and even had a discussion about philosophy.

Of course I hacked further on my badge (yes of course I did all the challenges and I really did not cheat 🤐).

Conclusion

This was a very intense week. The last night I fell asleep while I was trying to get my kiddo to fall asleep. Can't guarantee that my kid slept before I did, but don't tell my wife that!

I once heard a quote that says you need to try not to be the smartest person in the room in order to grow, and I can definitely say that I wasn't the smartest in any room at BruCon. So many cool smart people who are passionate about what they can teach someone else without being cocky about it. BruCon has a very cool vibe and I will definitely be present next year.

My next little project is going to be power glitching, which will definitely also be a blog post that is coming up.

I break web apps and IoT for fun, make vulnerable labs to learn, and write about it so you can too.