Skip to content

Back to the catalog

Forensic Analysis of the HackRF One with PortaPack Mayhem Firmware
arxiv.orgpaper

Forensic Analysis of the HackRF One with PortaPack Mayhem Firmware

Paper on the forensic analysis of a stand-alone HackRF One with a PortaPack running Mayhem firmware v2.0.1. It establishes at source-code level which data sit on the microSD card, their formats, when they are written and how to interpret them. The method is applied to a four-month SD image and covers RTC-battery-dependent timestamp rules, traces of on-device trimming and text editing, cluster-level recovery of deleted IQ captures, and decoding of recorded signals cross-checked with an independent decoder. In the example, the tail of a deleted IQ capture and a trimmed-away segment are recovered, and six captures are attributed to one rolling-code OOK transmitter with a shared 32-bit ID. It provides an artifact catalogue, interpretation rules and acquisition recommendations.

TL;DR Source-level forensic study of HackRF One/PortaPack Mayhem v2.0.1 SD card artifacts, including deleted IQ capture recovery and rolling-code OOK attribution.
Open original ↗
Document

What it is

A forensic artifact map for a stand-alone HackRF One with a PortaPack running Mayhem firmware v2.0.1 (commit 8e90c65a). It is based on the firmware source and a FAT32 microSD image from the author's own device, used August–December 2024. The image is public. The fetched text stops partway through the methods section, so the results and the acquisition recommendations were not available to me.

How it works

The device keeps no user-data file system of its own. The firmware sits in SPI flash and RAM is volatile, so everything persistent is on the SD card. The paper's directory tree (Figure 2b) gives these artifact locations:

PathWhat it tells the examiner
SETTINGS/*.iniApp opened, frequency and gain. Written when the app is closed.
SETTINGS/NAV.INIautostart_app, the app launched at boot.
DATE_FILEFLAGBoot counter used while the RTC has no battery. Dates start at 1980-01-01 (1980-01-0N).
CAPTURES/BBD_NNNN.C16Raw IQ as int16 I/Q. Duration = size / 4·fs.
CAPTURES/BBD_NNNN.TXTcenter_frequency and sample_rate for the capture.
*.C16-tmp, *.TXT~Leftovers from on-device IQ Trim and Notepad edits.
SCREENSHOTS/SCR_NNNN.PNGScreen showing firmware version and RTC time.
REMOTES/*.REM, PLAYLIST/*.PPL, BLERX/Lists/*.CSV, BLETX/User remotes, playlists and BLE packets.
APPS/, FREQMAN/, ADSB/, SAMPLES/Stock content. Diff against the official SD package to spot modification.
System Volume Information/, .Trash-1000/Traces of Windows mounting and of a Linux desktop (uid 1000).
Unallocated clustersDeleted IQ data and SD-package ZIP remnants.

The paper also infers the time zone from the fact that the device, Windows and Linux write FAT times under different rules. Decoded OOK captures were cross-checked with rtl_433 25.12.

What to do

  • Image the whole card, not just the partition. The author's image started after the first 1 MiB because FTK Imager was set to a logical-volume source, which discards everything before it.
  • Hash at acquisition and keep the report. The author's FTK report was lost, so the earliest integrity evidence was the ZIP CRC-32.
  • Work on a read-only, unmounted image and re-hash at the end.
  • Check DATE_FILEFLAG before trusting any file date.
  • Look for .C16-tmp and .TXT~ files, and carve the free clusters for deleted .C16 data.
  • Tools used: The Sleuth Kit 4.12.1, foremost, PhotoRec, binwalk, hashdeep, rtl_433, multimon-ng, and a custom FAT32 parser.

Caveats

  • One examiner, one device, and one firmware version. The same person used and examined the device, so the paper says this is not independent validation.
  • Hardware revision, serial number and acquisition tool version were not recorded, and the SPI flash was not read.
  • The settings files for transmitting apps show only that an app was opened. They say nothing about whether or when anything was transmitted.
  • Rules are tied to v2.0.1, and the paper does not claim they hold for other versions.

Organisations named here

  • jamming
  • location spoofing
  • rolling-code OOK

Technologies named here

  • HackRF One
  • PortaPack
  • Mayhem firmware v2.0.1
  • Independent signal decoder
  • Mayhem firmware

Techniques named here

  • Replay attack

Related in Hardware & RF