Posts by griven

  • MACOS 14 SONOMA BETA

    Wichtig ist auch das nach jeder Anwendung des Patchers direkt ein Reboot erfolgt und zwar noch bevor man irgendwas anderes im oder am System macht. Der Patcher erstellt nach erfolgreichem einbringen der Patches und neu erstellen der KernelCollection einen neuen Systemsnapshot und markiert diesen als aktiven Snapshot so, dass das System fortan davon bootet. Die gezeigte Meldung lässt darauf schließen das der Patcher zwar erfolgreich ausgeführt wurde der dann notwendige Reboot aber unterdrückt wurde und zum Beispiel der Versuch unternommen wurde ein Update zu installieren. Also immer dran denken nach Anwendung des Patchers immer direkt einen Reboot fahren.

  • MACOS 14 SONOMA BETA

    Nur um Missverständnissen vorzubeugen RestrictEvents.kext und das BootArg haben keinen Einfluss darauf welche Form von Update (Delta oder Full) angeboten wird die Kombi sorgt "nur" dafür das überhaupt was angeboten wird. Ähnlich wie die boot.efi beim Systemstart prüft auch der SoftwareUpdate Dienst zur Laufzeit ob der Rechner berechtigt ist bestimmte Updates zu empfangen (hier wird unter anderem die BoardID als Referenz benutzt) und bietet diese im Erfolgsfall dann über Systemsteuerung -> Allgemein -> Softwareupdate zur Installation an. Für den Fall das diese Prüfung fehlschlägt (unpassendes SMBIOS, fehlendes oder falsch gesetztes SecureBootModel, Fehlender T2 bei SMBIOS Versionen die einen haben sollten) werden keine Updates angeboten. RestrictEvents springt hier in die Bresche indem es (zukünftig idealerweise nur dem SoftwareUpdate Dienst) dem System vorgaukelt innerhalb einer virtuellen Maschine zu laufen mit dem Ergebnis das viele der sonst üblichen Checks übersprungen werden und man eben unter anderem trotzdem SoftwareUpdates angeboten bekommt.


    Ob man letztlich ein Delta Update oder die komplette Version bekommt hängt dann unter anderem auch von Zustand des Bootsnapshots ab. Ist das Siegel des Snapshots gebrochen zum Beispiel in Folge von OCLP Anwendung dann wird immer das komplette Paket geliefert und anstelle eines "einfachen" Updates eine Recovery auf die aktuelle Version durchgeführt. Das von Arkturus beschriebene Vorgehen ist nichts anderes als ein Rollback des APFS Snapshots auf die Version vor dem Patch (der dann natürlich auch ein intaktes Siegel besitzt) ob man das will nur um das Delta Update zu bekommen muss jeder selbst entscheiden...

  • MACOS 14 SONOMA BETA

    Phoenix85 wurde hier schon mehrfach geschrieben wie es geht hier nochmal kurz:


    1. RestrictEvents.kext hinzufügen

    2. BootArg revpatch=sbvmm hinzufügen


    Damit werden die OTA Updates trotz der vorgenommenen Änderungen für den WLAN Patch wieder angezeigt.

  • MACOS 14 SONOMA BETA

    Das hängt eher damit zusammen das der Spoof die Kabylake Framebuffer verwendet und die wiederum sind Metal3 kompatibel ;)


    Rein von der Generation her gehören die iGPU's der Skylake und die der Kabylake Prozessoren zur gleichen Generation (9. Generation) wobei die KabyLake gegenüber den Skylake iGPU's um einige Funktionen im Bereich der Hardware De/Encodierung (4K HVEC und DRM Funktionen) sowie den Support von Thunderbolt 3 erweitert wurden abgesehen davon sind beide aber identisch.

  • Anleitung für Broadcom-WLAN-Patch unter macOS Sonoma

    OCAT zeigt die schon an allerdings nur dann wenn eine OC Version verwendet wird die auch halbwegs aktuell ist...

    Der Phoenix85 ist da mit OC 0.8.8 unterwegs zumindest wenn man seinem Screenshot vertrauen kann und das kann dann ja irgendwie auch nicht wirklich passen...


    Phoenix85 klick mal in OCAT in der oberen Menuleiste auf Edit und wähle dann OpenCore DEV anschließend dann nochmal auf Edit und im Menu "Upgrade OpenCore and Kext" wählen. In dem Fenster das dann aufgeht klickst Du auf "Get OpenCore" und damit hast Du dann erstmal Dein OCAT auf dem aktuellen OC Stand gebracht. Jetzt kannst Du Deine config.plist in OCAT öffnen und anschließend wieder auf EDIT -> "Upgrade OpenCore and Kext" klicken und dann auf Start Sync wenn das erledigt ist hast Du auch die Möglichkeit die Strategy unter Kernel -> Block anzupassen.

  • Anleitung für Broadcom-WLAN-Patch unter macOS Sonoma

    In der Theorie kann man die Patches sogar manuell mit dem Terminal einspielen wenn man das will in der Praxis wird man aber dennoch nicht an OC vorbei kommen es sei denn man nimmt in Kauf händisch noch tiefer ins System einzugreifen...


    Das Problem an der Stelle hat fabiosun eigentlich treffend beschrieben denn Clover scheitert schon an der Stelle wo es darum geht die Voraussetzungen dafür zu schaffen das die Patches überhaupt was bringen. Damit der Zauber funktioniert muss im Vorfeld die IOSkywalkFamily.kext von Sonoma unschädlich gemacht werden damit die ältere Version von Ventura ins System eingebracht werden kann. Clover scheitert aktuell wohl noch am korrekten blocken der Extension was zu Paniken beim Systemstart führt.

  • Anleitung für Broadcom-WLAN-Patch unter macOS Sonoma

    Hast Du ;)


    Ein unsignierter Kext ist kein Problem denn der kommt an den Sicherheitsmaßnahmen vorbei ins System eben via KextInjection (Clover oder OC spielt hierbei eine untergeordnete Rolle) das alles passiert im Speicher ohne dauerhafte Veränderungen des Dateisystems. Die notwendigen Änderungen betreffen aber bei weitem nicht nur die paar Extensions sondern hier muss, wie TECHNIKVERBOT ja schon angedeutet hat, weit mehr wieder ins System gebastelt werden und das geht dann eben nicht mehr an den Sicherheitsmaßnahmen vorbei zur Laufzeit. In der Theorie sollte das Ganze natürlich auch mit Clover zu bewerkstelligen sein in der Praxis ist die Frage ob der Patcher mit Clover spielt oder anders ob die App nicht den Dienst verweigert wenn sie erkennt das das System nicht über OpenCore gestartet wurde. Ich habe das nicht ausprobiert aber wundern würde es mich ehrlich gesagt nicht wenn dem so wäre...

  • Anleitung für Broadcom-WLAN-Patch unter macOS Sonoma

    Quote from a1k0n

    Und der Part mit Somoma-BCM-Kexte.zip: IOSkywalkFamily, IO80211FamilyLegacy ist auch irgendwie nicht richtig. Das sind Kexte aus Ventura.

    Lass mal kurz nachsehen was OCLP da verwendet...



    Ach Mensch, verrückt das ja die Version aus Ventura wär hätte das gedacht (gilt im übrigen auch für die IO80211Family) ?!?


    Sorry aber wenn man schon meint man müsste Stunk machen dann bitte fundiert und korrekt recherchiert und nicht indem man Dinge selektiv und aus dem Zusammenhang gerissen zitiert und dann unqualifiziert kommentiert oder Sachen behauptet die schlicht nicht stimmen...

  • MACOS 14 SONOMA BETA

    BT ist ja auch unabhängig vom WLAN und benötigt unter Sonoma in aller Regel keine Patches...


    Das ganze betrifft ja "nur" das WLAN. Auf der anderen Seite klar die SIP abschalten ist ein gewisses Risiko aber ein, wie ich finde, kalkulierbares. Damit wirklich was am RootFS geändert werden kann muss es erstmal RW eingebunden werden und das geht unter macOS nunmal nicht ohne mithilfe des Users. Was ich damit sagen möchte? Ganz einfach wir Hackintosher sind ja in aller Regel keine einfachen, unbedarften User sondern wir sind schon Leute die IT technisch zumindest grundlegend bewandert sind und daher einigermaßen genau wissen wann sie Ihr Admin PW eingeben und wann besser nicht mit anderen Worten mit ein wenig gesundem Menschenverstand kann man unter Umständen ganz gut auf die SIP verzichten ;) Apple SecureBoot nutzen meiner Meinung nach eh die allerwenigsten so wie es eigentlich genutzt sollte dann dazu ist ja schon einiger Aufwand nötig. Allein auf das SecureBootModel kann man auch getrost und guten Gewissens verzichten...

  • MACOS 14 SONOMA BETA

    Eher nicht weil die Patches ja nach wie vor unsigned sind sprich die Binaries die der Patcher einbringt (Apps, Deamons und Frameworks) werden bei aktiver SIP schlicht und ergreifend nicht mehr geladen...