Wechsel von Clover auf OpenCore

Ging auch weniger an/gegen Dich julian91 sondern war eher allgemein gesprochen

Gerade die Punkte RequireVault und RequireSignature werden ja gerne und oft fälschlicherweise mit FileVault in Verbindung gebracht und da ist es meiner Meinung nach wichtig aufzuklären wo immer dieser Irrglaube auftaucht. Ich finde es eben wirklich kritisch wenn ein Sicherheitsrelevantes Feature abgetan wird mit "Wer braucht schon FileVault" und das aus Unwissenheit bzw. aus dem Versäumnis heraus sich in der Dokumentation zu informieren. Das Problem dabei ist das sich solche Aussagen nachhaltig in den Köpfen festsetzen denn sind wir mal ehrlich die Gro der Leute liest eher Threads in Foren und vertraut den Aussagen "versierter" User als sich durch die Dokumentation zu "quälen".

Ein gutes Beispiel dafür ist auch das Thema SIP denn auch hier wurde in den diversen Foren, auch hier, proklamiert das man diese am Hack tunlichst immer zu deaktivieren hat. Dieser Unsinn hat sich so nachhaltig in den Köpfen der User festgesetzt das bis heute gefühlt 99,8% der Leute mit deaktiviter SIP unterwegs sind und so wissentlich ein mächtiges Sicherheitsfeature des Systems aushebeln obwohl dies ganz und gar nicht (dauerhaft) notwendig ist.

Ich finde diesen, doch sehr laxen, Umgang mit sicherheitsrelevanten Themen den die Community "pflegt" ehrlich gesagt zunehmend bedenklich.

So nun aber back to Topic denn schließlich geht es in dem Thread ja nicht um eine Grundsatzdiskussion über Sicherheitskonzepte in Bootern und/oder Betriebssystemen sondern um die Frage wie mamids nun am elegantesten den switch von Clover zu OpenCore bewerkstelligen kann

Zitat von Download-Fritz

… mit "Secure Boot"-Unterstützung (nächstes Jahr) kann man dann auch eine volle Kette aufbauen …

Boot Guard -> UEFI Secure Boot -> OC Vault -> Apple Secure Boot -> SIP

Das ist prima, ist doch "Secure Boot" für eine UEFI-Windows Installation schon sinnvoll, leider klappt das dann nicht mit Clover. Insofern freue ich mich, dass OpenCore sich dem annimmt und sowohl Windows wie auch macOS in dieser Umgebung gemeinsam arbeiten können.

griven ... ich habe mir die Anleitung durchgelesen. Ich habe OpenCore konfiguriert während ich nebenbei Deinen Workshop auf Youtube von Anfang bis Ende angeschaut habe. Da ich öfter mal zurückgespult habe und meine Eingaben getätigt habe, kam ich am Ende auf gut drei Stunden. Ich habe mir die Anleitung durchgelesen, aber ich habe noch nicht alles verstanden. Im Gegensatz zu manch anderen schreie ich hier nicht rum: "Mach mir mal eine EFI!" Sondern ich bin mit Interesse bei der Sache. Mittlerweile kompiliere ich mir die Sachen selbst. Habe mich informiert, warum eine Debug-Version größer ist als eine Release-Version. Schaue mir die Repositories auf github an. Ich stehe auf dem Standpunkt: "Was man sich selbst erarbeitet hat, dass kann einem keiner mehr nehmen!" Das gilt sowohl im privaten Bereich als auch auf der Arbeit. Ich habe im Internet recherchiert und bin dann bei Insanlelymac auf diesen Komentar gestossen.

https://www.insanelymac.com/fo…ndComment&comment=2677706

Tut mir leid, dass ich da etwas verwechselt habe. Ich verstehe das jetzt so, dass man nicht so einfach die EFI kopieren kann, sondern man muss mit dem script "create_vault.sh" erst eine "vault.plist" anlegen. Richtig?

Hallo mamids, wenn deine SSD von Samsung ist.... einfach mal die Firmware neu flashen, (wenn möglich)

da gibt es ein Tool dazu, läuft unter Windows,

Tante Google findet das schon

Samsung SSD Magician Software

Ja bluebyte im großen und ganzen bedeutet es genau das wobei Du den EFI Ordner schon kopieren kannst solange eben die Signatur und die vault.plist mit kopiert werden und im Prozess keine Files verändert werden.

Das create_vault.sh Script erzeugt eine vault.plist Datei in der die SHA-256 hashes aller Files enthalten sind die zu Deiner OC Installation gehören (OC Files, Configs, Extensions usw.) und signiert diese Datei im Anschluss mit RSA Zertifikat und "implantiert" den entsprechenden Key in die OpenCore.efi. Wenn die Optionen RequireVault und RequireSignature in der config aktiviert sind liest OpenCore beim start die vault.plist, natürlich nicht ohne im Vorfeld die Signatur auf Gültigkeit zu prüfen, und gleicht dann die in der Vault.plist abgelegten Hashes mit den Hashes der Dateien auf der EFI ab. Sollte sich vom Zeitpunkt der Erstellung des Zertifikats und der Vault.plist etwas an den Dateien oder an der Vault.plist verändert haben egal ob wissentlich durch den User oder unwissentlich durch Schadprogramme verweigert OpenCore den Systemstart mit einem entsprechenden Hinweis. Aus dem Verhalten ergibt sich natürlich das es nur dann sinnvoll ist beide Komponenten wirklich zu aktivieren wenn man die konfiguration abgeschlossen hat denn ansonsten würde jede Änderung an der config.plist oder irgendeiner anderen Datei im OC Kontext bedingen das die Vault.plist neu aufgebaut und signiert werden muss.

In wie weit in dem Zug die OpenCore.efi ebenfalls gegen eine Version getauscht werden muss die noch keinen Public Key enthält kann ich adhoc nicht beantworten würde aber anhand der Dokumentation davon ausgehen das dem so ist weil der Suchbegriff den das Script verwendet um den Key in den EFI Treiber zu schreiben nicht mehr vorhanden ist. mhaeuser liege ich da mit meiner Annahme richtig?

Edit: ich lag falsch mit der Annahme der PublicKey bleibt der gleiche sprich die OpenCore.efi muss nicht erneut angepackt werden wohl aber muss die Vault.plist nach jeder Änderung an config oder Files neu erstellt und signiert werden. Danke mhaeuser fürs klarstellen weiter unten

Richtig spannend wird das Thema indes auch erst wenn die SecureBoot implementation komplett ist denn aktuell greift das ganze ja erst wenn OC schon gestartet ist alles was davor passiert (kompromitierte bootX64.efi zum Beispiel) würde so erstmal weitestgehend unbemerkt durchgehen da aktuell noch eine Instanz fehlt die schon auf dieser Ebene prüft.

Ich hoffe, ich mach das jetzt richtig mit dem vault ...griven ... vielen herzlichen Dank, dass Du mich auf den Weg gebracht hast. Jetzt habe ich es kapiert.

griven nein, der PK bleibt ja gleich... das Schlüsselpaar soll ja nicht jedes Mal gelöscht werden

mamids ... egal ob Sandisk oder Samsung. Ich habe WD, Sandisk und Samsung.

Das Tool für Sandisk gibt es im Netz.

Bootcamp lässt sich schon mal über OpenCore starten.

HighSierra startet. Bricht aber ab. Ohne Error. Fehlermeldung beim Laden von "AtherosE2200Ethernet.kext"

Catalina reagiert gar nicht.

Bei HighSierra "Normalize Headers"? Laut Video von griven soll das ja so.

mamids ... hatte das vorhin auch bei CHIP gefunden

https://www.chip.de/downloads/…D-Dashboard_83057942.html

Vielleicht findest Du auch was bei Western Digital. Die sind doch mit Sandisk fusioniert.

mamids ... war auch schon mal für ein Jahr ohne Windows. Linux und MacOSX 10.4.9 Tiger.

Vorhin bekam ich einen Schreck. Wollte über OpenCore mein HighSierra starten. Wollte nicht.

Bin dann ins BIOS. Oh Schreck. SSD nicht mehr vorhanden. Mußte sofort an Dich denken.

Nach einem Rechnerneustart war sie aber wieder da.

Halo zusammen,

ich lese hier gerade fleißig mit und bin auch selbst schon ein bisschen im Umbruch von Clover zu Open Core, habe aber mit dem letzteren noch etwas Probleme.

bluebyte Vielen Dank für Deine Beiträge in diesem Thema, dadurch kenn nun auch ich jetzt die Bedeutung der "Require Signatur + Require Vault". Hab jetzt auch eine Signatur in meinem EFI-Ordner und es läuft soweit alles. griven Du hast es auf dem Punkt getroffen, auch ich war wegen "hören/sagen" bis vor kurzem der Meinung das die auf "NO" stehen müssen, aber ohne es wirklich zu hinterfragen. Ich würde behaupten jeder der nicht allzu komplizierte Hardware hat, sollte mit diesem Thread OpenCore zum laufen bekommen.

Also noch ein riesiges DANKESCHÖN an dieses Großartige FORUM und allen die daran teil haben.

mamids manchmal setzt ein Nvram Reset das BIOS gleich mit zurück. Dann brauchst du den RTC fix. Schau im BIOS mal nach, ob deine Einstellungen noch stimmen. Festplatten Controller -> AHCI etc. Lies dazu bitte die beiden Links ich weiter oben geteilt habe

Für alle die mit vault arbeiten ist es manchmal nervig die Kommandos in der Shell einzutippen oder sich mit den Pfeiltasten durch die history zu quälen. Viele mögen es wissen, manche auch nicht, wie man sich das ganze vereinfachen kann.

Im Terminal den Befehl "history" (ohne die Quotes, Gänsefüßchen) eingeben.

Es erscheint eine Tabelle mit Nummern und den gespeicherten Befehlen.

Jetzt braucht man nur noch ein Ausrufezeichen mit der Nummer aus der History eingeben und der Befehl wird ausgeführt.

Brauch mir so nur !503 und !504 merken.

Habe mich die ganzen Tage mit OC beschäftigt. Video von griven vorwärts und rückwärts. Die Anleitung gelesen. Mir bei Insanelymac einige Sachen durchgelesen. Bei Acidanthera auf guitarhub Notizen gemacht. Die config.plist rauf und runter editiert - fast schon ohne hinzuschauen.

Habe heute gefrustet das Handtuch geworfen. Ich schicke mal die confi.plist hoch. Den Rest braucht man ja nicht, da OC nur das lädt was in der config.plist gewählt ist.

Bei der SSDT wusste ich nicht wie das mit OSY-Weiche funktioniert.

Zitat von bluebyte

Bei der SSDT wusste ich nicht wie das mit OSY-Weiche funktioniert.

Gibt viele Wege. Hier ein ganz eleganter:

1. Zuerst eine "OSDW"-Methode erstellen und oben in der SSDT platzieren (oder ausserhalb in einer anderen, dann verlinken):

Was passiert hier? OSDW wird abgearbeitet, wenn "Darwin" erkannt, dann bekommt "OSDW" den Wert "1", ansonsten "0".

Wieso "OSDW"? Ist in der Apple ACPI zu finden und wird dort "zweiteilig" ermittelt:

… das brauchen wir nicht, ist zu umständlich. Eine generelle Abfrage der Systeme ist schon in der DSDT enthalten.

Warum benutze ich "OSDW" und schreibe nicht "(_OSI ("Darwin"))" direkt rein? Weil ich's elegant haben will. Etliche modifizierte Apple SSDT haben auch abfragen nach "OSDW" drin und diese werden dann auch beantwortet.

Jetzt also die Abfrage, ob ein bestimmtes Device bei einem bestimmten System genutzt werden soll oder nicht:

Hier finden wir die Methode _STA (Status) und legen fest, dass das vorhandene Device "TATA", welches wir mit "Scope" weitergehend beschreiben, je nach "OSDW"-Wert ein "0x0F" (aktiv) oder "Zero" (deaktiviert) bekommt. Im Anschluss dann eine _DSM-Methode, um in das Device weitere Eigenschaften zu injecten.

Natürlich kann ich mir "OSDW" auch als Methode sparen, und schreibe gleich:

julian91 ich bin gerade auch am versuchen von Clover auf OpenCore zu wechseln. Aber spätestens bei der Sample.plist hänge ich total.

Kann ich das einfach aus meiner Config.plist von Clover übernehmen?

beim ersten Teststart häng ich hier.

Tirola steht doch auf dem Bildschirm was fehlt. Der Treiber, den Du bei item 0 angegeben hast. Ansonsten lies die Anleitung und schau Dir das Video von griven auf Youtube an.

Die sample.plist musst Du natürlich noch in config.plsit umbenennen und entsprechend mit einem Plist-Editor, mit dem XCode-Editor oder einem vergleichbaren JSON-Editor anpassen. Freaks nehmen auch den Textedit oder Nano.