MP 1,1-5,1 MonteRand (probably the start of an ongoing saga)

[cdf]

the patches below just remove the rdrand instructions and use a constant value instead.

I haven't looked at the actual instructions behind the patch, so maybe this is meaningless, but in case it isn't: could a user generated random value be used instead of a constant for a modicum of extra security?

 

[Bmju]

Hello @Syncretic , if you recall we had conversations some months ago and also you made on my request telemetrap, so I already knew your expert advanced skills in this field.

While my machines don’t required Latebloom (though I tested to delay booting and no issues) and SurPlus, from 12.1 beta1 kernel ≥ 21.2.x instead your new MonteRand patch is totally required.

I have low knowledge of that stuff you explained, but when I read a documentation I understand a bit of something, so with your MonteRand through OpenCore you are patching the kernel binary in RAM, so I simply adapted or converted your OC patch to a binary patch, but not directly on kernel file (as you can notice from picture the modified date is still stock apple 26 October) rather on its Preboot BKE kc that essentially already embeds the uncompressed LZFSE kernel and doesn't even require to rebuild a new kc with the patched kernel, so I summarised as this example:

sudo perl -pi -e 's|\x0f\xc7\xf1\x73\xfb\x21\xf1\x39\xd1\x73\xf5\x89\xc9\x48\x8b\x94\xcd\xd0\xfd\xff\xff|\x31\xc9\x90\x90\x90\x21\xf1\x39\xd1\x73\xf5\x89\xc9\x48\x8b\x94\xcd\xd0\xfd\xff\xff|g' /path/BootKernelExtensions.kc

sudo perl -pi -e 's|\x0f\xc7\xf2\x73\xfb\x83\xe2\x0f\x83\xfa\x07\x77\xf3\x0f\xb7\x34\x41|\x31\xd2\x90\x90\x90\x83\xe2\x0f\x83\xfa\x07\x77\xf3\x0f\xb7\x34\x41|g' /path/BootKernelExtensions.kc

of course this can be also applied directly to the kernel file but this implies to rebuild kmutil kc and a new snapshot from an external Recovery environment.

Tested your patch on same external USB disk with MacBook7,1 and MacBookPro6,2 (dualGPUs) and properly worked.

Thanks for your incredible work.

Hi - Probably a stupid question - and even if I 'should' know the answer, I don't! - but what is the advantage of patching here, vs. where OC patches by default?

 

[jackluke]

Hi - Probably a stupid question - and even if I 'should' know the answer, I don't! - but what is the advantage of patching here, vs. where OC patches by default?

No advantage (or maybe just allowing optional booting 21.2.0 from apple startup manager or refindplus or for those who delete snapshots for mount -uw / on machines without rdnand instruction) it's just for experimenting, I also of course use mainly OC and OCLP for OTA updates and they are without doubt much more advisable than any other method.

 

[Bmju]

@jackluke - Can I ask one more even more stupid question - what are you using BKE to stand for? I can see that you mean the decompressed kernel cache, but any google for BKE does not throw up much else (except for a few posts by your good self). Am I just showing how new I still am to mac/hack questions?!

 

[jackluke]

@jackluke - Can I ask one more even more stupid question - what are you using BKE to stand for? I can see that you mean the decompressed kernel cache, but any google for BKE does not throw up much else (except for a few posts by your good self). Am I just showing how new I still am to mac/hack questions?!

It's just an acronym I meant for BootKernelExtensions.kc usually located here (or anywhere apple copies it): /System/Volumes/Preboot/*/boot/System/Library/KernelCollections/

and right from BigSur it's already uncompressed (while from Yosemite and Catalina was compressed), that's why can easily patch it directly, but as I wrote binary patching the kernel and rebuild kc also worked.

 

[Syncretic]

I haven't looked at the actual instructions behind the patch, so maybe this is meaningless, but in case it isn't: could a user generated random value be used instead of a constant for a modicum of extra security?

(Warning: my brain seems to have its "-v" boot-arg set today, so lots of words to follow. Apologies for the wall of text.)

This patch was another "quick and dirty" fix so that 12.1b1 didn't stop everyone in their tracks - i.e. we couldn't know what other gremlins were lurking in the shadows until we could get past this one that prevented booting. The simplest path was to just disable the randomization, and from there we could determine what else might need attention for unsupported Macs to work. Longer-term, what you describe might be a better solution - or not. Someone needs to do more analysis on the affected code to more fully understand exactly why it's doing what it does. Is it purely a precautionary change, or is it a response to a known threat? Simply removing the randomization may or may not present an acceptable risk, but we won't know the true extent of that risk without further examination. I plan to do this when I have time, but nothing prevents someone else from digging into it. My available time comes in small increments.

Patching code like this is straightforward. Adding new code at boot-time is tricky - the obvious path is to use a kext, but kexts aren't necessarily available or usable during early boot, so we'd be talking about inserting new code somewhere, which presents a separate set of problems (both logistical and security-related).

In general, I don't spend much time on betas; I don't install them without a compelling reason, and I only analyze them for indications of what's coming in the release. Once there's a release, it's no longer a moving target, and I'll see what I can do with it. This is no different; I only patched this beta because further progress was impeded without such a patch. (I still haven't installed 12.1b1 here, and probably won't.)

So, long story short: replacing the RDRAND instructions with some other randomization would probably be better than using a constant, but likely involves great difficulty to do so, and may not really be necessary. I'll ponder it, but I don't expect to spend much time on details until an official release is imminent (again, to avoid wasting time on moving targets that change from week to week - for all we know, these RDRANDs will be gone in 12.1b2).

---

While I have the floor, please forgive a brief digression/non sequitur. Feel free to ignore the rest of this post.

On and off this site (but thankfully not on this thread), I've seen some sensationalistic posts promoting an alarmist view - that Apple is adding things like RDRAND explicitly to prevent old Macs from running Monterey+, possibly even in direct response to threads like this one, and they're effectively "out to get us." I disagree.

I have seen no evidence that Apple is actively trying to prevent classic Macs from running new versions of MacOS. What I do see is Apple's developers' indifference to the old systems, and their willingness to adopt new features from the oldest supported platforms. When they started using SSE4.1 instructions in MacOS, it wasn't to explicitly "kill off" the first two generations of Mac Pros, it was because SSE4.1 offered performance advantages, and every officially supported platform at that time had SSE4.1. It's unreasonable to expect Apple to jump through hoops (including avoiding use of newer technologies) to support old technologies when they have no reason to do so. We're lucky to have gotten this far with as few problems as we've encountered. Apple will almost certainly continue to expand the use of newer instructions when they're advantageous, and we'll either adapt or reach a point where it's no longer practical to do so (case in point: Mac Pro 1,1/2,1).

Apple could easily make it impossible to install Monterey on classic Macs. They don't bother wasting even minuscule resources on that because they don't have to. In 2020, Apple sold an estimated 22.5 million new Macs. The active "unsupported Mac" community ("active" meaning "trying to keep installing new MacOS versions," not "still running Mavericks on my trusty MP3,1") probably numbers less than ten thousand - that's 0.04% of their annual sales, and that estimate is probably high. We are not a "thorn in Apple's side," we are not "a force to be reckoned with," we are probably not on Apple's radar in any meaningful way at all. Apple is not interested in expending resources to curtail using Big Sur or Monterey on our old cheesegraters, they have bigger fish to fry. Instead, they want to optimize the performance of MacOS on the Macs they're still supporting, and if that means using instructions that didn't exist when our old systems were built, why not? The problems our old Macs encounter aren't there because Apple is throwing up roadblocks, it's because they don't care about the consequences for old Macs at all.

In short, please don't propagate dire warnings that Apple is actively trying to prevent us from moving forward with our old Macs, or that they're directly responding to what we're doing here. Without actual evidence, that's just clickbait. Our classic Macs' days are definitely numbered - not because Apple's "out to get us," but simply because our old Macs are old. (You don't see 8-track tape enthusiasts suggesting that Big Music is out to get them; technology has simply passed them by. We're on the same road, just moving a lot slower, and some of us are trying to tap the brakes to prolong the journey a bit. The end of the road is still somewhere out there, though.)

(Sorry for the rant, but that's been bothering me for a while. Please enjoy the rest of your day!)

 

[sfalatko]

Hello @Syncretic , if you recall we had conversations some months ago and also you made on my request telemetrap, so I already knew your expert advanced skills in this field.

While my machines don’t required Latebloom (though I tested to delay booting and no issues) and SurPlus, from 12.1 beta1 kernel ≥ 21.2.x instead your new MonteRand patch is totally required.

I have low knowledge of that stuff you explained, but when I read a documentation I understand a bit of something, so with your MonteRand through OpenCore you are patching the kernel binary in RAM, so I simply adapted or converted your OC patch to a binary patch, but not directly on kernel file (as you can notice from picture the modified date is still stock apple 26 October) rather on its Preboot BKE kc that essentially already embeds the uncompressed LZFSE kernel and doesn't even require to rebuild a new kc with the patched kernel, so I summarised as this example:

sudo perl -pi -e 's|\x0f\xc7\xf1\x73\xfb\x21\xf1\x39\xd1\x73\xf5\x89\xc9\x48\x8b\x94\xcd\xd0\xfd\xff\xff|\x31\xc9\x90\x90\x90\x21\xf1\x39\xd1\x73\xf5\x89\xc9\x48\x8b\x94\xcd\xd0\xfd\xff\xff|g' /path/BootKernelExtensions.kc

sudo perl -pi -e 's|\x0f\xc7\xf2\x73\xfb\x83\xe2\x0f\x83\xfa\x07\x77\xf3\x0f\xb7\x34\x41|\x31\xd2\x90\x90\x90\x83\xe2\x0f\x83\xfa\x07\x77\xf3\x0f\xb7\x34\x41|g' /path/BootKernelExtensions.kc

of course this can be also applied directly to the kernel file but this implies to rebuild kmutil kc and a new snapshot from an external Recovery environment.

Tested your patch on same external USB disk with MacBook7,1 and MacBookPro6,2 (dualGPUs) and properly worked.

Thanks for your incredible work.

@jackluke - an interesting idea. If I understand what you are doing you are patching the kernel on the Preboot volume - correct? If so wouldn't you need to repatch after every update (security or feature update)? If that is the case then it seems that patching through OC would be overall easier.

 

[cdf]

Patching code like this is straightforward. Adding new code at boot-time is tricky - the obvious path is to use a kext, but kexts aren't necessarily available or usable during early boot, so we'd be talking about inserting new code somewhere, which presents a separate set of problems (both logistical and security-related).

Actually, I was proposing something much simpler: to use a random number generated by users when they configure the patch. This could even be automated in OCLP every time a user refreshes their OC setup. Random numbers during early boot are used to randomize the kernel address space layout to make attacks more difficult. I suppose having a new number every now and then when updating OC is better than nothing...

 

[splifingate]

(Sorry for the rant, but that's been bothering me for a while. Please enjoy the rest of your day!)

Feel-free to blow-off as much steam as you need! Please just don't let yourself lob your comps out the window like a Letterman Watermellon <smile>

I hope you enjoy the rest of *your* day, Syncretic

Regards, splifingate

 

[joevt]

I haven't looked at the actual instructions behind the patch, so maybe this is meaningless, but in case it isn't: could a user generated random value be used instead of a constant for a modicum of extra security?

You could make it pseudo random.
wikipedia has more info about RDRAND and suggestions for alternatives. It explains that RDRAND is slow and is not meant for high performance code.
https://en.wikipedia.org/wiki/RDRAND

Any user-space application can do as it pleases, including using instructions newer than the CPU it's running on. If that happens, a #UD exception is thrown, and that process gets terminated. The real problems occur when such instructions appear in kernel-space (e.g. in a kext, or in the kernel proper) - the #UD condition is considered fatal, and a panic occurs. That's what this patch is trying to avoid.

How is RDRAND different from the instructions that AAAMouSSE.kext emulates? Can't it be emulated the same way? I understand the kernel loads earlier than kexts, so you'll need a different method to setup the instruction emulation.

Can you setup instruction emulation in an EFI driver? Does that setup survive transferring control to the kernel from boot.efi?

 

[Forrhouse]

Hello @Syncretic , if you recall we had conversations some months ago and also you made on my request telemetrap, so I already knew your expert advanced skills in this field.

While my machines don’t required Latebloom (though I tested to delay booting and no issues) and SurPlus, from 12.1 beta1 kernel ≥ 21.2.x instead your new MonteRand patch is totally required.

I have low knowledge of that stuff you explained, but when I read a documentation I understand a bit of something, so with your MonteRand through OpenCore you are patching the kernel binary in RAM, so I simply adapted or converted your OC patch to a binary patch, but not directly on kernel file (as you can notice from picture the modified date is still stock apple 26 October) rather on its Preboot BKE kc that essentially already embeds the uncompressed LZFSE kernel and doesn't even require to rebuild a new kc with the patched kernel, so I summarised as this example:

sudo perl -pi -e 's|\x0f\xc7\xf1\x73\xfb\x21\xf1\x39\xd1\x73\xf5\x89\xc9\x48\x8b\x94\xcd\xd0\xfd\xff\xff|\x31\xc9\x90\x90\x90\x21\xf1\x39\xd1\x73\xf5\x89\xc9\x48\x8b\x94\xcd\xd0\xfd\xff\xff|g' /path/BootKernelExtensions.kc

sudo perl -pi -e 's|\x0f\xc7\xf2\x73\xfb\x83\xe2\x0f\x83\xfa\x07\x77\xf3\x0f\xb7\x34\x41|\x31\xd2\x90\x90\x90\x83\xe2\x0f\x83\xfa\x07\x77\xf3\x0f\xb7\x34\x41|g' /path/BootKernelExtensions.kc

of course this can be also applied directly to the kernel file but this implies to rebuild kmutil kc and a new snapshot from an external Recovery environment.

Tested your patch on same external USB disk with MacBook7,1 and MacBookPro6,2 (dualGPUs) and properly worked.

Thanks for your incredible work.

On your Macbook 7,1, after installing Monterey, do you have any sleep wake issues or any graphics issues?
Thanks,
E

 

[paalb]

(Warning: my brain seems to have its "-v" boot-arg set today, so lots of words to follow. Apologies for the wall of text.)

This patch was another "quick and dirty" fix so that 12.1b1 didn't stop everyone in their tracks - i.e. we couldn't know what other gremlins were lurking in the shadows until we could get past this one that prevented booting. The simplest path was to just disable the randomization, and from there we could determine what else might need attention for unsupported Macs to work. Longer-term, what you describe might be a better solution - or not. Someone needs to do more analysis on the affected code to more fully understand exactly why it's doing what it does. Is it purely a precautionary change, or is it a response to a known threat? Simply removing the randomization may or may not present an acceptable risk, but we won't know the true extent of that risk without further examination. I plan to do this when I have time, but nothing prevents someone else from digging into it. My available time comes in small increments.

Patching code like this is straightforward. Adding new code at boot-time is tricky - the obvious path is to use a kext, but kexts aren't necessarily available or usable during early boot, so we'd be talking about inserting new code somewhere, which presents a separate set of problems (both logistical and security-related).

In general, I don't spend much time on betas; I don't install them without a compelling reason, and I only analyze them for indications of what's coming in the release. Once there's a release, it's no longer a moving target, and I'll see what I can do with it. This is no different; I only patched this beta because further progress was impeded without such a patch. (I still haven't installed 12.1b1 here, and probably won't.)

So, long story short: replacing the RDRAND instructions with some other randomization would probably be better than using a constant, but likely involves great difficulty to do so, and may not really be necessary. I'll ponder it, but I don't expect to spend much time on details until an official release is imminent (again, to avoid wasting time on moving targets that change from week to week - for all we know, these RDRANDs will be gone in 12.1b2).

---

While I have the floor, please forgive a brief digression/non sequitur. Feel free to ignore the rest of this post.

On and off this site (but thankfully not on this thread), I've seen some sensationalistic posts promoting an alarmist view - that Apple is adding things like RDRAND explicitly to prevent old Macs from running Monterey+, possibly even in direct response to threads like this one, and they're effectively "out to get us." I disagree.

I have seen no evidence that Apple is actively trying to prevent classic Macs from running new versions of MacOS. What I do see is Apple's developers' indifference to the old systems, and their willingness to adopt new features from the oldest supported platforms. When they started using SSE4.1 instructions in MacOS, it wasn't to explicitly "kill off" the first two generations of Mac Pros, it was because SSE4.1 offered performance advantages, and every officially supported platform at that time had SSE4.1. It's unreasonable to expect Apple to jump through hoops (including avoiding use of newer technologies) to support old technologies when they have no reason to do so. We're lucky to have gotten this far with as few problems as we've encountered. Apple will almost certainly continue to expand the use of newer instructions when they're advantageous, and we'll either adapt or reach a point where it's no longer practical to do so (case in point: Mac Pro 1,1/2,1).

Apple could easily make it impossible to install Monterey on classic Macs. They don't bother wasting even minuscule resources on that because they don't have to. In 2020, Apple sold an estimated 22.5 million new Macs. The active "unsupported Mac" community ("active" meaning "trying to keep installing new MacOS versions," not "still running Mavericks on my trusty MP3,1") probably numbers less than ten thousand - that's 0.04% of their annual sales, and that estimate is probably high. We are not a "thorn in Apple's side," we are not "a force to be reckoned with," we are probably not on Apple's radar in any meaningful way at all. Apple is not interested in expending resources to curtail using Big Sur or Monterey on our old cheesegraters, they have bigger fish to fry. Instead, they want to optimize the performance of MacOS on the Macs they're still supporting, and if that means using instructions that didn't exist when our old systems were built, why not? The problems our old Macs encounter aren't there because Apple is throwing up roadblocks, it's because they don't care about the consequences for old Macs at all.

In short, please don't propagate dire warnings that Apple is actively trying to prevent us from moving forward with our old Macs, or that they're directly responding to what we're doing here. Without actual evidence, that's just clickbait. Our classic Macs' days are definitely numbered - not because Apple's "out to get us," but simply because our old Macs are old. (You don't see 8-track tape enthusiasts suggesting that Big Music is out to get them; technology has simply passed them by. We're on the same road, just moving a lot slower, and some of us are trying to tap the brakes to prolong the journey a bit. The end of the road is still somewhere out there, though.)

(Sorry for the rant, but that's been bothering me for a while. Please enjoy the rest of your day!)

I think most of us users of old macs agree with you. We all should know that reason macs are so great is the willingness to leave the old behind. It is the major difference between Microsoft and Apple. In the future when I see people promoting that Apple is as you put it “out to get us” I will share a link to this. Bravo!

 

[Ausdauersportler]

Successfully tested on

- iMac11,3 (27" Mid 2010) with RX480 mobile GPU and
- iMac11,1 (27" Late 2009) with R9 280X mobile GPU
- iMac12,2 (27" Mid 2011) with WX7100 mobile GPU

all using OCLP 0.3.2 RDRAND edition - the casino has been reopened!

 

[khronokernel]

@Syncretic Was not expecting to make this report, but RDRAND was stripped from 12.1 Beta 2's kernel seeded today. Your patch no longer applies, however multiple systems have been verified to boot without issue on Beta 2

Dropping a kernel here, bit busy today so can't throw it in IDA right now.

 

[avro707]

So far I’ve not been able to get any Monterey going on the 11.6.1 machine in my signature.

I get stuck in a boot loop if I try to install. If someone has a verified PLIST that works (I’m using Martin Lo’s 0.7.5) then I’d certainly like to give that a go with the latest beta which does show up available on that machine.

 

[h9826790]

So far I’ve not been able to get any Monterey going on the 11.6.1 machine in my signature.

I get stuck in a boot loop if I try to install. If someone has a verified PLIST that works (I’m using Martin Lo’s 0.7.5) then I’d certainly like to give that a go with the latest beta which does show up available on that machine.

Please make sure you do this if you want to install Monterey.

And then revert the config back to default after Monterey installed.

 

[vsc]

So far I’ve not been able to get any Monterey going on the 11.6.1 machine in my signature.

I get stuck in a boot loop if I try to install. If someone has a verified PLIST that works (I’m using Martin Lo’s 0.7.5) then I’d certainly like to give that a go with the latest beta which does show up available on that machine.

I installed 12.0.1 with 0.7.5beta without any issue though I ensured support for a TB card was not enabled until after the install completed, where today I a have 0.7.5 (no beta) in the EFI partition. Notable is I started with 11.6.1 on the MacPro. My hardware configuration is very similar where my SSD is NVMe from OWC.

Additionally I did follow the video cited above.

 

[14dcutaneo]

I installed 12.0.1 with 0.7.5beta without any issue though I ensured support for a TB card was not enabled until after the install completed, where today I a have 0.7.5 (no beta) in the EFI partition. Notable is I started with 11.6.1 on the MacPro. My hardware configuration is very similar where my SSD is NVMe from OWC.

Additionally I did follow the video cited above.

This thread is for discussing RDRAND bypass with MonteRand on Monterey 12.1+. This is not your Opencore support thread. Please ask your questions in either of the appropriate threads.

OpenCore on the Mac Pro

This guide explains how to use the excellent OpenCore boot loader to install, run, and update the latest version of macOS on the MacPro5,1, resulting in a clean, unaltered operating system just like on a supported Mac.

forums.macrumors.com

Thread specific to Martin’s package: https://forums.macrumors.com/threads/activate-amd-hardware-acceleration.2180095/page-123

 

[vsc]

This thread is for discussing RDRAND bypass with MonteRand on Monterey 12.1+. This is not your Opencore support thread. Please ask your questions in either of the appropriate threads.

OpenCore on the Mac Pro

This guide explains how to use the excellent OpenCore boot loader to install, run, and update the latest version of macOS on the MacPro5,1, resulting in a clean, unaltered operating system just like on a supported Mac.

forums.macrumors.com

Thread specific to Martin’s package: https://forums.macrumors.com/threads/activate-amd-hardware-acceleration.2180095/page-123

I blindly responded not paying attention to the thread. My thanks for being the police on this thread.

 

[Enricote]

I can confirm my successful experience updating my cMacPro 4,1>5,1 to Monterey 12.1 Beta (21C5031d). I am still using the experimental OCLP 0.3.2 Nightly RDRAND Opencore Patcher.
Completely normal process using OTA update

 

[Nekapsule]

I just upgraded my X5675 Hackintosh to 12.1 Beta 2 while keeping MonteRand enabled. It worked but after the update process finished and the login screen appeared, I got this:

I disabled MonteRand, rebooted, and the warning did not re-appear.
Maybe a fluke, or maybe MonteRand breaks hash checks in 12.1 Beta 2?

Curious to get reports from others with MonteRand enabled when booting 12.1 Beta 2.

 

[Syncretic]

@Syncretic Was not expecting to make this report, but RDRAND was stripped from 12.1 Beta 2's kernel seeded today. Your patch no longer applies, however multiple systems have been verified to boot without issue on Beta 2

Dropping a kernel here, bit busy today so can't throw it in IDA right now.

I'll ponder it, but I don't expect to spend much time on details until an official release is imminent (again, to avoid wasting time on moving targets that change from week to week - for all we know, these RDRANDs will be gone in 12.1b2).

I just upgraded my X5675 Hackintosh to 12.1 Beta 2 while keeping MonteRand enabled. It worked but after the update process finished and the login screen appeared, I got this:

View attachment 1907808
I disabled MonteRand, rebooted, and the warning did not re-appear.
Maybe a fluke, or maybe MonteRand breaks hash checks in 12.1 Beta 2?

Curious to get reports from others with MonteRand enabled when booting 12.1 Beta 2.

The code patterns that MonteRand is looking for do not exist in 12.1b2, so the patches are never applied, meaning they will have no effect on your system whether they're enabled or not. The error you saw is not related to MonteRand.

How is RDRAND different from the instructions that AAAMouSSE.kext emulates? Can't it be emulated the same way? I understand the kernel loads earlier than kexts, so you'll need a different method to setup the instruction emulation.

Can you setup instruction emulation in an EFI driver? Does that setup survive transferring control to the kernel from boot.efi?

Assuming RDRAND remains an issue (even intermittently), any solution along these lines will require changes to OpenCore. RDRAND is easily emulated; however, for any #UD handler to work, some initialization code needs to run very early in the boot process (since the RDRANDs in question occur so early). Any kext-based solution is dependent on that particular kext being initialized before the RDRAND instructions occur, which presents another race condition. It's possible to create an EFI Runtime Service that would survive the transfer of control to the kernel, but getting that hooked into the #UD vector such that the kernel doesn't simply override it is tricky at best, and would require assistance from OpenCore to calculate addresses, look up symbols, etc. Realistically, it's probably too messy to attempt.

An imperfect but arguably reasonable solution would be to add functionality to the OpenCore patching mechanism, allowing an automated version of what @cdf proposed. Currently, both Find and Replace have masks available (Mask and ReplaceMask, respectively); adding another mask (which I'll call RandMask here) could instruct the patcher to randomize any bits set to 1 in that mask. So, for example (using hex instead of Base64, for clarity), we might use something like:

<key>Find</key>
<data>0f c7 f2 73 fb</data> // rdrandl %edx; jae -5
<key>Replace</key>
<data>ba 00 00 00 00</data> // movl $0x00000000,%edx
<key>RandMask</key>
<data>00 ff ff ff ff</data> // randomize last 4 bytes of the replacement

This would result in a unique value being loaded for each boot sequence, which is better than every boot being identical. It does not, however, address the fact that multiple calls to that randomizer will always return the same value (until the system is rebooted). Still, it's better than a simple constant.

 

[avro707]

Please make sure you do this if you want to install Monterey.
.......
And then revert the config back to default after Monterey installed.

You are a genius! All the other methods I tried, none worked. Your method was perfect first go with Monterey 12.1 beta (21C5031d)

Installed and working. Thank you! ? PLIST is swapped back after install and everything appears to be good.

I used that machine for nearly 2 hours of Zwift tonight and all perfect, not a single glitch.

 

[avro707]

This 0.7.5 package with 12.1b2 is working on my more powerful MP5,1 (128GB machine) but with an interesting quirk.

The OC was on EFI contained on a Samsung 870EVO SSD which also had my old Big Sur 11.2.3 (which I don't use anymore). When going into Monterey 12.1 beta 2 after the update finished, that was not visible anymore although the computer clearly used it for the OC.

I grabbed all the files from the EFI on the single processor Mac Pro and put them on the EFI on the drive where Monterey is installed and blessed OC then took out the 870 Evo drive. Seems to be working fine.

 

[Nekapsule]

12.1b3 has just been released, does anyone know if it runs without MonteRand like Beta 2?