ich habe mehrere defekte USB-Sticks.
Einer läßt sich nicht vollständig formatieren.
Bei einem anderen verliert er ständig die Partionierung.
Ein anderer wird nicht erkannt.
Die Daten darauf sind mir egal; sind also zum spielen...
Kennt jemand OSS Software Tools um z.B. per Low Level Funktionen auf die einzelnen Sektoren zuzugreifen, um diese zu testen?
Wie kommt man an das Betriebssystem bzw. die abgelegten Einstellungen heran?
Im Prinzip möchte ich diese softwaremäßig sezieren.
Also alles auslesen, testen und nach Möglichkeit verändern.
Hat jemand auch eine passende Dokumentation zu dem Thema?
Wie kommt man an das Betriebssystem bzw. die abgelegten Einstellungen
heran?
Welches Betriebssystem magst Du meinen? Welche Einstellungen?
Zwar ist in einem USB-Stick ein Controller verbaut, der das "Mass Storage Protocol" interpretiert und in entsprechende Zugriffe auf den verbauten Flash-Speicher umsetzt, aber weder ist standardisiert, wie er das tut, noch ist irgendeine Art und Weise standardisiert, wie man an dessen Firmware herankommt, oder wie und ob überhaupt irgendwelche Parameter dessen Verhalten beeinflussen.
Da kocht jeder Hersteller dieser Controller sein eigenes, komplett undokumentiertes Süppchen.
leider habe ich mir das schon so gedacht.
Ich hätte gern z.b. die Liste der defekten Blöcke; wo die Infos liegen über z.b.
Größe, Hersteller,Bezeichnung usw.
So viele Hersteller dürfte es gar nicht mehr geben; das wird doch alles eingekauft.
Mit dem Betriebssystem meinte ich den Controller, das ist doch meistens ein MC51 Derivat.
Und vor allem, wo sich alles versteckt und wie man darauf zugreifen kann.
Mit Low Level meinte ich, das ich direkt auf die einzelnen Speicherblöcke zugreifen kann.
ich verstehe Dein Anliegen nicht. Wenn es um den Aspekt der Datenrettung geht, interessiert mich nur ein Abbild der USB-Speichers, also eine serielle Folge aller Speicherblöcke in aufsteigender Nummerierung bezogen auf die LBA (logical block address) in Verbindung mit der Information, welche Blöcke nicht lesbar waren.
Welchen Wert haben denn die Rohdaten im Flashspeicher für Dich, die der Stick den LBA-Nummern zuordnen muss? Die können doch theoretisch wie Kraut und Rüben liegen und die Zuordnung der Blöcke nach außen ist wahrscheinlich nicht offensichtlich.
Handelt es sich hier wieder um ein geheimes Projekt? :)
das ist kein "geheimes" Projekt.
Der Hintergrund ist, daß ich den aktuellen Zustand des Sticks nicht auslesen bzw. bestimmen kann.
Bei Festplatten habe ich SMART, bei USB Sticks anscheinen nichts.
Dort gibt es nur geht oder geht nicht.
Weder weiß man, daß z.b. die fehlerhaften Blöcke zugenommen haben oder ähnlich problematisches.
Wenn er hin ist, dann meistens sofort.
Ohne Warnmöglichkeit.
Jogibär
PS: war von mir anscheinend eine Schnapsidee (ohne Schnaps;-))
Ich hatte mal ein Chinesisches Tool zum Controller flashen und zum Low Level Partitionieren unter Windows XP, ist aber durch die Win7/10 Updates verloren gegangen.
Ich musste bis jetzt nur einen USB-Stick wieder reanimieren.
Kaputt gegangen ist er an einer USB-PC-Card deren Spannungsversorgung
fuer den USB-Port wohl etwas schwach war.
Das hat die Firmware im Stick korrumpiert.
Ich hatte Glueck, und es gab tatsaechlich eine Software, mit der
man eine neue(!) Firmware wieder auf dem Stick installieren konnte.
Der verwendete Controller war von Alcor.
Der Bootlader im Stick, konnte ohne die Firmware immerhin noch
mit SCSI-Kommandos examiniert werden. So konnte ich z.B. den
Hersteller des Conrollers ohne(!) den Stick zu oeffnen, auslesen.
Das geht unter Windows mit dem Kommandozeilen Tool "plscsi".
Mit GUI ist mir da nichts bekannt, und fuer Linux auch nicht.
Man braucht aber schon recht gute Kenntnisse, wie SCSI-Befehle
funktionieren. Im Prinzip konnte man damit auf dem Stick wohl fast
alle SCSI-Kommandos, da gibt es z.B. auch "Block lesen", ausfuehren.
Das mag bei anderen Stick-Herstellern aber auch wieder anders sein.
Ich musste bis jetzt nur einen USB-Stick wieder reanimieren.
Kaputt gegangen ist er an einer USB-PC-Card deren Spannungsversorgung
fuer den USB-Port wohl etwas schwach war.
Das hat die Firmware im Stick korrumpiert.
Ich hatte Glueck, und es gab tatsaechlich eine Software, mit der
man eine neue(!) Firmware wieder auf dem Stick installieren konnte.
Der verwendete Controller war von Alcor.
Der Bootlader im Stick, konnte ohne die Firmware immerhin noch
mit SCSI-Kommandos examiniert werden. So konnte ich z.B. den
Hersteller des Conrollers ohne(!) den Stick zu oeffnen, auslesen.
Das geht unter Windows mit dem Kommandozeilen Tool "plscsi".
Mit GUI ist mir da nichts bekannt, und fuer Linux auch nicht.
Man braucht aber schon recht gute Kenntnisse, wie SCSI-Befehle
funktionieren. Im Prinzip konnte man damit auf dem Stick wohl fast
alle SCSI-Kommandos, da gibt es z.B. auch "Block lesen", ausfuehren.
Das mag bei anderen Stick-Herstellern aber auch wieder anders sein.
YMMV.
Hallo,
das muß dann aber meiner Meinung nach von dem USB Chip unterstützt werden.
SMART (HDD) über USB Adapter funktioniert nur bei wenigen.
Das soll auch über SCSI Kommandos laufen.
Bei mir über keinen Adapter, den ich habe.
Bei USB Sticks ist dies gar nicht vorgesehen.
das muß dann aber meiner Meinung nach von dem USB Chip unterstützt
werden.
SMART (HDD) über USB Adapter funktioniert nur bei wenigen.
Das soll auch über SCSI Kommandos laufen.
Bei mir über keinen Adapter, den ich habe.
Bei USB Sticks ist dies gar nicht vorgesehen.
Jogibär
Es tut mir ja leid, aber zu deinen frustrierenden Ergebnissen
kann ich nichts sagen. Der USB-Chip war wohl einer von NEC/Renesas,
und es waren auch keine "speziellen" Treiber o.ae. installiert.
Hast du den Zugriff mit "plscsi" schon einmal versucht?
Wenn, dann werden die Smartwerte vermutlich auch nur ein "Datenblock"
bei den SCSI-Status/Konfigurationsseiten sein.
PS: war von mir anscheinend eine Schnapsidee (ohne Schnaps;-))
Spieltrieb ist ein legitimes Motiv - ohne Spieltrieb kein Fortschritt!
Für den Anfang probiere 'mal ddrescue von der Gnu-Foundation auf dem "nackten" Gerät aus. Die Ausgabe musst Du nicht irgendwo hinschreiben
/dev/null reicht aus.
Wichtig ist, dass Du eine Logdatei verwendest und Du die hinterher sicherst.
Da steht dann detailliert drin, was Du zusammengefasst im Terminal-Fenster siehst. Von diesem machst Du bitte ein Bildschirmfoto oder eine Textkopie.
In den Anhaengen einmal eine SCSI-Inquiry mit "plscsi",
und was Diskinfo als Smartwerte liest.
Angeschlossen war die Platte ueber einen Logilink USB-SATA-Adapter.
Mit USB-Sticks funktioniert "plscsi" auch heute noch.
Ein wenig SCSI ist wohl in allen drin. :)
Der zweite ist uebrigens einer von Philips. Da war ein "Branding"
wohl zu teuer. :)
Was das Kopieren an Erkenntnissen bringen soll?
Mit einer kaputten Firmware kopiert sich da exakt gar nichts.
Und mit einer halb kaputten Firmware/Status, wird man auch nur
erratische Daten lesen koennen.
Ein Erkenntnisgewinn haelt sich da in Grenzen.
Dein Lowlevel-Tool heisst scsi generic device. Da gibt es unzaehlige Wrapper u.a. auch fuer Python um alle moeglichen Vendor-SCSI-Kommandi an die Dinger zu schicken. Jetzt musst du nur noch etwas detektivische Arbeit aufwenden, den Controller zu ermitteln (meistens reicht VID:PID-Recherche).
Die Taiwan-Derivate wie Phison usw. haben oft in der Tat 8051-kompatible Kerne drin, die man auch selber programmieren kann. Deren Datenblaetter findet man auch auf chinesischen Tauschforen - auf chinesisch. Die meisten Architekturen aehneln dem uralten "Chip for People" (CFP8051 o.aeh).
Der Gag bei solchen Chips besteht meistens darin, die richtigen SCSI-Kommandi an die Chips zu schicken, mit denen man dann an die Interna wie die Firmware rankommt, oder seine eigene Firmware in die Bootbloecke reinschreibt.
Aber nicht, dass du dann deinen modifizierten Stick auf dem Parkplatz eines bekannten Frankfurter Geldwaescheinstituts verlierst, ne.
ja sowas ähnliches suche(te) ich für Linux.
Ich bin ja auch manchmal unglaublich naiv...
Dachte, da kann man mit geringem Aufwand was machen.
Die meisten defekten Sticks sind von Intenso mit 64GB.
Mit dem durchsichtigen orangen Gehäuse.
Sind zwar spottbillig und unglaublich langsam,
aber die Haltbarkeit ist mies.
Werde in Zukunft auf diese verzichten.
Trotzdem Danke an alle.
ein Programm zum Testen und Korrigieren von Flash-Speicher für Linux sind die f3 Tools.
Einfach Mal mit apt-get f3 installieren und dann als root das entsprechende mit Parametern starten.
Beschreibung z.B. hier https://fight-flash-fraud.readthedocs.io/en/latest/index.html
Das verwende ich bei jedem neuen Speicher, denn manchmal stimmt der Aufdruck nicht mit der wirklichen Kapazität überein ;-) . Dann kann man das damit korrigieren und den Speicher problemlos verwenden.
