If you run Ghidra on a high DPI screen, you will probably find the GUI to be scaled down so small to be almost of no use.
There is a setting that you can adjust to scale the Ghidra GUI:
in $GHIDRA_ROOT/support is a file named launch.properties. In this launch.properties file is the following configuration key:
VMARGS_LINUX=-Dsun.java2d.uiScale=1
| #!/bin/sh | |
| # | |
| # A Small Shell script to check a binary for different microcontroller cpu architectures. | |
| # | |
| # This works by importing the binary into a project in Ghidra | |
| # And then iteratively attempting to analyze chunks of the binary firmare | |
| # all while timing the analysis. | |
| # | |
| # The theory is Ghidra should take noticeably longer to analyze a valid |
Let's say you want to access the application shared preferences in /data/data/com.mypackage.
You could try to run adb shell and then run-as com.mypackage
( or adb shell run-as com.mypackge ls /data/data/com.mypackage/shared_prefs),
but on a production release app downloaded from an app store you're most likely to see:
run-as: Package 'com.mypackage' is not debuggable
This brief tutorial will show you how to go about analyzing a raw binary firmware image in Ghidra.
I was recently interested in reversing some older Cisco IOS images. Those images come in the form of a single binary blob, without any sort of ELF, Mach-o, or PE header to describe the binary.
While I am using Cisco IOS Images in this example, the same process should apply to other Raw Binary Firmware Images.
I have a collection of QEMU VMs for different CPU Architectures. In an attempt to fill in some gaps on architectures I lacked VMs for, I decided to spin up a PowerPC32 VM under QEMU. I chose Debian-PowerPC as the OS.
Install the prerequisite PowerPC packages:
# apt-get install qemu-system-ppc openbios-ppc
The DIR-3040 models of DLINK routers feature encrypted firmware images in the most recent versions of the firmware. https://support.dlink.com/ProductInfo.aspx?m=DIR-3040-US details the firmware images available for this product.
1.11B02 - ftp://ftp2.dlink.com/PRODUCTS/DIR-3040/REVA/DIR-3040_REVA_FIRMWARE_v1.11B02.zip1.02B03 - ftp://ftp2.dlink.com/PRODUCTS/DIR-3040/REVA/DIR-3040_REVA_FIRMWARE_v1.02B03.zipUnzipping the first reveals two files:
DIR-3040_REVA_RELEASE_NOTES_v1.11B02.pdf
| #!/usr/bin/env python3 | |
| # | |
| # find-compressed-data.py | |
| # | |
| # A small script to bruteforce embedded compressed data that might not have a header | |
| # Useful for raw binary firmware images that do not contain a standard | |
| # binary header (ELF, PE, MACH-O). | |
| # | |
| # I included a limt on size at 16KB because this has a tendency to create |
| #!/bin/bash | |
| # | |
| # This script takes a Thecus Firmware Image and decrypts it. | |
| # The encryption key is based off of one of the supported | |
| # models, which are listed in the firmware filename. This | |
| # script will try all of the model names in the file name | |
| # and delete any that do not decrypt to a gzip file. | |
| # | |
| # You will need the following c program compiled and passed |
One of the most useful commands I've developed for reviewing source is a command to extract all strings from a
given directory. To execute this command, open a terminal and cd into the directory containing the source you
would like to audit. Next, run:
egrep -e "(\"|')(\w|\s|\d)*(\"|')" -r -h -I -o . | sort -u
There are at least two valid, signed TLS certificates that are bundled with publicly available Netgear device firmware.
These certificates are trusted by browsers on all platforms, but will surely be added to revocation lists shortly.
The firmware images that contained these certificates along with their private keys were publicly available for download through Netgear's support website, without authentication; thus anyone in the world could have retrieved these keys.