Completely Owning The Dreamcast Add-on You Never Had

July 17, 2017 by Elliot Williams 30 Comments

If you’ve got a SEGA Dreamcast kicking around in a closet somewhere, and you still have the underutilized add-on Visual Memory Unit (VMU), you’re in for a treat today. If not, but you enjoy incredibly detailed hacks into the depths of slightly aged silicon, you’ll be even more excited. Because [Dmitry Grinberg] has a VMU hack that will awe you with its completeness. With all the bits in place, the hacking tally is a new MAME emulator, an IDA plugin, a never-before ROM dump, and an emulator for an ARM chip that doesn’t exist, running Flappy Bird. All in a month’s work!

The VMU was a Dreamcast add-on that primarily stored game data in its flash memory, but it also had a small LCD display, a D-pad, and inter-VMU communications functions. It also had room for a standalone game which could interact with the main Dreamcast games in limited ways. [Dmitry] wanted to see what else he could do with it. Basically everything.

We can’t do this hack justice in a short write-up, but the outline is that he starts out with the datasheet for the VMU’s CPU, and goes looking for interesting instructions. Then he started reverse engineering the ROM that comes with the SDK, which was only trivially obfuscated. Along the way, he wrote his own IDA plugin for the chip. Discovery of two ROP gadgets allowed him to dump the ROM to flash, where it could be easily read out. Those of you in the VMU community will appreciate the first-ever ROM dump.

On to doing something useful with the device! [Dmitry]’s definition of useful is to have it emulate a modern CPU so that it’s a lot easier to program for. Of course, nobody writes an emulator for modern hardware directly on obsolete hardware — you emulate the obsolete hardware on your laptop to get a debug environment first. So [Dmitry] ported the emulator for the VMU’s CPU that he found in MAME from C++ to C (for reasons that we understand) and customized it for the VMU’s hardware.

Within the emulated VMU, [Dmitry] then wrote the ARM Cortex emulator that it would soon run. But what ARM Cortex to emulate? The Cortex-M0 would have been good enough, but it lacked some instructions that [Dmitry] liked, so he ended up writing an emulator of the not-available-in-silicon Cortex-M23, which had the features he wanted. Load up the Cortex emulator in the VMU, and you can write games for it in C. [Dmitry] provides two demos, naturally: a Mandlebrot set grapher, and Flappy Bird.

Amazed? Yeah, we were as well. But then this is the same guy emulated an ARM chip on the AVR architecture, just to run Linux on an ATMega1284p.

Seeking Treachery In A Questionably Sourced Phone

September 26, 2016 by Mike Szczys 24 Comments

Have you ever considered sourcing an off-brand phone from the China markets? Why, or what stopped you? The answer is data and identity. You are trusting both when you decide to use a smartphone. Let’s face it, smartphones are a personality prosthesis in our society. They know your physical location, what your interests are, the people you hang out with, and how you spend your money. The keys to the castle are shared with these devices and you shouldn’t grant that kind of trust without knowing your phone is worthy of it.

But… what if that phone has amazing features at an equally amazing price? [ijsf] bought the phone and then made it earn the proper level of trust. The model in question is a Blackview BV6000s — pictured above in a tub of soapy water proving it’s IP68 claim. This thing has flagship specs but not a flagship name so [ijsf] took [Dave Jones’] advice and took it apart instead of turning it on. In this case, it is a complete ROM dump and disassembly.

The goals was to find malware — anything that is potentially leaking data. Nothing was found, which we think is because this phone isn’t nearly shady enough. We’d expect the bargain basement models (like this $3 ~~wonder~~ vaporware) to be more in line. That one actually has a carrier behind it which means they plan to recoup on usage charges. But suspiciously cheap phones may be using a business model that makes it back by stealing a chunk of your identity.

Two good things come out of [ijsf’s] writeup. First, it’s a decent guide to dumping and snooping in a ROM. Second, in addition to the fruitless search for thieving apps, the annoying bloatware was removed for a cleaner ‘stock’ image.

D-Link Fails At Strings

April 14, 2015 by Eric Evenchick 32 Comments

Small Office and Home Office (SOHO) wireless routers have terrible security. That’s nothing new. But it is somewhat sad that manufacturers just keep repurposing the same broken firmware. Case in point: D-Link’s new DIR-890L, which looks like a turtled hexapod. [Craig] looked behind the odd case and grabbed the latest firmware for this device from D-Link’s website. Then he found a serious vulnerability.

The usual process was applied to the firmware image. Extract it, run binwalk to find the various contents of the firmware image, and then extract the root filesystem. This contains all the code that runs the router’s various services.

The CGI scripts are an obvious place to poke for issues. [Colin] disassembled the single executable that handles all CGI requests and started looking at the code that handles Home Network Administration Protocol (HNAP) requests. The first find was that system commands were being built using HNAP data. The data wasn’t being sanitized, so all that was needed was a way to bypass authentication.

This is where D-Link made a major error. They wanted to allow one specific URL to not require authentication. Seems simple, compare string A to string B and ensure they match. But they used the strstr function. This will return true if string A contains string B. Oops.

So authentication can be bypassed, telnetd can be started, and voila: a root shell on D-Link’s most pyramid-shaped router. Oh, and you can’t disable HNAP. May we suggest OpenWrt or dd-wrt?

Playing StarCraft On An ARM

July 31, 2014 by Brian Benchoff 25 Comments

Starcraft

Except for the really terrible Nintendo 64 port, StarCraft has always been bound to desktop and laptop PCs. Blizzard could take the code for StarCraft, port it to an ARM platform, put a version on the Google Play an iTunes store, and sit there while the cash rolls in. This would mean a ton of developer time, though, and potentially years tracking down hard to find bugs.

Or one random dude on the Internet could port StarCraft to an ARM platform. Yes, this means all the zerg rushes and dark templar ambushes you could possibly want are available for tablets and Raspberry Pis.

This godlike demonstration of compiler wizardry is a months-long project of [notaz] over on the OpenPandora team. Without the source for StarCraft, [notaz] was forced to disassemble the Win32 version of the game, convert the disassembly to C with some custom tools, and recompile it for ARM while linking in all the necessary Win32 API calls from the ARM port of Wine. Saying this was not easy is an understatement.

If you have an OpenPandora and want to relive your heady days of youth, you can grab everything you need here. For anyone without an OpenPandora that wants to play StarCraft on a Raspi, you might want to get working on your own recompiled port. Video below.

Continue reading “Playing StarCraft On An ARM” →

Microcorruption Embedded CTF

January 18, 2014 by Eric Evenchick 14 Comments

The folks at Matasano Security and Square have teamed up to build an online capture the flag (CTF) competition. The Microcorruption CTF focuses on embedded security and challenges players to reverse engineer a fictional “Lockitall LockIT Pro” lock system.

Each level places you in a debugging environment with a disassembly listing, live memory view, register view, and debugging console. You can set breakpoints, step through code, and modify registers like in a real debugging environment. Your goal is to figure out how to bypass the lock to collect bearer bonds.

While the device and motive may be fictional, the assembly is actual MSP430 code. The debugger is similar to GDB connected to a remote target using OpenOCD. There’s even a manual (PDF) to help you get up to speed with writing MSP430 code for the device.

This CTF looks like a great introduction to embedded security, and doesn’t require buying real hardware. It even includes a full tutorial to get you started.

Reverse Engineering Old PDA Software

March 13, 2012 by Mike Szczys 13 Comments

[Troy Wright] acquired a lot of twenty broken Dell Axim PDAs. This type hardware was quite popular a decade ago, but looks archaic when compared to a modern cell phone. That’s why he was able to get them for a song. After a bit of work he managed to resurrect eight of the units, but was dismayed to find there’s no published method for controlling the back light from software. For some reason this is a deal-breaker for his project. But he knew it was possible because there are some apps for the device which are able to set the back light level. So he found out how to do it by reverse engineering the software.

The trick is to get a hold of the code. Since it’s not open source [Troy] used IDA, a graphical disassember and debug suite. He had some idea of what he was hunting for as the Windows CE developer documentation does mention a way to directly control the graphical hardware independently from the display driver. A few hours of pawing through assembly language, setting break points, and testing eventually led him to the solution.

Hacking A Hack: Disassembly And Sniffing Of IM-ME Binary

November 2, 2010 by Mike Szczys 9 Comments

It’s fun to pick apart code, but it gets more difficult when you’re talking about binaries. [Joby Taffey] opened up the secrets to one of [Travis Goodspeed’s] hacks by disassembling and sniffing the data from a Zombie Gotcha game binary.

We looked in on [Travis’] work yesterday at creating a game using sprites on the IM-ME. He challenged readers to extract the 1-bit sprites from an iHex binary and that’s what got [Joby] started. He first tried to sniff the LCD data traces using a Bus Pirate but soon found the clock signal was much too fast for the device to reliably capture the signals. After looking into available source code from other IM-ME hacks [Joby] found how the SPI baud rate is set, then went to work searching for that in a disassembly of [Travis’] binary. Once found, he worked through the math necessary to slow down communication from 2.7 Mbit/s to 2400 bps and altered the binary data to match that change. This slower speed is more amenable to the Bus Pirate’s capabilities and allowed him to dump the sprite data as it was sent to the LCD screen.

[Thanks Travis]