Least Significant Bits

My apologies for having let things rot for two months. Since the last post, I have become a rabid cell phone and embedded device hacker. It's refreshing to see software run in your hand, rather than in a big noisy rack somewhere.

This isn't renouncing my complaints about cell phones -- I still stand behind every one.

So, where to begin? The first device that I had the chance to spend some time with was a Motorola V3 RAZR. This is an excellent design specimen, with an aluminum body that is a mere 13.9mm thick when closed and two beautiful LCD screens. The V3 is also almost pheromonal. It literally calls out, on behalf of its owner to all nearby members of the opposite sex, "I'm hot, you want me!" Well... Didn't work for me, but some of us are hopeless. :-)

On the down side, the keypad is compromised by its thinness. It may take time to get used to, but I found it very difficult to use for most tasks other than entering phone numbers. Forget fast games, the directional buttons incur some latency. Trying to type text messages was difficult as well.

Inside the V3, one can find a so-called Neptune ASIC with an ARM processor core. This is the main processor of the device -- it drives the LCD screen and controls all of the other peripherals. All of the native ARM code for the V3 is packed into a single monolithic executable, including the so-called Synergy operating system kernel and all of the applications. This is what one might call a Manufacturer's Special operating system. It doesn't stack up well to a real handheld device operating system like Palm OS, Symbian, Windows CE, or Linux. Other companies do this too, and if they don't mention an OS by name in the data sheet for a device, rest assured that it runs a Manufacturer's Special.

Software can be written for the V3 in the form of Java midlets. The V3's firmware contains a JVM from Aplix and supports the slightly dated CLDC/1.0 standard. It generally works, but has shortcomings. The V3 has many bells and whistles: a camera, a mini filesystem, bluetooth, PIM functions, etc., but none of these features can be accessed by a Java program because their JVM doesn't support the appropriate APIs. For example, the hardware should be sufficient to run camera applications like The vOICe midlet, but the JVM inhibits this. Actually, that isn't the whole story -- the V3 supports filesystem access, but the API is kept secret. Their JVM also gets abysmal JBenchmark scores, and can't multi-task or allow midlets to run in the background.

Some of the JVM problems might be fixed in the future with new firmware. Their SDK claims that JVMs for similar future devices, including the so-called V3i, will support a good number of the missing APIs, but this may or may not be backported to work with current V3 models.

On the topic of firmware upgrades, Motorola has chosen to make this process unpleasant for unaffiliated hackers. Motorola internally develops a software suite called Product Support Tools, or PST, which is used to apply firmware updates and edit otherwise hidden configuration details on their phones. They distribute PST to cell service providers and authorized service centers, and supposedly include heavy-duty copy protection measures.

Copyright protections apply to PST, as well as any firmware that might exist on a phone. Forum sites will actively remove links to PST that anyone might post, and HowardForums even has rules against asking specifically where to find PST. On the other hand, there seems to be widespread perception that copyright protection does not apply to, or is unenforceable on firmware update files. Perhaps because they are only useful when flashed to phones that are implicitly licensed to use them? Shaky reasoning, but this individual seems to buy it, by very publicly distributing leaked, derivative, and questionably infringing copies of their V3 firmware.

The Java shortcomings might also be more acceptable if the firmware were a bit more open to adding native applications, but here the story gets worse. Being a Manufacturer's Special operating system, there aren't any public APIs to begin with, and trying to write applications would require much of the operating system to be reverse engineered. Anyone brave enough to attempt this would quickly find out about their anti-tampering measures. The Neptune's ROM code supposedly contains an RSA public key, not unlike the XBOX. Parts of Motorola's firmware that contain native code are signed with the corresponding private key, and unauthorized firmware is rejected at boot time. Short of finding a security hole in the native code, silly Java midlets are the only option for programming.

For a hacker, this is unacceptable.

The second device I have tinkered with is a Motorola A780. This is a bulkier and less sexy device than the V3 -- it's 10mm thicker and 35g more massive. However, it's more of a PDA, with a feature set comparable with a Treo or Pocket PC, but much smaller and less massive than any of those devices.

So far, neither the A780 nor any of its cousins have been marketed in the U.S., let alone supported by any of the service providers. The A780 can only be purchased from importers, and will be a lot more expensive than a phone purchased from a domestic service provider, but will also be free of subsidy locking and other nonsense. As by design, an A780 bearing a Cingular or T-Mobile SIM card works flawlessly.

Some A780s sold in Europe have GPS built-in. Such models include a special version of ALK CoPilot navigation software, and support programmatic access to the location data. This would be a really nifty feature, but was not present on the device I tinkered with.

The A780, along with its cousins, the E680/E680i/A760/A768/A728 are what Motorola refers to as their EZX architecture. These devices have an Intel Xscale PXA270 processor to perform PDA functions, along with a Neptune ASIC dedicated to the GSM phone functions. EZX devices all run some derivative of MontaVista Linux, with a slightly munged Qt/Embedded UI library. All EZX software, with the exception of the kernel, is commercially licensed and closed-source.

In total, the A780 has 96MB of flash. After the operating system and built-in apps, there is between 40MB and 52MB of reusable flash memory. The flash can be expanded with a hard-to-find and size limited Transflash card. The A780 also has 48MB of SDRAM, which is more than some of my parents' laptops. The large RAM seems to be required because (1) the environment and applications are bloated, and (2) Motorola did not manage to take advantage of MontaVista's execute-in-place feature, or chose against it. The major filesystems are cramfs, and the RAM is effectively used as a cache of decompressed pages.

The Java implementation on the A780 is first class. It supports many APIs, probably more than any device produced by Nokia or Siemens. It supports the rare and desirable JSR-184 3D graphics API, and JSR-179 GPS/location API on GPS-equipped A780s. It scores extremely well in JBenchmark. Sadly, it doesn't support the bluetooth API, and there are a few other minor shortcomings, but overall the JVM is great. It's so great that the majority of problems seem to come from midlets anticipating smaller screens and keypads, and failing to take advantage of the touch screen.

Despite having the rich and well-documented Linux and Qt/Embedded APIs at their disposal, Motorola chooses to officially support only Java programmability for the A780. They even left an application installer around for installing native code, which can be used by third parties, but it's all completely undocumented. I spent a few weeks trying to create a native A780 GUI application. I produced a proof-of-concept native application called USBMode, but after an excessive amount of reverse-engineering.

The best resource for this type of phone, if you can read Chinese, is CCMOVE. The second best resource is MotorolaFans.com. OSNews also has a review of the E680i, which effectively runs the same software as the A780.

There is an OpenEZX project to try to create a fully open-source software stack for Linux side of the A780. They have a big task ahead of them. Replacing the kernel is a daunting enough task, as will be creating a phone application for OPIE or GPE. If they still weren't out of problems, they will also need to find a legally sound method of installing their software, i.e. without PST and without any RAM download programs owned by Motorola.

Congratulations! Most people would have given up after reading the first paragraph, muttering "It's just a phone!" There are a lot of details that were condensed or just left out.

 Filed Under:

• Diary
• Hardware

• Login to post comments