MiniDisc Player Supports Full Data Transfer

Between the era of the CD and the eventual rise and domination of streaming music platforms, there was a limbo period of random MP3 players mixed in with the ubiquitous (and now officially discontinued) iPod. In certain areas, though, the digital music player of choice was the MiniDisc, a miniature re-writable CD player with some extra digital features. Among them was the ability to transfer music to the discs over USB, but they did not feature the ability to transfer the songs back to a computer. At least until now, thanks to this impressive hack from [asivery].

Although it sounds straightforward, this trick has a lot of moving parts that needed to come together just right. The MiniDisc player uses a proprietary encoding format called ATRAC, so a codec is needed for that. The MiniDisc player stores data from the disc in a 40-second buffer when playing, so the code reads the data directly from DRAM in 40-second chunks, moves the read head, repeats the process as needed, then stitches the 40-second parts back together. It can work on any Sony NetMD portable, if you are lucky enough to still have one around.

The project is a tremendous asset to the MiniDisc community, especially since the only way to recover data from a MiniDisc player prior to this was to use a specific version known as the RH-1. As [asivery] reports, used RH-1 players are going for incredibly high prices partially because of this feature. Since this new method demonstrates that it’s possible to do with other devices, perhaps its reign in the MiniDisc world will come to a close. For those still outside the loop on this esoteric piece of technology, take a look at this MiniDisc teardown.

Thanks to [Maarten] for the tip!

A circuit board with a memory chip in a socket, and many memory chips in foam

Simple DRAM Tester Built With Spare Parts

Some of the most popular vintage computers are now more than forty years old, and their memory just ain’t how it used to be. Identifying bad memory chips can quickly become a chore, so [Jan Beta] spent some time putting together a cheap DRAM tester out of spare parts.

This little tester can be used with 4164 and 41256 DRAM memory chips. 4164 DRAM was used in several popular home computers throughout the 1970s and 1980s, including the Apple ][ series, Commodore 64, ZX Spectrum and many more. Likewise, the 41256 was used in the Commodore Amiga. These computers are incredibly popular in the vintage computing community, and its not uncommon to find bad memory in any of them.

With an Arduino at its core, this DRAM tester uses the most basic of electronic components, and any modest tinkerer should have pretty much everything in stock. The original project can be found here, including the Arduino code. Just pop the suspect chip into the ZIF socket, hit the reset switch, and wait for the LED – green is good, and red means it’s toast.

It’s a great sanity check for when you’re neck deep in suspect DRAM. A failed test is a sure sign that the chip is bad, however the tester does occasionally report a false pass. Not every issue can be identified with such a simple tester, however it’s great at weeding out the chips that are definitely dead.

If you’re not short on cash, then the Chip Tester Pro may be more to your liking, however it’s hard to beat the simplicity and thriftiness of building your own simple tester from spare parts. If you’re a little more adventurous, this in-circuit debugger could come in handy.

Continue reading “Simple DRAM Tester Built With Spare Parts”

Craziest Pin-Saving LCD Trick Ever!

We love squeezing every last bit of silicon goodness out of a tiny chip, or at least we delight in seeing it done. Today’s analog/digital hack is one of the sweetest we’ve seen in a while. And it’s also a little bit of a puzzle, so don’t scroll down to the answer until you’ve given the schematic a good think-over.

Continue reading “Craziest Pin-Saving LCD Trick Ever!”

Building The First Digital Camera

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
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.

Testing DRAM, One Byte At A Time

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.

Creative DRAM Abuse With Rowhammer

Project Zero, Google’s security analyst unit, has proved that rowhammer can be used as an exploit to gain superuser privileges on some computers. Row Hammer, or rowhammer is a method of flipping bits in DRAM by hammering rows with fast read accesses. [Mark Seaborn] and the rest of the Project Zero team learned of rowhammer by reading [Yoongu Kim’s] 2014 paper “Flipping Bits in Memory Without Accessing Them:
An Experimental Study of DRAM Disturbance Errors” (PDF link). According to [Kim], the memory industry has known about the issue since at least 2012, when Intel began filing patents for mitigation techniques.

Row hammer” by DsimicOwn work. Licensed under CC BY-SA 4.0 via Wikimedia Commons.

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:

20EA0: 48 b8 0f 05 EB 0C F4 F4 F4 F4 movabs $0xF4F4F4F40CEB050F,%rax 

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!

If you want to play along at home, the Project Zero team have a rowhammer test up on GitHub.

Taking Pictures With A DRAM Chip

 

DRAM Image

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.

Thanks to [svofski] for the tip.