34C3: Ultimate Apollo Guidance Computer Talk

While it might not be as exciting as the Saturn V rocket itself, the Apollo Guidance Computer (AGC) was one of the most important developments of the entire Apollo program. While comically underwhelming compared to modern hardware, the AGC was nothing short of revolutionary when it was developed in the 1960’s. Before the AGC, the smallest computers were about the size of a refrigerator and consumed hundreds of watts; both big problems if you’re trying to pack them into a relatively tiny space capsule with limited resources. Not only did the AGC get humanity to the Moon and back, but it also redefined the state of the art for microcomputers, paving the way for the desktop systems of the 1970’s.

That said, the design and operation of the AGC is downright bizarre to modern eyes; it comes from a time of limitations we can hardly fathom. With this in mind, [Michael Steil] and [Christian Hessmann] put together “The Ultimate Apollo Guidance Computer Talk” for 34C3.

This hour-long presentation walks viewers through every aspect of not only the AGC itself, but how it interacted with the Saturn V rocket and the overall lunar mission. Even if you aren’t enough of a vintage computing aficionado to appreciate the complexities of core rope memory, the presentation gives a fascinating look at the gritty details of one of humanity’s greatest achievements.

Though very slick and easy to understand graphics, [Michael] and [Christian] break down the alien world of the AGC. Even if a lot of this part of the presentation goes over your head, just listen for the sounds of laughter or applause from the audience: that’s when you’re looking at something really off-the-wall.

Of particular note during this presentation is the explanation of how the astronauts actually interacted with the AGC. The AGC’s display and keyboard (referred to as DSKY) may seem rather obtuse even to those who used to hack on a VT100, but [Michael] and [Christian] explain how it’s not quite as complex as it seems. Comparing the input and output of the DSKY with what we would see on a more contemporary command line interface, the presentation makes the case that it’s actually a very straightforward way of talking to the computer.

There’s also a complete breakdown of the different phases of the Apollo mission from launch to landing, explaining what the AGC would be doing at any given time. The DSKY is overlaid on actual footage from the Apollo missions, giving a unique perspective as to what the astronauts would see on their computer during iconic moments such as stage separation or lunar touchdown.

If this presentation has you hungry for more Apollo-era computer technology, we’ve covered plenty of projects to keep you occupied. From building a replica DSKY to leisurely paging through the printed version of the AGC’s source code.

Learning ARM assembly with visUAL

Learning assembly is very important if you want to get a grasp of how a computer truly works under the hood. VisUAL is a very capable ARM emulator for those interested in learning the ARM assembly.

The GUI: A simply program to ADD two numbers

In addition to supporting a large subset of ARM instructions, the CPU is emulated via a series of elaborate and instructive animations that help visualise the flow of data to/from registers, any changes made to flags, and any branches taken. It also packs very useful animations to help grasp some of the more tricky instruction such as shifts and stack manipulations.

As it is was designed specifically to be used as teaching tool at Imperial College London, the GUI is very friendly, all the syntax errors are highlighted, and an example of the correct syntax is also shown.

Branch visualisation, credits: VisUAL homepage

You can also do the usual things you would expect from any emulator, such as single step through execution, set breakpoints, and view data in different bases. It even warns you of any possible infinite loops!

That being said, lugging such an extravagant GUI comes at a price; programs that consume a few hundred thousand cycles hog far too much RAM should be run in the supported headless mode.


34C3: Hacking into a CPU’s Microcode

Inside every modern CPU since the Intel Pentium fdiv bug, assembly instructions aren’t a one-to-one mapping to what the CPU actually does. Inside the CPU, there is a decoder that turns assembly into even more primitive instructions that are fed into the CPU’s internal scheduler and pipeline. The code that drives the decoder is the CPU’s microcode, and it lives in ROM that’s normally inaccessible. But microcode patches have been deployed in the past to fix up CPU hardware bugs, so it’s certainly writeable. That’s practically an invitation, right? At least a group from the Ruhr University Bochum took it as such, and started hacking on the microcode in the AMD K8 and K10 processors.

The hurdles to playing around in the microcode are daunting. It turns assembly language into something, but the instruction set that the inner CPU, ALU, et al use was completely unknown. [Philip] walked us through their first line of attack, which was essentially guessing in the dark. First they mapped out where each x86 assembly codes went in microcode ROM. Using this information, and the ability to update the microcode, they could load and execute arbitrary microcode. They still didn’t know anything about the microcode, but they knew how to run it.

So they started uploading random microcode to see what it did. This random microcode crashed almost every time. The rest of the time, there was no difference between the input and output states. But then, after a week of running, a breakthrough: the microcode XOR’ed. From this, they found out the syntax of the command and began to discover more commands through trial and error. Quite late in the game, they went on to take the chip apart and read out the ROM contents with a microscope and OCR software, at least well enough to verify that some of the microcode operations were burned in ROM.

The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)

[Benjamin] then bravely stepped us through the browser-based attack live, first in a debugger where we could verify that their custom microcode was being triggered, and then outside of the debugger where suddenly xcalc popped up. What launched the program? Calculating a particular number on a website from inside an unmodified browser.

He also demonstrated the introduction of a simple mathematical error into the microcode that made an encryption routine fail when another particular multiplication was done. While this may not sound like much, if you paid attention in the talk on revealing keys based on a single infrequent bit error, you’d see that this is essentially a few million times more powerful because the error occurs every time.

The team isn’t done with their microcode explorations, and there’s still a lot more of the command set left to discover. So take this as a proof of concept that nearly completely undetectable trojans could exist in the microcode that runs between the compiled code and the CPU on your machine. But, more playfully, it’s also an invitation to start exploring yourself. It’s not every day that an entirely new frontier in computer hacking is bust open.

Ergonomic Keyboard Designed from the Ground Up

In 2011, [Fabio] had been working behind a keyboard for about a decade when he started noticing wrist pain. This is a common long-term injury for people at desk jobs, but rather than buy an ergonomic keyboard he decided that none of the commercial offerings had all of the features he needed. Instead, he set out on a five-year journey to build the perfect ergonomic keyboard.

Part of the problem with other solutions was that no keyboards could be left in Dvorak (a keyboard layout [Fabio] finds improves his typing speed) after rebooting the computer, and Arduino-based solutions would not make themselves available to the computer’s BIOS. Luckily he found the LUFA keyboard library, and then was able to salvage a PCB from another keyboard. From there, he programmed everything on a Teensy microcontroller, added an OLED screen, and soldered it all together (including a set of Cherry MX switches).

Of course, the build wasn’t truly complete until recently, when a custom two-part case was 3D printed. The build quality and attention to detail in this project is impressive, and if you want to roll out your own [Fabio] has made all of the CAD files and software available. Should you wish to incorporate some of his designs into other types of specialized keyboards, there are some ideas floating around that will surely improve your typing or workflow.

Hackaday Superconference Talk: Cory Grosser

When we look at a product or project here at Hackaday it is likely that our interest has been caught by its internal technology, or perhaps by its functionality. It is easy to forget that there is another angle to each and every item that graces these pages, and it is every bit as important as those we have already mentioned. Aesthetic design, the look and feel of a product, is something that is so often overlooked.

One of the speakers at the Hackaday Superconference was [Cory Grosser], one of America’s leading independent product designers, and the designer of the Supplyframe Design Lab in which the Superconference was being held. In his talk he covered some of the principles of design, touching on its psychology and its purpose in creating a successful product. In doing so he delivered a fascinating talk full of insights into the design of products both famous and somewhat obscure.

Continue reading “Hackaday Superconference Talk: Cory Grosser”

Barbara McClintock: Against The Genetic Grain

The tale of much of Barbara McClintock’s life is that of the scientist working long hours with a microscope seeking to solve mysteries. The mystery she spent most of her career trying to solve was how all cells in an organism can contain the same DNA, and yet divide to produce cells serving different functions; basically how cells differentiate. And for that, she got a Nobel prize all to herself, which is no small feat either.

Becoming a Scientist

Human chromosomes, long strands of DNA
Human chromosomes, long strands of DNA by Steffen Dietzel CC BY-SA 3.0

McClintock was born on June 16, 1902, in Hartford, Connecticut, USA. From age three until beginning school, she lived with her aunt in Brooklyn, New York while her father strove financially to start up a medical practice. She was a solitary and independent-minded child, a trait she later called her “capacity to be alone”.

In 1919, she began her studies at Cornell’s College of Agriculture and took her first course in genetics in 1921. A year later, due to the interest she showed in genetics, she was invited to take the graduate genetics course at Cornell. It was here that she became interested in the new field of cytogenetics, specifically of maize or corn. Cytogenetics studies how the chromosomes relate to cell behavior, particularly during cell division. Chromosomes are the long strands of DNA within the nucleus of every cell and shown here in the photo at a time when they are condensed, or coiled up.

While still at Cornell she developed a number of methods for visualizing and characterizing maize which ended up in textbooks. She also became the first to describe the morphology of the ten maize chromosomes, basically their form and structural relationships, which then allowed her to discover more about the chromosomes. One of her colleagues observed that ten of the seventeen significant advances made in the field at Cornell between 1929 and 1935 were hers. This was only the first step in what would be the remarkable career of a very well respected scientist.

Continue reading “Barbara McClintock: Against The Genetic Grain”

Fingerling Disemboweled for Your Entertainment

Due to the graphic nature of this post, small children and the elderly may want to leave the room. One of the hottest toys this holiday season has been gutted like a fish so that we may better understand the nature of its existence. Or maybe just what kind of sensors and motors the craftsmen over at WowWee managed to cram into a “robot” with an MSRP of only $15 USD.

[Josh Levine] mercilessly tears a Fingerling Monkey limb from limb on his blog, and points out some interesting design decisions made. While some elements of the toy are rather clever, there’s a few head-scratchers to be had inside the Fingerling. It’s interesting to see the final results of a decision process that had to balance the relatively rough life such a toy will live with the ever crucial cost of production.

The eyelids are particularly well thought out, operated by charging a coil under a magnet which is embedded in the plastic. Opening and closing the eyelids without a separate motor or gearbox is not only easier and cheaper, but prevents the possibility of damage if a child attempts to force open the eyes or otherwise manipulate the mechanism.

Other cost saving measures include the use of foil tape as a capacitive sensor, and simple ball-filled tilt sensors to detect orientation rather than an expensive accelerometer.

Interestingly, other parts of the toy seem overengineered in comparison. A cam and limit switch are used to detect when the Fingerling’s head has turned to its maximum angle, when it would have been cheaper and easier to simply detect motor stall current.

If you’re interested in seeing what makes popular toys tick, we’ve got a number of plaything tear downs which are sure to keep you satiated until the next big holiday toy rolls around.

Continue reading “Fingerling Disemboweled for Your Entertainment”