A few Blogs ago I wrote about risk taking and the engineering profession. Most of our engineering choices are not the stuff of life-and-death dramas. But there’s plenty of room for catastrophes.
In the dark ages of embedded development there were no standardized operating systems, no common code, and precious little memory to stuff the code and data into. But we’re now in the age of enlightenment. There’s plenty of cheap memory available in nearly every consumer product, tons of inexpensive libraries are readily available and operating systems are common in products from MP3 players to cell phones.
On the face of it, the change from the "old days" is for the better. Or is it?
Open source may be great for improving productivity but it’s horrible for product security. I know, some folks believe that more engineers working on code makes it more robust and hack proof. But that just isn’t so. The point of vulnerability simply changes. And the attractiveness of hacking a cell phone is just too much for bright, young engineering types to ignore.
For example, the A780 mobile is a quad-band GSM smartphone including an external keypad. Key features include EDGE high-speed data, large QVGA touchscreen, Linux OS, megapixel camera with video capture, Bluetooth, Java 2.0, MP3 player, TransFlash card slot, and wireless email and calendar sync. Just the product that gets your mouth watering with the thoughts of what can be done with it.
Enter the hackers. So what have they been able to do? They know the keycodes of every keypad and button/wheel on the device, they can control the touch screen, framebuffer. and the three different backlights. They know a lot about the architecture of the phone. The Xscale prcoessor (PXA270 Belverde) actually uses USB to talk to the Neptune chip. Neptune is a DSP with a synthesized ARM7TDMI on-chip. The PXA270 runs in host mode, the Neptune in device mode. They’ve discovered the debugging callbacks in the stock kernel. So by registering a simple kernel module with the usb rx/tx functions, they now have hexdumps of the usb traffic between those two chips (also called AP and BP).
Not very dangerous right? These hackers are just trying to expand the capabilities of the phone. But, it won't be long before a virus is written to attack the phone. Maybe the virus will play a raspberry noise on a specific date. But perhaps it will disable 911 calls, or create a bridge so others can listen to your call.
It's easy to dismiss the possibility of hacking a phone. But as engineers our job is to eliminate risk. Next time you're developing a consumer product think like a hacker – and plug the holes. At least it will complicate the hacking process.
Finding out the perceived frequency response of your combined headphone/ear 'system' and compensating for it using parametric equalization can offer some eye-opening benefits. But finding an EQ solution isn't always easy.