MASTG-TECH-0058: Exploring the App Package

Once you have the application package name you want to target, you may want to start gathering information about it. First, retrieve the iGoat-Swift IPA as explained in Obtaining and Extracting Apps.

You can unzip the IPA using the standard unzip or any other ZIP utility.

unzip iGoat-Swift.ipa

Inside you'll find a Payload folder containing the so-called Application Bundle (.app). The following is an example of the output. Note that it was truncated for better readability and overview:

$ ls -1 Payload/iGoat-Swift.app
rutger.html
mansi.html
splash.html
about.html

LICENSE.txt
Sentinel.txt
README.txt

URLSchemeAttackExerciseVC.nib
CutAndPasteExerciseVC.nib
RandomKeyGenerationExerciseVC.nib
KeychainExerciseVC.nib
CoreData.momd
archived-expanded-entitlements.xcent
SVProgressHUD.bundle

Base.lproj
Assets.car
PkgInfo
_CodeSignature
[email protected]

Frameworks

embedded.mobileprovision

Credentials.plist
Assets.plist
Info.plist

iGoat-Swift

The most relevant items are:

Info.plist contains configuration information for the application, such as its bundle ID, version number, and display name.
_CodeSignature/ contains a plist file with a signature over all files in the bundle.
Frameworks/ contains the app native libraries as .dylib or .framework files.
PlugIns/ may contain app extensions as .appex files (not present in the example).
iGoat-Swift is the app binary containing the app's code. Its name is the same as the bundle's, without the .app extension.
Various resources such as images/icons, *.nib files (storing the user interfaces of iOS apps), localized content (<language>.lproj), text files, audio files, etc.

The Info.plist File¶

The information property list, or Info.plist (by convention), is the primary source of information for an iOS app. It is a structured file containing key-value pairs that describe essential configuration information for the app. Actually, all bundled executables (app extensions, frameworks, and apps) are expected to have an Info.plist file. You can find all possible keys in the Apple Developer Documentation.

The file might be formatted as XML or in binary (bplist) format. You can convert it to XML format with one simple command:

On macOS with plutil, which is a tool that comes natively with macOS 10.2 and above versions (no official online documentation is currently available):

plutil -convert xml1 Info.plist

On Linux:

apt install libplist-utils
plistutil -i Info.plist -o Info_xml.plist

Here's a non-exhaustive list of some info and the corresponding keywords that you can search for in the Info.plist file by just inspecting the file or by using grep -i <keyword> Info.plist:

App permissions Purpose Strings: UsageDescription (see "iOS Platform APIs")
Custom URL schemes: CFBundleURLTypes (see "iOS Platform APIs")
Exported/imported custom document types: UTExportedTypeDeclarations / UTImportedTypeDeclarations (see "iOS Platform APIs")
App Transport Security (ATS) configuration: NSAppTransportSecurity (see "iOS Network Communication")

Please refer to the mentioned chapters to learn more about how to test each of these points.

App Binary¶

iOS app binaries are fat binaries (they can be deployed on all devices 32- and 64-bit). In contrast to Android, where you can actually decompile the app binary to Java code, the iOS app binaries can only be disassembled.

Native Libraries¶

iOS apps can make their codebase modular by using different elements. In the MASTG, we will refer to all of them as native libraries, but they can come in different forms:

Static and Dynamic Libraries:
- Static Libraries can be used and will be compiled in the app binary.
- Dynamic Libraries (typically having the .dylib extension) are also used but must be part of a framework bundle. Standalone Dynamic Libraries are not supported on iOS, watchOS, or tvOS, except for the system Swift libraries provided by Xcode.
Frameworks (since iOS 8). A Framework is a hierarchical directory that encapsulates a dynamic library, header files, and resources, such as storyboards, image files, and localized strings, into a single package.
Binary Frameworks (XCFrameworks): Xcode 11 supports distributing binary libraries using the XCFrameworks format, which is a new way to bundle up multiple variants of a Framework, e.g., for any of the platforms that Xcode supports (including simulator and devices). They can also bundle up static libraries (and their corresponding headers) and support binary distribution of Swift and C-based code. XCFrameworks can be distributed as Swift Packages.
Swift Packages: Xcode 11 adds support for Swift packages, which are reusable components of Swift, Objective-C, Objective-C++, C, or C++ code that developers can use in their projects and are distributed as source code. Since Xcode 12, they can also bundle resources, such as images, storyboards, and other files. Since Package libraries are static by default, Xcode compiles them, and the packages they depend on, and then links and combines everything into the application.

You can view native libraries in Grapefruit by clicking on the Modules icon in the left menu bar:

And get a more detailed view, including their imports/exports:

They are available in the Frameworks folder in the IPA you can also inspect them from the terminal:

$ ls -1 Frameworks/
Realm.framework
libswiftCore.dylib
libswiftCoreData.dylib
libswiftCoreFoundation.dylib

Or from the device with objection for iOS (as well as per SSH, of course):

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType      Perms  NSFileProtection    ...  Name
------------  -------  ------------------  ...  ----------------------------
Directory         493  None                ...  Realm.framework
Regular           420  None                ...  libswiftCore.dylib
Regular           420  None                ...  libswiftCoreData.dylib
Regular           420  None                ...  libswiftCoreFoundation.dylib
...

Please note that this may not be a complete list of native code elements used by the app, as some may be part of the source code and therefore compiled into the app binary and hence cannot be found as standalone libraries or Frameworks in the Frameworks folder.

For now, this is all the information you can get about the Frameworks unless you start reverse engineering them. Refer to this for more information on how to reverse-engineer Frameworks.

Other App Resources¶

It is usually worth reviewing the other resources and files you may find in the Application Bundle (.app) within the IPA, as they sometimes contain additional assets such as encrypted databases, certificates, etc.

Tests¶

MASTG-TEST-0223: Stack Canaries Not Enabled MASTG-TEST-0303: References to APIs for Storing Unencrypted Data in Shared Storage MASTG-TEST-0322: App Transport Security Configurations Allowing Cleartext Traffic MASTG-TEST-0065: Testing Data Encryption on the Network MASTG-TEST-0219: Testing for Debugging Symbols MASTG-TEST-0220: Usage of Outdated Code Signature Format

Demos¶