Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
29,866 posts in this topic

Recommended Posts

polyzargone
polyzargone
Posted
Posted

 

You will need to create a directory first, for EFI the correct syntax would be: 

mkdir /Volumes/EFI
sudo mount -t msdos /dev/diskXsX /Volumes/EFI

For the recovery: 

mkdir /Volumes/Recovery
sudo mount -t hfs /dev/diskXsX /Volumes/Recovery

 

Are you sure of this ? Assuming that the installation has been made by OS X using Clover, there's no need to create such directories. OS X will mount them by itself.

 

Well, this is just a question but I never had to proceed like this on OS X, only did that when running Linux :unsure:....

Link to comment
Share on other sites
polyzargone
polyzargone
Posted
Posted

Try this:

defaults write com.apple.DiskUtility DUDebugMenuEnabled 1

 

 

Sorry but this will not work either in OS X 10.11 :D. Apple has complety revamped Disk Utility with El Capitan and old methods doesn't work anymore.

 

I suggest to just do what I mentionned earlier which is the simpliest way I know so far to hide/unhide partitions in OS X 10.11. :P.

  • Like 1
Link to comment
Share on other sites
Simonej
Simonej
Posted
Posted

To Slice, only for information, there is here or in Clover Report one "to do list"?

 

I always read your posts and see many suggestions from dev. maybe this can help to remind you of the development and the curious have something more to read :)

  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

 

 

To Slice, only for information, there is here or in Clover Report one "to do list"?

I always read your posts and see many suggestions from dev. maybe this can help to remind you of the development and the curious have something more to read :)

You means this thread? http://www.insanelymac.com/forum/topic/306156-clover-bugissue-report-and-patch/

  • Like 2
Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

Slice,

 

Just to let you know. I noticed that you added:

#define CPU_MODEL_BROADWELL_HQ  0x47
to platform.h but Apple uses:
#define CPU_MODEL_BRYSTALWELL  0x47
Also. You should be able to inject kexts, but you need to change the path to that of a supported one by the com.apple.kext-management entitlement (/System/Library/Extensions or /Library/Extensions).

 

@Download-Fritz,

 

The omission of "Driver-%lx" in boot.efi is old news. Done in Yosemite already.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Slice,

 

Just to let you know. I noticed that you added:

#define CPU_MODEL_BROADWELL_HQ  0x47
to platform.h but Apple uses:
#define CPU_MODEL_BRYSTALWELL  0x47

Sure?

#define CPUID_MODEL_YONAH		0x0E
#define CPUID_MODEL_MEROM		0x0F
#define CPUID_MODEL_PENRYN		0x17
#define CPUID_MODEL_NEHALEM		0x1A
#define CPUID_MODEL_FIELDS		0x1E	/* Lynnfield, Clarksfield */
#define CPUID_MODEL_DALES		0x1F	/* Havendale, Auburndale */
#define CPUID_MODEL_NEHALEM_EX		0x2E
#define CPUID_MODEL_DALES_32NM		0x25	/* Clarkdale, Arrandale */
#define CPUID_MODEL_WESTMERE		0x2C	/* Gulftown, Westmere-EP/-WS */
#define CPUID_MODEL_WESTMERE_EX		0x2F
#define CPUID_MODEL_SANDYBRIDGE		0x2A
#define CPUID_MODEL_JAKETOWN		0x2D
#define CPUID_MODEL_IVYBRIDGE		0x3A
#define CPUID_MODEL_IVYBRIDGE_EP	0x3E
#define CPUID_MODEL_CRYSTALWELL		0x46
#define CPUID_MODEL_HASWELL		0x3C
#define CPUID_MODEL_HASWELL_SVR		0x3F
#define CPUID_MODEL_HASWELL_ULT		0x45

This is from Apple XNU sources.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Also. You should be able to inject kexts, but you need to change the path to that of a supported one by the com.apple.kext-management entitlement (/System/Library/Extensions or /Library/Extensions).

 

Give me this kext to look into.

100% This is what I have here:

#define CPUID_MODEL_BROADWELL		0x3D
#define CPUID_MODEL_BROADWELL_ULX		0x3D
#define CPUID_MODEL_BROADWELL_ULT		0x3D
#define CPUID_MODEL_BRYSTALWELL		0x47

Where did you get El Capitan sources?

Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

Give me this kext to look into.

 

Where did you get El Capitan sources?

See PM for header file (cpuid.h) from El Capitan with the new declarations.

 

You can use my LZVN to unpack a prelinkedkernel and then extract the __PRELINK_TEXT,__text and __PRELINK_INFO,__info sections. Change one of the _PrelinkBundlePath's from "/System/Library/Extensions/" to one with the same length, but a different name. Recompress the file and save it under a different name. Add a kernel cache flag and load it. The result is that you end up seeing the same error.

 

Sorry. I hope that you get it. I'm in the middle of something already.

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

Also. You should be able to inject kexts, but you need to change the path to that of a supported one by the com.apple.kext-management entitlement (/System/Library/Extensions or /Library/Extensions).

@Download-Fritz,

 

The omission of "Driver-%lx" in boot.efi is old news. Done in Yosemite already.

 

What path do you mean precisely? Isn't only the memory addresses to the kext's binary and Info.plist passed?

Also, thx for the info it vanished in Yos already. But still, fat boot.efi was still in Mountain Lion even though it was 64-bit only, so I guess next time Apple cleans the code in that kernel region, 'Driver-' will be dead for good.

Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

What path do you mean precisely? Isn't only the memory addresses to the kext's binary and Info.plist passed?

_PrelinkBundlePath

 

Also. I moved the unsigned kexts from /Library/Extensions to /Extra/Extensions and thus now I have these files in this directory:

AppleHDA892.kext

AppleEmulator.kext (you use your FakeSMC.kext instead)

AppleIntelE1000e.kext

 

I also enabled SIP completely with:

bootArgs->flags |= kBootArgsFlagCSRActiveConfig;
bootArgs->csrActiveConfig = 0;
bootArgs->csrCapabilities = CSR_VALID_FLAGS;
So everything is now 'protected' but the good news is that there is NO sign of ANY unsigned kext in any log or debug output. It is entirely active, but having the kext in the prelinkedkernel is the key. Therefor you use kext injection, but that appears to be broken (no pun intended) in Clover.

 

I'll write up a blog entry with my POC as soon as I can. Trust me. This works 100% with RevoBoot so it should work with Chameleon and Clover as well.

  • Like 1
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

Okay, obviously I'm blind once more... though what'S the point of kext injection if you are required to create a prelinkedkernel including them? Yes, the kexts are no longer in the Extensions dir, but the main point is to be able to either run a vanilla install or boot the installer without mods. Having them cached removes the need for injection for me to be honest.

  • Like 2
Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

Okay, obviously I'm blind once more... though what'S the point of kext injection if you are required to create a prelinkedkernel including them? Yes, the kexts are no longer in the Extensions dir, but the main point is to be able to either run a vanilla install or boot the installer without mods. Having them cached removes the need for injection for me to be honest.

Surely you are missing the point. And entirely. First. It is a proof of concept that shows a weak point in Apple's kext signing code/requirement, and that gives me a way to inject kexts into a prelinkedkernel to bypass Apple's strict kext signing restrictions and as a result my hack runs with the maximum SIP protection enabled. Without any issue. It's practically the same as kext injection, but without first having to write all code. And that is what my POC is about, but if you know any way to reproduce this, without the provided info, then please go ahead. Without trying to shoot off good ideas as usual.
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

I wonder how you can say "as usual" without even knowing me, but whatever you say. I guess asking a question about the purpose was simply over the top, I'm sorry I didn't blindly like your post without even knowing what you mean in detail and asked for clarification. Beside that I still think 'Driver-' support will be removed from the kernel at very latest in 10.12 and injecting right into prelinkedkernel is the only replacement I can think of retaining the former simpleness of just having the kext in a folder and having the boot solution do the work.

 

Again, I'm not saying your idea is not good, but that I (me... the subjective me that may not see all aspects of your idea as I can't read your mind) see little practical use for the regular user in the end. Whether it seems future-proof or not is to be decided by everyone for themselves.

  • Like 1
Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

I wonder how you can say "as usual" without even knowing me, but whatever you say. I guess asking a question about the purpose was simply over the top, I'm sorry I didn't blindly like your post without even knowing what you mean in detail and asked for clarification. Beside that I still think 'Driver-' support will be removed from the kernel at very latest in 10.12 and injecting right into prelinkedkernel is the only replacement I can think of retaining the former simpleness of just having the kext in a folder and having the boot solution do the work.

 

Again, I'm not saying your idea is not good, but that I (me... the subjective me that may not see all aspects of your idea as I can't read your mind) see little practical use for the regular user in the end. Whether it seems future-proof or not is to be decided by everyone for themselves.

Oops. The "as usual" is not for you, personally, but in general. Sure. I don't use Clover. That much is clear to everyone already, but many other people do and thus when I think that I can help... I will. And I did found a solution. One that works in DP3, DP4 and DP5 (tested). Just hang in as I prepare the POC writeup so that everyone can use it.

 

p.s. Anyone that needs to run the installer, has to inject FakeSMC.kext and other kexts, that will work just as usual. Even without rootless=0 or NVRAM vars.

  • Like 6
Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

Maybe it would be better to put the rather hacky ideas to solve this aside and try to cleanly mod prelinkedkernel. Catching it in-memory would be very hard, but I guess we could overwrite the file protocol, load prelinkedkernel, mod it and then return it already modded to boot.efi. Would save kernel patches, kicks the abandoned kext injection method and works as people are used to till Apple changes the format of prelinkedkernel. :)

It looks like Pike has done what you suggested Download-Fritz. At least, to me, it sounds similar. Either way.. great stuff.

  • Like 4
Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

Surely you are missing the point. And entirely. First. It is a proof of concept that shows a weak point in Apple's kext signing code/requirement, and that gives me a way to inject kexts into a prelinkedkernel to bypass Apple's strict kext signing restrictions and as a result my hack runs with the maximum SIP protection enabled. Without any issue. It's practically the same as kext injection, but without first having to write all code. And that is what my POC is about, but if you know any way to reproduce this, without the provided info, then please go ahead. Without trying to shoot off good ideas as usual.

I liked this post earlier but having reread it I feel it could be interpreted as liking Pike's retort back to Download-Fritz where infact I was liking Pike's description of his proof of concept. I have therefore quoted above only the part I liked.

  • Like 2
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...