Embedded Code Reuse

When examining embedded devices, it is not uncommon to find that two or more of them share common code, and even common hardware. This probably comes as no surprise, as re-using code and hardware designs helps lower production costs. What might be a little more surprising is when you find two devices from two different vendors that share the same code or hardware.

It’s important to be able to identify devices that use the same code or design. If you find a bug or vulnerability in one device, it’s likely that it affects other devices as well. Likewise, if you are having trouble reversing or analyzing a particular device, work that others have done on similar products can help put you on the right track.

In reality, a lot of vendors, particularly vendors that specialize in consumer grade products, do very little technical work. They are in the marketing and sales business and they farm out the technical work to third party companies that you’ve probably never heard of. For example, if you look at the JavaScript source of some Linksys products you’ll see copyright references to “CyberTAN  Inc.”, the Taiwanese company that wrote the firmware for Linksys.

Vendors will often use the same third-party company for more than one product. The firmware for the Linksys WRT160N router has references to CyberTAN, but there is also an icon file in the /etc directory called ‘wrt300n.small.ico’. If you look at the firmware for a WRT300N router you’ll find that it also has files that reference CyberTAN, indicating that the firmware for both these devices were at least partially developed by CyberTAN and likely share similar code.

Different vendors will often hire the same companies to develop their products, so it is not uncommon to find code shared between devices from different vendors. Some of the SSL VPNs from both Cisco and Netgear were developed by the same company, Cavium, and share very similar firmware.

Other devices are so similar that you can actually load the firmware from one vendor onto a device sold by a completely different vendor. The Trendnet TEW-632BRP and the D-Link DIR-615 revC1 routers both have the exact same hardware, and their firmware is in fact inter changeable. Further, the TEW-632 firmware has an icon image of a D-Link router, although the image is not that of a DIR-615 indicating that the company behind both these routers has re-used code for other devices as well.

There are other ways of identifying devices that were made by the same third-party company besides icons and copyright references. Take a look at the TEW-632BRP and DIR-615 boards:



Although not exactly the same, these two boards are almost identical, particularly the layout and circuitry around the CPU, flash, RAM, and network chips. Additionally, the TEW-632BRP board is labeled ‘21514632BRPA1A2’, while the DIR-615 board is labeled ‘21514DIR615C1A1’ and both boards are dated within few months of each other. Given the similarities in hardware, board design and board markings, these two devices were almost certainly developed by the same company, who simply made some slight modifications and sold them to two different vendors.

Tagged , . Bookmark the permalink.

10 Responses to Embedded Code Reuse

  1. illogique says:

    Interesting post. Although, you make a couple of assumptions which may not be accurate.

    When dealing with embedded hardware – especially in today’s cut-throat, high-volume, low-cost home consumer market, equipment manufacturers have to minimize their production costs. By doing so, they can maximize profits, or ensure that they can break-even on a device as quickly as possible.

    Certain silicon manufacturers actually come to the assistance of equipment manufacturers by providing reference designs. These designs show how to use a specific ASIC for an application. Most often, these reference designs will have board layouts, preferred support chip types (RAM, flash, ROM), and of course, a base software load.

    This type of business model encourages reuse/sharing, but also stifles innovation. A lot of products look and perform exactly the same. If the reference design is weak, so are the resulting products – especially if the equipment manufacturer does not want to put too much money into their product development phase.

  2. Craig says:

    illogique, thanks for the information, that’s something I didn’t consider. Either way there is code reuse though, which is usually what I’m trying to determine. Thanks!

  3. Dave says:

    That’s something I was going to point out as well, that many manufacturers simply clone the chipset vendor’s reference design as efficiently as possible, particularly in 1.0 releases. Later releases may have slight design tweaks, but usually only to lower component costs. The most obvious instance of this is in consumer video cards, where cards from different vendors can be almost identical if you ignore things like the colour of the circuit board and other minor details.

  4. vkw says:

    From the vendor side, code reuse saves tons of R&D cash, especially when you’re doing a family of related products (eg: WAP’s, Routers, etc…). So it’s expected, and almost guaranteed – both between a vendors product, and within vendors whom use various asian ODM’s. I’ve seen stuff that simply key’s off the product id/pn, and changes it’s personality from one device/vendor to another. I’ve even written code that does exactly that – you get 1 binary that’ll run on 2 or more devices – thus reducing your test + development cycles by a significant amount.

    Of course, you end up with the same bugs/security holes, but at least you only need to fix it once.

    illogique’s post about reference designs hold true from my experience on the vendor + hardware side of the house. While there are some crappy reference designs our there, most are ‘good enough’, so as a vendor you tweak what you need (normally additional IO or storage) and the rest remains the same. Once you’ve got a good stable of HW designs, everything else is usually just a variant. This is especially true for ODM’s.

  5. Craig says:

    Thanks for the additional input vkw. I hadn’t thought about binaries that may work/look different just based on the product id…that’s definitely something I’m going to have to start looking for!

    I definitely get the cost savings of code reuse, and that’s a good thing – especially if it means I can buy stuff cheaper. But looking at these systems from a security/hacking perspective, it’s always interesting to find the similarities in code and hardware.

  6. Dave says:

    >I definitely get the cost savings of code reuse,
    >and that’s a good thing – especially if it means
    >I can buy stuff cheaper.

    It goes beyond just lowering prices, you can sometimes get ongoing updates for EOL’d products by finding the common firmware for a newer device and loading that into your older discontinued one, thus obtaining bugfixes even after your HW has been EOLd (I’m thinking specifically of Zyxel here, but I’m sure others do it was well). Alternatively, you can get firmware updates from hardware manufacturer A that provides them when hardware manufacturer B doesn’t, or only provides ancient firmware (this time it’s LiteOn vs. Sony, you can upgrade Sony DVD drives with updated LiteOn firmware to replace the fossilised stuff Sony ships them with).

    The downside is that you have to know in advance what is and isn’t safe to use to avoid bricking your device. OTOH if you’re using an EOL’d piece of hardware that you’d have to replace otherwise, it’s not so bad…

  7. Fantastic site! I thoroughly enjoyed your content …very nicely written.

  8. RobinE says:

    Very, very interesting. My “project” is to have my Humax tuner/PVR UK Freesat model, assessable and accessing my NAS/LAN. As delivered it uses IP to implement access to the BBC iPlayer site, but otherwise can’t been “seen” on my LAN, and can’t access my NAS library. For the moment I have to copy media files to a USB stick and then store on my NAS at which point I can play it on my Popcorn Hour or Asus O!Play (or PCs). It features an internal HDD with EXT3 filesystem which I’ve demounted and copied. It’s running Linux of course. Why, oh why, do manufacturers “dribble out” these devices lacking obvious features (such as Samba access). I guess it helps keep the “revenue stream” flowing and bread on the table. So… I want to convert my Humax into the perfect media capture/player box which my wife might be able to use, rather than my PC based solutions which are deemed to be unusable by the female members of the family (who can blame them). The idea of a tutorial/class is interesting… I already have all(?) the electronics (and software know-how) require, but might be persuaded to divi-up some of my SocSec check for tuition.

  9. Pingback: Embedded Code Reuse | Linux-backtrack.com

  10. Lawrence says:

    I’ve seen this myself (re-use), and talked about it too over on my ipcam site.
    Its fun to reverse engineer stuff, and you do see the similarities in products.

    Luckily I learned to read / speak / write Chinese the last few years, so I can talk to the vendors directly (although they’re not always helpful!)

    Some of my reverse engineering stuff is on my blog here – http://www.computersolutions.cn/blog/tag/foscam/ (mostly camera firmware reverse engineering).

Leave a Reply

Your email address will not be published. Required fields are marked *