DNS-Technologien im Überblick

Das altehrwürdige Domain Name System ist seit mittlerweile fast vierzig Jahren einer der Grundpfeiler des Internets. Daneben erblicken neue Technologien rund um das DNS das Licht der Welt und entsprechende Unterstützung zieht in die Betriebssysteme ein.

Einleitung

Damit Pakete für das Internetprotokoll in Version 4 und 6 durch das Internet versendet werden können, sind Endpunkte, wie Clients und Server, mit Adressen versehen.

Über diese Adressen können die Dienste eines Servers abgerufen werden, so z. B. der Aufruf einer Webseite. Während IPv4-Adressen wie 192.168.15.15 noch übersichtlich scheinen, sieht es bei IPv6-Adressen wie der Adresse 2001:0db8:3c4d:0015:0000:1507:1503:1a2b anders aus.

Menschen sind nicht sonderlich gut darin, sich Zahlen zu merken, sodass eine andere Adressierung für die entsprechenden Endpunkte geschaffen werden musste. Gelöst wurde das Problem durch das Domain Name System, welches gerne als Telefonbuch des Internets bezeichnet wird.

Damit können Domains wie example.org auf eine entsprechende IP-Adresse abgebildet werden. Durch dieses Mapping vereinfacht sich die Nutzung und Adressierung im Internet.

Hierarchie im System

Wird eine Domain wie example.org aufgerufen, so wird ein DNS-Server abgefragt, der einem daraufhin den Domainnamen zu einer IP-Adresse auflöst.

Das gesamte Domain Name System ist hierarchisch aufgebaut. Auf der obersten Ebene befinden sich die autoritativen Nameserver für die Root-Zone. Diese sind dreizehn an der Zahl und tragen die Namen A bis M. Sie liefern die entsprechende Root-Zone aus, bei welcher es sich um einen knapp 2 MB großen Datenblob handelt.

In diesem enthalten ist eine Liste der autoritativen Nameserver für jede Top-Level-Domain. Damit verweist die Root-Zone auf DNS-Server, welche für einzelne Top-Level-Domains wie .de, .org oder .net zuständig sind.

Die Hierarchie im Domain Name System

Die Nameserver für die einzelnen Top-Level-Domains verweisen für eine angefragte Domain wiederum auf autoritative Nameserver, welche für diese Domain zuständig sind. In der Theorie kann diese Hierarchie mit jeder Ebene einer Domain, wie z. B. Subdomains, fortgesetzt werden.

Autoritative und cachende Nameserver

Besagte autoritative Nameserver sind dafür verantwortlich, verbindliche Aussagen zu einer Zone, wie einer Domäne oder einer ganzen Top-Level-Domain zu treffen. Was der autoritative Nameserver mitteilt, ist die objektive Wahrheit im Domain Name System.

Da es aus Gesichtspunkten wie der Lastverteilung und der Antwortgeschwindigkeit eher unpraktikabel ist, alle Anfragen zu einer bestimmten Zone nur von den autoritativen Nameservern beantwortet zu lassen, existieren cachende Nameserver.

Diese Nameserver, stehen z. B. beim Internet Service Provider und beantworten die DNS-Anfragen der Kunden. Kann eine solche DNS-Anfrage nicht aus dem Cache beantwortet werden, so wird wiederum der autoritative Nameserver angefragt und das Ergebnis für weitere Anfragen im Cache gehalten.

Nach Ablauf der Time to Live (TTL), welche in der Zone definiert ist, wird der Cache invalidiert und bei der nächsten Anfrage wieder der autoritative Nameserver befragt.

Zonen im Detail

In einer Zone können unterschiedlichste sogenannte Resource Records, kurz Records angelegt werden. Eine Zone, welche die entsprechende Konfiguration enthält, könnte wie folgt aussehen:

$ORIGIN example.org.
$TTL 3600
; SOA Records
@		IN	SOA	dns.example.org. 2022061900 86400 10800 3600000 3600
; NS Records
@		IN	NS	ns-1.example.org.
@		IN	NS	ns-2.example.org.
@		IN	NS	ns-3.example.org.
; MX Records
@		IN	MX	10 mail.example.org.
; A Records
@		IN	A	10.1.1.1
; AAAA Records
@		IN	AAAA	2001:db8:123:4567::1
; CNAME Records
api		IN	CNAME	www
www		IN	CNAME	example.org.

In der Zonen-Datei sind eine Reihe von Resource Record-Typen definiert, welche bestimmten Zwecken dienen. Von diesen Typen ist eine größere Anzahl definiert, von denen hier ein auszugsweiser Überblick gegeben werden soll.

A

Der A-Record definiert die IPv4-Adresse des Hosts. Mit diesem wird der Hostname schlussendlich der entsprechenden IPv4-Adresse zugeordnet.

AAAA

Wie beim A-Record ordnet auch der AAAA-Record dem Host eine IP-Adresse zu. In diesem Fall wird allerdings eine IPv6-Adresse zugeordnet.

CNAME

Bei CNAME handelt es sich um die Abkürzung für Canonical Name record. Mit diesem Record kann einer Domain ein weiterer Name zugeordnet werden. Dies kann genutzt werden, um Subdomains wie api.example.org anzulegen.

In einer beispielhaften Konfiguration würde dies dann wie folgt aussehen:

$ORIGIN example.org.
info    IN	CNAME	www
www		IN	A	192.168.1.1
www		IN	AAAA	2a01:4f8:262:5103::1

Hier wird die Subdomain info.example.org per CNAME auf die Subdomain www.example.org verwiesen, welche wiederum per A- und AAAA-Record auf die entsprechenden IP-Adressen des Hosts verweist.

MX

Der MX-Record ist ein wichtiger Record-Typ im Domain Name System, weil er dafür sorgt, dass E-Mails den entsprechenden Empfänger erreichen. Dazu definiert er den entsprechenden Mailserver, welcher für eine Domain zuständig ist:

; MX Records
@		IN	MX	10 mail.example.org.

Damit kann per DNS ermittelt werden, wie der Mailserver erreichbar ist und die entsprechende E-Mail zugestellt werden.

NS

Der NS-Record bzw. die NS-Records definieren die für die Domain zuständigen Nameserver. Bei einem bei Hetzner gehosteten Server, könnte das Ganze wie folgt aussehen:

; NS Records
@		IN	NS	helium.ns.hetzner.de.
@		IN	NS	hydrogen.ns.hetzner.com.
@		IN	NS	oxygen.ns.hetzner.com.

Die dort angegebenen Server sind die autoritativen Nameserver, da die entsprechenden Auskünfte, die diese Server erteilen, für die konfigurierte Domain verbindlich sind.

PTR

Ein PTR-Record, kurz für Pointer record, dient dazu, ein Reverse DNS Lookup zu ermöglichen. Das bedeutet, dass zu einer IP-Adresse der entsprechende DNS-Name ermittelt wird.

Wichtig ist diese Art der Konfiguration unter anderem bei der Bereitstellung von Mailservern.

SOA

SOA-Records, welche ein Kürzel für Start Of Authority darstellen, dienen der Darstellung bestimmter Informationen wie der primären Nameserver oder der Bereitstellung von Informationen, wie der TTL, für andere DNS-Server.

; SOA Records
@		IN	SOA	hydrogen.ns.hetzner.com. dns.hetzner.com. 2022121602 86400 10800 3600000 3600

TXT

Der TXT-Record ist ein relativ universeller Record im Domain Name System, mit welchem maschinenlesbare Daten im DNS hinterlegt werden können:

; TXT Records
@		IN	TXT	"v=spf1 redirect=example.org"

Genutzt wird diese Möglichkeit für unterschiedliche Techniken, wie im E-Mail-System mit DMARC oder dem Sender Policy Framework (SPF).

Probleme im Domain Name System

Das Domain Name System funktioniert in den Grundzügen, so wie es seit 1983 definiert wurde. Allerdings wirft diese Architektur auch einige Probleme auf.

In der klassischen DNS-Variante über UDP oder TCP, findet die komplette Kommunikation unverschlüsselt statt und stellt somit auch aus Sicht des Datenschutzes bzw. der Privatsphäre ein Problem dar.

Daneben sind die DNS-Responses nicht vor Änderungen geschützt und können somit ohne Wissen des Empfängers manipuliert werden.

Auch DDoS-Attacken in Form einer DNS Amplification Attack lassen sich bedingt durch die Gegebenheiten im Domain Name System durchführen. Hierbei wird die Zieladresse mit Datenverkehr von DNS-Servern belastet. Dies funktioniert, da der Angreifer eine DNS-Anfrage mit einer gefälschten IP-Adresse stellt und die Antwort somit beim eigentlichen Ziel der Attacke aufläuft. Der Angreifer benötigt in einem solchen Fall wenig Bandbreite, da die Antwort des DNS-Servers meist wesentlich größer ausfällt, als die Anfrage.

Ein weiteres Problem sind sogenannte Broken Resolvers. Dies ist insbesondere bei einigen Internet Service Providern der Fall, bei denen Dinge wie die TTL, also die Gültigkeit einer DNS-Antwort nicht berücksichtigt werden. Daneben existieren auch solche Resolver, die bei nicht vorhanden Domains nicht mit NXDOMAIN antworten, sondern stattdessen auf eine eigene Webseite umleiten.

Dieses Problem kann schon mit dem ursprünglichen Domain Name System verhindert, werden, indem alternative DNS-Server genutzt werden. Grundsätzlich erschweren solche Broken Resolvers die Fehlerfindung und beeinflussen die Funktionalität des Domain Name System.

Eine Fehlermeldung in Chrome, welche auf Probleme mit der DNS-Konfiguration hinweist

Interessant ist hier die Unterstützung durch Browser, wie Chrome, welcher bei Inkonsistenzen mit dem DNS-Server entsprechende Hinweise in Form einer spezifischen Fehlermeldung gibt.

Verbesserungen am System

Die Schwächen des Domain Name Systems sind nicht unberücksichtigt geblieben und so gab es im Laufe der Zeit immer wieder Verbesserungen, um das eine oder andere Problem zu beseitigen und das Domain Name System zu verbessern.

Dies fing schon in der Frühzeit des DNS an, als neben der ursprünglichen Möglichkeit per UDP Anfragen zu stellen, dies auch per TCP abgewickelt werden sollte. Hintergrund war es hier unter anderem DNS-Responses, welche größer als 512 Byte sind, versenden zu können.

Daneben wurde zur Erweiterung der DNS-Responses über UDP der Extension Mechanismus for DNS, kurz EDNS, definiert. Über diesen Mechanismus ist es möglich, mehr als 512 Byte per UDP zu übertragen. Genutzt wird dies unter anderem bei DNSSEC.

Bei der gewöhnlichen Nutzung wird in den meisten Fällen, aufgrund des geringeren Overheads, UDP genutzt. Nur in Fällen, in denen z. B. größere Datenmengen im Spiel sind, wird TCP genutzt.

TSIG und DNSSEC

Eine Sicherheitstechnologie in Bezug auf DNS ist TSIG, welches mit der RFC 2845 spezifiziert wurde. Das Kürzel steht für Transaction Signatures und ist ein Verfahren zur Absicherung von DNS-Updates z. B. bei dynamischem DNS.

Eine weitere Erweiterung des DNS sind die Domain Name System Security Extensions kurz DNSSEC. Mittels DNSSEC soll die Authentizität und Integrität von DNS-Daten gewährleistet werden.

Das bedeutet bei DNSSEC, dass die Übertragung selbst nicht verschlüsselt ist, sondern nur sichergestellt wird, dass die enthaltenden Daten korrekt und unverändert sind. Die Verbreitung von DNSSEC hat dabei in den vergangenen Jahren zugenommen.

Technologien für neue Anforderungen

Während Technologien wie DNSSEC und TSIG, bestimmte Anwendungszwecke im Auge haben, ist das Bewusstsein für Datenschutz und Privatsphäre im Laufe der letzten Jahre und Jahrzehnte gewachsen, sodass Lösungen entwickelt wurden, welche unverschlüsseltes DNS ersetzen oder ergänzen sollen.

Die neu entwickelten Protokolle und Technologien, welche in den vergangenen Jahren entwickelt wurden, hören auf so illustre Kürzel wie DoT, DoH oder DoQ.

Die unterschiedlichen DNS-Varianten im Laufe der Zeit

Interessant ist hier ein kurzer Rückblick auf die Geschichte des DNS-Protokolls. Als dieses ursprünglich zum Einsatz kam, setzte das Protokoll auf UDP auf, sodass die erste DNS-Version als DNS over UDP bezeichnet werden kann.

Mit der RFC 1123 aus dem Jahre 1989 wurde schließlich begonnen TCP für DNS-Anfragen zu nutzen, sodass DNS over TCP geboren war. Sowohl die UDP als auch die TCP Variante nutzen den Port 53.

DNS over TLS

DNS over TLS, kurz DoT, wurde im Mai 2016 im Rahmen der RFC 7858 standardisiert und wird genutzt, um DNS-Abfragen mittels TLS zu verschlüsseln. Es handelt sich hierbei nur um eine Transport- und um keine Ende-zu-Ende-Verschlüsselung.

DNS über TLS

Bei DoT wird zu dem DNS-Server eine Verbindung über TCP aufgebaut und diese mittels TLS abgesichert. Bedingt durch die Transportverschlüsselung können die DNS-Einträge nicht mehr zwischen den Knoten manipuliert werden. Der standardmäßig vorgesehene Port für DoT ist 853.

Wie auch bei DNS over HTTPS, werden bei dieser Variante DNS-Verstärkungsangriffe weitestgehend unterbunden.

Gegenüber unverschlüsseltem DNS erzeugt die Verschlüsslung per TLS einen gewissen Overhead, welcher sich auf die Geschwindigkeit der DNS-Anfrage auswirkt.

Im Gegensatz zu DNS über HTTPS soll diese Variante in der Praxis schneller sein. Allerdings gibt es je nach Implementierung unter Umständen Probleme, die meist von einem nicht korrekt implementierten Standard herrühren.

Bedingt durch den fest definierten Standardport für DoT (853), lässt sich dieses Protokoll relativ einfach blockieren. In einem solchen Fall kann auf andere DNS-Protokolle geschwenkt oder alternativ auf unverschlüsseltes DNS gesetzt werden.

DNS over HTTPS

Eine weitere Variante, welche ähnlich dem DNS over TLS funktioniert, ist DNS over HTTPS. Dieses wurde in der RFC 8484 standardisiert.

DNS über HTTPS

DoH läuft über den gleichen Port, wie gewöhnliches HTTPS, den Port 443. Damit kann von Außen keine Unterscheidung getroffen werden, ob es sich um DNS-Anfragen oder normalen HTTPS-Datenverkehr handeln.

Der Grund hierfür ist darin zu suchen, dass der Datenverkehr bzw. die Informationen der DNS-Abfrage über das Hypertext Transfer Protocol gesendet werden.

Damit wird eine Blockierung entsprechender DNS-Abfragen über dieses Verfahren erschwert. Allerdings leidet auch hier wieder die Performanz im Vergleich zu gewöhnlichem unverschlüsselten DNS.

Eine Spielart von DNS over HTTPS ist das relativ neue DNS-over-HTTP/3 kurz DoH3, welches wie HTTP/3 als Transportprotokoll QUIC anstatt von TCP nutzt. Dies darf allerdings nicht mit DNS over QUIC verwechselt werden.

DNS over QUIC

Zu den neueren Ideen bzw. Technologien bei der DNS-Abfrage gehört DNS over QUIC. Ziel von DoQ ist es, die Latenzen zu verringern, bei gleichzeitiger Nutzung einer verschlüsselten Verbindung.

DNS über QUIC

Definiert ist DoQ in der RFC 9250. Grundlage für das Protokoll ist QUIC, welches als Transportschicht TCP ersetzt und in dieser Form auch bei HTTP/3 genutzt wird.

Ziel von DoQ ist, dass dieses Protokoll auch für autoritative Nameserver verwendet werden kann. Damit soll eine möglichst breite Anzahl an Nutzungsmöglichkeiten im Zusammenhang, mit dem Domain Name System abgebildet werden können.

Da DoQ über den zugewiesenen Port 853 läuft, ist auch hier technisch gesehen eine einfache Blockierung möglich. Allerdings definiert die RFC hier im Abschnitt Port Selection:

In the stub to recursive scenario, the use of port 443 as a mutually agreed alternative port can be operationally beneficial, since port 443 is used by many services using QUIC and HTTP-3 and is thus less likely to be blocked than other ports

Unterstützung auf Serverseite

Damit DNS-Dienste, über welche Protokolle auch immer, im Internet genutzt werden können, muss die entsprechende Server-Software die gewünschten Protokolle unterstützen.

Neben BIND, dem Platzhirsch unter den DNS-Server, existieren noch weitere DNS-Server von denen bezüglich ihrer Fähigkeiten noch Unbound und der Windows Server kurz beleuchtet werden sollen.

DNS over TLS DNS over HTTPS DNS over QUIC
BIND ab Version 9.17 ab Version 9.17
Unbound ab Version 1.7.3 ab Version 1.12.0
Windows Server (DNS) ab Windows Server 2022

Bei BIND zogen mit der Version 9.17, welche im Jahr 2020 erschien, der Support für DoT und DoH (in einer experimentellen Version) ein. Eine Unterstützung für DNS over QUIC, steht im Moment noch aus.

Unbound liefert seit der im Juni 2018 erschienen Version 1.7.3 eine Unterstützung für DNS over TLS aus. Mit der im Oktober 2020 erschienen Version 1.12.0 wurde die Unterstützung für DNS over HTTPS implementiert. An der Umsetzung von DNS over QUIC in Unbound wird im Moment noch gearbeitet.

Ab dem Windows Server 2022 wird DNS over HTTPS offiziell unterstützt. Bei DNS over TLS und DNS over QUIC ist bisher keine Unterstützung im Windows Server vorhanden.

Linux

Neben der Unterstützung auf Serverseite ist auch die Unterstützung auf Client-Seite, in Form von Betriebssystemen auf dem Desktop, als auch im Bereich der mobilen Betriebssysteme wichtig.

In den meisten Linux-Distributionen, welche Systemd nutzen, kann dies über systemd-resolved erledigt werden. Dieser unterstützt ab der Version 239 opportunistisches DNS over TLS und ab der Version 243 striktes DNS over TLS.

Hier kann z. B. unter Ubuntu in der Konsole die entsprechende Konfigurationsdatei editiert werden:

nano /etc/systemd/resolved.conf

Dort sollte die Einstellung:

DNSOverTLS=yes

hinzugefügt werden. Anschließend können über den normalen Netzwerkdialog, DoT-fähige DNS-Server eingetragen werden:

9.9.9.9, 149.112.112.112

In diesem Fall sind es die DNS-Server von Quad9. Anschließend laufen die DNS-Abfragen per DoT über die gewählten DNS-Server.

macOS

Seit macOS 11, welches mit dem Namen Big Sur auf den Markt kam, unterstützt macOS neben DNS over TLS auch DNS over HTTPS.

Aktiviert werden können die gewünschten Einstellungen über Konfigurationsprofile. Dazu muss ein entsprechendes Profil heruntergeladen und anschließend installiert werden.

Das Profil unter macOS

Die Konfigurationsprofile befinden sich in den Systemeinstellungen unter macOS. Nach der Aktivierung kann über das Terminal überprüft werden, ob die entsprechenden Einstellungen aktiv sind:

sudo tcpdump -i any "port 853 and host 9.9.9.9 or host 149.112.112.112"

Bei der Nutzung von DoH sollte der Port im Befehl auf 443 geändert werden. Nachdem der Befehl abgesetzt wurde, sollte Netzwerkverkehr zu dem Quad9-DNS-Server im Dump auftauchen.

Windows

Unter Windows 10 wird, seit dem Build 19628, DNS over HTTPS unterstützt. Dazu muss in der Registry der Pfad:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

aufgerufen werden und dort ein Parameter vom Typ DWORD erstellt werden. Dieser trägt den Namen EnableAutoDoh sowie den Wert 2. Anschließend sollte ein Neustart des Rechners durchgeführt werden.

Die Einstellungen im Registrierungs-Editor

Nun können in den Einstellungen für den jeweiligen Netzwerkadapter die passenden DNS-Server mit einer entsprechenden Unterstützung für DoH eingestellt werden:

9.9.9.9, 149.112.112.112

Unter Windows 11 können die Einstellungen für DoH bequem über die Netzwerkeinstellungen eingestellt werden, nachdem dort die passenden DNS-Server hinterlegt sind, kann dort unter DNS over HTTPS das Feature aktiviert werden.

Neben DoH unterstützt Windows 11 auch DNS over TLS. Dazu werden in den Netzwerkeinstellungen die entsprechenden DNS-Server hinterlegt und das DNS over HTTPS-Feature deaktiviert.

Nun muss die Kommandozeile geöffnet werden und dort müssen die Befehle:

netsh dns add global dot=yes​
netsh dns add encryption server=9.9.9.9 dothost=: autoupgrade=yes
netsh dns add encryption server=149.112.112.112 dothost=: autoupgrade=yes

eingegeben werden. Das Kommando:

netsh dns add encryption

muss hierbei für jeden DNS-Server für die IPv4- und IPv6-Adresse wiederholt werden. Abgeschlossen wird das Prozedere mittels:

ipconfig /flushdns
netsh dns show global

Der letztere Befehl zeigt an, ob die Einstellungen für DNS over TLS aktiviert wurden. DNS over QUIC wird unter Windows vom System selbst bisher noch nicht unterstützt.

Android

Während seit Android 9 (Pie) DNS over TLS bereits verfügbar ist, ist DNS over HTTPS ab Android 11 enthalten und teilweise auch auf einigen Geräten mit Android 10 verfügbar.

Die teilweise Verfügbarkeit unter Android 10 erklärt sich dadurch, dass das entsprechende DNS Resolver Modul unter Android 10 noch optional, aber unter Android 11 verpflichtend zum System dazu gehört. Installiert werden diese Änderungen über ein Google Play-Systemupdate.

In den Einstellungen kann DoT bzw. DoH aktiviert werden

Zur Aktivierung unter Android genügt es in den Systemeinstellungen, die Netzwerkeinstellungen aufzurufen und dort im Punkt Privates DNS, die entsprechenden DNS-Server zu hinterlegen. Hierbei wird, je nach Android-Version, DNS over HTTPS (in der Variante DoH3) gegenüber DNS over TLS bevorzugt, zumindest bei den dem System bekannten DNS-Servern.

iOS

Seit iOS 14, also knapp 2 Jahre später als unter Android, zog in iOS die Unterstützung für DNS over TLS ein. Ebenfalls ab iOS 14 wird DNS over HTTPS unterstützt.

Wie unter macOS, kann die Einstellung über entsprechende Konfigurationsprofile vorgenommen werden. Dazu muss ein Profil auf dem iOS-Gerät heruntergeladen und installiert werden.

Die Installation des Profils erfolgt über die Einstellungen unter iOS

Nachdem das Profil bestätigt und installiert worden ist, wird der DNS-Server in der im Profil hinterlegten Konfiguration genutzt.

Unter iOS existiert die Besonderheit, dass DNS-Abfragen für den Appstore und die Terminalbefehle dig und nslookup per Design nicht über die im Profil hinterlegten DNS-Server abgefragt werden.

Das Profil kommt nicht immer zur Anwendung

Auch gelten die Einstellungen nicht, wenn z. B. iCloud Privat Relay oder eine VPN-Verbindung aktiv sind.

Browser

Neben der betriebssystemseitigen Unterstützung liefern auch die meisten Browser mittlerweile eine Unterstützung für DNS over HTTPS aus. Diese Unterstützung ist unabhängig vom darunterliegenden Betriebssystem.

Die Einstellungen für DNS over HTTPS im Firefox

Im Firefox kann DNS over HTTPS in den Einstellungen unter Allgemein und dort in den Verbindungs-Einstellungen aktiviert werden. Dort kann dann der Punkt DNS über HTTPS aktiviert mitsamt eines Servers ausgewählt werden.

Die Einstellungen zu DoH unter Chrome

Unter Chrome kann DoH über die Einstellungen unter dem Punkt Datenschutz und Sicherheit aktiviert werden. Dort findet sich unter dem Unterpunkt Sicherheit der Punkt Sicheres DNS verwenden.

Router

Auch Router bieten in vielen Fällen Funktionalitäten zur besseren Absicherung von DNS-Abfragen.

So können in der FRITZ!Box entsprechende DNS-Server, welche DoT unterstützen hinterlegt werden. Auf Wunsch kann die FRITZ!Box auch einen Fallback auf unverschlüsseltes DNS durchführen, falls die entsprechenden DoT-Server nicht erreicht werden können. Dies kann zum Beispiel durch entsprechende Firewalls oder beim technischen Ausfall der Server passieren.

Andere Verfahren

Neben den oben beschriebenen Varianten existieren noch weitere DNS-Varianten wie Oblivious DNS bzw. Oblivious DoH, DNS over TOR und DNSCrypt, welche allerdings im weiträumigen Praxiseinsatz eher seltener zu finden sind.

Nachteile der neuen Lösungen

Bei den neuen Lösungen, wie DoT, DoH und DNS over QUIC, existieren eine Reihe von Problemen bzw. Kritikpunkten.

Viele beziehen sich dabei auf gewünschte Eigenschaften der Verfahren, wie die Verschlüsselung, welche es unter anderem erschwert, den DNS-Verkehr zu überwachen. Genutzt wird eine solche Überwachung z. B. in Kinderschutzsoftware, oder im geschäftlichen Umfeld, um den Netzwerkverkehr zu überwachen und entsprechende Policen durchzusetzen.

Je nach Lösung wird dann versucht, die neueren Verfahren zu deaktivieren bzw. dessen Nutzung nicht zuzulassen oder aber eigene Server für die entsprechenden Protokolle zu betreiben, welche wiederum die entsprechen Sperrmöglichkeiten anbieten.

Auch sind die, bei den Verfahren wie DoT oder DoH genutzten, meist zentralen DNS-Server von Google, Cloudflare oder Quad9 ein Problem, da sich dort ein Großteil des DNS-Verkehrs sammelt und dies Begehrlichkeiten wecken oder der Profilbildung dienen kann.

Daneben sollte beachtet werden, dass je nach Implementation bzw. Betriebssystem die Nutzung der verschlüsselten DNS-Varianten nicht immer garantiert ist. Sei es durch ungewollte Downgrades auf unverschlüsseltes DNS oder aber Applikationen wie der Appstore unter iOS, welcher von den DNS-Einstellungen des Systems unabhängig funktioniert. Daneben gibt es in bestimmten Versionen von Android den Fall, dass die Private-DNS-Einstellungen nach dem Aufwachen des Gerätes erst wieder nach einigen Sekunden angewendet werden.

Fazit

DNS-Abfragen müssen heute nicht mehr unverschlüsselt erfolgen, da es eine Reihe von neuen Ideen und Transportprotokollen gibt, welche neben der jeweiligen Vorteile teilweise auch spezifische Nachteile haben.

Mittlerweile findet sich für die Verfahren DNS over TLS und DNS over HTTPS eine breitere Unterstützung in den Betriebssystemen. Dort, wo diese noch nicht verfügbar ist, kann auf DNS-Proxies oder im Spezialfall Browser auf dessen Möglichkeiten zurückgegriffen werden.

DNS over TLS DNS over HTTPS DNS over QUIC
Linux über systemd-resolved (ab Version 239 bzw. 243)
macOS ab macOS 11 (Big Sur) ab macOS 11 (Big Sur)
Windows ab Windows 11 (Build 25158) ab Windows 10 (Build 19628), Windows 11
Android ab Android 9 (Pie) ab Android 11
iOS ab iOS 14 ab iOS 14

Neben der gewöhnlichen DNS Auflösung haben aktuell vorwiegend die Technologien DoT und DoH eine größere Verbreitung erlangt. Spannend wird in Zukunft auch die Entwicklung von DoQ, welches zumindest das Potenzial hat, bestehende Technologien rundum DNS-Abfragen abzulösen.

Allerdings stellt sich bei vielen dieser Protokolle die Frage, welchen DNS-Servern vertraut werden soll, denn das bestehende DNS-System ist ein dezentrales System ohne übermächtige Gatekeeper, während bei Diensten wie DoT und DoH eine Zentralisierung zu beobachten ist.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Browser für Restic-Repositories

Für Backups nutze ich gerne Restic. Restic bietet neben dem Backup selbstverständlich auch eine Funktionalität zum Wiederherstellen eines Backups an. Allerdings gibt es mit dem Restic Browser ein grafisches Werkzeug zum Anschauen der durch Restic erstellten Repositorys.

Die Restic-Installation wurde nicht gefunden

Beim Start des Restic Browser kann es vorkommen, das dieser die Restic-Installation nicht findet. Dort muss dann der Pfad manuell definiert werden. Wurde Restic unter macOS, mittels Homebrew installiert, so lautet der Pfad:

/opt/homebrew/bin/restic

Der entsprechende Pfad wird sich leider nicht gemerkt, sodass er beim nächsten Mal wieder eingegeben werden muss. Nachdem die Installation definiert wurde, kann mit der Applikation ein Restic-Repository geöffnet und durchsucht werden.

Die Applikation in Aktion

Ordner als auch Dateien können anschließend über die Oberfläche wieder hergestellt werden. Während dies für lokale Repositorys gut funktioniert, sieht es bei Repositorys welche per SFTP eingebunden werden anders aus. Hier nimmt der Ladevorgang, zur Anzeige der Dateien in einem Snapshot, sehr viel Zeit in Anspruch.

Zu finden ist der Restic Browser auf GitHub. Lizenziert ist er unter der MIT-Lizenz und damit freie Software. Die Releases sind für Linux, macOS und Windows verfügbar.

Problematische USB-Sticks unter Windows formatieren

Manchmal kann ein USB-Stick unter Windows nicht mit den grafischen Bordmitteln formatiert werden. Dies kann auftreten, wenn auf dem USB-Stick mehrere Partitionen vorhanden sind. In einem solchen Fall kann auf die Kommandozeile und das Werkzeug diskpart zurückgegriffen werden.

Die Kommandozeile unter Windows

Mithilfe dieses Werkzeuges können bestehende Partitionen gelöscht und der USB-Stick neu initialisiert werden. Dazu muss die Kommandozeile gestartet werden und der Befehl diskpart eingegeben werden. Anschließend müssen die vorhandenen Datenträger ermittelt werden:

list disk

Das Kommando listet dabei die angeschlossenen Datenträger auf:

  Datenträger ###  Status         Größe    Frei     Dyn  GPT
  ---------------  -------------  -------  -------  ---  ---
  Datenträger 0    Online         3953 GB    12 MB        *
  Datenträger 1    Online         7450 MB  3263 MB        *

Mithilfe der Auflistung kann der korrekte Datenträger ausgewählt werden:

select disk 1

Im letzten Schritt muss der Datenträger bereinigt und mit einer neuen Partition versehen werden:

clean
create partition primary

Nachdem der Vorgang abgeschlossen wurde, kann diskpart mittels exit verlassen werden und der Stick normal formatiert werden.

Der universelle Cyberdelfin

Funktechniken wie NFC, RFID und Frequenzen wie die Nutzung des 433 MHz-Bandes bleiben den meisten Interessierten verschlossen. Mit dem Flipper Zero, welcher nun auch in Europa ausgeliefert wird, soll sich dies ändern.

Vor knapp zwei Jahren wurde im Rahmen einer Kickstarter-Kampagne im Juli 2020 der Flipper Zero angekündigt, auch Golem.de berichtete darüber.

Beim Flipper Zero handelt es sich um einen Hacker-Tamagotchi bzw. eine Art Funk-Multitool für Hacker. Die grundsätzliche Idee war es, die benötigten Werkzeuge für das Pentesting bestimmter Technologien, welche vorwiegend in der physischen Welt Verwendung finden, in einem Gehäuse zu vereinen. Dadurch ist der Anwender wesentlich mobiler und kann entsprechende Tests auch unauffällig durchführen.

Der Flipper Zero in Aktion

Im Grunde handelt es sich um ein Bündel unterschiedlichster Funktionalitäten, mit denen der Flipper Zero unter anderem als Universalfernbedienung, NFC- und RFID-Kopierstation (soweit technisch möglich), oder als Bastelwerkzeug für Hardwareinteressierte genutzt werden kann.

Nachdem die Kickstarter-Backer in Amerika und Australien bereits beliefert wurden, steht jetzt Europa auf der Liste.

Vom Hackspace zur Idee

Die Idee des Flipper Zero kam im Umfeld des Neuron Hackspace auf. Der Neuron Hackspace versteht sich als der erste Hackspace in Moskau, welcher von einem Besuch des 29C3 in Berlin inspiriert, schließlich im Juni 2011 seine Tore in Moskau öffnete.

In diesem mittlerweile geschlossenen Hackspace, kam die Idee für den Flipper Zero und den Flipper One auf. Die ursprüngliche Idee für die Geräte stammte von Pavel Zhovner, während Alexander Kulagin die Projektleitung übernahm und sich Valeria Aquamain als Art Director verantwortlich zeichnete.

Ursprünglich sollte ein Raspberry Pi Zero W als Grundlage genutzt werden. Von dieser Idee wurde Abstand genommen, da das Modul nicht in ausreichenden Stückzahlen geliefert werden konnte und die entsprechenden Compute-Module zu teuer gewesen wären.

Die Idee dahinter war, bestimmte Funktionalitäten in separater Hardware zu implementieren und den Raspberry Pi Zero W mit einer Linux-Distribution für anspruchsvollere Aufgaben zu betreiben.

Diese Variante erhielt den Namen Flipper One. Die Variante ohne entsprechende Linux-Möglichkeiten wurde schließlich zum Flipper Zero. Die Arbeit am Flipper One wurde zugunsten der Flipper Zero zurückgestellt.

Nachdem die Macher des Flipper Zero knapp 12.000 Vorbestellungen erhalten hatten, folgte eine entsprechende Kickstarter-Kampagne.

Die ursprünglich für das Hauptziel vorgesehenen 60.000 US-Dollar waren bereits nach acht Minuten ausfinanziert und 28 Tage später waren 4,4 Millionen US-Dollar erreicht und schlussendlich wurden über 4,8 Millionen US-Dollar eingesammelt.

Aufgrund der eingesammelten Summe wurden auch einige vorher als optional betrachtete Features mit in das Gerät aufgenommen. Dazu zählen ein alternativer dunkler Farbton, Bluetooth und NFC.

Designprozess

Für das Design, insbesondere das sogenannte Design for manufacturability (DFM), wurde mit der Firma Design Heroes zusammengearbeitet, welche ebenfalls in Moskau ansäßig sind. Beim DFM liegt der Fokus darauf, das Design des Produktes so zu gestalten, dass es in der Produktion keine größeren Probleme verursacht und einfach herzustellen ist.

Daneben unterstützte Design Heroes die Macher des Flipper Zero von den ersten Sketchen über die 3D-Modelle bis zu den ersten Prototypen, welche im 3D-Druck entstanden.

Während des Designprozesses wurden unterschiedlichste Änderungen vorgenommen, so wanderte z. B. der IR-Transceiver von der oberen Seite des Gerätes an die Seite. Grund hierfür war, dass der Transceiver auf der Oberseite oft verdeckt war, entweder durch Finger oder entsprechende Boards, welche mit der GPIO-Leiste genutzt wurden. Auch das Layout der GPIO-Leiste änderte sich einige Male, bis es seine jetzige Form erhielt.

Ebenfalls erst im Laufe des Design- und Umsetzungsprozesses, erfolgte die Erweiterung des Gerätes um einen microSD-Slot, um Dinge wie Code-Datenbanken und Ähnliches zu speichern, welche im 1 Megabyte großen Flash-Speicher des Gerätes selbst keinen Platz finden würden.

Während des Prozesses wurden immer wieder Anpassungen an der Hardware und der entsprechenden Verdrahtung gemacht. So wurde unter anderem die Batterie mit einem entsprechenden Konnektor versehen, damit diese einfach wechselbar ist, falls der Akkumulator mit der Zeit nicht mehr die gewünschte Leistung liefert.

Produktion

Bei der Ankündigung des Flipper Zero war von einer Auslieferung im Februar 2021 die Rede, was aus unterschiedlichsten Gründen nicht eingehalten werden konnte. Allerdings war dies aus Sicht eines Backers nicht weiter tragisch, was auch der exzellenten Kommunikation des Teams hinter dem Gadget zu verdanken ist.

So gab es für die Backer und andere Interessierte einen tiefen Einblick in die Probleme bei der Entwicklung und der Produktion. Prozesse wie die Herstellung der Gehäuse per Spritzguss wurden erklärt und die Herausforderungen dabei beschrieben. Die späteren Schritte wie der Test der Hardware wurden ebenfalls ausführlich beleuchtet.

Auch in diesem Projekt gab es Probleme im Zusammenhang mit der Chipkrise, sodass sich bestimmte Bestellungen für Bauteile, wie dem Bildschirm, verzögerten. Das führte auch dazu, dass einige Redesigns vorgenommen werden mussten, um nicht lieferbare Komponenten zu ersetzen.

So erwies es sich zeitweise als schwierig weitere ICs für das Laden der Batterie zu erhalten, der eingesetzte BQ25896RTWR war nicht mehr zu beschaffen, was für entsprechende Verzögerungen sorgte.

Erster Eindruck

Je nach getätigter Bestellung kann und wird der Flipper Zero mit entsprechendem Zubehör wie der Silikonhülle geliefert.

Der Flipper Zero selbst, wird in einer kleinen Pappbox geliefert. Wer diese öffnet, erhält einen Blick auf eine kurze Anleitung, sowie einen Aufkleber.

Darunter befindet sich ein USB-C-Kabel, welches mitgeliefert wird, sowie eine Ebene tiefer der eigentliche Flipper Zero. Das Gerät selbst misst 100 × 40 × 25 mm und wiegt 102 Gramm und liegt damit angenehm in der Hand.

Der Flipper Zero im Außeneinsatz

Allerdings wirkt es zumindest in der Vorstellung des Autors etwas größer als die Produktfotos es erahnen ließen.

Gefertigt wird das Gehäuse aus Polycarbonat, ABS-Kunststoff und Polymethylmethacrylat, besser bekannt unter dem Namen Acrylglass. Spezifiziert ist das Gerät für eine Betriebstemperatur von 0 bis 40 Grad.

Bildschirm

Der Flipper Zero verfügt über ein 1.4 Zoll (3,56 Zentimeter) großes Display, mit einer Auflösung von 128 × 64 Pixeln. Der Bildschirm ist ein klassisches LCD bei einem Stromverbrauch von 400 nA, wenn das Backlight deaktiviert ist. Intern ist dieser Bildschirm per SPI angebunden.

Der Bildschirm selbst ist beim Flipper immer aktiviert, nur die Hintergrundbeleuchtung wird entsprechend zugeschaltet.

Die Wahl des Bildschirmes war für den Flipper Zero eine zentrale Entscheidung, so wurde praktisch das gesamte Gerät um den Bildschirm herum gebaut. In der Überlegung stand auch ein E-Ink-Display, allerdings wurden hier die Aktualisierungsraten als zu gering bewertet und sich stattdessen für ein entsprechendes LCD entschieden.

Überblick

Gesteuert wird das Gerät über eine Art Steuerkreuz, inklusive Mitteltaste, sowie dem Zurück-Button. Neben dem Bildschirm ist eine Status-LED verbaut.

Der Flipper ist der Verpackung entstiegen

An der Oberseite des Gehäuses befindet sich eine GPIO-Leiste zur Ansteuerung externer Hardware. Sie wird mit 3,3 Volt betrieben, ist aber 5 Volt tolerant. Die Schräge auf der linken Seite enthält den Infrarot-Transceiver.

Auf der Unterseite befindet sich der Slot für die microSD-Karte. Dieser wird unter anderem für die Datenbanken benötigt, welche die Firmware des Flipper Zero nutzt.

Auf der rechten Seite befindet sich die USB-C-Buchse, mit welcher das Gerät geladen und mit einem Rechner verbunden werden kann.

Zwischen dem microSD-Slot und der USB-C-Buchse findet sich noch eine Öse, an welcher ein Band befestigt werden kann. Mitgeliefert wird ein solches Band allerdings nicht.

Das Herz der Maschine

Herz des Flipper Zero ist der STM32WB55, einem Mikrocontroller von STMicroelectronics. In diesem befindet sich ein ARM Cortex M4, welcher mit 64 MHz getaktet ist und als Applikationsprozessor dient, sowie ein ARM Cortex-M0+ welcher mit 32 MHz getaktet ist und als Netzwerkprozessor dient. Daneben verfügt der Mikrocontroller über 1 Megabyte Flashspeicher und 256 KByte SRAM.

In der Theorie sollte der Flipper Zero mit einer Batterieladung ungefähr 30 Tage durchhalten. So zumindest die Aussage während der Kickstarter-Kampagne. Mittlerweile werden sieben Tage Laufzeit angegeben. Es handelt sich um eine LiPo-Batterie mit einer Kapazität 2000 mAh. Geladen wird diese über den USB-C-Anschluss des Flipper Zero.

Im Gerät selbst sind eine Vielzahl an meist drahtlosen Schnittstellen implementiert. Im Kontext des Gerätes werden diese auch als Subsysteme bezeichnet.

Sub-Ghz-System

Der Flipper-Zero besitzt eine Antenne für Frequenzen unterhalb eines Gigahertz, welche in Verbindung mit dem CC1101-Chip genutzt wird. In der Terminologie des Gerätes ist dies das sogenannte Sub-Ghz-System. Innerhalb dieses Frequenzbereiches bewegen sich eine Reihe von Geräten, wie Garagentore, Autoschlüssel, mehr oder weniger smarte IoT-Geräte, wie schaltbare Steckdosen, was nicht weiter verwunderlich ist, da ein Teil der Frequenzen unterhalb eines Gigahertz zu den ISM-Bändern gehören.

Auch wenn das System als Sub-Ghz-System bezeichnet wird, bedeutet dies nicht, dass mit dem Flipper Zero alle Frequenzen unterhalb eines Gigahertz genutzt werden können.

Der CC1101 von Texas Instruments wird als sparsamer Transceiver angeboten. Er unterstützt die Frequenzbänder 300–348 MHz, 387–464 MHz und 779–928 MHz. Damit stehen auch nur diese Frequenzen im Sub-Ghz-System zur Verfügung.

Im Flipper Zero befindet sich auch ein Frequenzscanner; mit dem innerhalb dieser Bänder ermittelt werden kann, auf welcher Frequenz das System sendet. Dazu wird der entsprechende Sender aktiviert, während der Frequenzscanner läuft.

Der Frequenzscanner in Verbindung mit einem Autoschlüssel

Signale können im Sub-Ghz-System auch roh aufgezeichnet werden. Allerdings sollte beachtet werden, dass es sich beim Flipper Zero nicht um ein Software Defined Radio (SDR) handelt und somit das Signal bei der Rohaufzeichnung nicht immer komplett aufgezeichnet wird.

RFID

Neben dem Sub-Ghz-System, werden 125 kHz RFID-Tags, welche auch als Low Frequency-Tags bekannt sind, unterstützt. Der Flipper Zero unterstützt mehrere Modulation, wie Amplitudenmodulation, Phasenumtastung und Frequenzumtastung im Zusammenhang mit diesen Tags.

Zu den unterstützten Karten zählen EM400x, EM410x, EM420x, HIDProx, Indala. Diese werden unter anderem zur Zugangskontrolle genutzt. Solche Karten können mit dem Flipper einfach ausgelesen und geklont werden.

Near Field Communication

Im Rahmen der erfolgreichen Kickstarter-Kampange kam die Unterstützung für Near Field Communication, kurz NFC hinzu, was das Gerät in diesem Bereich abrundet.

Bei RFID sind eine Reihe von Frequenzbereichen definiert, das Band zwischen 125 und 134,2 kHz (Low Frequency), das Band auf 13,56 MHz (High Frequency) und das Band zwischen 856 und 960 MHz (Ultra High Frequency).

NFC setzt ebenfalls auf der Frequenz 13,56 MHz auf und nutzt diese für entsprechende Übertragungen über kurze Entfernungen von wenigen Zentimetern.

Während RFID auf hohe Reichweite optimiert ist, meist primitive Protokolle nutzt, keine bzw. wenig Sicherheit bietet, sieht dies bei NFC-Tags anders aus. Hier wird auf komplexere Protokolle und kryptografische Absicherung gesetzt.

Im Gegensatz zu RFID ist bei NFC der bidirektionale Datenaustausch zwischen zwei Geräten möglich. Hier unterstützt das Gerät aktuell unterschiedlichste Standards, wie ISO-14443A/B, NXP Mifare® Classic/Ultralight/DESFire, FeliCa™ und die NFC Forum-Protokolle.

Damit ist das Gerät zu einer Vielzahl an Karten, wie Kreditkarten und dem Personalausweis kompatibel. Auch Zugangschips, wie sie in vielen Gebäuden benutzt werden, können ausgelesen werden. Je nach Möglichkeit wird nach der generellen Erkennung einer Karte; die Bearbeitung in einer speziellen Applikation innerhalb der Firmware vorgeschlagen.

Die UID wurde ausgelesen

Wird z. B. ein Mifare Classic eingelesen, so können anschließend mit der entsprechenden App die Schlüssel ausgelesen werden.

Auch Amiibos können emuliert werden

Grundsätzlich beherrscht der Flipper Zero bei allen Subsystemen nicht nur das Auslesen der Informationen, sondern auch die Emulation z. B. die entsprechender NFC-Tags. So ist z. B. die Emulation von Amiibos für die Nintendo Switch ohne Probleme möglich.

Bluetooth

Eine weitere Funktechnik, die der Flipper Zero beherrscht, ist Bluetooth Low Energy in Version 5, bei einer Datenrate von 2 Mbps.

Bluetooth muss hierbei in den Einstellungen der Flipper aktiviert werden, anschließend kann es unter anderem dafür genutzt werden sich mit der mobilen App zu verbinden.

Daneben befindet sich unter den Plugins eine Beispielapplikation zur Nutzung als Bluetooth-Fernbedienung.

Infrarot

Infrarot ist nicht erst seit dem Start des James-Webb-Teleskops in aller Munde. Der Flipper Zero verfügt über einen Infrarot-Transceiver zum Senden und Empfangen entsprechend kodierter Signale. Der Transceiver arbeitet bei einer Wellenlänge von 800 bis 950 nm.

In der Firmware selbst wird hierfür eine Applikation mitgeliefert, welche als eine Art Universalfernbedienung fungiert und per Wörterbuch-Attacke alle entsprechenden IR-Codes sendet, um den Kanal zu wechseln oder das Gerät abzuschalten. Damit wäre es beispielhaft möglich im Elektronikmarkt alle Fernseher abzuschalten; auch wenn es sicherlich sinnvollere Varianten der Nutzung gibt.

iButton

Eine kontaktbehaftete Schnittstelle, welche vom Flipper Zero unterstützt wird, ist die iButton-Schnittstelle. Diese auch als Dallas Touch Memory bekannte Technik wird z. B. zur Zugangskontrolle in Gebäuden benutzt.

Die Kontaktpunkte für die Schnittstelle

Hierbei wird der iButton auf eine entsprechende Schnittstelle gelegt und ein mechanischer und elektrischer Kontakt hergestellt. Anschließend findet die Kommunikation über 1-Wire statt.

Hierfür wurde am Flipper Zero eine Kontaktmöglichkeit auf der Unterseite des Gerätes geschaffen, mit welcher die entsprechende Hardware ausgelesen, beschrieben und emuliert werden kann. Unterstützt werden die Protokolle CYFRAL und Dallas DS1990A.

GPIO

Die Einsatzmöglichkeiten des Flipper Zero sind nicht nur auf Funktechnologien beschränkt. Über die GPIOs, welche sich oben am Gehäuse befinden, kann das Gerät mit externer Hardware verbunden werden.

Die GPIO-Leiste des Flipper Zero

Damit ist es möglich den Flipper für das Flashen von Hardware oder das Debugging und Fuzzing zu benutzen. Über diese Funktionalität kann das Gerät auch als USB-UART-Bridge genutzt werden.

Der Flipper Zero unterstützt die Spannungen 3,3 und 5 Volt, wobei letztere in den Einstellungen aktiviert werden muss. Pro Pin werden maximal 20 mA geliefert.

Im Shop des Herstellers werden unter anderem Entwicklungsboards mit Wi-Fi und entsprechende Prototyping-Boards angeboten.

Visuell, Taktil und Musikalisch

Neben dem Bildschirm gibt der Flipper Zero über eine LED, einen Buzzer, sowie per Vibration Rückmeldung an die Außenwelt und den Nutzer. Der eingebaute Buzzer arbeitet in einer Frequenz von 100 bis 2500 Hz, bei einer maximalen Lautstärke von 87 dB.

Das Plugin MusicPlayer auf dem Flipper Zero

Er kann mit der in der Firmware integrierten Musik-App getestet werden. In den Einstellungen kann die Lautstärke generell auf null reduziert werden, sodass das Gerät auch weniger auffällig benutzt werden kann.

Bad USB und U2F

Über den USB-Port, kann das Gerät zum Pentesting per USB genutzt werden. Diese als Bad USB firmierte Technik, emuliert eine USB-Tastatur und kann entsprechende Skripte ausführen. Dazu wird das gewünschte Skript ausgewählt und das Gerät an den Rechner der Wahl angeschlossen.

Als Skriptsprache wurde Ducky Script implementiert, sodass eventuell vorhandene Skripte übernommen werden können. Bekannt ist Ducky Script durch Rubber Ducky, einem Keystroke-Injection-Tool.

Genutzt wird diese Funktionalität z. B. bei Sicherheitsüberprüfungen von Unternehmen, bei welchen als gewöhnliche USB-Sticks getarnte Bad USB-Geräte vor oder im zu testeten Unternehmen platziert werden. Die Hoffnung ist es, dass der Finder dieser Sticks diese am Arbeitsrechner anschließt und damit die entsprechenden Skripte zur Ausführung bringt.

Natürlich kann das Ganze auch für unlautere Zwecke genutzt werden. Damit handelt sich um eine der vielen Dual-Use-Funktionalitäten des Flipper Zero.

Daneben gibt es Unterstützung für U2F, also für eine entsprechende Zwei-Faktor-Authentifizierung, wie sie z. B. auch mit dem YubiKey umgesetzt wird.

Einrichtung

Nachdem der Flipper Zero ausgepackt wurde, kann mit der Ersteinrichtung begonnen werden. Der Flipper Zero verfügt über einen microSD-Port, in welchem eine entsprechende microSD-Karte hinterlegt werden sollte. Bei zu kurzen Fingernägeln, kann der Vorgang des Einsetzten der Karte etwas unpraktisch sein, ist aber mit etwas Geschick zu bewerkstelligen.

In der Theorie funktioniert das Gerät auch ohne eine entsprechende microSD-Karte, allerdings ist die Praktikabilität etwas eingeschränkt, da auf der microSD-Karte entsprechende Datenbanken und Ähnliches gespeichert werden.

Eine microSD-Karte wird nicht mitgeliefert. Bei der Wahl der Karte sollte auf Karten von Markenherstellern gesetzt werden. Hintergrund ist, dass der Flipper Zero per SPI-Modus auf die Karten zugreift, während bei einem Rechner im Normalfall mit dem SDIO-Modus gearbeitet wird.

Bei günstigen microSD-Karten ist die Unterstützung für den SPI-Modus in vielen Fällen fehlerhaft oder unzureichend implementiert und kann zu Problemen führen.

Unterstützt werden microSD-Karten bis zu einer Kapazität von 128 GB, allerdings genügt in den meisten Fällen eine Karte mit einer Kapazität von 16 oder 32 GB. Die microSD-Karte für den Flipper Zero kann FAT32 oder exFAT formatiert sein.

Die Formatierung kann auch über das Gerät selbst vorgenommen werden, sodass hier keinerlei Vorbereitung am Rechner notwendig ist. Dabei wird die microSD-Karte bis zu einer Größe von 32 GB mit FAT32 formatiert, darüber hinaus mit exFAT.

Firmware-Update

Da der Flipper Zero mit einer relativ alten Firmware ausgeliefert wird, sollte im ersten Schritt die entsprechende Firmware aktualisiert werden. Dazu soll laut Anleitung die Webseite update.flipperzero.one besucht werden, welche die entsprechenden Möglichkeiten des Updates aufzeigt.

Angeboten werden zwei Möglichkeiten, das Gerät zu aktualisieren. Bei der ersten Möglichkeit wird die Applikation qFlipper genutzt, welche als Desktop-Anwendung unter Linux, macOS und Windows zur Verfügung steht.

Daneben existiert mittlerweile auch die Möglichkeit das Gerät über die entsprechende mobile App (iOS, Android) zu aktualisieren. Allerdings steht diese Möglichkeit erst neueren Firmware-Versionen zur Verfügung, sodass bei der Erstaktualisierung die qFlipper-Applikation genutzt werden muss.

‎Flipper Mobile App
Preis: Kostenlos
Flipper Mobile App
Preis: Kostenlos

Neben diesen beiden Methoden wird unter my.flipp.dev an einer Methode gearbeitet, die Aktualisierung über den Browser vorzunehmen. Diese wird allerdings noch als experimentell eingestuft und sollte nicht genutzt werden.

Das Firmware-Update wird durchgeführt

Nachdem Start der Applikation kann der Flipper Zero mit dem Rechner verbunden werden. Wurde dieser erkannt, kann das Update gestartet werden.

qFlipper weist auch darauf hin, ob eine microSD-Karte im Gerät erkannt wurde. Auch ohne microSD-Karte kann die Firmware-Aktualisierung vorgenommen werden. Wird später eine entsprechende Karte im Gerät installiert, können die entsprechenden Datenbanken ebenfalls über qFlipper auf diesem installiert werden.

Die eigentliche Aktualisierung selbst dauert nur knapp eine bis zwei Minuten und ist relativ schnell abgeschlossen. Damit ist das Gerät einsatzbereit und kann genutzt werden.

Der grüßende Delfin

Am Anfang begrüßt der Cyberdelfin den Nutzer und bedankt sich unter anderem für die Unterstützung auf Kickstarter. Anschließend kann das Gerät genutzt werden.

Der Delfin bedankt sich für die Unterstützung

Der Delfin ist hierbei eine Anspielung auf die Kurzgeschichte Johnny Mnemonic, von William Gibson, in welcher ein entsprechender Cyberdelfin mit dem Namen Jones vorkommt.

Die Steuerung erfolgt, wie oben erwähnt, über das Steuerkreuz und den Bestätigungs- bzw. Zurück-Button.

Mit einem Druck des Rechts-Button wird der Pass des Cyberdelfins angezeigt. Der Cyberdelfin ist ein elementarer Bestandteil des Flipper Zero und soll eine Art Tamagotchi-Erlebnis liefern. Neben einem Namen, der automatisch für das Gerät vergeben wird, verfügt der Delfin über ein Level, das aktuell bis Level 3 gesteigert werden kann. Dieses Level steigt mit der Nutzung Flipper Zero. Daneben verfügt der Delfin über eine Gemütslage, von Glücklich zu Okay bis hin zu Schlecht. Der Name wird bei der Produktion fest vergeben. Dazu wurde ein neuronales Netz mit den Namen der Pokémon trainiert.

Ein Druck auf den Oben-Button führt zum Sperrmenü des Flipper Zero. In diesem kann das Gerät gesperrt werden, eine PIN gesetzt und in der Theorie der sogenannte DUMB mode aktiviert werden.

In diesem noch nicht implementierten Modus, soll das Gerät nur noch Spiele spezifische Funktionalität anzeigen und somit wie ein Spielzeug aussehen, falls es einmal unauffälliger zugehen soll.

Die Links- und Unten-Buttons können im Menü frei belegt werden und sind im Auslieferungszustand mit dem Sub-Ghz-System und dem NFC-System belegt.

Ein Druck auf die mittlere Taste öffnet das Menü. Neben dem Zugriff auf die unterschiedlichen Subsysteme finden sich hier die Einstellungen und die Plugins. Eines der Plugins ist das Spiel Snake, sodass Freunde eines alten Nokia-Telefons auf ihre Kosten kommen.

In den Einstellungen können Informationen zur Hardware eingesehen werden, das System konfiguriert und Informationen über den genauen Stromverbrauch des Gerätes ermittelt werden.

Neben der Bedienung über das Menü- bzw. das Steuerkreuz gibt es einige Spezialkombinationen. Für einen Neustart z. B. wird das Steuerkreuz nach links gedrückt und gleichzeitig die Zurück-Taste für einige Momente gedrückt. Der Neustart ist nach knapp zwei Sekunden abgeschlossen und das Gerät kann dann wieder genutzt werden.

Kompanion-Applikationen

Bei Firmware-Upgrade wurde bereits erläutert, dass es für den Flipper Zero unterschiedliche Applikationen existieren. Diese sollen noch einmal kurz im Detail beleuchtet werden.

qFlipper

Die Applikation qFlipper, dient unter anderem der Aktualisierung des Gerätes. Daneben können dort Informationen über die Firmware und die Datenbanken ermittelt werden.

qFlipper bietet ein Update an

Was die Firmware-Aktualisierungen betrifft, ermöglicht qFlipper die Auswahl der entsprechenden Channels, sodass der Flipper Zero auch mit der Entwicklungsfirmware bespielt werden kann.

Auch ein Zugriff auf die microSD-Karte ist über qFlipper möglich, sodass über diesen Weg Dateien auf die microSD-Karte gelegt werden können oder von dort heruntergeladen werden können.

Der Quelltext der App ist auf GitHub verfügbar und unter der GPL3 lizenziert und damit freie Software. Technisch handelt es sich um eine in C++ geschriebene Applikation, welche das Qt-Framework nutzt.

App für Mobilgeräte

Neben qFlipper existieren für iOS und Android entsprechende mobile Apps. Mit dieser kann die Firmware ebenfalls aktualisiert werden und es können interne Informationen über das Gerät eingesehen werden.

Über die mobilen Apps können unter anderem die ausgelesenen Schlüssel verwaltet werden

Ein wichtiges Feature der Applikation ist die Verwaltung eingelesener Schlüssel und Ähnlichem. Über den Archive-Tab der Applikationen können diese bequem verwaltet und entsprechend benannt werden.

Zwar verfügt der Flipper Zero über eine Bildschirmtastatur, über welche die Schlüssel benannt werden können, allerdings ist dies mit den mobilen Applikationen wesentlich angenehmer.

Auch das Streaming des Bildschirminhaltes des Flipper Zero, z. B. für Screenshots, ist mit der App möglich. Genau wie die qFlipper-Applikation enthalten die mobilen Apps einen Dateimanager, um auf den internen und externen Speicher des Flipper Zero zuzugreifen.

My Flipper

Neben diesen nativen Applikationen existiert mit My Flipper eine Webapplikationen, welche aktuell nur im Browser Chrome funktioniert. Geschuldet ist dies der Nutzung der Web Serial API.

Die Webapplikation My Flipper

Über die Webapplikation, können Spielereien vorgenommen werden, z. B. die Nutzung des Flippers als Ausgabegerät für Zeichnungen, welche in der Webapplikation vorgenommen werden oder auf die Kommandozeile zugegriffen werden.

Kommandozeile

Dies funktioniert auch per Terminal z. B. unter macOS. Dazu muss nach dem Anschluss des Flipper Zero das entsprechende Gerät ermittelt werden:

ls /dev/cu.usbmodemflip*

Nun kann sich mit dem Gerät verbunden werden:

screen /dev/cu.usbmodemflip_Uchfun1

Über die Kommandozeile können unter anderem die GPIO-PINs gesteuert werden.

Dokumentation und Community

Mit docs.flipperzero.one verfügt der Flipper Zero über eine entsprechende Dokumentation, welche im Moment allerdings noch an vielen Stellen lückenhaft oder nicht vorhanden ist.

Wohl unter anderem deshalb sucht Flipper Devices nach einem Technical Writer.

Allerdings hilft die Community bei vielen Fragen rund um das Gerät weiter. Neben dem offiziellen Forum existiert ein entsprechender Discord-Server.

Eine weitere Auflistung rund um die Community und interessanter Projekte rund um den Flipper Zero findet sich bei Awesome Flipper, welches sich als guter Einstiegspunkt anbietet.

Die offiziellen Applikationen rund um den Flipper Zero, sowie die Firmware sind auf GitHub verfügbar. Die mobilen Applikationen sind unter der MIT-Lizenz, qFlipper und die Firmware unter der GPL3 lizenziert und damit freie Software.

Made in Russia

Mit dem Projekt, wurde die Firma Flipper Devices Inc., nach US-amerikanischem Recht gegründet und registriert, bei welcher es sich, zumindest was den Sitz in den USA angeht, um eine Briefkastenfirma handelt.

Das eigentliche Büro des Projektes bzw. der Firma befindet sich Moskau. Mit der Invasion der Ukraine stellte sich die Frage, ob die Geräte aufgrund der politischen Lage noch ausgeliefert werden. Das Team formulierte seine Gedanken und die entsprechenden Informationen darüber klar:

Our team consists of both Ukrainians and Russians. And all of us have friends and relatives on both sides. We are all very worried about the ongoing events and consider it necessary to speak out.

We are radically against the ongoing „special military operation*“ and none of our team members support it. All sensible Russian-speaking professionals in the IT industry adhere to the same opinion.*

We want to live and develop in a peaceful, professional, and competitive environment where the main values are honesty, common sense, laws, and human rights. Where contracts are respected, institutions work, and international business can be created.

Current events will not affect the Flipper Zero production in any way, and all ordered devices will be shipped to backers and those who have pre-ordered, though there may be delays for customers from the CIS countries due to logistics disruptions in the region.

*We refer to these events using the „officially approved“ wording in order to comply with the new law, violation of which is punishable by up to 15 years in prison.

Hier bleibt es zu beobachten, wie sich die Lage in den nächsten Jahren entwickelt und ob dies die Weiterentwicklung des Gerätes beeinträchtigt.

Fazit

Nachdem das Projekt bei Kickstarter ein großer Erfolg wurde, änderte das Team seine Pläne hinweg von einer Kleinserie für wenige Professionelle hin zu einem professionellen Anbieter von Pentesting-Geräten. Neben dem eigenen Shop soll in Zukunft auch über Plattformen wie Amazon geliefert werden.

Auf der Hardware-Seite erhält der Nutzer ein ausgereiftes Gerät und auch die Firmware weiß an einigen Stellen bereits zu glänzen, auch wenn es hier noch weiterführende Pläne gibt.

Aktuell findet der Support für das dynamische Laden von ELF-Binäries für die Plugins in der Erprobung. Im Moment müssen diese direkt mit der Firmware kompiliert und anschließend die Firmware geflasht werden. Das eröffnet die Möglichkeit, unterschiedlichste Plugins einfach mit dem Gerät nutzen zu können.

Bis zur Version 1 der Firmware, soll unter anderem die Dokumentation wesentlich verbessert und die Anzahl der unterstützten Funkprotokolle erhöht werden.

Die Kompanion-Applikationen wirken ausgereift und werden sicherlich in Zukunft durch entsprechende Updates aufgewertet.

Während das Gerät für Backer 119 US-Dollar kostete, beträgt der reguläre Retail-Preis 169 US-Dollar. Bestellt werden kann es über den offiziellen Shop, wobei mit längeren Lieferzeiten zu rechnen ist. Wer als Kickstarter-Backer seinen Flipper Zero noch nicht in den Händen hält, kann den aktuellen Status der Auslieferung auf ship.flipp.dev verfolgen.

Alles in allem erhält der Nutzer ein Gerät, welches viele Funktionalitäten, welche es früher nur einzeln gab, in einem kompakten System zusammenfasst. Mit weiteren Verbesserungen und Erweiterungen der Firmware und Kompanion-Applikationen wird der Flipper Zero zu einem wertvollen Begleiter.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Von Codierungen und Vereinheitlichung

Unicode erblickte vor knapp dreißig Jahren das Licht der Welt und brachte ein wenig Ordnung in die babylonische Vielfalt der Kodierungsstandards. Auch wenn er oft genutzt wird, gibt es doch viel Halbwissen rund um diesen Standard.

Wenn eine Datei mit einem Text eingelesen wird, so besteht diese für den Computer nur aus einer Abfolge von Daten, ohne eine wirkliche Bedeutung. Dass wir am Ende in dieser Datei Eine Geschichte zweier Städte von Charles Dickens finden, ist dem Umstand geschuldet, dass sich auf die Codierung dieser Daten geeinigt wurde.

Für die Codierung von Text wurden viele Codierungen erdacht und in der Praxis eingesetzt, vom Morsecode über den Baudot-Murray-Code, welcher als 5-Bit-Code die Tastenstellung eines Telegrafengerät kodierte, bis zum American Standard Code for Information Interchange, kurz ASCII, der für viele Jahre das Fundament der Textkodierung in der IT darstellte.

Eine Telegraphen-Tastatur

Mit Unicode, welcher vor etwa 30 Jahren das Licht der Welt erblickte, wurde ein wenig Ordnung in die babylonische Vielfalt der Codierungsstandards gebracht, was wegen der Internationalisierung der IT dringend nötig war. Und damit ist dieser Standard aus der Vergangenheit gleichzeitig die Zukunft.

ASCII und EBCDIC

Wie vieles in der IT, baut auch Unicode auf einem historischen Erbe auf, in diesem Fall dem ASCII-Standard. In diesem 1963 verabschiedeten Standard waren in einer 7-Bit-Codierung 128 Zeichen kodiert. Neben dem lateinischen Alphabet, also den Zeichen von A bis Z, jeweils in Groß- und Kleinschreibung, den Ziffern und einigen Sonderzeichen, befanden sich in diesem auch etliche Steuerzeichen.

Zu diesen Steuerzeichen gehören bekannte Zeichen wie der Tabulator oder der Zeilenvorschub, als auch weniger bekannte Zeichen wie die Glocke (Bell). Genutzt wurden diese Zeichen zur Steuerung der Geräte, welche mit dem ASCII-Code umgehen sollten.

Technisch betrachtet wurden im ASCII-Code eigentlich nur 126 Zeichen kodiert. Der Hintergrund hierfür ist historisch begründet. Das Zeichen 0 (kodiert als Bits 0000000) wird genutzt, um die Nichtexistenz von Daten anzuzeigen. Im Kontext einer Lochkarte werden keine Löcher im entsprechenden Bereich gestanzt.

Das Gegenteil hiervon ist das Zeichen 127 (1111111), welches festlegt, dass die Daten auf diesem Feld als gelöscht gelten; auch hier wieder der Lochkarten-Hintergrund, bei welchem im Fehlerfalle bestehende Löcher nicht mehr geschlossen werden können bzw. sollten und somit alle Löcher gelocht werden, um ein gelöschtes Datum zu symbolisieren.

Eine ASCII-Tabelle in einem Drucker von General Electric aus den 70er Jahren

Da sie in dieser Form nicht mehr benötigt wurden, wurden diese Zeichen teilweise anders genutzt. In vielen Programmiersprachen stellt das Zeichen 0 das Ende einer Zeichenkette dar. Somit können in diesen Sprachen, wie z. B. C, Zeichenketten abgespeichert werden, ohne dass die entsprechende Länge bekannt sein muss, im Gegensatz zu Sprachen wie z. B. Pascal.

In seiner heutigen Form wurde der ASCII-Code nach einigen kleineren Änderungen schließlich 1968 verabschiedet. Neben dem ASCII-Code wurde von IBM der Extended Binary Coded Decimal Interchange Code (EBCDIC) entwickelt, welcher vorwiegend auf Großrechnern genutzt wurde. Diese Entwicklung fand zwischen 1963 und 1964 statt und wurde mit dem System/360 der Öffentlichkeit vorgestellt.

Im Westen nichts Neues

Aus Sicht der westlichen Welt war der ASCII-Code für viele Dinge gut genug. So können Umlaute im Deutschen leicht ersetzt werden, z. B. das Zeichen ä durch ae. Allerdings wurde dies nicht immer gemacht und war auch nicht immer gewünscht.

Um andere Zeichen wie Umlaute oder Akzentzeichen abzubilden, entstanden 8-Bit Codes basierend auf dem ASCII-Code, welche somit die doppelte Zeichenanzahl unterbringen konnten.

In Westeuropa hat sich hierbei insbesondere der Standard ISO/IEC 8859-1 etabliert, besser bekannt unter dem Namen Latin-1. Ziel dieses Standards war es, möglichst viele Zeichen westeuropäischer Sprachen abzubilden. Unter Windows wurde eine abgewandelte Form dieses Zeichensatzes unter dem Namen Windows-1252 genutzt.

Durch die ISO standardisiert sind daneben Zeichensätze für weitere europäische Regionen wie Griechisch, aber auch Kyrillisch, Arabisch, Thai und Hebräisch.

Daneben existieren andere 8-Bit-Codierungen, welche teilweise nur mit ihren jeweiligen Anwendungen bzw. Betriebssystemen kompatibel waren und nicht standardisiert sind. Ein Beispiel für eine solche Codierungen ist CBM-ASCII, in welcher unter anderem Zeichen für Blockgrafik enthalten waren und welche bei vielen Heimcomputern von Commodore zum Einsatz kam.

Zeichensalat

Die Nutzung unterschiedlicher Codierungen führt aber auch zu Problemen. Wird ein Dokument z. B. mit der falschen Codierung geöffnet, so erhält der Nutzer in solchen Fällen sogenannten Zeichensalat:

Falsches Üben von Xylophonmusik quält jeden größeren Zwerg.

Auch Texte, in denen mehrere Sprachen vorhanden sind, ließen sich mit diesen bestehenden Codierungen nicht einfach umsetzen.

Noch ein Standard?

Mit der Globalisierung und dem Austausch von Dokumenten über Sprach- und Systemgrenzen hinweg entwickelte sich die Vielfalt an Codierungen zu einem Problem.

Die ISO/IEC 2022 versuchte dieses Problem zu lösen. Bei diesem Standard kann unter Zuhilfenahme verschiedener Escape-Sequenzen zwischen den unterschiedlichen Zeichensätzen umgeschaltet werden. Durchgesetzt hat sich dieser Standard nur in Japan, Korea und China, in erster Linie im Kontext E-Mail; da der Standard auch entsprechende 7-Bit-Codierungen definiert.

Schlussendlich kam es zur Entwicklung von Unicode. Wie so viele Entwicklungen, die die IT weiter brachten, hatten sie etwas mit Xerox zu tun. Vom PARC Universal Packet, welches maßgeblich das Design von TCP/IP beeinflusste, bis zum WIMP-Paradigma (Windows, Icons, Menus, Pointer), dem wir unsere modernen Desktop-Oberflächen und Interface-Konzepte verdanken.

Dort entstand der Xerox Character Code Standard, welcher als inoffizieller Vorgänger des Unicode-Standards betrachtet werden kann. Joseph D. Becker, welcher sich bei Xerox schon länger mit multilingualer Software befasste und unter anderem 1984 das Paper Multilingual Word Processing dazu verfasste, ist einer der Erfinder und Gestalter von Unicode.

Die eigentliche Entwicklung von Unicode begann 1987. Neben Joseph D. Becker arbeiteten Lee Collins und Mark Davis, damals bei Apple angestellt, ebenfalls an dem neuen Standard, welcher ein universelles Set von Zeichen darstellen sollte, in welchem die aktuellen Schriftsysteme der Zeit enthalten sein sollten. In der damaligen Entwurfsphase war es noch nicht das erklärte Ziel historische Schriftsysteme abzubilden:

Unicode gives higher priority to ensuring utility for the future than to preserving past antiquities. Unicode aims in the first instance at the characters published in modern text (e.g. in the union of all newspapers and magazines printed in the world in 1988), whose number is undoubtedly far below 2^14 = 16,384. Beyond those modern-use characters, all others may be defined to be obsolete or rare; these are better candidates for private-use registration than for congesting the public list of generally-useful Unicodes.

Im Laufe des Jahres 1989 stießen zur Gruppe um Becker, Mitarbeiter von Metaphor, RLG und Sun Microsystems hinzu. 1990 wurde das Team um Mitstreiter von Microsoft und NEXT erweitert.

Ende desselben Jahres war der Standard dann so weit gediehen, dass am 3. Januar 1991 das Unicode Consortium gegründet wurde. Dieses setzte einige Monate später im Oktober des Jahres den ersten Unicode-Standard in die Welt.

Allerdings wurde dies nicht überall so verstanden. In der TrueType Spezifikation in Version 1.0 für das entsprechende Font-Format erhielt der Standard die Plattform-ID Apple Unicode, was allerdings ein Irrtum war, welcher mittlerweile korrigiert wurde.

Beim Unicode Consortium selbst handelt es sich um eine gemeinnützige Organisation, mit Sitz in Mountain View in Kalifornien. Sie sorgt für die Weiterentwicklung des Standards und die Aufnahme weiterer Zeichen. Zu den Mitgliedern gehören unter anderem Adobe, Apple, Google und Netflix, aber auch Institutionen wie das Bangladesh Computer Council.

Aufbau

Grundsätzlich definiert der Unicode-Standard einen sogenannten Codespace. Jedem Zeichen wird eine Nummer innerhalb dieses Codespace zugewiesen. Ein vergebener Wert für ein Zeichen innerhalb dieses Codespace wird als Code Point bezeichnet und stellt die Grundlage von Unicode dar. So entspricht z. B. der Code Point 2126 dem Omega-Zeichen (Ω). Der Umfang dieses Codespace erstreckt sich von 0 bis 10FFFF.

Genau betrachtet stellt ein Code Point aber nicht unbedingt ein Zeichen dar, da es Zeichen gibt, welche sich aus mehreren Code Points zusammensetzen. So könnte ein Ä als A mit einem Trema (die Punkte über dem Ä), also mit zwei Code Points, dargestellt werden.

Auch werden keine Repräsentationen der Zeichen durch den Unicode-Standard vorgegeben. Stattdessen handelt es sich um abstrakte Zeichen, welche definiert werden. Ihre jeweilige Ausgestaltung ist z. B. entsprechenden Fonts vorbehalten.

Allerdings ist der Adressraum von Unicode nicht flach, sondern in sogenannte Planes unterteilt. Eine Plane entspricht hierbei 2^16, also 65.536 Code Points. Insgesamt sind 17 Planes (Plane 0 bis 16) im Standard definiert. Damit ist das aktuelle Limit an Zeichen in Unicode auf 1.114.112 festgelegt. Nach dem Abzug von Regionen für die private Nutzung bleiben am Ende in etwa 970.000 Code Points für die öffentliche Nutzung übrig.

Die Planes sind nach bestimmten Kriterien unterteilt und definiert. Aktuell genutzt respektive definiert sind sieben dieser Planes, wobei zwei davon für die private Nutzung definiert sind und somit im Unicode-Standard keinerlei Zeichen zugewiesen bekommen.

Die wichtigste und zuerst definierte Plane ist die Basic Multilingual Plane (BMP) mit der ID 0. In dieser sind die Zeichen für die meisten aktuell genutzten Sprachen, definiert. Grundsätzlich sollten in dieser Plane alle Zeichen definiert werden, welche in modernen Schriftsystemen rund um die Welt Verwendung finden. Hier finden sich neben Symbolen und lateinischen Buchstaben hauptsächlich die Zeichen aus der chinesischen, japanischen und koreanischen Sprache.

Die Basic Multilingual Plane

Innerhalb der Planes werden die Code Points in sogenannten Blöcken gruppiert. So existieren in der BMP 164 solcher Blöcke. In diesen Blöcken werden Schriftzeichen thematisch gruppiert, so z. B. der Block für lateinische Buchstaben, für Thai, für mathematische Operatoren oder geometrische Formen. Die Größe eines Blockes hängt von der Anzahl der zu kodierenden Code Points ab, ist aber immer ein Vielfaches von 16.

Neben dieser Plane existieren noch die Supplementary Multilingual Plane mit der ID 1, die Supplementary Ideographic Plane mit der ID 2, die Tertiary Ideographic Plane mit der ID 3 und die Supplementary Special-purpose Plane mit der ID 14.

In der Supplementary Multilingual Plane finden sich weitere Schriftsysteme, auch historischer Natur, wie ägyptische Hieroglyphen oder Zeichen zur Notation von Musik. Auf der Supplementary Ideographic Plane finden sich weitere sogenannte CJK-Zeichen also Schriftzeichen aus dem Chinesischen, Japanischen, Koreanischen und Vietnamesischen. Neben einigem historischen Schriftsystemen wie dem Oracle bone script, einem Vorgänger der chinesischen Schrift, welcher auf Orakelknochen gefunden wurde, ist die Tertiary Ideographic Plane größtenteils leer. Die Supplementary Special-purpose Plane wird für bestimmte Spezialzeichen genutzt, die z. B. im Zusammenhang mit Emojis zum Tragen kommen.

Die Planes 4 bis 13 sind im Moment nicht belegt und somit für zukünftige Erweiterungen verfügbar. Die Planes 15 und 16 sind sogenannte Private Use Area Planes, mit welchen Zeichen kodiert werden können, welche nicht im Unicode-Standard definiert sind. Hierbei müssen sich die Anwendungen über die Bedeutung der einzelnen Zeichen bewusst sein, um diese korrekt darstellen zu können.

Teilweise sind die Zeichen innerhalb einer Plane und entsprechender Blöcke fragmentiert, da Blöcke bereits komplett belegt waren und Zeichen erst später dazukamen.

Altlasten

Neben besagter Fragmentierung befinden sich auch historische Altlasten im Unicode.

Damit bestehende Zeichensätze wie die Latin-Familie, aber auch asiatische Systeme, sinnvoll übernommen werden und einfach konvertiert werden konnten, wurden diese als Ganzes in den Standard übernommen. So entsprechen die ersten 256 Zeichen im Unicode-Standard exakt dem Standard ISO/IEC 8859-1, besser bekannt als Latin-1.

Dies führt stellenweise zu doppelten Zeichen im Unicode-Standard und auch Zeichen wie dem Ä, welches eigentlich ein zusammengesetztes Zeichen ist und als solches nach den heutigen Kriterien wohl nicht im Standard aufgenommen würde. Die meisten dieser Zeichensätze sind in der Basic Multilingual Plane gelandet.

Im Standard selbst mag dies zu einigen Problemen geführt haben und wie ein Makel wirken, aber es war eine pragmatische Entscheidung, welche die Umstellung auf Unicode vereinfachen sollte.

Im Reich der Codierungen

Um ein Unicode-Zeichen zu codieren, existieren unterschiedliche Unicode-Codierungen, sogenannte Unicode Transformation Formats (UTF). Diese unterscheiden sich in grob in Codierungen mit fester Länge wie UTF-32 und Codierungen variabler Länge wie UTF-8.

Im Standard existieren drei Geschmacksrichtungen dieser UTFs: UTF-8, UTF-16 und UTF-32. Die Zahl gibt die Minimalbits an, welche zur Codierung eines Zeichens benötigt werden. Auch wenn dies historisch betrachtet nicht immer der Fall war, da es Codierungen wie UTF-1 oder UTF-7 gab.

Im Falle von Buchstaben aus dem ASCII-Zeichensatz benötigt ein Zeichen in der Codierung UTF-8 ein Byte, kann aber bis zu 4 Byte beanspruchen, je nach dem auf welches Unicode-Zeichen verwiesen werden soll. Somit können alle Zeichen des Unicode-Standards entsprechend kodiert werden. Werden nur ASCII-Zeichen genutzt, so ist diese Codierung kompatibel mit ASCII.

Die Geschichte von UTF-8 ist eng mit der des Betriebsystems Plan-9 verbunden, welches in den 80er-Jahren in den Bell Laboratories entwickelt wurde. Die ursprüngliche Umsetzung sah vor 16-Bit breite Zeichen in Plan 9 zu nutzen. Allerdings waren die Entwickler damit unzufrieden. Ein Anruf von IBM, zu einem bevorstehenden Meeting des X/Open Komitees, führte dazu, dass Rob Pike und Ken Thompson an einem Mittwochabend die UTF-8 Codierung entwickelten und sie Plan 9 von Mittwoch zu Freitag auf UTF-8 umstellten. Ein weiterer Anruf beim X/Open Komitee und dem Eingeständnis, dass der Vorschlag von Pike und Thompson wesentlich besser war als der eigene, begann UTF-8 seinen Siegeszug.

Doch wie wird das Ganze technisch gelöst? Da es sich bei ASCII um eine 7-Bit-Codierung handelt, wird das Bit mit dem Index 7 nicht genutzt. Es ist immer Null. So wäre das Zeichen F wie folgt kodiert:

[0 1 0 0 0 1 1 0]
 7 6 5 4 3 2 1 0

Dieser Umstand wird nun für UTF-8 genutzt. Ist das Bit (Index 7) Null, so handelt es sich um ein ASCII-Zeichen, ist es Eins, so liegt eine UTF-8 Codierung vor. Das Zeichen Ä (196) sähe in der UTF-8-Codierung wie folgt aus:

[11 00 00 11] [10 00 01 00]

Die Bitfolge 11 im ersten Byte zeigt dabei an, dass es sich um das Startbyte des Zeichens handelt. Die Anzahl der Einsen am Anfang gibt hierbei an, in wie vielen Bytes das Zeichen kodiert ist. Das Yen-Zeichen ¥ würde in UTF-8 wie folgt kodiert werden:

[11 10 11 11] [10 11 11 11] [10 10 01 01]

Hier zeigt das Startbyte drei Einsen am Anfang. Damit ist klar, dass dieses Zeichen in drei Byte kodiert wird. Die folgenden Bytes sind die sogenannten Folgebytes und sind an der Bitfolge 10 am Anfang zu erkennen.

Nach den aktuellen Unicode-Regeln darf ein UTF-8-Zeichen maximal 4 Byte in Anspruch nehmen, auch wenn die Art der Codierung in der Theorie mehr Bytes nutzen könnte. Zu den jeweiligen Codierungen zählen weiterhin bestimmte Feinheiten, die im Rahmen dieses Artikels nicht im Detail besprochen werden sollen, da sie für das Grundprinzip der Codierung unerheblich sind. So dürfen unter anderem bestimmte Bitfolgen nicht genutzt werden, da sie im Rahmen der UTF-8 Codierung als ungültig angesehen werden. Ein Vorteil dieser Codierung ist, dass immer klar ist, wo ein neues Zeichen beginnt und daher defekte Daten in der UTF-8-Codierung problemlos übersprungen werden können.

Bei UTF-16 wird ein Zeichen durch 16 Bit abgebildet, wenn es sich um ein Zeichen aus der Basic Multilingual Plane handelt. Bei Codierungen außerhalb der BMP werden jeweils zwei 16-Bit-Pärchen genutzt. Dies sollte allerdings nicht mit der UTF-32 Codierung verwechselt werden, da es sich trotzdem um zwei UTF-16 codierte Entitäten handelt.

UTF-32 kodiert jeden Code Point immer in vier Byte und stellt damit die speicherintensivste Codierung dar. Im gewissen Rahmen, mit Ausnahme zusammengesetzter Zeichen, bietet sie einen wahlfreien Zugriff auf die Zeichen einer Zeichenkette an. Damit kann auf Zeichen innerhalb der Zeichenkette zugegriffen werden, indem ihre Position berechnet wird, anstatt die komplette Zeichenkette von Anfang an decodieren zu müssen.

Im Zusammenhang mit den Codierungen fallen gelegentlich auch die Begriffe UCS-2 und UCS-4. Bei UCS-2 handelt es sich um eine obsolete Codierung, welche nur die Code Points der Basic Multilingual Plane codieren konnte. UCS-4 hingegen ist gleichbedeutend mit UTF-32. Die Begrifflichkeit UCS kommt vom Universal Coded Character Set aus der Norm ISO/IEC 10646.

Daneben gibt es Codierungen wie UTF-EBCDIC, welche dafür gedacht waren, Unicode auf entsprechende Mainframe-Rechnern, welche mit der EBCDIC-Codierung arbeiten, zu bringen. In der Praxis wird auf solchen Systemen, wie z/OS, aber meist UTF-16 genutzt.

Der Unterschied zwischen Codierungen fester Breite gegenüber denen variabler Breite liegt im Aufwand, die entsprechende Codierung auszuwerten. Bei den Codierungen variabler Breiten, muss ein entsprechender Rechenaufwand in das Lesen der Codierungen gesteckt werden. Dieser entfällt bei Codierungen fester Breite, allerdings ist hier der Speicherbedarf höher als bei den Codierungen variabler Breite.

Byte Order Mark

Doch wie wird erkannt, in welcher Codierung ein Dokument vorliegt? Dafür existiert das Byte Order Mark, kurz BOM. Dieses steht am Anfang einer Datei und teilt die genutzte Codierung mit.

Für UTF-8 haben viele ein solches BOM sicherlich schon einmal gesehen:



Als hexadezimale Repräsentation sieht dieses dann wie folgt aus:

EF BB BF

Bei den UTF-16 und UTF-32 Codierungen muss die Endianness, also die Reihenfolge der Bytes berücksichtigt werden. Dies wird mit dem Byte Order Mark, wie der Name es andeutet, bewerkstelligt. Ein Beispiel eines UTF-16 BOM:

 FE FF (Big Endian)
 FF FE (Little Endian)

Die Nutzung des Byte Order Mark ist optional. Ist keines gesetzt, so wird automatisch davon ausgegangen, dass die Byte-Reihenfolge Big-Endian ist.

ISO und Unicode

Mit dem Standard ISO/IEC 10646, dem Universal Coded Character Set sind die Zeichen des Unicodes auch in einem ISO-Standard verewigt. Mittlerweile werden der ISO-Standard und Unicode synchronisiert; das bedeutet, sie definieren die gleichen Zeichen.

Allerdings existieren Unterschiede zwischen diesem Standard und Unicode. Während die Namen und Code Points in beiden Standards gleich sind, spezifiziert der Unicode Standard Regeln zur Interoperabilität und liefert weitere Dinge wie entsprechende Algorithmen mit. Im Vergleich dazu stellt der ISO-Standard nur eine Zeichentabelle dar.

Im Laufe der Zeit

Während im Oktober 1991 die Unicode-Version 1.0.0, mit 7129 Code Points, veröffentlicht wurde, ist die aktuelle Version 14.0 im September 2021 erschienen und definiert ein Vielfaches an Code Points im Standard.

Dabei sind von Version zu Version immer wieder neue Zeichen hinzugekommen. Der Unicode-Standard legt fest, dass einmal eingebrachte Zeichen nie wieder aus dem Standard entfernt werden dürfen. Das bedeutet, dass sich gut überlegt werden muss, ob ein Zeichen wirklich dem Standard zugeschlagen wird.

Allerdings ist dies nicht immer so gewesen. In der Frühzeit des Standards bis einschließlich Version 2.0, welche im Juli 1996 erschien, wurden unter anderem das koreanische Alphabet in Version 2.0 entfernt und durch neue Zeichen an einer anderen Stelle in der Codeplane ersetzt. Auch in den vorherigen Versionen 1.1 und 1.0.1 wurden Zeichen entfernt.

Ab der Version 2.1 des Standards wurde sich von dieser Praxis gelöst und seitdem wird der Standard nur noch erweitert. Wird nun von der Nutzung eines Zeichens abgeraten, so wird dieses im Unicode-Standard als deprecated gekennzeichnet.

Im Oktober 2010 wurden mit dem Unicode-Standard 5.2 nicht nur Symbole für Spielkarten und weitere Schriftsysteme hinzugefügt, sondern auch Emojis feierten ihr Debüt in dieser Version. Gab es ursprünglich 722 definierte Emojis, sind diese mittlerweile angewachsen und verfügen auch über die Unterstützung unterschiedliche Hautfarben anzeigen zu können.

Mit Version 1.40 sind 144.697 Code Points definiert. Damit ist in etwa ein Siebtel des Codespace belegt. Dass das klingonische Schriftsystem darunter ist, ist im Übrigen ein Gerücht. Allerdings werden klingonische Zeichen über die privaten Bereiche des Unicode-Codespaces genutzt. Für diese privaten Bereiche innerhalb des Codespace gibt es mit der Under-ConScript Unicode Registry eine Art informelle Registry für diese.

Umsetzung in der IT

Standards und damit auch der Unicode-Standard sind nur dann sinnvoll, wenn sie umgesetzt und genutzt werden. Aktuelle Windows-Versionen und macOS-Versionen nutzen für die interne Repräsentation von Unicode UTF-16, bei Linux ist es UTF-8. Damit ist die grundlegende Nutzung in den entsprechenden Betriebssystemen gegeben.

In den Betriebssystemen selbst gibt es für den Nutzer unterschiedliche Möglichkeiten Unicode-Zeichen einzusetzen. Viele Varianten arbeiten mit der Eingabe der entsprechenden ID des Code Points in dezimaler oder hexadezimaler Repräsentation in Verbindung mit einer Taste. Unter Windows kann die Alt-Taste in Verbindung mit der entsprechenden ID zur Eingabe genutzt werden. Auch unter Linux und macOS sind solche Eingaben möglich, wobei diese unter macOS explizit aktiviert werden müssen.

Die Zeichentabelle unter Windows 10

Daneben existieren in den Betriebssystemen auch entsprechende Applikationen, wie die Zeichentabelle unter Windows, mit der Unicode-Zeichen über ein entsprechendes Interface herausgesucht und genutzt werden können.

Bei Programmiersprachen wie Java oder den auf .NET basierenden Sprachen wird intern ebenfalls mit UTF-16 gearbeitet. Unter Rust kann der primitive Typ einen sogenannten Unicode scalar value speichern. Dieser entspricht einem Code Point; allerdings sind die sogenannten Low- und High-Surrogate, welche für UTF-16 benötigt werden, hier nicht mit eingeschlossen.

Interessant ist auch die Betrachtung von Fonts in Bezug auf Unicode. Die erste Frage, die sich hier vielleicht stellt, ist ob ein Font existiert, welcher alle Unicode-Zeichen unterstützt.

Aus technischen Gründen ist dies schon nicht möglich. So kann eine TrueType-Schriftart maximal 65.535 Glyphen enthalten. Auch im OpenType-Format ist eine solche Beschränkung enthalten.

Einer der Fonts aus der Noto-Familie

Allerdings gibt es Font-Familien wie Noto, welche von Google beauftragt wurde und mittlerweile über 77.000 Code Points des Unicodes-Standards abdeckt. Daneben gibt es eine Reihe weiterer Fonts wie GNU Unifont oder WenQuanYi, welche ebenfalls eine Vielzahl an Zeichen aus dem Unicode-Zeichensatz unterstützen.

Der Name der Schriftartfamilie Noto steht für No Tofu und spielt auf das Kästchen an, welches angezeigt wird, wenn ein Font ein entsprechendes Unicode-Zeichen nicht enthält. Früher wurde hierbei häufig der Replacement Character, welcher sich in der Basic Multilingual Plane befindet, genutzt. Dieser zeigt eigentlich an, dass ein Zeichen nicht als valides Unicode-Zeichen erkannt werden konnte, also ein Kodierungsfehler vorliegt. Heutzutage wird für den Fall, dass ein valides Unicode-Zeichen vom Font nicht dargestellt werden kann, die .notdef Glyphe des entsprechenden Fonts angezeigt.

Auch bei der softwareseitigen Unterstützung von Unicode gibt es hier und da Probleme. So wurden bis in die 2000er-Jahre hauptsächlich die Code Points aus der Basic Multilingual Plane unterstützt. Andere Planes waren nicht wirklich zugänglich.

Auch die Zusammensetzung von Zeichen aus mehreren Code Points wird von vielen Anwendungen nicht richtig beherrscht. Gebessert hat sich dies unter anderem durch den Standard GB 18030 der chinesischen Regierung, welcher ebenfalls die entsprechenden Zeichen aus der Codeplane unterstützt und damit ein Unicode Transformation Format darstellt.

Dieser Standard definiert, welche Zeichen zwingend in entsprechenden Betriebssystemen und Anwendungen unterstützt werden müssen und brachte damit die Unicode-Unterstützung jenseits der Basic Multilingual Plane voran.

Auch in anderen Anwendungen, wie E-Mail kann Unicode dank des MIME-Standards seit vielen Jahren genutzt werden. Für die Codierungen von Domainnamen, mit Nicht-ASCII-Zeichen, waren ebenfalls Unicode Transformation Formate in der Entwicklung (UTF-5, UTF-6), allerdings hat sich hier Punnycode durchgesetzt.

Trotz der Durchdringung der Unicode-Standards, kommt es immer wieder zu kleineren und größeren Problemen mit ihm. So akzeptierte Outlook 2016 keine Passwörter mit Unicode-Zeichen und ein Schriftzeichen der Sprache Telugu führte zu Problemen unter iOS und macOS.

Kritik

Der Unicode-Standard ist nicht perfekt und so gab und gibt es immer wieder Kritik an diesem. Einer dieser Punkte ist die Han-Vereinheitlichung. Bei dieser ging und geht es darum, die Zeichen aus den unterschiedlichen ostasiatischen Sprachen auf ihre Grundformen zurückzuführen und diese entsprechend im Unicode-Standard abzubilden. Dies führte zu einiger Kritik, obwohl hierbei möglichst alle betroffenen Sprachgruppen eingebunden wurden, da teilweise Zeichen vereinheitlicht wurden, welche nicht unbedingt dieselbe Bedeutung hatten.

Auch das besagte Mapping bestehender Zeichensätze in den Unicode-Standard, wie im Abschnitt über die Altlasten beschrieben, war ein solcher Kritikpunkt.

Aus der Sicht der IT-Sicherheit wird manchmal die Nutzung von Homoglyphen kritisiert, da dort bestimmte Zeichen durch andere, ähnliche aussehende Zeichen ausgetauscht werden, um z. B. eine Domain einer Bank zu imitieren und den Kunden so um seine Zugangsdaten zu bringen. Ein bekanntes Beispiel hier ist der Austausch des Buchstabens O durch eine 0, welches schon beim ASCII-Standard funktionierte. Mit dem Unicode-Standard sind viele weitere Möglichkeiten für solche Homoglyphen dazugekommen.

Auch die Sortierung und Groß- und Kleinschreibung kann sich im Codespace von Unicode und entsprechender lokaler Regelungen manchmal als schwierig erweisen, da sich z. B. die Sortierreihenfolge nicht unbedingt aus der Anordnung der Zeichen innerhalb des Codespace ergibt.

Die Zukunft

Unicode ist bisher nicht überall angekommen. So wird der Standard ISO/IEC 8859-15 respektive Latin-9 als 8-Bit-Code weiterhin verwendet. Genutzt wird diese Codierung unter anderem bei amtlichen Werken wie der elektronischen Gesundheitskarte.

Im Internet sind mittlerweile über 97,6 % aller Webseiten als UTF-8 kodiert, 1,1 % als ISO-8859-1 und noch mal knapp ein Prozent entfallen auf die Codierungen Windows-1251 und Windows-1252.

Alte Zeichensätze und Codierungen werden über kurz oder lang ein Nischendasein führen und zum Großteil durch Unicode ersetzt werden, zumindest was moderne System angeht.

Im Rahmen der Script Encoding Initiative von Deborah Anderson, welche sie seit 2002 an der University of California in Berkeley betreibt, werden neue Schriftsysteme für den Standard vorgeschlagen, sodass auch in Zukunft weitere Zeichen in den Standard aufgenommen werden.

So zog 2016, mit Adlam, ein ungewöhnliches Schriftsystem in den Standard ein. Ungewöhnlich deshalb, weil dieses System erst seit 1989 existiert. Zwei Brüder entwickelten dieses System, um ihre Sprache, Fulani, phonetisch in einem Schriftsystem abbilden zu können. Etliche Jahre später wurde das System dank der Unterstützung der Script Encoding Initiative schließlich in den Unicode-Standard übernommen und wird mittlerweile unter Windows, Chrome OS sowie Android unterstützt.

Dieses Beispiel zeigt, wie Unicode eine Grundlage für die Nutzung und Überführung von Schriftsystemen in die digitale Welt ist. Noch einige Jahrzehnte zuvor war ein Großteil des Internets und der IT auf einige lateinische Buchstaben reduziert. Dank Unicode ist es möglich in seiner jeweiligen Muttersprache und in seinem angestammten Schriftsystem digital zu kommunizieren, sich zu informieren und teilzuhaben.

Das Unicode Consortium wird seine Arbeit fortsetzen und sich dabei auch in einem teilweise politischen Spannungsfeld bewegen. Wie Randall Munroe, Autor des xkcd-Comics, dazu einmal sagte:

I am endlessly delighted by the hopeless task that the Unicode Consortium has created for themselves. […] They started out just trying to unify a couple different character sets. And before they quite realized what was happening, they were grappling with decisions at the heart of how we use language, no matter how hard they tried to create policies to avoid these problems. It’s just a fun example of how weird language is and how hard human communication is and how you really can’t really get around those problems.

So bietet uns Unicode lateinische Schrift, Spielkarten, Operatoren, Emojis, Schriftzeichen aus vielen menschlichen Kulturen und mehr. Und da sich Schrift und Sprache im Laufe der Zeit verändern, wird der Unicode-Standard wohl nie fertiggestellt, sondern ein lebendiger und sich weiterentwickelnder Standard sein.

Mit seinen 144.697 Zeichen und der Abbildung von über 150 Schriftsystemen liefert er einen Beitrag zur Erhaltung der Schriftkultur und der Daten über die Jahrzehnte. In Zeiten von Globalisierung und weltweit miteinander interagierenden Systemen ist ein gemeinsamer Zeichensatz sicherlich nicht die schlechteste Idee gewesen.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.