Jump to content

[Guide] Dell Latitude E6410 (Nvidia) Hackintosh: Big Sur, Monterey, Ventura & Sonoma macOS installations with Open Core Legacy Patching


deeveedee
 Share

295 posts in this topic

Recommended Posts

I am thinking about making these VMM kernel patches (Reroute kern.hv_vmm_present patch) a permanent part of my EFI.  I have read this and for my purposes, I don't see any reason why these kernel patches can't be permanently enabled.  My hack needs them to perform macOS updates and installs and I don't notice any operational differences when running macOS with these kernel patches enabled.  There are some apps that are negatively impacted by these kernel patches, but I haven't used any of these apps.

 

Does anyone see any reason why I couldn't keep these VMM kernel patches enabled permanently?

 

EDIT: These VMM Kernel Patches used to be a permanent part of my EFI (I copied them from an earlier OCLP-generated EFI).  It was only recently that I dropped them after not seeing them in the OC EFI generated by newer versions of OCLP.

 

EDIT2: From Discord, I learned that this is when the kernel patches were removed (recently): https://github.com/dortania/OpenCore-Legacy-Patcher/commit/218507b8a79a3f721968e77c66c03ab5d6104e51

 

EDIT3: These kernel patches are supposed to be replaced by RestrictEvents.kext 1.1.2 with NVRAM value revpatch=sbvmm.  I have this NVRAM value in my config.plist, but maybe it's configured wrong?

 

Spoiler

Screenshot2023-08-08at9_36_16PM.png.591e18e4409a302fe465a83e58d2cf8b.png

 

It appears that I have done something to break RestrictEvents.kext and that's why I still need the kernel patches to install and upgrade macOS.

 

I checked NVRAM and it appears to be ok:

Spoiler

Screenshot2023-08-08at9_54_15PM.png.5a0db61a2342ac6621e496e315b0fce1.png

 

I checked kextstat and it appears to be ok:

Spoiler

Screenshot2023-08-08at9_58_11PM.thumb.png.bf840d28c95f077da2a1ef054b4d043c.png

 

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

EDIT: The boot issue was solved by the OCLP Devs - it was a flaw in RestrictEvents.kext which is fixed with version 1.1.3.  -no_compat_check is required for this hack.

 

EDIT2: The need for -no_compat_check is mentioned in the RestrictEvents.kext release notes

Screenshot2023-10-18at9_12_48AM.png.c6ce70312d41810a8390b12b5d513ecf.png

 

=======================================

 

I am going to assume that I have something wrong in my EFI and that this error is causing the macOS Installer boot-loop (when update/installing macOS without VMM kernel patches).  It would be too time-consuming for me to test, since I'd have to make EFI changes and then perform macOS upgrades or installs.  I am going to start making small changes to my EFI to see if I can diagnose and resolve this problem over time.

 

The list below will grow as I test different EFI changes.  I'll stop growing the list when I find the solution.

  • remove -no_compat_check from boot-args.  This boot-arg is a left-over from my original Mojave and Catalina implementations (with DosDude patcher) and should no longer be necessary with OCLP's kernel patches and/or RestrictEvents patches.
Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

  • 1 month later...

I do not believe that OCLP is safe to use for secure computing operations.

 

It occurred to me how utterly insane I was for allowing uncertified, 3rd-party software to require that SIP be partially disabled, allow it to root my hack (breaking the macOS "seal"), allow it to install uncertified software at the network layer (for Wi-Fi) and then to trust my hack for anything that requires data privacy, data integrity and protected digital identity.

 

I am typing this on my HackMini8,1 that does not require OCLP.  I will be removing OCLP from my Dell laptop and reverting to High Sierra on that laptop.  I already changed all passwords associated with websites that I visited while using my OCLP-patched Dell laptop.

 

In order for OCLP to be trustworthy for me, it would need one of the following:

  1. The ability to patch graphics and Wi-Fi without breaking the MacOS "seal" (and thus without rooting my hack) and the ability to perform the patches without requiring SIP to be partially or fully disabled - OR -
  2. A certified attestation of the chain of custody of the OCLP software (all of it - the python and the post-install patches) and a certification from a FIPS-certified lab that OCLP and the post-install patches are safe and secure.  This certified chain of custody and lab test would need to accompany each new OCLP version.

Just my personal opinion, but if you are using OCLP, which requires you to partially disable SIP, allow OCLP to break the macOS "seal" and allow OCLP to inject uncertified 3rd-party software into your rooted-Mac or rooted-hack and you continue to do your online banking with your Mac, make stock trades with your Mac, login to your e-mail with your Mac or even something seemingly harmless like login to your FaceBook page, you are placing yourself in grave danger.

 

If you need Sonoma, buy a Mac or a hack that supports it without OCLP.

 

BTW - I believe that Open Core and CLOVER are safe. It is only OCLP that I have a problem with for the following reasons:

  1. OCLP breaks the macOS seal. With the broken seal, macOS loses much of its ability to protect from other threats that are not OCLP
  2. OCLP injects 3rd-party, uncertified software into the network layer. Without attestation to chain of custody and without a FIPS-certified lab test, allowing this on your Mac is insane
  3. OCLP must partially disable SIP (the way SIP is partially disabled, I'm not especially concerned about this, but the combination of the broken seal and injected 3rd-party software with SIP expands the threat/attack surface)

 

EDIT: Because of my OCLP security concerns, I will not use OCLP on any "production" systems that required access to sensitive data, private credentials and other critical systems.  For example, I will not use OCLP on a Mac that I use with my Apple Developer Account, access on-line banking and even something that seems as harmless as access Facebook (which allows single-sign-on to other applications).  I will only be using OCLP in a hobby / experimental environment where no critical or production systems can be accessed or harmed.

Edited by deeveedee
  • Like 3
  • Confused 1
Link to comment
Share on other sites

I have asked one of the OCLP Devs to add a warning in OCLP GUI (when using OCLP to generate OC EFI and apply post-install patches) and another warning that appears each time the Mac / hack is booted with OCLP patches.  If the OCLP Devs add this warning, that would be helpful, since most who use OCLP will be completely unaware of the security risks.  

 

That said, nothing has been said or accomplished to make me feel any more secure when using OCLP.  For the reasons I stated in my previous post, OCLP is unsafe.  If you need even a modicum of data/computer security, buy a supported Mac.

  • Like 1
Link to comment
Share on other sites

@miliuco I see that even you are disappointed in me for the way I handled the OCLP security issue.  No way for you to know, but I tried other ways and finally resorted to eliciting an emotional response that started what eventually became a civilized conversation with an OCLP Dev.  Hopefully the OCLP Devs implement the warnings and the ability to disable Wi-Fi patches as I have requested.  Then, I think OCLP will be more suited to the general, Intel-Mac use that they are targeting.

 

Sorry if I offended you and others with my methods and my confrontational approach.  If I didn't think the matter was important enough to go out on a limb and risk my reputation, I would have just stayed quiet.  It certainly would have been easier.  I feel blessed to have missed the non-confrontational gene.  And just so you know, the people defending the Devs and ridiculing me for trying to expose what isn't really a security concern are ignorant and have no idea what they're talking about.  But this wouldn't be the first time the masses were wrong.

  • Like 1
Link to comment
Share on other sites

@deeveedee

 

Dear friend, you have not offended me in any way, rest assured. On the contrary, it is an important topic that interests many people.


Without going any further, here on the OpenCore side we have seen since the beginning the implementation of many features precisely in search of greater security when using our Hackintoshes. Without going into depth, implementation of SecureBootModel, password to access the picker, option to activate UEFI Secure Boot and a lot of lines of code seeking to eliminate bugs or security risks.


On the OCLP side the situation is different, today there is no other way to apply patches without relaxing the security of the system, but here I also see khronokernel and the rest concerned about security which, of course, is impossible to achieve 100% from the moment we are modifying something that by design is unmodifiable.


Let everyone do what they want, although your warning is useful since many users seem to never think about security so your reminder is welcome.


Your proposal of some notice or information may be a good idea. In some ways this already exists in the OCLP documents but many users do not read these documents so the notice when installing or running OCLP can be useful. Nor can it be an excessively long and complex notice.


In short, we have one person with above-average knowledge and concerns (you) who has expressed concern about lax security with OCLP, we have a good group (probably tens or hundreds of thousands) of outdated Macs who can enjoy the new ones macOS thanks to OCLP, OCLP users should be clear that they lose security when using OCLP and that each one makes a reasoned decision.


I know that my 2 Hackintoshes are less secure when applying OCLP root patches to recover the Fenvi wifi but I prefer to have the wifi back. Am I wrong? If I don't have any safety issues in the future, I will think I did the right thing, but if something bad happens to me, I will think I was wrong. That's how we humans are.


What seems logical to me and is deducible from your arguments is that whoever uses the Mac for professional tasks in any field or task in which security is a plus (or is simply a user more concerned about security), logically should have a real Mac with native macOS without third-party modifications.


Finally, your posts may be liked more or less but they are always interesting and productive. They never seem like filler texts to me. Absolutely. And they often generate opinion-rich discussions.

  • Like 2
Link to comment
Share on other sites

@miliuco  This is what the OCLP Devs have posted on the OCLP Source page:

ScreenShot2023-10-03at1_47_14PM.thumb.png.fb633deabe826a8258c03492ecc40bc8.png

 

Note the comment "These builds ... are not guaranteed to be safe."  

 

If you were the ignorant, uninformed user, would this statement lead you to believe that the official builds of OCLP are guaranteed to be safe?  And would you then conclude that if you want guaranteed safety, use the official build of OCLP and not the nightly builds?

 

Regardless of what has been said to defend the OCLP Devs, they have worked hard to make us believe that OCLP is a simple appliance that is easy to use by everyone and it is safe to use.  It is only when challenged by a technical user that they admit that it is not "set it and forget it" and there is no guarantee of safety.  Oh, BTW, I admire and respect the Devs and think that what they have achieved is awesome.

 

Here's a little story for the interested reader...

In a previous life, my software development team was building a new NDIS drivers for Windows 7.  The NDIS driver was attempting to do something that had never been done before (and, as far as I know, no one else has ever done it after we succeeded).  The first iteration of that driver cost us $1.8M USD to design, develop and test.  When we submitted the driver to a lab for FIPS certification, it failed.  We needed to throw away the old design, do a complete redesign from the ground up, spend another $1.1M USD to design, develop and test before we achieved FIPS certification.  Sometimes, we can do really good work and produce a really great product and it still shouldn't be used.

Edited by deeveedee
  • Like 2
Link to comment
Share on other sites

Imho, you are right in the majority of your statements.

But think about me as an example. I have never worked on IT, I'm a hobbyist, I like the Apple ecosystem a lot, I discovered the Hackintosh world in the very beginning (2005), I fell in love right away, on the one hand I had a Mac for daily use and on the other a Hack to learn, tinker, break something, have fun and have a good time. In those years I didn't even think about security, only about the pleasure of experiencing new things.


Today things are very different, the great expansion of the Internet has brought an exponential increase in risks and security has become a major concern.


I start from the basis that in Hacks we need FakeSMC or VirtualSMC, which are made by volunteer developers, and we rely on these extensions to be able to start the system. And so with many other things that we use to have macOS on a PC and are not made by Apple.


It is true that free software that shows its code allows it to be analyzed by many people. It is also true that analyzing it requires knowledge that most of us do not have. There are Linux and Apache, among others, widely used free software with good security scores. Not made by commercial companies. Largely by volunteers.


But I think that when you talk about OCLP you are thinking above all about SIP and broken seal snapshot. And there is not much to argue with you or contradict you. They are security breaches. Many of us are clear about it.


Before using OCLP in the Hack (never used until the Fenvi wifi in Sonoma) I have seen that some passwords used by me had appeared in password leaks and some other security gaps that I have not always fixed quickly (my fault).


OCLP increases the risk? Yes, as you say. How much does it increase? Difficult to quantify. Am I going to continue having Monterey on my 21" 2015 iMac and Ventura on my 2 Hacks to be safer? I really enjoy all this, trial and error, learning new things, the satisfaction when something resists for hours or days it finally works fine, etc.


Do you see how you always post something that makes us spin in our heads? 🙂 In the end, those who want to learn something and those who don't want to...


Good night and sorry for the long text.

 

Edited by miliuco
  • Like 2
Link to comment
Share on other sites

The very nice discussion with an OCLP developer has continued on MacRumors.  The latest OCLP Dev response suggests that the Devs are unlikely to accept any of my suggestions: allowing Wi-Fi patching to be selectively enabled/disabled and alerting the unsuspecting user of potential data security vulnerabilities on OCLP-patched Macs.

 

My confidence in OCLP would have increased slightly if the Devs eagerly embraced the idea to add warnings.  Now, I have to say that I'm a little more suspicious.  You can see my response here.

 

EDIT: I "jokingly" posted the plot (below) for a fictitious novel that I am not really writing.  I hope readers of this post can see how realistic the plot actually is.  When OCLP becomes mainstream and is used by many unsuspecting, unaware Intel Mac users, the temptations to exploit vulnerabilities in OCLP-patched Macs will increase.  If the OCLP Devs do make any mistakes (they are human after all) or, God forbid, one or more Devs intentionally introduce a vulnerability, the average Intel Mac user will never know (until it is too late).

 

EDIT2: I feel responsible for helping to promote the use of OCLP and did what I thought was necessary to alert our community about the dangers.  I will no longer be participating in any OCLP conversations unless it is to warn about the dangers.  I recognize that if I shout too loudly or too frequently, the effect of my warnings has diminishing returns.

=======================================

 

A group of really nice, well-intended developers created a piece of software that gains instant approval and wide-spread adoption. The really nice developers achieve celebrity status. Unbeknownst to the really nice, well-intended developers, one of the core team members has accepted a substantial bribe from a nation-state. In return for the bribe, the nation-state is permitted to inject innocuous, seemingly harmless code that allows the nation-state to steal identities and hack bank accounts of the users of the popular software.

 

Using unauthorized, personally identifiable information collected during the Beta tests (collected even when the "Disable Analytics Slider" was enabled), in addition to user identity information collected from MacRumors, InsanelyMac, Discord and other online forums, the nation-state develops a list of targets for their malicious exploits.

 

Meanwhile, the really nice, well-intended developers continue to enjoy their celebrity status; so much so, that users of their software actually make donations to them and erect a statue of them in their honor.

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

One of the things that made me suspicious about OCLP was my realization that OCLP Devs were collecting analytics about my hack even though I had analytics disabled in the OCLP GUI.  I never mentioned this on any forums until now.  I was alerted to this unauthorized analytics collection by a Dev in Discord, who didn't realize what he/she said to reveal this secret collection of analytics.  I have learned that temptations to exploit evolve over time.  What may initially be a harmless collection of analytics leads to the realization of something like "look at this - we can see every website that this user is visiting."  This further evolves into, "I wonder what else we can collect / see?"  On these suspicions, I am not speculating - I have seen this happen first-hand.

 

EDIT: After further conversation with Devs here, I don't believe there was any evil/malicious intent in the unauthorized collection of data.  It doesn't change the fact that it was collected and that it triggered my initial suspicions about OCLP security.

Edited by deeveedee
  • Sad 1
Link to comment
Share on other sites

Since I slightly participated to the conversation, I appreciated all the discussion and the effort you've spent in proposing a better awareness about the risks related to OCLP patches.

Dispite my question might be interpreted as retorical, I really want to thank you about giving the proper enlightment to these security hazards.

 

As someone else stated prior to me, anyone will decide about their own machines.

 

By the way, it was clear that you do not plan to switch to novel writing career

  • Like 1
Link to comment
Share on other sites

1 minute ago, acquarius13 said:

By the way, it was clear that you do not plan to switch to novel writing career

 

Am I that bad?  I thought I had a chance.

Link to comment
Share on other sites

50 minutes ago, deeveedee said:

One of the things that made me suspicious about OCLP was my realization that OCLP Devs were collecting analytics about my hack even though I had analytics disabled in the OCLP GUI.  I never mentioned this on any forums until now.  I was alerted to this unauthorized analytics collection by a Dev in Discord, who didn't realize what he/she said to reveal this secret collection of analytics.  I have learned that temptations to exploit evolve over time.  What may initially be a harmless collection of analytics leads to the realization of something like "look at this - we can see every website that this user is visiting."  This further evolves into, "I wonder what else we can collect / see?"  On these suspicions, I am not speculating - I have seen this happen first-hand.

This is really interesting. Have you found something (logs, alerts, warnings, etc.) on your hack about this collection or did the dev tell you about this without considering what he/she was explaing into discord channel? Again, I'm asking in order to check my rigs and, if present, to find a trace of this unauthorized collection.

  • Like 1
Link to comment
Share on other sites

@acquarius13 The Dev disclosed something to me about my hack that was not mentioned by me and could only have been known through the collection of data from my hack.  I did not authorize the collection of this data and had specifically set the "Analytics" slider to disabled in the OCLP GUI.  An easy explanation for this unauthorized collection would be "We collected the analytics because OCLP was Beta."  The reason doesn't matter - the data was collected without my authorization.  If Devs are willing to take this liberty, then they have already demonstrated that the end justifies the means.  After that line is crossed, nothing is off limits (and I don't care how nice, friendly, charismatic and well-liked they are or how big their fan base is).

 

EDIT: The unauthorized collection of data was via the OCLP updating/patching process (not the Open Core EFI generation).  I need everyone to think about what this means.  Let's say that OCLP's post install patches (which sit at the network layer) are collecting data.  Let's say that this collected data is submitted innocuously in an "encrypted" non-human-readable format that can be deciphered by the recipient...  What if this collected data starts as pure analytics for the sake of improving OCLP and later evolves into all the website IP addresses visited by the user... Where does this go?  What could someone do with this data if they knew the websites that you visited?

 

When I was writing NDIS drivers for Windows, our customers used our software in DEBUG mode.  We clearly disclosed to our customers that we were collecting data that would reveal all IP addresses known/visited by the PCs and Servers running our software.  Since our NDIS drivers operated in promiscuous mode, we could also collect data about the packets on the local network.  We never used this data maliciously and always disclosed all data collected to our customers.

 

EDIT2: I don't think that anyone will believe I was clever enough to test this unauthorized disclosure of my data, but I actually did plan to find out whether data was being collected about me and I did take actions to substantiate my suspicion.  Without knowing my background, no one would actually believe that I did this.

 

EDIT3: The Devs rejected my request to allow the user to disable Wi-Fi post-install patches.  It is the Wi-Fi post-install patches that concern me most.  Their fans will cheer their decision to keep OCLP easy to use.  I've probably read too many CIA/Assassin thrillers and I've personally seen too many exploitation attempts that my team thwarted, but this rejection of my feature request by OCLP Devs just makes me more distrusting.

 

This reminds me of the movie "A Few Good Men":  You said he was in danger, I said, 'Grave danger?' You said, 'Is there any other kind?'

Edited by deeveedee
  • Like 2
Link to comment
Share on other sites

I need to point out one other thing that is interesting in MacRumors.  One of the Devs, Ausdauersportler, is going out of his way to publicly discredit me.  The exchange starting here is revealing.  He makes personal attacks against me (never any technical claims or arguments) hoping to damage my reputation and credibility.  He does have a few fans that like him no matter what he says.  One of the more mature Devs (Ball of Neon who goes by TheDebunker in the MacRumors forum) has engaged me quite civilly with what I think is a productive conversation.  Ausdauersportler has not demonstrated the mental or intellectual capacity to operate at this same level.  His attempts to discredit me make me even more suspicious.

  • Like 2
Link to comment
Share on other sites

@acquarius13 See this conversation here.  Read the 4 or 5 posts.  You and I have the same idea.

 

EDIT: My recent dialog with Ball of Neon (TheDebunker) on MacRumors has made me really like these OCLP Devs.  I respected them for their accomplishments with OCLP.  Now I genuinely like them.  But ... just because I respect and like them doesn't in any way lessen the data security risks with OCLP.  In almost every interaction where I've seen OCLP defended, the reason is because "they have always been so helpful" or "they're so generous with their time" or "look how much they have done for us."  I hate to break it to you, but that is irrelevant.  We're talking computer / data security people.  WTF?

Edited by deeveedee
Link to comment
Share on other sites

This post and subsequent posts make it even more important for OCLP to include data security warnings during installation/patching and when the OCLP-patched Mac boots.  Regardless of what OCLP defenders and fans have claimed, OCLP Devs have made claims that OCLP is "Built with Security in Mind" and easy to use.  The OCLP Dortania page  claims "Experience macOS Just like before"

Spoiler

ScreenShot2023-10-05at7_05_58AM.thumb.png.84b48661e76cbb14f288f4cacb294d07.png

 

If this doesn't imply to the unsuspecting user that an OCLP-patched Mac is just as safe and secure as an unpatched Mac, I don't know what does.

 

I appreciate the fact that the OCLP Devs are now saying that OCLP was initially intended to be a "small project" with limited audience, but the extensive work invested in the product and the documentation says otherwise.  OCLP has all the earmarks of a product intended to go mainstream.

 

EDIT: I appreciated TheDebunker's (Ball of Neon's) courteous and professional approach, but I need to correct one thing they said.  In the MacRumor's forum, TheDebunker said that OCLP would have a short life because Apple will drop Intel support in 2-3 years.  We just received a Big Sur update from Apple and Apple is still publishing Safari updates for Big Sur.  Big Sur was released in 2020.  It is 2023.  If Apple discontinues Intel support in a macOS release 2-3 years from now, that means that Apple will be supporting Intel-based Macs for another 5-6 years.  That's a long life expectancy for OCLP.  And there will certainly be users who use their OCLP-patched Macs well beyond the end of Apple's official support.

 

EDIT2: TheDebunker claimed that the use of Discord as a communication medium was something the Devs later regretted.  I think it was brilliant.  If I wanted to maximize publicity for my new app and I wanted to maximize exposure to non-technical, unquestioning, unaware users, I'd use Discord to do it.

 

EDIT3: I'm amazed by short memories.  The customers of Bernie Madoff and Sam Bankman-Fried loved both of these men ... until they didn't.

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

I continue to stand by my position that OCLP-patched Macs / hacks are not safe for production use with e-mail, on-line banking, software development that requires secure credentials (e.g., Apple Developer Account), activities that are seemingly harmless like checking a FaceBook page and any activities that require the use of private credentials, secure data and secure digital identity.  There is now an OCLP discussion thread here.

  • Like 1
Link to comment
Share on other sites

My requests to add warnings in OCLP have been challenged by many defenders/supporters/fans of OCLP and defenders/supporters/fans of the OCLP Devs.  My request to add warnings seemed like a no-brainer to me, so I thought of an analogy that will help to explain my OCLP feature request here.

Edited by deeveedee
Link to comment
Share on other sites

I am pleased with the Dev responses in the OCLP Security Thread. One of my reasons for assisting with the creation of the OCLP Thread was to have a public repository of OCLP security issues until messaging and warnings are implemented. Unfortunately, the Dev responses suggest more potential security vulnerabilities than I had anticipated.

 

I will not be using OCLP to apply post-install patches on any 'production' systems where my private credentials, secure data and digital identity need to be protected and could be at risk.

 

There are many who are angry with me because I had the audacity to challenge the Devs and their generosity. That makes no sense. This is not personal, not a popularity contest, not a game of playing nice. This is serious and those who are treating the issue as a hobby and a game should only be using OCLP in a no-risk, hobby environment to play games.

 

I accept responsibility for helping to promote the use of OCLP. I am now trying to make all aware of the dangers.  Computer/data security happens to be my area of expertise and I recognize that there will be challenges and claims of overdoing it by those who have no idea what they are talking about.

 

BTW: This is so serious that I am suspicious of anyone who tries to clutter the OCLP thread with tangential garbage or makes attempts to damage my credibility or that of the OCLP security thread. There are people who want security vulnerabilities to remain unknown, unaddressed and fully exploitable. They will go to great lengths to win trust and popularity while hacking your data and stealing your identity. Ask Sam Bankman-Fried and Bernie Madoff how their customers loved them (until they didn't).

 

In this case, we must look a gift horse in the mouth. How quickly we have forgotten the lessons of the Trojan Horse and plenty of more current examples that should make us at least cautious.

Link to comment
Share on other sites

I discovered that OCLP was ignoring my setting to disable checks for newer OCLP versions.  Even when I disabled App Updates, OCLP was still checking for and notifying me of the availability of a newer OCLP version.  Since I can't believe the OCLP GUI settings, I have completely removed OCLP from this HackBookPro6,2 for the reasons stated previously.  I have reverted to High Sierra 10.13.6 which runs "natively" on this hack (High Sierra natively supports NVidia Tesla).

 

After I figure out what's going on with the OCLP App Update setting (and possibly Reporting setting), I plan to resume my use of OCLP with Ventura.  I will not be using OCLP with Sonoma unless OCLP Devs figure out how to patch Wi-Fi without root-patching the Wi-Fi framework.

 

I am currently running High Sierra 10.13.6 booting with Open Core 0.9.5.  This hack runs PERFECTLY.

 

EDIT: Apps that I am using with High Sierra 10.13.6 include

  • Microsoft Remote Desktop 10.15.2
  • Microsoft Office 2019
  • Tunnelblick (Open VPN) 3.8.8d
  • Firefox 115.3.1esr
  • Norton Antivirus 360
  • iMovie 9.0.9 (need to figure out how to upgrade to 10.1.9)

 

EDIT2: I have reinstalled Ventura 13.6 with OCLP 0.6.8.  Despite disabling App Update in the OCLP GUI, the OpenCore-Patcher app was installed and enabled in Login Items.  I have disabled this script:

Screenshot2023-10-13at8_43_58AM.png.1835a4f92788545ec465da408867f0dc.png

Edited by deeveedee
  • Like 1
Link to comment
Share on other sites

Now that I have determined the suitable "insecure" use of the hack, I am becoming increasingly impressed with Ventura 13.6 running on my MBP6,2 patched with OCLP 1.0.1. Despite having both macOS firewall enabled (both incoming and outgoing connections) and Norton Antivirus 360 / Firewall with an active subscription for updates, this MBP6,2 is VERY responsive. I am running the following apps without issues (I understand that my use cases may not be the same as yours, so YMMV):

  • MS Office 2019 (Word, Powerpoint, Excel are most common apps for me in Office) (fully licensed for updates)
  • Tunnelblick Open VPN
  • Handbrake (yes, it's slow, but it works)
  • Safari, Firefox 
  • MS Remote Desktop
  • VNC Viewer
  • XCode
  • Terminal

Because of the increased attack surface with my OCLP-patched hack, I do not have e-mail or any private/sensitive documents on my hack and I do not access my bank records, investments on my hack. I use a fully-supported system for more secure/sensitive operations. Again, this is just my preference.

All working extremely well!

 

Also very interesting, when I first used DosDude patches to enable Mojave and Catalina on this Dell Latitude E6410, I needed to use a "heavier" Dell power brick.  With the OCLP-patched hack, power management is so good, that I am using the much lighter power adapter.

  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...