If you (the attacker) can get a shell on the device, usually it is trivial to SCP the filesystem contents out of the device. This shell might come from any of the traditional software or network vulnerabilities. It is also common for serial ports on the device to expose a login shell.
Standard software and network security countermeasures apply. In particular, try to disable debug ports in production firmware.
The bootloader is in a particularly weak position in an IoT device:
It is common for just the bootloader to be written to the device during manufacturing. The final firmware image is written to the device through the bootloader at a later stage. It is unusual that the bootloader is configured to disable console and Flash access after device programming is complete.
Conveniently for old folks like me, bootloaders usually still use RS232 serial ports for access. The old XModem/ZModem/Kermit protocols are often shipped and can be used to copy files off device Flash.
Countermeasures:
It’s extremely unlikely that you can remove these facilities altogether; they’re important for manufacturing. You can make small gains by making them difficult or inconvenient to use:
This is an unusual and difficult. Notably, this method was used to extract encryption keys from the original XBox (page 125). Many of the same countermeasures apply:
I have never encountered an IoT device which did not give me a useful firmware image once its main Flash was removed and dumped. There must be someone shipping a device with encrypted Flash; please get in contact with me if you find one!
Some devices ship with an SD card as their boot media. The solution here is obvious: remove the card and dump it using a regular computer. Once, I had to get the soldering iron out as the device didn’t use a socket. That’s as tough as it gets.
(I enjoy the irony that an 8-bit CPU can boot from an SD card that contains a 32-bit CPU – and that this is the most cost-effective way to do things in some applications.)
Most devices will use a soldered-on Flash device. There are a few common variations:
Many designs will allow the Flash chip to be read while still on the PCB. This is great for the attacker; less risk of damage to the device and less work. For a serial Flash device, this is achieved by lifting the TX/RX/MISO/MOSI lines and connecting them to an off-the-shelf device programmer. You can do the same with a parallel part, but it’s usually easiest to just remove the whole chip and put it in a socket.
Another option is to solder to the exposed Flash pins and disable the main CPU – either by holding it in reset or disabling the clocks.
Removing a Flash chip is easy. The exact method varies depending on the board, but the simplest thing for most devices is to heat it with a hot air rework station and lift the chip off the board with tweezers. Higher density boards make this more challenging. Sometimes as an attacker you don’t care about destroying the host PCB – anything you learn from one device will be applicable to another anyway.
By far the best countermeasure to physical Flash attacks is to encrypt the firmware and use a trusted boot facility. Then, an attacker has nothing of value to extract from the Flash. Even without trusted boot, encrypted firmware is a lot better than nothing.
Failing that, you’re limited to physical controls:
Xilinx FPGAs have an interesting solution to this. Their firmware (bitstream) is stored encrypted in an external Flash chip. The decryption keys are stored in write-only SRAM within the FPGA package. An external battery keeps the key storage SRAM alive. The keys never need to leave the chip.
There are obvious downsides to this – a battery is expensive and large – but if you’re using an FPGA already, cost, space and power consumption are probably not big constraints.
If you’re looking at a small device (usually 8-bit), it’s likely that the CPU, RAM and Flash are integrated onto the same die.
These parts all have code locks that prevent the program Flash from being read externally. There are plenty of examples of people defeating those locks. Many of these attacks require the microcontroller to be removed and the package melted off. This is beyond the ability of most at-home attackers.
