Skip to main content

Third-Party Libraries & Frameworks

Many iOS apps are integrating third-party frameworks/libraries into the apps to quickly add new features and functionality. Many times, this includes authentication functionality or other sensitive functions for the app.

% otool -L $BINARY
  • System Libraries are located in /usr/lib. (These do not typically need to be evaluated for the apps)

  • Frameworks are prefaced with @rpath, which is designated as the Frameworks sub-directory of the application Bundle directory. (i.e. $APP_PREFIX/AppName.app/Frameworks/)

  • System Frameworks are located in /System/Library/Frameworks. (These do not typically need to be evaluated for the apps)

Our focus will mostly be on the Frameworks that are designated with the @rpath prefix as these are the ones that are included with the app (though you can safely disregard the Swift frameworks if any are used).

% otool -L $BINARY | grep rpath | grep -v libswift | awk '{ print $1 }'
@rpath/ActiveLabel.framework/ActiveLabel
@rpath/Alamofire.framework/Alamofire
@rpath/AlamofireImage.framework/AlamofireImage
@rpath/AlamofireNetworkActivityLogger.framework/AlamofireNetworkActivityLogger
@rpath/DZNEmptyDataSet.framework/DZNEmptyDataSet
@rpath/AppNameLogin.framework/AppNameLogin
@rpath/JGProgressHUD.framework/JGProgressHUD
@rpath/KeychainAccess.framework/KeychainAccess
@rpath/PhoneNumberKit.framework/PhoneNumberKit
@rpath/SQLCipher.framework/SQLCipher
@rpath/SQLite.framework/SQLite
@rpath/Sentry.framework/Sentry
@rpath/libPhoneNumber_iOS.framework/libPhoneNumber_iOS

// On Device

cd /private/var/containers/Bundle/Application/{UUID}/AppName.app/Frameworks/

ls | grep -v libswift

ActiveLabel.framework
Alamofire.framework
AlamofireImage.framework
AlamofireNetworkActivityLogger.framework
DZNEmptyDataSet.framework
AppNameLogin.framework
JGProgressHUD.framework
KeychainAccess.framework
PhoneNumberKit.framework
SQLCipher.framework
SQLite.framework
Sentry.framework
libPhoneNumber_iOS.framework

If the app came from the App Store the libraries will be encrypted as well as the main binary. These typically get decrypted along with the app, so no further action should be needed.

TaskCommand
Ensure framework is decryptedotool -l $FMWK | grep -A 4 LC_ENC
Dump Headersclass-dump-swift -H -o headers $FMWK
Obtain class & method namesotool -oV $FMWK > class_methods.txt
List binary load commandsotool -l $FMWK > load_commands.txt
Dump Symbolsnm -arch arm64 -m $FMWK > symbols.txt
Stringsstrings $FMWK > library_strings.txt

Examine this information for vulnerabilities and possible points of interaction to the app. In some cases, we have found that binary protections, such as jailbreak detection routines, are implemented in frameworks, and not in the main app binary (as expected). So, this is a critical -- though tedious -- task to perform when testing an app.

Library Version

Libraries are required to have an Info.plist file which describes its parameters. It is always a good idea to check the version of the library and evaluate if any public vulnerabilities or exploits are available. It is not uncommon to see libraries that are several years old.

As with the main executable, the library version is kept in the Info.plist:

## plutil Info.plist 
{
BuildMachineOSBuild = 19E287;
CFBundleDevelopmentRegion = en;
CFBundleExecutable = Alamofire;
CFBundleIdentifier = "org.cocoapods.Alamofire";
CFBundleInfoDictionaryVersion = "6.0";
CFBundleName = Alamofire;
CFBundlePackageType = FMWK;
CFBundleShortVersionString = "4.9.1";
CFBundleSignature = "????";
CFBundleSupportedPlatforms = (
iPhoneOS
);
CFBundleVersion = 1;
DTCompiler = "com.apple.compilers.llvm.clang.1_0";
DTPlatformBuild = 17F65;
DTPlatformName = iphoneos;
DTPlatformVersion = "13.5";
DTSDKBuild = 17F65;
DTSDKName = "iphoneos13.5";
DTXcodeBuild = 11E608c;
MinimumOSVersion = "8.0";
}

In this case, version 4.9.1 of this library was released in October 2019. Check if this version has any known vulnerabilities.