Technical differences between mach_override and fishing hook?

Question

Today I first came across the fishhook library https://github.com/facebook/fishhook , which can be used to dynamically rewrite characters in Mach-O binaries (they say for iOS, but I think the code will work on OS X too )

Until now, I knew and used mach_override https://github.com/rentzsch/mach_override , which aims at a similar goal (i.e. replaces one implementation of a function with another), but overwrites the assembler instructions of the beginning of the function to move to another place.

The fish hook approach looks a lot simpler, but since it “only” rewrites the symbol table, I have the feeling that it is less general than the mach_override approach.

Can someone give some complicated technical facts about situations when one project should be preferable to another (for example, a situation where one approach will not work and the other will be)?

Answer 1

Two approaches use different methods:

A) fishhook works, as you said, on characters in the character table. This means that if a character is exported using dylib or a frame, and you can change the import table, you can redirect it to your implementation.

B) mach_override uses the Mach VM API for OS X (and iOS) to fix functions when they are already loaded, that is, already in memory. It does this by binary correction of the beginning of the function implementation, to go to another address (your implementation), and then bounce back.

Fishhook is more stable in the sense that it (i) simplifies implementation and (ii) is seamless as soon as the process loads dyld and the characters are connected. However, it will not work with characters that are not directly loaded by the executable. In other words, if you want to fix printf (3), for example, it will only work on printf calls from your executable file, and not on calls made from libSystem or other libraries. However, Mach_override is not so stable as it relies on certain prologue functions that can be overridden - approximately 90% of the time, but not 100%.

While validating the information on iOS pages is read-only, in some cases it may be possible to get around this (if you fix the executable, you can also fix LC_SEGMENT commands and sections), and you can use the Mach VM apis to unprotect from pages (only if the device is locked).

Answer 2

Fishhook was created with the goal of connecting features that served as entry points to system calls on iOS to track a rare error. On iOS, executable pages are read-only, so it is impossible to execute a patch in downloads, but the tables used to search for dynamically related functions are not readable, so we fix them.

For obvious reasons, this approach will not work for functions that do not pass through the dynamic channel, whereas for mach_override it will work until you can find the function and write to the memory page containing the code.

Note that I personally have not used mach_override, so I'm not sure how much it really works.