3

I am on the hook to collect some of legacy firmware images from real-world embedded devices. Before digging into it, I am trying to confirm some high-level points.

Is it in general possible to gather firmware images from legacy embedded devices? I can come up with some hurdles here:

  1. I am aware that many embedded devices disable the debug port.
  2. embedded system have the so-called "Code Readout Protection" mechanism to prevent users from downloading the firmware

However, I am also aware the following facts:

  1. Firmware could be extracted from embedded devices by abusing busybox, for instance its wget command. Something like: Limited BusyBox shell

  2. The "code readout protection" could be bypassed, so as the "debug port" issue.

So I am wondering if someone can really picture the landscape here, is it generally considered easy or not to extract legacy firmwares from embedded devices? What is the common procedure and best practice? Thanks.

  • 1
    The scope of this question is far too broad. – julian Oct 2 '18 at 2:30
  • 1
    @lllllllllllll: I strongly suggest you edit your question to be a little better scoped. This will maybe even prompt NirIzr to give an even better answer, even though the one he gave is already as comprehensive as it gets, given the detail you provide. So unless you find someone who has worked on the exact target you're trying to reverse, this will be as good as it gets without more details provided by you. – 0xC0000022L Oct 2 '18 at 8:16
  • 1
    Although I agree this is a very general question, I do think it may be useful for future readers. I'm not sure OPs intention was to get an answer for a single specific device. – NirIzr Oct 2 '18 at 10:15
  • @NirIzr no worries, wasn't going to close or delete it. And I agree it's going to be useful for future internauts. – 0xC0000022L Oct 2 '18 at 11:05
4
+200

As this question is quite general, it'll be difficult to provide a very technical answer.

You've asked quite a few questions here, so please let me start with a general overview and then proceed to answer all of your specific questions.

General overview

The difficulty of pulling firmware images from an embedded device really depends on the firmware device itself, and the access you have to that firmware device.

I would say there are a few different alternatives depending on your actual goal (just getting as many firmwares as possible verses getting firmwares for specific devices you're in possession of or interested in, for example). I'll list the general options in ascending difficulty:

Getting a firmware image/update online

Since a lot of devices support some kind of firmware update mechanisms, firmware images are often made available by the manufacturer either via a manual web page download for manual update or via a web service that will serve over-the-air updates. Although those updates may sometimes be encrypted, in most cases they are just signed - because the actual threat landscape is modifying a firmware and not reading it.

As the format of a firmware update may be more complex to understand than a raw dd dump, for example, you'll need to spend extra efforts in understanding the format, extracting the firmware asset(s) from the firmware update file and optionally implementing some firmware-loading logic to get the in-memory image / addressing available. Tools like binwalk are a decent starting point.

If firmware is only available over-the-air, you'll also need to spend time understanding the over-the-air protocol and any server side limitations on serving assets. A server may refuse offering an old version you're particularly interested in or require some kind of a per-device identification/authentication.

Using an application info-leak vulnerability

The simplest example that comes to mind is information disclosure vulnerabilities in web applications that often exist on many embedded devices, however there may be other relevant targets. Unlike native information disclosure vulnerabilities where often pointers, addresses and memory data may be leaked, web information disclosure vulnerabilities often expose files and stored data. This may either allow you to pull other relevant information (for example, probing for hardware devices/interfaces) or even access to the firmware if it is either stored on the same storage or mounted (all the time or when an update runs).

Reading a firmware by software when shell access is available

Shell or root access may be available to you without looking at the firmware because of a known vulnerability or one that is easy enough to discover without actually reading any code. A device may also offer some kind of terminal access for debugging purposes. Instead of a full-blown terminal, one can have the ability to just execute a single shell command using command injections, for example.

Once you have access, this is mostly a matter of probing for any available assets and recovering whatever you can.

Reading a firmware by hardware when physical access if available

As this can often be the most challenging way of extracting firmware images, you may occasionally be lucky to the point that this approach can be as easy as pulling a SD card and plugging it into a computer. This isn't often the case, though. Since this specific topic is quite huge and you seem to be looking for an overview, I will not dive deep into the specifics.

When physical access to a device is available and any debug ports, uarts, or serial ports are available, you may often find them very useful for extracting details about the firmware. Some of those features may also be available through an ethernet port. These debugging interfaces often provide raw access to different components, such as the storage or controlling the boot sequence.

Although sometimes identifying such a port can be easy thanks to exposed unconnected pinheads and existing pin label printouts depicted below:

pinheads pin labels

Unmounted pinheads on the left, pin labels on the right. Click to enlarge

The different debug ports could also be harder to recognize when no labels are printed and there are no pinheads connected. A walk-through example for identifying both exposed and hidden debug ports is available here.

When debug ports are insufficient, the next step further is directly reading the firmware from the storage chip. This often includes either taking it out of the board and using your own electronic circuit to read memory out of the chip or hooking to the chip while it's still connected to the original board but either passively listening to data as it's read by the device or issuing your own read instructions. You'll first need to identify the circle components and their purpose, and manufacturer datasheets. This will obviously also require dedicated hardware. Generic boards exist for that purpose (some specifically for firmware extraction and hardware reverse engineering like GoodFET and BusPirate) and you can also get some development equipment from chip manufacturers that use proprietary In Circuit Serial Programming, if they'll be willing to sell those to you.

You can go even as far as reading the data directly from the chip using electrical and optical analysis of the chips' die layers, but that seems unlikely for your case.

Answering your specific questions

Is it in general possible to gather firmware images from legacy embedded devices?

As mentioned earlier, this greatly depends on the specific device and how protected it may be. It tends to be doable for most cheap devices but as a device becomes more expensive you can assume it'll be more complex and indirectly incur more difficulties.

It is also important to note that excluding the really expensive and/or often targeted devices (smartphones is a good example of those), most difficulties will not come from a manufacturer actively trying to make firmware extraction harder, but will more often come from design decisions and product choices and just happen to impact the difficulty of extracting a firmware image.

  1. I am aware that many embedded devices disable the debug port

Although this can sometimes be the case for either increased security or to reduce costs, removing a debug port completely makes repairs and QA more difficulties. Often, although the debug port may to be included a convenient pinout may be laid out for easy access, either heads for easy access or without as seen in the following picture:

output pins without a head soldiered on them

Picture taken from this step by step hardware reverse engineering tutorial

  1. embedded system have the so-called "Code Readout Protection" mechanism to prevent users from downloading the firmware

The cheaper devices will generally not bother with code readout protection, and there are some ways to bypass it although those tend to be relatively difficult and specific. One such method is to remove the storage chip and interact with it directly to extract the firmware image, as I previously mentioned in Reading a firmware by hardware when physical access if available.

  1. Firmware could be extracted from embedded devices by abusing busybox, for instance its wget command. Something like: Limited BusyBox shell

This approach is an example of what I've discussed under Reading a firmware by software when shell access is available above. In the example you linked, wget is used to exfiltrate the data after you get it, but there's no limit to the creativity of that (one can even go as far as use available LEDs to encode binary data).

  1. The "code readout protection" could be bypassed, so as the "debug port" issue

Yes, through slightly more advanced hardware reverse engineering tools and abilities it is possible to extract software from chips that have readout protection, use a device port although it isn't mounted, avoid the need of a debug port, using the chip's datasheet to recognize how to properly read the data out, snarfing it while it's being read by the existing circuit, etc...

is it generally considered easy or not to extract legacy firmwares from embedded devices? What is the common procedure and best practice?

As shown by this post, and repeated several times, this can be relatively easy or relatively difficult, depending on specific case. Common procedures also vary heavily.

Further reading

The topic of hardware reverse engineering is big an wide, and it is hard to cover it all in an SO post. You should spend more time reading, watching talks and following walkthroughs to gain more knowledge on the subject. Here are a few resources:

  1. A survey of The State-of-the-Art in IC Reverse Engineering
  2. Keep your tentacles off my bus and other talks by Dmitry Nedospasov.
  3. This hardcore example of firmware extraction by decapping by Travis Goodspeed.
  4. This introductory level, five part hardware/firmware reverse engineering walkthrough.
  5. A presentation about practical extraction using a Null dereference bug.

and many other resources available online.

  • Fantastic answer! I appreciate it a lot. I will read your answer in details and leave more comments later. Take care! – lllllllllllll Oct 2 '18 at 13:06
  • Thanks again for your detailed information. Just another (quick?) question, I am always assuming that firmware (over-the-air) update is a rare case, which can only be handled by experts. Hence many firmware images that can be extracted from the real-world device is a bit "out-dated". To get the newest firmware, you probably have to crawl online. Does that make sense to you? – lllllllllllll Oct 2 '18 at 14:56
  • Yes. For a lot of the devices that don't have over the air updates users will have to update manually. – NirIzr Oct 2 '18 at 14:59
  • Yes, I see. But on the other hand users probably need some advanced skills to update, or they basically do not have the motivation to do that. So I guess the argument holds to see that "many firmware in real-world embedded devices" are kinda outdated. So we will need to go for their web page to get the newest version. – lllllllllllll Oct 2 '18 at 15:00
  • Yep. Definitely. Users don't bother doing all that – NirIzr Oct 2 '18 at 15:03

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.