Regression in %hookf

[dom-lgtm]

What are the steps to reproduce this issue?

Create a Tweak with the following code:

%hookf(void, "afunction"){ }

What happens?

MSHookFunction((void )_logos_symbol$_ungrouped$"afunction", (void )&_logos_function$_ungrouped$"afunction", (void **)&_logos_orig$_ungrouped$"afunction");

This obviously doesn't compile.

What were you expecting to happen?

MSHookFunction((void )MSFindSymbol(NULL, "afunction"), (void )&_logos_function$_ungrouped$lookup$afunction, (void **)&_logos_orig$_ungrouped$lookup$afunction);

Any logs, error output, etc?

Compilation errors due to missing MSFindSymbol and unwanted quotes.

Any other comments?

It worked perfectly until I updated theos.

What versions of software are you using?

Latest git master.

[kirb]

This is by design. It’s not recommended to use MSFindSymbol() or dlsym() with NULL passed as the image argument, as looking up a symbol across the entire set of images loaded in the processes is slow. Unfortunately the initial design of %hookf encouraged this. Instead, define it yourself by passing the pointer into %init:

%hookf(void, afunction) {
  // …
}

%ctor {
  void *myLib = dlopen("/System/Library/PrivateFrameworks/Awesome.framework/Awesome", RTLD_NOLOAD);
  void *myFunc = dlsym(myLib, "afunction");
  %init(afunction = myFunc);
}

[NSExceptional]

@kirb I actually got the OK from @uroboro to revert this regression when I have time

[dom-lgtm]

Thanks @NSExceptional .

What about adding an optional:

%hooklib "/System/Library/PrivateFrameworks/Awesome.framework/Awesome" %hookf .... %end

Best of both world?

@kirb I write most of my tweaks without logos, but I love to have logos when I need to do a quick and dirty proof of concept or a throw away analysis tweak. Having to write the constructor defeats the purpose of %hookf as I may as well call MSHookFunction by hand at this point.

[uroboro]

An idea that floated around when I originally introduced this feature was to specify the library along with the function name:

%hookf(void, "/System/Library/PrivateFrameworks/Awesome.framework/Awesome:aFunction") {
}

[EthanArbuckle]

@uroboro that seems reasonable. Do you recall any problems with that approach? It's similar to how Frida's CLI works: module.so!symbol_name.

• If the provided input contains :, the LHS is expected to be a dlopen-resolvable path and the RHS a symbol that is exported by the specified library. When an explicit path is provided, runtime behavior should not permit falling back to a global search.

• If the provided input does not contain :, it's expected to be just a symbol name and will perform a global search across all images (the previous/legacy behavior of %hookf).

considerations:

Could a valid path contain : (like an ip-based nfs mount)?

Would it make sense to allow address-based hooking? ("TrustKit.framework/TrustKit:0x4793c")