Thema: (CMD42) ein Befehl zum Karten-Update RNS310/RNS315 (AMUNDSEN+)

Zitat von MaxCH

...So wie ich das bisher verstehe braucht man einen modifizierten MMC Treiber und ein um das CMD42 Erweitertes MMC Tool:
-https://patchwork.kernel.org/project/linux-mmc/patch/1433526147-25941-8-git-send-email-alcooperx@gmail.com/
-https://media-www.micron.com/-/media/client/global/documents/products/technical-note/sd-cards/tnsd01_enable_sd_lock_unlock_in_linux.pdf
Das Kommand 42 ist sowohl fürs sperren als auch fürs Entsperren zuständig. Ich glaube derzeit eher, dass es ein Software Problem als eine Hardwareeinschränkung ist. Es ist deutlich wahrscheinlicher, dass irgendwas beim Linux Kernel, beim angepassten MMC Treiber, im CMD42 Tool oder im jeweiligen Zusammenspiel der HW Komponenten, Treiber und der angepassten Ubuntu 16.4 @Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Version nicht richtig funktioniert. Vielleicht kann es die HW, aber der angepasste Treiber erkennt das Gerät in dieser Konstellation nicht komplett ... irgedwie sowas...

das siehst du richtig. die 2-3 custom-kernels, die im netz rumschwirren, einschliesslich das von mir zusammengestellte 'simply@clever' basieren auf den patches von alan cooper. diese patches haben es aber leider nie geschafft aus dem beta-status rauszukommen. der dominierende teil der linuxkernel-entwickler hat das damals für nicht wesentlich erachtet und eine einbindung in den regulären kernel support nicht weiter unterstützt. ich hatte kurzzeitig per email kontakt zu dem programmierer der patches. er schien nicht gerade erfreut darüber zu sein, das seine arbeit zu diesem thema nicht gewürdigt wurde und hat wohl auch aufgrund dessen die programmierung alsbald daran eingestellt. insofern wurde seine arbeit im wesentlichen wahrscheinlich auch nur auf seinem computer (notebook) getestet. das ist einer der gründe, warum heutzutage nur ein paar notebook-typen mit diesen patches entsprechend umgehen können.

der von mir programmierte befehl 'cmd42' basiert auf der grundlage der 'Card Lock/Unlock Operation' aus der SD Spezifikation Teil 1 (Physical Layer Simplified Specification Version 2.00) und stellt nichts anderes zur verfügung als das locken/unlocken von sd-karten. auszüge davon findest du auch in der pdf-datei der firma micron, die im wesentlichen vorschlägt, diesen teil mit in das tool 'MMC' einzupflegen. das hatte im vorfeld wohl jemand auch schon versucht, aber ohne richtig darüber nachzudenken und auch nur sehr halbherzig. denn, wie die meisten inzwischen wissen fehlt bei dem gepimpten 'MMC', das seit der zeit im netz grassiert, die unlock-option. warum auch immer!? wie du inzwischen selbst festgestellt hast, wäre es ein leichtes gewesen diese option mit in 'mmc' unterzubringen. zu dieser fahlen erkenntnis kam ich damals (2017) auch und hatte mich animiert einen eigenständigen befehl (cmd42), der auch die unlock-option zur verfügung stellt, dafür zu programmieren.

Zitat von MaxCH

Wie dem auch sei, ich werde da die Tage mal ein wenig mit rumspielen, falls ich Zeit finden sollte. Habe da mittlerweile eh schon viel zu viel Zeit investiert, aber irgendwie wurmt es einen ja und man will es ausprobieren :-)

Eine Raspberry Pi Version wäre wie gesagt schön, einen PCI angebunden MMC/SD Leser/Schreiber hat er zumindest schonmal drin.
Hat das schon mal wer ausprobiert?

du bist ja gut! hast dich ein bischen ins thema eingelesen, ein paar sachen ausprobiert, hätts gerne noch ein raspberry pi variante und bist jetzt schon am stöhnen. kauf dir doch einfach eine originale sd-karte dann hast du das problem mit der zeit nicht. frag mich mal, wieviel zeit ich für die software investiert habe, die ich hier auf nachtfalke zur verfügung stelle. einschliesslich des täglichen supports auf anfragen etc.. umgerechnet in einen obulus von sagen wir mal von netterweise 20.- euro für eine informatikerstunde. käme ich da inzwischen auf eine summe, die das 100-fache der kosten einer original sd-karte mehr als deutlich übersteigen würde. ganz zu schweigen von all den mühen die andere leute da schon investiert haben. ich denke da in erster linie z.bsp. an @Link nur für registrierte und freigeschaltete Mitglieder sichtbar. dem wir es wohl im wesentlichen zu verdanken haben, das wir überhaupt karten-daten (maps) zu verfügung haben. oder @Link nur für registrierte und freigeschaltete Mitglieder sichtbar. der hier das ganze zeug und noch mehr tag/täglich für jeden zum download anbietet.

ebenso auch andere, die mit dem thema CID-change und sd-karten lock/unlock hier in diesem forum nichts weiter zutun haben. aber einen wesentlichen bestandteil dazu beitrugen, das es überhaupt möglich ist. wie 'Sean Beaupre' der in einer äusserst langwierigen prozedur die firmware eines samsung handys disassembliert hat und dabei auf verschiedene vendor-codes aufmerksam wurde, die gesperrte speicherbereiche dieses handys freischalteten. 'Richard Burton' der diese information dann für sich weiter nutzte, reichlich an samsung karten eingekauft hatte um damit zu experimentieren und an dessen ende er mit seinem programm 'evoplus_CID' erfolgreich die CID dieser karten verändern konnte.

spar dir die zeit mit dem weiteren ausprobieren, du wirst zu keinen neuen erkenntnissen kommen, die nicht schon lange bekannt sind und in anderen threads hier im forum nicht auch schon ausführlich diskutiert wurden. wenn du was gutes tun möchtest, dann nimm dir den kernel-source, die patches von alan cooper und passe die lock/unlock-routinen an die verschiedenen notebook-typen an. das wäre hilfreich. aber das frisst dann richtig deine zeit. denn der aufwand der dafür nötig ist, ist ähnlich komplex und umfangreich wie das reassemblieren einer unbekannten firmware. das macht man nicht von heute auf morgen. damit ist dir eine beschäftigung über mehrere monate, wenn nicht sogar mehr, gesichert.

mfg jori...

Ja das ist richtig Jori, da ist einiges an Zeit draufgegangen, aber so ist das bei Hobbys.
Das loggen des Datenstroms war in der Tat eine Herausforderung, somal ich mit logicanalysern noch keine Erfahrung hatte.
Dazu kam dann noch die Problematik mit passenden Treibern und Inkompatibilitäten aufgrund von Unterschieden der Nachbauten zum Original Analyser.
Dadurch hat das Ding sich erstmal geweigert mit dem PC zu reden.
Das hat mich einiges an Zeit gekostet und ich hatte noch Glück, dass ich mit einem sehr netten Herrn (der sehr vertraut ist mit der Analyzer Software) kommuniziert hatte, der mir sehr weitergeholfen hat das Problem zu lösen.
Und natürlich hat auch ein Beitrag, aus einem anderen Forum (ich weiß nicht, ob ich das hier nennen darf) hat sehr dabei geholfen, den Datenstrom zu analysieren.
Letztendlich konnte ich aber den Datenstrom analysieren und konnte das Passwort auslesen und damit war mein Ziel erreicht.

Das ganze ist aber nur für Leute, die das als Hobby sehen und bereit sind auch ein paar Euro dafür locker zu machen. Insgesamt hat mich der Analyser plus der SD-Sniffer gut 70 Euro (~) gekostet.
Wirklich sinnvoll weiterverwenden kann ich das nicht aber darum ging es mir auch nicht. Ich wollte sehen ob das geht, ich habe gesehen das es geht und gut ist. Hobbys kosten Geld, so ist das nunmal.
Man kann auf diesem Weg zu jeder CID ein Passwort finden aber es ist ein steiniger und sehr aufwendiger Weg, der auch einiges an Zeit und Aufwand benötigt.
Da ist die Passwort Generierung im WWW deutlich einfacher und mit 5€ auch erschwinglich. Aber wenn bei mir das Interesse geweckt wird, dann muss ich das herausfinden.

Die Berechnung des Passworts hingegen, habe ich schnell aufgegeben, da es einfach zu viele Möglichkeiten einer Verschlüsselung gibt und ohne zu wissen welcher Algorythmus verwendet wird ist es nicht möglich (für mich zumindest)
Ein reverse engineering war mir auch nicht möglich obwohl ich sehr gerne den Algorythmus geknackt hätte ;-)