[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!
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.
[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.
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.
Continue reading “Parts: 32KB SPI SRAM memory (23K256)”
[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.