Please enable JavaScript.
Coggle requires JavaScript to display documents.
Analyzing and Exploiting Firmware, Reference - Coggle Diagram
Analyzing and Exploiting Firmware
Common goals to locate when analyzing firmware
Backdoor accounts
Configuration files
Vulnerable services
Source code
API endpoints (URLs)
Private keys
API tokens
How data is stored
Passwords
A. Methodology of firmware analysis and reverse engineering
Analyzing firmware
Additional
- identify whether a firmware
image is compressed or encrypted. Ex:
$ binwalk -e RT-N300_3.0.0.4_378_9317-g2f671ff.trx
Mounting filesystems
Extracting the filesystem
Most interested in the
filesystem
. We need to extract the filesystem from the firmware binary image
Auto extract
filesystem
Use
binwalk
:
$ binwalk -e [firmware-name]
Ex:
$ binwalk -t -vv -e RT-N300_3.0.0.4_378_9317-g2f671ff.trx
After the Binwalk execution, we can go to the directory with the name
_[firmwarename].extracted
, which will hold the entire filesystem
Extract
filesystem
manually
Use a tool such as
hexdump
and
grep
for the signatures
Ex: the
Squashfs
filesystem
grep
the
hexdump
output for
shsq
(which is the magic byte for any
Squashfs
filesystem) in
reverse order
:
$ hexdump -C RT-N300_3.0.0.4_378_9317-g2f671ff.trx | grep -i 'hsqs'
use the
dd
utility to dump contents starting from this location till the end:
$ dd if=RT-N300_3.0.0.4_378_9317-g2f671ff.trx bs=1 skip=925888 of=rt-n300-fs
1.5. Identify that the
Squashfs
filesystem begins from the
address
0x000e20c0
2.5. Have the
Squashfs
content in
rt-n300-fs
Run a utility such as
unsquashfs
to look at the entire filesystem:
$ unsquashfs rt-n300-fs
If firmware ZIP is password protected, we first need to crack the password with tool like
fcrackzip
. Ex:
$ fcrackzip -u -v -b firmware.zip
Analyzing filesystem contents
Manual
Look for all the configuration files:
$ find . -name '
.conf'*
Then look at each config file, which end in the
cfg
extension, or outdated and vulnerable versions of common binaries with public advisories, to find credentials or sensitive information. Look for any files called
passwd
or
shadow
Look at versions of various libraries and components to find outdated one with vulnerabilities
Auto
Use
Firmwalker
to identify some of the common sensitive information. Could clone firmwalker script from git.
Ex:
./firmwalker.sh ~/lab/firmware/dlink/r2/v2/_2K-mdm-image-mdm9625.yaffs2.extracted/yaffs-root
Firmwalker
identifies additional binary files, certificates, IP addresses, private keys, etc., and saves the output in
firmwalker.txt
In some case, we also need to
reverse engineer
ARM and MIPS-based binaries to understand them more and identify vulnerabilities
On a
deeper level
,
firmware diffing techniques
helps compare one firmware with its previous version.
Obtaining firmware
Googling/researching
Google Docking
Leverage the
Google Hacking Database
to search for firmware or devices via the link
https://www.exploit-db.com/google-hacking-database
(dorking requestes)
Search Google for binary file extensions hosted on file-sharing platforms, such as
MediaFire, Dropbox, Microsoft OneDrive, Google Drive, or Amazon Drive
Ex search:
intitle:"Netgear" intext:"Firmware Download"
Find
exposed cloud storage locations
Search
Amazon S3 buckets
could find the firmware in a vendor’s unprotected bucket
The
S3Scanner tool
can enumerate a vendor’s Amazon S3 buckets
Ex:
$ python3 s3scanner.py vendor_potential_buckets.txt
Can create your own similar custom file and provide vendor names followed by popular
suffixes
for S3 buckets, such as
-dev, -development, -live, -staging, and -prod
Decompiling associated mobile apps (application analysis approach)
Might pick up
hardcoded endpoints
that the applications communicate with. One of those endpoints could be the one used to
download the firmware automatically during the update process
--> Use this info to get the firmware
Dumping firmware directly from the device
Dump the firmware using the
device bootloader
Bootloader is usually accessible in many ways, through:
embedded serial RS232 ports
, using
special keyboard shortcuts
, or
over the network
In most consumer devices, the bootloader is programmed to allow
flash memory read and write operations
Exposed programming interfaces such as
UART, JTAG, and
SPI
Can connecting to these interfaces directly to read the flash memory
Disassembling the device to find its flash storage
Connect your UART pins directly or use an 8-pin SOIC chip-clip to dump the firmware using
flashrom
and an
SPI-enabled hardware board
such as a
Shikra
Dump firmware contents to a bin file:
$ flashrom -p ft2232_spi:type=232H -r spidump.bin
Extract the firmware directly from either the
flash chip
(through SPI, for example) or
the microcontroller unit
(MCU)
Most difficult method
Need a chip programmer
Proxying or mirroring traffic during device updates
May have to adjust the
user-agent header
since vendors verify this value for firmware downloads
One example to capture the traffic (Using Kali, Ettercap, Wireshark, and SSLstrip)
Start
SSLstrip
:
ssltrip -a
Start up
Ettercap GUI
:
ettercap -G
Click on the
Sniff
menu and the
Unified sniffing...
option
Select the interface. Ex:
eth0
Select
Scan for hosts
under
Hosts
(With this we can find the
id of target device
)
Filter traffic as needed. Ex: 192.168.1.137 for the target device
Open up
Wireshark
to view traffic
Configure
iptables
to redirect traffic from destination port 80 to port 1000, which is what
SSLstrip
listens on:
iptables -t nat -p tcp -A PREROUTING --dport 80 -j REDIRECT --to-port 10000
Start capturing traffic from the target device by clicking on
Start capturing packets
Enable
IP forwarding
:
echo 1 > /proc/sys/net/ipv4/ip_forward
Need to have a
trusted certificate
installed on the device (assuming the transfer occurs over
HTTPS
) and intercept the traffic using a
network sniffer
,
poisoning technique
(such as
ARP cache poisoning
), and
proxy
that can
dump binary communication to a file
Downloading from the vendor's website
Select the Support tab
Select the Drivers & Tools button
Click on the download link
Enter the target device in the search bar
Navigate to the target vendor's website
If the firmware for the specific device isn’t published, try asking the vendor for it
Worth trying to acquire a development and a release build. Doing so will make your testing more effective, because you’ll be able to see the differences between the two builds
Build the firmware manually (a dreaded practice)
The firmware source code might be publicly
accessible, especially in open source projects
Build the firmware by following manufacturer published walkthroughs and instructions
Ex: Firmware of the
GL.iNet routers
is based on
OpenWrt
Emulating firmware for dynamic analysis
I. Use
Firmware Analysis Toolkit (FAT) script
, which uses Firmadyne to perform the emulation of
complete firmware images
(highly recommended to perform this on an
Ubuntu-based system
)
Ex: Emulate firmware DWP2360b by D-Link for its Wireless PoE Access Point
Run
./fat.py
and input firmware name and the brand of the firmware image.
Ex:
DWP2360b-firmware-v206-rc018.bin
for firmware name and
dlink
for brand
Put in password for database (your choice)
Once it finishes the
initial processing
,
creating an image
,
setting up networking
, and
getting an IP address
, it will show that FAT shows you the
IP address
and mentions that the
firmware is now emulated
Open the IP address up in the browser, which presented with the router login page
The FAT script does
Extracts the filesystem from the firmware.
Gets the architecture of the firmware.
Makes the required image.
Sets up the networking.
Emulates the image.
Could do
manually
. Ex: download Debian images for the appropriate architecture and copy the files from the firmware to the newly created Debian instance, and then run the web server (or the component you are testing) using Chroot
II.
Single binary emulation
using
Quick Emulator (QEMU)
Identify the binary endianness and the CPU architecture for which it was compiled. You can find the main binaries on Linux distributions in the
bin
folder. It’s very common to have only a single binary called
busybox
:
$ file ./squashfs-root/bin/busybox
/squashfs-root/bin/busybox: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
[MIPS CPU architecture, MSB: big-endian byte ordering >< LSB: little-endian]
Use QEMU’s
qemu-mips
emulator to emulate executables:
$ qemu-mips -L ./squashfs-root/ ./squashfs-root/bin/zcat
For little-endian, use
qemu-mipsel
Different
filesystems
and tools
yaffs2
Squashfs
: unsquashfs
B. Dynamic Analysis Firmware
Might discover files that were generated after the device booted and didn’t exist during the static analysis phase
Identify the network services and established connections:
$ netstat -a -n -u -t
Look through
rootfs
files like
/etc/passwd
Use Radare2, IDA, Hopper, etc. to reverse engineer executable binaries
Look for strings like
telnet
and look at pseudo code to see the disassembly as a logical program which makes more sense to us
To reverse engineer binary, we need to emulate it using
QEMU
then run it. Reverse like pwn
Ex: Reverse Damn Vulnerable Router Firmware (DVRF)
Extract the filesystem from the firmware using Binwalk
$ binwalk -t -e DVRF_v03.bin
$ cd _DVRF_v03.bin.extracted/squashfs-root
Copy the QEMU binary for the corresponding architecture in the root folder. Confirm our target binary architecture with
readelf
$ readelf -h pwnable/Intro/stack_bof_01
[This binary is MIPS little-endian]
cp $(which qemu-mipsel-static) .
Once we have copied the qemu-mipsel-static to our current directory, we can then use the change root (
chroot
) utility along with
QEMU
to both emulate the binary and run it, and at the same time have the binary believe that its root folder is the current folder from where we are running the command":
$ sudo chroot . ./qemu-mipsel-static pwnable/Intro/stack_bof1
Debugging this program by running it with
QEMU
and
chroot
, along with an additional flag of
-g
which will attach
GDB
to the process:
$ sudo chroot . ./qemu-mipsel-static -g 1234 ./pwnable/Intro/stack_bof1
Now that the execution has paused, we can
launch GDB
and
set up the target
to remote along with the
port
which we have just assigned. Additionally, we will have to
set the architecture
to MIPS:
gef> set architecture mips
gef> target remote 127.0.0.1:1234
Same as pwn. Can then find
bof
at
dat_shell
function
C. Backdooring Firmware
Modifying the contents, and then repackaging it into new firmware. This new firmware could then be flashed to the device.
To modify firmware, use
FMK
tool, which utilizes Binwalk and additional tools to extract the filesystem from the firmware and also provides us with the ability to repackage the modified filesystem into a new firmware binary
Steps
After extracted the firmware and identify its architecture, we need to create and combine backdoor for that architecture. The backdoor script can be any script that downloaded online.
Ex: Use
Buildroot
:
$ ./mipsel-buildroot-linux-uclibc-gcc bindshell.c -static -o bindshell
Look for places where we could place this binary in the filesystem, and how we can make this autostart during boot up.
Ex: add the binary in
etc/templates/
and can refer it from the script called
system.sh
located at
/etc/scripts/
which run during boot up
Build new firmware based on this modification.
Ex:
$ ./build-firmware.sh Dlink_firmware/ -nopad -min
Once we have the new firmware image, we can copy this firmware to our FAT directory and emulate it to verify that our added backdoor is working. Test with netcat to the backdoor reverse shell
D. Target Firmware Update Mechanisms
MIPS
32 general-purpose registers, including $zero, $at, $v0-$v1, c, $t0-$t9, $s0-$s7, $k0, $k1, $gp, $ra, $fp, and $ra
$a0-$a3
is meant for storing
arguments
to functions
$t0-$t9
is for
temporary data storage
$gp
is the
global area pointer
(we try not to modify GP during exploitation)
$sp
is the
stack pointer
$fp
is the
frame pointer
$ra
is the
return address
program counter (PC)
stores the memory address of the next instruction
To take control of a MIPS-based binary program execution flow, we are only concerned with two registers -
RA
and
PC
Reference
Practical IoT Hacking: Ch9
IoT Penetration Testing: Ch3