Dylib Hijack Scanner (DHS) False Positives

There are two kinds of hijackers that DHS looks for: a) 'weak' and b) 'rpath'

a) weak hijackers
An application that has an unfulfilled weak dependency, can be easily hijacked by fulfilling the dependency. In other words, an attacker can plant a dylib who's matches the name of the weak dependency. Once planted, the (malicious) dylib will be automatically loaded whenever the application is loaded. DHS attempts to uncover such hijackers by detecting weak dependencies that are fulfilled with dylibs that appear to be unrelated to the application (e.g. mismatching in signing authorities, etc.). This approach is invariable prone to false positives. However, to err on the side of caution DHS will report false positives instead of false negatives.

b) rpath hijackers. 
An application that has run-path dependencies can be hijacked if it has multiple run-path search directories and at least one run-path dependency that does not exist in a primary run-path search directory. DHS attempts to detect such hijackers by analyzing run-path dependencies. If a run-path dependent dylib is found in multiple run-path search directories and appears to be unrelated to the application, it will be reported as a false positives. While less prone to false positives (when compared to the weak hijacker detection), legitimate scenarios do exist where benign dylibs cannot be differentiated from a malicious hijack. Again, DHS chooses to report false positives instead of false negatives.

The following (non-exhaustive) list includes known false positives:
app: 	Microsoft Messenger 
dylib: 	mbukernel

app: 	Microsoft Messenger Daemon 
dylib:	mbuinstrument

app: 	Matlab
dylib: 	cefclient

app: 	iExplorer, ForkLift, etc
dylib:	OSXFuse

app:	SmartConverter.app, etc
dylib: 	Sparkle

app: 	Adobe Photoshop
dylib:  LogSession