Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. @mhaeuser Thank you for contributing to this thread. My intent wasn't to bash anyone or any boot loader and I certainly do not want to mandate my security preferences. Just trying to raise awareness.
  3. It would be great if somebody could help me in testing the driver. I have three machines with X520-DA1 adapters connected via DAC cables and 10GBase-SR fibre optics to the switch. Everything is working fine in these configurations but I would like to ask some X540 and X550 owners to test the latest version of the driver with their cards. Please check if the media (100Mbit, 1Gbit, and 10Gbit, for X550 also 2.5Gbit and 5Gbit) are correctly recognized and working well as I don't have the opportunity to test these configurations. Thanks in advance❣️
  4. @deeveedee For context, I implemented OC Secure Boot. Your observations are all correct from what I can tell. You are also correct that non-T2 Macs *do* use Apple Secure Boot Medium Security starting with the verification of the kernel (efiboot is not verified). I guess Apple's work is also "nonsense", maybe they need some better experts for consultancy. ;) @miliuco's distinctions of Full and Medium Security as well as evaluation of security are lacking. Full Security works a bit like iOS, where the Image4 manifests are personalized for the machine (based on ApECID), which prevents booting unexpected installs (i.e., ideally such not explicitly installed on this machine). Of course, the iOS model is more sophisticated with downgrade protection and all. The advantage of this is questionable for various reasons, but I think of it as an intermediate step towards the more iOS-like model we got with Apple Silicon. I'm not sure whether Apple has any protection whatsoever against just re-using the same ApECID on another machine to forge supposedly trusted installs with T2. Regarding whether this is needed for personal use, well, why not? Every consumer device nowadays uses Secure Boot - Desktops, Laptops, Tablets, Phones, Watches. Windows requires it to be supported, macOS enables internal checks by default, and even many Linux distros are capable by default and ship with the necessary infrastructure. Booting an external device is not the main or only attack vector, any malicious modification of the boot chain suffices (which can be done in software with admin permissions and with incorrectly configured systems even with plain user permissions, also privilege escalation exploits could suddenly be made much more persistent). I advise against making up supposed "primary threat vectors" and to instead trust the leading engineers who do this for a living. Regarding T2, well, it is not even involved in what is classically called "Secure Boot". T2 Macs have the additional efiboot verification done by Mac EFI (which OC does for us, but introduces the new issue that OC must be trusted too), which serves the same purpose as UEFI Secure Boot. In fact, when you sign OpenCore for usage with UEFI Secure Boot and configure Apple Secure Boot correctly, you have a fully end-to-end Secure Boot chain. There are no compromises or "half-bakedness" due to missing T2 here. However, T2 is involved in two related technologies, called "Trusted Boot" and "Measured Boot". The former verifies the integrity of UEFI itself. Without it, you could maliciously modify the firmware and then disable Secure Boot that way. However, if you use a device with Intel Boot Guard or similar, it is not disrupted by using UEFI SB-ready OpenCore and Apple Secure Boot - you again have a perfectly valid end-to-end Trusted Boot + Secure Boot chain. The latter "measures" various platform properties (configuration, loaded software, ...) and then applies security policies to them. For Windows and BitLocker, TPM may not release the decryption key if the measurement yields unexpected results. For Apple T2, I am actually not sure, it is not well documented or explored which policies they apply. You cannot easily replicated this in software, but it is not even clear what exactly you lose. TL;dr, T2 hardly matters here. I advise to ignore @Slice for such topics, as he primarily drops uneducated one-liners, ignores corrections, and decides to remain both ignorant and yet confident in obviously incorrect claims.
  5. Today
  6. I forgot to mention OCLP Nightly version 1.5 has been reverted to 1.4.3 Nightly as kindly pointed out by @Antonuccio.
  7. @eng_redaesm Developers link, get OpenCore-Patcher.app (GUI). https://github.com/dortania/OpenCore-Legacy-Patcher/actions/runs/8326849351 @eSaF has posted the script by @LAbyOne , it works very well but I am not comfortable with a shared app on InsanelyMac whose code is not accessible. It's just a personal opinion.
  8. SecureBootModel ? Set it to Disabled Disable any kexts for Wifi and Bluetooth... and try again Add your hardware in Signature
  9. Here is a better Method. A Downloader for both Release and Nightly versions. On my machine after launch, I have to go to Finder/Applications (not Launchpad) to see the app (in Terminal!!??) Then you will be presented with 2 options plus Exit. Any problems let me know. Good luck. OC-Legacy Patcher Downloader.dmg.zip
  10. @eSaF Can You share OCLP Nightly version 1.5 link please
  11. Hi, zip and upload your EFI Folder so we can see if there any problems within. Also furnishing your profile with the specs of your machine would also be very helpful. See here how to add your Specs.
  12. 38:825 0:000 No OpenRuntime driver. This is ok, OpenRuntime is not mandatory. This is false message. OpenRuntime is mandatory. I changed this message in new commits.
  13. I am a Chinese user and I am not proficient in using English. I am a Chinese user and I am not proficient in using English. During the installation process, when installing Sonoma 14.41, some machines may restart indefinitely, but the specific reason is unclear. When installing 13.6.6 using the same configuration of EFI, everything was fine again. The specific reason is very confusing. I believe that the EFI file I configured is compatible and complete. Although this conceptual problem may arise, there are indeed some machines that may have it.
  14. I already have these two kexts in there and they are active
  15. Maybe it is not "RtWlanU.kext" and "RtWlanU1827.kext" , make sure that usb map is done correctly and if not try "RtWlanU.kext" and "RtWlanU1827.kext" with xhiunsupported.kext and USBinjectAll.kext and see... I had same problem and used mentioned kexts Good luck.. just trying to help mate
  16. Question to @chris1111 about USB WiFi adapter. Is there already a solution so that you can use e.g. TP Link T9UH USB WiFi adapter with Sonoma 14.4.1. I just tried the last version V16, kexts and config.plist entries also come in, but OC doesn't boot. If I set "false" for these two kexts "RtWlanU.kext" and "RtWlanU1827.kext" in the config.plist, OC then boots normally again. It would be nice if I could still use this TP Link T9UH on my Hackintosh. The device works perfectly under Ventura even with the ac WiFi standard. Thanks for the tips, greetings Alfredo
  17. see my friend @miliuco and above too My Lenovo 100% intel Wifi and BT to my Desktop intel Wifi + BRCM BT And both to my Iphone The "secret" to me is Clover and compiled Kexts and Bootloader with GCC compiler
  18. Hi my friend works from Desktop to iPhone for while, and I believe it's not Bluetooth or even Wireless, but permission or configuration from Kext. See my Desktop Airdrop intel Wireless + Broadcom BT to my Iphone
  19. Yesterday
  20. @Max.1974 I'm skeptical, I don't think Intel wifi can ever use Airdrop. Apple configures macOS by default to use Airdrop only under very specific conditions. itlwm spoofs itself as wifi but it is not seen by macOS as real wifi. AirportItlwm works the way Airdrop compatible wifi work, it can support Airdrop in theory but so far the developer has not been able to do it, this kext comes from the Linux driver and the Linux code surely lacks what Broadcom has to allow Airdrop.
  21. Hi all friends, since I decide put my Broadcom Wireless Card + BT on my Aorus Z790 (with intel WI-Fi 6 Ax211 + intel BT), when I mapped my usb ports, I block intel BT and use BRCM Broadcom bluetooth working fine, and using compiled Clover 5156 or 5157 (not works with "another" boot loader), to send from my Desktop to my iPhone works fine or another real Mac. Include too my not real Mac Lenovo E470. I believe that coders will find way to work AirDrop with intel Wireless card.
  22. Update. Discovered that I had to add amfi=0x80 due to Amfipass.kext not being loaded. Used proper tree and it asked if I wanted to fix an inheritance issue between amfipass.kext and IOSkywalkFamily.kext (maybe not this one but one of the new kexts). Said yes and proper tree reordered my kexts in config.plist. Took out amfi=0x80 and it boots again w/o it. Updated system to 14.4.1 and OCLP had a background task that asked if I wanted to patch the system again. Said yes, it patched and rebooted. All good. WiFi works along with AirDrop with a Fenvi T919 in 14.4.1 Sonoma on a HP 800 G5 SFF. Also mapped my USB Ports using USBToolBox in Windows to get my internal (on motherboard) USB port to work so I could plug in the BlueTooth 4.X Fenvi cable. Bluetooth now also works. I'd like to investigate finding a BT 5.0 or even 5.1 to work in my hack. Want this to connect to my stereo in another room. Thank you all for your help. Especially @miliuco
  23. I agree that the value of OpenCore's SecureBootModel depends on the use cases. That has always been my point with security. If I disconnect my Mac from all networks and turn it off, then it is completely safe for use as a paper weight. We're not off-topic in this thread. i think it's important for people to be able to see what OpenCore's SecureBootModel does and then for them to make their own determination. My challenge is with blanket statements like "useless," "nonsense" and "has no/little importance in Hacks" when no context has been provided. Statements like this lead users to believe that they don't need to consider their use cases.
  24. @Paweł I don't have this card. Did you try 2.4.2 beta version? https://dortania.github.io/builds/?product=RealtekRTL8111&viewall=true
  25. @deeveedee Yes, in single user use on a home PC I believe that disabling SecureBootModel has little influence on security. It may be that in multi-user or business use it may be more important. Verification of the kernelcache and OS snapshot is important, of course, but you have to accept that there are users who can operate differently without being worried about it and that is something we have to accept. I assume that we are using a boot loader (OpenCore or Clover doesn't matter here) developed by people we don't know (but we trust) to install macOS in an environment for which it is not specifically designed. I can say the same about kexts. If strict security (or as high as possible) were one of the guidelines of my activity with computers, it is likely that I would not have Hacks or Windows. But for me mainly it is a very great hobby. I don't underestimate security at all, but I think that what macOS gives me in the Hack is enough for me even with SecureBootModel=Disabled or OCLP. Actually, I have SecureBootModel=x86legacy on all systems except for one Sonoma disk where I am interested in keeping in touch with the evolution of OCLP and the patch for Broadcom Wi-Fi. I think we're getting off the topic of this thread and linking to other posts about security in macOS. If the topic is SecureBootModel and its usefulness in Hacks, I contribute what I know so far about it.
  1. Load more activity
×
×
  • Create New...