Schedule

Der Hub wird spätestens Ende Januar archiviert, alle nutzerbezogenen Inhalte, Boards und auch einige Wiki-Seiten werden dabei entfernt. Alle öffentlichen Assemblies, Projekte und Veranstaltungen bleiben. // The hub will be archived by end of January. All user-provided content, boards and several wiki pages will be deleted. All public assemblies, projects and events will remain.
Schedule










 

Tag 3
19:00

19:30

20:00

20:30

21:00

21:30

22:00

22:30

23:00

23:30
10 years of Dieselgate (en)

Felix Domke, Karsten Burger

Let's have a (hopefully) final look at Diesel emission cheating. This technical talk summarizes what I learned by reverse-engineering dozens of engine ECU software, how I found and characterized "interesting logic" which, more often than not, ended up being a court-approved "defeat device". What started as a "curious investigation" in 2015 to obtain a ground truth to widespread media reports of "VW being caught for cheating" ended up as a full-blown journey through the then-current state of the Diesel car industry. In this talk, Karsten and Felix will walk through the different implementation of defeat devices, their impact on emissions, and the challenges in documenting seemingly black boxes in court-proven expert reports.

Rowhammer in the Wild: Large-Scale Insights from FlippyR.AM (en)

Martin Heckel, Florian Adamsky, Daniel Gruss

Last year at 38c3, we gave a talk titled "Ten Years of Rowhammer: A Retrospect (and Path to the Future)." In this talk, we summarized 10 years of Rowhammer research and highlighted gaps in our understanding. For instance, although nearly all DRAM generations from DDR3 to DDR5 are vulnerable to the Rowhammer effect, we still do not know its real-world prevalence. For that reason, we invited everyone at 38c3 last year to participate in our large-scale Rowhammer prevalence study. In this year's talk, we will first provide an update on Rowhammer research and present our results from that study. A lot has happened in Rowhammer research in 2025. We have evidence that DDR5 is as vulnerable to Rowhammer as previous generations. Other research shows that not only can adversaries target rows, but columns can also be addressed and used for bit flips. Browser-based Rowhammer attacks are back on the table with Posthammer and with ECC. fail, we can mount Rowhammer attacks on DDR4 with ECC memory. In our large-scale study, we measure Rowhammer prevalence in a fully automated cross-platform framework, FlippyR.AM, using the available state-of-the-art software-based DRAM and Rowhammer tools. Our framework automatically gathers information about the DRAM and uses 5 tools to reverse-engineer the DRAM addressing functions, and based on the reverse-engineered functions, uses 7 tools to mount Rowhammer. We distributed the framework online and via USB thumb drives to thousands of participants from December 30, 2024, to June 30, 2025. Overall, we collected 1006 datasets from 822 systems with various CPUs, DRAM generations, and vendors. Our study reveals that out of 1006 datasets, 453 (371 of the 822 unique systems) succeeded in the first stage of reverse-engineering the DRAM addressing functions, indicating that successfully and reliably recovering DRAM addressing functions remains a significant open problem. In the second stage, 126 (12.5 % of all datasets) exhibited bit flips in our fully automated Rowhammer attacks. Our results show that fully automated, i.e., weaponizable, Rowhammer attacks work on a lower share of systems than FPGA-based and lab experiments indicated, but at 12.5%, are still a practical vector for threat actors. Furthermore, our results highlight that the two most pressing research challenges around Rowhammer exploitability are more reliable reverse-engineering tools for DRAM addressing functions, as 50 % of datasets without bit flips failed in the DRAM reverse-engineering stage, and reliable Rowhammer attacks across diverse processor microarchitectures, as only 12.5 % of datasets contained bit flips. Addressing each of these challenges could double the number of systems susceptible to Rowhammer and make Rowhammer a more pressing threat in real-world scenarios.

Race conditions, transactions and free parking (en)

Benjamin W. Broersma

ORM's and/or developers don't understand databases, transactions, or concurrency.

Light in the Dark(net) (en)

Tobias Höller

Science is hard and research into the usage of the Tor network is especially so. Since it was designed to counter suveillance, it gathering reliable information is difficult. As a consequence, the studies we do have, have yielded very different results. This talk investigates the root causes of contradicting studies by highlighting how slight changes in methodology or data selection completely change the results and thereby our understanding of what the Darknet is. Whether you consider it the last bastion of freedom or a haven of crime, this talk will tell you where to look and what to ignore in order to confirm your current opinion. And in case you are open to changing it, we have some food for thought for you.

Human microservices at the Dutch Railways: modern architecture, ancient hardware? (en)

Maarten W

The Dutch railways have been operating an increasingly complicated network of trains for over 80 years. The task of overseeing it is far too complex for a single human. As such, a network of specifically scoped humans has been connected. Over time, computers and software have been introduced into the system, but today there is still a significant role for humans. This talk describes the network of "human microservices" that is involved in the Dutch Railways' day to day operation from the eyes of a software developer.

Netzpolitik in der Schweiz: Zwischen Bodensee und Matterhorn (de)

Kire, Rahel

Auch in der Schweizer Netzpolitik ging es im auslaufenden Jahr drunter und drüber. Wir blicken mit gewohntem Schalk auf das netzpolitische Jahr 2025 zwischen Bodensee und Matterhorn zurück - und diskutieren jene Themen, die relevant waren und relevant bleiben.

The Angry Path to Zen: AMD Zen Microcode Tools and Insights (en)

Benjamin Kollenda

EntrySign opened the door to custom microcode on AMD Zen CPUs earlier this year. Using a weakness in the signature verification we can load custom microcode updates and modify behavior of stock AMD Zen 1-5 CPUs. While AMD has released patches to address this weakness on some CPUs, we can still use unpatched systems for our analysis. In this talk we cover what we found out about microcode, what we saw in the microcode ROM, the tooling we build, how we worked to find out more and how you can write & test your own microcode on your own AMD Zen systems. We have our tools up on https://github.com/AngryUEFI for everyone to play around with and hopefully help us understand microcode more than we currently do.

The Spectrum - Hackspace Beyond Hacking (en)

sjaelv, MultisampledNight

The Spectrum is a newly founded queer-feminist, intersectional hackspace centering FLINTA+, disabled, and marginalized beings. We see hacking as playful exploration—of technology, art, and ideas—to reimagine what inclusion and collaboration can be. At 39C3, we share how awareness, accessibility, and transdisciplinary creation can transform community and hack the norm.

Von Fuzzern zu Agenten: Entwicklung eines Cyber Reasoning Systems für die AIxCC (de)

Mischa Meier (mmisc), Annika Kuntze

Die AI Cyber Challenge (AIxCC) der DARPA hatte zum Ziel, die Grenzen der autonomen Cybersicherheit zu erweitern: Können AI-Systeme Software-Schwachstellen unabhängig, in Echtzeit und ohne menschliche Hilfe identifizieren, verifizieren und beheben? Im Laufe von zwei Jahren entwickelten Teams aus aller Welt „Cyber Reasoning Systems“ (CRS), die in der Lage sind, komplexe Open-Source-Software zu analysieren, Code zu analysieren, reproducer zu generieren, um zu zeigen, dass ein gemeldeter Fehler kein Fehlalarm ist, und schließlich Patches zu synthetisieren. Unser Team nahm an dieser Challenge teil und entwickelte von Grund auf ein eigenes CRS. In diesem Vortrag geben wir Einblicke in den Wettbewerb: Wie funktioniert die LLM-gesteuerte Schwachstellenerkennung tatsächlich, welche Designentscheidungen sind wichtig und wie sind die Finalisten-Teams an das Problem herangegangen?