ScapyCon 2026: packets, automotive security and a nice badge
ScapyCon 2026 was held on 15-16 September at TechBase in Regensburg, Germany. Two days, roughly fifty-sixty participants, and a schedule packed with protocols, automotive security, wireless hacking and hands-on workshops. Here is my writeup.
The thoughts and interpretations in this post are my own, based on my understanding of the talks and discussions at ScapyCon 2026.
Table of contents
How I found ScapyCon
I first heard about ScapyCon earlier this year, when I met the Dissecto team at VECS in Gothenburg. The conference is organized by Dissecto - maintainers and primary contributors to the automotive part of Scapy, the Python packet manipulation library.
As an avid Scapy user myself, it did not take much convincing. A conference built around a tool that often finds its way into our penetration testing scripts, combined with automotive, embedded and protocol security, was a very good reason for a trip to Regensburg.
Arrival, old town and a very nice badge
Regensburg itself was very nice. The old town, with its massive Regensburger Dom, narrow alleys and cobblestone streets, felt familiar to someone coming from Sweden. Vacation season had just ended, the streets were relatively calm, and I had some time to explore before the conference. I happened to stumble upon a Biergarten promoting a brewery with a very suitable name (Hacker-Pschorr)!
Getting to the actual venue turned into a small adventure.
I had checked the route from my hotel months earlier, but when conference morning arrived, TechBase had seemingly migrated to the other side of the city. The bus ticket machines refused my credit card, so I eventually just yeeted myself onto a bus and hoped for the best.
With less than 100 metres left to walk, a stranger approached me.
Are you going to ScapyCon? I don't think this is the place - but I've hailed an Uber, you can join.
We had both been fooled by Google Maps.
The Uber arrived, we traveled across town, and my new friend turned out to be one of the speakers. A good start to a security conference.
Things continued in the same direction when I walked through the doors and was handed a personalized electronic conference badge. It has a colour display, physical buttons, Flipper Zero-compatible GPIO headers, RGB LEDs shining through a semi-transparent PCB, Bluetooth and V2X functionality. It can sniff V2X traffic and can show the conference schedule on its display.
As conference badges go, this was more than expected.
I'm still digging into everything it can do.
The talks
The conference opened with Dr. Nils Weiss tracing the history of ScapyCon back to the TROOPERS community, where keynote speaker Enno Rey has been a central figure. It made for a warm and rather emotional introduction before handing the stage over to Enno himself.
Enno reflected on a life spent around standards and protocols: RFC keywords, IPv6, and the sometimes unexpected consequences of protocol design. IPv6 might be a little overengineered, he argued, but he was not convinced that we would necessarily design it better today. Extension headers provided a good example of how flexibility in a protocol can also create interesting opportunities for abuse.
He finished with a paraphrase of Max Weber that stayed with me:
AI cannot tell us how to live, nor which values are worth pursuing.
That statement turned out to be a suitable theme for some of the talks later in the conference.
Taking modern cars apart
The next presentation, by Dr. Enrico Pozzobon, covered an experiment involving a really hands-on approach to automotive security research: rent production vehicles, take them apart, extract firmware and intercept their network traffic to find out what they actually do with user data.
The researchers found that vehicles can store considerably more information than users themselves are able to request or inspect, including event logs and camera footage. Not all of this necessarily leaves the vehicle. Some data appears to be retained for incident handling, while other information may simply remain because nobody thought particularly hard about removing it.
Third-party providers were also extensively involved in vehicle services. The researchers additionally observed evidence of OTA updates taking place overnight without user interaction, including diagnostic traffic at the UDS level.
One takeaway for me was that physical vehicle disassembly definitely belongs in an OEM's threat model. It requires time and effort, but it is evidently feasible. The researchers did, after all, return the rental cars intact.
V2X wardriving
Another talk started by Dieter Schuster and Nikolai Puch clearing up a common misconception: ITS-G5 does not mean 5G. It is based on 5 GHz 802.11p radio technology. The corresponding technology is commonly known as WAVE in the US, while cellular V2X, or C-V2X, is the branch that makes use of cellular technology.
Anyway, the presenters had gone V2X (ITS-G5) wardriving and collected the messages being broadcast by vehicles and infrastructure. These include CAM messages, essentially periodic announcements saying I'm here, moving this fast, in this direction
, and event-driven DENM messages warning other road users that something has happened. Road infrastructure can similarly broadcast information about lanes, intersections and traffic lights.
Among other things, the collected data revealed a number of speeding vehicles (although probably not in a form that law enforcement can turn into a speeding ticket just yet).
More interesting from a security perspective was the potential ability to fingerprint vehicle types based on attributes exposed through the V2X PKI and information such as advertised vehicle dimensions.
There was also a direct Scapy connection. Work is underway on V2X support in Scapy, which in turn has required adding support for UPER and OER ASN.1 encoding. This is the kind of protocol support that makes Scapy particularly useful when exploring technologies that are otherwise difficult to interact with.
From garage to CI
Automotive fuzzing was discussed in a talk by Reinhard Kugler about moving testing away from physical garages and into repeatable CI environments.
The approach used CAN DBC files as the input model for BooFuzz, a fuzzer descended from Sulley, and moved as much testing as possible from hardware-in-the-loop to software-in-the-loop. With access to source code or suitable binaries, automotive applications can instead be containerized and fuzzed at scale, while measuring coverage for different message combinations.
The attraction is obvious: physical automotive test environments are expensive and difficult to scale. Containers are cheap, reproducible and considerably easier to integrate into development pipelines.
Beyond blind fuzzing
AI inevitably made an appearance as well, this time in the context of CAN, UDS and ISO-TP fuzzing with Dr. Natasha Alkhatib.
Rather than blindly generating inputs, the demonstrated setup used a locally hosted LLM through Ollama to drive Scapy-based fuzzing. Responses from the target ECU (negative response codes, pending responses, timeouts, etc.) were fed back into the model and used to guide subsequent tests.
A number of automotive security tools received a mention along the way, including CaringCaribou, which I've contributed to in the past. That was a nice moment.
More broadly, the talk demonstrated how open models are starting to become a practical component in fuzzing toolchains. Projects such as ChatAFL and work around OSS-Fuzz point in the same general direction: not replacing traditional fuzzing, but using models to help decide where and how to explore next.
Digging into Bluetooth firmware
A Bluetooth talk (by my new friend, Antonio Vasquez Blanco!) provided something closer to a toolbox for attacking and reverse engineering Bluetooth implementations.
The presenter walked through vulnerabilities and methodology, including BlueTrust for cloning Bluetooth identities and BSAM, the Bluetooth Security Assessment Methodology, together with its newer automated checker.
From there, the talk moved down into chipset firmware from vendors including Espressif, Realtek, CSR and Intel. Various tools can be used to dump controller firmware, enumerate vendor-specific HCI commands and change a device's BD-ADDR.
Bluetooth is already a complex family of protocols, and implementations differ substantially between chipset vendors. Reverse engineering the controller firmware therefore opens up an interesting additional attack surface beyond simply interacting with the documented Bluetooth stack.
CRA myths, debunked
The Cyber Resilience Act received a myth-busting session with Janine Funke and Charan Krishnamurthy.
One misconception was that automotive products are simply outside the scope of the CRA. More precisely, vehicles and products covered by the EU vehicle type-approval cybersecurity regime are excluded, while automotive-related digital products outside that regime may still fall under the CRA.
Another concerned the reporting requirements starting 11 September, 2026 . These do not suddenly mean that every manufacturer must have active scanning, a complete vulnerability disclosure process and the entire CRA machinery in place from that date. The different obligations enter into application at different times.
The practical message was: do not wait for harmonized standards before doing anything. Reporting readiness matters now, while documentation and gap closure continue through late 2026 and the first half of 2027 ahead of the broader CRA application date on 11 December 2027.
The CRA reporting deadlines are also easily misunderstood. Both actively exploited vulnerabilities and severe security incidents require an initial notification within 24 hours, followed by a more detailed notification within 72 hours of becoming aware of the issue. This means that the 72 hours include, rather than follow, the initial 24-hour period. After that the timelines differ: severe incidents require a final report within one month of the 72-hour notification, while actively exploited vulnerabilities require a final report no later than 14 days after a corrective or mitigating measure becomes available.
AI-assisted auditing of Scapy
One of the more thought-provoking sessions came from Trail of Bits via remote video conference and covered an AI-assisted code audit of Scapy performed as part of OpenAI's Patch the Planet
cyber program.
The scale was impressive: 11 runs over 36 hours resulted in 670 agent sessions. Together with five days of work from one human auditor, the process produced 471 crashes, which were reduced to 265 real bugs and ultimately 129 reported issues.
Those numbers also illustrate the difficult part.
Point an agent at a parser and it can produce hundreds of crashes in an afternoon. That does not mean it has produced hundreds of useful security findings. False positives need to be removed, multiple crashes can share the same root cause, and whether something is a security issue at all depends heavily on the threat model.
The Scapy maintainers later summarized the problem rather nicely:
A finding is not equal to understanding.
For anyone looking at AI-assisted security testing, that distinction is worth keeping in mind.
What's new in Scapy
Naturally, we also got news directly from the Scapy maintainers, presented by Dr. Nils Weiss.
Scapy 2.7 introduced ForwardMachine, a scriptable multi-client, multi-destination TCP forwarder, together with improvements around TLS and Bluetooth.
For 2.8, work is underway on improvements to J1939, UDS and ISO-TP robustness, as well as SMB and Netlogon. V2X and CAN XL support may also make their way into the library.
Given how often we use Scapy specifically because it allows us to quickly interact with network protocols, several of those additions are particularly interesting.
WHAD - my personal highlight
One of my highlights of the conference was WHAD: Wireless HAcking Devices framework - or, depending on who you ask, We Have A Demo
, presented by Damien Cauquil and Romain Cayre.
WHAD provides a common way of working with wireless protocols across different hardware. A Python API and a set of command-line tools communicate through a unified host/hardware protocol with devices such as ESP32 and nRF52 boards, YARD Stick One and Bluetooth HCI dongles. Supported technologies include BLE, Zigbee and LoRa, among others.
What I particularly liked was the model used to describe attacks. Wireless attacks are broken down into 11 primitives: capture, inject, connect, synchronize, spoof, jam, extract, transform, dump, replay and forge. Each primitive has a corresponding basic tool.
Those tools can then be piped together - with IPC over Unix sockets - so that an attack path becomes a chain of relatively simple operations rather than one large purpose-built program.
And, true to the alternative expansion of the WHAD acronym, there was a demo.
One of the presenters wore a heart rate monitor. Its live readings were intercepted during the presentation and embedded directly into the slides. Simple, visual and effective.
If you've encountered some of the presenters' previous tools, such as Mirage, Wazabee, BtleJack or Bumblebee, WHAD is definitely worth a look.
CANsec - bringing MACsec to CAN
The final protocol rabbit hole worth mentioning was CANsec, an effort to bring authentication and integrity protection to the CAN layer. This talk was presented by Dr. Friedrich Wiemer.
Ethernet already has MACsec. The initial idea was apparently to design something new for CAN, until the working group arrived at a fairly sensible realization: inventing a new security protocol is expensive.
Instead, CANsec reuses MACsec and maps its structures onto CAN XL frames through an adaptation layer.
MACsec uses unidirectional secure channels, each with its own keying material, avoiding freshness collisions between communicating nodes. Key agreement has historically been a poor fit for automotive use, however, with the established process being relatively involved and taking up to 7-8 seconds(!). A new automotive-oriented implementation currently in development brings this down to roughly 50+ ms, and the same key-agreement mechanism is intended to be adaptable for CANsec.
There is another catch though. The resulting overhead is around 26 bytes, which becomes problematic when working with CAN FD and its maximum 64-byte payload. The proposed answer is another fragmentation mechanism, FDAL, which effectively allows CAN XL-style data to be transported over CAN FD.
Scapy has been used extensively to test the protocol during development, and a CAN XL implementation had just been submitted upstream as a pull request. Once again, Scapy was sitting somewhere between protocol specification and practical experimentation.
The workshops
Each conference ticket included two four-hour hands-on workshops. There were several to choose from, and after some deliberation I ended up with two that were particularly relevant to our work: AI-assisted embedded penetration testing and truck hacking.
AI-assisted penetration testing of embedded devices
The AI-assisted penetration testing workshop with Jonas Horreis started with the instructor discussing the classic tendency of AI assistants to agree with whatever assumption you present to them. He also covered the more practical failure modes: accidental deletion, agents disappearing down irrelevant side quests, and automation confidently doing something other than what you intended. It reminded me of Bruce Schneier's recent presentation at Def Con on Hacking AI, making the analogy of AI to the Genie Problem; how the Genie (AI) may either solve the task in a way you did not anticipate or tear down everything in its path to complete the task.
Five pieces of advice stood out as being more useful than simply writing an enormous prompt: choose an appropriate model and thinking time, provide a skill file, plan before acting, review before executing, and write tests first.
For the hands-on portion, we were given access to real ECUs exposing CAN and DoIP interfaces. The task was to take claims from a threat model and use AI-assisted tooling to construct test cases and task the AI to validate whether those security properties actually held.
The AI found the expected issues surprisingly easily, including a publicly known SecurityAccess vulnerability which with some additional instructions was exploited.
My impression afterwards was that I found the AI assistance genuinely useful for streamlining automation, writing scripts and iterating on tests.
I'm planning to experiment with the same approach on our own automotive hacking education platform, built around the CyCar we developed for our CAN Hack! automotive security workshop.
Truck hacking
My second workshop was a CTF-style introduction to heavy vehicle security with Ben Gardiner using an NMFTA truck cybersecurity testing platform (TCAT), with a focus on J1939 and UDS.
The theory alone was worth attending, describing the threat model of heavy vehicle fleet organizations, the differences between US and EU trucks, and a tour through classic CAN attacks: bus-off attacks, bit smashing, flooding and spoofing. We were introduced to previous security research into heavy vehicle systems. One memorable example involved a practical attack injecting RF to mess with J2497 trailer messages and put a truck in limp mode.
J1939 adds a standardized model on top of CAN, with PGNs and SPNs carried using 29-bit CAN identifiers and a set of conventions that differ considerably from the automotive CAN environments many security testers first encounter. We looked at how to enumerate the Controller Applications, or CAs, present on a bus and how diagnostics work in a heavy vehicle environment.
From a practical perspective, we got familiar with Scapy's J1939 layer and the tools pretty_j1939 as well as TruckDevil. We combined the tools and Scapy-powered scripts to enumerate CAs and their attributes. There were also flags to capture that related to SecurityAccess and key replay attack.
I found this workshop rewarding in terms of a broader set of tools and some possibly overlooked attack surface when it comes to heavy machinery that is worth exploring further.
Final words
I'm very glad I found ScapyCon.
With around fifty-sixty attendees, it was small enough that conversations happened naturally, while the technical focus was narrow enough that almost every session connected to something we already work with: automotive security, embedded systems, wireless protocols, fuzzing or Scapy itself.
The joint dinner on day one was a nice addition to continue networking and discuss in a relaxed setting. Reminds me of the philosophy of Security Fest, which I am a co-organizer of.
I came home with plenty of inspiration for future work, particularly around V2X, CAN XL, wireless testing and new ways of using Scapy as the glue between protocols, hardware and custom tooling. Not to forget the potential for WHAD in testing wireless protocols.
The electronic badge is already sitting on my desk. The list of tools and ideas accumulated over two days is considerably more intimidating, in the best possible way.
I'll do my best to be back next year! Thanks to the organizers and thank you for reading this!