SD-Karten mit Schreibschutz - Hat das mal jemand analysiert?

[Torsten C. (torsten_c)]

Hallo,
um SD-Karten z.B. zum Booten über USB wirklich sicher gegen Viren zu 
machen, sollen sie einen zuverlässigen Schreibschutz haben.

Auch wenn ich z.B. CAD-Daten mit in einen MakerSpace nehme, soll sich 
dort kein Virus auf dem USB-Stick einnisten.

Ich habe dafür einen TrekStor USB-Stick CS mit Schreibschutz.
32 GB sind unnötig groß und 15€ ziemlich teuer, wenn man viele davon 
haben möchte.

Ein Virus könnte ja am Treiber vorbei direkt auf das Speichermedium 
zugreifen, also z.B. beim RasPi direkt über die SPI-Schnittstelle 
zugreifen. Sowas z.B. soll verhindert werden.

Bei einem USB-Kartenlesegerät für SD-Karten sitzt der Schalter zum 
Auslesen des Schreibschutz-Schiebers ja im Kartenlesegerät und wird dort 
vielleicht sicher von der Firmware ausgewertet.

Ich konnte nirgends herausfinden, ob das wirklich sicher gegen 
Kompromittierung ist. Siehe auch:
Beitrag "Re: USB-Stick mit Schreibschutz"

Wie findet man das heraus? Oder hat das mal jemand analysiert?

Ist das bei allen gleich oder gibt es dabei Unterschiede zwischen den 
Kartenlesegeräten?

Alternativ könnte man CDs erstellen und ein USB-CD-ROM-Lauferk 
anschließen oder doch die 15€-USB-Sticks mit Schreibschutzschalter 
nehmen. Aber diese Lösungen sind vergleichsweise groß und teuer, dann es 
geht um viele kleine (z.T. bootfähige) Medien zum Wechseln, 
Ausprobieren, als Backup für das FabLab usw..

Größenordnung ca. 5 .. 20 Stück mit ca. 0,3 … 3GiB.

SD-Karten sind dafür mit Abstand am preiswertesten, ab 5€

Nebenbei: Für Festplatten hätte ich sogar einen "coolgear SATA Adapter 
with Write-Protection" parat:
https://www.coolgear.com/product/usb-3-0-sataide-adapter-with-write-protection
Aber der schießt mit Kanonen auf Spatzen. ;)

Vielleicht könnte ein Virus die  Kartenleser-Firmware oder 
SATA-Adapter-Firmware kompromittieren, aber das wäre bei einem USB-Stick 
mit Schreibschutzschalter sicherlich genauso möglich. Ich denke, dagegen 
würde tatsächlich nur ein USB-CD-ROM-Lauferk helfen. Das Risiko würde 
ich eingehen.

VG Torsten

[Rufus Τ. F. (rufus)]

Du könntest einen SD-Karten-Leser selbst bauen. Mit einem Atmega32U4 und 
der LUFA-Bibliothek sollte das nicht allzu kompliziert sein.

Und dann hast Du es in der Hand, welche Kommandos Du von der 
USB-Schnittstelle an die SPI-Schnittstelle durchlässt, an der Du die 
SD-Karte anschließt.

[Jim M. (turboj)]

Rufus Τ. F. schrieb:
> Du könntest einen SD-Karten-Leser selbst bauen. Mit einem Atmega32U4 und
> der LUFA-Bibliothek sollte das nicht allzu kompliziert sein.

Aber leider schnarchlahm. Die 1MB/sec bei guten Bedinungen sind 
heutzutage nur noch in Ausnahmefällen akzeptabel.

[Rufus Τ. F. (rufus)]

Tja. Einen Tod muss man sterben.

Alternative: Leistungsfähigeren µC verwenden und den 4-Bit-SPI-Modus 
implementieren, um mit der SD-Karte zu kommunizieren.

Richtig aufwendige Alternative:

µC mit USB-Host verwenden, um mit dem einen USB-SD-Kartenleser 
anzusprechen und den µC wiederum als USB-Device an einen PC anschließen. 
Die Firmware auf dem µC filtert Schreibzugriffe aus.

[René F. (Gast)]

SD Karten bringen doch von Haus aus die Möglichkeit mit sich sperren zu 
lassen. (CSD Register)

[Dr. Sommer (Gast)]

Torsten C. schrieb:
> und wird dort vielleicht sicher von der Firmware ausgewertet.

Das wird er definitiv nicht. Da ist keine elektrische Auswertung dran. 
Das macht alleine der Host. Der kann sich dran halten, oder auch nicht.

SD Karten lassen sich aber über bestimmte Befehle Software seitig 
schreib schützen. Schließlich waren die auch mal als CD ROM Ersatz 
gedacht, für Musik o.ä. Leider unterstützt kaum ein Gerät diese Befehle, 
und meiner Erfahrung nach stürzt Windows komplett ab wenn man eine 
schreibgeschützte Karte einlegt...

[georg (Gast)]

Torsten C. schrieb:
> sollen sie einen zuverlässigen Schreibschutz haben

Es gibt keinen Hardware-Schreibschutz, ob Schalter oder Wert in einem 
Register, das wird immer per Software ausgewertet (oder auch nicht), 
entweder im Hostsystem oder in der Controller-Firmware. M.a.W. das ist 
nur der Wunsch "bitte beschreib mich nicht".

Georg

[Frank K. (fchk)]

Mein Vorschlag:

https://www.digikey.de/product-detail/de/microchip-technology/USB2642-ML/USB2642-ML-ND/4876269

https://www.microchip.com/wwwproducts/en/USB2642

Das ist ein Controllerchip für Card Reader plus USB 2 High Speed Hub. 
Damit kannst Du Dir selbst einen Kartenleser bauen. Den Schreibschutz 
steuerst Du über Pin 13 (SD_WP). Je nach Paranoia-Level kannst Du eine 
eigene Firmware ein ein externes SPI-Flash packen. Der Chip kann das.

Damit bekommst Du ordentliche Performance plus Schreibschutz auf 
Controller-Ebene.

Wenn das nicht deine Paranoia befriedigt, musst Du Dir einen BeagleBone 
Black (*) als Kartenleser zweckentfremden. Der hat Support für Linux USB 
Gadgets, und darüber bekommst Du auch Support für Mass Storage. Den 
Schreibschutz müsstest Du dann im Linux Kernelsource implementieren.

fchk

(*) Du brauchst einen, der ein EMMC enthält, damit Du davon Dein Linux 
booten kannst und der MicroSD-SLot frei für Deine Speicherkarten bleibt. 
Es gibt auch Versionen ohne EMMC. BeagleBone Green geht auch.

[Torsten C. (torsten_c)]

Wie ist der Schrebschutz in kandelsüblichen USB-Sticks und Kartenlesern 
implementiert? Kennt jemand Beispiele, von denen Details bekannt sind?

Das mit dem Schieber an der SD-Karte ist hier offenbar allen bekannt, 
wie man liest. Aber ein Virus auf dem Host-Rechner kann nicht einfach 
die SW im Kartenleser umgehen.

Denke ich. So denken die meisten.

Aber ist das so? Wer weiß das?

Nochmal: Dass ein Virus die Kartenleser-Firmware kompromittieren könnte, 
ist ein kalkulierbares Restrisiko, denn es gibt aktuell keinen solchen 
Virus.

Rufus Τ. F. schrieb:
> Du könntest einen SD-Karten-Leser selbst bauen.
Klar, das diese Antwott kommt. * grins *

Ich hätte die Frage auch im "Forum für alle Fragen rund um 
Mikrocontroller und sonstige digitale Elektronik" stellen können. Aber 
ein Selbstbau wäre ein anderes Projekt, und hält jetzt zu sehr auf.

Rufus Τ. F. schrieb:
> Leistungsfähigeren µC verwenden und den 4-Bit-SPI-Modus

Ich habe hier sogar noch ein Infineon XMC2Go Board aus:
Beitrag "100x Infineon XMC2Go Board mit ARM Cortex-M0 zu gewinnen"

[Dr. Sommer (Gast)]

Torsten C. schrieb:
> Aber ein Virus auf dem Host-Rechner kann nicht einfach die SW im
> Kartenleser umgehen.

Wer sagt denn dass die FW das überhaupt auswertet? So dumm wie heutige 
Consumer HW ist, wird das im Treiber auf dem Host-PC gemacht.
Fragt sich nur, wer extra ein Virus bastelt, um deine SD-Karten 
anzugreifen!
Mach es wie jeder andere: Verwende auf deinem PC nur aktuelle Software. 
Formatiere die Karte/Stick jedes Mal nach der Nutzung an fremden 
Rechnern. Am besten unter Linux, und schalte das Auto-Mount aus. Das 
dürfte so nahezu perfekt sicher sein, es sei denn jemand findet eine 
Lücke im USB oder SD Host Treiber die nicht bekannt wird bevor du das 
Medium anschließt. Und für diesen extrem unwahrscheinlichen Fall greift 
Maßnahme 2: Regelmäßige Backups.

[Rolf M. (rmagnus)]

Dr. Sommer schrieb:
> Mach es wie jeder andere: Verwende auf deinem PC nur aktuelle Software.
> Formatiere die Karte/Stick jedes Mal nach der Nutzung an fremden
> Rechnern. Am besten unter Linux, und schalte das Auto-Mount aus.

SD-Karten formatiert man am besten mit dem offiziellen Tool von 
sdcard.org. Das gibt's aber leider nicht für Linux.

[soso... (Gast)]

Torsten C. schrieb:
> Wie findet man das heraus? Oder hat das mal jemand analysiert?

Üblicherweise ist der "Schreibschutz" nur eine mechanischer Schieber. 
Der Schieber wird über einen Kontakt im SD-Sockel eingelesen, und der 
SDIO-Controller sagt dann "Schreibgeschützt". Es gibt übrigens Sockel 
ohne Kontakt.

Ich kenne das von unseren i.MX6-Boards : Dort habe ich den 
Schreibschutzkontakt immer nur auf einen GPIO gelegt, und bin nicht mal 
sicher, ob unser Linux-Heini das im Treiber überhaupt liest. Weil der 
i.MX6 SDIO nativ kann, hängt kein Chip dazwischen.

Und daher ist das eine reine Softwaregeschichte, und ein Virus könnte - 
durch ignorieren des Schreibschutzes z.B. auf Treiberebene - schon die 
Karte beschreiben.

Aber nur in dem Fall. Oft hängt die SD-Karte über einen 
USB-SDIO-Controller am PC, dann müsste man diesen manipulieren. Denn der 
könnte den Schreibschutz handhaben. Das wird dann schwierig werden, weil 
der Virus alle Chips kennen müsste.
Andererseits haben die ganzen Chinaheinis vermutlich oft Sockel ohne 
Schreibschutzkontakt ;-)

--> 100% sicher ist bei SD-Karten schwierig.

[Dr. Sommer (Gast)]

Rolf M. schrieb:
> SD-Karten formatiert man am besten mit dem offiziellen Tool von
> sdcard.org. Das gibt's aber leider nicht für Linux.

Richtig... man kann das ja 1x unter Windows machen und davon ein Image 
ziehen. Die ersten 32MB oder so sollten reichen, um den MBR und FAT zu 
erwischen (da sind teilweise große Lücken zwischen).

[Manfred F. (manfred_f)]

soso... schrieb:
> 100% sicher ist bei SD-Karten schwierig.

Aber nicht unmöglich. Das Setzen des PERM_WRITE_PROTECT Bits im CSD ist 
nicht reversibel. Da kommt kein Virus dran vorbei. Du allerdings auch 
nicht, d.h. wenn du nach setzen des Bits feststellst das du doch eine 
Datei vergessen hast kannst du die Karte in die Tonne werfen und eine 
neue verwenden.

Wers mal ausprobieren möchte:
Auf https://github.com/BertoldVdb/sdtool gibts ein Programm dafür.

[Kaj (Gast)]

Torsten C. schrieb:
> Dass ein Virus die Kartenleser-Firmware kompromittieren könnte,
> ist ein kalkulierbares Restrisiko, denn es gibt aktuell keinen solchen
> Virus.
Und das weisst du woher? Sorry, aber das ist ein typisches:
"Hab ich noch nichts von gehoert, gesehen, und vorstellen kann ich mir 
das erst recht nicht. Also gibt es das auch nicht."

Frei nach dem kindlichen Motto:
"Wenn ich die Augen zu mache, dann sehe ich es nicht, also kann es mich 
auch nicht sehen."

Weisst du etwa was alle Hacker, Geheimdienste, und Softwareentwickler 
dieser Welt so in petto haben?

Man kann sogar ein Passwort das du am PC eintippst abfangen, ohne das 
das der PC infiziert sein muss. Reicht wenn dein Smartphone auf dem 
Tisch liegt und entsprechend infiziert ist. Durch die ganzen Sensoren im 
Smartphone koennen die Vibrationen des Tippens aufgezeichnet und 
ausgewertet werden. Das hat die 'Georgia Tech, School of Computer 
Science' 2011 gezeigt. Genauigkeit: bis zu 80%
Und das war vor 7 Jahren...

Dasselbe in gruen:
Die Pin deiner Bankkarte kann auch ermittelt werden, wenn du an der 
Hand, mit der du die Pin eintippst, eine Smartwatch/Fitnessarmband 
traegst.

Fingerabdruecke aus Bildern rekonstruieren und Fingerabdruckerscanner 
ueberlisten: hat der CCC gezeigt.

Ja, das ist alles nicht gerade trivial, aber auch keine 
Raketenwissenschaft.

Das nur mal als kurzer Abriss dessen, was geht. Vorstellen koennen sich 
das die wenigsten, das aendert aber nichts daran, das es geht.

Die Erfahrung zeigt: Es gibt immer einen Weg.

Wenn du irgendwelche Sicherheit willst:
Billig Sticks kaufen, Daten rauf, mit in den Hackerspace nehmen, und 
danach den gesammten USB-Stick so lange schreddern bis nur noch Staub 
uebrig ist.

[Jim M. (turboj)]

Kaj schrieb:
>> Dass ein Virus die Kartenleser-Firmware kompromittieren könnte,
>> ist ein kalkulierbares Restrisiko, denn es gibt aktuell keinen solchen
>> Virus.
> Und das weisst du woher? Sorry, aber das ist ein typisches:
> "Hab ich noch nichts von gehoert, gesehen, und vorstellen kann ich mir
> das erst recht nicht. Also gibt es das auch nicht."

USB Kartenleser sind üblicherweise als ASIC gestrickt, da ist nix 
programmierbares drin. Also kann auch keine Firmware manipuliert werden.

Bei Messenware wie Kartenlesern lohnt es sich die 1E6 EUR für die 
Entwicklung auszugeben - weil man >1E5 Geräte verkaufen kann.

Kaj schrieb:
> Weisst du etwa was alle Hacker, Geheimdienste, und Softwareentwickler
> dieser Welt so in petto haben?

Angreifer dieses Kalibers würden die Hardware (Kartenleser) selbst 
austauschen. Viieeel einfacher.

[c-hater (Gast)]

Torsten C. schrieb:

> um SD-Karten z.B. zum Booten über USB wirklich sicher gegen Viren zu
> machen, sollen sie einen zuverlässigen Schreibschutz haben.

Haben sie nicht. Ich kenne jedenfalls keine einzige.

> Ein Virus könnte ja am Treiber vorbei direkt auf das Speichermedium
> zugreifen, also z.B. beim RasPi direkt über die SPI-Schnittstelle
> zugreifen. Sowas z.B. soll verhindert werden.

Eben das geht nicht. Weil bei allen mir bekannten SD-Karten der 
Schreibschutz-Schalter nur ein völlig blödes Stück Plastik ist, was auf 
die Funktion der SD-Karte selber absolut Null Einfluß hat.

Erfolgversprechender wären da wohl USB-Sticks mit Schreibschutz. 
Vermutlich in der überwiegenden Mehrzahl der Fälle auch irgendwie zu 
umgehen, aber der Angreifer müsste dazu schon wissen, was der Stick 
genau tut, um den Schreibschutz umzusetzen. Die Komplexität für den 
Angreifer steigert sich also im Vergleich auf dem praktisch völlig 
nutzlosen SD-Scheiss doch um einige Größenordnungen.

[Rufus Τ. F. (rufus)]

c-hater schrieb:
> Eben das geht nicht. Weil bei allen mir bekannten SD-Karten der
> Schreibschutz-Schalter nur ein völlig blödes Stück Plastik ist, was auf
> die Funktion der SD-Karte selber absolut Null Einfluß hat.

Deswegen haben die anderen in diesem Thread auch darüber diskutiert, wie 
man einen sicheren SD-Karten-Leser konstruieren kann, dessen Firmware 
nicht von irgendwelcher Schadsoftware angegriffen werden kann. Daß die 
Karten selbst keinen Schreibschutz haben, ist allgemein bekannt; 
insbesondere µSD-Karten haben noch nicht mal den 
Schreibschutzwunschschieber.

[c-hater (Gast)]

Rufus Τ. F. schrieb:

> Deswegen haben die anderen in diesem Thread auch darüber diskutiert, wie
> man einen sicheren SD-Karten-Leser konstruieren kann, dessen Firmware
> nicht von irgendwelcher Schadsoftware angegriffen werden kann.

Nun, wenn das Grundproblem erkannt wurde, dann ist doch auch die Lösung 
ziemlich trivial. Man braucht einfach nur eine Bridge, auf deren 
Verhalten ein potentieller Angreifer keinen Zugriff hat. Also z.B. 
USB-Storage Richtung Host und SD Richtung Client. Jeglicher 
Schreibzugriff auf das Block-Device aus Richtung Host wird "gefressen", 
solange der Schreibschutzschalter der Bridge gesetzt ist.

Ziemlich trivial, finde ich. Das könnten sogar C-Only-Leute aus den frei 
verfügbaren Wichsvorlagen mit einem Minimum an Glue-Code innerhalb 
weniger Minuten bis Stunden zusammenklöppeln...

Was die allerdings sicher nicht könnten: den Code gegen gezielte 
Angriffe auf die Implementierung des USB-Storage-Client (über alle 
Ebenen des Stack hinweg) zu härten...

[Frank K. (fchk)]

Jim M. schrieb:

>> Und das weisst du woher? Sorry, aber das ist ein typisches:
>> "Hab ich noch nichts von gehoert, gesehen, und vorstellen kann ich mir
>> das erst recht nicht. Also gibt es das auch nicht."
>
> USB Kartenleser sind üblicherweise als ASIC gestrickt, da ist nix
> programmierbares drin. Also kann auch keine Firmware manipuliert werden.

Meep. Falsch. 6. Setzen.

Da ist in der Regel ein 8051 oder ARM7 Core drin - mit DMA Support für 
den Datentransfer. USB ist zu komplex, um es in einer reinen State 
Machine zu implementieren. Auch in einer SD-Karte steckt ein 8051 oder 
ARM7 drin.

fchk

[Rufus Τ. F. (rufus)]

c-hater schrieb:
> dann ist doch auch die Lösung ziemlich trivial.

Überraschung: Die wurde hier schon genannt. Schlecht geschlafen?

[Volker (Gast)]

Hallo Torsten,

die Fragen hatte ich  mir auch gestellt, wie ein Speicher 
schreibgeschützt werden kann.

Viel zum Thema Hardwareschreibschutz hab ich hier zusammengetragen.
"Hardware-Hacks für mehr Sicherheit."
https://www.vkldata.com/

Am Besten wird ein Speicher abgesichert, wenn das Write-Protect Pin an 
den FLASH-Bausteinen selbst verwendet wird.
(Das wird leider allzu oft in den Hardware-Designs vergessen.)

Eine Umbauanleitung für USB-Sticks ist hier zu finden:
"Hardware-Schreibschutz am USB-Stick nachrüsten"
https://www.vkldata.com/Schreibschutzschalter-am-USB-Stick-nachruesten

Für SD-Karten ist ein Kartenleser, welcher den Schieber berücksichtigt 
auch eine gute Lösung.
Für 99,99% der Viren sollte das eine enorme Hürde sein.
Ein gelegentlicher Checksummentest...

Wie sicher soll Dein System werden?
Anwendungsfälle?


Gerne nehme ich noch Verbesserungen oder neue Vorschläge auf.

[Torsten C. (torsten_c)]

Frank K. schrieb:
> Das ist ein Controllerchip für Card Reader plus USB 2 High Speed Hub.
> Den Schreibschutz steuerst Du über Pin 13 (SD_WP).

Danke, Frank! Also einfach mal schauen, welcher Chip im Kartenleser ist. 
Da hätte ich eigentlich auch selbst drauf kommen können. :\

Manfred F. schrieb:
> Das Setzen des PERM_WRITE_PROTECT Bits im CSD ist nicht reversibel.
> Da kommt kein Virus dran vorbei.

Cool! Dieses Bit kannten hier sicher mehrere noch nicht, danke! :)

Volker schrieb:
> Viel zum Thema Hardwareschreibschutz hab ich hier zusammengetragen.

Cool! :) Da bin ich froh, dass Du meinen Thread gelesen hast.

> … Wie sicher soll Dein System werden?

Wenn mal irgendwas nicht so geht, wie es soll, möchte ich die Ursache 
"kompromittiertes storage device" erstmal außschließen können.
Anwendungsfälle^^: Boot- oder Recovery-Datenträger, oder sich einfach 
sicher fühlen, wenn der Kartenleser mit SD-Karte mal in einem fremden PC 
war.

[Jepp (Gast)]

Genau, du schmeißt den atmega Frosch an die  Wand und hoffst, dass er zu 
einem STM wird.

[Volker (Gast)]

Hallo Torsten,

Ich würde mit einem WP-Adapter beginnen, der den WP-Schieber 
berücksichtigt.
Grundprinzip: Immer nur etwas besser sein, als das erwartete/definierte 
Risiko.

Das sollte für die überwiegend meiste Malware und Ransomware (fremde 
PCs) etc. ausreichen. USB3.0 dann ists auch performant.
Allein das bringt mAn einen enormen Sicherheitsgewinn und Vertrauen.
Das Image gelegentlich mit einem Backup Vergleichen schafft weiteres 
Vertrauen..

Angriffe auf eine (die vielen) Firmwares, um etwas am Adapter zu 
manipulieren halte ich für sehr sehr speziell.
Wenn Du kein besonderer Geheimnisträger bist, dann wird vermutlich 
dieser Aufwand nicht an Dir exerciert werden;-)


Ich hatte auch ein OS-Projekt vorgeschlagen das auch die Firmware mit 
berücksichtigt:
https://www.vkldata.com/Open-Source-Projekte
Hier könnte die Black und Whiteliste der gefilterten Kommandos 
eingesehen werden (Blockade der Firmwareupdates/Manipulation)...
Kein BadUSB mehr...
Das wäre ein sinnvolles Projekt für eine Studien- oder 
Diplo.-Masterarbeit.
Wenn Jemand einen Prof. kennt, der das aufgreifen möchte, dann liefere 
ich gerne Ideen und Beratung dazu.

[Joachim B. (jar)]

c-hater schrieb:
> Torsten C. schrieb:
>
>> um SD-Karten z.B. zum Booten über USB wirklich sicher gegen Viren zu
>> machen, sollen sie einen zuverlässigen Schreibschutz haben.
>
> Haben sie nicht. Ich kenne jedenfalls keine einzige.

wofür steht das S in SD?

was ist mit:
Beitrag "Re: SD-Karten mit Schreibschutz - Hat das mal jemand analysiert?"

[Karl K. (karl2go)]

Torsten C. schrieb:
> Wenn mal irgendwas nicht so geht, wie es soll, möchte ich die Ursache
> "kompromittiertes storage device" erstmal außschließen können.
> Anwendungsfälle^^: Boot- oder Recovery-Datenträger, oder sich einfach
> sicher fühlen, wenn der Kartenleser mit SD-Karte mal in einem fremden PC
> war.

Kann man nicht unter Linux einstellen, dass ein Datenträger nicht 
gemountet wird? Dann kann man doch die SD-Karte, nachdem sie an einem 
fremden Rechner war, einstecken und erstmal plattmachen. Denn Daten von 
fremden Rechnern übertragen geht ja mit Schreibschutz eh nicht.

[Rolf M. (rmagnus)]

Joachim B. schrieb:
> wofür steht das S in SD?

Die Wikipedia beschreibt's ganz gut:

Der Name Secure Digital leitet sich von zusätzlichen Hardware-Funktionen 
für die Digitale Rechteverwaltung (DRM) ab. Mittels eines im geschützten 
Speicherbereich abgelegten Schlüssels soll die Karte das unrechtmäßige 
Abspielen geschützter Mediendateien verhindern.

[Joachim B. (jar)]

Rolf M. schrieb:
> Die Wikipedia beschreibt's ganz gut:

manno Wiki lesen kann ich auch, aber du gehst mit keinem Wort darauf 
ein!
Beitrag "Re: SD-Karten mit Schreibschutz - Hat das mal jemand analysiert?"

probierts doch einfach aus, entweder es funktioniert und der SD 
Schreibschutz ist gesetzt oder eben nicht!

Da braucht mir doch keiner Wiki zitieren!

[Rolf M. (rmagnus)]

Joachim B. schrieb:
> Rolf M. schrieb:
>> Die Wikipedia beschreibt's ganz gut:
>
> manno Wiki lesen kann ich auch, aber du gehst mit keinem Wort darauf
> ein!

Das war schon Absicht. Ich wollte damit ausdrücken, dass der Grund für 
die Bezeichnung wohl ein anderer ist als du denkst.