Forensic Analysis of the HackRF One with PortaPack Mayhem Firmware

arXiv:2610.20647 · cs.CR · Submitted 2026-10-11 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "Forensic Analysis of the HackRF One with PortaPack Mayhem Firmware".

Elias: The gist The study establishes, at source-code level, where forensically relevant data reside on the microSD card of a device running Mayhem v2.0.1, in which format,

Nadia: First, who's behind it and why it matters.

Title and authors: Nadia: They suggest that practitioners should take the advice from the study and remove the microSD card before you switch your device on, imaging it as a whole disk instead of just targeting a single partition.

Elias: That makes sense because it helps ensure you capture all potential traces without missing anything that might be hidden outside the main user data areas.

Priya: I agree, getting a full disk image is always better than trying to isolate just one partition, especially when dealing with complex file systems like FAT32.

Nadia: Then they push for keeping the hash report of your acquisition tool together with the image itself as proof that the image hasn't changed since you performed the acquisition.

Elias: That’s basic digital forensics practice, but it reinforces the need to document those initial integrity checks explicitly in this context.

Priya: It ties back to what we talked about earlier—we need verifiable proof that our analysis is sound, not just a collection of interesting findings on one specific device.

Nadia: They also recommend being careful with the scope; they state their rules are limited specifically to Mayhem v2 point 0.one and one SD card for this particular study <ref:2610.20647#pg1>.

Elias: Which is a necessary constraint, because generalizing that analysis across different firmware versions or hardware setups would be way too broad without further testing.

Priya: That limitation is important—it tells us this specific methodology is tuned to that exact version, so we have to be careful when applying it elsewhere.

Nadia: They also mention future work involving differential analysis using controlled sets of actions on the same device to see how those artifacts change.

Elias: That suggests they aren't just looking at static files, but dynamic changes based on user interaction, which opens up a new direction for investigation.

Priya: I’m curious if that dynamic approach can help us track specific user behaviors or application usage more accurately than the current static catalog.

Nadia: That’s the potential—moving from just knowing *what* files exist to understanding *how* those files were modified over time.

The paper's summary: Elias: Basically, they’ve given us a detailed way to find, interpret, and recover usage traces on these specific devices based on source code analysis.

Nadia: They established that you can find an artifact catalogue where every piece of data is linked to the source code file that writes it.

Priya: And they showed how you can reconstruct user activity by interpreting timestamps according to system-specific rules, considering things like the RTC battery state.

Elias: Plus, they provide a method for cluster-level recovery of deleted in-phase/quadrature IQ captures and signal decoding validated against tools like rtl four hundred thirty-three.

Priya: It provides a concrete path for examiners to find and interpret usage traces on SDR hardware with this specific firmware.

Nadia: This work is valuable because it offers an examiner a way to find, interpret, and recover usage traces based on source code and verifiable methods.

Elias: It’s a very focused study that provides the necessary detail for anyone needing to analyze these systems running Mayhem v2 point 0.one <ref:2610.20647#pg1,running Mayhem v2.0.1>.

Priya: It’s a solid piece of research that gives us actionable steps for analyzing this specific type of embedded device forensics.

The paper's improvements: Nadia: So we looked at how they found the data on that Mayhem firmware, and now they’re talking about how to make that analysis better in practice, like adding more detail to the catalogue.

Elias: Yeah, they suggest linking every single artifact back to the source code file that actually wrote it. It makes tracing things way clearer because you know exactly which function is responsible for creating that file.

Priya: That mapping is useful because it connects the abstract data on an SD card to the actual logic inside the program, which helps us trust what we’re seeing, right?

Nadia: Exactly. It moves it from just finding a file to understanding *why* that file exists and what process created it.

Elias: And they also talk about dynamic timeline interpretation. They suggest using rules based on how the real-time clock battery is acting, because that affects how the system records time stamps on the files.

Priya: That’s important because if you don't account for the RTC battery state, your whole timeline reconstruction is just a guess based on one specific assumption.

Nadia: It forces us to be precise about those assumptions. They say you have to figure out how fast the universe is expanding near us, and that affects time readings in some systems, so it’s not just UTC.

Elias: And they mention inferring time zones based on which system wrote the file, like Windows versus Linux rules being different. That’s a big caveat for anyone trying to build a universal timeline for these devices.

Priya: It really shows that even with source code mapping, the measurement itself is tricky because the underlying operating system is doing things differently.

Nadia: They also give this workflow for recovering deleted data, focusing on cluster-level recovery of those IQ captures from unallocated space.

Elias: They specifically point out how to handle trimmed files when IQ Trim runs. When that happens, they write the temporary data to a minus tmp file, and then the original gets deleted.

Priya: So if you’re looking for evidence of an old capture that someone tried to hide by trimming it, this method tells you exactly where to look for that temporary evidence.

Nadia: It’s about making sure we don't miss those remnants of deleted data when we scan the whole disk image.

Elias: These improvements suggest a way to build a more reliable forensic toolkit for SDR devices, moving past just basic file listing.

Priya: It helps bridge the gap between finding raw data and actually proving what that data means in terms of user activity and signal quality.

Nadia: So, the next thing we have to consider is how this all fits into a bigger picture, maybe comparing it to those other papers on watermarks or vulnerability benchmarking.

Conclusion: Nadia: So to wrap up, this paper on "Forensic Analysis of the HackRF One with PortaPack Mayhem Firmware" shows how you can actually get into those device traces using source code knowledge and specific workflows.

Elias: Yeah, it gives us a real practical method for finding deleted IQ captures and decoding signals by cross-checking them against independent tools like rtl four hundred thirty-three.

Priya: It’s solid because it doesn't just claim to find data; it shows you how the specific format dictates the recovery path, which helps us judge if the results are trustworthy.

Nadia: It really changes how we think about analyzing embedded hardware that isn't designed with forensic logging in mind.

Elias: Exactly. It moves us away from just looking at file signatures and into understanding the actual execution flow of the operating system, which is where a lot of the hidden usage traces live.

Priya: And for someone just listening, it means that even if you have this type of SDR device in your hands, there’s a specific set of rules you need to know to actually extract anything useful.

Nadia: That's the point. It's not some massive new technology; it's about applying deep knowledge of the code to make existing hardware yield actionable data for investigation.

Elias: The study is limited, obviously, only to Mayhem v2 point zero.one and one specific SD card setup, but that’s fine because it sets a clear baseline for what we *can* do with this approach right now.

Priya: And the authors themselves flag that the method relies heavily on knowing where the data is written in the code, so if you don't have access to that source, you can't do this kind of analysis.

Nadia: So we’ve seen how they map artifacts to source code, how they handle time zone rules based on battery status, and how they recover trimmed data segments.

Elias: It’s a useful guide for anyone working in embedded forensics who needs to know exactly where the relevant data resides when you're dealing with these types of SDR platforms.

Priya: It helps ground the theory in what’s actually measurable—the PSD and envelope analysis they use to classify signals is a solid way to prove signal content.

Nadia: Yeah, that’s what matters. We need those verifiable methods so we can defend our findings in practice when we're dealing with real-world evidence from these kinds of devices.

Elias: It’s a good piece of work because it provides a repeatable process for analyzing this specific device family under Mayhem v2 point zero.one conditions.

Priya: So, the big picture here is that we can use code analysis to unlock forensic potential in hardware that often gets ignored by traditional digital forensics tools.

Nadia: Exactly. This leads us perfectly into looking at those other papers on watermarking and benchmarking, because we need to know how reliable these new methods are when applied broadly.

Fırat University

cs.CR

Submitted: 2026-10-11

Updated: 2026-10-11

Comments: 26 pages, 12 figures, 9 tables. The forensic image is available at https://doi.org/10.5281/zenodo.23219006

Code: https://github.com/portapack-mayhem/mayhem-firmware

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 82/100

The gist: The gist The study establishes, at source-code level, where forensically relevant data reside on the microSD card of a device running Mayhem v2.0.1, in which format, when they are written and how

Key concepts

HackRF One/PortaPack: The HackRF One is an open, low-cost Software-Defined Radio (SDR) hardware. When paired with the PortaPack interface board, it becomes a standalone device capable of recording radio signals digitally and retransmitting them.
Mayhem Firmware: Mayhem is the open-source firmware running on the HackRF One. It operates on a real-time operating system and manages how user data persists, storing all persistent information on the attached microSD card.
IQ Captures: These are digital files containing radio signals recorded as in-phase (I) and quadrature (Q) samples. These raw samples are the primary evidence for analyzing radio transmissions, such as identifying signal types or decoding remote controls.
Artifact Catalogue: This is a comprehensive list of every piece of data found on the SD card, including where it's written by the software and how to read it. It includes details on settings files, trimmed data traces, and deleted file markers.

Summary

The gist The study establishes, at source-code level, where forensically relevant data reside on the microSD card of a device running Mayhem v2.0.1, in which format, when they are written and how they should be interpreted>

Device and Data Model

The HackRF One operates as an open-hardware, lowcost SDR that can record radio signals digitally as in-phase/quadrature (IQ) samples and retransmit them> The PortaPack interface board allows the device to become a stand-alone tool with its own touchscreen, battery, and microSD card> The most important components from a forensic point of view are the microSD slot, the RTC backup battery, the SPI flash holding the firmware, and the micro-USB port> Mayhem is a firmware built on ChibiOS/RT 2.6.8 real-time operating system and is distributed under the GNU General Public License (GPL)> Since v2.0.0, some applications are kept on the SD card as APPS/ files> The device’s own memory has no file system for user data; all user data that persist when the device is switched off are on the SD card> Mayhem uses fixed directory names in the root directory of the SD card, such as CAPTURES/, SETTINGS/, and SCREENSHOTS/>

Artifact Catalogue and Interpretation

The study provides an artifact catalogue for Mayhem v2.0.1 where every artifact is linked to the source-code file that writes it> Key artifacts include SETTINGS/.ini files, which are re-created at every exit from the application, providing information on when an application was opened and closed> The CAPTURES/ directory stores radio captures as headerless, interleaved int16 I/Q data files where duration is calculated as size / (4 × sample rate)> Deleted data can be detected by the FAT32 setting the first byte of a file’s directory entry to 0xE5 and marking its clusters as free> Trimmed copies of files are written to a-tmp file when IQ Trim runs, providing evidence that a capture was trimmed> The study details how file dates are formed through the DATE FILEFLAG file when the backup battery that powers the device’s real-time clock (RTC) is absent, and an inference of the time zone exploits the fact that Windows and Linux write file times according to different rules>

Timeline and Deleted Data Recovery

The examination follows a six-stage workflow, starting with acquisition and integrity using MD5 and SHA-256 hashes on a read-only copy> File-system analysis involves examining FAT32 clusters, including unallocated space where deleted data may be found> The timeline is generated from mactime and the file list, interpreting timestamps according to the system that wrote them, taking into account the state of the RTC battery> Deleted IQ data can be recovered contiguously from free cluster ranges between neighboring captures> For example, a final part of a deleted IQ capture was recovered and six captures were attributed to a single rolling-code on-off keying (OOK) transmitter sharing one 32-bit identifier>

IQ Signal Analysis and Decoding

The study provides a workflow for decoding remote-control signals in the captures by comparison with an independent decoder called rtl 433> The examination of a C16 capture involves reading the centre frequency (fc) and sample rate (fs), using the envelope, PSD, and spectrogram to determine if a signal is present and how it is encoded> If the envelope shows only two levels, on and off, and consists of pulses, the signal is classified as OOK> The line code is identified by looking at which lengths of pulses and gaps occur next to each other in pulse-width modulation (PWM) or Manchester coding> The results were validated against an independent decoder called rtl 433, showing that the Manchester decoding was consistent with the independent tool on 154 of the 163 frames>

Conclusion and Recommendations

The findings lead to recommendations for practitioners, such as removing the SD card before switching the device on and imaging it as a whole disk rather than only a partition> It is recommended to keep the hash report of the acquisition tool together with the image as proof that the image has not changed since acquisition> The rules are limited to Mayhem v2.0.1 and a single SD card, with future work suggesting differential analysis with controlled sets of actions on the same device> This study offers an examiner a way, based on source code and verifiable methods, to find, interpret and recover the usage traces on the SD card> The final part of a deleted capture was recovered, and the captures were shown to belong to a single rolling-code transmitter>

--- Page 1 ---

Forensic Analysis of the HackRF One with PortaPack Mayhem Firmware

Düzgün Küçük Department of Digital Forensics Engineering, Fırat University, Elazığ, Türkiye 11 October 2026 Abstract Software-defined radios (SDRs) have become an inexpensive, portable platform for replay attacks, location spoofing and jamming. The HackRF One can operate stand-alone when fitted with a PortaPack interface board running the open-source Mayhem firmware> No peer-reviewed study has addressed the forensic analysis of this device family> This work establishes, at source-code level, where forensically relevant data reside on the microSD card of a device running Mayhem v2.0.1, in which format, when they are written and how they should be interpreted> The methodology is applied to an SD card image that the author acquired from their own device after four months of real use, and every inference is drawn from the image alone> The workflow covers timestamp rules that depend on the real-time clock (RTC) battery state, traces of on-device trimming and text editing, cluster-level recovery of deleted in-phase/quadrature (IQ) captures, and decoding of recorded signals cross-checked with an independent decoder> In the example image, the final part of a deleted IQ capture and a trimmed-away capture segment are recovered, and six captures are attributed to a single rolling-code on-off keying (OOK) transmitter sharing one 32-bit identifier> The study provides practitioners with an artifact catalogue, interpretation rules and acquisition recommendations Keywords: digital forensics; embedded device forensics; FAT32; deleted data recovery; OOK demodulation

--- Page 2 ---

1 Introduction Software-defined radios (SDRs) are devices that use software in place of most of the circuitry that processes radio signals> As a result, a single piece of hardware can work as both a receiver and a transmitter over a wide frequency range> The HackRF One is an open-hardware, lowcost SDR that operates from 1 MHz to 6 GHz in half-duplex mode [1]> In this mode, it either receives or transmits at any one time> When the PortaPack interface board and the Mayhem firmware [2] are added, the device becomes a stand-alone tool, independent of a computer, with its own touchscreen, battery and microSD (Secure Digital) card> This tool can record radio signals digitally, as in-phase/quadrature (IQ) samples, and retransmit them> It can also generate fake Global Positioning System (GPS) signals, Automatic Dependent Surveillance–Broadcast (ADS-B) messages, with which aircraft report their positions, and Bluetooth Low Energy (BLE) packets> These capabilities can be used in offences such as location spoofing, jamming communications and the replay attack, in which the signal of a car or garage remote control is recorded and retransmitted later> Kouwen et al. [3], in their study of the forensic examination of two-way radio equipment, stated that SDR hardware capable of record-and-replay, such as the HackRF One, requires the “special attention” of law-enforcement experts and called for research on such hardware> Established methods exist for the forensic analysis of embedded systems and Internet of Things (IoT) devices such as drones [4]–[6], smart speakers [7], game consoles [8]–[11], smartwatches [12]–[13] and vehicle infotainment systems [14], [15]> However, no comparable study was found for SDRs> The closest studies either use an SDR as a signal-collection tool or address the file signatures of a different radio tool, the Flipper Zero [17]> In digital forensics, the files or traces that a device or software leaves behind during use and that provide information about user activity are called artifacts> This study addresses the artifacts left by the HackRF One/PortaPack> This study answers the following research questions: 1. Where, and in what format, are forensically relevant data stored on a HackRF One/PortaPack running Mayhem v2.0.1, and which component writes them and when? 2. How can user activity, namely which applications were used, on which frequencies and when, be reconstructed from these artifacts? How should the timestamps be interpreted? 3. How can deleted, trimmed or edited data be detected and recovered? 4. How can the type of recorded radio signals be determined, their contents decoded, and this decoding validated> The contributions of the study are as follows: 1. For Mayhem v2.0.1, an SD card artifact catalogue in which every artifact is linked to the source-code file that writes it, and a mapping of the application settings files to the applications (Section 5.2)> 2.

Improvements for AI systems

Bold header: Source Code Driven Artifact Mapping

The improved AI system can derive an SD card artifact catalogue in which every artifact is linked to the source-code file that writes it, allowing for a forensic examination based on the meaning of each file found is determined by locating the function in the Mayhem source code that writes that file.

Bold header: Dynamic Timeline Interpretation

The system can reconstruct user activity by interpreting timestamps according to specific rules, such as how FAT32 timestamps carry no time-zone information, and inferring time zones based on which system wrote the file, as shown in the rule: Device clock is at least 51 min ahead of UTC, so it is not UTC; consistent with Türkiye local time (UTC+3).

Bold header: Deleted Data Recovery Workflow

The system can perform cluster-level recovery of deleted in-phase/quadrature (IQ) captures by scanning unallocated clusters, and specifically recover data from trimmed files, as described by the rule: When IQ Trim is used, the trimmed data are written to a-tmp file, the original is deleted and the-tmp file is renamed.

Bold header: Signal Content Validation

The AI can determine signal type by using the envelope, the Welch power spectral density (PSD) and the spectrogram and validate decoded signals by performing decoding of recorded signals cross-checked with an independent decoder, such as comparing results against rtl 433.

Bold header: Hardware Component Association

The system can perform a final step to associate artifacts with physical hardware, revealing the components that leave no trace on the SD card and must be examined separately, by using the mapping provided in Table 9.

Abstract

Software-defined radios (SDRs) have become an inexpensive, portable platform for replay attacks, location spoofing and jamming. The HackRF One can operate stand-alone when fitted with a PortaPack interface board running the open-source Mayhem firmware. No peer-reviewed study has addressed the forensic analysis of this device family. This work establishes, at source-code level, where forensically relevant data reside on the microSD card of a device running Mayhem v2.0.1, in which format, when they are written and how they should be interpreted. The methodology is applied to an SD card image that the author acquired from their own device after four months of real use, and every inference is drawn from the image alone. The workflow covers timestamp rules that depend on the real-time clock (RTC) battery state, traces of on-device trimming and text editing, cluster-level recovery of deleted in-phase/quadrature (IQ) captures, and decoding of recorded signals cross-checked with an independent decoder. In the example image, the final part of a deleted IQ capture and a trimmed-away capture segment are recovered, and six captures are attributed to a single rolling-code on-off keying (OOK) transmitter sharing one 32-bit identifier. The study provides practitioners with an artifact catalogue, interpretation rules and acquisition recommendations.