Keyword - Cocoa

Entries feed - Comments feed

Sunday, November 6 2011

Mac OS X Application SandBoxing: what about Apple ?

There is a lot of discussions around the upcoming sandboxing requirement for all the Mac App Store published applications.

There were several publications on the subject with sometimes very elaborate discussion:

These articles lead me to wondering:

  • Apple is going to enforce sandboxing on third-party applications, but what about Apple's own applications ?
  • Sandboxing is said to be a work in progress; the current entitlement keys are sparse and most of the time, developers relies on temporary exceptions to keep their application fully functional. Is there anything in Apple's applications that give a clue of possible entitlement keys ?

So, I decided to take my Terminal and play with the codesign tool. This tool is very useful because if can sign binaries (obviously), but it can also print what is contained in the signature (certificate chain, requirements, entitlements). So I ran it on my Application folder.

cd /Applications
find . -type d -name "*.app" -exec echo {} \; -exec codesign -d --entitlements - {} \;

Here are the applications that contain entitlements (as on 2011-11-06). I have indicated if they mandate the use of sandbox:

  • Address Book
  • App Store
  • FaceTime
  • Font Book
  • Preview (SANDBOXED)
  • TextEdit (SANDBOXED)
  • Activity Monitor
  • Boot Camp Assistant
  • RAID Utility
  • iCal
  • PhotoStreamAgent (in iPhoto)
  • iTunes

Here are the key points:

  • All the Apple applications are signed
  • Only a few of them contain entitlements
  • Only two of them are sandboxed

Digging further into the entitlements, I found:

  • Preview is actually using a temporary entitlement key for global Mach lookup. So don't be shy using them into your applications !
  • A bunch of private entitlement keys: they may be migrated to public entitlement keys as they seems generic.

And finally, here are the private entitlement keys I found:

  • com.apple.private.aps-connection-initiate: it seems related to iCloud, as applications like Address Book, FaceTime, iCal, iTunes and iPhoto (PhotoStreamAgent) have this one.
  • com.apple.private.dark-wake-push: a key to wake up the computer ???
  • com.apple.private.AuthorizationServices: widely used, it seems a good candidate for a future entitlement key.

I hope that by March 2012, Apple would have solved all the details about sandboxing. It would be nice to see a set of versatile entitlement that could protect the end-user and let the developer be inventive.

By letiemble - Apple

Saturday, October 29 2011

Receigen, a smart code generator for Mac App Store receipt validation

Receigen has just been made available in the Mac App Store.

If you are developing an application for Mac and want to distribute it in the Mac App Store, you will be inevitably faced to receipt validation. This entry explains what is receipt validation and why Receigen can help you.

What is receipt validation ?

When you purchase an application from the Mac App Store, it installs into the /Applications folder of your Mac. Inside the application bundle, the Mac App Store application places a receipt file. This file is a record of sale that can be used to check if the installed copy of the application is authorized to run. Apple is providing a comprehensive documentation on the technical issues.

Why do I need receipt validation ?

If you fail to property validate the receipt file, anybody with a copy of your application can run it, with or without proper authorization. This happened to some developpers in the early days of Mac App Store.

What are the steps of validation ?

In order to code the receipt validation, you need to understand:

  • how asymetric cryptography works
  • how signature are attached to a container
  • how ASN.1 encodng/decoding works
  • how to obfuscate code to harden the reverse engineering.

Here is the basic workflow to use when validating a receipt:

  1. Locate the receipt file to load it: this is an easy part as its location is fixed inside the application bundle.
  2. Verify that the receipt is properly signed: the receipt file is a PKCS#7 container that contains the receipt data and that is signed by Apple.
  3. Extract the receipt data: the receipt data are encoded in ASN.1 format, which is a compact binary format widely used in cryptography.
  4. Check that the receipt data matches the bundle information and the machine the application is running on.
  5. Make sure that the checking code is secure. You should hide strings, constants, function calls and make sure that the validation code changes between each release of your application.

Damn, that seems a lot of work

Yes, it is. And I am sure that you have better to do than spending hours on this topic. Receigen has been designed to cope with all this tedious work, by ensuring that you can focus on your application and only your application.

Here is what Receigen brings you:

  • Smart generation of validation code: all it needs is the bundle identifier and version.
  • Seamless integration with Xcode: Receigen can be invoked on the command line easily.
  • Human readable code: Receigen produces a human readable code but still obfuscated when compiled.
  • Never twice the same code: Receigen embeds a code generator that produce a different output each time it is invoked.
  • A tiny price: think about the time you will have spent to produce the same code.

So, go and try out Receigen on the Mac App Store.

By letiemble - Apple

Wednesday, October 19 2011

Mac AppStore receipt validation testing

This entry tries to list all the required step in order to test a Mac App Store receipt validation.

If you look a smart and simple way to generate the receipt validation code, try Receigen on the Mac App Store.

Previously on receipt validation...

For those who are still wondering what is receipt validation, I suggest them to read this document from Applethat explains what receipt validation is; then this page should give them a good reason to properly implement it.

What is required

In order to correctly test receipt validation, you need to:

  • Declare your application on the iTunes Connect portal. Go to Manage Your Applications and file the form. Note that the bundle identifier and the bundle version are important, as they will be used to generate the receipt. Don't forget to file all the information (even the sales/pricing ones).
  • Declare a test account on the iTunes Connect portal. Go to Manage Users and create it.
  • Sign the application with a valid certificate. The receipt retrieval process is only triggered if the application bundle has been properly signed. Development certificate can be fetched from the Mac Dev Center.

How to proceed

Now that all the pre-requisites are ready, you can test your receipt validation code.

  • Launch the application in the Finder. DO NOT LAUNCH it from Xcode !!! The application must be launched by the launchd daemon.
  • If your receipt validation code is ok, then the lack of receipt should make the application exit with a code 173.
  • This exit will trigger the request for a valid receipt. You should see a Mac App Store login window by now. Use the test account credentials to log-in.
  • If the credentials are valid and that the bundle information match the one you entered, then a valid is generated and installed in the application bundle.
  • After the receipt is installed, the application is re-launched automatically.

Conclusion

Comments and feedback are welcomed to improve this entry.

By letiemble - Apple

Sunday, September 18 2011

Monobjc Continuous Integration

The upcoming version of Monobjc 4.0, will be able to run on Mac OS X 10.5, 10.6 and 10.7 operating systems under both i386 and x86_64 architectures. For a complete coverage of this platforms and architectures, the goal is to have these three platforms readily available so non-regression and deployment testing occurs almost seamlessly.

Thanks to Parallels Desktop, I was able to quickly setup two virtual machines running respectively Mac OS X 10.5 and 10.6, on top of a Mac OS X 10.7 system. Then I setp up a Jenkins based continuous integration system driving all the platforms; non-regression testing can now be run on the three platforms easily.

Monobjc CI Infrastructure

By letiemble - Monobjc

Sunday, December 21 2008

Sparkle support in Monobjc

Monobjc 2.0.313.0 was released on December 2008, the 17th. One major addition in Monobjc is the support of Sparkle update engine. Sparkle is one of the most used framework in the Cocoa world, as it makes updating an application a breeze. The main problem with Sparkle in Monobjc was the private framework embedding. With Sparkle, updating a Monobjc application has never been so simple. Check out the tutorial for Monobjc and Sparkle.

By letiemble - DotNet

Saturday, December 13 2008

Monobjc with Delphi Prism

I am pleased to see that Monobjc can be now used with Delphi Prism thanks to RemObjects Software. Marc Hoffman has a nice blog entry about this integration.

By letiemble - DotNet

Monday, August 25 2008

How to put a clickable hyperlink into a static NSTextField ?

The title is pretty clear, and the answer to the question is pretty simple: Technical Q&A QA1487. Et voilà !!!

By letiemble - Monobjc

Monday, August 11 2008

Raytracing with Mono on Mac OS X

A while ago, Luke Hoban implemented a ray-tracing sample application. I have made a Cocoa port of this application by using the Monobjc bridge, and it was over in less than one hour. Here is a screenshot:

Ray Tracer Application in Cocoa

You can download the source code as part of Monobjc.

By letiemble - DotNet

Thursday, January 17 2008

Monobjc is alive (hourray)

After six month of casual development, I am pleased to announce the Monobjc project. The Monobjc project provides a .NET/Objective-C bridge that can be used to add the power of the Mac OS X API (Cocoa, CoreGraphics, WebKit, QuickTime, etc) to .NET application (thanks to Mono).

By letiemble - Monobjc