HoRNDIS-9.3(x86_64_and_arm64e) fails to load with Bad code signature

[kingster]

Hi

Unable to load the signed kext for arm64e due to codesign issue. What do I need to do to load the kext here?

sudo kmutil load -p /Library/Extensions/HoRNDIS.kext
Error Domain=KMErrorDomain Code=29 "Authenticating extension failed: Kext com.joshuawise.kexts.HoRNDIS v9.3 in executable kext bundle com.joshuawise.kexts.HoRNDIS at /private/var/db/KernelExtensionManagement/Staging/com.joshuawise.kexts.HoRNDIS.8pBb9C/HoRNDIS.kext:

Authenticating extension failed: Bad code signature" UserInfo={NSLocalizedDescription=Authenticating extension failed: Kext com.joshuawise.kexts.HoRNDIS v9.3 in executable kext bundle com.joshuawise.kexts.HoRNDIS at /private/var/db/KernelExtensionManagement/Staging/com.joshuawise.kexts.HoRNDIS.8pBb9C/HoRNDIS.kext:

Authenticating extension failed: Bad code signature}

Mac OS Version : 12.6.5 Chip : M1

[TomHeaven]

The released kext is not correctly signed with an Apple Developer Pogram ID (which requires 99 dollars per year). That's why it is not allowed to be loaded in a real Mac. A temporary solution is to disable SIP and try to load the kext again.

[samip5]

which requires 99 dollars per year

Which you might be able to crowsource, to get signed kexts. :)

[smiba]

I'd be happy to contribute, it's quite annoying right now that I have to disable SIP for this to work

[mfonville]

I'd be willing to contribute too.

Even better would be if someone with the proper development skills could overhaul the driver in a way that doesn't require a kernel extension. A crowdsource for that might work.

[d235j]

Even better would be if someone with the proper development skills could overhaul the driver in a way that doesn't require a kernel extension. A crowdsource for that might work.

This is not really helpful because Apple requires separate permissions for each specific vendor and product ID for a DriverKit driver. See https://github.com/360Controller/360Controller/issues/1267 for some discussion on this.

The correct fix is for the upstream hardware vendor to implement USB CDC-NCM, which is natively supported by macOS and recent versions of Windows. Both the PlutoSDR and the BeagleBone have done this in newer firmware versions.

[mfonville]

This is not really helpful because Apple requires separate permissions for each specific vendor and product ID for a DriverKit driver. See 360Controller/360Controller#1267 for some discussion on this.

Thank you for sharing that. Pity that Apple is blocking that path then.

Best is indeed with devices support USB CDC-NCM. On Android this is support is lacking, AFAIK only recent Pixel phones support this. I don't know about other brands supporting NCM (yet).

[samip5]

Well, this is beyond annoying of Apple.

If you're generating your first Developer ID certificate, the software that you sign it with must be notarized by Apple in order to run on macOS 10.14.5 or later.

[d235j]

Well, this is beyond annoying of Apple.

If you're generating your first Developer ID certificate, the software that you sign it with must be notarized by Apple in order to run on macOS 10.14.5 or later.

The user can get around that by right click -> open (possibly twice). Notarization just gets rid of that scary warning.

This is not specific to kexts, but to software in general.

[samip5]

The user can get around that by right click -> open (possibly twice). Notarization just gets rid of that scary warning.

Yes, but that's not fun when you try to make a signed version of the thing.

[d235j]

The user can get around that by right click -> open (possibly twice). Notarization just gets rid of that scary warning.

Yes, but that's not fun when you try to make a signed version of the thing.

You probably can blame the prevalence of fake video player and fake antivirus Trojan software for that.