At this year’s Chaos Communication Congress, we caught up with [muzy] and [overflo], who were there with a badge and soldering project they designed to teach young folks how to solder and program. Blinkenrocket is a basically a 64-LED matrix display and just enough support hardware to store and display animations, and judging by the number of blinking rockets we saw around the necks of attendees, it was a success.
Their talk at 34C3 mostly concerns the production details, design refinements, and the pitfalls of producing thousands of a thing. If you’re thinking of building a hardware kit or badge on this scale, you should really check it out and crib some of their production optimization tricks.
For instance, instead of labelling the parts “C2” or “R: 220 Ohms”, they used a simple color-coding scheme. This not only makes it easier for kids to assemble, but it also means that they didn’t have to stick 1,000 part labels on every component. Coupled with [overflo]’s Zerhacker, SMD parts in strips were cut to the right length and color-coded in one step, done by machine.
The coolest feature of the Blinkenrocket itself is the audio programming interface. It’s like in the bad old days of software stored on cassette tapes, but it’s a phenomenal interface for getting a simple animation out of a web app and straight into a piece of minimal hardware — just plug it into a laptop or cell phone’s audio out and press “play” in the browser. The original design tried to encode the data in the pulse-length of square waves, but this turned out to be very hardware dependent. The final design used frequency-shift keying. What’s old is new again.
Everything you could want to know about the design, its code, and even the website itself are up on the project’s GitHub page, so go check it out. If you’d like to arrange a Blinkenrocket workshop yourself, shoot [muzy] or [overflo] an e-mail. Full disclosure: [overflo] gave us a kit, the “hard-mode” SMD one with
0805 1206 parts, and it was fun to assemble and program.
We once knew a guy who used to tell us that the first ten times he flew in an airplane, he jumped out of it. It was his eleventh flight before he walked off the plane. [Mathias Lasser] has a similar story. Despite being one of the pair who decoded the iCE40 bitstream format a few years ago, he admits in his 34C3 talk that he never learned how to use FPGAs. His talk covers how he reverse engineered the iCE40 and the Xilinx 7 series devices.
If you are used to FPGAs in terms of Verilog and VHDL, [Mathias] will show you a whole new view of rows, columns, and tiles. Even if you don’t ever plan to work at that level, sometimes understanding hardware at the low level will inspire some insights that are harder to get at the abstraction level.
Continue reading “34C3: Reverse Engineering FPGAs”
If you’ve been to a Chaos Communication Congress, you know the feeling — the strange realization after it’s all over that you’re back in the “real world”. It’s somehow alienating and unfriendly in comparison to being surrounded by computer freaks, artists, hackers, activists, coders, and other like-minded individuals over the four days of the Congress. A hand-written poster by the podcasting center read “Endlich, normale Leute” — “At last, normal people” — which is irony piled on irony but the sentiment is still right for certain strange values of “normal”. Normal hackers? You’d probably fit right in.
We cover a lot of the talks from the Congress, because they’re first-class and because you can play along at home, but the real soul of the Congress is people getting together, making something temporary and crazy, talking over their common plans, learning new things directly from one-another, and simply having fun. Here’s our chance to give you a little of the other side of the Congress.
Continue reading “Great People and Culture at 34th Chaos Communication Congress”
Writing your own drivers is a special discipline. Drivers on the one hand work closely with external hardware and at the same time are deeply ingrained into the operating system. That’s two kinds of specialization in one problem. In recent years a lot of dedicated networking hardware is being replaced by software. [Paul Emmerich] is a researcher who works on improving the performance of these systems.
Making software act like network hardware requires drivers that can swiftly handle a lot of small packets, something that the standard APIs where not designed for. In his talk at this year’s Chaos Commnication Congress [Paul] dissects the different approaches to writing this special flavor of drivers and explains the shortcomings of each.
Continue reading “34C3: Roll Your Own Network Driver In Four Simple Steps”
Inspiration can come from many places. When [Veronica Valeros] and [Sebastian Garcia] from the MatesLab Hackerspace in Argentina learned that it took [Ai Weiwei] four years to discover his home had been bugged, they decided to have a closer look into some standard audio surveillance devices. Feeling there’s a shortage of research on the subject inside the community, they took matters in their own hands, and presented the outcome in their Spy vs. Spy: A modern study of microphone bugs operation and detection talk at 34C3. You can find the slides here, and their white paper here.
Focusing their research primarily on FM radio transmitter devices, [Veronica] and [Sebastian] start off with some historical examples, and the development of such devices — nowadays available off-the-shelf for little money. While these devices may be shrugged off as a relic of Soviet era spy fiction and tools of analog times, the easy availability and usage still keeps them relevant today. They conclude their research with a game of Hide and Seek as real life experiment, using regular store-bought transmitters.
An undertaking like this would not be complete without the RTL-SDR dongle, so [Sebastian] developed the Salamandra Spy Microphone Detection Tool as alternative for ready-made detection devices. Using the dongle’s power levels, Salamandra detects and locates the presence of potential transmitters, keeping track of all findings. If you’re interested in some of the earliest and most technologically fascinating covert listening devices, there is no better example than Theremin’s bug.
Continue reading “34C3: Microphone Bugs”
[Will Scott] and [Gabe Edwards] shed some light on the current state of consumer computing technology at 34C3 in their talk DPRK Consumer Technology. The pair has also created a website to act as a clearinghouse for this information — including smartphone OS images up at koreaComputerCenter.org.
Not a whole lot is known about what technology North Korean citizens have available to them. We have seen Red Star OS, the Mac-like Linux based operating system used on PC based desktops. But what about other systems like smartphones?
[Will] and [Gabe] found that cell phones in North Korea are typically manufactured by Chinese companies, running a custom version of the Android Operating system. The phone hardware is common — the phone sold as the Pyongyang 2407 in North Korea is also sold in India as the Genie v5. If you can get your hands on the Genie, you can run the Korean version of the Android OS on that hardware.
Continue reading “34C3: North Korea’s Consumer Technology”
Despite the presence of human drivers, modern cars are controlled by computers. In his talk at the Chaos Communication Congress [Guillaume Heilles] and [P1kachu] demonstrate the potential of taking control of a car’s computer. This of course leads to the natural conclusion of emulate an Xbox controller and using the car to play computer games.
His research was limited by the fact that the only cars they had access to were the daily drivers of different members of [P1kachu]’s family, which meant that all tinkering had to be strictly non-destructive. Despite this, they achieved impressive results and deliver a great introduction into reverse engineering.
[P1kachu] used a RasPi and an OBD-II adapter to access the car’s CAN bus and begins the presentation with a quick overview of the protocol. He then briefly touches on security measures that he ran into, which are optional and their implementation varies widely between manufacturers. His first attempt to access the CAN bus was successfully blocked by a challenge-response algorithm doing its work. His mother’s convertible however provided no such obstacles and gaining access allowed him to map the position of the steering wheel and pedals to a game controller, using the car to play video games.
After this, [Guillaume] steps in and walks us through the teardown of a gadget that plugs into the OBD-II port and claims to do amazing things for your car’s mileage by reprogramming the ECU. The device was not brand specific and after having seen the variations in the ways different manufacturers implement the protocol, [Guillaume] and [P1kachu] doubted that the gadget was capable of even holding the information required to modify every known implementation out there. Listening to the output of the device, along with a quick analysis of the circuit followed by decapping the single chip they found, showed that their doubt was justified. The lecture closes with an extended Q&A that adds more information on car hacking. Those that don’t have access to a car can instead tear down hot glue guns, doppler modules or antique calculators.
Continue reading “34C3: Using Your Car As Video Game Controller”