Contribute
Register

Automatic SSDT/DSDT generation from ProBook Installer?

Status
Not open for further replies.
Maybe that is better, so if 10.8.4 brings changes it wont patch it... We can test it manually first... Either way does not change much, we will be looking what Apple does.

On the contrary, executed this way, the code will patch the kext, if its checksum is not equal to the checksum of the patched 10.8.2/10.8.3 kext. So, on 1O.8.4 this code will patch the kext, no mather if the patch is proper for this new kext or not. Maybe it will be proper to reverse the logic (to search for the md5 sum of the vanilla 10.8.2/10.8.3 kext and patch it, if it's vanilla).
 
On the contrary, executed this way, the code will patch the kext, if its checksum is not equal to the checksum of the patched 10.8.2/10.8.3 kext. So, on 1O.8.4 this code will patch the kext, no mather if the patch is proper for this new kext or not.

I think that is exactly what kpkp said. Whether or not patching some future AppleRTC binary with this patch is a good thing or not depends on whether it happens to work or not (rolling the dice...)
 
On the contrary, executed this way, the code will patch the kext, if its checksum is not equal to the checksum of the patched 10.8.2/10.8.3 kext. So, on 1O.8.4 this code will patch the kext, no mather if the patch is proper for this new kext or not.
if (checksum == current vanilla) then patch, that is how i understood RM comment, if i got it wrong my bad.

Edit: because i think that is better to prevent having wrongly patched kexts, is aways better to have vanilla if you are trying to help someone with a problem.
 
if (checksum == current vanilla) then patch, that is how i understood RM comment, if i got it wrong my bad.

That was exactly my comment.

In my mind, this has advantages over the other way (checksum != patched_10_8_2):

- you're not patching something which is unknown (eg. 10.8.4) [if the patch turns out to work w/o modifications with some future binary, this is would be considered a disadvantage... like I said, patching w/o knowing that it works is rolling dice]
- you're not patching something twice (eg. patched 10.8.4) [does the patch result in no-op in the case of double patch]
 
That was exactly my comment.

In my mind, this has advantages over the other way (checksum != patched_10_8_2):

- you're not patching something which is unknown (eg. 10.8.4) [if the patch turns out to work w/o modifications with some future binary, this is would be considered a disadvantage... like I said, patching w/o knowing that it works is rolling dice]
- you're not patching something twice (eg. patched 10.8.4) [does the patch result in no-op in the case of double patch]

So, the code should be:

Code:
if [ "$RTCpatched" == "43d7bd19be683cfb8dae1826da40ab24" ]
then[INDENT]cp -Rf "$kextdir/AppleRTC.kext" "$BackupDir"
perl -pi -e 's|\x75\x30\x89\xd8|\xeb\x30\x89\xd8|' "$kextdir/AppleRTC.kext/Contents/MacOS/AppleRTC"[/INDENT]
fi

where 43d7bd19be683cfb8dae1826da40ab24 is the vanilla checksum.
 
So, the code should be:

Code:
if [ "$RTCpatched" == "43d7bd19be683cfb8dae1826da40ab24" ]
then[INDENT]cp -Rf "$kextdir/AppleRTC.kext" "$BackupDir"
perl -pi -e 's|\x75\x30\x89\xd8|\xeb\x30\x89\xd8|' "$kextdir/AppleRTC.kext/Contents/MacOS/AppleRTC"[/INDENT]
fi

where 43d7bd19be683cfb8dae1826da40ab24 is the vanilla checksum.

Yes...
 
Status
Not open for further replies.
Back
Top