A year ago I analyzed how many built-in apps in iOS 10.1 and macOS 10.12 were using Swift: Apple’s use of Swift in iOS 10.1 and macOS 10.12.
How many built-in apps are using Swift in iOS 11.1 and macOS 10.13.1? Let’s find it out!
Tool to detect binaries using Swift Last year I explained how to write a script that loops through all the files of a folder and print the paths of binaries using Swift.
Swift Optionals and force unwrapping The Swift programming language supports optional types, which handle the absence of a value. An optional represents two possibilities: Either there is a value and you can unwrap the optional to access that value, or there isn’t a value at all.
Here is how you can declare an optional variable in Swift:
var myOptionalString: String? The myOptionalString variable can contain a string value or nil.
Let’s say you pick a random pointer. Can we know if it points to a valid Objective-C object? Of course without crashing… Well there is no simple solution. In this post I give a solution for 64-bit architectures. The code provided has only been tested on macOS 10.12.1 and iOS 10.1.1 with the modern Objective-C runtime.
There is not much documentation available on this subject. There is one article written in 2010 by Matt Gallagher but the content is outdated and not working properly anymore.
Swift has been announced at the WWDC 2014, more than 2 years ago. Most of the sample code projects from Apple are now written in Swift. But does Apple use Swift in iOS 10.1 and macOS 10.12.1?
How to detect if a binary is using Swift? A naïve approach would be to check if an app contains the Swift libraries in its Frameworks folder: libswiftCore.dylib, libswiftFoundation.dylib, …
Here is the content of the Frameworks folder of the MRT.
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.