Clover Problems and Solutions

[Slice]

KC consists of several mach bodies different by types. Type 2 - executable for example prelinkedkernel. Type 12 - KC, and type 11 == MH_KEXT_BUNDLE somehow related to kext. Each body begins with header followed by a chain of load commands. LC_SEGMENT_64 represents a some memory segment. For example _HIB is a starting point of kernel. Command LC_SYMTAB describes a symbols table which I used to find a symbol inside the kernel. This way I made symbolic patcher instead of find bytes patterns.

BigSur introduced new mach body type 12 and new SEGMENTs. I found __TEXT_EXEC points to kernel body after KC.  Segments __REGIONnnn with even numbers points to kext descriptions. The kext defined by UUID.

For older method with prelinkedkernel we found PrelinkedInfo with is an array of plists "-PrelinkedInfoDictionary" where is item contains _PrelinkExecutableSourceAddr which is the kext binary.

To inject our kext here we have to reallocate this array and add here our kext plist with real addresses.

All this description has a lack of address shifts. For example if kext binary has virtual address 0xFFFFFF8001180000 then we will find in in real memory at address 01180000. Why?

But I have mush more complex case with symbol tables which I found by binary search and the resulting address is not same as it should be.

 

 

 

[vector sigma]

4 hours ago, Slice said:

For older method with prelinkedkernel we found PrelinkedInfo with is an array of plists "-PrelinkedInfoDictionary" where is item contains _PrelinkExecutableSourceAddr which is the kext binary.

To inject our kext here we have to reallocate this array and add here our kext plist with real addresses.

All this description has a lack of address shifts. For example if kext binary has virtual address 0xFFFFFF8001180000 then we will find in in real memory at address 01180000. Why?

looks like this is the easy part Lol. This is a relative address, for the prelikedkernel should be:

kextStart = (0xFFFFFF8001180000 - *__PRELINK_TEXT seg)  + *__PRELINK_TEXT seg->fileoff. 

then you have _PrelinkExecutableSize..done. 

 

P. S. __TEXT_EXEC is right after the empty __PRELINK_TEXT and it is full of mach_header, so the formula looks just the same to me, no? 

 

__TEXT_EXEC_BootKernelExtensions.kc._text.zip

 

Edited August 10, 2020 by vector sigma

[Slice]

21 hours ago, vector sigma said:

 

 

__TEXT_EXEC_BootKernelExtensions.kc._text.zip

 

What is it? Part of KC? Why reduced?

[vector sigma]

2 hours ago, Slice said:

What is it? Part of KC? Why reduced?

is the __TEXT_EXEC segment of the BootKernelExtensions.kc. First mach_header coincides with the address of the first _PrelinkKmodInfo's kext in the PRELINK_INFO dictionary. 

Also there are segments __REGION0 up to __REGION435....

Edited August 10, 2020 by vector sigma

[cecekpawon]

Hello, sorry to interrupt

 

On 8/10/2020 at 2:10 AM, Slice said:

To inject our kext here we have to reallocate this array and add here our kext plist with real addresses.

 

So, with KC, is that true that we were no longer able to inject our kexts through the devicetree, no matter what?

 

EDIT:

 

I dont install big sur, excuse my curiosity _/|\_

Edited August 20, 2020 by cecekpawon

[Slice]

3 hours ago, cecekpawon said:

Hello, sorry to interrupt

 

 

So, with KC, is that true that we were no longer able to inject our kexts through the devicetree, no matter what?

 

EDIT:

 

I dont install big sur, excuse my curiosity _/|\_

Not true, we may. But bs kernel does more checks and I don’t know exactly new requirements.

But ok, I am ready to accept other methods.