ISP-Level-Befehle: Die versteckte Hürde beim Lesen und Schreiben der SD-Karten-CID

Alle paar Monate passiert es wieder.

Jemand kommt in die IT, hält eine microSD-Karte hoch und fragt ganz nüchtern: „Können wir die CID auf der Karte einfach ändern?“

Der ITler schaut auf die Karte. Dann auf die Person. Atmet einmal tief durch.

Die Frage ist nicht falsch. Sie basiert nur auf einer Annahme, die mit der tatsächlichen Hardware-Architektur nicht viel zu tun hat.

Von außen wirkt eine SD-Karte simpel. Reinstecken, sie taucht als Speicher auf, Dateien rüberziehen, fertig. Also denkt man: Wenn es da eine „Card ID“ gibt, liegt die doch irgendwo drin – irgendwo, wo man sie öffnen, bearbeiten oder überschreiben kann.

Und genau da fängt das Missverständnis an.

Wo die CID wirklich sitzt

Die CID – das Card Identification Register – liegt nicht dort, wo deine Dateien gespeichert sind. Sie liegt nicht neben deinem Firmware-Image oder deinen Fotos im NAND-Flash. Sie befindet sich im Controller selbst, als strukturiertes Register, definiert durch die SD-Spezifikation.

Bei der Herstellung wird dieser CID-Wert direkt in den Controller programmiert. Er enthält Informationen wie Hersteller-ID, Produktname, Seriennummer, Produktionsdatum und Prüfsumme. Er soll genau dieses eine physische Medium eindeutig identifizieren.

Der entscheidende Punkt ist simpel: Die CID ist Controller-Daten, keine Nutzerdaten.

Wenn man das einmal verstanden hat, klärt sich der Rest ziemlich schnell.

Die Ebene, die kaum jemand sieht

Steckst du eine microSD-Karte in einen USB-Reader und verbindest sie mit dem Rechner, sprichst du nicht direkt mit dem SD-Controller. Du kommunizierst mit einem Bridge-Chip, der USB-Massenspeicher-Befehle in SD-Protokoll-Befehle übersetzt.

Dein Betriebssystem sieht nur ein Blockgerät – also logische Sektoren, die gelesen und beschrieben werden können. Diese Abstraktion ist gewollt. USB Mass Storage wurde entwickelt, um Wechseldatenträger universell und einfach nutzbar zu machen.

Aber diese Einfachheit verdeckt mehrere Schichten.

Das CID-Register liegt unterhalb der Dateisystem-Ebene und unterhalb des normalen Blockzugriffs. Die meisten USB-Kartenleser für den Consumer-Bereich geben keine rohen SD-Kommandos an das Host-System weiter. Sie übersetzen nur das, was für den Dateizugriff nötig ist.

Wenn also jemand versucht, mit Software-Tools über einen Standard-USB-Reader die CID auszulesen oder zu ändern, arbeitet er komplett oberhalb der Ebene, auf der die CID überhaupt existiert.

Das ist ungefähr so, als würdest du versuchen, die Seriennummer deiner CPU zu ändern, indem du eine Textdatei bearbeitest. Du sprichst mit dem Betriebssystem – nicht mit dem Silizium, in dem der Wert steckt.

CID lesen vs. CID schreiben

Um eine CID auszulesen, müssen spezielle SD-Kommandos wie CMD10 über die native SD-Schnittstelle gesendet werden. Dafür muss der Host-Controller rohen Kommandozugriff unterstützen. Manche Linux-Systeme mit direktem SD-Bus-Zugriff können das. Die meisten USB-Reader können es nicht.

Das Schreiben der CID ist noch einmal eine ganz andere Nummer.

Die SD-Spezifikation sieht nicht vor, dass CID-Werte im normalen Betrieb einfach umgeschrieben werden. Bei vielen Controllern erfordert eine Änderung der CID herstellerspezifische Befehlsketten oder spezielle Factory-Programmiermodi. Diese sind über normale Consumer-Schnittstellen nicht zugänglich.

Hier lehnt sich der ITler nach vorne und sagt:

Du bearbeitest keinen Speicher. Du versuchst, den Controller neu zu programmieren.

Wo die CID liegt – und wo du tatsächlich arbeitest

Ebene	Was sie steuert	Für das OS sichtbar?	Bearbeitbar?	Beispiele
Dateisystem	Dateien & Ordner	Ja	Ja	FAT32, exFAT, NTFS
Logische Block-Ebene	Sektoren & Partitionen	Ja	Ja	Datenträgerverwaltung, dd, Imaging-Tools
USB-Massenspeicher-Bridge	Befehlstranslation	Nein	Nein	Standard-USB-Kartenleser
SD-Protokoll-Ebene	SD-Kommandos (CMD10 usw.)	Meistens nein	Manchmal	Native SD-Schnittstelle unter Linux
Controller-Register-Ebene	CID, CSD, interne Konfiguration	Nein	Selten (Factory-/Vendor-Kommandos)	ISP-Level-Zugriff

Dafür braucht es eine andere Zugriffsebene – oft als ISP-Level (In-System Programming) bezeichnet – bei der der Controller selbst Low-Level-Kommandos akzeptiert, außerhalb der normalen Massenspeicher-Übersetzung.

Und genau diese Ebene ist bewusst eingeschränkt.

Warum das so gebaut ist

CID-Werte spielen überall dort eine Rolle, wo Nachverfolgbarkeit und Identität wichtig sind. Embedded-Systeme binden sich an bestimmte Medien. Lizenzsysteme prüfen Identifikatoren. Industrielle Deployments protokollieren Medien über Seriennummern. Wenn sich eine CID so leicht ändern ließe wie ein Sektor, würden diese Mechanismen sofort kippen.

Die Hürde ist kein Zufall. Sie ist Teil der Architektur.

Wenn du tiefer verstehen willst, wie microSD-Karten physisch aufgebaut sind und warum das Controller-Design so entscheidend ist, haben wir das hier ausführlicher erklärt:

Wie microSD-Karten gebaut werden, wie sie ausfallen und wie Profis sie verwalten

Sobald man sieht, wie viel Intelligenz in diesem winzigen Controller steckt, wirkt die Idee, dessen interne Register „mal eben“ umzuschreiben, deutlich weniger realistisch.

Wo es praktisch wird

Im Bastlerbereich experimentieren manche mit gepatchten Kerneln, speziellen Chipsets oder Android-Geräten, die tiefere Kommandoebenen freigeben. Ob es klappt, hängt stark vom konkreten Controller und der Schnittstelle ab. Konsistent ist das selten – skalierbar fast nie.

Im Unternehmens- oder Provisioning-Umfeld verschiebt sich die Frage von „Können wir das irgendwie hacken?“ zu „Können wir das reproduzierbar bei hunderten oder tausenden Karten umsetzen?“

Und da sind Standard-USB-Reader schlicht das falsche Werkzeug. Man braucht Hardware, die auf der nativen Kommandoebene kommuniziert – nicht nur auf Dateisystem-Ebene.

Speziell entwickelte Systeme wie der Nexcopy mSD160PC microSD-Duplikator arbeiten auf Controller-Kommunikationsebene und ermöglichen strukturiertes CID-Auslesen während Duplizierungs- und Provisioning-Prozessen.

Das bedeutet nicht, Architektur zu umgehen. Es bedeutet, von Anfang an das richtige Werkzeug für die richtige Zugriffsschicht zu verwenden.

Das eigentliche Fazit

Dass sich das Lesen und Schreiben der SD-CID so kompliziert anfühlt, liegt nicht daran, dass der Wert irgendwo im Speicher versteckt ist. Es liegt daran, dass die meisten von der falschen Seite der Abstraktionsgrenze auf die Karte zugreifen.

Dein Rechner sieht logische Blöcke.

Die CID sitzt in Controller-Registern.

Das sind unterschiedliche Ebenen im Stack.

Versteht man das, ändert sich die Diskussion. Der Vertrieb hört nicht auf zu fragen – er stellt nur bessere Fragen. Und der ITler muss beim nächsten Mal nicht ganz so laut seufzen.

Field Note

Die Trennung zwischen Block-Level-Zugriff und Controller-Level-Zugriff ist nicht nur ein Detail in der Spezifikation – wir begegnen ihr regelmäßig in echten Provisioning-Umgebungen. Wenn Teams versuchen, CID-Werte mit Standard-USB-Readern oder Software-Tools auszulesen oder zu ändern, liegt die Grenze fast immer an der Zugriffsebene, nicht an der Qualität des Tools. Sobald man direkt mit nativen SD-Kommandos und Controller-Kommunikation gearbeitet hat, wird die Grenze offensichtlich: Daten kopieren und Identität konfigurieren sind zwei grundverschiedene Operationen.