constructor and destructor attributes

Posted: July 16th, 2016 | Author: | Filed under: code injection, Debugging, MacOSX, OS X, Programming | Tags: , , , , , , | 2 Comments »

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:

constructor
destructor
The constructor attribute causes the function to be called automatically before execution enters main (). Similarly, the destructor attribute causes the function to be called automatically after main () has completed or exit () has been called. Functions with these attributes are useful for initializing data that will be used implicitly during the execution of the program.
These attributes are not currently implemented for Objective C.

Note: The GCC documentation tells that these attributes are not implemented for Objective-C. However this seems to work as expected with my tests using Clang ‘clang-703.0.31’ from Xcode 7.3.1.

 
 
Example

Here is an example of C code to demonstrate these attributes:


//
// To compile:
// clang -o constructor constructor.c
//

#include <stdio.h>
 
void constructor() __attribute__((constructor));
void destructor() __attribute__((destructor));

int main()
{
	printf ("main called\n");
	return 0;
}

void constructor()
{
	printf ("constructor called\n");
}

void destructor()
{
	printf ("destructor called\n");
}

When running this application, you will see the following output logs as you would expect:

constructor called
main called
destructor called

 
 
How does it work under the hood?

When you mark functions with these attributes, the compiler will create in your binary the sections called __mod_init_func for the constructors and __mod_term_func for the destructors. These sections contain the list of function pointers. You can use the excellent MachOView to see these sections:


ACTION

When your application is launched, dyld will call the constructors before your main() function is called. This is handled by the following dyld function:

void ImageLoaderMachO::doModInitFunctions(const LinkContext& context)

The destructors are handled by the dyld function:

void ImageLoaderMachO::doTermination(const LinkContext& context)

Since dyld is open source you can look at the implementation in the file ImageLoaderMachO.cpp of dyld. The source code for macOS 10.11.4 is available here.

 
 
Example of use

  • The first obvious usage is to be able to initialize some global variables with a constructor and do some cleanup with a destructor. It could be used to initialize some libraries too.
  •  

  • Another usage is code injection. In a previous post ‘Simple code injection using DYLD_INSERT_LIBRARIES’ I wrote code to replace some methods with an Objective-C +(void)load class method. Using a constructor would allow to inject code earlier in the process.
  •  

  • 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.

Blowfish operations with key size longer than 448 bits in macOS 10.11.5 / iOS 9.3.2

Posted: July 10th, 2016 | Author: | Filed under: iOS, MacOSX, OS X, Programming | Tags: , , , , | No Comments »

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:

ACTION

If you perform a Blowfish operation with a key length longer than 448 bits, it will now fail with an error kCCParamError. Below is an example of code using a 64 bytes Blowfish key that works on macOS 10.11.4 / iOS 9.3.1 but returns an error kCCParamError on newer systems:


#import <Foundation/Foundation.h>
#import <CommonCrypto/CommonCrypto.h>

int main(int argc, const char * argv[])
{
	@autoreleasepool
	{
		uint8_t keyData[64] =
		{
			0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF,
            0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF,
			0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF,
			0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF
		};
		
		CCCryptorRef cryptorRef;
		CCCryptorStatus status = CCCryptorCreate(kCCDecrypt, kCCAlgorithmBlowfish, 0, keyData, sizeof(keyData), NULL, &cryptorRef);
		
		NSLog(@"CCCryptorCreate result: %d", status);
		if(status != kCCSuccess)
		{
			NSLog(@"*** CCCryptorCreate failed!!!");
		}
	}
	
    return 0;
}

If you have to support Blowfish with a key longer than 448 bits, you can’t use anymore CommonCrypto and should switch to a different implementation. Note that using Blowfish with a key longer than 448 bits is not recommended as it weakens the security guaranteed by the algorithm.


State Preservation and Restoration Debug Logs

Posted: July 8th, 2016 | Author: | Filed under: Debugging, iOS, OS X, Programming | Tags: , , , , , | No Comments »

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. To enable this mode set the preference UIStateRestorationDeveloperMode to YES in your main function before the call to UIApplicationMain:

[[NSUserDefaults standardUserDefaults] setBool:YES forKey:@"UIStateRestorationDeveloperMode"];

Identifying the type of build (Build, Archive) at compile time in Xcode

Posted: June 23rd, 2016 | Author: | Filed under: iOS, OS X, Programming, Xcode | Tags: , , , , , | No Comments »

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:


ACTION

The ‘ACTION’ environment variable has 2 interesting values:

  • build: when the app is built
  • install: when the app is archived

Here is what you can do to identify the type of build (Build, Archive) at compile time in Xcode:

  • In the ‘Preprocessor Macros’ (GCC_PREPROCESSOR_DEFINITIONS) in the Builds Settings of your project, add:
     XCODE_ACTION_${ACTION}=1
    
  • In your precompiled prefix header for example, you can now create a define IS_ARCHIVE_BUILD:
    #if XCODE_ACTION_install
    	#define IS_ARCHIVE_BUILD	1
    #else
    	#define IS_ARCHIVE_BUILD	0
    #endif
    

You can then use the define IS_ARCHIVE_BUILD to have a different behavior at compile time. This solution works fine with Xcode 7.3.1 as well as Xcode 8.0b1. It hasn’t been tested with other Xcode versions.


Programmatically lock the screen

Posted: June 5th, 2016 | Author: | Filed under: MacOSX, OS X, Programming | Tags: , , , | No Comments »

The Keychain Access application has a preference to display a “Lock Screen” menu item in the menubar:


Keychain Access Preferences

After enabling the checkbox ‘Show keychain status in menu bar’, this menu will appear in the menubar:


Lock Screen in 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:].


-[AppleKeychainExtra _lockScreenMenuHit:]

That’s this simple! The method -[AppleKeychainExtra _lockScreenMenuHit:] simply calls the private method ‘SACLockScreenImmediate’ from the Login private framework. The Login framework takes care of all the hard work.

Now we can create a simple application to lock the screen. Here is the whole source code:

extern void SACLockScreenImmediate();

int main()
{
    SACLockScreenImmediate();
    return 0;
}

To compile it:

clang -F /System/Library/PrivateFrameworks -framework login -o LockScreen LockScreen.c

You can download the precompiled binary here: LockScreen.zip


Disable swipe to delete in Mail.app on OS X 10.11

Posted: May 10th, 2016 | Author: | Filed under: code injection, MacOSX, Mail, OS X | 5 Comments »

OS X 10.11 ‘El Capitan’ added a new feature to Mail.app ‘Swipe to manage your inbox’:

Swipe to manage your inbox.
Now you can take care of your email with a swipe, just like on your iOS devices. Need to triage your inbox? Swipe right to mark an email as read or unread, or swipe left to delete. You’ll be focused on what’s important in no time.


Swipe To Delete

 

I find this new feature extremely annoying as I keep triggering it by accident. Sadly it seems that there is no preference (even secret preference) to disable this feature. But the good news is that Mail.app supports plugins.

To disable this feature, I created a simple Mail.app plugin. A precompiled version for Mail 9.3 (3124)
(OS X 10.11.4) can be downloaded here: DisableSwipeGesture.mailbundle.zip

 

You can download the source code here : Download ‘DisableSwipeGesture’ Source Code

 

Installation using the precompiled version for Mail 9.3 (3124) – OS X 10.11.4:

  • Download the precompiled version
  • Unzip
  • Copy the file into ~/Library/Mail/Bundles/
  • Relaunch Mail.app

 

Installation for other versions of Mail.app:

  • Download the DisableSwipeGesture source code
  • Open the project in Xcode
  • Build
  • Relaunch Mail.app

 

How does it work?

Mail.app uses a standard NSTableView to support the swipe to delete gesture. It implements the AppKit -tableView:rowActionsForRow:edge: delegate method to add the swipe to delete feature.

Before handling a swipe event, AppKit checks if swipe to delete is supported with the internal method -(BOOL)[NSTableView _allowSwipeToDeleteForEvent:]. The default implementation checks if the NSTableView is a view based tableview and if there is a delegate. The ‘DisableSwipeGesture’ Mail plugin overrides this internal method to always return NO i.e. to never allow swipe to delete. Note that this plugin only changes the behavior of Mail.app, it does not affect any other app. However the same mechanism could be used to disable the swipe to delete feature for any OS X app supporting plugins.

 

Mail.app plugin compatibility

Before loading any plugin, Mail.app checks if the plugin’s Info.plist contains the current Mail.app ‘PluginCompatibilityUUID’ value. If this is not the case, Mail.app will refuse to load the plugin and you will see an alert:


Incompatible Plugin

If you use this ‘DisableSwipeGesture’ plugin and you update Mail.app though an OS X update, you will need to update the PluginCompatibilityUUID value in the Info.plist of the ‘DisableSwipeGesture’ plugin. The simplest solution is to recompile the plugin using the steps provided in ‘Installation for other versions of Mail.app’. The Xcode project has a build phase that will extract the PluginCompatibilityUUID from /Application/Mail.app and copy it into the Info.plist.


Checking if Reduced Motion is enabled on iOS 7

Posted: May 20th, 2014 | Author: | Filed under: Debugging, iOS, Programming | Tags: , , , | No Comments »

Apple introduced in iOS 7.0.3 a setting to reduce motion ( http://support.apple.com/kb/HT5595 ) :
Settings -> General -> Accessibility -> Reduce Motion


Reduced Motion Setting

Sadly there is no public API to know if the user enabled “Reduce motion”.
Here is how to get the value of this setting using a private API. Note that you should not use this code for applications submitted to the App Store.


#include <dlfcn.h>

+ (BOOL) reduceMotionEnabled
{
	BOOL (*_UIAccessibilityReduceMotionFunction)(void) = (BOOL (*)(void)) dlsym(RTLD_DEFAULT, "_UIAccessibilityReduceMotion");
	if(_UIAccessibilityReduceMotionFunction != NULL)
	{
		return _UIAccessibilityReduceMotionFunction();
	}
	else
	{
		NSLog(@"Unsupported: _UIAccessibilityReduceMotion does not exist on this iOS version");
		return NO;
	}
}

Edit: Apple added a public API on iOS 8:

// Returns whether the system preference for reduce motion is enabled
UIKIT_EXTERN BOOL UIAccessibilityIsReduceMotionEnabled() NS_AVAILABLE_IOS(8_0);


QuickLook plugin to preview .strings files

Posted: March 25th, 2014 | Author: | Filed under: Debugging, MacOSX, Programming | Tags: | 2 Comments »

OS X and iOS use .strings files for localized text strings as described in the String Resources Documentation:

Resource files that contain localizable strings are referred to as strings files because of their filename extension, which is .strings.

It is yet annoying that OS X and Xcode don’t provide a built-in QuickLook plugin for previewing .strings files. When you preview such a file in QuickLook you see this window:


Without 'StringsFile' QuickLook plugin

To solve this issue, here is a simple QuickLook plugin called ‘StringsFile’ that lets you preview .strings files (plain text .strings and binary property plist .strings).
This QuickLook plugin is really useful to quickly check the content of a .strings file. When you preview such a file, you will now see:


With 'StringsFile' QuickLook plugin

A precompiled version can be downloaded here: StringsFile.qlgenerator.zip

You can download the source code here : Download ‘StringsFile’ Source Code

Installation:

  • Download the precompiled version
  • Unzip
  • Copy the file into /Library/QuickLook/ or ~/Library/QuickLook/
  • Execute the command “qlmanage -r” in the Terminal – or restart the machine

Update (02.04.2014): The plugin has been updated to also generate a thumbnail for .strings files.


Thumbnail


Detecting the iOS device hardware architecture (32-bit/64-bit)

Posted: October 9th, 2013 | Author: | Filed under: iOS, Programming | Tags: , , , , , | 2 Comments »

In a previous post I explained how to detect if an app runs in a 32-bit or 64-bit iOS Simulator. It was not explaining how to detect if an iOS app runs on a 32-bit or 64-bit iOS device. This post aims at giving a generic method that can detect all cases:

  • 32-bit application running in a 32-bit iOS Simulator
  • 32-bit application running in a 64-bit iOS Simulator
  • 64-bit application running in a 64-bit iOS Simulator
  • 32-bit application running in a 32-bit iOS device
  • 32-bit application running in a 64-bit iOS device
  • 64-bit application running in a 64-bit iOS device

Below is the method is64bitHardware. It returns YES if the hardware is a 64-bit hardware and works on a real iOS device and in an iOS Simulator.
When running in an iOS Simulator, it uses the function is64bitSimulator() from my previous post http://blog.timac.org/?p=886.
When running on a real iOS device, it asks the kernel for the host info.


#include <mach/mach.h>

+ (BOOL) is64bitHardware
{
#if __LP64__
	// The app has been compiled for 64-bit intel and runs as 64-bit intel
	return YES;
#endif
	
	// Use some static variables to avoid performing the tasks several times.
	static BOOL sHardwareChecked = NO;
	static BOOL sIs64bitHardware = NO;
	
	if(!sHardwareChecked)
	{
		sHardwareChecked = YES;
	
#if TARGET_IPHONE_SIMULATOR
		// The app was compiled as 32-bit for the iOS Simulator.
		// We check if the Simulator is a 32-bit or 64-bit simulator using the function is64bitSimulator()
		// See http://blog.timac.org/?p=886
		sIs64bitHardware = is64bitSimulator();
#else
		// The app runs on a real iOS device: ask the kernel for the host info.
		struct host_basic_info host_basic_info;
		unsigned int count;
		kern_return_t returnValue = host_info(mach_host_self(), HOST_BASIC_INFO, (host_info_t)(&host_basic_info), &count);
		if(returnValue != KERN_SUCCESS)
		{
			sIs64bitHardware = NO;
		}
		
		sIs64bitHardware = (host_basic_info.cpu_type == CPU_TYPE_ARM64);

#endif // TARGET_IPHONE_SIMULATOR
	}

	return sIs64bitHardware;
}



Detecting if an app runs in a 32-bit or 64-bit iOS Simulator

Posted: October 1st, 2013 | Author: | Filed under: iOS, Programming | Tags: , , , , | No Comments »

With Xcode 5, it is now possible to compile an application for armv7 and/or arm64.
You can compile an application as 32-bit and/or as 64-bit and you can run this application in a 32-bit or 64-bit iOS Simulator:

In fact there are 3 different cases:

  • 32-bit application running in a 32-bit iOS Simulator
  • 32-bit application running in a 64-bit iOS Simulator
  • 64-bit application running in a 64-bit iOS Simulator

It is possible to distinguish these 3 different cases but this is not as easy as I would expected.

The case of a 64-bit application running in a 64-bit iOS Simulator is simple to solve by just using the define __LP64__: A 64-bit application can only run in a 64-bit iOS Simulator.

Distinguishing the 2 other cases is more difficult and a runtime check is needed. Something to note is that the ‘iOS Simulator’ process is running as 64-bit even in the case of a 32-bit iOS Simulator.

I noticed however that a process called ‘SimulatorBridge’ is used:

  • When launching an 64-bit iOS Simulator, the process ‘SimulatorBridge’ runs as 64-bit
  • When launching an 32-bit iOS Simulator, the process ‘SimulatorBridge’ runs as 32-bit

Running a 32-bit iOS Simulator

Below is a function to know if the iOS Simulator is a 32-bit Simulator or a 64-bit Simulator. The function “is64bitSimulator()” returns true if the iOS Simulator is a 64-bit iOS Simulator:

#include <sys/sysctl.h>

#if TARGET_IPHONE_SIMULATOR

bool is64bitSimulator()
{
	bool is64bitSimulator = false;
	
	/* Setting up the mib (Management Information Base) which is an array of integers where each
	 * integer specifies how the data will be gathered.  Here we are setting the MIB
	 * block to lookup the information on all the BSD processes on the system.  Also note that
	 * every regular application has a recognized BSD process accociated with it.  We pass
	 * CTL_KERN, KERN_PROC, KERN_PROC_ALL to sysctl as the MIB to get back a BSD structure with
	 * all BSD process information for all processes in it (including BSD process names)
	 */
	int mib[6] = {0,0,0,0,0,0};
	mib[0] = CTL_KERN;
    mib[1] = KERN_PROC;
    mib[2] = KERN_PROC_ALL;
	
	long numberOfRunningProcesses = 0;
	struct kinfo_proc* BSDProcessInformationStructure = NULL;
	size_t sizeOfBufferRequired = 0;
	
	/* Here we have a loop set up where we keep calling sysctl until we finally get an unrecoverable error
	 * (and we return) or we finally get a succesful result.  Note with how dynamic the process list can
	 * be you can expect to have a failure here and there since the process list can change between
	 * getting the size of buffer required and the actually filling that buffer.
	 */
	BOOL successfullyGotProcessInformation = NO;
	int error = 0;
	
	while (successfullyGotProcessInformation == NO)
	{
		/* Now that we have the MIB for looking up process information we will pass it to sysctl to get the 
		 * information we want on BSD processes.  However, before we do this we must know the size of the buffer to 
		 * allocate to accomidate the return value.  We can get the size of the data to allocate also using the 
		 * sysctl command.  In this case we call sysctl with the proper arguments but specify no return buffer 
		 * specified (null buffer).  This is a special case which causes sysctl to return the size of buffer required.
		 *
		 * First Argument: The MIB which is really just an array of integers.  Each integer is a constant
		 *     representing what information to gather from the system.  Check out the man page to know what
		 *     constants sysctl will work with.  Here of course we pass our MIB block which was passed to us.
		 * Second Argument: The number of constants in the MIB (array of integers).  In this case there are three.
		 * Third Argument: The output buffer where the return value from sysctl will be stored.  In this case
		 *     we don't want anything return yet since we don't yet know the size of buffer needed.  Thus we will
		 *     pass null for the buffer to begin with.
		 * Forth Argument: The size of the output buffer required.  Since the buffer itself is null we can just
		 *     get the buffer size needed back from this call.
		 * Fifth Argument: The new value we want the system data to have.  Here we don't want to set any system
		 *     information we only want to gather it.  Thus, we pass null as the buffer so sysctl knows that 
		 *     we have no desire to set the value.
		 * Sixth Argument: The length of the buffer containing new information (argument five).  In this case
		 *     argument five was null since we didn't want to set the system value.  Thus, the size of the buffer
		 *     is zero or NULL.
		 * Return Value: a return value indicating success or failure.  Actually, sysctl will either return
		 *     zero on no error and -1 on error.  The errno UNIX variable will be set on error.
		 */ 
		error = sysctl(mib, 3, NULL, &sizeOfBufferRequired, NULL, 0);
		if (error) 
			return NULL;
		
		/* Now we successful obtained the size of the buffer required for the sysctl call.  This is stored in the 
		 * SizeOfBufferRequired variable.  We will malloc a buffer of that size to hold the sysctl result.
		 */
		BSDProcessInformationStructure = (struct kinfo_proc*) malloc(sizeOfBufferRequired);
		if (BSDProcessInformationStructure == NULL)
			return NULL;
		
		/* Now we have the buffer of the correct size to hold the result we can now call sysctl
		 * and get the process information.  
		 *
		 * First Argument: The MIB for gathering information on running BSD processes.  The MIB is really 
		 *     just an array of integers.  Each integer is a constant representing what information to 
		 *     gather from the system.  Check out the man page to know what constants sysctl will work with.  
		 * Second Argument: The number of constants in the MIB (array of integers).  In this case there are three.
		 * Third Argument: The output buffer where the return value from sysctl will be stored.  This is the buffer
		 *     which we allocated specifically for this purpose.  
		 * Forth Argument: The size of the output buffer (argument three).  In this case its the size of the 
		 *     buffer we already allocated.  
		 * Fifth Argument: The buffer containing the value to set the system value to.  In this case we don't
		 *     want to set any system information we only want to gather it.  Thus, we pass null as the buffer
		 *     so sysctl knows that we have no desire to set the value.
		 * Sixth Argument: The length of the buffer containing new information (argument five).  In this case
		 *     argument five was null since we didn't want to set the system value.  Thus, the size of the buffer
		 *     is zero or NULL.
		 * Return Value: a return value indicating success or failure.  Actually, sysctl will either return 
		 *     zero on no error and -1 on error.  The errno UNIX variable will be set on error.
		 */
		error = sysctl(mib, 3, BSDProcessInformationStructure, &sizeOfBufferRequired, NULL, 0);
		if (error == 0)
        {
			//Here we successfully got the process information.  Thus set the variable to end this sysctl calling loop
            successfullyGotProcessInformation = YES;
        }
        else 
        {
			/* failed getting process information we will try again next time around the loop.  Note this is caused
			 * by the fact the process list changed between getting the size of the buffer and actually filling
			 * the buffer (something which will happen from time to time since the process list is dynamic).
			 * Anyways, the attempted sysctl call failed.  We will now begin again by freeing up the allocated 
			 * buffer and starting again at the beginning of the loop.
			 */
            free(BSDProcessInformationStructure); 
        }
	} //end while loop
	
	
	/* Now that we have the BSD structure describing the running processes we will parse it for the desired
     * process name.  First we will the number of running processes.  We can determine
     * the number of processes running because there is a kinfo_proc structure for each process.
     */
	numberOfRunningProcesses = sizeOfBufferRequired / sizeof(struct kinfo_proc);
	for (int i = 0; i < numberOfRunningProcesses; i++)
    {
		//Getting name of process we are examining
        const char *name = BSDProcessInformationStructure[i].kp_proc.p_comm;
		
		if(strcmp(name, "SimulatorBridge") == 0)
		{
			int p_flag = BSDProcessInformationStructure[i].kp_proc.p_flag;
			is64bitSimulator = (p_flag & P_LP64) == P_LP64;
			break;
		}
    }
	
	free(BSDProcessInformationStructure);
	return is64bitSimulator;
}

#endif // TARGET_IPHONE_SIMULATOR