- Mach-O Library Load Commands
	- `LC_LOAD_DYLIB` specifies a dynamic library to be loaded at runtime and the dylib must be loaded when the binary or library is executed.
	- `LC_LOAD_WEAK_DYLIB` specifies a weakly linked dynamic library. If the dylib is not found, the binary or library will still be executed without interruption.
	- `LC_REEXPORT_DYLIB` specifies a dynamic library to be reexported by the binary or library.
- Install names specify the path to the dylib at runtime
	- `@executable_path` **–** This variable is replaced with the path to the directory containing the main executable for the process, for example, _/Applications/Dummy.app/Contents/MacOS._
	- `@loader_path` **–** This variable is replaced with the path to the directory containing the mach-o binary, which contains the load command.
	- `@rpath` – is a variable that will be replaced with one or more paths specified by the LC_RPATH command at runtime.
- Requirements for dylib hijacking:
	- The app is not restricted with a hardened runtime or having the com.apple.security.cs.disable-library-validation entitlement.
	- One of the files in the application path `app/Contents` is not properly signed (Figure 3). We can run the `codesign –verify –verbose <app_name>` command. If we see an error message in the output, it indicates that the signature is invalid.
- Identify weak dylibs:
	- `otool -l <app_name> | grep LC_LOAD_WEAK_DYLIB -A5`
	- Look for a weak library from a writeable directory
- Check if any dylibs are loaded from `@rpath`:
	- ` otool -l <app_name> | grep LC_LOAD_DYLIB -A5`
	- If any libs have `@rpath`, see if directory is writeable. If multiple `LC_RPATH` load commands are present and the library is not found in primary run-path, a malicious dylib can be placed in the primary path.