Posts by DerBeste

Quote from mhaeuser

DerBeste Das ist jetzt wirklich nicht böse gemeint, aber probiere doch, die Sache ordentlich zu lernen. LLMs sind nicht auf dem Level, realistische Treiber zu entwickeln. Wenn ein erfahrener Entwickler alles vorkaut, kommt vielleicht wenigstens etwas raus, aber so nicht. Ich mache gerade Compilerentwicklung - deutlich angenehmer als Treiberentwicklung - und nichtmal dort sind die LLMs eine große Hilfe, wenn es nicht gerade um Boilerplate oder sehr isolierte Bugs geht.

Außerdem ist so der Lerneffekt fast 0. Deine Posts widersprechen sich immer wieder und dir fällt es entweder nicht auf oder es ist dir egal (wäre schade). Den allgemein bekannten Fakten wie der FW-Geschichte von schrup21 widersprechen sie ebenfalls. Erst gibt es einen halbfertigen Prototypen, der lädt, dann auf einmal können DriverKit-Treiber gar nicht geladen werden, dann geht es auf einmal doch wieder. Ich hoffe, das fällt nicht nur mir auf.

Es gibt kompetente Netzwerkentwickler wie Mieze in der Community und es täte allen gut, eher auf sie als auf halluzinierende KIs zu hören. Soll jeder sein Lieblingsspielzeug nutzen, aber meine Studiokopfhörer machen mich auch nicht zum Spezialisten für Mix&Master…

Hallo mhaeuser,

danke für deine offenen Worte. Ich nehme das "nicht böse gemeint" mal so an, hier aber Klartext von meiner Seite:

LLMs & Technik: Ich nutze KI als Werkzeug für Boilerplate und Ideen, nicht als Ersatz für meinen Kopf. Dass KI bei Treibern halluziniert, ist mir absolut bewusst; das Debugging und die Logik liegen bei mir.

Widersprüche: Beim Reverse Engineering und Prototyping geht es oft einen Schritt vor und zwei oder drei zurück. Das kenne ich aus meiner jahrzehntelangen Tätigkeit als Konstrukteur nur zu gut. Wer Fehler nicht wagt und öffentlich macht, macht auch keinen Fortschritt.

Experten & "Geht nicht": Ich habe großen Respekt vor Mieze & Co. Mein Projekt ist ein paralleler Versuch, kein Angriff. Dass Dinge als "unmöglich" gelten, war damals beim AMD-Kernel auch hier und in anderen deutschen Foren ein tägliches Gerede, und genau das ist mein Antrieb gewesen.

Zum Thema Kritik: Da ich meinen Source Code bisher noch gar nicht veröffentlicht habe, ist deine vernichtende Kritik für mich faktisch nicht nachvollziehbar. Es wirkt eher wie ein Ausdruck von Missgunst als eine fachliche Einschätzung. Hättest du den Code im Ganzen gesehen und dann deine konstruktive Kritik geäußert, um die Entwicklung womöglich voranzutreiben, wäre das eine Hilfe für die Community gewesen. Aber so, ohne jede Basis, ist es das auf keinen Fall.

Ich nehme das exakt so für mich auf und beende die Diskussion auf diesem Portal hiermit.

Beste Grüße!

Hier ist das vollautomatisierte Shell-Skript für Linux.

Dieses Skript führt den gesamten Prozess (Abhängigkeiten installieren, Nexmon klonen, Umgebung einrichten, Chip auswählen, Dump durchführen) automatisch durch.

Anleitung:

Kopiere die Datei extract_firmware_linux.sh auf deinen Linux-Rechner (zB. per USB-Stick).

Mache sie ausführbar: chmod +x extract_firmware_linux.sh

Führe sie als Root aus: sudo ./extract_firmware_linux.sh

Das Skript fragt dich interaktiv, welchen Chip du auslesen möchtest und wie dein WLAN-Interface heißt, und erledigt den Rest für dich.

Quote from karacho

DerBeste Die Firmware habe ich noch nirgends gefunden. Ich habe so eine PCIe Karte im Rechner. Ist es nicht möglich die Firmware auszulesen und als .bin zu speichern?

Quote from Azteca

Würde gerne die Sachen liefern, jedoch hab keine Ahnung wie man das aus der Karte kopiert.

Quote from schrup21

Es gibt keine Firmware für BCM4360.

Diese Module werden in Linux mit der SMAC Firmware betankt.

https://wireless.docs.kernel.o…rs/drivers/brcm80211.html

Code

1. /lib/firmware/brcm/bcm43xx-0.fw

Apple verwendet eine eigene, proprietäre Firmware, die ist in AirPort_BrcmNIC enthalten (auch die FW für die BCM943602 und BCM94350 ist da integriert).

Hier eine Anleitung wie ihr die Firmware-ROM eines Broadcom-WLAN-Chips mit Nexmon extrahiert

Beispielchip: BCM43602

Ziel: Erzeugung einer originalen "rom.bin" direkt aus dem WLAN-Chip

1. Voraussetzungen

Bevor ihr beginnt, müssen alle folgenden Bedingungen erfüllt sein:

- Betriebssystem: Linux (Ubuntu wird empfohlen)

- Rechte: Root-Zugriff (`sudo`)

- Hardware: Broadcom-WLAN-Chip, der von Nexmon unterstützt wird (z. B. BCM43602)

- Systemstatus: Der WLAN-Chip wird vom System korrekt erkannt

Ohne diese Voraussetzungen ist der Vorgang nicht erfolgreich durchführbar.

2. System vorbereiten

Öffne ein Terminal und aktualisiere dein System:

bash

sudo apt update

sudo apt upgrade -y

Installiere anschließend alle benötigten Werkzeuge:

bash

sudo apt install -y git build-essential make gcc bc python3

Diese Pakete sind notwendig, um Nexmon zu kompilieren und Patches zu bauen.

3. Nexmon herunterladen

Wechsle in dein Home-Verzeichnis:

bash

cd ~

Klone das offizielle Nexmon-Repository:

bash

git clone https://github.com/seemoo-lab/nexmon.git

Wechsle in das Nexmon-Verzeichnis:

bash

cd nexmon

4. Nexmon-Umgebung einrichten

Initialisiere die Nexmon-Umgebung:

bash

source setup_env.sh

Wichtig:

Dieser Schritt setzt notwendige Umgebungsvariablen. Ohne ihn schlagen alle weiteren Befehle fehl.

5. Passenden Chip auswählen

Navigiere in das Patch-Verzeichnis:

bash

cd patches

Suche den Ordner deines Chips, z. B.:

bash

bcm43602

Wechsle in das Nexmon-Unterverzeichnis des Chips:

bash

cd bcm43602/nexmon

6. ROM-Dump-Patch bauen

Baue das ROM-Dump-Patch:

bash

make dump-rom

Dabei wird ein kleines Patch-Programm erzeugt, das später den ROM-Inhalt des WLAN-Chips ausliest.

7. WLAN-Interface vorbereiten

Deaktiviere das WLAN-Interface, um Konflikte zu vermeiden:

bash

sudo ifconfig wlan0 down

Falls dein Interface anders heißt (zB. "wlp2s0"), passe den Namen entsprechend an.

8. ROM-Dump ausführen

Starte nun den ROM-Dump:

bash

sudo make run-dump-rom

Was dabei passiert:

- Der WLAN-Chip wird initialisiert

- Der ROM-Inhalt wird in den RAM gespiegelt

- Die Daten werden ausgelesen

- Der Dump wird in eine Datei geschrieben

Der Vorgang dauert nur wenige Sekunden.

9. Ergebnis prüfen

Nach erfolgreichem Abschluss findest du eine Datei wie:

bash

rom.bin

oder

bash

fw_rom.bin

Prüfe die Dateigröße:

bash

ls -lh rom.bin

Erwartet:

- Größe zwischen 500 KB und 1 MB

Fehlerfall:

- Datei ist leer oder 0 Byte → Dump fehlgeschlagen

10. ROM-Datei sichern

Kopiere die Datei auf den USB-Stick

bash

cp rom.bin ~/firmware_bcm43602_rom.bin

Diese Datei ist nun die Grundlage für die Analyse- oder Patch-Arbeiten.

11. ROM-Datei analysieren (optional)

Zur Analyse der Firmware kannst du "binwalk" verwenden:

bash

sudo apt install -y binwalk

binwalk firmware_bcm43602_rom.bin

Damit lassen sich Code-Bereiche und Strukturen identifizieren – insbesondere relevant für Reverse Engineering.

12. Rechtliche Hinweise

- Die Firmware ist proprietär

- Nutzung ausschließlich zu Forschungs- und privaten Zwecken

- Keine öffentliche Weiterverbreitung !

- Broadcom- und ggf. Apple-Lizenzen gelten weiterhin

Kurzfassung

- Linux vorbereiten

- Nexmon herunterladen und initialisieren

- Broadcom-Chip auswählen

- ROM-Dump-Patch bauen

- ROM aus dem WLAN-Chip auslesen

- "rom.bin" sichern und optional analysieren

Ergebnis:

Eine originale WLAN-Firmware direkt aus der Hardware.

Edit:

Lasst euch aber Zeit. Ich arbeite derzeit an einem anderen Projekt und kann mich erst dann darum kümmern, wenn ich das neue Projekt abgeschlossen habe.

Quote from Azteca

Und wie sieht es aus mit BCM94360CS2?

Ich benötige die Data Sheet und die passende Firmware, dann wäre eine Umsetzung unter Umständen möglich.

Quote from karacho

Super

Jedoch sehe ich keine Firmware für die BCM4360.

Ich war beim Verfassen meines Textes etwas voreilig, aber das ist zunächst nur ein kleines Problem. Solange ich das entsprechende Data Sheet und die Firmware im Netz finden kann, lässt sich die Implementierung problemlos durchführen, da das Grundgerüst bereits steht.

Vielen Dank für den Hinweis.

Hallo zusammen,

versprochen ist versprochen, und dieses Versprechen halte ich nun ein.

Hier ein kurzes und einfaches Update zu meinem Projekt. Den neuen DriverKit-Treiber für diverse Broadcom-WLAN-Chips konnte ich erfolgreich bauen, linken und signieren.

Der Treiber entspricht vollständig DriverKit Version 24.5 und läuft nur im User-Space (das war ein harter Kampf). Kernel Extensions werden daher nicht mehr benötigt. Das Build-System kümmert sich automatisch um die Einbindung der passenden Firmware. Unterstützt werden aktuell 23 verschiedene Broadcom-Chipsätze, zum Beispiel BCM4350, BCM4360 und BCM43602 etc. Die grundlegenden Hardware-Funktionen sind umgesetzt. Dazu gehören das MMIO-Mapping, die Verwaltung von DMA-Puffern und das Zurücksetzen der Hardware-Kerne etc. Der komplette Build-Prozess läuft automatisch ab und beinhaltet auch das Code-Signing sowie die anschließende Prüfung.

Der Treiber ist damit bereit für die erste Installation und für erste Tests auf meiner Hardware. Nun muss die passende Hardware her.

Ein paar Bilder befinden sich im Anhang

Zum Projekt BCMWLANCompanion werde ich den Beitrag vorerst zurückhalten und zu einem späteren Zeitpunkt veröffentlichen. Eine entsprechende Mitteilung folgt.

Quote from mhaeuser

MacGrummel Selbstverständlich können neue Treiber geladen werden. WiFi ist nur keine unterstützte Geräteklasse - jeder Mac hat bereits WiFi, also wird in die Richtung keine Arbeit gesteckt. Inwieweit es “unmöglich” ist im Vergleich zu den alten Ethernet-Emulatoren, weiß ich nicht - wenn es an mach_types.h scheitert, muss man wohl auf das nächste tolle LLM warten.

Okay, lass mich eines klarstellen, weil die Diskussion sich im Moment etwas im Kreis dreht: Das Problem ist nicht einfach nur an „mach/mach_types.h“ das ist lediglich ein Symptom, nicht die Ursache.

Als Entwickler solltest du das leicht reproduzieren können. Es geht nicht um eine einzelne Datei, sondern darum, wie DriverKit aufgebaut ist.

Im Grunde ist es so: DriverKit-Treiber dürfen nur die Header aus DriverKit und USBDriverKit verwenden, die dafür gedacht sind. Aber sobald du anfängst, echte Treiberlogik zu schreiben, wie zum Beispiel für USB, PCI oder Netzwerk nahe Funktionalität dann stößt du zwangsläufig auf Abhängigkeiten, die früher zulässige Kernel-APIs verwendet haben aber heute vollständig isoliert sind.

Das beinhaltet unter anderem:

* mach_*-Typen etc.

* IOUSB/IOService-Strukturen, die in DriverKit nicht übernommen wurden

* Synchronisations- und Memory-Primitive, für die es keinen Ersatz gibt

* Includes, die Xcode selbst über Standard-C++ Includes einzieht, auf die man selbst keinen Einfluss hat

Selbst wenn du jede direkte Referenz sauber entfernst, kommst du nicht weiter: Du ersetzt etwas Verbotenes, brauchst dafür etwas anderes, das auch nicht erlaubt ist, und dann geht der Build woanders schief.

Das ist kein Anfängerfehler und kein „falscher Include“.

Das ist ein unauflösbarer Zyklus. Du kannst es dir so vorstellen: Eine Katze, die ihren eigenen Schwanz hinterher jagt und egal, wie schnell sie hinterher läuft, wird sie niemals zum Ziel gelangen, weil das System bewusst so konstruiert wurde.

Ein weiterer Punkt, der gern übersehen wird:

Ein sauberer Build außerhalb von Xcode, etwa über ein Makefile oder CMake, ist faktisch unmöglich, da der Compiler während der Prüfung der erlaubten Includes scheitert, bevor man überhaupt funktionalen Code erreicht. Das ist kein Zufall, sondern Toolchain-Design.

Zu deiner Aussage „WiFi ist keine unterstützte Geräteklasse“: Genau das ist der Punkt. DriverKit suggeriert Offenheit, bietet sie aber real nur dort, wo Apple ohnehin vollständige Kontrolle besitzt. Dass alle Macs bereits WLAN haben, ist kein technisches Argument, sondern ein strategisches und erklärt exakt, warum diese Klassen bewusst ausgespart wurden.

Kurz gesagt: Ja, man kann formal neue DriverKit-Treiber laden. Aber in der Praxis sind sie so eingeschränkt, dass echte Hardware-Unterstützung nicht möglich ist.

Aber wenn du das nicht glauben magst, dann kannst du es gern selbst probieren:

* Einen eigenen USB- oder Netzwerk-Treiber schreiben

* Ohne private Frameworks

* Ohne alte Kext-Header

* Nur mit DriverKit

Das Ergebnis ist reproduzierbar und unabhängig vom Skill-Level. Das ist kein Versagen einzelner Entwickler.

Das System ist von Anfang an so gebaut, dass man nicht gewinnen kann.

Ach, sorry, mit Hilfe der KI verfasst

Ich hab's erst nach Wochen festgestellt, das meine ganze Tipperei für die Katz war. Nicht, weil ich doof bin, sondern weil Apple sein System wie eine Festung abgeriegelt hat, gegen die man einfach keine Chance hat.

Ich dachte erst, es gibt eine Möglichkeit das zu umgehen, aber Pustekuchen. Ich hätte besser auf die anderen gehört, die meinten: Vergiss DriverKit, besonders für WLAN, das ist gelaufen.

Tja, selbst auf die Nase fallen ist die beste Lehre. Apple hat das System so gebaut, dass wir alle verlieren.

DriverKit ist keine Lösung, sondern eine Fessel.

Apple will die Treiber nur noch selbst schreiben. Alles, was nicht ins Konzept passt, fliegt raus.

* USB-WLAN? Tot.

* Eigene Hardware? Egal.

* Broadcom? Pustekuchen.

* Monate Arbeit? Apple lacht.

Fakt ist: Ich durfte gar nicht gewinnen. Und das gilt auch für viele, die viel mehr draufhaben als ich.

Das Schlimmste: Apple redet von Sicherheit und Stabilität. Schön und gut, aber das ist doch alles Quatsch!. Ja, Mieze, ich gebe dir nun 100 % Recht, alles Bullshit!

Es geht um Kontrolle, um mehr Kohle und darum, andere klein zu halten. Wer nicht Apple ist, ist nicht willkommen.

Ich war so blöd zu glauben, Apple weiß, was es tut, und will uns nicht verarschen.

Falsch gedacht.

Das Ganze ist Absicht.

Und das betrifft nicht nur mich, sondern alle:

* Hackintosh-User

* Hardware-Bastler

* Open-Source-Leute

* Entwickler, die einfach nur schaffen wollen

* und alle macOS-Nutzer, die für billige Hardware tief in die Tasche greifen müssen, weil Apple abkassieren will

Apple hat vergessen, warum so viele User macOS mochten: Weil man früher noch selbst was machen konnte und Treiber anpassen. Diese Zeiten sind vorbei.

Die harte Realität ist: Ich bin nicht gescheitert. Der Treiber ist komplett fertig, aber Apple hat den Riegel vorgeschoben.

Wenn du alles DriverKit-tauglich machst, landest du am Ende bei bestimmten Funktionen und Headern, die es in normalen macOS- oder Kernel-Treibern (kext) gab – wie zum Beispiel mach/mach_types.h oder spezielle USBHost-Header. Die sind aber in DriverKit nicht mehr gültig. Das Bauen klappt dann einfach nicht mehr.

DriverKit-Treiber dürfen nur die DriverKit- und USBDriverKit-Header nehmen, die Apple erlaubt. Aber Xcode zwingt dich indirekt dazu, trotzdem verbotene Includes zu benutzen, weil Xcode halt manchmal komische Sachen macht, auf die man keinen Einfluss hat. Ein sauberer Build über ein Makefile ist darum unmöglich: Der Compiler checkt die verbotenen Dateien nicht und gibt Fehlermeldung aus, weil DriverKit zum Beispiel keinen Zugriff auf mach/mach_types.h hat.

Kurz gesagt: Apple führt dich absichtlich in eine ausweglose Situation, in der bestimmte Sachen einfach nicht gehen und der Build-Prozess unmöglich ist.

Und das fühlt sich nicht wie ein technisches Problem an, sondern wie ein fetter Betrug.

Wenn Apple meint, sie können jedes Jahr ein neues System raushauen und alle rennen hinterher, dann irren sie sich.

Viele werden gehen, womöglich zu Linux, und zu anderen offenen Systemen, wo man nicht erst fragen muss.

Ich hab's kapiert, aber es ist ein mieses Gefühl.

Nicht, weil ich verloren habe, sondern weil das Spiel von Anfang an beschissen war.

Und ja, der Text wurde teilweise mit einer KI verfasst!!

Quote from apfelnico

Hab zwar keine Ahnung welches Problem gelöst wurde, habe aber große Hochachtung vor der Programmierung einer signierten DEXT. Also modern wie es sein soll. Von so etwas habe ich in unserem Umfeld kein zweites Mal gehört. Meinen Glückwunsch!

Hi Apfelnico,

Die folgenden Ausführungen basieren auf umfangreichen Eigenentwicklungen und praktischen Erfahrungen aus mehrwöchiger Arbeit mit macOS-Treibern. Angesichts der spärlichen und oft unzureichenden offiziellen Veröffentlichungen seitens Apple musste ich viele der hier dargestellten Erkenntnisse durch ausgiebiges Experimentieren und intensives Testen gewinnen.

Apple liefert nach meinem Kenntnisstand nur minimale Dokumentation zu den neuen DEXT-Technologien und verschweigt bewusst wichtige Details, was die Entwicklung erheblich erschwert.

Hier eine Gesamtübersicht: KEXT vs. DEXT und die Zukunft von Hackintosh

Die Entwicklung von Treibern unter macOS befindet sich in einem tiefgreifenden Wandel. Apple verfolgt die klare Strategie, die traditionellen Kernel Extensions (KEXT) vollständig abzulösen und durch moderne Driver Extensions (DEXT) zu ersetzen. Dieser Wandel hat erhebliche Auswirkungen auf alle Entwickler, insbesondere auf Community- und Hobby-Programmierer.

1. Der technische Wandel: KEXT zu DEXT

1.1 Kernel Extensions (KEXT) - Die alte Architektur

KEXTs sind Erweiterungen, die direkt im Kernel von macOS ausgeführt werden. Diese Architektur bietet zwar volle Kontrolle und schnellen Hardwarezugriff, bringt aber erhebliche Nachteile mit sich:

• Direkter Zugriff auf Kernel-Ressourcen
• Hohe Anfälligkeit für Systemabstürze (Kernel Panics)
• Manuelle Nutzerfreigabe seit macOS High Sierra
• Erhöhte Systemanfälligkeit durch fehlerhafte Module

KEXTs gelten heute offiziell als veraltet und werden von Apple langfristig nicht mehr unterstützt.

1.2 Driver Extensions (DEXT) - Die moderne Lösung

Driver Extensions sind Teil des System Extension Frameworks und laufen vollständig im User Space. Sie sind sicherer, stabiler und moderner:

• Keine Kernel-Ausführung → deutlich weniger Systemabstürze
• Abgesicherte, sandbox-basierte Umgebung
• Müssen in ein App-Bundle integriert werden
• Nutzung moderner, restriktiver APIs
• Abhängigkeit vom System Extension Management

DEXTs sind zwar sicherer, aber erheblich komplizierter zu entwickeln und bieten weniger Zugriffsrechte als klassische KEXTs.

2. Apples strategischer Kurs seit 2017

Eigentlich ist seit macOS High Sierra klar erkennbar, dass Apple die KEXTs schrittweise aus dem System entfernt. Die wichtigsten Meilensteine:

• 2017 – High Sierra: Einführung von User-Approved Kernel Extension Loading
• 2019 – Catalina: Start des System Extension Frameworks
• 2020 – Big Sur: Signed System Volume und Klassifizierung von KEXTs als "Legacy"
• 2021–2024: Weitere Einschränkungen und Abschaffung zahlreicher Kernel-APIs

Diese Entwicklung zeigt: Apple will KEXTs vollständig eliminieren.

3. Auswirkungen auf Entwickler und Community-Projekte

Die Umstellung auf DEXTs bringt erhebliche Einschränkungen mit sich:

• Keine direkten Kernelhooks mehr
• Stark limitierte Zugriffsmöglichkeiten auf Hardware
• Treiber müssen in Apps verpackt werden
• Nur eingeschränkt dokumentierte APIs
• Höherer Aufwand beim Debugging
• Zunehmende Abhängigkeit von signierten Entitlements

Damit werden viele etablierte Vorgehensweisen der Hackintosh-Community deutlich erschwert.

4. Das nahende Ende der Hackintosh-Ära

Mit der erwarteten finalen macOS-Generation macOS 26.x, die voraussichtlich die letzte Version mit x86_64-Unterstützung sein wird, steht der Hackintosh-Community ein tiefgreifender Einschnitt bevor.

Die zentralen Punkte:

• Apple stellt seine gesamte Produktlinie auf Apple Silicon um
• Ab macOS 26.x ist sehr wahrscheinlich Schluss mit neuen x86_64-Builds
• Ohne x86_64-Kernel existiert keine Basis mehr für Hackintosh-Installationen
• Aktuelle und zukünftige Treiberentwicklungen (DEXT) sind zunehmend auf Apple Silicon ausgelegt
• Der klassische PC-basierte Hackintosh wird mittelfristig nicht mehr realisierbar sein

Damit ist klar: Wir bewegen uns auf das tatsächliche Ende des Hackintosh-Ökosystems zu.

5. Spezielle Problematik: PCI Netzwerkkarten

Die bisherigen Netzwerk- und PCI-Treiber wie die beliebten Realtek RTL8xxx Karten werden nicht mehr von den modernen DEXT-DriverKit unterstützt. Man kann zwar versuchen, einen Kext dafür zu bauen, aber mit vielen Hürden.

Alternative zu IONetworkController / IOPCIDevice für Realtek-Ethernetkarten

In modernen macOS-Versionen ist die klassische KEXT-Architektur weitgehend abgelöst worden. Besonders Netzwerk- und PCI-Treiber betroffen:

Die moderne API IOPCI erlaubt grundlegende Geräte-Erkennung, Lesen/Schreiben in PCI-Konfiguration und Mapping von BAR-Memory, aber nicht denselben Tiefgang wie IOPCIDevice im Kernel.

Für Netzwerkkarten hat Apple das Framework NetworkDriverKit eingeführt, das IONetworkController ersetzt. Damit erhält man eine moderne Userspace-taugliche API, Unterstützung für Netzwerk-Interfaces und Queues für RX/TX.

Fazit für Realtek-Chips:

Ein vollständiger RTL8168/8111-Treiber wie früher lässt sich in DriverKit nicht mehr 1:1 umsetzen. Eine realistische Lösung besteht aus PCI-Handling in einer minimalen Kernel-Extension und Ethernet-Interface in einer DriverKit SystemExtension.

6. WLAN-Adapter unter macOS Tahoe

6.1 USB-WLAN-Adapter - höchste Erfolgschance

USB-Adapter sind aktuell die einzige realistische und dauerhaft tragfähige Basis für WLAN-Treiber unter macOS Tahoe, da sie über das User-Space-fähige IOUSBHost-Framework laufen.

Gute Chancen bestehen für:

• Realtek RTL8812AU / BU (802.11ac)
• Realtek RTL8822BU (802.11ac)
• Mediatek MT7612U (802.11ac)
• Mediatek MT7921U (WiFi 6)

6.2 PCIe-WLAN-Karten - möglich, aber extrem schwierig

PCIe-Treiber über DEXT sind theoretisch machbar, aber extrem schwierig, weil:

• DMA, Interrupts und Registerzugriffe stark eingeschränkt sind
• Apple den gesamten WLAN-Stack vollständig blockiert
• AWDL, Handoff etc. nicht nachbildbar sind
• DEXT kein direkter Ersatz für die alten Broadcom-KEXTs ist

Chancen nach Chipsätzen:

• BCM4360: niedrig-mittel (noch am ehesten machbar)
• BCM43602: niedrig (komplexere Firmware, wenig Dokumentation)
• BCM4352: niedrig (bekannte Limitierungen)

6.3 Apple-eigene WLAN-Module - praktisch ausgeschlossen

Alle Chipsätze, die Apple in Macs verbaut, sind:

• tief in das AppleIO80211-Framework integriert
• stark signiert
• vollständig proprietär
• ohne DEXT-Äquivalent
• ohne veröffentlichte APIs

Dazu gehören BCM4350, BCM4364, BCM4377, BCM4387 und alle Apple Silicon internen WiFi/BT-Module.

7. Fazit

• KEXTs waren lange das Fundament vieler Community-Treiber, verlieren aber endgültig ihre Bedeutung
• DEXTs sind die Zukunft, allerdings restriktiver, komplexer und weniger flexibel
• Apples klare Sicherheitsstrategie erschwert freie Treiberentwicklung erheblich
• Mit macOS 26.x nähert sich die Hackintosh-Ära dem Abschluss, da keine neuen x86-Builds mehr zu erwarten sind
• Für Netzwerkkarten und WLAN-Adapter bedeutet dies: nur noch sehr eingeschränkte Möglichkeiten, vor allem über USB-basierte Lösungen

Die Entwicklergemeinschaft steht vor der Herausforderung, sich an diese neuen Gegebenheiten anzupassen oder alternative Lösungen zu finden.

Problemstellung mit dem RTL802.11ac.dext Treiber unter macOS Tahoe:

Leider verliefen die Testergebnisse mit meinem RTL802.11ac.dext unter macOS Tahoe nicht erfolgreich. Während der DEXT-Treiber unter macOS Sequoia problemlos mittels des Installations-Tools installiert wird und korrekt erkannt wird, sieht die Situation unter macOS Tahoe derzeit sehr kritisch aus.

Zwar lässt sich die Installation mit dem Tool ohne Fehlermeldungen durchführen, jedoch kommt es anschließend zu keiner funktionsfähigen Initialisierung des Treibers.

Trotz ordnungsgemäßer Vorgehensweise:

Korrekter Aufbau und Einbindung des DEXT-Pakets

Vollständige Code-Signierung nach Apple-Richtlinien

Fehlerfreie Installation durch das zertifizierte Tool

Ich muss die Ursache für dieses Verhalten unbedingt identifiziert und beheben.

Edit:

So ein Ärger. Ich habe oben ausführlich erklärt, dass man für den Build das passende KDK, also das Kernel Development Kit, installieren muss. Und genau das habe ich selbst völlig übersehen. Mir ist erst jetzt wieder eingefallen, dass ich es noch nicht eingerichtet habe. Das muss ich unbedingt nachholen.

Vielen Dank für die freundlichen Worte.

Nach mehreren Tagen harter Arbeit ist es mir gelungen, den RTL802.11ac.dext-Treiber vollständig zu bauen. Das eine echte Herausforderung! Jetzt habe ich jedoch ein Problem: Der Treiber lässt sich nicht einfach nach /System/Library/DriverExtensions installieren, obwohl alle notwendigen Schritte erfolgreich durchlaufen wurden.

Ich konnte den Treiber bisher nur nach /Library/DriverExtensions übertragen. Das sollte aber eigentlich nicht so sein.

Bisher habe ich auch keinen existierenden Installer für DEXT-Treiber gefunden. Deshalb arbeite ich gerade daran, eine App zu programmieren, die die Installation in /System/Library/DriverExtensions ermöglichen soll. Ob so eine App jemals zuverlässig funktioniert, ist aber ungewiss.

Mit direkten Terminal-Befehlen ist es mir bisher nicht gelungen, den DEXT-Treiber dorthin zu installieren, und mir fällt momentan kein anderer praktikabler Weg ein.

Jeder sinnvolle Ratschlag ist willkommen.

Edit:

Alles claro,

ich habe die Antwort aus dem Netz erhalten und muss die Installation des signierten DEXT ausführen:

1. In das Terminal Fenster öffnen und wechsle in Root-Modus, damit ich alle Systemrechte habe:

bash:

2. Setze die korrekten Rechte für den Zielordner, damit macOS die DEXT akzeptiert:

bash:

3. dann kopiere den signierten DEXT-Treiber in das System-Verzeichnis:

bash:

4. installiere die DEXTs mit kmutil und erstelle den Kernel-Cache neu:

bash:

5. überprüfe, ob die DEXTs korrekt geladen wurden:

bash:

6. starte das System neu, damit die DEXTs vom Kernel geladen werden:

bash:

Wichtige Hinweise:

Sicherstellen, dass der KDK zur macOS-Version passt, sonst schlägt `kmutil` fehl.

Dext Driver muss signiert sein, sonst werden sie blockiert.

Arbeite immer als root, damit alle Berechtigungen korrekt gesetzt werden.

Verzichte auf veraltete Befehle wie `bless --bootinfo`, kmutil ersetzt diese Funktion vollständig.

Quote from schrup21

Hi, ich möchte dir zwar nahe legen, dich nicht von einzelnen abhalten zu lassen, aber natürlich respektieren wir alle deine Entscheidung.

Schade ist es aber schon.

Zur Info:

seit gestern arbeite ich am finalen Compilerprozess und drehe mich seit mehreren Stunden dabei immer wieder um zwei hartnäckige Fehler. Gelegentlich tritt zudem nur ein unerwarteter Compilerfehler auf. Dennoch bin ich überzeugt, dass ich inzwischen etwa 98 % des ersten funktionsfähigen Prototyps des Realtek RTL802.11ac Treibers erreicht habe.

Die Entwicklung ist sehr anspruchsvoll, da Apple im DriverKit Umfeld immer wieder aber auch bewußt viele Hürden hinterläßt, die es uns Hobbybastler schwer machen, stabile und funktionsfähige Treiber nach einem einheitlichen Aufbau zu erstellen. Jede einzelne Komponente muss genau den erwarteten Schnittstellen, Signaturen und Sicherheitsvorgaben entsprechen, sonst verweigert das System den Build oder die Initialisierung.

Trotz dieser komplexen Rahmenbedingungen bin ich zuversichtlich, dass der Prototyp bald vollständig kompiliert und testbereit sein wird. Jede gelöste Hürde liefert wichtige Erkenntnisse, die in die weitere Entwicklung einfliessen und es ermöglichen, zukünftig auch andere Treiberarten effizienter und zuverlässiger zu entwickeln.

Die oben genannten Gedanken mussten einfach einmal ausgesprochen werden, sonst wäre ich innerlich daran explodiert. Mit öffentlichen Äußerungen und Kritik sollte man sich daher so gut wie möglich zurückhalten, denn solche Diskussionen bekommen heute sehr schnell unnötige Dynamik. Ich möchte keine großen Worte schwingen. Erst wenn ich das Projekt mit gutem Gewissen abgeschlossen habe, kann ich eine Version zum Testen bereitstellen. Alles davor ergibt wenig Sinn und macht einen nur unnötig angreifbar, was ich vermeiden möchte. In diesem Sinne.

Quote from schrup21

BcmWLAN DriverKit (Dext) Prototype: Broadcom Wi-Fi Support for macOS Tahoe

https://www.insanelymac.com/fo…-support-for-macos-tahoe/

Hier auch noch ein paar Infos:

https://www.insanelymac.com/fo…e/16/#findComment-2844163

Edit: wurde gelöscht wie es aussieht.

Display More

IIm Moment wird es von mir keine weiteren öffentlichen Aufrufe zur Entwicklung fehlender Treiber geben. Dieses Thema habe ich vorgestern für mich abgeschlossen, nachdem ich das Grundgerüst des DriverKit-Treibers hochgeladen hatte und dafür von „Bin-hacker“ Kommentare erhielt, obwohl ich alles sehr ausführlich erklärt hatte. Ich habe deutlich geschrieben, dass es sich zunächst nur um das Grundgerüst handelt , also wenn es so besser verstehen kann die „Autobahn“, auf der später die eigentlichen „Fahrzeuge“ fahren sollten. Die vollständige Funktion, also das „fahrende Auto“, wollte ich Schritt für Schritt ergänzen und gerne auch im Team entwickeln. Trotzdem wurde das eigentliche Konzept nicht verstanden.

Künftig arbeite ich ausschließlich für mich selbst und nur für meine eigene, nicht kompatible Hardware. Das mache ich bewusst im Hintergrund, um mich nicht erneut angreifbar zu machen.

Die technische Entwicklung läuft dennoch sehr gut. Beim Realtek RTL8111, den ich eigenständig entwickle (hat nichts mit Mieze Realtek8111 zu tun), und beim Broadcom-Treiber gibt es spürbare Fortschritte. Den Realtek RTL802.11ac habe ich inzwischen zu etwa 85 Prozent fertiggestellt. Auch der DriverKit-basierte Text-Treiber lässt sich bereits erfolgreich installieren und laden. Die restlichen rund 15 Prozent sind zurzeit in Arbeit.

Veröffentlicht werden diese Projekte nicht mehr, da es keinen Sinn hat, sich unnötigen Angriffen auszusetzen oder sich die eigene Arbeit schlecht reden zu lassen.

Quote from Arkturus

Das Script habe ich nicht verwendet, sondern den Code im Terminal vom Recovery eingeben. Ich habe die NVMe nun in der angepassten Version bereits in Nutzung und macOS installiert. Einen weiteren Check würde ich jetzt nicht mehr machen. Aber es wäre ja von Interesse, ob diskutil da tatsächlich eine EFI Partition mit entsprechenden ESP Flag erstellt oder wie bei mir eine einfache Fat32-Partition.

Arkturus

Das Skript zur Erstellung eines 1:1 bootfähigen Klons funktioniert einwandfrei. Das habe ich kurz vor dem Hochladen des Skriptes getestet und erfolgreich von der geklonten Partition gebootet.

Wenn ich dich richtig verstanden habe, ging es dir darum, eine größere EFI-Partition zu erstellen, da die vom System generierte EFI-Partition oft nur etwa 200 MB groß ist. Um das zu vereinfachen, habe ich vorgeschlagen, ein Skript zu schreiben, das die vielen manuellen Prozesse vereinfacht zusammenfasst. Außerdem werde ich die von dir beschriebenen Probleme im Zusammenhang mit der Erstellung der EFI-Partition und dem Setzen des entsprechenden ESP-Flags berücksichtigen.

Ich habe das Thema im Blick, bin jedoch aktuell mit einem anderen Projekt beschäftigt. Dennoch werde ich daran arbeiten und versuchen, Lösungen für diese Herausforderungen zu finden.

Gruß

Quote from Arkturus

ich habe mal den Recovery von Sonoma gebootet und auf einer unbenutzten NVMe die ich demnächst verwenden will versucht die Anleitung im Terminal umzusetzen umzusetzen. Das läuft insoweit nach Plan ab, als eine MSDOS Fat32 Partition mit dem Namen EFI erstellt wird und ich habe den Rest der NVMe als freien Speicher zur Verfügung. Allerdings hat die neue Partition keinen ESP/EFI/Flag und wird vom UEFI Bios nicht als solche erkannt. Es lässt sich auch kein UEFI Label in der UEFI-Shell setzen. Es ist einfach eine Fat32-Partition, die auch nicht versteckt ist und nicht gemountet werden muss. Ich haben nun die Anleitung nochmals studiert und bei mir keine Umsetzungsfehler erkennen können. Die Reparatur mit Diskutil repaireVolume ändert an dem Fiasko nichts. DerBeste

Vielleicht hat noch jemand die Zeit und Muße zum Faktencheck.

EDIT: Ich habe mall etwas probiert und das hat nicht einmal eine Minute gedauert. MiniTool Partitionswizzard ist bis 10.3 kostenfrei, jetzt aber nicht mehr ganz billig zu haben.

Ich habe die Test-NVMe zuvor nochnal,s mit dem FDP gelöscht, damit eine konforme EFI vorhanden ist. Dann Windows 11 gebootet und mit dem MiniTool Partitionswizzard die APFS Partition gelöscht und erstmal auch bestätigt, damit die Aktion auch ausgeführt wird. Sonst lässt sich die EFI nicht vergrößern. Wahrscheinlich können die Aktionen vorher auch geplant werden. Dann lässt sich die EFI auch beliebig vergrößern. Ausgeführt und die EFI vom KBL-Desktop reinkopiert und das Teil bootet einwandfrei.

Ich habe übrigens 1 GB für die EFI gewählt, im Bild noch nicht zu sehen. Tatsächlich ist dei gemountetet EFI unter MacOS 1,12 GB

Wird die Disk komplett gelöscht, ist das natürlich wieder weg.

Display More

Hi Arkturus,

ich werde das Ganze noch einmal in aller Ruhe durchgehen und ein neues Skript aus dem ganzen Durcheinander erstellen. Dabei werde ich die notwendigen Korrekturen vornehmen, damit solche Probleme in Zukunft nicht auftreten.

Gruß

Quote from cobanramo

Das "Forum" und meiner wenigkeit ging zwar aus irgendeinem grund davon aus, das du das ganze bei einem "bestehendem" System über Terminal machst..

Spass bei seite, klar kann man auch so machen, viele wege führen nach Rom, am einfachsten finde ich immer noch über Linux, ist schnell und unproblematisch so wie man es haben möchte erledigt...

Why not, irgendjemandem wird es bestimmt mal weiterhelfen, immer her damit..

Gruss Coban

Hi @ll,

Hi Coban,

hier ist das Skript um eine bootfähige 1:1 Klone von der macOS_Sequoia zu generieren.

Auch hier gilt: Sei vorsichtig und wähle die richtige Partition aus, um eine unwiderrufliche Formatierung der falschen Partition zu vermeiden. Ein erfahrener Hackintosh sollte dies eigentlich nicht passieren, aber dennoch ist Vorsicht geboten.

Hier ist, worauf ihr achten müsst:

1. Sicherheitskopien erstellen: Stellt sicher, dass ihr vor der Ausführung des Skripts eine vollständige Sicherung eurer Daten erstellt. Der Klonvorgang kann alle Daten auf der Zielpartition überschreiben.

   
   

2. Richtige Partitionen auswählen: Achtet darauf, die richtigen Quell- und Zielpartitionen einzugeben, um Datenverlust zu vermeiden. Ihr werdet nach den Partitionen gefragt, die ihr klonen möchtet.

   
   

3. EFI-Partition beachten: Wenn auf der Zielpartition bereits eine EFI-Partition vorhanden ist, werdet ihr gefragt, ob ihr diese überschreiben möchtet. Wenn ihr die EFI-Partition nicht überschreiben wollt, stellt sicher, dass dies korrekt beantwortet wird. Das Skript wird mit dem Terminal-Code gestartet: ./clone_script-DE.sh

   
   

4. Benutzerrechte: Um das Skript auszuführen, benötigt ihr Administratorrechte. Ihr werdet nach dem Passwort gefragt, wenn das Skript Befehle mit sudo ausführt.

   
   

5. Verwendung auf Hackintosh-Systemen: Wenn ihr das Skript auf einem Hackintosh verwendet, stellt sicher, dass das Zielsystem nach dem Klonvorgang korrekt bootet. Überprüft die Funktionalität des Systems und der EFI-Partition, um sicherzustellen, dass der Klon ordnungsgemäß funktioniert.

   
   

6. Skriptausführung überwachen: Achtet auf die Protokollausgaben während der Ausführung des Skripts, um sicherzustellen, dass keine Fehler auftreten. Ein Logfile wird erstellt, in dem alle Schritte dokumentiert sind.

   
   

So könnte euer Prozess aussehen:

Laut der Meldung im unteren Abschnitt wurde die 1:1-Kopie meiner Partition im beschriebenen Fall am Ende nicht erfolgreich eingebunden (gemountet). Daher habe ich das Skript entsprechend angepasst. Die korrekte Änderung finden Ihr im Anhang.

Falls noch Fragen auftreten, zögere nicht, nachzufragen. Ich habe eine erweiterte Version des Skripts erstellt, die explizit abfragt, ob die EFI-Partition geklont werden soll oder nicht. Standardmäßig ist das Skript so konzipiert, dass eine vorhandene EFI-Partition auf der Zielpartition nicht überschrieben wird. In der erweiterten Version kannst du individuell entscheiden, ob die EFI-Partition überschrieben werden soll oder nicht.

Im Anhang befinden sich zwei Varianten. Die eine auf Deutsch und die andere auf Englisch.

Viel Erfolg beim Klonen!

Gruß

Edit: Könnt ihr das bitte in das richtige Thema verschieben? Ich bin mir nicht sicher, ob es hierher passt.

@cobanramo

meiner Meinung nach sollte es auch auf dem laufenden System möglich sein, und ich müsste es bei Gelegenheit mal ausprobieren. Wer es jedoch tut, sollte sich bewusst sein, dass es auf eigenes Risiko geschieht.

Edit: Bitte den unteren Beitrag von Coban beachten und nicht am laufendem System versuchen !!! !

Gruß

Hallo Community,

ich habe die versprochene Anleitung in meinem ersten Beitrag (oben) eingefügt.

Ich bin mir nicht ganz sicher, ob es für den einen oder anderen interessant wäre, aber ich könnte eine Anleitung erstellen, wie man eine 1:1 bootfähige Kopie (Clone) einer macOS Sequoia-Partition mithilfe von Terminal-Befehlen erstellt. Wenn das von Interesse ist, lasst es mich wissen, und ich würde die Schritte ausführlich erklären und dokumentieren

Leute, ich stehe zu dem, was ich geschrieben habe, und möchte euch so bald wie möglich ein Update geben. Momentan arbeite ich an einem Experiment mit meiner Nvidia-Grafikkarte, das ich schon seit einiger Zeit verfolge. Wenn ich dieses Experiment erfolgreich abschließe (was ich hoffentlich bald schaffe), werde ich all die Dinge, die ich dabei quasi als Nebeneffekt erstellt habe, hier mit euch teilen können. Bitte habt etwas Geduld mit mir.

Wie bereits oben erwähnt, muss ich wohl in diesem Moment eine Menge Tomaten auf den Augen gehabt haben. Das habe ich völlig übersehen und es wurde dann auf die altbewährte Weise erstellt.

Aktuell bin ich dabei, das Tutorial für die beiden Themen zu schreiben.