In this demo, we'll assume that we don't have command line access to the router.
Instead,
we'll extract the firmware direct from flash memory using the
CH341A programmer and flashrom utility.
We'll verify what we've captured using Binwalk.
The setup for this demo is pretty straightforward.
I've used a SOIC clip to connect the CH341A to the flash chip on the router.
However, these can be temperamental.
They often slip off and you have to make sure
they're in just the right position.
The main thing to note is that wire 1 of the SOIC clip, shown here in
red, is connected to Pin 1 on the flash chip, which is located next
to the dot located on top of the chip.
The pins are labeled from 1 to 4 down the left‑hand side and then 5
at the bottom right up to 8 at the top right.
If you choose to connect hook clips, instead of SOIC clip, you
only need to hook up the pins that are needed for SPI
communication, namely 1, 2, 4, 5, and 6.
You'll need to check the data sheet for the device you're
testing to confirm the correct pin outs.
However,
be sure not to connect the power supply to VCC as
this may start the boot process.
Once we're all connected up, we can switch to our lab environment.
We call the flashrom utility with the word flashrom and
specify the type of programmer we're using.
In this case, we're using a generic CH341A, but there are more
than 3 dozen supported programmers. Among the most popular are
the Bus Pirate and the Raspberry Pi.
The ‑r option instructs flashrom to read from the connected memory
device and save the output to the specified file name,
which in this case, is TL‑WR841N_firmware.bin. Flashrom
runs in user space and usually requires super user
privileges, but as you can see here, we're able to run it as a regular user.
That's because we're using a supported USB device as the
programmer. If you switch to a different programmer,
you may need to run flashrom with sudo. Flashrom very quickly
identifies that we have a 4MB EN25QH32 Eon flash chip and that
memory is being read using SPI.
It takes a total of 34 seconds to read the entire contents of the flash
chip. Let's verify the dumped firmware using Binwalk.
We've already discussed Binwalk so I won't go over it again,
but it's a fast easy‑to‑use tool for analyzing reverse
engineering and extracting firmware images.
So as soon as I think I've grabbed some firmware, I use it to verify the image.
It'll very quickly tell us if the images are corrupted or if
we've got something wrong. Simply calling Binwalk followed by
the firmware image name very quickly shows that we have an image
with a U‑Boot bootloader,
some LZMA compressed data, and a Squashfs filesystem. It looks good to me.