When you want to protect a computer connected to the Internet against attackers, you usually put it behind a firewall. The firewall controls access to the protected computer. However, you can defeat any lock and there are ways a dedicated attacker can compromise a firewall. Really critical data is often placed on a computer that is “air gapped.” That is, the computer isn’t connected at all to an insecure network.
An air gap turns a network security problem into a physical security problem. Even if you can infect the target system and collect data, you don’t have an easy way to get the data out of the secure facility unless you are physically present and doing something obvious (like reading from the screen into a phone). Right? Maybe not.
Researchers in Isreal have been devising various ways to transmit data from air walled computers. Their latest approach? Transmit data via changing the speed of cooling fans in the target computer. Software running on a cellphone (or other computer, obviously) can decode the data and exfiltrate it. You can see a video on the process below.
A few years ago, [Artem] learned about ways to focus sound in an issue of Popular Mechanics. If sound can be focused, he reasoned, it could be focused onto a plane of microphones. Get enough microphones, and you have a ‘sound camera’, with each microphone a single pixel.
Movies and TV shows about comic books are now the height of culture, so a device using an array of microphones to produce an image isn’t an interesting demonstration of FFT, signal processing, and high-speed electronic design. It’s a Daredevil camera, and it’s one of the greatest builds we’ve ever seen.
[Artem]’s build log isn’t a step-by-step process on how to make a sound camera. Instead, he went through the entire process of building this array of microphones, and like all amazing builds the first step never works. The first prototype was based on a flatbed scanner camera, simply a flatbed scanner in a lightproof box with a pinhole. The idea was, by scanning a microphone back and forth, using the pinhole as a ‘lens’, [Artem] could detect where a sound was coming from. He pulled out his scanner, a signal generator, and ran the experiment. It didn’t work. The box was not soundproof, the inner chamber should have been anechoic, and even if it worked, this camera would only be able to produce an image or two a minute.
The idea sat in the shelf of [Artem]’s mind for a while, and along the way he learned about FFT and how the gigantic Duga over the horizon radar actually worked. Math was the answer, and by using FFT to transform a microphones signals from up-and-down to buckets of frequency and intensity, he could build this camera.
That was the theory, anyway. Practicality has a way of getting in the way, and to build this gigantic sound camera he would need dozens of microphones, dozens of amplifiers, and a controller with enough analog pins, DACs, and processing power to make sense of all of this.
This complexity collapsed when [Artem] realized there was an off-the-shelf part that was a perfect microphone camera pixel. MEMS microphones, like the kind found in smartphones, take analog sound and turn it into a digital signal. Feed this into a fast enough microcontroller, and you can perform FFT on the signal and repeat the same process on the next pixel. This was the answer, and the only thing left to do was to build a board with an array of microphones.
[Artem]’s camera microphone is constructed out of several modules, each of them consisting of an 8×8 array of MEMS microphones, controlled via FPGA. These individual modules can be chained together, and the ‘big build’ is a 32×32 array. After a few problems with manufacturing, the board actually worked. He was recording 64 channels of audio from a single panel. Turning on the FFT visualization and pointing it at a speaker revealed that yes, he had indeed made a sound camera.
The result is a terribly crude movie with blobs of color, but that’s the reality of a camera that only has 32×32 resolution. Right now the sound camera works, the images are crude, and [Artem] has a few ideas of where to go next. A cheap PC is fast enough to record and process all the data, but now it’s an issue of bandwidth; 30 sounds per second is a total of 64 Mbps of data. That’s doable, but it would need another FPGA implementation.
Is this sonic vision? Yes, technically the board works. No, in that the project is stalled, and it’s expensive by any electronic hobbyist standards. Still, it’s one of the best to grace our front page.
Magnetic resonance imaging devices are one of the most fantastically incredible machines humans have ever built. They’re capable of producing three-dimensional images of living tissue by flipping protons around with a magnetic field. Ninety percent of the population doesn’t know what that sentence means, yet you can find an MRI machine inside nearly any reasonably equipped hospital in America.
For his Hackaday Prize entry, [Peter Jansen] is building a magnetic resonance imager, capable of producing the same type of images you’d get from the radiology department at a hospital. It’s going to be a desktop unit, capable of scanning fruit and other similarly sized objects, and can be built using tools no more advanced than a hot air gun and a laser cutter.
Last year, [Peter] developed the plywood mechanism that would rotate a magnetic sensor across the diameter of the scanning volume, rotate the object to be scanned, and lift the object through the volume. It’s a weird 3-axis CNC machine, basically, but the parts near the magnetic sensor can’t be made out of metal. Dental floss worked okay, but we have a few hundred feet of Spectra fishing line if we ever bump into [Peter]. Magnetic resonance imaging means big coils of wire, too, which means the tedious task of winding coils around a cylinder is part of the build. [Peter] built a machine to do the work for him.
Already, [Peter] has some amazing work under his belt that produces real data that could not be otherwise obtained. An Open Source MRI is the perfect project for the Hackaday Prize’s Citizen Science phase, and we’re very happy to see him enter this project.
If you’ve taken any digital signal processing classes at a college or university, you’ve probably been exposed to MATLAB. However, if you want to do your own work, you might think about Linux and one of the many scientific computing applications available for it.
[David Duarte] recently published a three-part tutorial on using Octave to do scientific audio processing. The first part covers basic reading, writing, and playing of audio files. Part two covers synthesis of signals, plotting, and some basic transformations. Modulation is the topic of the third part. If you prefer your tutorials on video, you can check out the video below.
We’ve talked about MATLAB before in the context of message cracking. Then again, some of the best signal processing is done by humans. If you don’t like Octave, you might try Scilab, another Linux package that is similar. There’s also Freemat, Sage, and Spyder. Of course, you can also run MATLAB under Linux.
“If you’re asking ‘why,’ you don’t get it.” So said [JP] when he told us about his strandbeest bicycle build. After all, who in their right mind would graft a complex multi-leg mechanical walking mechanism to the rear end of a perfectly good bicycle? But to expand on his sentiment, to not understand his creation is to miss the whole essence of our movement. Sometimes you just have to make something, because you can.
If you aren’t familiar with the strandbeest, it is the creation of Dutch artist [Theo Jansen]. Complex skeletal walking machines powered by the wind, that in the case of [Jansen]’s machines autonomously roam the beaches of the Netherlands. Hence the name, from Dutch: “Beach beast”.
[JP]’s strandbeest bike came together over 8 months of hard work. It started with a conceptual CAD design and 3D print, and progressed through many iterations of fine-tuning the over 400 parts required to put four legs on the back of a bicycle frame. It’s an impressive achievement and it is fully rideable, though we suspect we won’t be seeing it at the Tour de France any time soon.
He’s posted several videos of the bike in action, you can see one of them below the break.
[jamesone111] bought a Transcend WifiSD card, presumably for photography, but it may just have been because he heard that they’re actually tiny Linux servers.
He read a post about these cards on the OpenWRT forums. They’re all a similar configuration of a relatively large amount of memory (compared to the usual embedded computer), a WiFi chip, and an ARM processor running a tiny Linux install. The card acts as a WiFi access point with a little server running on it, and waits for the user to connect to it via a website. It also has a mode where it will connect to up to three access points specified by the user, but it doesn’t actually have a way to tell the user what its IP address is; which is kind of funny.
[jamesone111] hacked around with the Transcend card for a bit. He found it pretty insecure, which as long as you’re not a naked celebrity, shouldn’t be a huge issue. For the hacker this is great as it opens up the chance of hacking the firmware for other uses.
Some have already pulled off some cool hacks with these cards. For example, [peterburk] hacked a similar card by PQI to turn his iPod into a portable file server.
The year was 1996, the European Space agency was poised for commercial supremacy in space. Their new Ariane 5 Rocket could launch two three-ton satellites into space. It had more power than anything that had come before.
The rocket rose up towards the heavens on a pillar of flame, carrying four very expensive and very uninsured satellites. Thirty-seven seconds later it self destructed. Seven billion dollars of RUD rained down on the local beaches near the Guiana Space Centre in Southern South America. A video of the failed launch is after the break.
The cause of all this was a single improper type cast in a bit of code that wasn’t even supposed to run during the actual launch. Talk about a fail.
There were two bits of code. One that measured the sideways velocity, and one that used it in the guidance system. The measurement side used a 64 bit variable, but the guidance side used a 16 bit variable. The code was borrowed from an earlier, slower rocket whose velocity would never grow large enough to exceed that 16 bits. The Ariane 5, however, could be described with a Daft Punk song, and quickly overflowed this value.
The code that caused the overflow was actually a bit of pre-launch software that aligned the rocket. It was supposed to be turned off before the rocket firing, but since the rocket launch got delayed so often, the engineers made it timeout 40 seconds into the launch so they didn’t have to keep restarting it.
The ESA never placed blame on a single contractor. The programmers had made assumptions. The engineers had made reasonable shortcuts to make their job easier. It had all made it through inspections, approvals, and finally the launch event.
They certainly learned from the event; the Ariane 5 rocket has flown 82 out of 86 missions successfully since then. It has at least five more launches contracted before it is retired in 2023 for the Ariane 6 rocket being developed now. This event also changed the way critical software and redundant systems were tested, bringing the dangers of code failure to the attention of the public for the first time.