Zauberei mit SD-Karten ?

> von dieser Navi-Karte eine Sicherheitskopie (Clone) anzufertigen

Dann mach eine Block-Level-Kopie (Linux z.B. per "dd").

> Gibt es irgendwelche Formatierungssysteme, die solche Karten in
> üblichen Rechnern nicht lesbar machen ???

Ja - man muß nicht mal formatieren.  Bei einer Block-Level-Kopie spielt 
das aber keine Rolle.

Matthias S. schrieb:
> selbstgebritzelte.

Selbstgebritzelte Filesysteme in einem Navi, welches standardmäßig im 
Auto verbaut ist? Kann ich nicht so recht glauben. Obwohl, der Autolobby 
muss man alles zutrauen... :-)

Sven B. schrieb:
> Erwin D. schrieb:
>> Matthias S. schrieb:
>>> selbstgebritzelte.
>>
>> Selbstgebritzelte Filesysteme in einem Navi, welches standardmäßig im
>> Auto verbaut ist? Kann ich nicht so recht glauben. Obwohl, der Autolobby
>> muss man alles zutrauen... :-)
>
> Naja, im einfachsten Fall kannst du zB einfach die Daten ohne
> Partitionstabelle auf die Karte schreiben. Braucht ja nicht unbedingt
> ein Dateisystem. Oder ein Tar- oder Zip-Archiv draufdumpen. Dafür
> braucht's auch kein Dateisystem.

Klar, kann man alles machen, das ist schon klar.
Aber meine Zweifel beziehen sich auf ein Navi, welches standardmäßig in 
einem Auto verbaut ist...

Ein Schelm, wer Böses dabei denkt?

Vor zehn Jahren entwickelten wir in der Firma eine industrielle 
Steuerung mit Logging der Daten. Intern war eine 512MB SDKarte fest 
eingebaut (nicht vom Benutzer ohne Öffnen zugänglich) die allerdings 
über einen USB Memory Stick kopiert werden konnte. Wir verwendeten auch 
kein FAT32 für die SDKarte, sondern beschrieben sie direkt im Block 
Verfahren. Wir dachten uns wirklich nichts "Böses" dabei. Es war für 
unsere Anwendung einfach viel effizienter ohne FAT System auszukommen. 
Der Benutzer konnte ja über USB die Daten kopieren.

Guten Abend
und ich danke herzlich für die zahlreichen Antworten.

Nur: Ich hatte doch geschrieben, dass die Karte per Win10 nicht 
zugreifbar ist und per Linux überhaupt nicht erkannt wird.

Wie sollte ich also z.B. "mit dd erstmal eine Kopie zu erstellen...", 
oder
"...eine Block-Level-Kopie (Linux z.B. per "dd")" realisieren?

Erwin D. schrieb:
> meine Zweifel beziehen sich auf ein Navi, welches standardmäßig in
> einem Auto verbaut ist...

Na ja, das Auto ist KEIN Trabant.  ?

MaWin schrieb im Beitrag #5966963:
> Er soll einen Dump der Karte machen und hier hochladen, damit wir es
> analysieren können.

Wie denn, bitte sehr ???

> Wie sollte ich also z.B. "mit dd erstmal eine Kopie zu erstellen...",
>oder "...eine Block-Level-Kopie (Linux z.B. per "dd")" realisieren?

Such mal per Google nach "Linux kopie dd" ...

> per Linux überhaupt nicht erkannt wird

Wenn Windows die Karte zumindest ohne Inhalt erkennt, wird ein
Linux auch etwas lesen koennen. Nur eben direkt vom Blockdevice.
Tu dir einen Gefallen und lass ein dmesg in einem Terminal laufen.
Da wirst du sicherlich beim Einlegen der Karte einige Zeilen
Log bekommen die dir als Finngerzeig auf das richtige Device
dienen koennen.
Ansonsten das selbe auch mal mit einer "normal" formatierten
Karte versuchen. Da eine SD-Karte einen MBR enthaelt, wird
es aber wohl ein anderes Blockdevice sein.
Ob die "Navi"-Karte eine Partitionstabelle enthaelt musst du
dann selber herauskriegen.

... schrieb:
> Tu dir einen Gefallen und lass ein dmesg in einem Terminal laufen.

Ja gerne.
Aber ich bin ein Linux-Idiot. Will sagen, wie kann ich dieses "dmseg" 
aktivieren?

Sorry für meine doofen Fragen, aber ich bin nun mal kein Computerfreak.

Uwe

A. K. schrieb:
> nur wurden die Daten zwecks Tarnung invertiert.

Das hört sich sehr interessant an....

Nur, wie darauf reagieren?

Wie weit kommt man hier mit Clonezilla?
https://www.heise.de/download/product/clonezilla-49483

Du kannst vor und nach dem einlegen der Karte auch einmal lsblk ins 
Terminal eingeben. Damit wird Linux dir zeigen, was es aktuell an 
Blockdevices kennt und eventuelle Partitionen anpassen.

*anzeigen

Oh, ich sehe gerade:
das Kommando "lsblk -f" zeigt die Partitionen inklusive Filesystem an.

rbx schrieb:
> Clonezilla?

Was meldet Clonezilla bei Erstellung eines Images?
Nix gefunden oder tut es was?

Früher, als SD-Karten so um 32 MB hatten, gab es regelmäßig Unfälle mit 
dem DRM-Bereich. Die Karte wurde dann nicht mehr erkannt, der Rechner 
fror beim Einsetzen ein paar Minuten lang ein, oder die Daten waren 
nicht lesbar ("ihr Medium ist nicht formatiert") -- und in einem anderen 
System lief alles wieder einwandfrei. Das war der Grund dafür, warum 
SD-Karten so einen schlechten Ruf hatten und Profis grundsätzlich CF 
verwendeten. Die SD-Hersteller haben dann sogar ein offizielles "SD 
Fomatter Tool" herausgegeben, um (u.a.) das DRM neu zu initialisieren.

Diese Probleme sind lange abgestellt. Aber einem OEM-Navi würde ich 
durchaus zutrauen, DRM bewusst und mit Absicht als Kopierschutz zu 
verwenden. Dann hättest Du genau die Symptome.

Uwe schrieb:
> Er soll einen Dump der Karte machen und hier hochladen, damit wir es
> analysieren können

Natürlich schrieb nicht ich so einen Quatsch, sondern ein Psychopath der 
gerade seinen psychotischen Schub hat, und seine Ergüsse wurden 
inzwischen von einem Mod gelöscht.

Proprietäre Speicherformste gibt es bei KFZ Navis immer wieder, der 
Hersteller freut sich über Mehreinnahmen. Ersetze den ganzen 
Navi-Scheiss durch ein quer eingebautes 7" Android. Das geht dsnn zwar 
nicht im Tunnel, ist aber immer up to date (na ja, soweit Google hat 
Maps pflegt).

A. K. schrieb:
> Es gab einstmals ein Betriebssystem mit eigentlich ganz normalen
> Filesystem, nur wurden die Daten zwecks Tarnung invertiert.

Es reicht ja schon, irgendein "Magic Number"-Byte im Header eines 
bekannten Dateisystems auf einen anderen Wert zu setzen. Normale 
Betriebssysteme erkennen dann nicht mehr, daß es meinetwegen FAT32 ist, 
aber man kann seine ganzen Zugriffsroutinen weiter benutzen, sofern man 
eben im Header den einen geänderten Byte-Wert abfragt. Der 
Entwicklungsaufwand ist hier so minimal, daß er sich schon bei der 
ersten verhinderten Kopie rechnet.

Klar, rightige Profis für Softwarepiraterie hält das nicht ab. Aber Otto 
Normalkopierer guckt in die Röhre. ;-)

Ich hatte mal ein ähnliches Problem mit einer SD Karte, die ich auf 
meinem PC mit Ubuntu 16.04 für den Raspberry Pi 3 vorbereitet habe.

Auf dem PC habe ich die SD Karte erst mit f3 geprüft, anschließend 
formatiert und dann Rasbian draufgeschmissen.
Aber das Rasperry Pi 3 wollte von der SD nicht booten, er hat die SD 
erstmal nicht erkannt.


Leider weiß ich nicht mehr so genau, was genau das Problem war.
Entweder lag es am SD Card Reader der 5.25" Frontblende oder daran, dass 
die Partition erst ab einem bestimmten Offset anfangen durfte.

Irgendwie habe ich das dann gelöst und dabei einen alten USB 1.1 SD Card 
Reader verwendet.
Entweder ging es mit diesem oder ich habe die anders Partitioniert.
Aber wie schon gesagt, ich kann mich nicht mehr genau daran erinnern, 
eventuell habe ich es irgendwo aufgeschrieben.

Ich würde aber auf jeden Fall mal empfehlen, die SD Karte in einem 
anderen SD Card Reader zu testen.

Das kopieren der Karte wird aber ggf. nicht ausreichen. Es kann sein, 
daß auch die Seriennummer der SD-Karte geprüft wird. Dann muß auch eine 
ganz offiziell gekaufte Karte vom Händler im Navi erst freigeschaltet 
werden.

Sind die Dateien vielleicht nur "versteckt" (Attribut)?
Schon mal die Ordner-Ansicht umgestellt, damit man alle Dateien 
(versteckt & Systemdateien) sieht?

Ein USB Image-Tool sollte dafür schon reichen, mit einer CF-Karte hatte 
ich vor Kurzem das gleiche Problem unter WIN, mit dem Tool von heise.de 
hat es dann irgendwie gefunzt das Image davon runter zu ziehen.
Danach ging dann das große Grübeln los was wohl in dem Image drin sein 
mag.

Vielleicht geht´s schrieb:
> Sind die Dateien vielleicht nur "versteckt" (Attribut)?

Klar, auf der Karte ist sicher ein NTFS. Weil das ja so super 
standardisiert ist, baut man das auch an Stellen ein, die nie mit 
Windows in Kontakt kommen...

oszi40 schrieb:
> Clonezilla bei Erstellung eines Images?

Clonezilla macht doch nicht alles 1:1 am Anfang wie ein Diskeditor 
zeigte.

ntfs schrieb:
> Vielleicht geht´s schrieb:
>> Sind die Dateien vielleicht nur "versteckt" (Attribut)?
>
> Klar, auf der Karte ist sicher ein NTFS. Weil das ja so super
> standardisiert ist, baut man das auch an Stellen ein, die nie mit
> Windows in Kontakt kommen...

Es ist durchaus möglich, dass das Navi mit Linux als Betriebssystem 
arbeitet.
Bei den alten TomToms war das zumindest der Fall.
Vielleicht mal mit ext2fsd probieren, ob sich was lesen lässt.

oszi40 schrieb:
> wie ein Diskeditor zeigte.

Mazda-Navi Navigon-Daten FAT32 sind lesbar, aber nicht so einfach als 
Image zu sichern wie ein Beispiel mit Clonezilla zeigte, da am Anfang 
der SD einige Differenzen ins Auge fallen.

Also was Seat(VW)-Navis der Generation ca. 2010 - 2016 angeht gilt laut 
meinen Recherchen im Internet folgendes (bin kein Insider):

Hier sind die Kartendaten typischerweise auf dem Navi gespeichert, das 
Kartenupdate kommt aber per SD-Karte.
Dann kann man sich entscheiden die Kartendaten auf der SD-Karte zu 
belassen oder auf das Navi zu kopieren. Wenn ich mich noch erinnere wird 
aber vor dem Kopieren vom Navi verlangt die Karte mit dem Navi (d.h. mit 
der Navi-Seriennummer) fest zu verheiraten, so dass sie danach nicht auf 
ein anderes Navi erneut kopiert werden kann. Das geschieht indem im 
Root-Verzeichnis der SD-Karte eine Datei mit der Navi-Seriennummer 
abgelegt wird.

Und damit man mit den SD-Karten keinen Schindluder betreibt hat VW das 
eigentlich recht clever gelöst.
 - Die Karte ist mit einem Standard-Dateisystem formatiert, also 
FAT-irgendwas
 - Standardmäßig ist bei den SD-Karten der Sicherheitsmodus aktiviert 
(mit einem stinknormalen Passwort, Passwortalgorithmus nimmt als 
Quelldaten die SD-Karten-Seriennummer), so dass die Karte gelockt ist 
und keinen Zugriff lesend/schreibend auf den Speicherinhalt zulässt
 - Für mehr Infos über den Sicherheitsmodus empfehle ich ein Studium des 
frei erhältlichen SD-Karten-Standards (Norm)
 - In diesem Sicherheits-Modus kann zumindest die Seriennummer der 
SD-Karte gelesen werden (vermutlich noch so einige andere Info die der 
SD-Kartenhersteller in dem Block ablegt) und natürlich kann die 
Unlock-Funktion (wenn man das korrekte Passwort hat) aufgerufen werden, 
das Passwort ist ja wie gesagt mittels eines Algorithmus von der 
SD-Karten-Seriennummer abgeleitet
 - Der PW-Algorithmus ist vermutlich recht simpel, aber eben ein 
"Geheimnis", jeder der das Geheimnis kennt kann die Karte unlocken und 
danach kopieren oder manipulieren (Lock-Datei löschen z.B.) und danach 
wieder locken und die Karte kann ein weiteres Mal für ein anderes Navi 
verwendet werden
 - Der Algorithmus ist meines Wissens bis jetzt nicht im Internet 
gelandet, es gibt aber Leute die auf Nachfrage und viel Bitte Bitte für 
eine SD-Karten-Seriennummer das passende Passwort verraten ohne den 
Algorithmus dabei preiszugeben


Fun Fact: Es gab eine bestimmte Serie von SD-Karten von Samsung die 
einen HW oder FW-Bug hatten: Der Hersteller-Block mit der 
SD-Karten-Seriennummer war nicht schreibgeschützt ausgeführt. Das 
machen/machten sich manche Leute zu eigen und nutzten solche Karten um 
die SD-Karten-Seriennummer zu ändern auf eine Seriennummer zu der das 
korrekte Passwort bereits im Internet zu finden war, denn dann braucht 
man diese undurchsichtigen Informaten nicht und muss nicht Bitte Bitte 
sagen;-)

Fun Fact2: Es gibt nicht viele SD-Kartenleser für PCs die FW-mäßig 
"dumm" genug sind unter Linux sich so low-level ansprechen zu lassen, 
dass die SD-Karten Funktion "Lock" und "Unlock" durchführbar ist. 
Vielleicht ist es auch Absicht, jedenfalls muss man dafür entweder 
selbst einen SD-Kartenleser bauen und den Treiber selbst schreiben oder 
man kauft ganz bestimmte dafür bekannte alte Notebooks die den passenden 
SD-Kartenleser eingebaut haben um das Lock und Unlock mit dem richtigen 
Linux auf der Kommandozeile durchfüren zu können.

Und ganz zu guter Letzt: Auf Ebay finden sich immer wieder seeeehr 
günstige (relativ original aussehende) SD-Karten mit Updates für diese 
Navis. Dreimal dürft ihr raten wie diese Händler (die oft aus den 
östlichen Ländern kommen) diese SD-Karten so günstig anbieten können...

Have fun!

Ärgerlich ist, wenn ein Hersteller kein Backup zulässt und der Kunde 
dann für viel Geld seine kaputte SD tauschen soll. Ein geeigneter 
Disk-Editor könnte wahrscheinlich einige fehlerhafte Werte der SD 
berichtigen?

Erwin D. schrieb:
> Matthias S. schrieb:
>> selbstgebritzelte.
>
> Selbstgebritzelte Filesysteme in einem Navi, welches standardmäßig im
> Auto verbaut ist? Kann ich nicht so recht glauben. Obwohl, der Autolobby
> muss man alles zutrauen... :-)

Es sollte genügen ein bestehendes Dateisystem leicht zu modifizieren, 
dass andere Software diese nicht mehr mehr lesen kann.
Man müsste also nicht einmal ein komplett neues Dateisystem entwickeln, 
wenn man nicht will, dass andere dieses lesen können.


Ganz stupides Beispiel ohne jetzt tief in die Materie einzutauchen, also 
nicht perfekt, sondern nur als grobes Beispiel.
Z.B. in dem man die inode Nummern invertiert.
Macht man das, dann kommt kein klassischer Dateisystemtreiber damit mehr 
klar, der eigene Treiber allerdings schon.

Natürlich muss noch ein bisschen mehr gemacht werden, damit ein 
Dateisystem nicht als Dateisystem X erkannt wird, aber das sollte nicht 
das Problem sein.

Wichtig ist ja nur, dass die grundsätzlichen Algorithmen die gleichen 
bleiben und man sich somit viel Arbeit spart und man Datensicherheit und 
Robustheit behält.

Als typische Kandidaten bieten sich die meisten Dateisystemtreiber von 
bspw. FreeBSD an, denn die sind lizenztechnisch recht unproblematisch.

Nano schrieb:

> Es sollte genügen ein bestehendes Dateisystem leicht zu modifizieren,
> dass andere Software diese nicht mehr mehr lesen kann.

Brauchst Du doch gar nicht. SD-Karten haben ihren DRM-Bereich, über den 
man den Inhalt verschlüsseln kann. Deswegen heisst diese Evolutionsstufe 
ja "secure digital" -- die Urform ohne Verschlüsselung hiess MMC 
(multi-media card).

Ich kann mich noch an die Anfänge der SD-Karten erinnern, als diese 
Verschlüsselung öfter mal von alleine losging. Dann war die Karte 
plötzlich nicht mehr lesbar oder brachte sogar den Rechner zum Absturz. 
Das ging soweit, dass die SD Group schließlich ein Tool zum 
lowlevel-Formatieren der Karten veröffentlichte. Damit konnte man die 
Dinger wiederbeleben.