Doees not run on Apple Silicon or build under Monterey :(

[bctiemann]

Tried running this per the readme on my M1 Pro, Monterey 12.3.1. Failed to run as-is due to being build for Intel (understandable).

Opened the project in Xcode, and it failed to build with clang: error: no such file or directory: '/System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport'

I'm not familiar enough with how frameworks/libraries work in Xcode to figure this out for myself. Might there be any chance of you picking this project back up for an updated build that supports Apple Silicon?

My MBP and its enormous trackpad would thank you...!

[cocoahuke]

Hi, bctiemann

This project does not support M1 macs because M1 equipped something called "Kernel Integrity Protection" prevents kernel code from been modifying, you can not disable that, it's a lower level stuff than SIP. Injecting code into the multitouch driver is critical for this project to function properly.

One possible solution is to rebuild the entire multitouch driver, and load this custom driver instead of the OEM one. but that's a hell of work to do cuz I don't have the multi touch driver source code.

[bctiemann]

Aw, that's a shame. Sorry to hear that!

[swealpha]

Karabiner-Element have a function that is similar but not even that one work? Is it because of m1/m2/m3 silicon cpu? So sad.

https://karabiner-elements.pqrs.org/

[teqtic]

@cocoahuke I am very interested in reviving this project for Apple silicon. How were you intercepting the trackpad events on Intel? Is there nothing we can tap into on the new systems to achieve the same thing? Surely we can think of something. I found this link about how to run kernel extensions on Apple Silicon. Does that help at all?

@swealpha There is an open issue for karabiner here. However, I'm not sure the intended purpose of the ignore area is to ignore the touches system wide, but just to create an exception area where Karabiner's keyboard key change effects do not apply when the trackpad is touched in that area.

[teqtic]

Does this article about different techniques for code injection on MacOS help at all?

https://knight.sc/malware/2019/03/15/code-injection-on-macos.html

[teqtic]

@cocoahuke it looks like Kernel Integrity Protection (KIP) can be disabled using the bputil command. Would that make this work on Apple Silicon Macs again?

https://www.reddit.com/r/mac/comments/1duc5cp/comment/mqvqoh3/?context=3
https://keith.github.io/xcode-man-pages/bputil.1.html

[teqtic]

I was able to get the app_shrinkTrackpad.xcodeproj project to build on MacOS Sequoia by updating the "Other linker flags" from:

/System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport

to

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/PrivateFrameworks/MultitouchSupport.framework/MultitouchSupport.tbd

I also successfully built kext_shrink_trackpad.xcodeproj without issues.

I then found the output "app_shrinkTrackpad.app" and "kext_shrink_trackpad.kext".

I copied kext_shrink_trackpad.kext to app_shrinkTrackpad.app/Contents/Resources/ [found instructions here]

I moved app_shrinkTrackpad.app into /Applications and ran it as root:

sudo /Applications/app_shrinkTrackpad.app/Contents/MacOS/app_shrinkTrackpad

That had me rebooting to change the boot security policy to permissive with allowing the loading of system kernel extensions.

Then I tried to run it again and it had me approve the kext in System Settings and reboot again.

Now when I run it I get "File not exist" after it successfully loads the kext. I tracked this down in the source code to it not finding "/System/Library/Extensions/AppleMultitouchDriver.kext/Contents/MacOS/AppleMultitouchDriver"

When I browse for that file myself, indeed I cannot find it. AppleMultitouchDriver.kext is there, but there is no "MacOS" folder in "Contents". It appears that the binaries have been removed from system kexts in /System/Library/Extensions since Ventura:

dortania/OpenCore-Legacy-Patcher#998

Any ideas on how to proceed?

[teqtic]

I was able to make a bit more progress by downloading the Apple Kernel Debug Kit and editing the path to AppleMultiTouchDriver from

"/System/Library/Extensions/AppleMultitouchDriver.kext/Contents/MacOS/AppleMultitouchDriver"

TO

"/Library/Developer/KDKs/KDK_15.5_24F74.kdk/System/Library/Extensions/AppleMultitouchDriver.kext/Contents/MacOS/AppleMultitouchDriver"

This allowed the code to proceed further but it now causes a freeze and reboot (kernel panic). I'm not sure if this is because I have not yet disabled Kernel Integrity Protection, or if there is indeed a bug or some sort of incompatibility after so many years of unsupported MacOS updates.

It would be great if anyone has some insights! Can this code malfunctioning potentially make my Mac unbootable, or is a freeze and reboot the worst that could happen?

[MikeRich88]

This allowed the code to proceed further but it now causes a freeze and reboot (kernel panic)

How are you running the code? If you are booting the computer, and then simply running the app, nothing is being installed permanently.

If you are doing something like "kextload", again still nothing is being installed permanently, as long as the kext isn't in some folder like /Library/Whatever/

The kernel panics, and you must reboot, but nothing is changed or damaged. You will boot fresh and the kernel will be happy again.

If you are doing anything with launchctl, or something similar, then you are in the danger zone (cue Kenny Loggins). Don't put anything in a /Library/ folder, or use launchctl, that might cause it to auto load, which would brick the main OS in a non-permanent way. (You would have to boot Recovery, and then rm -rf the offending files.)

Of course in Mac OS 16 they'll probably fully take away any ability to do anything with the kernel because of Al Qaeda or whatever stupid reason.

[teqtic]

This allowed the code to proceed further but it now causes a freeze and reboot (kernel panic)

How are you running the code? If you are booting the computer, and then simply running the app, nothing is being installed permanently.

If you are doing something like "kextload", again still nothing is being installed permanently, as long as the kext isn't in some folder like /Library/Whatever/

The kernel panics, and you must reboot, but nothing is changed or damaged. You will boot fresh and the kernel will be happy again.

If you are doing anything with launchctl, or something similar, then you are in the danger zone (cue Kenny Loggins). Don't put anything in a /Library/ folder, or use launchctl, that might cause it to auto load, which would brick the main OS in a non-permanent way. (You would have to boot Recovery, and then rm -rf the offending files.)

Of course in Mac OS 16 they'll probably fully take away any ability to do anything with the kernel because of Al Qaeda or whatever stupid reason.

I am running the code exactly the way I detailed in the post above. The kext is inside the app package.

I was able to get even further by analyzing the code and trying to understand it with ChatGPT. On Apple Silicon Macs, the driver file has multiple "mach-o" headers because it's a universal binary, so you have to find the arm64 header and use that one to find the vtable offsets to the commands we want.

However, even after doing all that and getting what I think is a valid memory pointer reference, it's still freezing the kernel. I really wish we could get a hold of @cocoahuke !

[ptjaworski]

I'm not so profound in the KIP topic, but maybe that article would help somehow to solve this issue. As I can see they have changed the CLI API, so the old commands are still available under systemextensionsctl tool if SIP is disabled

In Big Sur, there’s very limited experience but a similar approach should succeed; note that kextunload and kextcache have been replaced by kmutil, which is exceedingly well documented but also very complex.

https://eclecticlight.co/2020/12/21/what-stops-your-mac-running-incompatible-extensions/

[uxsmr]

@teqtic Just following up - any progress on this?

[teqtic]

@demochasr I'm afraid not. I managed to find an email address for the original author @cocoahuke and asked if this would in any way be possible, given what I've found. This is what he replied in July:

hello, sorry for late reply

It’s not feasible because simply loading an unsigned kernel driver isn’t sufficient. The shrink_trackpad project relies on hijacking an exposed interface of the multitouch driver. However, due to Apple’s kernel-level security mitigations, it’s no longer possible to modify existing code pages — and this security feature cannot be disabled.

I then replied:

No problem, thanks for getting back to me! Is there any other way you can think of to make this happen? What about cloning the Apple multitouch driver and loading that instead? Would it be possible to modify it?

but I haven't heard back since that first reply in July :(