AirPlay and how does it work?

AirPlay is the Apple way for sharing media between your Apple devices. You can share music, photos and videos from an iPhone, iPad, or Mac to an Apple TV and it is also possible to share music to an Airport Express with attached speakers. Apple has licensed the audio streaming part of the AirPlay protocol to different manufacturers so third party devices can be used to receive AirPlay streams.

Beside the possibility to stream content from an IOS or OSX device it is also possible to use the AirPlay mirroring function. With this function you can use a tv as a second screen. Because the mirroring image feed is encoded using the H.264 codec more recent hardware is required. This more recent hardware uses the graphic card for the encoding process. The following devices (and newer) can be used:

• iPad 2
• iPad mini
• iPhone 4S
• iPod touch
• iMac, Mac mini, Macbook Air (mid 2011) + (Mountain Lion)
• MacBook Pro (early 2011) + (Mountain Lion)
• Apple TV (2nd or 3rd generation)

AirPlay mirroring does also require a fast and stable Wi-Fi connection, I would suggest using the 802.11n standard on 5GHz. This gives the most stable experience, especially in crowded Wi-Fi environments.

AirPlay discovers other devices with the Bonjour protocol. Because of this no extra configuration in the network is needed. When your are using a company network and the amount of apple devices grows you should think about the fact that Bonjour is a chatty protocol. Some companies that are using large numbers of Apple devices have seen a peak in multicast traffic after introducing IOS and OSX devices. To solve this problem you could use different SSID’s / different subnets for de IOS and OSX devices. The details of the AirPlay protocol are not officially made public by Apple but with reverse engineering people have discovered the details and published them unofficially. You can find this information on

http://nto.github.io/AirPlay.html

In the following part you will find a bandwidth usage tests for AirPlay mirroring. I have used the following test scenario:

Devices:

• MacBook Pro 13 inch, late 2011, i5 2.4 GHz, 4GB memory.
• Apple TV, 3th generation.
• Apple Airport Extreme, 5th generation.

Network:

• 802.11n 2,4GHz network

Tests:

• Mirroring desktop, MacBook Pro –> Apple TV
• Mirroring video, MacBook Pro –> Apple TV

(The test is conducted with a 720p video file)

Results:

Mirroring the desktop from the MacBook Pro to the Apple TV uses between 350KB/s and 1,3 MB/s and this delivered a good result. When playing a video on the MacBook Pro the usage varies between 1,5MB/s and peaks of 3,6MB/s. Normally the bandwidth should be sufficient to deliver a smooth video playback. In reality I experienced some hiccups. It is possible that the Wi-Fi network has a problem with some interference and cannot deliver a stable connection. Normally you would not notice this but because the mirroring feed cannot be buffered, every hiccup will be visible. When you are experiencing these problems you should try another channel for your Wi-Fi network or switch to the 5GHz band. I have switched to the 5GHz network and didn’t had any more hiccups in the playback.

In practice an 802.11g network will be sufficient for AirPlay streaming but you will see buffering problems when using AirPlay mirroring. When using an 802.11n 5GHz network you normally should be good. I hope I have given you some interesting and helpful facts about the Airplay protocol.

Advertisement

Sysprep techniques for OS X machines

It is possible to deploy OS X with different tools, for larger over the network deployments it is preferable to use DeployStudio or Apple’s NetInstall software. DeployStudio is the most preferable option because you have a truckload of customization option. In a future blogpost I want to discuss these options. For now I want to look at some OS X sysprep techniques you can use for small scale sneakernet deployments.

The first thing you want to do is choosing an OS X machine that will function as image builder. Keep in mind when you choose your hardware you cannot deploy the created image on a newer generation of hardware. So when you have an image build on a 2009 iMac you cannot use this image on a 2012 iMac. This will most likely not work at all and if the system boots it will be unstable or you cannot use some features. In contrary, if you use an 2012 iMac for building the image you will be able to deploy this image on 2009 iMacs.

When you have chosen a machine you make a clean OS X installation. After the installation you apply updates and install all software you want to include in the image. When you are ready to create the image there are some sysprep techniques that can be used.

The first technique is not really a sysprep one but this can still be very useful!

Making an hidden admin account:

sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add %user%

Before applying the command you need the create the admin account in OS X. With this command the user sees his own account at login where he only needs the enter his password. Next to the users account a separate login window is displayed where both the username and password needs to be entered.

Reactivate the startup wizard at reboot:

sudo rm -rf /var/db/.AppleSetupDone

With this command the first time wizard will reappear after rebooting the machine. When you have deployed the image and the system is rebooted it will show the wizard where the user can enter his own password, information and settings.

Delete swapfiles: 

rm /private/var/vm/swapfile*

This says it all, it deletes the swapfile.

Clean up caches and temp data:

rm -rf /Library/Caches/*
rm -rf /System/Library/Caches/*
rm -rf /Users/Shared/*
rm -f /private/etc/ssh_host*

With these commands you clean-up the system caches and temporary data.

Clean up log files:

rm /private/var/log/%specifylog%
touch /private/var/log/%specifylog%

There are a lot of different log files in OS X. I will give you some examples:

• /alf.log
• /cups/access_log
• /cups/error_log
• /cups/page_log
• /ftp.log*
• /httpd/*
• /lastlog
• /mail.log*
• /secure.log
• /system.log*

It is important to use the touch command after each removal because syslog will not recreate a missing log on his own.

After you have used the above commands to create a clean image the system can be rebooted. You can now start from an external disk and use the disk utility to create an image from the system disk.

FileVault

FileVault is a OS X build-in method for on the fly encryption and decryption of your internal hard disk. OS X Lion and Mountain Lion are using FileVault 2, with version 2 it is possible to encrypt the entire disk and not only the users home folder. FileVault uses the XTS-AES 128 encryption and because of CPU optimizations there is almost no noticeable performance issue with the on the fly encryption and decryption process.

Booting from an encrypted system disk is not possible. So apple needed to think of something to authenticate the user and start decrypting the system disk before accessing it. Apple designed it to boot from the recovery partition and present the login window. When a user enters the right credentials the decryption key is accessed, with the decryption key the system volume is decrypted.

FileVault can be enabled by going to the Security and Privacy pane in the system preferences. When enabling FileVault on systems with multiple local users it is possible to allow every user to unlock the computer. During the setup you will get a recovery key, this key can be used if all the user passwords are lost. The recovery key should be stored somewhere safe!

You can also choose to store the recovery key with Apple. To do this you need to choose three questions and provide three answers. After storing the recovery key the systems needs to restart. When the system is restarted the encryption process begins. During the encryption process the mac can be used normally. With the following command the process can be watched in the terminal:

diskutil cs list

In the output you can see after “Size (Converted):” how many GB have been encrypted so far.

When the process is finished the result will be “-none-“. The process can also be monitored in the FileVault menu:

When booting your system and you have forgotten your password you can enter your recovery key after three bad passwords. With the recovery key the system disk is decrypted and after the boot it is possible to set a new password. When the recovery key is stored with Apple you need to call AppleCare. Here you give the macs serial number and answer the three security questions. When the recovery key is lost and it is not stored with Apple there is no way to recover the data on the disk.

Keychains

I want to tell you briefly about the keychain system in OS X. Keychains are used to store sensitive critical data. You can think of:

• Resource passwords (only if allowed to save)
• Wireless passwords
• Kerberos items
• Certificates
• Keys
• Website forms
• Secure notes

Only the account password is not stored in the keychains.

The keychains are files encrypted with the Triple DES algorithm and located in different locations.

• /Users/%username%/Library/Keychain/login.keychain

The login.keychain is automatically created for every user and is unlocked when the user successfully logs in. This keychain contains user specific items.

• /Library/keychain/System.keychain

Non user specific items are stored in the System.keychain. Here you can find wireless passwords, network passwords and Kerberos items. Only administrators can make changes in this keychain.

• /Library/Keychain/FileVaultMaster.Keychain

This keychain can only be opened with the File Vault master password. I will make a future blog post about File Vault where this is explained.

• /System/Library/Keychains

This is also a keychain where only administrators can make changes. It is used to store root certificates.

With the Keychain Access application found in /Applications/Utilities you can open and edit the keychain. You can add, delete and modify entries. It is also possible to repair keychains. The keychain Access application opens with the user’s login.keychain as a default. Here you see different entries and you can resolve passwords. If you want to show a password you will be prompted for the user account password.

As mentioned earlier the login.keychain password is the same as the user account password. When a user changes his password the login.keychain password is also changed but if the password is reset by an administrator the login.keychain password is not changed. When the user logs in after a reset by an administrator there will be the following prompt:

The user can choose to update the keychain password but fore this the user needs to remember his forgotten password. So normally the user needs to create a new keychain. This new keychain is then created with the new user password. Because there is a new keychain the saved password etc. from the old locked keychain are not present anymore.

The old keychain is saved in the user’s  ~/Library/Keychains folder. It can still be unlocked with the Keychain Access application when the user remembers the old password. If OS X can’t open the keychain and it is corrupted you can repair it with the Keychain Access application. In the Keychain Access menu you can choose Keychain First Aid. Here you need to enter a username and password, select the repair option and click on the Start button.

Nice little extra: If you travel a lot and want to take notes etc. securely with you, you can safe them in a keychain file. With the Triple DES encryption the keychain file is securely encrypted and you can only open the keychain again with the password you used to create the keychain.

Apple XProtect

In the past couple of months Apple has blocked unsafe versions of Java and Flash for OS X systems. Because of this, older Java and Flash versions are suddenly not working anymore. Sometimes the software developer needs to develop a bugfix or the user needs to update to the latest version of the used software.

So how can Apple remotely block software on your system? The answer is: XProtect. I will give you a short overview of this protection mechanism in this blogpost.

Since OS X v10.6 the XProtect framework checks every download for malicious code. The XProtect definitions where updated with the normal OS X software update. Recently Apple released an update for the XProtect framework so it can check for updates on itself. This way Apple can react faster on potential threads.

This mechanism is controlled with the XProtect.plist file. This file can be found in the following location:

System -> Library -> CoreServices -> CoreType.bundle -> Contents -> Resources

Here you can also see the XProtect.meta.plist file. In this file you can find the version number, this is used to check if an update is needed. Here you can also find software that is blocked.

When you open the XProtect.meta.plist file with an texteditor it is possible to change the string value of blocked software so that older versions of the software are usable. Keep in mind that it is blocked with a reason.

It is possible to turn the automatic update feature of XProtect off. You can do this by going to the following location:

Preferences -> Security -> General -> Advanced

Here you can choose to turn the automatic update feature off. If you want to force a manual update of the definitions you can run the following command in a terminal.

sudo launchctl start com.apple.xprotectupdater

It is nice to have a build in solution to protect users. But you always need to remember the fact that XProtect is not a antivirus replacement. The on-access scanning from known antivirus products reacts a lot faster than the XProtect mechanism. To be as safe as possible I would suggest using XProtect in combination with a known antivirus product.