Skip to main content

Binary Protections

There are certain protections that should be in place on the main application executable for things like stack protection, ASLR, and memory management.

For iOS apps, this can be obtained from the otool command, which is part of the Xcode Command Line tools that should be installed on your macOS system.

Extract the IPA file​

The $BINARY that is used in the examples below refers to the main app executable file.

% unzip -qq ExampleApp.ipa
% cd Payload/Example.app
% plutil -p Info.plist | grep CFBundleExecutable
"CFBundleExecutable" => "example"

So, in this example, $BINARY is the file named example in the "Payload/Example.app" directory.

Check for Stack Protection​

The iOS compiler can set a stack canary to help prevent buffer overflows:

% otool -Iv $BINARY | grep __stack_chk

Your output should be similar to this:

% otool -Iv $BINARY | grep __stack_chk_guard
0x0000000100541b94 29059 ___stack_chk_fail
0x00000001006988b8 29060 ___stack_chk_guard
0x00000001006998b0 29059 ___stack_chk_fail

Note: This is for apps written in Objective-C or that use the Objective-C Bridge with Swift. Consult the App Type page to determine this. If the app is written in pure Swift, then this check will fail because Swift has strict buffer protections built-in.

Check for Position Independent Executable​

Position Independent Executable (PIE) is part of the address space layout randomization (ASLR) implementation.

% otool -hv $BINARY

Your output should be similar to this:

% otool -hv $BINARY
MH_MAGIC_64 ARM64 ALL 0x00 EXECUTE 55 6360 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE

Note: These checks are not applicable to libraries and Frameworks that the app may be using. In an iOS application, dynamic libraries are loaded at a specific offset from the main executable, in the higher ranges of the app memory space. As long as the main executable of the app has PIE enabled, then any dynamic library will effectively have it as well, since it is based on where the executable is loaded, which will be different every time.

Check for Automatic Reference Counting​

Automatic Reference Counting (ARC) is a way of managing object related memory. Prior to ARC, the developer had to keep track of every allocation of memory and ensure that it was released properly. The lack of ARC is not necessarily a finding. It is just a warning that you may want to test for further memory-based vulnerabilities.

% otool -Iv $BINARY | grep -iw _objc_autorelease

Your output should be similar to this:

% otool -Iv $BINARY | grep -iw _objc_autorelease
0x000000010054184c 29398 _objc_autorelease
0x0000000100699680 29398 _objc_autorelease