High Sierra booting possibly corrupts newer Systems. Fix, description and a boot picker renamer

[Macschrauber]

Summary:

We discovered a serious bug: booting High Sierra without System Integrity Protection (csrutil disable) possibly corrupts another mounted (unsupported) APFS2* OS Preboot volume, even when on another drive. Consequently, the corrupted OS may appear as High Sierra and check for compatibility with Board IDs compatible with High Sierra, possibly prevents booting. I've created a tool to address this problem.

This is a follow-up by the writings a while ago in another thread: https://forums.macrumors.com/thread....2207814/page-500?post=31995153#post-31995153

Spoiler: Screenshots of the issue

Ventura with High Sierra icon and data volume name

Try to boot the newer OS with High Sierra's PlatformSupport.plist got prevented because Board ID of Mac Pro7,1 is missing

The problem:

Booting High Sierra (natively) and having APFS2 Volume(s) in the machine could possibly replace SystemVersion.plist and PlatformSupport.plist in the Proboot volume of another mounted APFS2 OS with its own outdated version.

Also, the .contentDetails and .disk_label* files, which stores the name the BootPicker and OpenCore displays for the System name, could be renamed to the data volume name of the OS. If the Data Disk name for this system is 'Ventura - Data', High Sierra could have set the name for the System to 'Ventura - Data.'

Where the latter is just cosmetic, the no more matching board ID in PlatformSupport.plist could make the system non-bootable.

Also we found that it replaces 3 .im4 files for Macs with T2 chip.


The effect:

The following example details is for a Mac Pro 5,1: A wrong PlatformSupport.plist file of High Sierra gives a prohibited sign, or in verbose mode, the message for an unsupported board ID of a Mac Pro 7,1 Mac-27AD2F918AE68F61 if this machine is spoofed. And shuts down hard after 30 seconds.

If we set the boot-arg -no_compat_check in OpenCore's config.plist, the OS ignores these issues and boots.

A wrong SystemVersion.plist file of High Sierra gives a High Sierra icon in the OpenCore boot menu (which is just cosmetic) but could prevent the OS from updating or installing an OS reading the wrong High Sierra version 10.13.x.


The cure:

Replacing SystemVersion.plist, PlatformSupport.plist and the .im4 files with the proper versions. They are also stored in the CoreServices folder of the System volume and in the i386 folder of the Preboot volume.

So we replace the Preboot files with the proper files, and the situation is fixed. If the OS cannot boot anymore because of the missing Board ID (prohibition sign or Board ID message), we need to either boot another APFS2 capable OS, mount the System volume, and replace the files or add the boot-arg:
-no_compat_check to the OpenCore config.plist.

Spoiler: Screenshots of the cure

1 Ventura SystemVersion_plist mismatch

2 found High Sierra SystemVersion.plist in Ventura Preboot

3 fix SystemVersion.plist ?

4 fixed SystemVersion.plist

... same for PlatformSupport.plist ...

5 the report when the tool is done

6 .contentDetails fix

7 .contentDetails fixed

8 a second run of Preboot fixer

9 Ventura icon and System name are back

The tool:

Preboot fixer and renamer checks all Preboot folders for matching SystemVersion / PlatformSupport plists and .im4 files and asks for replacing them if they don't match.

If it is started on an APFS1 OS (late versions of Sierra, High Sierra, Mojave), it cannot mount the APFS2 System volume to read the original plists. However, it alarms if it finds High Sierra SystemVersion.plist files in APFS2 Preboots.

The wrong .contentDetails and the .disk_label* icon drawn by the native Apple boot picker can be rebuilt by the tool as well.

You can edit the names and icons with the tool as well, even with multiple lines by entering option-return for a new line.
This is the button <proceed with label editor>. Thanks to @joevt for all the help and providing the bash functions for it.

the names in the boot picker could be renamed by the preboot fixer and renamer tool
The @joevt multiline names are ESPs, there is also a tool for renaming ESPs in the Dumper package​

Maybe a possible exorcism:

you can try to update the date of High Sierra's SystemVersion.plist
This needs more testing but it seems it helps, preventing High Sierra from replacing files in newer System's Preboots.
Boot High Sierra and do this in Terminal

sudo touch -t 203009110327 /System/Library/CoreServices/SystemVersion.plist
sudo touch -t 203009042358 /System/Library/CoreServices/PlatformSupport.plist

*

APFS1: APFS Systems with one volume​

APFS2: APFS Systems with a separated system and data volume​

Changelog:

3-1-2024: first release
5-1-2024: fixed a glitch where unmouted APFS1 System Volumes would give false alarm. Confusing and cosmetical, nothing get harmed. Changed the text from Comparing to the System Volume is not possible on this OS to Can not compare (System Volume not mounted) as an unmounted APFS1 System Volume is giving the same status as a APFS2 System Volume what could not be mounted on old APFS1 OS.
21-1-2024: first final release, as part of the Dumper package.


I placed the tools in my firmware dumper package to ease administration. They can be found in the Readme & other tools folder.
Using the Dumper to check and backup the bootrom is a good practice for all Macs, but that's another topic ;-)


downloader for the package (disk image password is: rom):
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1


or on Github:

Macschrauber-s-Rom-Dump/Rename_and_repair_preboot.md at main · Macschrauber/Macschrauber-s-Rom-Dump

A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4.1 / 5.1 - Macschrauber/Macschrauber-s-Rom-Dump

github.com

GitHub - Macschrauber/Macschrauber-s-Rom-Dump: A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4.1 / 5.1

A tool for dumping and analysing Mac firmwares. Plus flashing for Mac Pro 4.1 / 5.1 - Macschrauber/Macschrauber-s-Rom-Dump

github.com

link to the Dumper post:

Healthy NVRAM normal behaviour on 4,1->5,1 machines

Macschrauber's Rom Dump I needed to encrypt the disk image as DropBox has flagged it for containing Flashrom. The password is rom. What's new in the latest versions: Update from 20-2-2024 -> checking Fsys for missing items or wrong order sometimes they get into the wrong order or items...

forums.macrumors.com

 

[Macschrauber]

I tested the csr configuration OCLP makes and this configuration prevents High Sierra to change other OS' Preboot volumes:

$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).

Configuration:
    Apple Internal: disabled
    Kext Signing: disabled
    Filesystem Protections: disabled
    Debugging Restrictions: enabled
    DTrace Restrictions: enabled
    NVRAM Protections: disabled
    BaseSystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Booting High Sierra with s.i.p. completely off, by setting crsrutil disable in High Sierra Recovery, let High Sierra change other OS' Preboot volumes.

In my example this was just Ventura, I have other examples where it wrote in various other OS. Also I got reports from other users.

And also one report of someone using Sonoma, attaching a machine with Ventura in TDM mode got his Ventura Preboot config files corrupted.



I don't know exactly, yet, what exact csr setting let High Sierra write into other Preboots. I tried setting BaseSystem alone, but that is not the culprit.

Maybe you guys will test a bit more. But remember, setting -no_compat_check to OpenCore's config.plist to don't lock yourself out.






finding boot-args in opencore config.plist

adding -no_compat_check

 

[Macschrauber]

This post is for additional tests.

I read out csr-active-config what High Sierra's Recovery OS sets: 0x77 WAAAA==

This is the setting the Preboot got corrupted. Now on another container, this time it was Big Sur. Same machine and drives.

I booted Monterey, Big Sur was not booted a while.

The csr-active-config from where the Preboot got NOT corrupted is (set by OCLP):
0x843 QWG=

 

[joevt]

The problem:

Booting High Sierra (natively) and having APFS2 Volume(s) in the machine could possibly replace SystemVersion.plist and PlatformConfig.plist in the Proboot volume of another mounted APFS2 OS with its own outdated version.

Also, the .contentDetails file, which possibly stores the name the BootPicker and OpenCore displays for the System name, could be renamed to the data volume name of the OS. If the Data Disk name for this system is 'Ventura - Data', it should be set to 'Ventura - Data.'

Where the latter is just cosmetic, the wrong plist files could make the system non-bootable.

I had a look at my iMac14,2 (27 inch, Late 2013) which runs OCLP and contains High Sierra. It appears that all macOS versions starting from Big Sur are affected by High Sierra, probably because Big Sur is the first to have snapshots which High Sierra doesn't understand? Catalina appears to be unaffected.

My High Sierra is on a HFS+ partition, not APFS.

Since you said High Sierra is replacing the plist files, I had a look at the modification dates of those plist files and the other files.
The plist files have modification date 2020 which matches High Sierra 11.3.6.
They have data added Dec 31, 2023 which is probably the last time I booted High Sierra. The 100+ files were modified between minute 12 and 19 of the last hour of the year.

Actually there's some modified Catalina Preboot files. I guess the SystemVersion.plist has the correct version because High Sierra can read the Catalina System volume?

Actually, those changes on that date are for Ventura and Catalina. Big Sur and Monterey where changed on Nov 5. Maybe I booted Ventura on Dec 31.

I should boot High Sierra again to verify or check the logs for last boot date on each system...

A Mac file has 4 or 5 or 6 dates. The stat command shows 4 dates. The Finder has 4 dates but it's not the same set. The touch command can change some dates and could be used to see what dates from stat correspond with what dates from the Finder. The Catalina Preboot has inode change time Dec 31, 2023 for some files. This date is not shown in the Finder.

 

[K two]

To sum it up, running OCLP and High Sierra on the same Mac can be a problem? 🤷‍♂️

 

[joevt]

To sum it up, running OCLP and High Sierra on the same Mac can be a problem? 🤷‍♂️

More like using High Sierra on a Mac that has newer macOS versions (those that are on APFS volumes).
I don't think OCLP has anything to do with it except for maybe changing SIP from the default value?

 

[Macschrauber]

More like using High Sierra on a Mac that has newer macOS versions (those that are on APFS volumes).
I don't think OCLP has anything to do with it except for maybe changing SIP from the default value?

With that csr-active-config 0x843 (I added CSR_ALLOW_UNRESTRICTED_NVRAM), what OCLP sets the plists* do not get changed:

CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE
CSR_ALLOW_UNAPPROVED_KEXTS
CSR_ALLOW_ANY_RECOVERY_OS
CSR_ALLOW_DEVICE_CONFIGURATION
CSR_ALLOW_UNRESTRICTED_NVRAM
CSR_ALLOW_UNRESTRICTED_DTRACE
CSR_ALLOW_APPLE_INTERNAL
CSR_ALLOW_KERNEL_DEBUGGER
CSR_ALLOW_TASK_FOR_PID
CSR_ALLOW_UNRESTRICTED_FS
CSR_ALLOW_UNTRUSTED_KEXTS

with 0x77, what High Sierra und Mojave sets when doing csrutil disable
The SystemVersion and PlatformSupport plists were replaced by the High Sierra ones.

CSR_ALLOW_UNRESTRICTED_NVRAM
CSR_ALLOW_UNRESTRICTED_DTRACE
CSR_ALLOW_APPLE_INTERNAL
CSR_ALLOW_TASK_FOR_PID
CSR_ALLOW_UNRESTRICTED_FS
CSR_ALLOW_UNTRUSTED_KEXTS

I wanted to trigger that again, I booted 2 times High Sierra with csr-active-config 0x77 but could not get the plists replaced.

After that I booted Monterey and got Big Sur plists replaced.

Repaired that, booted Mojave, set 0x77, booted Monterey and no plists were replaced.

Just thinking, what about the APFS2 OS or OC do that when a High Sierra Drive is in the machine?


I added comments to SystemVersion.plist of both, High Sierra OS and Preboot, to separate those two. Modification time is same. Just to see what of those both is copied. But could not yet trigger the situation.

Guess I run OC in 0x77 a while with the High Sierra drive in the box to see if booting or having High Sierra in the box is the problem.

Edit: changed the OpenCore config to csr-active-config 0x77 (like csrutil disable), getting it into a not fully working condition, as expected, but it booted Monterey without the root patches. Anyway, even after various boots of Monterey the plists were not changed. I do NOT booted High Sierra in that test row.


For the not too much tech savy: The problem is the content of the configuration files (* to shorten it I call it plists), not the date. The dates are a good data point to investigate, tho.

 

[joevt]

The dates indicate that more than the plist files are affected in the Preboot volumes. I reinstalled Big Sur, Monterey, Ventura, and Sonoma (not clean install though - just an update mostly - all except Sonoma which is a new install). This restores the Recovery and Preboot volumes and removes the High Sierra modifications. I'll backup the Preboot and Recovery volumes (just duplicate the UUID folders) than see what gets changed.

In the case of Catalina, the Preboot volume has two UUID folders - one for the System volume and one for the Data volume.
I believe Catalina uses the System volume's UUID for the Recovery and Preboot UUID folders. Big Sur and later use the Data volume's UUID for their Preboot and Recovery UUID folders.

It appears that the Data Volume UUID for Catalina was created by High Sierra. High Sierra doesn't know what a System or Data volume is, so it created a UUID folder for all volumes that are not Preboot, Recovery, and whatever else High Sierra knows about?

Since Big Sur and later macOS versions use the data volume's UUID, and High Sierra doesn't know what a data volume is but it can read the data volumes, it updates the existing data volume UUID folder in the Preboot volume. High Sierra can't read the system volumes for Big Sur and later, so it doesn't create a UUID folder for the system volume?

The Catalina Preboot data volume UUID folder contains only these files:

./Library/Preferences/SystemConfiguration/com.apple.Boot.plist
./System/Library/CoreServices/.contentDetails
./System/Library/CoreServices/.disk_label
./System/Library/CoreServices/.disk_label_2x
./System/Library/CoreServices/.root_uuid
./System/Library/CoreServices/PlatformSupport.plist
./System/Library/CoreServices/SystemVersion.plist
./System/Library/CoreServices/boot.efi.j132ap.im4m
./System/Library/CoreServices/boot.efi.j137ap.im4m
./System/Library/CoreServices/boot.efi.j680ap.im4m
./usr/standalone/i386/EfiLoginUI/Lucida13.efires
./usr/standalone/i386/EfiLoginUI/Lucida13White.efires
./usr/standalone/i386/EfiLoginUI/appleLogo.efires
./usr/standalone/i386/EfiLoginUI/battery.efires
./usr/standalone/i386/EfiLoginUI/disk_passwordUI.efires
./usr/standalone/i386/EfiLoginUI/flag_picker.efires
./usr/standalone/i386/EfiLoginUI/guest_userUI.efires
./usr/standalone/i386/EfiLoginUI/loginui.efires
./usr/standalone/i386/EfiLoginUI/recoveryUI.efires
./usr/standalone/i386/EfiLoginUI/recovery_user.efires
./usr/standalone/i386/EfiLoginUI/sound.efires
./usr/standalone/i386/EfiLoginUI/unknown_userUI.efires

which is not enough for booting. Perhaps this is the list of files that High Sierra adds to all the Preboot volumes? Perhaps High Sierra is performing an update for the three Mac hardware models that would use the j132ap, j137ap, or j680ap version of boot.efi? (secure boot stuff so probably Macs with T2 chip?).

For the Recovery volume, Catalina has an empty folder with the Data UUID. I delete the Data UUID folders for Catalina's Preboot and Recovery volumes. I guess it wouldn't hurt to leave them.

In Sonoma, I have to use sudo to make modifications to the Preboot and Recovery volumes. I think this is different from previous macOS versions?

 

[Macschrauber]

The dates indicate that more than the plist files are affected in the Preboot volumes. I reinstalled Big Sur, Monterey, Ventura, and Sonoma (not clean install though - just an update mostly - all except Sonoma which is a new install). This restores the Recovery and Preboot volumes and removes the High Sierra modifications. I'll backup the Preboot and Recovery volumes (just duplicate the UUID folders) than see what gets changed.

In the case of Catalina, the Preboot volume has two UUID folders - one for the System volume and one for the Data volume.
I believe Catalina uses the System volume's UUID for the Recovery and Preboot UUID folders. Big Sur and later use the Data volume's UUID for their Preboot and Recovery UUID folders.

It appears that the Data Volume UUID for Catalina was created by High Sierra. High Sierra doesn't know what a System or Data volume is, so it created a UUID folder for all volumes that are not Preboot, Recovery, and whatever else High Sierra knows about?

Since Big Sur and later macOS versions use the data volume's UUID, and High Sierra doesn't know what a data volume is but it can read the data volumes, it updates the existing data volume UUID folder in the Preboot volume. High Sierra can't read the system volumes for Big Sur and later, so it doesn't create a UUID folder for the system volume?

The Catalina Preboot data volume UUID folder contains only these files:

./Library/Preferences/SystemConfiguration/com.apple.Boot.plist
./System/Library/CoreServices/.contentDetails
./System/Library/CoreServices/.disk_label
./System/Library/CoreServices/.disk_label_2x
./System/Library/CoreServices/.root_uuid
./System/Library/CoreServices/PlatformSupport.plist
./System/Library/CoreServices/SystemVersion.plist
./System/Library/CoreServices/boot.efi.j132ap.im4m
./System/Library/CoreServices/boot.efi.j137ap.im4m
./System/Library/CoreServices/boot.efi.j680ap.im4m
./usr/standalone/i386/EfiLoginUI/Lucida13.efires
./usr/standalone/i386/EfiLoginUI/Lucida13White.efires
./usr/standalone/i386/EfiLoginUI/appleLogo.efires
./usr/standalone/i386/EfiLoginUI/battery.efires
./usr/standalone/i386/EfiLoginUI/disk_passwordUI.efires
./usr/standalone/i386/EfiLoginUI/flag_picker.efires
./usr/standalone/i386/EfiLoginUI/guest_userUI.efires
./usr/standalone/i386/EfiLoginUI/loginui.efires
./usr/standalone/i386/EfiLoginUI/recoveryUI.efires
./usr/standalone/i386/EfiLoginUI/recovery_user.efires
./usr/standalone/i386/EfiLoginUI/sound.efires
./usr/standalone/i386/EfiLoginUI/unknown_userUI.efires

which is not enough for booting. Perhaps this is the list of files that High Sierra adds to all the Preboot volumes? Perhaps High Sierra is performing an update for the three Mac hardware models that would use the j132ap, j137ap, or j680ap version of boot.efi? (secure boot stuff so probably Macs with T2 chip?).

For the Recovery volume, Catalina has an empty folder with the Data UUID. I delete the Data UUID folders for Catalina's Preboot and Recovery volumes. I guess it wouldn't hurt to leave them.

In Sonoma, I have to use sudo to make modifications to the Preboot and Recovery volumes. I think this is different from previous macOS versions?

I have no Catalina installation here, will add it to the tests as soon I get one.

Interesting details. I was surprised I could mount the Preboot volumes without su privs.

Copy back the SystemVersion und PlatformSupport plists from System volume to Preboot needed.

As your High Sierra OS is HFS+ I can stop investigate what plists are copied as HFS+ has no Preboot, I am pretty sure.

 

[joevt]

sudo find /Volumes/HighSierra -name 'boot.efi*'
finds results in
/Volumes/HighSierra/System/Library/CoreServices
and
/Volumes/HighSierra/usr/standalone/i386

The latter also has the EfiLoginUI folder.

I wonder if we can just erase standalone since High Sierra will never get another update from Apple.

standalone/bootcaches.plist looks interesting. Is it instructions that tell High Sierra how to mess up the Preboot volumes?

grepping for a binary that loads bootcaches.plist...

 

[Macschrauber]

Quickly installed DosDude Catalina,

The Preboot fixer works same way as with High Sierra and Mojave, could not mount the later other OS APFS System Volumes.

Catalina does not detect APFS2 System Volumes, same as with the earlier OS:

diskutil list disk1
/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Monterey - Daten        11.9 GB    disk1s1
   2:                APFS Volume Preboot                 10.8 GB    disk1s2
   3:                APFS Volume Recovery                4.1 GB     disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4
   5:                APFS Volume                         16.0 GB    disk1s5
   6:                APFS Volume Update                  12.2 MB    disk1s6
   7:                APFS Volume                         11.0 GB    disk1s7
   8:                APFS Volume Ventura - Data          20.4 GB    disk1s8
   9:                APFS Volume                         11.4 GB    disk1s9
  10:                APFS Volume Sonoma_Blade - Data     5.5 GB     disk1s10
  11:                APFS Volume Big Sur - Daten         2.8 GB     disk1s11
  12:                APFS Volume                         15.3 GB    disk1s12
mac@Macs-Mac-Pro ~ % diskutil apfs list disk1s5
disk1s5 is not an APFS Container

Preboot fixer log on Catalina:

Ventura Data's Preboot is: [13.6.3]
Comparing to the System Volume is not possible on this OS

Sonoma_Blade Data's Preboot is: [14.0]
Comparing to the System Volume is not possible on this OS

Big Sur Daten's Preboot is: [11.7.10]
Comparing to the System Volume is not possible on this OS

Monterey Daten's Preboot is: [12.7.2]
Comparing to the System Volume is not possible on this OS

Mojave SSD [10.14.6] SystemVersion.plist ok
Mojave SSD [10.14.6] PlatformSupport.plist ok

Catalina [10.15.7] SystemVersion.plist ok
Catalina [10.15.7] PlatformSupport.plist ok

High Sierra SSD [10.13.6] SystemVersion.plist ok
High Sierra SSD [10.13.6] PlatformSupport.plist ok

Sonoma Data's Preboot is: [14.0]
Comparing to the System Volume is not possible on this OS

Monterey 12.7.1 Data's Preboot is: [12.7.2]
Comparing to the System Volume is not possible on this OS

Ventura Data's Preboot is: [13.5]
Comparing to the System Volume is not possible on this OS

Monterey Data's Preboot is: [12.6.5]
Comparing to the System Volume is not possible on this OS

anyway it warns if those APFS2 Preboot Volumes contain 10.13 as System Version, tho it can not fix it in High Sierra, Mojave and Catalina.

Don't prevents one to make backups of SystemVersion.plist and PlatformSupport.plist in those Preboot volumes.

Maybe I add scanning for files SystemVersion.bak and PlatformSupport.bak. Or even making those .bak files if verified matching. But I dont like it too much modifying user's OS.

 

[joevt]

Found bootcaches.plist in a few places:

sudo grep -R --exclude-dir '*/private/*' --exclude-dir '*/Users/*' --exclude-dir '*/.*' bootcaches.plist /Volumes/HighSierra
Password:
grep: /Volumes/HighSierra/.dbfseventsd: Operation not supported on socket
Binary file /Volumes/HighSierra/Library/Application Support/SoftRAID/SoftRAIDTool matches
Binary file /Volumes/HighSierra/System/Library/CoreServices/backupd.bundle/Contents/Resources/brtool matches
Binary file /Volumes/HighSierra/System/Library/PreferencePanes/StartupDisk.prefPane/Contents/MacOS/StartupDisk matches
Binary file /Volumes/HighSierra/System/Library/PrivateFrameworks/StorageKit.framework/Versions/A/Resources/storagekitd matches
Binary file /Volumes/HighSierra/System/Library/Receipts/com.apple.pkg.Core.bom matches
Binary file /Volumes/HighSierra/usr/bin/kextutil matches
Binary file /Volumes/HighSierra/usr/libexec/diskmanagementd matches
Binary file /Volumes/HighSierra/usr/libexec/kextd matches
Binary file /Volumes/HighSierra/usr/sbin/kextcache matches
/Volumes/HighSierra/usr/share/man/man8/kextcache.8:.Ar os_volume Ns Pa /usr/standalone/bootcaches.plist ,
/Volumes/HighSierra/usr/share/man/man8/kextcache.8:.Ar os_volume Ns Pa /usr/standalone/bootcaches.plist
/Volumes/HighSierra/usr/share/man/man8/kextcache.8:.Pa bootcaches.plist
/Volumes/HighSierra/usr/share/man/man8/kextcache.8:.It Pa /usr/standalone/bootcaches.plist
/Volumes/HighSierra/usr/share/man/man8/kextd.8:.It Pa /usr/standalone/bootcaches.plist
joevt@Joes-Giga-Mac ~ % man kextcache
joevt@Joes-Giga-Mac ~ % man /Volumes/HighSierra/usr/share/man/man8/kextd.8

Can examine the man pages like this:

man /Volumes/HighSierra/usr/share/man/man8/kextcache.8
man /Volumes/HighSierra/usr/share/man/man8/kextd.8

Seems to suggest that maybe removing the bootcaches.plist file might make High Sierra not do the update? I'll probably just try renaming standalone. If it works, it would be more permanent that trying to mess with SIP.

 

[Macschrauber]

At the moment I cannot force HS to manipulate the plists. Thats not ideal to test the situation.

I tested the Fixer with all OS in a row, High Sierra, on its own Sata SSD was in a sled, installed in APFS, being the only OS on that SSD.

I booted every OS ( HS, Mojave, Catalina, Big Sur, Monterey, Ventura, Sonoma ) to test the Fixer with unmounted OS (the first release had a bug with unmounted volumes).

No OS did manipulate the plists. OCLP 1.3.0 booted Big Sur to Sonoma, HS and Mojave natively and Catalina was in the DosDude flavor.

My HS installation is unchanged. Guess the next steps is to scan the logs if HS logged copying / writing the plists.

edit: searched the logs in High Sierra for Preboot/ SystemVersion PlatformSupport etc etc -- sadly nothing. The logs contain the dates where that plists manipulation happend.

sudo log show --predicate "processID == 0" --debug | grep -i 'SystemVersion'

 

[Macschrauber]

I wondered why I can't force High Sierra to copy back its plists again.

What did I ?

-> I added a comment to SystemVersion.plist to distinguish Preboot and System folder.

This changed the modification date of that plist.

So I changed the modification date back to where it was, 11.Sep.2020, 3:27, exactly as the creation date - and bang, I got High Sierra copy back its SystemVersion.plist of the System folder, booting High Sierra natively. Could identified it by the comment.

This time to Catalina's Preboot folder.

Maybe the cure is that easy?

Change the modification time of the plists?

Well, why not, whoever wants to test that, try in High Sierra:

Edit: just touching did not worked, setting the modification date higher to 2030 seems to work.

sudo touch -t 203009110327 /System/Library/CoreServices/SystemVersion.plist
sudo touch -t 203009042358 /System/Library/CoreServices/PlatformSupport.plist

Is that enough to stop HS copying its plists to other APFS2 Preboot volumes when System Integrity Protection is fully disabled?

Needs more testing, of course.

 

[joevt]

I thought changing the standalone folder name might make High Sierra not modify Preboot volumes but it appears High Sierra makes the modifications anyway when you select restart in High Sierra.

I forgot to add -p to the cp -R command when backing up the Preboot and Recovery UUID folders so the dates and stuff weren't preserved. Maybe I should have used the Finder to duplicate the folders.

It appears that the modified files are these (using md5 to compare the files):

./System/Library/CoreServices/.contentDetails # didn't exist in the backup.
./System/Library/CoreServices/.disk_label
./System/Library/CoreServices/.disk_label_2x
./System/Library/CoreServices/PlatformSupport.plist
./System/Library/CoreServices/SystemVersion.plist
./System/Library/CoreServices/boot.efi.j132ap.im4m
./System/Library/CoreServices/boot.efi.j137ap.im4m
./System/Library/CoreServices/boot.efi.j680ap.im4m

And these:

 ./Library/Preferences/SystemConfiguration/com.apple.Boot.plist
./System/Library/CoreServices/.root_uuid

but com.apple.Boot.plist is usually the same for all macOS versions and .root_uuid doesn't change.

Changing boot.efi for j132ap, j137ap, j680ap might make those 3 Mac models not bootable? All other Macs should not have a problem (except for the cosmetic issues in OpenCore Picker). For my iMac and Hackintosh, OpenCore can boot macOS with the High Sierra modified Preboot volumes.

 

[Macschrauber]

I thought changing the standalone folder name might make High Sierra not modify Preboot volumes but it appears High Sierra makes the modifications anyway when you select restart in High Sierra.

I forgot to add -p to the cp -R command when backing up the Preboot and Recovery UUID folders so the dates and stuff weren't preserved. Maybe I should have used the Finder to duplicate the folders.

It appears that the modified files are these (using md5 to compare the files):

./System/Library/CoreServices/.contentDetails # didn't exist in the backup.
./System/Library/CoreServices/.disk_label
./System/Library/CoreServices/.disk_label_2x
./System/Library/CoreServices/PlatformSupport.plist
./System/Library/CoreServices/SystemVersion.plist
./System/Library/CoreServices/boot.efi.j132ap.im4m
./System/Library/CoreServices/boot.efi.j137ap.im4m
./System/Library/CoreServices/boot.efi.j680ap.im4m

And these:

 ./Library/Preferences/SystemConfiguration/com.apple.Boot.plist
./System/Library/CoreServices/.root_uuid

but com.apple.Boot.plist is usually the same for all macOS versions and .root_uuid doesn't change.

Changing boot.efi for j132ap, j137ap, j680ap might make those 3 Mac models not bootable? All other Macs should not have a problem (except for the cosmetic issues in OpenCore Picker). For my iMac and Hackintosh, OpenCore can boot macOS with the High Sierra modified Preboot volumes.

Do you found the Recovery was changed, too? Quickly scanned my Recoveries and SystemVersion.plist were unchanged.

The problem, with not booting, getting the forbidden sign is to the board ID.

If we spoof an MacPro 7,1 with the board ID Mac-27AD2F918AE68F61, to boot an unsupported OS and this board ID is not in the PlatformSupport.plist file no more (due to replacing with the HighSierra plist), it stops booting early.

What prevents this is the boot-arg -no_compat_check.

So this is the biggest part of the glitch, imo.

For the .im4m files: do we know what models are for 132, 137, 680?


compared the .im4m files:

almost every OS had these being replaced from High Sierra, did diff with boot.efi.j132ap.im4m and they are identical.




So copy the .im4m files back is the next thing the Fixer has to do. I am not sure if replacing the .disk_label files makes sense, as often people change them. Also the Rename Preboot script can adjust the name if needed.

 

[joevt]

Do you found the Recovery was changed, too? Quickly scanned my Recoveries and SystemVersion.plist were unchanged.

No changes in Recovery except maybe Catalina gets an empty Data UUID folder or maybe something else put that there.

The problem, with not booting, getting the forbidden sign is to the board ID.

If we spoof an MacPro 7,1 with the board ID Mac-27AD2F918AE68F61, to boot an unsupported OS and this board ID is not in the PlatformSupport.plist file no more (due to replacing with the HighSierra plist), it stops booting early.

What prevents this is the boot-arg -no_compat_check.

So this is the biggest part of the glitch, imo.

Oh right. The PlatformSupport.plist lists supported models and gets changed.

For the .im4m files: do we know what models are for 132, 137, 680?

There's a list at https://dortania.github.io/OpenCore-Post-Install/universal/security/applesecureboot.html
Apple T2 iMacPro1,1 (j137)
Apple T2 MacBookPro15,2 (j132)
Apple T2 MacBookPro15,1 (j680)

compared the .im4m files:

almost every OS had these being replaced from High Sierra, did diff with boot.efi.j132ap.im4m and they are identical.

So copy the .im4m files back is the next thing the Fixer has to do. I am not sure if replacing the .disk_label files makes sense, as often people change them. Also the Rename Preboot script can adjust the name if needed.

You can draw the .disk_label and ask the user if it looks ok. Either Open Core has a utility or you can use my convert_label command.

 

[Macschrauber]

about those .im4m files:

Seems these have to do with IOS devices: https://www.theiphonewiki.com/wiki/IMG4_File_Format

scanned them with a tool i found in Github: https://github.com/tihmstar/img4tool/
and it seems the files indeed differ in content:

% ./img4tool /Users//Desktop/i4m4\ files/from\ High\ Sierra/boot.efi.j132ap.im4m -a
img4tool version: 0.197-aca6cf005c94caf135023263cbb5c61a0081804f
Compiled with plist: YES
IM4M: ---------
Version: 0
MANB: MANB: ------------------------------
MANP: MANP: ------------------------------
BORD: BORD: 12
CEPO: CEPO: 2
CHIP: CHIP: 32786
SDOM: SDOM: 1
iuob: iuob: false
mpro: mpro: true
msec: msec: true
srvn: srvn: 8a608c6dec07c58df07a283d140c05380b3e9a52
xugs: xugs: 1

efbb: efbb: 
DGST: DGST: 4c518869acad60f71ead59593c3cea577181d38ddf7484ab6a6a0952fa72c86850c7a8030993dfd449c3f3fceea51b30
EKEY: EKEY: false
EPRO: EPRO: true
ESEC: ESEC: true

mkrn: mkrn: 
DGST: DGST: e585d0bdb538ac7088bbd5be9eea60703eca758bf26cea92699b9900e4fac0d16da548f4dee2fb9d52d53aa4eb9e77c4
EKEY: EKEY: false
EPRO: EPRO: true
ESEC: ESEC: true




% ./img4tool /Users//Desktop/i4m4\ files/from\ Monterey_Blade/boot.efi.j132ap.im4m -a
img4tool version: 0.197-aca6cf005c94caf135023263cbb5c61a0081804f
Compiled with plist: YES
IM4M: ---------
Version: 0
MANB: MANB: ------------------------------
MANP: MANP: ------------------------------
BORD: BORD: 12
CEPO: CEPO: 2
CHIP: CHIP: 32786
SDOM: SDOM: 1
mpro: mpro: true
msec: msec: true
srvn: srvn: 8647a2e6803bb553f54bfe608ff7a928e118a8b8
xugs: xugs: 1

efib: efib: 
DGST: DGST: 674e5fc97b8a9a9f05cef31034827c132d7cf76f2ae38c006fadf5d6b946fea79e0509a138462ae642ff6b553a472698
EPRO: EPRO: true
ESEC: ESEC: true

hpmu: hpmu: 
DGST: DGST: c990067b80f28e4f377691ad2bf2cab2153fb345a323f6d04ff79503d664485e9ed3db3160648baa3af4ae77b1522216
EPRO: EPRO: true
ESEC: ESEC: true

mkrn: mkrn: 
DGST: DGST: 0d8849b06c3bdde2dad16d50d1a0df8f4433e4e753913681df64536305194ace1549307df61152664905904321fa16b3
EPRO: EPRO: true
ESEC: ESEC: true

mupd: mupd: 
DGST: DGST: c5938bb01de9efd77d06dee4e45524b27b054ea3c0965d1cf382ae462994b7aadb81d042f1df910bb5acb70b9e5c47a9
EPRO: EPRO: true
ESEC: ESEC: true

thou: thou: 
DGST: DGST: e7e574376f4c9194aadbbb71451830c2ac3c502b8ee7e156e411607c529ec1b4d196fde4491015476bdaae44fa4a89e6
EPRO: EPRO: true
ESEC: ESEC: true

xbtc: xbtc: 
DGST: DGST: 8fc479646b505ba4c6a99faa3b4e00a801d4d755153ff8bd78f136ea422a12984f006a12fb9c335e8605cc32628e473c
EPRO: EPRO: true
ESEC: ESEC: true

xmtr: xmtr: 
DGST: DGST: bda5ea37abf6225011d37f3adf5f9ddd7bc5da6e3d1ff3f5c7bed1340aca8c4d419bd7015505eac239e9da11b7dc396e
EPRO: EPRO: true
ESEC: ESEC: true

xrtc: xrtc: 
DGST: DGST: 5d5b461386cb36fe16ecef8f995400418def1f97ec833b62c4dfadd353c32e3be7a632d2571184db45fad3deec4c4bcf
EPRO: EPRO: true
ESEC: ESEC: true

xstc: xstc: 
DGST: DGST: 4eb64470e631e3f9b9537984988e34c53d6d3ea459c3f29b96bb7cec860423d45a3bb552d4ab50f03b1a79be7cf3d026
EPRO: EPRO: true
ESEC: ESEC: true

xsys: xsys: 
DGST: DGST: a73f9af058b6a3bd130df884a0f27fac86e6ae48ae7b5de8e0383057f522f42cb324884b984f8c99a84eea1e537f65a6
EPRO: EPRO: true
ESEC: ESEC: true

 

[joevt]

about those .im4m files:

Seems these have to do with IOS devices: https://www.theiphonewiki.com/wiki/IMG4_File_Format

The iOS device in this case is the T2 chip.
https://www.theiphonewiki.com/wiki/T8012

 

[Macschrauber]

I added checking and replacing .im4m files to the Fixer where possible.

Luckily the .im4m files are present in the i386 folder of the Preboot volume in those OS what are affected by High Sierra files replacing.

So the cure for that files is easy scriptable.

I did not added it to the Dumper package as this is a work in progress.

If someone wants to test the Fixer at the current state I attach it to this post:

most likely you need to adjust the download security settings by xattr -cr ~/Downloads/Preboot\ Fixer.app


a screenshot:

 

[joevt]

I've attached screenshots.

Some suggestions:

- First 4 screenshots show a SystemVersion.plist DO NOT MATCH! window, then the Mismatching info, then the same DO NOT MATCH! window but with a Fix button, then a "will ask for password" window. These four windows can be combined into one. The sixth screenshot is the correct info. Perhaps this can be in the first window as well (use scrolling text for the before and after text).

- The next five screen shots are similar to the first 6 except these are for PlatformSupport.plist. The Mismatching info window isn't large enough to contain the entire text which makes me wonder if it's even necessary to display the text. A scrolling text box may be useful here. The "will ask for password" window is redundant because it uses the password from the first time.

- I'm not sure what's happening with the next set of fixes. It lists 3 mismatching im4m files, but then it shows 4 windows listing the path for 4 im4m files - the fourth is not one of those listed in the mismatching window. Maybe include more of the path of the folders containing the im4m files that you are comparing
Preboot usr/standalone/i386 and S*/L*/CoreServices

- Instead of 70 clicks, make it a couple clicks? First, list all the problems and corrections with a Fix All button. Then fix all the problems.

- For Catalina, if there's a System volume UUID folder that contains boot.efi and a Data volume UUID folder that doesn't contain boot.efi, then delete the Data volume UUID folder. Do similar for the Recovery volume.

- If the .contentDetails text ends with " - Data" and the System volume name doesn't match, then replace it and the .disk_label with a version that uses the System volume name. You can use the trick in my DiskUtil.sh script where I use bless to create the label on a mounted temporary disk image (to avoid any side effects of bless) and then copy the .disk_label files to the final destination.

 

[Macschrauber]

yes, I want to combine the user interaction to one window per OS.

It's rather raw, now.

Also the path dialog was a test output for file not found, forgot to remove.

I would like to have a scrollable dialog in AppleScript, but this is not available without extensions. In case you know a failsave method what is compatible for all the OS versions I would like to add it. Somewhere I limited display to x lines for dialog text, need to check that again.

Also I did not find a method to check if sudo is still cached. As each do shell script command in AppleScript has its own ID I can not detect if the next command uses the cached password.

Maybe just make a boolean if the dialog was presented the first time. I do want to explain why the user has to give an admin password, of course.

 

[startergo]

Also I did not find a method to check if sudo is still cached.

Maybe if you combine the request where passwords are needed in a loop like this?

how to prevent password prompt pops up many times

My code looks like: set sourceFolder1 to (path to library folder as text) & "Frameworks:SDL.framework" set sourceFolder2 to (path to library folder as text) & "Frameworks:SDL_ttf.framewo...

stackoverflow.com

 

[Macschrauber]

Maybe if you combine the request where passwords are needed in a loop like this?

how to prevent password prompt pops up many times

My code looks like: set sourceFolder1 to (path to library folder as text) & "Frameworks:SDL.framework" set sourceFolder2 to (path to library folder as text) & "Frameworks:SDL_ttf.framewo...

stackoverflow.com

well, I made some tests:

the sudo password is cached for about 3 minutes between two calls.

If I do a simple sudo script like whoami every 2 minutes to refresh, the cached time is about 6 minutes until a 2nd password dialog appears.

That is long enough for the script.

Collecting all the sudo commands is plan B. But I think not needed. And if, that's just a password dialog...

 

[Macschrauber]

I did another bleeding edge pre-version.

- gives just one dialog for telling the user why he has to enter his admin password. Also refresh the cache by a useless sudo command before each dialog to keep it in cache.

- condensed all those dialogs to one for each OS on APFS2 OS. If checking on an APFS1 OS like late Sierra to Mojave it could be more.

- moved the .log file to ~/Library/Logs/

- did more logging and more precise process bar information

SystemVersion.plist got a wrong year to test so it's reporting matching System Numbers, also I just manipulated one .im4m file to test

(xattr -cr /path/to/app may be needed if it says it is damaged)