While the official history of the digital camera begins with a Kodak engineer tinkering around with digital electronics in 1975, the first digital camera was actually built a few months prior. At the Vintage Computer Festival East, [William Sudbrink] rebuilt the first digital camera. It’s wasn’t particularly hard, either: it was a project on the cover of Popular Electronics in February, 1975.
Cromemco catalog page for the Cyclops, the first digital camera
[William]’s exhibit, Cromemco Accessories: Cyclops & Dazzler is a demonstration of the greatest graphics cards you could buy for S-100 systems and a very rare, very weird solid-state TV camera. Introduced in the February, 1975 issue of Popular Electronics, the Cyclops was the first digital camera. This wasn’t a device that used a CCD or a normal image sensor. The image sensor in the Cyclops was a 1 kilobit DRAM from MOS, producing a digital image thirty-two pixels square.
The full description, schematic, circuit layout, and theory of operation are laid out in the Popular Electronics article; all [William] had to do was etch a PCB and source the components. The key part – a one kilobit MOS DRAM in a metal can package, carefully decapsulated – had a date code of 1976, but that is the newest component in the rebuild of this classic circuit.
To turn this DRAM into digital camera, the circuit sweeps across the rows and columns of the DRAM array, turning the charge of each cell into an analog output. This isn’t a black or white camera; there’s gray in there, or green if you connect it to an oscilloscope.
This project in Popular Electronics would be manufactured by Cromemco in late 1975 and was released as their first product in January, 1976. The Cromemco was marketed as a digital camera, designed to interface with the MITS Altair 8800 computer, allowing anyone to save digital images to disk. This was the first digital camera invented, and the first digital camera sold to consumers. It’s an amazing piece of history, and very happy [William] was able to piece this together and bring it out to the Vintage Computer Festival this weekend.
A few weekends ago, [Chris] was in the mood for some retrogaming. That meant digging out the old Apple IIgs equipped with a monstrous RAM card with a whole three megabytes of RAM. This particular Apple IIgs had intermittent issues for a long time, and [Chris] was beginning to suspect the RAM was the culprit. Testing this required testing a few dozen individual RAM chips, so why not build something with an Arduino to make [Chris]’ life easier?
The chips found in [Chris]’ Apple are standard 1 M x 1 DRAM chips, the standard for late-80s computers. To test these chips on an Arduino, he picked up a beautiful ZIF socket, wired up the chip to an Arduino shield, and began the joyous process of figuring out how to interface DRAM to an Arduino.
Unlike static memories, DRAM needs to be refreshed periodically to recharge the capacitors. While this refresh cycle was the bane of designers and engineers throughout time, [Chris] actually doesn’t need to care about refreshing the DRAM. He’s just writing 1024 rows to the memory and reading it straight out – no need to refresh the memory. The trick comes from the multiplexed address bus. For his project, [Chris] needs to write 10 bits of the address, latch it, then write the other half of the address bits.
The DRAM tester was a success, and [Chris] put all the code and schematics up on GitHub. Solving the mystery of the broken Apple IIgs wasn’t as simple, as [Chris] thinks the problem might be in one of the support chips on the gigantic RAM card or the IIgs motherboard. Still, it’s a neat, quick build to test out a few DRAM chips.
The technique is deceptively simple. Dynamic RAM is organized into a matrix of rows and columns. By performing fast reads on addresses in the same row, bits in adjacent rows can be flipped. In the example image to the left, fast reads on the purple row can cause bit flips in either of the yellow rows. The Project Zero team discovered an even more aggressive technique they call “double-sided hammering”. In this case, fast reads are performed on both yellow rows. The team found that double-sided hammering can cause more than 25 bits to flip in a single row on a particularly vulnerable computer.
Why does this happen? The answer lies within the internal structure of DRAM, and a bit of semiconductor physics. A DRAM memory bit is essentially a transistor and a capacitor. Data is stored by charging up the capacitor, which immediately begins to leak. DRAM must be refreshed before all the charge leaks away. Typically this refresh happens every 64ms. Higher density RAM chips have forced these capacitors to be closer together than ever before. So close in fact, that they can interact. Repeated reads of one row will cause the capacitors in adjacent rows to leak charge faster than normal. If enough charge leaks away before a refresh, the bit stored by that capacitor will flip.
Cache is not the answer
If you’re thinking that memory subsystems shouldn’t work this way due to cache, you’re right. Under normal circumstances, repeated data reads would be stored in the processor’s data cache and never touch RAM. Cache can be flushed though, which is exactly what the Project Zero team is doing. The X86 CLFLUSH opcode ensures that each read will go out to physical RAM.
Wanton bit flipping is all fine and good, but the Project Zero team’s goal was to use the technique as an exploit. To pull that off, they had to figure out which bits they were flipping, and flip them in such a way as to give elevated access to a user level process. The Project Zero team eventually came up with two working exploits. One works to escape Google’s Native Client (NaCL) sandbox. The other exploit works as a userspace program on x86-64 Linux boxes.
Native Client sandbox escape exploit
Google defines Native Client (NaCL) as ” a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.” It was designed specifically as a way to run code in the browser, without the risk of it escaping to the host system. Let that sink in for a moment. Now consider the fact that rowhammer is able to escape the walled garden and access physical memory. The exploit works by allocating 250MB of memory, and rowhammering on random addresses, and checking for bit flips. Once bit flips are detected, the real fun starts. The exploit hides unsafe instructions inside immediate arguments of “safe” institutions. In an example from the paper:
Viewed from memory address 0x20EA0, this is an absolute move of a 64 bit value to register rax. However, if we move off alignment and read the instruction from address 0x20EA02, now it’s a SYSCALL – (0F 05). The NaCL escape exploit does exactly this, running shell commands which were hidden inside instructions that appeared to be safe.
Linux kernel privilege escalation exploit
The Project Zero team used rowhammer to give a Linux process access to all of physical memory. The process is more complex than the NaCL exploit, but the basic idea revolves around page table entries (PTE). Since the underlying structure of Linux’s page table is well known, rowhammer can be used to modify the bits which are used to translate virtual to physical addresses. By carefully controlling which bits are flipped, the attacking process can relocate its own pages anywhere in RAM. The team used this technique to redirect /bin/ping to their own shell code. Since Ping normally runs with superuser privileges, the shell code can do anything it wants.
The TL;DR
Rowhammer is a nasty vulnerability, but the sky isn’t falling just yet. Google has already patched NaCL by removing access to the CLFLUSH opcode, so NaCL is safe from any currently known rowhammer attacks. Project Zero didn’t run an exhaustive test to find out which computer and RAM manufacturers are vulnerable to rowhammer. In fact, they were only able to flip bits on laptops. The desktop machines they tried used ECC RAM, which may have corrected the bit flips as they happened. ECC RAM will help, but doesn’t guarantee protection from rowhammer – especially when multiple bit flips occur. The best protection is a new machine – New RAM technologies include mitigation techniques. The LPDDR4 standard includes “Targeted Row Refresh” (TRR) and “Maximum Activate Count” (MAC), both methods to avoid rowhammer vulnerability. That’s a good excuse to buy a new laptop if we ever heard one!
This picture was taken by using a DRAM chip as an image sensor (translated). A decapped 64k DRAM chip was combined with optics that could focus an image onto the die. By reading data out of the DRAM, the image could be constructed.
DRAM is the type of RAM you find on the RAM cards inserted into your motherboard. It consists of a massive array of capacitors and transistors. Each bit requires one transistor and one capacitor, which is quite efficient. The downside is that the memory needs to be refreshed periodically to prevent the capacitors from discharging.
Exposing the capacitor to light causes it to discharge faster. Once it has discharged past a certain threshold, the bit will flip from one to zero. To take a picture, ones are written to every bit in the DRAM array. By timing how long it takes a bit to flip from one to zero, the amount of light exposure can be determined. Since the DRAM is laid out in an array, each bit can be treated as a pixel to reconstruct the image.
Sure, modern CCDs are better, cheaper, and faster, but this hack is a neat way to totally re-purpose a chip. There’s even Turbo Pascal source if you’d like to recreate the project.
A few months ago, [Josh] was given an old Commodore 64. He needed to make an AV cable and find a new power supply, and even after testing these new parts out, [Josh] found it still wouldn’t boot. Not one to look a gift horse in the mouth — or perhaps he enjoys the challenge — he set out on restoring a thirty year old circuit board.
He replaced a few chips and the caps, but found he had no way to test the DRAM chips. Compared to SRAM or Static RAM used by other computers of the era, DRAM is a bit harder to interface, requiring a capacitor in each memory cell to be refreshed a few dozen times every second. With a bit of help from his good friend [CNLohr], [Josh] figured out a circuit to read and write to his chips and build a small board based on the ATmega8U2 microcontroller for testing purposes.
For the longest time, hardware tinkerers have only been able to play around with two types of memory. RAM, including Static RAM and Dynamic RAM, can be exceedingly fast but is volatile and loses its data when power is removed. Non-volatile memory such as EPROMS, EEPROMS, and Flash memory retains its state after power is removed, but these formats are somewhat slower.
There have always been competing technologies that sought to combine the best traits of these types of memory, but not often have they been available to hobbyists. [Majenko] got his hands on a few MRAM chips – Magneto-Resistive RAM – and decided to see what they could do.
Magneto-Resistive RAM uses tiny pairs of magnetic plates to read and write 1s and 0s. [Majenko] received a sample of four MRAM chips with an SPI bus (it might be this chip, 4 Megabits for $20, although smaller capacity chips are available for about $6). After wiring these chips up on a home-made breakout board, [Majenko] had 16 Megabits of non-volatile memory that was able to run at 40 MHz.
The result was exactly what the datasheet said: very fast write and read times, with the ability to remove power. Unlike EEPROMS that can be destroyed by repeated reading and writing, MRAM has an unlimited number of write cycles.
While MRAM may be a very young technology right now, it’s a wonderful portent of things to come. In 20 (or 30, or 40) years, it’s doubtful any computer from the largest server to the smallest microcontroller will have the artificial separation between disk space and memory. The fact that any hardware hacker is able to play around with this technology today is somewhat amazing, and we look forward to more builds using MRAM in the future.
If you haven’t gotten a chance yet, do watch the video of this attack. It’s does a good job explaining the problem. Full drive encryption stores the key in RAM while the computer is powered on. The RAM’s stored data doesn’t immediately disappear when powered off, but fades over time. To recover the keys, they powered off the computer and booted from a USB disk that created an image of the RAM. You can read more about the attack here.
How can you reduce this threat? You can turn off USB booting and then put a password on the BIOS to prevent the specific activity shown in the video. Also, you can encrypt your rarely used data in a folder on the disk. They could still decrypt the disk, but they won’t get everything. I don’t think this problem will truly be fixed unless there is a fundamental change in hardware design to erase the RAM and even then it would probably only help computers that are powered off, not suspended.
The potential for this attack has always been talked about and I’m glad to see someone pull it off. I’m hoping to see future research into dumping RAM data using a USB/ExpressCard with DMA access.
