[Andrew] recently got scammed on an SD card purchase and put together a small tool that can help you determine if you’ve had the wool pulled over your eyes as well.

You see, he purchased a set of MicroSD cards, all of which had an advertised capacity of 4GiB. When he tried to use them, they all failed to write more than about 115MiB of data, so he knew something was up. He sat down with some tools that can be used to check the actual capacity of flash media, but he says they were unbelievably slow to scan the cards.

While he waited for one of the scans to complete, he decided to create a utility of his own that would do the same thing in a fraction of the time. His quick and dirty application, called “Scam-o-Matic”, writes random data to the card, double-checking the written region to ensure that data can be read back. If it finds errors your card is likely either a fake or damaged, but if not, it automatically prepares the media for use.

Obviously this sort of situation is relatively rare, but if you think that you have picked up some shady SD cards, be sure to check out [Andrew’s] Github repository.

How much memory do you really need? We suppose it’s not really our place to judge how you misuse use memory in your projects. But we do appreciate the clean and orderly technique that [Eric Rogers] uses to add multiple SPI SRAM chips to an Arduino.

The heavy lifting is done with a CPLD shield called the Amani 64. It intercepts the SPI calls from the Arduino to an SRAM chip, and translates the address information to find the appropriate data on a collection of 23K256 devices. These chips are inexpensive, and using several of them provides a savings over choosing a single SPI addressable chip with a larger memory size.

The best part is that the flexibility of the CPLD allowed [Eric] to devise an addressing system that takes advantage of unused bits in the Arduino’s SPI data transfer functions. When using a single 23K256 chip, there are four write functions that waste a total of six bits. He devised a method to inject addressing data into these unused bits, allowing him to address up to 64 different memory chips for a potential of 2 MB of storage. The CPLD pulls out this injected address and subsequently writes or reads the bank of SRAM chips.

Looking for other SRAM upgrade options? Here’s another one that uses multiplexing to decrease the address lines necessary to add memory.

[Andy] stuffed some more RAM onto an Arduino Mega and his three-part walk through on the design, construction, and software is a great read and one of the more ‘hard core’ Arduino builds we’ve seen.

The build is centered around a 512K × 8 SRAM module [PDF warning]. Because the RAM is divided up into about 512,000 chunks of 8 bits, the Arduino has to access the RAM through 16 ‘address lines’, then send the data through 8 ‘data lines’. [Andy] didn’t want to use up 24 pins on his Arduino, so he used a latch to multiplex the lowest 8 address lines and the data lines together. With the 512KB RAM expansion installed, the Mega is able to address a whopping 520 Kilobytes.

We’ve seen a few builds that have been limited by the amount of RAM available in the Arduino, like capturing video and some robot hacks, and adding some more RAM to those builds would be great. Multiplexing data and address lines using a latch can be expanded even further, but 520KB ought to be enough for anybody.

If you’ve ever wanted to dive in and take a look at how memory hardware is implemented here is a good example of how to implement some latching circuits with ether BJT or CMOS transistors. BJTs require biasing resistors which increases the complexity and power consumption when compared to CMOS. If power consumption isn’t an issue you could certainly make some really fast logic.

Most modern on chip RAM is made using SRAM because it only takes six transistors to implement(vs eight) and is pretty fast. When it comes to density DRAM can get one bit of storage by using a single transistor and capacitor(putting the capacitor underneath he transistor can save even more space). All that said, latches and flip flops are still a very useful (and common) tool when working with digital circuits.

We’d bet you never had a Dreamcast Visual Memory Unit, but if you can find one now it can be turned into an iPod (translated). The VMU was originally a memory card for the not-so-popular gaming console that put an LCD screen right in your controller. When you weren’t at home you could take it with you and play mini-games. This version lacks its original guts, which have been replaced with a 6th generation iPod nano. The screen is just a bit small for the opening so a frame of white tape was applied as a bezel. The sleep button has been extended through the cover for the VMU connector. It seems there’s a gaping hole in the back of the case, but after seeing the ultrasonic knife used to cut away the plastic we don’t care. We’ve embedded video of that tool after the break.

[via Reddit]

[StaticChanger] built a scoreboard to display his kill statistics from Halo for the PC. Yes, we’ve seen kill counters before, but we like the way that he gathers the data. This project is reading the score directly from an address in memory.

Using a program called Cheat Engine, the memory used by a program can be sniffed. After a few passes, the program will help you find a static memory address for your desired data. Once you have that it’s just a matter of using a pointer to that address in your desired programming language. In this case, a C# program polls the value and instructs an Arduino to display the value on a couple of 7-segment displays. Voila, the number appears next to your screen as you see in the image above.

You can now download the exploit package for the PlayStation 3. [Geohot] just posted the code you need to pull off the exploit we told you about on Sunday, making it available on a “silver platter” with just a bit of explanation on how it works. He’s located a critical portion of the memory to attack. By allocating it, pointing a whole bunch of code at those addresses, then deallocating it he causes many calls to invalid addresses. At the same time as those invalid calls he “glitches” the memory bus using a button on his FPGA board to hold it low for 40ns. This trips up the hypervisor security and somehow allows read/write access to that section of memory. Gentleman and Ladies, start your hacking. We wish you the best of luck!

[Thanks Phileas]

Check out this visual hardware guide from deviantART member [Sonic840]. It has everything from memory modules, to bus sockets, to power connectors, to an entire array of CPU sockets that have been used over the years. You’re bound to see something in there you didn’t know existed.

[via Gizmodo]

[Jerry] lost his finger in an accident and has since added a prosthetic USB flash drive in its place. It’s making the best of a bad situation; there’s nothing wrong with a little voluntary cyborgization. At least it’s not as invasive as some of the implants we’ve seen before.

UPDATE: Here’s the entry on [Jerry]‘s personal blog.

[via Gizmodo]

Microchip’s new 23K256 is a serially interfaced 32 kilobyte SRAM memory chip, available in 8 pin DIP and 8 pin SO packages. SRAM, like EEPROM, is a data storage medium. Data stored in SRAM is lost without constant power, but it’s really fast and there’s no limits to the number of write cycles. EERPOM stores data even without power, but it’s slow and usually limited to around a million write cycles.

32K SRAM chips typically have 15 address lines and 8 data lines, like the IS61LV256AL we used on our CPLD development board.  The 23K256 requires just four signal lines, but sacrifices the speed of a parallel memory interface. It’s a great way to add extra memory to a low-pin count microcontroller without routing 23 signal traces. We’ll show you how to interface this chip below.

Microchip 23K256, 32K SPI SRAM (Mouser search, Octopart search, $1.48). Datasheet (PDF).

We connected the 23K256 to our Bus Pirate universal serial interface tool as shown in the table. It’s very important to power the chip using only the Bus Pirate’s 3.3volt supply, the 23K256 isn’t rated for 5volts.

The Bus Pirate is an easy way to learn about a chip without writing any code, but the same principals apply to using the 23K256 with any microcontroller. This demonstration uses the latest version of the Bus Pirate firmware (26-FEB-2009), which you can download from our Google Code SVN.

HiZ>m <–choose mode
1. HiZ
…
5. SPI
…
MODE>5 <–SPI mode
MODE SET
… <–30KHz, all default settings
SPI READY
SPI>W <–capital ‘W’ enables power supplies
VOLTAGE SUPPLIES ON
SPI>

First, we put the Bus Pirate into SPI mode at 30KHz and chose the default settings for all options. We enabled the Bus Pirate’s on-board 3.3volt power supply with a capital ‘W’.

Configuration register

bit 7,6 = byte (00) page (10) sequence (01) mode
bit 0 = Hold disabled (1)

Data is stored inside the 23K256 in 1024 pages that each contain 32bytes. The scope of reads and writes is set by bit 7 and 6 of the configuration register. Storage can be accessed by the byte (00), by 32byte pages (10), or sequentially through the entire 32K (01).  We’ll work in sequence mode, which gives us access to read and write any length of data, anywhere in the 32K of storage space.

The hold pin is used to pause transfers when other chips on the same bus need to be accessed. Bit 0 of the configuration register controls the hold pin. When set to 1, the hold pin is disabled. We tied hold to ground for normal operation, but its functionality can be completely disabled by setting bit 0.

The configuration register is changed by sending the write configuration command (0b00000001) and the new settings.

SPI>[0b1 0b01000001] <–update config register
CS ENABLED
WRITE: 0×01 <–write config command
WRITE: 0×41 <–value to write
CS DISABLED
SPI>

We start an SPI transaction by enabling the 23K256 chip select line ([). We send the write configuration command (0b1, 0x01, or 1), followed by the new settings for the configuration register (0b01000001, 0x41). We set bit 6 for sequential access mode, and set bit 0 to disable the hold pin function. Bits 5-1 have no function, but the datasheet says to always write 0. The transaction concludes by disabling the chip select signal (]).

SPI>[0b101 r]
CS ENABLED
WRITE: 0×05 <–read config register
READ: 0×41 <–value read
CS DISABLED
SPI>

Next, we use the read configuration register command (0b00000101, 0b101, 0×05, or 5) to verify that the settings were properly written. This command returns one byte (r) which should match the value we wrote in the previous operation (0×41, or 0b01000001).

Data access

Now we can read and write data to the chip. Writes begin with the data write command (0b10, 0×02, or 2), followed by two bytes which determine where to write the data. The values to store are sent after the address. Depending on the access mode, a single byte, a page, or the entire memory can be filled in a single operation.

SPI>[0b10 0 0 1 2 3 4 5 6 7 8 9 10]
CS ENABLED
WRITE: 0×02 <–data write command
WRITE: 0×00 <–address byte 1
WRITE: 0×00 <–address byte 2
WRITE: 0×01 <–start of data to write
WRITE: 0×02
WRITE: 0×03
WRITE: 0×04
WRITE: 0×05
WRITE: 0×06
WRITE: 0×07
WRITE: 0×08
WRITE: 0×09
WRITE: 0x0A
CS DISABLED
SPI>

We start with the write data command (0b10) and set the write location to the beginning of the chip (0 0). We send a total of ten values to store, the numbers 1 to 10.

After writing the data, we can read it back with the read data command (0b00000011, 0b11, 0×03, or 3).

SPI>[ 0b11 0 0 r:10]
CS ENABLED
WRITE: 0×03 <–read data command
WRITE: 0×00 <–start address byte 1
WRITE: 0×00 <–start address byte 2
BULK READ 0x0A BYTES: <–read out 10 bytes
0×01 0×02 0×03 0×04 0×05 0×06 0×07 0×08 0×09 0x0A
CS DISABLED
SPI>

We send the read data command (0b11), followed by the address from which to start reading (0 0). We then read back 10 bytes (r:10). The 10 byte are the numbers 1 to 10, the same values we wrote in the previous step.

Like this post? Check out the parts posts you may have missed. Want to request a part post? Please leave your suggestions in the comments.

[les robots] had a defective Eye-Fi card on his hands and when a replacement was sent, he was told to destroy the original. What better way to ‘destroy’ something than opening the case? The Eye-Fi is an SD card with a builtin WiFi radio so it can upload images while remaining in camera. One version uses Skyhook’s location service to geotag photos. You can see a few photos of the dismantled card on Flickr. The board is manufactured by Wintec. The wireless side is handled by Atheros’ ROCm, the same low power Radio-on-Chip module you would find in a mobile phone. The flash memory comes from Samsung and the antenna is along the back edge, where it has the best chance of getting signal.

Frozen Cache is a blog dedicated to a novel way to prevent cold boot attacks. Last year the cold boot team demonstrated that they could extract encryption keys from a machine’s RAM by placing it in another system (or the same machine by doing a quick reboot). Frozen Cache aims to prevent this by storing the encryption key in the CPU’s cache. It copies the key out of RAM into the CPU’s registers and then zeroes it in RAM. It then freezes the cache and attempts to write the key back to RAM. The key is pushed into the cache, but isn’t written back to RAM.

The first major issue with this is the performance hit. You end up kneecapping the processor when you freeze the cache and the author suggests that you’d only do this when the screen is locked. We asked cold boot team member [Jacob Appelbaum] what he thought of the approach. He pointed out that the current cold boot attack reconstructs the key from the full keyschedule, which according to the Frozen Cache blog, still remains in RAM. They aren’t grabbing the specific key bits, but recreating it from all this redundant information in memory. At best, Frozen Cache is attempting to build a ‘ghetto crypto co-processor’.

We stand by our initial response to the cold boot attacks: It’s going to take a fundamental redesign of RAM before this is solved.

[via Slashdot]

The Maxim DS2431 1K EEPROM is 1-Wire device that adds storage to a project using a single microcontroller pin. We previously interfaced a 1-wire thermometer, but this EEPROM is slightly different because it draws power directly from the 1-Wire bus. Grab the datasheet (PDF) and follow along while we read and write this simple 1-Wire memory.

DS2431 1-Wire 1K EEPROM (Digikey #DS2431+-ND, $1.67)

We used our Bus Pirate universal serial interface to demonstrate the DS2431 EEPROM, we covered the proper connections and configuration options in our previous 1-wire post. The DS2431 requires just two connections: ground (pin 1) and 1-Wire/power (pin 2).  Pin 3 remains unconnected. Like last time, we used a 2K pull-up resistor with the 1-Wire bus.

First, we use the Bus Pirate’s SEARCH ROM command to identify connected 1-Wire devices.

1-WIRE>(240) <–SEARCH ROM command macro
1WIRE ROM COMMAND: SEARCH (0xF0)
Found devices at:
Macro     1-WIRE address
1.0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B <–address
*DS2431 1K EEPROM <– type
2.0x2D 0xFE 0x8D 0×43 0×01 0×00 0×00 0×52
*DS2431 1K EEPROM
3.0x2D 0x2B 0xED 0xEF 0×00 0×00 0×00 0x7C
*DS2431 1K EEPROM
Found 0×03 devices.
The first 10 device IDs are available by MACRO, see (0).
1-WIRE>

The SEARCH ROM command reveals that there are 3 EEPROMs connected to the 1-Wire bus. The Bus Pirate stores the 64bit 1-wire addresses in macros so we don’t have to type it every time. We’ll work with the first device, identified by macro (1).

Writing to the DS2431 takes three steps:

• Write data to DS2431′s 8byte ‘scratch pad’ EEPROM buffer
• Verify the scratch pad contents and get the write access key
• Copy data from the scratch pad to the EEPROM for permanent storage.

Command 0x0f writes to the scratch pad. The scratch pad is an 8byte buffer that holds data prior to saving it permanently in the EEPROM.

1-WIRE>(85)(1) 0x0f 0×00 0×00 0 1 2 3 4 5 6 7 <–command
1WIRE BUS RESET OK
1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
1WIRE ADDRESS MACRO 1: 0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B
1WIRE WRITE: 0x0F <–write to scratch pad
1WIRE WRITE: 0×00 <–begin address byte 1
1WIRE WRITE: 0×00 <–begin address byte 2
1WIRE WRITE: 0×00 <–data
1WIRE WRITE: 0×01
1WIRE WRITE: 0×02
1WIRE WRITE: 0×03
1WIRE WRITE: 0×04
1WIRE WRITE: 0×05
1WIRE WRITE: 0×06
1WIRE WRITE: 0×07
1-WIRE>

The MATCH ROM macro, (85), isolates the the first device, (1). 0x0f is the command to write to the scratch pad, followed by the start address, 0 0. Finally, we send eight bytes of data to save in the scratch pad. The scratch pad is eight bytes long, and all eight bytes will be copied from the scratch pad to the EEPROM at once.

1-WIRE>(85)(1) 0xaa r:3 r:8 r:2 r:2 <–command
1WIRE BUS RESET OK
1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
1WIRE ADDRESS MACRO 1: 0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B
1WIRE WRITE: 0xAA <–read scratch pad
1WIRE BULK READ, 0×03 BYTES: <–access code
0×00 0×00 0×07
1WIRE BULK READ, 0×08 BYTES:<–verify our data
0×00 0×01 0×02 0×03 0×04 0×05 0×06 0×07
1WIRE BULK READ, 0×02 BYTES:<–inverse CRC
0×44 0×67
1WIRE BULK READ, 0×02 BYTES:<–all 1s from here
0xFF 0xFF
1-WIRE>

To copy data from the scratch pad to the EEPROM, we must first retrieve a three byte access code from the scratch pad with the command 0xaa.  The first three bytes are the access code (0×00 0×00 0×07), followed by the data contained in the scratch pad.

1-WIRE>(85)(1) 0×55 0×00 0×00 0×07
1WIRE BUS RESET OK
1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
1WIRE ADDRESS MACRO 1: 0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B
1WIRE WRITE: 0×55 <–copy to EEPROM command
1WIRE WRITE: 0×00<–access code (3 bytes)
1WIRE WRITE: 0×00
1WIRE WRITE: 0×07
1-WIRE>!!!! <–read bits
1WIRE READ BIT: 0
1WIRE READ BIT: 1 <–bits alternate, done
1WIRE READ BIT: 0
1WIRE READ BIT: 1
1-WIRE>

Command 0×55 with the correct access code will copy the scratch pad to the data EEPROM. Bit reads (!!!!) alternate between 0 and 1 when the copy completes.

1-WIRE>(85)(1) 0xf0 0×00 0×00 r:8 r:8
1WIRE BUS RESET OK
1WIRE WRITE ROM COMMAND: MATCH (0×55) *follow with 64bit address
1WIRE ADDRESS MACRO 1: 0x2D 0×54 0xD2 0xEF 0×00 0×00 0×00 0x2B
1WIRE WRITE: 0xF0 <–read memory
1WIRE WRITE: 0×00 <–start address (2 bytes)
1WIRE WRITE: 0×00
1WIRE BULK READ, 0×08 BYTES: <–read back data
0×00 0×01 0×02 0×03 0×04 0×05 0×06 0×07
1WIRE BULK READ, 0×08 BYTES: <–read beyond our data
0×00 0×00 0×00 0×00 0×00 0×00 0×00 0×00
1-WIRE>

Command 0xf0 followed by a two byte memory address (0×00 0×00) begins the data read process. The first eight bytes (r:8) are the values we wrote earlier. Reads don’t involve the scratch pad and don’t have an 8byte limit, so further reads continue to the end of the memory.

Don’t forget to catch up on any parts posts you may have missed.

We saw another interesting tool today: coreinfo is a library for the custom BIOS coreboot. Using it you can examine the memory directly without any damage.

The Q&A session at the end of [Jacob Appelbaum]‘s talk included a discussion of possible countermeasures. We’re convinced that this won’t be solved until there’s a fundamental change to RAM design. One of the interesting suggestions we heard was building a “RAM condom”. It would be a riser card that the RAM plugs into. When the case intrusion system triggered it would blank the RAM. It’s an interesting idea; anyone want to build it?

An article in EETimes suggests that we may see a memristor-based memory prototype in development as soon as 2009. The memristor is claimed by many to be the theorized fourth passive circuit element, linking the fundamental circuit variables of charge and flux. This news may not sound that exciting to most computer geeks, but this new component could usher in a new era of computer memory by forming the basis of RRAM (resistive random-access memory).

Scientists at HP labs have finally confirmed that the memristor behaves as their theories predicted. The reason that the component will work so well for memory is that the process is nonvolatile and the bits themselves will only change after the CPU tells them to. The bits in current DRAM systems slowly fade out and require a refreshment every 50 nanoseconds.

[via /.]