Did you ever wonder why the Facebook.app for iOS is such a big download? This post tries to give some answers. The version 66.0 (released on 7 October 2016) was analyzed on an iPad Air 2 (64-bit).
Here is what you see when downloading Facebook on an iPad Air 2:
App content A scan of the content of the Facebook app using GrandPerspective gives already a good overview:
In iOS 10 Apple added a new dedicated setting for Temperature Unit in the Settings.app under General > Language & Region > Temperature Unit . It lets you switch your preferred unit between Fahrenheit and Celsius:
Sadly Apple did not provide a public API for third party apps. Here is how you can access this preference in your app:
You first need to expose the NSLocaleTemperatureUnit NSLocaleKey: FOUNDATION_EXPORT NSLocaleKey const NSLocaleTemperatureUnit; You can now print the temperature unit.
In a previous post CryptedHelloWorld: App with encrypted mach-o sections, I created a simple macOS app CryptedHelloWorld with its (__TEXT, __text) section encrypted. The section is decrypted by a constructor function.
This post explains how to dump the decrypted app. A common way is to attach the app with a debugger (GDB, LLDB) and manually dump the decrypted memory to disk.
However I will use a different solution by using 2 techniques already presented in previous posts: a destructor function and code injection.
Mail.app in macOS 10.11 and earlier used to check the plugins compatibility using the SupportedPluginCompatibilityUUIDs key in the plugin’s Info.plist. For example a Mail plugin would only be compatible with macOS 10.11.6 if its Info.plist contained the following:
<key>SupportedPluginCompatibilityUUIDs</key> <array> <string>71562B89-0D90-4588-8E94-A75B701D6443</string> </array> Mail.app version 10.0 in macOS Sierra (10.12) now uses a different key to check the plugins compatibility. It now requires a key with the format Supported%ld.%ldPluginCompatibilityUUIDs where %ld.
In a previous post ( constructor and destructor attributes ), I described the constructor attribute and mentioned software protection as a possible use case:
A constructor attribute could be used to implement a software protection. You could encrypt your executable with a custom encryption and use a constructor function to decrypt the binary just before it is loaded.
In this post I describe such a protection with an example.
GCC (and Clang) supports constructor and destructor attributes:
__attribute__((constructor)) __attribute__((destructor)) Description A function marked with the __attribute__((constructor)) attribute will be called automatically before your main() function is called. Similarly a function marked with the __attribute__((destructor)) attribute will be called automatically after your main() function returns.
You can find the GCC documentation here:
The constructor attribute causes the function to be called automatically before execution enters main ().
Until macOS 10.11.4 and iOS 9.3.1 CommonCrypto/corecrypto supported Blowfish operations with key sizes longer than 448 bits. Starting with macOS 10.11.5 and iOS 9.3.2 this is no longer the case: the minimum and maximum key sizes are now enforced (respectively kCCKeySizeMinBlowfish 8 bytes and kCCKeySizeMaxBlowfish 56 bytes).
This is probably the fix for CVE-2016-1802:
If you perform a Blowfish operation with a key length longer than 448 bits, it will now fail with an error kCCParamError.
The State Preservation and Restoration system is well documented here: Preserving Your App’s Visual Appearance Across Launches.
But what is not well known is that there is a secret preference to enable debug logs. You can set the preference UIStateRestorationDebugLogging to YES in your main function before the call to UIApplicationMain:
[[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"UIStateRestorationDebugLogging"]; There is also a less useful ‘Developer Mode’ secret preference which will skip the deletion of the restoration archive when the app crashes.
Let’s say you want to have a different behavior in your app depending on whether you build it in Xcode or you perform an Archive. And you want this behavior to be done at compile time. Note that the use of different configurations is not what is wanted.
Here is a solution using the ACTION Xcode property build setting. This property is documented in the Xcode Build Setting Reference:
The Keychain Access application has a preference to display a “Lock Screen” menu item in the menubar:
After enabling the checkbox Show keychain status in menu bar, this menu will appear in the menubar:
This menu is located here: /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu
and it is fairly easy to find the method -[AppleKeychainExtra _lockScreenMenuHit:].
That’s this simple! The method -[AppleKeychainExtra _lockScreenMenuHit:] simply calls the private method SACLockScreenImmediate from the Login private framework.