As discussed earlier,
firmware is a type of software that is scribed
directly into a piece of hardware.
It operates without going through APIs, the operating system, or device drivers.
It provides the instructions and guidance needed for the
device to communicate with other devices or to perform a
set of basic tasks and functions.
Obtaining firmware provides us with an opportunity to identify
vulnerabilities and weaknesses that can be exploited via traditional
attack vectors such as web interfaces and network protocols.
Firmware also stores device configuration and sensitive
information such as passwords and encryption keys.
An attacker will always follow the path of least resistance and we should too.
Why go to the effort of extracting ones and zeros from bare metal
when we can download the firmware from the internet.
But even before we get to that stage,
we should be sure that we actually need to obtain the software.
Spoiler alert.
In the demo we'll do shortly,
we'll see that we can get full root access to the
operating system without even trying.
Why do we need to obtain the firmware?
Assuming we can't get unfettered command line access through the serial console,
the next obvious place to look is the internet.
Manufacturers often make firmware updates available
online for users to download.
Sometimes these are just patches which are interesting in
themselves because they can reveal an undisclosed
vulnerability in a previous version,
but there is usually a rolled up version of the full
firmware made available periodically as well.
This next one is viable, but painful.
If we can interrupt the boot process and interact directly with the bootloader,
there may be bootloader commands we can execute to dump
the firmware from memory to screen.
We can then capture the output in a serial console log file.
But remember, data is transferred one bit at a time.
Let's do some quick math.
Let's assume we have a 128 MB flash memory chip.
When we dump firmware over serial, it's dumped as hexadecimal.
That means for every byte of memory, we dump three bytes,
two hex characters and a space.
Then we have to account for error correction,
which is 64 bytes for every 2 KB page, that gives us a 3% overhead.
So for a 128 MB flash memory chip, we actually dump about 400 MB.
Now, our serial transfer speed is 115,200 KBps or .011 Mbps,
which gives a total transfer time of nearly 10 hours,
but we're not done there,
we now have a file full of hexadecimal which we need to convert back to binary,
trimming out all the unnecessary strings in the file along the way.
This really is a method of last resort.
This next method is probably one of the easiest ways to
obtain firmware directly from a device.
We can connect the Ch341a programmer to the flash memory chip either with a
SOIC clip or hook clip test leads and run Flashrom or some other similar
program to extract the firmware direct from memory.
The final method is similar to the dumping of a serial method,
except this time, we're dumping over TFTP,
which is much quicker.
We, again, need to interrupt the boot process to access the bootloader.
We also need to spin up a TFTP server on a separate device and connect the
test device to the network in which the TFTP server resides.
There may need to be some reconfiguration of the network
interface to ensure both the TFTP server and the target
device reside in the same subnet.
This method relies on having TFTP available on the target device,
but it's quite common to find because it's often used for firmware updates.
We're doing the same, just backwards.
With the exception of downloading it from the internet because
I assume you already know how to do that,
we'll now run through some demos showing each of these techniques.
However,
it's worth noting that there are other ways of obtaining
firmware when these options don't work.
For example,
IoT devices will occasionally beacon out to an
update server to pull down an update.
When this happens or if you can trigger it,
then you may be able to sniff the update on the wire using tcpdump or Wireshark.