Hallo Experten, ich bin hier irgendwie am verzweifeln. Hintergrund: Vor kurzem hatte ich ein neues (gebrauchtes) Auto gekauft und das Ding hat serienmässig ein Navi. Die Kartendaten sind auf einer 16GB SD-Karte (volle Größe) gespeichert und diese Karte ist ständig im Kartenleser des Navis. Nun hatte ich schon genug verreckte SD-Karten erlebt und dachte, es wäre sicher eine gute Idee von dieser Navi-Karte eine Sicherheitskopie (Clone) anzufertigen. Also die Navi-Karte in den Kartenleser meines Win10-Rechners eingesteckt und sie wird dabei promt mit Signalton als Laufwerk E angezeigt, allerdings ohne jeden Inhalt. Die danach aufgerufene Datenträgerverwaltung sieht auch ein Laufwerk E, zeigt aber hier "Kein Medium" auf. Aha, dachte ich, sicher irgendeine andere Art der Formatierung, oder so und man hört ja so viel vom Alleskönner Linux. Deshalb einen Laptop per USB-Stick mit einem Linux-Mint gebootet und in den Laptop-Kartenleser die (verflixte) Navi-Karte eingeschoben. Ergebnis: Nichts, einfach gar nichts. Keinerlei Hinweis, dass sich etwas per Kartenleser getan hat. Als Gegentest hatte ich danach testhalber eine andere, per Fat32 formartierte Karte versucht. Die wurde sofort erkannt und ihr auch Inhalt dargestellt. Tja, nun frage ich mich als Nicht-Experte wie kann das sein? Gibt es irgendwelche Formatierungssysteme, die solche Karten in üblichen Rechnern nicht lesbar machen ??? Ich danke fürs Lesen und noch viel mehr für hilfreiche Tipps. Tschüss Uwe
Uwe schrieb: > Gibt es irgendwelche Formatierungssysteme, die solche Karten in üblichen > Rechnern nicht lesbar machen ??? Jo, du hast ja da gerade eine. Unter Linux kannst du probieren, mit dd erstmal eine Kopie zu erstellen, das sollte eigentlich klappen. (Blockdevice mal in /dev oder /udev angucken). Die Auswahl an Dateisystemen ist riesig und dann gibt es noch selbstgebritzelte.
> 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... :-)
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.
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...
Beitrag #5966950 wurde von einem Moderator gelöscht.
Erwin D. schrieb: > Aber meine Zweifel beziehen sich auf ein Navi, welches standardmäßig in > einem Auto verbaut ist... Kosten-Nutzen: hat irgendwer was davon, ein Dateisystem zu implementieren (außer dass es Zeit und damit Geld kostet)? Nein? Dann wird es auch nicht gemacht. Gerade in der Autoindustrie wird auf jeden Cent geschaut. Netter Nebeneffekt: Der 0815-Anwender schafft es nicht, das Kartenmaterial runterzuziehen und an seinen Freund weiterzugeben.
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.
Beitrag #5966963 wurde von einem Moderator gelöscht.
Erwin D. schrieb: > 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... Jo klar, aber mein Punkt war, dass es im Zweifel einfacher ist, das Dateisystem wegzulassen ;)
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 ???
Uwe schrieb: > 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 ??? Oh, bitte nicht! Was sollen wir mit einem 16-GB-Dump?
> 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.
Erwin D. schrieb: > 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 gab einstmals ein Betriebssystem mit eigentlich ganz normalen Filesystem, nur wurden die Daten zwecks Tarnung invertiert.
... 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?
Uwe schrieb: > Will sagen, wie kann ich dieses "dmseg" > aktivieren? Terminal öffnen, ›dmesg -w‹ eingeben und Enter ([⏎]) drücken. Karte einstecken, Terminal beobachten.
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.
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?
Uwe schrieb: > Tja, nun frage ich mich als Nicht-Experte wie kann das sein? > Gibt es irgendwelche Formatierungssysteme, die solche Karten in üblichen > Rechnern nicht lesbar machen ??? SD-Karten tragen ja das "S" im Namen, was "secure" heißen soll, im Sinne von DRM Kopierschutz und Konsorten. Vielleicht ist bei dieser Karte der DRM-Mechanismus aktiviert. Damit will sich der Rechteinhaber davor schützen, dass ein kostenpflichtiges Kartenupdate (ca 400€ bei manchen Herstellern) nur einmal und nicht für jeden Wagen gekauft wird. JEDE produzierte SD-Karte (aber nicht MMC und auch nicht eMMC) hat diese DRM-Geschichten eingebaut, aber aktiviert sind sie nur sehr selten. Du könntest so eine Karte haben. Dann hast Du verloren und musst auf Deine 400€ SD-Karte sehr gut aufpassen. fchk
:
Bearbeitet durch User
Noch ein schönes Detail: SD Karten haben eine UID. Manche Hersteller nutzen die, um daraus einen Schlüssel abzuleiten und damit die Daten (egal welches Filesystem) zu verschlüsseln. Wenn das bei deiner Anwendung der Fall ist, brauchst Du Dir um Sicherungskopien keinen Kopf zu machen.
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. ;-)
Beitrag #5967631 wurde von einem Moderator gelöscht.
Hallo Uwe, eventuell helfen Dir die beiden Kommandos lsscsi Ausgabe z.B. (ohne SD-Karte) >lsscsi [0:0:0:0] cd/dvd PLDS DVD+-RW DS-8A9SH ED11 /dev/sr0 [6:0:0:0] disk ATA WDC WDXXXXXXXX-0 1M03 /dev/sda [6:0:1:0] disk ATA WDC WDXXXXXXXX-0 1M03 /dev/sdb Ausgabe z.B. (mit SD-Karte in einem TMC USB Karten Adapter) >lsscsi [0:0:0:0] cd/dvd PLDS DVD+-RW DS-8A9SH ED11 /dev/sr0 [6:0:0:0] disk ATA WDC WDXXXXXXXX-0 1M03 /dev/sda [6:0:1:0] disk ATA WDC WDXXXXXXXX-0 1M03 /dev/sdb [7:0:0:0] disk Generic Compact Flash 0.00 /dev/sdc [7:0:0:1] disk Generic SD/MMC 0.00 /dev/sdd [7:0:0:2] disk Generic microSD 0.00 /dev/sde [7:0:0:3] disk Generic MS/MS-PRO 0.00 /dev/sdf [7:0:0:4] disk Generic SM/xD-Picture 0.00 /dev/sdg oder fdisk -l (mit eingesteckter SD-Karte) Disk /dev/sdd: 59.49 GiB, 63864569856 bytes, 124735488 sectors Disk model: SD/MMC Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdd1 32768 124735487 124702720 59.5G 7 HPFS/NTFS/exFAT Beide Kommandos must Du als Root (d.h. Superuser) oder via vorangestelltem sudo ausführen. d.h. su - (eingeben (mit blank und Minus) und mit root Passwort anmelden, danach) lsscsi oder fdisk -l aufrufen oder sudo lsscsi oder sudo fdisk -l aufrufen Wenn Du Deine original SD-Karte und die leere SD-Karte für die Sicherung identifiziert hast, musst Du dann mittels dd die Karten kopieren. Aber Vorsicht nicht das Ziel mit der Quelle vertauschen. Parameter von dd sind: if Input Device oder File of Output Device oder File bs Block Größe (block size) In Deinem Fall 1M für 1MB status =progress um den Fortschrittsbalken zu sehen. Somit lautet Dein dd Kommando su - (root login) dd if=/dev/sdX of=/dev/sdY bs=1M status=progress sync (um den Schreib-Cache zu leeren) erst wenn sync wieder zurückkommt kannst Du die beiden Karten vom PC trennen!!! mittels sudo sieht es so aus: sudo dd if=/dev/sdX of=/dev/sdY bs=1M status=progress sudo sync Wobei X und Y die zugehörigen Namen im Device-Tree Deiner SD-Karten sind und b,c,d,e,f,... etc. als Buchstaben sein können. Steck erst Deine leere Karte ein um Dich mit den Befehlen lsscsi oder fdisk -l oder beiden vertraut zu machen. Es gibt auch Linux Distributionen, bei denen lsscsi nicht installiert ist und nachinstalliert werden muss. Ich hoffe diese Beschreibung hilft Dir weiter. Markus
Beitrag #5967670 wurde von einem Moderator gelöscht.
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.
Uwe schrieb: > Na ja, das Auto ist KEIN Trabant. ? Waren im Trabi nicht solche Navis eingebaut? https://img.oldthing.net/4367/29562125/0/n/Autoatlas-Deutsche-Demokratische-Republik-DDR-mit-Bulgarien-CSSR-Polen-Rumaenien-UdSSR-Ungarn.jpg
Einen Versuch wert wäre vielleicht wenn Du eh auf Windows zuhause bist der "Win32 Disk Imager", häufig klappt der ganz gut und du bekommst ein Image der kompletten Karte über Partitionsgrenzen hinweg und auch von Bereichen, die Windows so nicht erkennt.
Harald W. schrieb: > Waren im Trabi nicht solche Navis eingebaut? Das war nicht das Navi, sondern die SD-Karte.
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.
Da bräucht man dann ein µC mit 2x SDIO der on the fly die Seriennummer manipulieren kann :) (wird dann aber wirklich nen übles gefrickel)
Sind die Dateien vielleicht nur "versteckt" (Attribut)? Schon mal die Ordner-Ansicht umgestellt, damit man alle Dateien (versteckt & Systemdateien) sieht?
Uwe schrieb: > Nun hatte ich schon genug verreckte SD-Karten erlebt Mach dir keine Sorgen, solange die Karte nur gelesen wird. In meinem seit einigen Jahren laufenden Dauertest gehen Karten nur dann kaputt, wenn auf sie geschrieben wird. Solange sie nur gelesen werden (und sonst Strom für interne Verwaltungsaufgaben wie Blockauffrischung haben), booten die Karten problemlos zigmillionen mal. > Gibt es irgendwelche Formatierungssysteme, die solche Karten in üblichen > Rechnern nicht lesbar machen ??? Es ist eher andersrum: von allen möglichen denkbaren Formatierungssystemen, die es für SD-Karten geben könnte, gibt es nur eine gute Handvoll, die mit einem PC lesbar sind. So, wie auch der Platinen Frickler schrieb: >> Wir verwendeten auch kein FAT32 für die SDKarte, sondern beschrieben sie >> direkt im Block Verfahren. Wir dachten uns wirklich nichts "Böses" dabei.
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.
Beitrag #5972079 wurde von einem Moderator gelöscht.
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...
Angehängte Dateien:
-
Clonezillas_Irrtum.jpg
40 KB
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.
Wäre jetzt auch nicht das erste Mal, es gibt zumindest z.B. einige Kopierschutz-Varianten, die sowas oder was ähnliches machen (z.B. einfach die Prüfsumme ändern oder so).
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.