Stealing DNA By Phone

April 24, 2019 by 8 Comments

Data exfiltration via side channel attacks can be a fascinating topic. It is easy to forget that there are so many different ways that electronic devices affect the physical world other than their intended purpose. And creative security researchers like to play around with these side-effects for ‘fun and profit’.

Engineers at the University of California have devised a way to analyse exactly what a DNA synthesizer is doing by recording the sound that the machine makes with a relatively low-budget microphone, such as the one on a smart phone. The recorded sound is then processed using algorithms trained to discern the different noises that a particular machine makes and translates the audio into the combination of DNA building blocks the synthesizer is generating.

Although they focused on a particular brand of DNA Synthesizers, in which the acoustics allowed them to spy on the building process, others might be vulnerable also.

In the case of the DNA synthesizer, acoustics revealed everything. Noises made by the machine differed depending on which DNA building block—the nucleotides Adenine (A), Guanine (G), Cytosine (C), or Thymine (T)—it was synthesizing. That made it easy for algorithms trained on that machine’s sound signatures to identify which nucleotides were being printed and in what order.

Acoustic snooping is not something new, several interesting techniques have been shown in the past that raise, arguably, more serious security concerns. Back in 2004, a neural network was used to analyse the sound produced by computer keyboards and keypads used on telephones and automated teller machines (ATMs) to recognize the keys being pressed.

You don’t have to rush and sound proof your DIY DNA Synthesizer room just yet as there are probably more practical ways to steal the genome of your alien-cat hybrid, but for multi-million dollar biotech companies with a equally well funded adversaries and a healthy paranoia about industrial espionage, this is an ear-opener.

We written about other data exfiltration methods and side channels and this one, realistic scenario or not, it’s another cool audio snooping proof of concept.

Self-aware Robotic Arm

April 24, 2019 by 16 Comments

If you ever tried to program a robotic arm or almost any robotic mechanism that has more than 3 degrees of freedom, you know that a big part of the programming goes to the programming of the movements themselves. What if you built a robot, regardless of how you connect the motors and joints and, with no knowledge of itself, the robot becomes aware of the way it is physically built?

That is what Columbia Engineering researchers have made by creating a robot arm that learns how it is connected, with zero prior knowledge of physics, geometry, or motor dynamics. At first, the robot has no idea what its shape is, how its motors work and how they affect its movement. After one day of trying out its own outputs in a pretty much random fashion and getting feedback of its actions, the robot creates an accurate internal self-simulation of itself using deep-learning techniques.

The robotic arm used in this study by Lipson and his PhD student Robert Kwiatkowski is a four-degree-of-freedom articulated robotic arm. The first self-models were inaccurate as the robot did not know how its joints were connected. After about 35 hours of training, the self-model became consistent with the physical robot to within four centimeters. The self-model then performed a pick-and-place task that enabled the robot to recalibrate its original position between each step along the trajectory based entirely on the internal self-model.

To test whether the self-model could detect damage to itself, the researchers 3D-printed a deformed part to simulate damage and the robot was able to detect the change and re-train its self-model. The new self-model enabled the robot to resume its pick-and-place tasks with little loss of performance.

Since the internal representation is not static, not only this helps the robot to improve its performance over time but also allows it to adapt to damage and changes in its own structure. This could help robots to continue to function more reliably when there its part start to wear off or, for example, when replacement parts are not exactly the same format or shape.

Of course, it will be long before this arm can get a precision anywhere near Dexter, the 2018 Hackaday Prize winner, but it is still pretty cool to see the video of this research:

Texting With A Teletype

April 23, 2019 by 13 Comments

How do you get the kids interested in old technology? By connecting it to a phone, obviously. Those kids and their phones. When [Marek] got his hands on an old-school teletype, he hooked it up to a GSM network, with all the bells and whistles including a 40mA current loop running at an impressive 50 baud.

The teletype in question here is a vintage T100 teletype manufactured in Czechoslovakia sometime in the ’70s. This was a gift to [Marek]’s workplace, the museum of Urban Engineering in Cracow, and this project is effectively an experiment to investigate the possibility of running this teletype as an interactive exhibit rather than an artefact from the age of current loops and phone systems.

The current loop is, or was, the standard way of connecting a teletype to anything, so all [Marek] had to do was construct a box that translated the signals from a GSM modem to this current loop. For the prototype, the microcontroller in question is an old AT89C2051 (as that’s what was sitting in the parts drawer). This was moved over to a PIC32 microcontroller and a SIM800 GSM module. This is housed in a two-part enclosure, with the GSM interfaced housed in one half, with the current loop generator consisting of a simple DC power supply housed int the other half.

This interface is capable of receiving and sending messages from the keyboard to a GSM network, so it is theoretically possible you could text your friends using an old-school teletype. This functionality hasn’t been implemented yet, but it is just about the coolest thing you could possibly imagine. You can check out a video of the teletype in action below. Continue reading “Texting With A Teletype” →

Making Microfluidics Simpler With Shrinky Dinks

April 23, 2019 by 6 Comments

It’s as if the go-to analogy these days for anything technical is, “It’s like a series of tubes.” Explanations thus based work better for some things than others, and even when the comparison is apt from a physics standpoint it often breaks down in the details. With microfluidics, the analogy is perfect because it literally is a series of tubes, which properly arranged and filled with liquids or gasses can perform some of the same control functions that electronics can, and some that it can’t.

But exploring microfluidics can be tough, what with the need to machine tiny passages for fluids to flow. Luckily, [Justin] has turned the process into child’s play with these microfluidic elements made from Shrinky Dinks. For those unfamiliar with this product, which was advertised incessantly on Saturday morning cartoon shows, Shrinky Dinks are just sheets of polystyrene film that can be decorated with markers. When placed in a low oven, the film shrinks about three times in length and width while expanding to about nine times its pre-shrunk thickness. [Justin] capitalized on this by CNC machining fine grooves into the film which become deeper after shrinking. Microfluidics circuits can be built up from multiple layers. The video below shows a mixer and a simple cell sorter, as well as a Tesla valve, which is a little like a diode.

We find [Justin]’s Shrinky Dink microfluidics intriguing and can’t wait to see what kind of useful devices he comes up with. He’s got a lot going on, though, from spider-powered beer to desktop radio telescopes. And we wonder how this technique might help with his CNC-machined microstrip bandpass filters.

Continue reading “Making Microfluidics Simpler With Shrinky Dinks” →

Mowerbot Keeping The Lawn In Check Since 1998

April 23, 2019 by 36 Comments

Mowing the lawn is a chore that serves as an excellent character building excercise for a growing child. However, children are expensive and the maintenance requirements can be prohibitive. Many instead turn to robots to lend a hand, and [Rue Mohr] is no exception.

[Rue]’s creation goes by the name Mowerbot, and was first built way back in 1998. Steel angle and brushed DC motors are the order of the day, helping the ‘bot get around the garden and chop the grass down to size. Being of such a vintage, there’s no Raspberry Pi or Arduino running the show here. No, this rig runs on the venerable 386, chosen primarily as it can run off just 5 V. The original build ran off a 5 1/4″ floppy, though it was later upgraded to CF card storage instead.

It’s not the first robot mower we’ve seen, but is likely one of the longest serving. It’s still in use today, though [Rue] reports it’s due for some new batteries. Given it’s been chewing up the grass for over two decades now, that’s fairly impressive performance. We hope to see this 386-driven beast still cutting away long into the future.

The Simplest Of Pseudo Random Number Generators

April 23, 2019 by 12 Comments

A truly random number is something that is surprisingly difficult to generate. A typical approach is to generate the required element of chance from a natural and unpredictable source, such as radioactive decay or thermal noise. By contrast it is extremely easy to generate numbers that look random but in fact follow a predictable sequence. A shift register with feedback through an XOR of its output and one of its stages will produce a continuous stream of pseudo-random bits that repeat after a set period.

[KK99] has created the simplest possible pseudo-random binary sequence generator, using a three-bit shift register. It’s realised on a pleasingly retro piece of perfboard, with a CD4047 as clock generator and a 74HC164 shift register doing the work. Unusually the XOR gate is made from discrete transistors, 2N3053s in bulky TO39 packages, and for a particularly old-fashioned look a vintage HP LED display shows the currently generated number. A relatively useless pseudo-random sequence with a period of seven bits is the result, but the point of this circuit is to educate rather than its utility. You can see it in operation in the video below the break.

We had a demonstration of the dangers of using a pseudo-random sequence back in 2016. The German military cipher nicknamed “Tunny” by British codebreakers relied upon a mechanical sequence generator, and the tale of its being cracked led to the development of Colossus, the first stored-program electronic computer.

Continue reading “The Simplest Of Pseudo Random Number Generators” →

Circuit-Level Game Boy: Upping Emulation Ante By Simulating Every Cycle

April 23, 2019 by 12 Comments

Usually when writing emulation software for a system like the Game Boy, one makes sure to take as many shortcuts as possible in order to reduce the resources required for the emulation. This has however the unfortunate side-effect that it reduces the overall accuracy of the emulation and with it the compatibility with games on the system.

This is the basic reasoning behind projects which seek to abandon simplistic abstractions in favor of cycle-accurate, full compatibility approaches, of which MetroBoy is probably the most extreme one. Instead of abstracting away the hardware, it instead does the emulation at the circuit level. As with such other projects, this means that the emulator requires a lot more CPU cycles to get things just right. On the bright side, one can likely still run this emulator on any modern system.

As the MetroBoy author explains, he implemented code in C++ which allowed him to construct circuits in an HDL-style manner, which should theoretically also allow him to generate a Verilog (or VHDL) softcore out of the project. As a demonstration of implementing HDL in C++ it’s decidedly interesting.

An approach like this is pretty much the exact opposite of a project like the UltraHLE (ultra high-level emulator) Nintendo 64 emulator, which used the knowledge that Nintendo 64 games are written in C as a first step to creating libraries that the code in the Nintendo 64 ROMs would call instead of the native (Nintendo) libraries. This allowed N64 games to directly run on the target system, with the graphic and system calls translated by UltraHLE into native OS calls, using the 3dfx Glide API for accelerated graphics.

While an approach like UltraHLE took allows for the most minimal use of system resources by essentially foregoing emulation completely, for retro systems like the Game Boy where games were implemented in assembly on bare hardware, using this circuit-level emulation ensures that one gets the most accurate match with the original handheld console experience.

As a word of caution to those who are now itching to try out MetroBoy, its Github site notes that it currently lacks support for game saves, uses a mixture of original Game Boy (DMG) and Game Boy Advance SP (AGS) hardware that confuses some games and has rather buggy sound support.

If playing around with software-defined Game Boy circuits isn’t enough and would like to literally look inside a real Game Boy, the X-ray image from the top of the article is something Chris over at Elektronaut pulled off several years ago.