PiRogue Tool Suite logo

PiRogue Tool Suite: the Debian 13 edition

Ce billet n’a pas encore été traduit en français. La version anglaise est disponible ci-dessous.

Previous episodes:

Initial work

Since Debian gets a new stable release roughly every two years, with Debian 13 released in August 2025, the beginning of 2026 looked like a good time to try catching up. That’s why Debamax and Defensive Lab Agency got together for a PiRogue Tool Suite sprint in April.

PiRogue images for Raspberry Pi

Even if the PiRogue project started on Raspberry Pi hardware, the “ViRogue project” lifted that requirement back in 2024. Feedback seems to confirm that users are now deploying PiRogue on various hardware, even sometimes migrating away from Raspberry Pi hardware that was being used previously.

That being said, a number of Pi 4 and Pi 5 deployments are still in service, so it makes sense to keep on providing PiRogue images for Raspberry Pi. The pirogue-images approach (also explained in the previous blog post) didn’t need many changes to build Debian 13 images instead of Debian 12 images: fetching an arm64 Debian image for Raspberry Pi, and tweaking it a little to match PiRogue’s needs.

In the Debian 12 case, there was really no hope of using the mainline Linux kernel (as shipped in Debian) since it entirely lacked Raspberry Pi 5 support, which is why we resorted to building separate, experimental Pi 5 images that would embed the heavily modified Raspberry Pi kernel instead.

Since then, even if Debian 13 still doesn’t ship a Linux kernel supporting the Pi 5, the mainline Linux kernel received a number of commits adding basic support for the Pi 5. That’s why Debamax experimented with building a Pi 5 image using a backported Linux kernel (from trixie-backports), which meant switching from the v6.12.y series (found in Debian 13) to the v6.19.y series (found in Debian unstable, testing, and trixie-backports suites at the time).

The experiment ended up being totally successful!

The resulting image deployed on a Pi 5:

  • was booting (that seems very basic, but that’s never a given when it comes to specific hardware);
  • was accessible over Ethernet;
  • made it possible to deploy the pirogue-base package that pulls everything needed for a PiRogue environment, including configuring the Wi-Fi access point.

Connecting a phone to that network confirmed that traffic analysis was also working as expected, with Suricata alerts popping up when suspicious activity was detected, etc.

NFStream

That package could have been a topic when we switched to Debian 12 in 2024: it needs to be built for both architecture (amd64 and arm64), and the generated binary packages end up depending on some native dependencies like libffi. A rebuild (with or without changes) might have been needed when we switched from PiRogue 1.x versions (based on Raspberry OS, itself based on Debian 11 at the time) to PiRogue 2.x versions (based on Debian 12), but we were lucky as the existing packages were still installable dependency-wise, and working fine.

In the context of this “let’s upgrade all the things!” sprint, it made sense to see if we could upgrade NFStream as well:

  • old version: 6.3.5~ds3, with packages built in June 2023, and with an upstream version dating back to October 2021!
  • new version: 6.6.0~ds1, with packages built in April 2026, and with an upstream version dating back to February 2026 (still current as the time of writing).

This package was a little challenging initially as it required a number of build dependencies (as usual), but also a set of specific versions, branches, and/or patches for 4 different libraries. In the first iterations of the Debian packaging, those had been “vendorized” to make sure we could build a proper source package, which could be built cleanly (e.g. in disposable chroot environments). Fast-forward a few years, installation instructions have been cleaned up quite a lot, with two external components disappearing entirely, and the other two being referenced as Git submodules.

That was reflected in the Debian packaging, which still needed to implement fixes or workarounds for the build system: trivial things like not writing outside the source directory (e.g. to /tmp…) or enabling parallel builds; but also less trivial things like making sure the Debian tooling for Python packages wouldn’t rename the C extension, as that would break importing the nfstream Python module.

Frida

Looking back, automation already looked like an important topic in 2024, and that’s been confirmed with even more numerous releases over the last few years:

  • 2022: 26 releases;
  • 2023: 22 releases;
  • 2024: 32 releases;
  • 2025: 69 releases;
  • 2026: 14 releases at the time of the sprint (April), 62 releases at the time of writing (early November).

Regarding the Frido-based automation, some documentation was added on top of the initial implementation in 2024, but no changes were required regarding:

  • either the high-level steps that are used to automatically update the packaging branch for a given version, dealing with source generation, binary builds, binary checks, and binary publication (to a staging repository);
  • or the low-level actions which implement merging a given upstream version, defining a Debian revision on top of it, making sure all patches still apply, creating a tentative tag, and triggering actual builds for both amd64 and arm64 architectures.

Unfortunately, since Debamax was busy with other customers, automatic builds stopped in June 2025, after successfully building binary packages for 15 versions that year. Upstream changes required adjusting the patch series applied through the Debian packaging, and that was only looked at during the April 2026 sprint. Once the required changes were applied, automated builds resumed and the catch-up was massive: 49 versions over 3 days! And the automation has been green ever since!

Changes required or planned for Debian 13

  • Stricter package manager: APT delegates GPG signature verification to a tool called Sequoia (shipped in the sqv package), and this was known to be a critical topic. After a flag day (initially set to 2026-01-01, then pushed back to 2026-02-01), signatures from keys involving SHA-1 would be rejected. One way to address this topic is to generate new signing keys with higher security standards. Another way is to follow the Sequoia project’s migration guide, which makes it possible to “upgrade” an existing signing key. Cyril followed that guide months in advance (that problem had been anticipated with other customers), and the remaining steps were rather easy: make sure the pirogue.gpg keyring file that’s made available in the Debian 12 PPA and now the Debian 13 PPA, as well as shipped by the pirogue-archive-keyring package, was refreshed with the updated signing key.
  • The PiRogue ecosystem involves many packages, and some of them considered to be of lower priority were dropped: mitmproxy, Mobile Verification Toolkit (MVT).
  • Changes in Python 3.13 broke VPN support in pirogue-admin, which was easily fixed.

Post-sprint status

The Debamax/Defensive Lab Agency sprint was considered a success, since the following could be confirmed:

  • fixed automated builds for Frida, leading to an empty build queue;
  • working PiRogue images for Raspberry Pi, fully tested on Pi 4 and Pi 5;
  • working PiRogue confirmed on VPS as well, in the VPN operating mode.

Finalizing the release

Fast-forward to October 2026, the PiRogue development schedule included the switch to Debian 13, so it was time to finalize the first release of the 3.x series.

What we expected was “let’s pick things up where we left off”. Unfortunately, that wasn’t the case, at all.

Let’s list what needed to be done (possibly going back and forth between topics):

  • make sure PiRogue images were working fine;
  • decide which Frida version to ship (many new versions became available in April, and many more piled up since then);
  • prepare official releases for the few packages that had been patched in April;
  • check what happened in the Debian 12 PPA between April and October, and make sure any changes were carried over to the Debian 13 PPA.

Linux regression

Unfortunately, we got bad news with the very first topic, as the official PiRogue image (for Raspberry Pi 3 and Raspberry Pi 4) was still working fine, but the experimental PiRogue image (for Raspberry Pi 5) was no longer booting.

Since the main difference between both images is about shipping a linux-image package from trixie-backports instead of picking it from trixie or trixie-security, it seemed clear there might be a regression in the Linux kernel between the version available in April and the one available in October. The initial investigation confirmed that two upstream series are suitable for our needs (v6.19.y and v7.0.y), while the next two upstream series are not (v7.1.y and v7.2.y).

The exact reason for this regression hasn’t been pinpointed just yet, but further investigation (tracked as pirogue-images#9) will hopefully lead to bug reports where appropriate (in Debian’s bug tracking system and/or in the Linux kernel’s Bugzilla).

As a temporary measure, it was determined that building the experimental image for Raspberry Pi 5 using the latest suitable Linux package from trixie-backports would be an acceptable solution for the upcoming 3.0.0 release, and that’s been implemented with the help of https://snapshot.debian.org/:

  • the initial commit fundamentally brings us back to the sprint’s status, at least kernel-wise (v6.19.y series);
  • this extra commit ensures that the very first apt-get dist-upgrade doesn’t deploy a known-broken Linux kernel;
  • this last commit switches series to the latest suitable one (from v6.19.y to v7.0.y), confirmed with a full PiRogue deployment.

Frida

With the many builds available, we still had to answer one important question: which version to pick. During the PiRogue 2.x life cycle, it was decided to stick with Frida 16.x versions when incompatibilities were discovered in 17.x versions (e.g. the socketTrace method disappeared).

After investigation, the lead PiRogue developer reported the latest versions (17.25.*, as of October/November 2026) wouldn’t work for PiRogue’s needs, and that we would be using 17.17.0 (from August 2026).

Even with that important question answered, we would still have work to do as some Frida components were found to be completely broken. This was traced back to missing declarations in the upstream build system, which was easy to patch locally, twice:

  • once in the debian/bookworm branch which is used to build the binary packages we publish in our PPA;
  • once in the auto/debian/bookworm branch which is used to track new upstream release, and which is mainly updated automatically via Frido; this was used to publish a fixed package for the 17.23.3 upstream release (versioned 17.23.3~pirogue2), in addition to ensuring any later upstream releases wouldn’t be affected by the same issue.

Of course, the problem and the solution were also reported upstream, through the frida-tools#207 pull request which was just merged! This means that the 17.26.0 upstream release cannot be built automatically anymore, as the patch series no longer applies cleanly. That boomerang effect is slightly annoying, but that’s totally normal when being a good FLOSS citizen: implement a solution locally, notify upstream, then clean things up when upstream integrates that solution (or another one).

PiRogue packages

Comparing the contents of the debian-12 and debian-13 PPAs made it possible to establish a list of packages to release and a list of packages that can be removed.

This took a number of commits, but that was finalized early November 2026.

Conclusion

Some more PiRogue deployment tests were performed:

  • starting from the official PiRogue image, on a Raspberry Pi 4;
  • starting from the experimental PiRogue image, on a Raspberry Pi 5;
  • starting from a freshly installed Debian 13 system on a VPS hosted by Scaleway.

Regarding operating modes, the first two tests cover the “access point” one, while the last test covers the “VPN” one. There was no explicit test of the “appliance” one, but since that’s basically a simplified version of the “access point” one (there’s no Wi-Fi access point to manage), we’re crossing fingers and hoping for the best!

Go grab the release while it’s hot!

  • Raspberry Pi images: arm64_v3.0.0 release.
  • Other systems: until installation instructions are updated to reflect the move from Debian 12 to Debian 13 as the supported operating system, feel free to follow the exact same instructions, replacing every occurrence of debian-12 with debian-13!

Even if Debamax is only working on PiRogue from time to time (as opposed to PiRogue developers working on this project all year long), it’s definitely a project that we really care about. It should be quite clear we’re talking about some long-term commitment, as it’s been four years already since joining the project!