In any normal situation, if you’d read an article that about building your own quantum computer, a fully understandable and natural reaction would be to call it clickbaity poppycock. But an event like the Chaos Communication Congress is anything but a normal situation, and you never know who will show up and what background they will come from. A case in point: security veteran [Yann Allain] who is in fact building his own quantum computer in his garage.
Starting with an introduction to quantum computing itself, and what makes it so powerful also in the context of security, [Yann] continues to tell about his journey of building a quantum computer on his own. His goal was to build a stable computer he could “easily” create by himself in his garage, which will work at room temperature, using trapped ion technology. After a few iterations, he eventually created a prototype with KiCad that he cut into an empty ceramic chip carrier with a hobbyist CNC router, which will survive when placed in a vacuum chamber. While he is still working on a DIY laser system, he feels confident to be on the right track, and his estimate is that his prototype will achieve 10-15 qubits with a single ion trap, aiming to chain several ion traps later on.
As quantum computing is often depicted as cryptography’s doomsday device, it’s of course of concern that someone might just build one in their garage, but in order to improve future cryptographic systems, it also requires to fully understand — also on a practical level — quantum computing itself. Whether you want to replicate one yourself, at a rough cost of “below 15k Euro so far” is of course a different story, but who knows, maybe [Yann] might become the Josef Prusa of quantum computers one day.
Most of these stories start with a cat standing on someone’s chest, begging for food at some obscene hour of the morning. But not this one. Chaz the cat is diabetic, and he needs to get his insulin with breakfast. The problem is that Chaz likes to eat overnight, which ruins his breakfast appetite and his chances at properly metabolizing the insulin. [Becky] tried putting the bowl away before bed, but let’s face it — it’s more fun to solve a problem once than to solve the same problem every night.
[Becky]’s solution was to design and print a bowl holder with a lid, and to cover the bowl when the cat diner is closed using a small servo and a NodeMCU. It looks good, and it gets the job done with few components. Chaz gets his insulin, [Becky] gets peace of mind, and everybody’s happy. This isn’t going to work for all cats, because security is pretty lax. But Chaz is a senior kitty and therefore disinterested in pawing at the lid to see what happens. Claw your way past the break to see [Becky]’s build/demo video featuring plenty of cat tax coverage.
SIM cards are all around us, and with the continuing growth of the Internet of Things, spawning technologies like NB-IoT, this might as well be very literal soon. But what do we really know about them, their internal structure, and their communication protocols? And by extension, their security? To shine some light on these questions, open source and mobile device titan [LaForge] gave an introductory talk about SIM card technologies at the 36C3 in Leipzig, Germany.
Starting with a brief history lesson on the early days of cellular networks based on the German C-Netz, and the origin of the SIM card itself, [LaForge] goes through the main specification and technology parts of each following generation from 2G to 5G. Covering the physical basics, I/O interfaces, communication protocols, and the file system located on the SIM card, you’ll get the answer to “what on Earth is PIN2 for?” along the way.
Of course, a talk like this, on a CCC event, wouldn’t be complete without a deep and critical look at the security side as well. Considering how over-the-air updates on both software and — thanks to mostly running Java nowadays — feature side are more and more common, there certainly is something to look at.
The heart of the rig is a motion platform consisting of a tiny stepper motor fitted with a linear slide screw. This is connected to an Arduino or PIC with a basic stepper driver board. While the motor does not respond well to microstepping or other advanced techniques, simply driving it properly can give a resolution of 15 μm per step.
The motor/slide combination is not particularly powerful, and thus cannot readily be used to move the camera or optics. Instead, the rig is designed for photography of very small objects, in which the rail will move the subject itself.
It’s a tidy build that would serve well for anyone regularly doing macro focus stack photography. If you’ve been trying to better photograph your insect collection, this one is for you. It’s a valuable technique and one that applies to microscopy too. Video after the break.
The first thing Jeremy Cook thought when he saw a video of Theo Jansen’s Strandbeest walking across the beach was how incredible the machine looked. His second thought was that there was no way he’d ever be able to build something like that himself. It’s a feeling that most of us have had at one time or another, especially when starting down a path we’ve never been on before.
But those doubts didn’t keep him from researching how the Strandbeest worked, or stop him from taking the first tentative steps towards building his own version. It certainly didn’t happen overnight. It didn’t happen over a month or even a year, either.
His first builds could barely move, and when they did, it wasn’t for long. But the latest version, which he demonstrated live in front of a packed audience at the LA College of Music, trotted across the stage with an almost otherworldly smoothness. To say that he’s gotten good at building these machines would be something of an understatement.
Jeremy’s talk is primarily focused on his Strandbeest creations, but it’s also a fascinating look at how a person can gradually move from inspiration to mastery through incremental improvements. He could have stopped after the first, second, or even third failure. But instead he persisted to the point he’s an expert at something he once believed was out of his reach.
Shell scripting is handy and with a shell like bash it is very capable, too. However, shell scripting isn’t always very efficient. Think about it. If you run grep or tr or sort to do some operation in a shell script, you are spawning a whole new process. That takes time and resources. But there are some answers to reducing — but not eliminating — the problem.
Have you ever written a program like this (in any language, but I’ll use C):
You hope the compiler doesn’t write assembly code like this:
Most optimizers should pick up on the fact that you can convert a call like this to a jump and let the ret statement in _bar return to foo’s caller. However, shell scripts are not that smart. If you have a shell script called MungeData and it calls another program or shell script called PostProcess on its last line, then you will have at one time three processes in play: your original shell, the shell running MungeData, and either the PostProcess program or a shell running the script. Not to mention, the processes to do things inside post process. So what do you do?
Your cellphone is the least secure computer that you own, and worse than that, it’s got a radio. [Jiska Classen] and her lab have been hacking on cellphones’ wireless systems for a while now, and in this talk gives an overview of the wireless vulnerabilities and attack surfaces that they bring along. While the talk provides some basic background on wireless (in)security, it also presents two new areas of research that she and her colleagues have been working on the last year.
One of the new hacks is based on the fact that a phone that wants to support both Bluetooth and WiFi needs to figure out a way to share the radio, because both protocols use the same 2.4 GHz band. And so it turns out that the Bluetooth hardware has to talk to the WiFi hardware, and it wouldn’t entirely surprise you that when [Jiska] gets into the Bluetooth stack, she’s able to DOS the WiFi. What this does to the operating system depends on the phone, but many of them just fall over and reboot.
Lately [Jiska] has been doing a lot of fuzzing on the cell phone stack enabled by some work by one of her students [Jan Ruge] work on emulation, codenamed “Frankenstein”. The coolest thing here is that the emulation runs in real time, and can be threaded into the operating system, enabling full-stack fuzzing. More complexity means more bugs, so we expect to see a lot more coming out of this line of research in the next year.
[Jiska] gives the presentation in a tinfoil hat, but that’s just a metaphor. In the end, when asked about how to properly secure your phone, she gives out the best advice ever: toss it in the blender.