LaForge

Seit 2018 betreibt Eventphone ein neues Telefonsystem auf den chaosnahen Events. Natürlich wird neue Soft- und Hardware sofort zum Forschungsgegenstand. Schnell gab es die üblichen Fragen: Wie funktioniert das genau? Ist das alles an Features? Kann man das updaten? Kann man nicht kompatible Geräte vielleicht kompatibel machen? Was kann man noch verbessern? Ist das sicher?

Natürlich haben wir Antworten und möchten unser Wissen mit euch teilen. Es gibt einen Überblick über DECT, kaputte Crypto™ und was man mit Kreativität daraus machen kann. Unser Anspruch ist, dass wir es so erklären, dass alle Zuschauerinnen und Zuschauer ein bisschen mehr über DECT wissen und mindestens einmal gelacht haben. Seit dem Easterhegg 2018 betreibt Eventphone das PoC (Phone Operation Center) mit neuer Hard- und Software. Wer ist Eventphone bzw. das PoC und was machen die? Neben vielen selbst entwickelten Komponenten nutzen wir eine DECT-over-IP-Lösung des kanadischen Telekommunikationsunternehmens Mitel. Wir geben euch eine Architekturübersicht der neuen Anlage und sprechen über Antennen, Software sowie Lizenzierung. Nachdem wir die größten Probleme, die wir mit dem alten System hatten, vollständig gelöst haben, schauten wir etwas genauer unter die Haube. Bei den ersten Analysen entdeckten wir einen unkritischen, aber witzigen Fehler, den wir euch zeigen wollen. Unser primäres Ziel war es, die Kompatibilität zu erhöhen, denn es gab einige Geräte, die trotz DECT-Standard nicht mit der Anlage funktionierten oder sich sehr sonderlich verhielten. Warum eigentlich? Wir fingen an, die Kommunikation der Geräte zu analysieren, und fanden heraus: Wer ein Byte verliert, hat acht Bit zu wenig. Es folgt: eine DECT-Anmeldung als Theaterstück. Aber halt! Ist das nicht alles verschlüsselt? Woher wisst ihr das? Es folgt: die Geschichte der Mitel Crypto und was daraus entstand: rfpproxy. Es folgt: eine DECT-Anmeldung mit rfpproxy als Theaterstück. Dann sammelten wir Metadaten und löschten sie wieder, mit Unterstützung der Feuerwehr. Und dann? Dann haben wir viel gespielt, analysiert und entwickelt. Weil die Zeit knapp ist zeigen wir euch 3 kleine Beispiele. Musik während des Telefonats über Vanity Number, die Akte AVM und Telefonbuchfunktionen. Am Ende geben wir euch Informationen zum Weitermachen sowie einen Ausblick. Außerdem wollen wir euch motivieren uns zu helfen. Wir hätten gern einen Wireshark Dissector. Stay connected!

Other people: zivillian ST Kambor-Wiesenberg

Billions of subscribers use SIM cards in their phones. Yet, outside a relatively small circle, information about SIM card technology is not widely known. This talk aims to be an in-depth technical overview.

Today, billions of subscribers use SIM cards in their phones. Yet, outside a relatively small circle, information about SIM card technology is not widely known. If at all, people know that once upon a time, they were storing phone books on SIM cards.

Every so often there are some IT security news about SIM card vulnerabilities, and SIM card based attacks on subscribers.

Let's have a look at SIM card technology during the past almost 30 years and cover topics like

• Quick intro to ISO7816 smart cards
• SIM card hardware, operating system, applications
• SIM card related specification bodies, industry, processes
• from SIM to UICC, USIM, ISIM and more
• SIM toolkit, proactive SIM
• eSIM

It's tempting to buy a SDR device like a LimeSDR or USRP family member in the expectation of operating any wireless communications system out there from pure software. In reality, however, the SDR board is really only one building block. Know the limitations and constraints of your SDR board and what you need around it to build a proper transceiver.

For many years, there's an expectation that general purpose SDR devices like the Ettus USRP families, HackRF, bladeRF, LimeSDR, etc. can implement virtually any wireless system. While that is true in principle, it is equally important to understand the limitations and constraints. People with deep understanding of SDR and/or wireless communications systems will likely know all of those. However, SDRs are increasingly used by software developers and IT security experts. They often acquire an SDR board without understanding that this SDR board is only one building block, but by far not enough to e.g. operate a cellular base station. After investing a lot of time, some discover that they're unable to get it to work at all, or at the very least unable to get it to work reliably. This can easily lead to frustration on both the user side, as well as on the side of the authors of software used with those SDRs. The talk will particularly focus on using General Purpose SDRs in the context of cellular technologies from GSM to LTE. It will cover aspects such as band filters, channel filters, clock stability, harmonics as well as Rx and Tx power level calibration. The talk contains the essence of a decade of witnessing struggling SDR users (not only) with running Osmocom software with them. Let's share that with the next generation of SDR users, to prevent them falling into the same traps.

This talk explains how individuals were able to communicate globally in the 1990ies using self-organized networks of BBSsin networks like FIDO and Z-Netz, before individual access to the Internet was possible. It also covers the efforts of non-profit organizations to provide individual access to Internet Mail+News via UUCP and later via IP during that period.

This talk covers how individuals could participate in local, regional and global message-based data communications in the 1990ies. It covers the technologies used to access such networks, both on the infrastructure (BBS) side, as well as on the user/client side. At the same time, the talk is a bit of a personal journey from

• accessing dial-up BBSs using accoustinc coupler and modem
• becoming CoSysop of a BBS and learning about how to operatie BBSs
• being a Node/Point in message based communications networks like Z-Netz and FIDO
• using UUCP to participate in Internet mail/news (Usenet)
• working in the technical team of Kommunikationsnetz Franken e.V. to set up a community-based ISP with modem and ISDN dial-up banks, satellite based Usenet feeds, analog leased lines ISDN-SPV.
• helping getting Germany's alleged first Internet Cafe (we then called it an Online Bistro) connected

Let's have a detailed look at some modern 3G/4G cellular modems and see what we can find out about their internals using undocumented debug interfaces and software or hardware based hacking techniques.

Cellular modems are not only present in smartphones, tablets and laptops, but these days also in many M2M and internet-of-toilets (IoT) applications. Long gone are the days where those modules were GSM/GPRS/EDGE only with ancient ARM7TMDI or ARM926EJS cores and a relatively small-sized firmware in the range of kilobytes to very few megabytes, like on the famous OsmocomBB supported phones. Modern cellular modems re-use the cellular chipsets of smartphones one or two generations ago, like the MDM9615 used in the iPhone 5. As those chipsets contain plenty of processors and are quite sophisticated SoCs on their own, one can even find (undocumented) Linux or Android in some modems, which of course makes them a very attractive target for further exploration or running your own code inside the modem. We will give a short overview about the current market of cellular modems, the major chipset suppliers and chipset families and then pick one or two examples and show the methods used for reverse engineering them to a point where they can be used for much more than the AT command or QMI interface officially documented/supported by the manufacturer. This includes the execution of custom code inside modems, as well as protocol tracing of the air-interface. We'll also look at the FOTA (Firmware Update Over The Air) features, and perform a security analysis of our findings. This talk understands itself following the tradition of various baseband processor related talks at many CCC events of the past decade, including 25C3: Anatomy of smartphone hardware and 28C3: Reverse-engineering a Qualcomm baseband. Both speakers (Harald Welte and Holger Freyther) have been working on Free Software related to cellular telephony for more than a decade, including projects like Openmoko, OpenBSC, OsmocomBB and many other Osmocom projects.

Other people: holger

Seven years after presenting „running your own GSM network“, we are back presenting about how to do the same for 3G (UMTS/HSPA) networks.

Seven years ago, the now famous „running your own GSM network“ talk was held at 25C3, paving the way for a first step into the then-new field of applied research (aka hacking) into mobile communications research. The result of that talk is what is known as OpenBSC. Together with its sister-projects OsmoBTS, OsmoPCU, OsmoNITB, OsmoSGSN and OpenGGSN are commonly used to run GSM/GPRS networks as a means to perform security research, offensive as well as defensive. Now, the team behind those projects has finally started work on supporting 3G base station hardware, extending the scope from 2G/2.5G/2.75G technologies towards UMTS, HSDPA and HSUPA. The talk will cover * what was/is required to implement in terms of the protocol stacks, * the current status of this work, * how it integrates into the Osmo* world, * how it is envisioned to be usd in mobile security research. Like at 25C3, there will also be a demo, of course..