(Inhalte des Tickets - wetter)
 
(Eine dazwischenliegende Version von einem anderen Benutzer werden nicht angezeigt)
Zeile 40: Zeile 40:
 
|-
 
|-
 
! style="border: 1px solid black;" | 0x3
 
! style="border: 1px solid black;" | 0x3
| style="border: 1px solid black; background: #fcc" | VV
+
| style="border: 1px solid black; font-family: Courier, monospace; background: #fcc" | AC
| style="border: 1px solid black; font-family: Courier, monospace; background: #fcc" | 00
+
| style="border: 1px solid black; font-family: Courier, monospace; background: #fcc" | EC
 
| style="border: 1px solid black; font-family: Courier, monospace; background: #fcc" | 00
 
| style="border: 1px solid black; font-family: Courier, monospace; background: #fcc" | 00
 
| style="border: 1px solid black; font-family: Courier, monospace; background: #fcc" | 00
 
| style="border: 1px solid black; font-family: Courier, monospace; background: #fcc" | 00
Zeile 99: Zeile 99:
 
|-
 
|-
 
! style="border: 1px solid black;" | 0xd
 
! style="border: 1px solid black;" | 0xd
| style="border: 1px solid black; font-family: Courier, monospace; background: #cfc" | 00
+
| style="border: 1px solid black; background: #cfc" | BB
| style="border: 1px solid black; font-family: Courier, monospace; background: #cfc" | 00
+
| style="border: 1px solid black; background: #cfc" | BB
| style="border: 1px solid black; font-family: Courier, monospace; background: #cfc" | 00
+
| style="border: 1px solid black; background: #cfc" | BB
| style="border: 1px solid black; font-family: Courier, monospace; background: #cfc" | 00
+
| style="border: 1px solid black; background: #cfc" | BB
 
|-
 
|-
 
! style="border: 1px solid black;" | 0xe
 
! style="border: 1px solid black;" | 0xe
Zeile 120: Zeile 120:
 
In Block 0x0 und Block 0x1 ist die UID des Tickets abgelegt (insg. 7 Byte). In Block 0x0 und Block 0x2 ist ausserdem je ein Checkbyte (CC) mit einer Art Prüfsumme über die UID. In Block 0x2 ist ein Byte (<code>48</code>) das für interne Benutzung des Herstellers reserviert ist und sonst nicht weiter interessant ist. In Block 0x2 sind dann am Ende noch 2 Byte mit Lockbits. Die Lockbits sind auf <code>f507</code> gesetzt, was bedeutet dass die Blöcke 0x4 bis 0xa (jeweils inklusive) schreibgeschützt sind (<code>f__7</code>) und die locking-bits von den Blöcken 0x3 und 0xa bis 0xf nicht mehr geändert werden können (<code>_5__</code>).  
 
In Block 0x0 und Block 0x1 ist die UID des Tickets abgelegt (insg. 7 Byte). In Block 0x0 und Block 0x2 ist ausserdem je ein Checkbyte (CC) mit einer Art Prüfsumme über die UID. In Block 0x2 ist ein Byte (<code>48</code>) das für interne Benutzung des Herstellers reserviert ist und sonst nicht weiter interessant ist. In Block 0x2 sind dann am Ende noch 2 Byte mit Lockbits. Die Lockbits sind auf <code>f507</code> gesetzt, was bedeutet dass die Blöcke 0x4 bis 0xa (jeweils inklusive) schreibgeschützt sind (<code>f__7</code>) und die locking-bits von den Blöcken 0x3 und 0xa bis 0xf nicht mehr geändert werden können (<code>_5__</code>).  
  
In Block 0x3, der OTP, ist dann in Byte 0 ein Flag (VV) welches das Ticket als verbraucht markiert: Wenn dort 00 steht, ist das Ticket noch frisch und wenn dort 01 steht ist das Ticket bereits benutzt.
+
'''Ein- und Austritte''': In Block 0x3, der OTP, befinden sich zwei Zähler: In Byte 0 ist ein Zähler (AC), welcher auf 00 ist, sollte das Ticket noch garnicht benutzt worden sein. Der Wert 01 wurde in dem Byte nach den Spielen gefunden, wobei unklar ist, ob diese Tickets regulär nach dem Spiel ausgebucht wurden. Diese Ausbuchung findet zumindest im Berliner Olympiastadion, obwohl sie vorgesehen ist, nicht statt. Sollte dem so sein, ist es wahrscheinlich der Counter für die Austritte (AC), denn bei einem Ticket, was dreimal das Stadion verlassen hat, wurde hier der Wert 07 (in Bits: 00000111) gefunden, was ein dreimaliges Schreiben dieses Bytes nahe legt. Auf demselben Ticket wurde im Byte neben an (EC, wie Eintritts-Counter) der Wert 03 (also: 00000011) gelesen, was soviel wie "zwei" heisst. Das legt nahe, dass hier die Wiedereintritte gezählt wurden. Das Ticket aus dem dieses Wissen abgeleitet wird, befand sich zum Zeitpunkt des Auslesens außerhalb des Stadions nach dem dritten Austritt und vor dem dritten wiedereintritt. Die beiden letzten Bytes des Feldes 0x3 standen weiterhin auf 00. Wohlmöglich wird hier weitergezählt, wenn die ersten beiden Bytes voll sind. Demnach wären 16 Aus- und Wiedereintritte technisch ohne weitere Komplikationen möglich.
 +
 
 +
Unklar ist, ob im vierten Block Prüfsummen gespeichert werden, die sich aus der Zahl der Ein- und Austritte sowie etwa der UID oder Personennummer errechnen. Dies würde eine Fälschung ohne großen Datenbestand zu analytischen Zwecken erschweren.
  
 
In Block 0x4 und 0x5 sind 8 Byte (XX) deren Bedeutung zur Zeit unklar ist. Das scheinen zufällige Bytes als Datenbank-ID zu sein.
 
In Block 0x4 und 0x5 sind 8 Byte (XX) deren Bedeutung zur Zeit unklar ist. Das scheinen zufällige Bytes als Datenbank-ID zu sein.
Zeile 129: Zeile 131:
  
 
In Block 0xb und 0xc scheint eine Art Kunden- oder Personennummer (KK) BCD-kodiert eingetragen zu sein. Bei einigen Tickets ist diese Nummer auch aufgedruckt, ansonsten scheint sie nicht (besonders deutlich) von aussen sichtbar zu sein. Bei diesen Hospitality-Tickets wo auch kein Name auf dem Ticket aufgedruckt ist, scheint sie einfach pro Ticket hochgezählt worden zu sein oder so. Bei den 'normalen' (verkauften) Tickets auf denen der Name des Inhabers aufgedruckt ist, scheint sie pro Inhaber (oder Besteller?) eindeutig zu sein, d.h. wir haben je 2 Tickets von 2 Personen gesehen und pro Person steht jeweils die gleiche Nummer drin. Damit könnte man also ggbf. Personen über Spiele hinweg verfolgen.
 
In Block 0xb und 0xc scheint eine Art Kunden- oder Personennummer (KK) BCD-kodiert eingetragen zu sein. Bei einigen Tickets ist diese Nummer auch aufgedruckt, ansonsten scheint sie nicht (besonders deutlich) von aussen sichtbar zu sein. Bei diesen Hospitality-Tickets wo auch kein Name auf dem Ticket aufgedruckt ist, scheint sie einfach pro Ticket hochgezählt worden zu sein oder so. Bei den 'normalen' (verkauften) Tickets auf denen der Name des Inhabers aufgedruckt ist, scheint sie pro Inhaber (oder Besteller?) eindeutig zu sein, d.h. wir haben je 2 Tickets von 2 Personen gesehen und pro Person steht jeweils die gleiche Nummer drin. Damit könnte man also ggbf. Personen über Spiele hinweg verfolgen.
 +
 +
In Block 0xd scheinen noch zusätzliche Daten (BB) aufgezeichnet zu werden, wenn das Ticket benutzt wird (also wenn in Block 0x3 die 1 gesetzt wird). Die genaue Interpretation dieser Daten ist zur Zeit noch unklar.
  
 
Der <span style="background: #fcc">hellrosane Bereich</span> ist nur einfach beschreibbar (von 0 zu 1 aber nicht zurück). Der <span style="background: #cfc">hellgrüne Bereich</span> ist beliebig oft beschreibbar. Der Rest der Karte ist nicht mehr beschreibbar, bzw. war nie beschreibbar (der <span style="background: #ccc">graue Bereich</span>).
 
Der <span style="background: #fcc">hellrosane Bereich</span> ist nur einfach beschreibbar (von 0 zu 1 aber nicht zurück). Der <span style="background: #cfc">hellgrüne Bereich</span> ist beliebig oft beschreibbar. Der Rest der Karte ist nicht mehr beschreibbar, bzw. war nie beschreibbar (der <span style="background: #ccc">graue Bereich</span>).

Aktuelle Version vom 1. Juli 2006, 00:47 Uhr

Philips produziert RFID-Transponder fuer die ca. 3 Millionen WM-Tickets. Als Technik wird Mifare Ultralight eingesetzt. Diese Technologie stammt aus dem Hause Philips und basiert auf ISO 14443 A.

Der Transponder soll Bestellnummer und "Fan-Informationen" speichern. Der Chip wird an den Drehkreuzen zu den "Sicherheitszonen" ausgelesen. Das Drehkreuz fragt die Stadiondatenbank, ob Einlass gewaehrt werden kann. Die Stationdatenbank speichert dazu Daten der Ticketinhaber, einschliesslich Ausweisnummer. Die Stadiondatenbank wird mit in- und ausländischen Hooligan-Datenbanken abgeglichen.

Das Personalisieren von Eintrittskarten ist bis eine Stunde vor Spielbeginn möglich. Dazu werden die Daten des Ticketinhabers im "Frankfurter Zentralsystem" gespeichert. Alle 12 WM-Stadien sollen via DSL mit dem Zentralsystem verbunden sein und bekommen von dort ihre Daten.

Quellen:


Inhalte des Tickets

Ein Mifare-Ultralight-Ticket besteht aus 16 Blöcken zu je 4 Byte. Die ersten 8 plus 2 Byte sind vom Hersteller belegt (UID und Checkbits), dann kommen 2 Byte mit Lockbits, dann 4 Byte One-time programmable Zone (OTP, Block 0x3) und dann 12 mal 4 Byte zur freien Verwendung. Die Lockbits und OTP sind im Auslieferungszustand 0 und lassen sich nur von 0 auf 1 setzen, aber nicht wieder von 1 nach 0.

Block Byte
0 1 2 3
0x0 UID CC
0x1 UID
0x2 CC 48 F5 07
0x3 AC EC 00 00
0x4 XX XX XX XX
0x5 XX XX XX XX
0x6 00 NN 00 00
0x7 Land 00
0x8 00 00 00 00
0x9 00 00 00 00
0xa 00 00 00 00
0xb 00 KK KK KK
0xc KK 00 00 00
0xd BB BB BB BB
0xe 00 00 00 00
0xf 00 00 00 00

In Block 0x0 und Block 0x1 ist die UID des Tickets abgelegt (insg. 7 Byte). In Block 0x0 und Block 0x2 ist ausserdem je ein Checkbyte (CC) mit einer Art Prüfsumme über die UID. In Block 0x2 ist ein Byte (48) das für interne Benutzung des Herstellers reserviert ist und sonst nicht weiter interessant ist. In Block 0x2 sind dann am Ende noch 2 Byte mit Lockbits. Die Lockbits sind auf f507 gesetzt, was bedeutet dass die Blöcke 0x4 bis 0xa (jeweils inklusive) schreibgeschützt sind (f__7) und die locking-bits von den Blöcken 0x3 und 0xa bis 0xf nicht mehr geändert werden können (_5__).

Ein- und Austritte: In Block 0x3, der OTP, befinden sich zwei Zähler: In Byte 0 ist ein Zähler (AC), welcher auf 00 ist, sollte das Ticket noch garnicht benutzt worden sein. Der Wert 01 wurde in dem Byte nach den Spielen gefunden, wobei unklar ist, ob diese Tickets regulär nach dem Spiel ausgebucht wurden. Diese Ausbuchung findet zumindest im Berliner Olympiastadion, obwohl sie vorgesehen ist, nicht statt. Sollte dem so sein, ist es wahrscheinlich der Counter für die Austritte (AC), denn bei einem Ticket, was dreimal das Stadion verlassen hat, wurde hier der Wert 07 (in Bits: 00000111) gefunden, was ein dreimaliges Schreiben dieses Bytes nahe legt. Auf demselben Ticket wurde im Byte neben an (EC, wie Eintritts-Counter) der Wert 03 (also: 00000011) gelesen, was soviel wie "zwei" heisst. Das legt nahe, dass hier die Wiedereintritte gezählt wurden. Das Ticket aus dem dieses Wissen abgeleitet wird, befand sich zum Zeitpunkt des Auslesens außerhalb des Stadions nach dem dritten Austritt und vor dem dritten wiedereintritt. Die beiden letzten Bytes des Feldes 0x3 standen weiterhin auf 00. Wohlmöglich wird hier weitergezählt, wenn die ersten beiden Bytes voll sind. Demnach wären 16 Aus- und Wiedereintritte technisch ohne weitere Komplikationen möglich.

Unklar ist, ob im vierten Block Prüfsummen gespeichert werden, die sich aus der Zahl der Ein- und Austritte sowie etwa der UID oder Personennummer errechnen. Dies würde eine Fälschung ohne großen Datenbestand zu analytischen Zwecken erschweren.

In Block 0x4 und 0x5 sind 8 Byte (XX) deren Bedeutung zur Zeit unklar ist. Das scheinen zufällige Bytes als Datenbank-ID zu sein.

In Block 0x6 wird die Nummer des Spiels (NN) BCD-kodiert abgelegt, also eine Karte für Spiel 56 hat 0x56 in Byte 1.

In Block 0x7 wird irgendeine Nationalität kodiert. Wir haben bereits gesehen: "DEU", "GBR" und " ".

In Block 0xb und 0xc scheint eine Art Kunden- oder Personennummer (KK) BCD-kodiert eingetragen zu sein. Bei einigen Tickets ist diese Nummer auch aufgedruckt, ansonsten scheint sie nicht (besonders deutlich) von aussen sichtbar zu sein. Bei diesen Hospitality-Tickets wo auch kein Name auf dem Ticket aufgedruckt ist, scheint sie einfach pro Ticket hochgezählt worden zu sein oder so. Bei den 'normalen' (verkauften) Tickets auf denen der Name des Inhabers aufgedruckt ist, scheint sie pro Inhaber (oder Besteller?) eindeutig zu sein, d.h. wir haben je 2 Tickets von 2 Personen gesehen und pro Person steht jeweils die gleiche Nummer drin. Damit könnte man also ggbf. Personen über Spiele hinweg verfolgen.

In Block 0xd scheinen noch zusätzliche Daten (BB) aufgezeichnet zu werden, wenn das Ticket benutzt wird (also wenn in Block 0x3 die 1 gesetzt wird). Die genaue Interpretation dieser Daten ist zur Zeit noch unklar.

Der hellrosane Bereich ist nur einfach beschreibbar (von 0 zu 1 aber nicht zurück). Der hellgrüne Bereich ist beliebig oft beschreibbar. Der Rest der Karte ist nicht mehr beschreibbar, bzw. war nie beschreibbar (der graue Bereich).