Delegate function hooking

[noita-player]

It'd be convenient to have a hook on delegate dispatch. They reach processevent eventually, but at that point I don't think we can easily recover the delegate this ufunction was dispatched because of (correct me if I'm wrong). The options of TScriptDelegate, FMulticastDelegate, FMulticastInlineDelegate, and FMulticastSparseDelegate complicate matters. The multicast types all get their InvocationList member from the same base class, TMulticastScriptDelegate, which makes life a little easier, maybe, if delegates were to be supported in a more simple way where we allow you to fetch the bound func or getter/setter the TArray InvocationList.

Here are some notes from looking for where this could most easily be done:

FCallDelegateHelper::CallMulticastDelegate

I don't quite follow who invokes this, but we should be reaching it via a user of FUNC_DECLARE_DYNAMIC_MULTICAST_DELEGATE invoking Broadcast (or execute/executeifbound for the non-multicast delegates)

TMulticastScriptDelegate::ProcessMulticastDelegate

Templated, invoked from CallMulticastDelegate, and the template is code-generated by the macro for UHT emitted here.. Likely multiple sites to hook. Inconvenient.

[UE4SS]

What's the use-case for this ? I'm unable to come up with a reason why knowing what delegate triggered the UFunction would be important.
Is there a particular reason the UFunction and UObject context isn't enough ?

I did some cursory checking and to support this, we'd most likely need to add yet another AOB to the already long list of AOBs that we scan for.
Delegates seem complicated and for multi-cast delegates I think the best bet would be TMulticastScriptDelegate<FWeakObjectPtr>::ProcessMulticastDelegate<UObject>.
We would have access to the delegate itself and a pointer to its params.
Notice the template-params. I don't know if those are important at all in this case.
Keep in mind that I didn't do extensive testing to make sure that all multi-cast delegates hit this function so this is still an area that would need more checking.
I was unable to get other function, CallMulticastDelegate, to trigger in my testing.
If it was a good entry-point, because we haven't implemented the VM, we'd have to use a mid-function hook right after the original code retrieves the delegate details from the same stack and then we'd have to copy those from the x86 registers.

The call-stack for ProcessMulticastDelegate, triggered by a BP-only MulticastInlineDelegate looks liks this.
Note that I'm including the call-stack all the way to ProcessLocalScriptFunction so the ProcessMulticastDelegate function is a bit further down.

void __cdecl ProcessLocalScriptFunction(class UObject* __ptr64, struct FFrame&__ptr64, void* __ptr64 const)
ProcessScriptFunction<void(__cdecl*)(UObject*, FFrame&, void*)>+386
UObject::execLocalFinalFunction+4B
ProcessLocalScriptFunction+5E
UObject::ProcessInternal+75
UFunction::Invoke+79
UObject::ProcessEvent+362
AActor::ProcessEvent+72
TMulticastScriptDelegate<FWeakObjectPtr>::ProcessMulticastDelegate<UObject>+120 <-- HERE !!!
UTP_PickUpComponent::OnSphereBeginOverlap+52
UTP_PickUpComponent::execOnSphereBeginOverlap+249
UFunction::Invoke+79
UObject::ProcessEvent+362
TMulticastScriptDelegate<FWeakObjectPtr>::ProcessMulticastDelegate<UObject>+120 <-- HERE !!!
FComponentBeginOverlapSignature_MCSignature::Broadcast+ED
UPrimitiveComponent::BeginComponentOverlap+3D4
UPrimitiveComponent::UpdateOverlapsImpl+153
USceneComponent::UpdateOverlaps+6E
USceneComponent::EndScopedMovementUpdate+131
FScopedMovementUpdate::~FScopedMovementUpdate+2B
UCharacterMovementComponent::PerformMovement+AD2
UCharacterMovementComponent::ControlledCharacterMove+A2
UCharacterMovementComponent::TickComponent+366
FActorComponentTickFunction::ExecuteTick+EB
TGraphTask<FTickFunctionTask>::ExecuteTask+E7
FNamedTaskThread::ProcessTasksUntilQuit+10E
FTaskGraphCompatibilityImplementation::WaitUntilTasksComplete+206
FTickTaskSequencer::ReleaseTickGroup+242
FTickTaskManager::RunTickGroup+17
UWorld::Tick+7F8
UGameEngine::Tick+2CC
FEngineLoop::Tick+6C4
GuardedMain+3FC
GuardedMainWrapper+1A
LaunchWindowsStartup+FC
WinMain+14
__scrt_common_main_seh+106
kernel32.00007FF8100A7614
ntdll.00007FF810C226A1

[noita-player]

The user story is like: There is a UI that defines a delegate for when some data loads. You may want to be a delegate, prevent all the delegates from running, or change the data before it reaches those delegates. You can't be certain what delegates are being dispatched to, maybe they're blueprints that aren't always loaded. So you can't just hook those ufunctions, you'd need to preestablish all blueprints that might have the delegate to modify them with bpmodloader. Maybe you could generally hook SomeDelegateName__Event regardless of the class owner if wildcard support is added to RegisterHook, as we might be guaranteed that naming shceme, but there's a conflict issue when a game has ClassA.SomeDelegate as well as ClassB.SomeDelegate with different signatures.

I'll keep looking for an easier way to do this that doesn't introduce a new hook, no problem. I do kind of want to replace the pattern scanning system with something that is more compatible/reliable with different versions - for example, find references to string "Invalid object name" and walk up to the first call instruction to find the FName constructor. This exists on retail builds as well as debug/unoptimized builds, and isn't going to break due to compiler differences or optimization level differences. I think it can be made much more reliable introducing a little bit of program analysis like this, and the sporadic use of zydis is a good foundation.

Thanks for the call stack & pointers!