Ozmosis Patch macOS Mojave

Guten Tag zusammen

Wer nutzt denn hier noch Ozmosis und hat Zugriff auf macOS Mojave? Ich bräuchte ein Versuchskaninchen, am besten jemand der bereits DBounce benutzt hat... @derHackfan vielleicht?

Ich habe die 167X Version von Ozmosis soweit möglich überarbeitet um Kompatibilität mit Mojave herzustellen. Sollte das ganze funktionieren hätte es sehr gute Zukunftsaussichten, solange sich an macOS nichts fundamentales ändert... Kompatibilität mit neuen OS wäre durch einen einzigen Plist Eintrag herzustellen.

Naja aber soweit ist das alles nur Theorie... Leider fehlt mir aktuell eine Festplatte und die Zeit um das ganze selber zu testen

Zitat von derHackfan

Was hat du denn an den Ozmosis Files verändert

Naja, wie genau möchtest du es haben?

Kurzfassung: Ich habe teile von Ozmosis disassembled und angepasst um zu versuchen die KextInjection unter Mojave zu fixen...

Mittelfassung: Um Kexts aus der EFI zu injecten sind prinzipiell zwei Dinge notwendig:

• readBooterExtensions --> Lesen der Extensions vom devicetree
• loadExecutable --> Umgehen der SIP Beschränkungen

Die Art wie die einzelnen Befehle ausgeführt/injected werden unterscheidet sich zwischen den Bootloadern.
Wen es interessiert, bei Ozmosis sieht dies so aus:

Die AppleKernel haben sich im laufe der Versionen verändert und so verändern sich auch die Muster nachdem die im Bootloader eingebauten Kernelpatcher suchen um die Befehle zu erlauben.
Unter Clover kann man sich das ganze zB hier in der Source ansehen: https://sourceforge.net/p/clov…atform/kext_inject.c#l595
Unterschieden wird hier wieder zwischen readBooterExtensions (EXT) und loadExecutable (SIP). Clover geht an dieser stelle einen dirty Weg und patcht im readStartupExtensions Bereich und überspringt durch einen hardcode somit den eigentlich vorhergesehenen readPrelinkedExtensions Bereich für das ausführen von readBooterExtensions.
Ok, davon abgesehen sieht man in der oben verlinkten Liste sehr schön in welchen Bereichen (SIP oder EXT) Veränderungen notwendig waren um die KextInjection zu erlauben. Von 10.10 bis 10.13 veränderte sich an dem EXT procedure nichts, jedoch im SIP Bereich. Die Veränderungen waren meist marginal und cecekpawon setzte diese in einem disassemble von Ozm um, durch kleine Anpassungen der Assembler-Befehlsreferenzen und hinterlegten Hex-Werte.
An dem SIP Patch hat sich für Mojave nichts verändert, jedoch am EXT Patch. Dementsprechend kann das problem nicht wie bisher durch das verändern von einzelnen Bytes im loadExecutable-Bereich behoben werden. Praktisch niemand der in den letzten paar Jahren kleinere Ozm Patches rausgebracht hat besitzt oder hat Zugriff auf die Ozmosis Source. Ozm behandelt das ganze Thema dynamisch, angelehnt an meklort, was jedoch einige Probleme mit sich bringt wenn die Source nicht vorhanden ist und man versucht etwas zu patchen. Für 10.14 musste sich also was anderes ausgedacht werden und somit habe ich zusammen mit cecekpawon ein neues Konzept entworfen, basierend auf ceceks UEFTW Tools und vorallem dem KernextPatcher.
Dieses neue Konzept sieht in diesem ersten Versuch so aus, dass alte hardcoded Patches von cecek wieder entfernt wurden, der dynamische Kernelpatch Mechanismus von Ozmosis aber trotzdem teilweise deaktiviert wurde und der seit El Capitan nötige und von cecek entwickelte SMBIOS fix wieder in Ozmosis.efi eingefügt wurde. Die nötigen Kernelpatches werden vom Kernextpatcher übernommen, der über eine Plist, angelehnt an die in Clover hinterlegten Patches, seine Informationen bekommt. In manchen Teilen ist somit die KernelPatch Prozedur jetzt näher angelehnt an Clover, leider weniger dynamisch, aber trotzdem funktionell (siehe Clover)

Man kann das ganze jetzt natürlich noch ausführliche beschreiben, welche Mechanismen innerhalb Ozmosis konkret deaktiviert werden, wo die Unterschiede zwischen dem erzwungenen readBooterExtensions und dem ganzen über den readPrelinkedExtensions sind, aber das würde jetzt sehr einfach nur technischer werden, das wichtigste ist eigentlich gesagt... Ansonsten einfach Fragen

@derHackfan hast du aktuell ein System mit DBounce bereit? Hast du eventuell sogar schon einen Mojave stick?

Neue Ozmosis.efi:
hackintosh-forum.de/attachment/74780/

Neueste Version des Kernextpatchers:
hackintosh-forum.de/attachment/74779/

KernextPatcher.plist mit den notwendigen KernelPatches für Kext-Injection unter Mojave in Kombination mit der neuen Ozmosis.efi:
hackintosh-forum.de/attachment/74778/ (Wird auf der EFI für den Patcher abgelegt)

• EnhancedFat muss im BIOS das Filesystem ersetzen.
• Alle anderen Treiber (hackintosh-forum.de/attachment/74781/, HFSPlus, Ozmosis, KernextPatcher (...)) sollten mit DBounce von der EFI geladen werden.
• Eine Shell kann unter EFI/Boot als BootX64.efi hinterlegt werden um DBounce mit bcfg einzubinden.
• Ebenfalls muss eine Defaults.plist mit den neuesten FirmwareFeatures, FirmwareFeaturesMask, Bios Date und Bios Version in der EFI Ozm OrdnerStruktur vorhanden sein.
• Auch FakeSMC und eventuell weiter notwendiges wie USBInjectAll auf die EFI Partition. (Wie gewohnt nach Efi/Oz/Darwin/Extensions/Common)
• Ist in der defaults das UserInterface aktiviert, braucht es ein Theme in EFI/Oz

Über Feedback freue ich mich natürlich!

Edit: Release: macOS Mojave Ozmosis BETA − OZ167X-XMAX

Ich hatte die Zeit ein wenig mit Sierra zu testen. Der auf die oben angehängte Ozm Version angewandte Patch bezieht sich nicht nur auf Mojave, sondern auf die generelle Funktionsweise von Ozmosis.
Dementsprechend kann ein Test mit jeglichem Betriebsystem schonmal die allgemeine Funktionsweise überprüfen.

Und was soll ich sagen, die Anpassungen scheinen wie erhofft gewirkt zu haben. Teile der veralteten Ozmosis Patching Prozeduren werden nicht mehr angewandt und bdmesg verändert sich entsprechend.

Zudem übernimmt der Kernextpatcher wunderbar die Aufgabe den Kernel mit neuen Daten zu patchen und sobald dies getan ist springt Ozmosis wieder ein und kann erfolgreich Kexts einbringen.
Obwohl die Herangehensweise also eine neue ist, funktioniert Kext-Injection wunderbar und zuverlässig mit Kexts aus dem ROM und auch aus der EFI.
Deaktiviert man hingegen die KernelPatches des KernextPatchers und lässt Ozm somit ins Messer laufen, funktioniert auch keinerlei Kext-Injection und der Bootvorgang bleibt bei den bekannten SMC-Issues stecken.

Das ganze beweist also, dass das allgemeine Prinzip und die Idee dahinter funktionieren. Habe ich nicht eine weitere Neuerung von Mojave übersehen, würde dass heißen, dass mit dieser Ozm Version die Kext-Injection unter Mojave laufen sollte, Ozm also somit kompatibel wäre. Vielleicht könnte das ja jemand testen und eventuell sogar bestätigen...

Übrigens die Sache mit DBounce ist nur ein Vorschlag, ich habe ein ROM mit den neuen Dateien bestückt und getestet, funktioniert fabelhaft auch aus dem ROM heraus. Das ROM braucht nur genug Platz, was bei meine Z97-D3H jedoch der Fall war...

Tests sind erfolgreich abgeschlossen, mit cecekpawon alles besprochen und release vorraussichtlich noch heute.

Hier ein paar Anhänge:

Boot schon, aber keine KextInjection.

Egal ob Clover oder Ozmosis, jeder "Bootloader" muss den Kernel patchen um die eingebauten Sicherheitsvorkehrungen zu umgehen und Kexts in den Prelinked Kernel injecten zu können. Dafür haben die Loader eingebaute Patching-Mechanismen.

Die Kernel der macOS Systeme ändern sich und so ändern sich auch die nötigen patches.

Der eingebaute Patching-Mechanismus von Ozmosis hat mit Mojave nichts mehr bewirken können (aufgrund der Kernel-Veränderungen). Da er ohne den Source-Code in diesem speziellen Fall schwer zu patchen ist, haben wir uns dazu entschieden den Mechanismus zu deaktivieren und stattdessen den Kernext-Patcher den Dienst machen zu lassen. Das hat aber andererseits den Vorteil, dass ab jetzt Kernel-Veränderungen ganz easy im KernextPatcher eingetragen und somit volle Upgrade-Kompatibilität hergestellt werden kann.

Ein Platz-Problem im Rom sollte es eigentlich nicht geben, da APFS jetzt praktisch komplett wegfällt. Gleiches gilt für die meisten alten Treiber. Nötig ist nur noch der APFSDriverLoader, EnhancedFat (anstatt Filesystem), Ozmosis selber und der KernextPatcher.

Mein ElCap-Mojave kompatibles System sieht so aus:

Erstmal für euch die Finalen Dateien an die, die testen wollen:

Ozmosis-XMAX.zip mit den neuen Patches

KernextPatcher.ffs.zip inklusive eingebauter Plist für Kext-Injection von Mountain Lion --> Mojave (sowohl früheres als auch neueres lässt sich hier ganz leicht noch einbauen)

APFS.zip loader mit 5 KB (neueste Version 1.1.1)

Edit: Release: macOS Mojave Ozmosis BETA − OZ167X-XMAX

Noch eine Sache zu APFS und Ozmosis-Booteinträgen:

Ich kann hier noch kein allgemeines Urteil fällen, aber derzeit sieht es zumindest folgendermaßen aus:
Früher war ein Booteintrag unbeständig, teils bei Reboots, teils nur bei NVRam Resets ist er verschwunden --> bcfg boot add nötig.

Bootet man in die Recovery oder in Sierra oder ähnliches und wählt hier in den Systemeinstellungen als Startvolume ein installiertes Mojave aus, wird vom OS (also kein bcfg) ein Booteintrag erstellt. Nach einigen Tests siehts so aus als wäre dieser Booteintrag bestehend. Keine reboots entfernen ihn und selbst nach NVRam Resets bleibt dieser Booteintrag – bei der Nutzung des neuesten Ozmosis und des APFSDriverLoaders – bestehen.

Bevor ich das mir gleich anschau, führ mal bitte drivers -b in der shell aus und schick den output. Hast du mal versucht wie beschrieben einen Booteintrag zu erstellen indem du über einen funktionierenden macOS Boot das Startvolume auswählst?

Kann gerade auf den ersten Blick kein Problem mit dem ROM feststellen, ich muss nur sagen, dass da gefühlt einiges unbenutztes drinnen liegt (Disabler, PartitionDXE, Extfs etc.)

Sieht eigentlich soweit gut aus... Wenn du ins BIOS gehst und dort zB auf die Auswahl einen Flash-files gehst, müsstest du eigentlich auch auf APFS Platten navigieren können. Das würde schonmal zeigen, dass APFS geladen wird...

Ist aktuell eine Platte mit Mojave oder HS verbunden? Hast du die Startvolume-Auswahl mal probiert?