An uncertain future -

An uncertain future


From the puerile to the predatory, hacking has invaded embedded systems. Can we make the world safe for our devices?

In an increasingly connected world embedded systems programmers have to worry more about the security of their devices. Not only is the device design at risk from IP thieves but once it's connected to the Internet, the device could be exposed to all sorts of attacks from hackers.

In this piece we'll look at some tactics you can use to defend against reverse engineering. We'll also study the kind of attacks that happen specifically on embedded systems as opposed to desktop and server computers.

Securing a design
When designing a product, you'll need to protect its assets. Often the first asset to consider is the design itself. Can a competitor reverse engineer the design to steal some of your ideas for their own products? Can someone simply manufacture a replica and sell it under their own name? Can someone disassemble the code, change some of it, and produce a new ROM that will make the product work in unlicensed ways?

To combat reverse engineering, some companies remove markings from chips to make it harder for the curious. Swapping address lines or data lines going to the ROM means the hacker can't simply read and disassemble the code. However, hackers can easily figure out which lines were crossed by scoping the lines of the processor and the ROM.

A more secure approach uses on-chip program memory. Some PICmicro parts allow you to write to flash but prohibit the flash from being read externally. These parts also prevent the software from reading the flash, apart from the fetch cycle, which allows the code to execute. Determined hackers won't stop at probing the address lines—some will open the mask ROM chip packaging and use a microscope to read the on-chip code, which is visible since each one or zero is represented by the presence or lack of a transistor. On-chip SRAM provides greater protection, since the state of the SRAM isn't physically visible, and if the chip contains security fuses for tamper detection the built-in battery can be disconnected from the SRAM when the security fuse blows, losing all the code.

Other micros, such as the Dallas Semiconductor DS5240, decrypt all code and data on-chip, meaning the developer encrypts the code before it's stored in the ROM. Reading the ROM or monitoring the bus will only reveal the encrypted version of the code. As long as the key, which is stored in the microprocessor, is secure, there's no access to the decrypted version of the code outside of the chip.

The most extreme protective measure are likely to matter only when the data being manipulated by the system is far more valuable than the design. If you make it hard enough for someone to reverse engineer your design, they'll simply design a new product for the same cost. However, if your design handles transactions of large amounts of money, the hackers' reward for reverse engineering the system to enable manipulation and fraud may be worth many multiples of their design costs.

Contract manufacturing now more commonly happens on the far side of the world from where the design took place. Some countries with very cheap manufacturing costs also have very lax intellectual-property”protection laws. If you contract out the manufacture of 10,000 units, how do you know that the contractor didn't build 15,000 and keep the balance for sale on the black market or under a different name? A unique identifier for every product can give some level of protection. The design can incorporate a chip with a unique identifier, which we'll call the unit ID. This ID could be the Ethernet address if the board has one or you could use Intel's StrataFlash product, which supplies a unique 64-bit identifier on each flash chip.1

The process works like this: You construct an encrypted key that only works in conjunction with the unit ID. It's OK if the manufacturer knows the encrypted key, as long as he doesn't have the algorithm to produce an encrypted key from the unit ID. At the end of manufacture the manufacturer downloads this key to the product's EEPROM. The software will then only run if the key in EEPROM matches the unit ID. If you contract a company to build 10,000 units, you then issue 10,000 keys.

This scheme has weaknesses. For example, the circuit to the chip that contains the unique number could be modified to always return the same unit ID, and that would enable a hacker or manufacturer to built unlimited units with a single key. However the level of reverse engineering, and therefore cost, involved might make the exercise uneconomical. As with most security measures, although you might not make the system impenetrable, you hope to make it unprofitable to hack.

War stories
Viruses and worms are a scourge for conventional computers that are connected to the Internet. As more embedded systems use the Internet they'll become vulnerable to similar threats. You might think that embedded systems will be immune from attack because they're so different from the desktop machines and servers. As more embedded systems use sophisticated operating systems, however, they'll become vulnerable to the same threats as conventional computers.

In one case an electronic microscope installed in a university, running embedded Linux, was used to relay spam. The spammers used the sendmail configuration, which allowed mail relaying by default. This is a common fault that spam merchants exploit. When the group responsible for the microscope was contacted with complaints that they were a source of spam, they had no idea that the microscope was running sendmail. This example shows one of the biggest challenges of securing embedded systems. The customers are more diverse and don't see themselves as systems administrators—which is reasonable. Customers buying Internet-connected embedded devices won't want to suddenly take on responsibility for routinely downloading security patches and enforcing password policies.

While a microscope with embedded Linux might be a rarity, conventional operating systems are starting to appear in lots of popular devices—sooner or later a mainstream operating system is going to be connected to your TV, whether as part of the set-top box or a standalone box that records and plays video, music, and digital photographs. This market is so much larger than the PC market that it's bound to be a hugely popular target for hackers. If you thought Janet Jackson's Superbowl stunt was outrageous, you ain't seen nothin' yet. Imagine what might appear on prime-time TV if some teenager with a bad attitude has hacked your set-top box.

Set-top boxes are already a major target for hackers, but up until now it's been about hacking the boxes when the hacker already has physical access. A major attraction is getting free access to pay-TV channels. This has led to an intriguing battle of wits between the engineers at DirecTV and hackers who hack the smart cards used with DirecTV's set-top boxes.

A discussion on Slashdot debates how DirecTV didn't give enough attention to security mechanisms on its early smartcards.2 It was straightforward for hackers to produce counterfeit smartcards and sell them on the Web. As DirecTV updated its software, the hackers updated the cards to follow suit. A new generation of cards provided better security, but DirecTV continued to support the old cards as it moved legitimate customers on to the new generation. Once the vast majority of the remaining old-generation smart cards were hacked cards, DirecTV sent an update to the smart cards that set a flag in EEPROM that caused the card to go into an infinite loop soon after the card was powered. This effectively disabled the cards. Ambitious hackers with the right tools were able to overcome the problem, but most people who had bought hacked cards were now locked out.

The vast resources applied to hacking smartcards show how much the TV set-top box is seen as a lucrative challenge for hackers. Here's another example of a set-top box attack. In this case, hackers broke into Motorola cable modems to watch pay-TV for free and snoop on cable-modem traffic from nearby users.3 The hack enabled access to the shell of the VxWorks operating system that ran on the cable modem.

The hack, however, didn't represent a weakness in VxWorks or even the application built on top of it. These cable modems contain flash that can be updated by the cable company, and it's impossible to stop the hackers from updating the same flash with their own code. Once the hackers can use physical access to change the code, there's little you can do in software to prevent security mechanisms being bypassed.

The edge of the Internet
The population of embedded systems devices directly connected to the Internet isn't the only target for the imaginative hacker. Integration between a PC and an embedded systems device can leave loopholes that wouldn't exist on a traditional network. When the people at Palm designed their PC synchronization mechanism, they didn't add any validation that the Palm being synchronized with the computer was actually entitled to the information that it was receiving.4 It was thus possible to walk up to any password-protected NT or 2000 PC and place a brand-new Palm in the synchronization cradle and press the sync button. The Palm would then download all of the contacts, diary, and documents from the PC without verifying who was accessing the PC. Of course, if those details included children's names and birthdays, the data thief would now have a good starting point for guessing passwords. This type of trust between PC and embedded systems computer will be even more easily exploited as more devices use wireless links.

Illuminated roadside signs that warn traffic of accidents or roadwork are often programmed wirelessly. They're a favorite target of hackers, who change the traffic warning to some witty comment or obscenity to play to the passing audience.

The two-way intercoms used at the drive-through of many fast-food restaurants also work wirelessly. In at least one case, pranksters tuned into the same frequency and in response to their orders some customers were given answers like “You don't need two burgers; you're too fat!”5 Whether you consider such a prank funny or criminal, if you're designing the intercom system, you need to expect such attacks on your system.

Consider recent vulnerabilities found in Bluetooth-enabled phones, one of which allows a device to snoop the phonebook of a handset without the owner realizing it.6 While these vulnerabilities aren't weaknesses in the protocol itself, they're weaknesses in the products that use the protocol. Most of these phones are also Java capable. It's easy to imagine a virus in the future being delivered as a Java program via Bluetooth and spreading from phone to phone. As the owner of an infected phone wanders through a crowded train station he'll come in range of many other Bluetooth-enabled phones, spreading the virus via physical proximity—much closer to the behavior of a biological virus than anything we've dealt with on the Internet. A similar outbreak could occur on the freeway between cars, many of which use Bluetooth for cell phone integration or in-car diagnostics.

The sandbox approach to Java Virtual Machines on most phones and the diversity of phone models may make this threat remote for now, but the market will pressure cell phone manufacturers to make their devices more capable and more standardized. The soon-to-be-ratified optional Java Packages JSR 75 is one of a number of initiatives that will give Java more access to phone functions.7 Although desirable for legitimate application writers, these changes play into the hands of malware authors.

Another way the devices on the edge of the Internet will be targeted will be through the PC. The current crop of Internet-based worms and viruses make it straightforward to gain access to thousands, if not millions, of computers around the globe. Statistically, many of those computers will be regularly connected to phones, PDAs, MP3 players, X10 home automation networks, and other interesting gadgets. If you want to launch an attack against all MP3 players, the hardest part will be getting the disease to spread from one MP3 player to the next. A vector is the medical term for a body that carries a virus without suffering from the virus itself, such as mosquitoes carrying malaria. This biological distribution method can be simulated by spreading our MP3 virus on conventional computers in exactly the same way as current viruses, exploiting vulnerabilities in the operating system or e-mail programs. Once the virus is on a PC that's used to configure one of the targeted devices, the virus can communicate with the MP3 device. The next time the device is connected to the PC, the virus could change song titles, add rude noises to a music collection, erase the device, or generally cause trouble.

These attacks will only deliver their payload from a small percentage of the PCs they infect, since only a small percentage will have the appropriate connected device. This limited range won't put off the virus writers, however, because the effort to infect many computers is not much greater than the effort required to infect a few. Because most PCs won't suffer any effects of this type of attack, it will be more difficult to detect and therefore will likely spread further before detection.

From these examples you can see that designers of embedded systems won't be able to rely on third-party security products or on the security of the underlying operating system—the nature of the attacks is just too diverse. The embedded systems community has enjoyed the reputation for producing more reliable software than the desktop community. That could change dramatically if users find that their microwave oven can catch a virus.

In my last column (“Start Me Up,” April 2004, p.14), I mistakenly stated:

“When you forget to initialize a global value, the chances are you'll get a zero—though this isn't a certainty. The C standard dictates that any static values that aren't explicitly initialized in the code must be initialized to zero, but nonstatic values are undefined.”

This is not the case. All variables declared outside a function, whether the 'static' keyword is used or not, will be initialized to zero. Thanks to Victor Kamensky, Chris Knight, and Dave Sinkula for spotting this mistake.

Niall Murphy has been writing software for user interfaces and medical systems for 10 years. He is the author of Front Panel: Designing Software for Embedded User Interfaces . Murphy's training and consulting business is based in Galway, Ireland. He welcomes feedback and can be reached at . Reader feedback to this column can be found at .


  1. “Intel StrataFlash Memory (J3) Product Overview,” Intel web site:
  2. “DirecTV's Secret War On Hackers,” discussion:
  3. Poulsen, Kevin, “Cable modem hackers conquer the co-ax,” The Register, United Kingdom, Feb. 5, 2004:
  4. Rubin, Avi, “Windows NT/2000 'Lock Computer' allows palm sync,” posted on Risks Digest, ACM's Forum on Risks to the Public in Computers and Related Systems, Sept. 2000, Volume 21: Issue 4:
  5. Leyden, John, “Radio hackers hurl drive by abuse at Burger King customers,” The Register, United Kingdom, Jan. 12, 2004:
  6. Laurie, Adam, and Ben Laurie, “Bluetooth vulnerabilities,” A.L. Digital Ltd. press release, updated Feb. 13, 2004:
  7. “JSR-000075 PDA Optional Packages for the J2METM Platform,” Java Community Process:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.