Support for hooking KVO-enabled objects

[flocked]

This library manages to swizzle objects that are KVO.

SwiftHook

Here is the implementation:
KVOWrapper.swift

[lukaskubanek]

@flocked Thanks for raising this feature request! To give you some context, I’ve forked this library from Peter Steinberger, and I’m in the process of modernizing it. This is almost done, the README reflects the current state, and just today, I released the first beta of what will be version 1.0 of this implementation.

To be honest, I’ve not questioned the feasibility of hooking KVO-enabled objects, as Peter’s implementation didn’t allow it. After updating to Sequoia 15.4.1 and testing the example Mac app in the repo, I noticed that it’s no longer possible to hook the sample NSWindow due to it being KVO-observed, which actually limits the usefulness of the library (and breaks the example). Coincidently, you’ve shared this issue, and you’ve even attempted to implement this in Peter’s repo. So, I’m potentially interested in having the support in version 1.0. I wonder what is your use case for this feature?

Thanks for pointing me to SwiftHook. This library has been on my list of things to check out for a while. I haven’t explored it in detail, but they claim to have KVO support built in. Since you’ve dealt with it already, can you explain what trick they’re leveraging?

[lukaskubanek]

After an initial investigation, I discovered that the trick used in SwiftHook is to force KVO on hooked objects. This is done in wrapKVOIfNeeded(object:selector:) by installing a persistent dummy observer on a private key path. This causes the runtime to create the NSKVONotifying_ subclass and swap the object’s isa pointer, which remains set until the dummy observer is removed when the (last) hook is reverted.

In our context, this means our custom dynamic subclass will almost always be layered on top of the KVO NSKVONotifying_ subclass. We need to modify the ObjectHookStrategy to install a dummy KVO observer on the object prior to installing our custom dynamic subclass and keep a reference to it, so it isn’t removed when external observers go away. That also covers the case where the object is already KVO-observed. Holding onto this observer prevents the KVO subclass from being torn down and ensures our subclass never points to a non-existent class.

SwiftHook also checks whether the object is KVO-supported and only does the wrapping if that’s the case. This is done in isSupportedKVO(object:) and then cached. Apparently, Foundation classes like NSString, NSArray, NSSet, NSOrderedSet, NSDictionary (and their mutable variants) don’t support KVO, i.e. one can’t add an observer to them. This check is done by trying to add an observer and catching any Objective-C exception. When trying to hook objects of these types with the library, errors are thrown. We’d either need to adopt this approach as well or treat those classes in a special way by not forcing KVO on them and applying our custom dynamic subclass directly. I’d prefer the latter option.

Lastly, SwiftHook makes sure the KVO subclass overrides a property’s getter and setter by briefly observing that property’s key path when being KVO-wrapped. This ensures that the hook doesn’t install its own override, which would break KVO (e.g. when observing the property thereafter). Since our subclass will itself override the getter or setter and call super (so KVO notifications still fire), we can skip that extra add/remove step and just rely on normal method dispatch.

[lukaskubanek]

For KVO-supported objects, this would then lead to the following flows:

First KVO, then hooking:

Step	Runtime Class Hierarchy
Start	Base
Add KVO observer	Base < NSKVONotifying_Base
Add hook	Base < NSKVONotifying_Base < InterposeKit_Base_1
Remove hook	Base < NSKVONotifying_Base
Remove KVO observer	Base

First hooking, then KVO:

Step	Runtime Class Hierarchy
Start	Base
Add hook	Base < NSKVONotifying_Base < InterposeKit_Base_1
Add KVO observer	Base < NSKVONotifying_Base < InterposeKit_Base_1
Remove hook	Base < NSKVONotifying_Base
Remove KVO observer	Base

[flocked]

I tried implementing it, but it's crashing. Take a look at the KVO_Test test project.

Inside ObjectSubclassManager's ensureSubclassInstalled(for:) I call object.wrapKVOIfNeeded() to add a dummy KVO observer to the object before installing the dynamic subclass. After uninstalling the dynamic subclass inside uninstallSubclass(for:), I call object.unwrapKVO().

NSObject+KVOWrapper.swift

[flocked]

It's all much harder to do. they change the complete method of one that is interposed and use libffi.

[lukaskubanek]

It's all much harder to do. they change the complete method of one that is interposed and use libffi.

I believe this is similar to what ITKSuperBuilder does by adding a super trampoline. However, Peter’s implementation doesn’t currently behave correctly in all situations. See #21.

I tried implementing it, but it's crashing. Take a look at the KVO_Test test project.

Thanks for looking into it!

When I ran your example app, it didn’t crash, likely because the NSTextField being hooked wasn’t KVO-observed yet, and the dummy observer installation ceremony worked just fine. I’m on macOS 15.4.1.

I then tested the example app bundled with the repo and tried applying hooks to the NSWindow object, which is already KVO-observed at the time of hook installation. This indeed triggered an error, but it was the KVO detection one. Skipping that check made it work, so I think this trick is indeed viable. I’ll make sure to build a cleaner version of what SwiftHook does before releasing 1.0.

[lukaskubanek]

OK, I probably spoke too soon. Now, I'm occasionally getting crashes with _NSKeyValueRetainedObservationInfoForObject in the stack trace, which hints at something being off with KVO. SwiftHook seems to do the method patching directly on the NSKVONotifying_ dynamic subclass. I’m now thinking that slapping another dynamic subclass onto it might not be compatible.

Edit: OK, it looks like it really isn’t compatible and we can’t have both dynamic subclasses installed at the same time. Will have to think more about how to approach it.

[lukaskubanek]

I’ve looked into the approach of forcing KVO and using the KVO subclass for installing hooks just like SwiftHook does. The problem with this is that it makes instance isolation tricky. Once two objects are hooked, they share the same KVO subclass, which leads to shared hooks, chaining calls, and other weirdness. In the non-KVO world we avoid this by using a unique subclass per object.

SwiftHook works around this by adding manual bookkeeping at dispatch time. As far as I can see, that’s the only way to make this work. However, I don’t plan to go down the rabbit hole for now, so InterposeKit version 1.0 won’t support KVO.