0xced

How to restore Apple Front Row Trailers

2011-05-26T00:40:00.001+02:00

Comme vous avez pu le constater, Front Row Trailers ne fonctionne plus. Étant donné que Front Row est absent de Lion, je ne mettrai plus à jour Front Row Trailers.

Voici donc la méthode pour remettre les bandes-annonces originales d'Apple:

Téléchargez et décompressez Restore Apple Trailers
Double-cliquez sur le fichier Restore Apple Trailers.command
Entrez votre mot de passe

As you probably have noticed, Front Row Trailers is not working anymore. Since Front Row is missing in Lion, I have no plan to update Front Row Trailers.

So here is how to restore factory Apple trailers:

Download and decompress Restore Apple Trailers
Double-click on Restore Apple Trailers.command
Enter your password

Using Ingredients as Xcode documentation browser

2011-02-14T10:24:00.001+01:00

Xcode 3.2.3 documentation browser was quite broken: ⌘ + ⌥ + double click on a method or function would open the documentation browser but would not scroll to the method you just asked documentation for. So I started to write an Xcode plugin to open Ingredients instead. Then Xcode 3.2.5 was released (I skipped version 3.2.4) and this annoying bug was fixed, so I did not bother to publish my plugin. But recently, I read on twitter that [RED4CTED] documentation browser was even more broken, so I decided it was time to release my Xcode-Ingredients plugin.

Note that the plugin is written for Xcode 3, so things have probably changed in [RED4CTED] (which I have not yet tried). If you are brave enough to use [RED4CTED], that you know a bit about Xcode plugins (@kodz, @rentzsch, @tjw?) and that you would like to use Ingredients for reading the documentation, please have a look and adapt the plugin for [RED4CTED]. In order to discover the searchForAPIString: method, I just set a breakpoint on makeKeyAndOrderFront: and looked at the backtrace, but I'm not sure if this technique is still applicable.

I will update this blog post as soon as someone can get the plugin to work with [RED4CTED].

CLLocation getDistanceFrom: vs distanceFromLocation:

2010-09-11T13:46:00.001+02:00

In Backwards Compatibility if Apple Starts Polishing, Oliver Drobnik explains how he solved the getDistanceFrom: vs distanceFromLocation: problem. His solution involves a new method (distanceBetweenLocation:andLocation:) and eight lines of code for calling getDistanceFrom: through a NSInvocation.

Wouldn't it be nice if instead you could use [aLocation distanceFromLocation:anotherLocation] everywhere in your code, while still retaining backward compatibility? Enter the Objective-C runtime! In your main.m file, first #import <objc/runtime.h> and at the very beginning of your main function, add this:


Method getDistanceFrom = class_getInstanceMethod([CLLocation class], @selector(getDistanceFrom:));
class_addMethod([CLLocation class], @selector(distanceFromLocation:), method_getImplementation(getDistanceFrom), method_getTypeEncoding(getDistanceFrom));

Here you go, -[CLLocation distanceFromLocation:] available at runtime in any iOS version with only two lines of code. Note that on iOS 3, class_addMethod will add the distanceFromLocation: method to the CLLocation class using getDistanceFrom: implementation. On iOS 4, class_addMethod will do nothing as the method already exists.

Using SDK 3.1.3 with iPhone SDK 4

2010-07-02T18:38:00.011+02:00

In iPhone SDK 4 Apple has removed all 3.x SDKs. I think that was not a very good idea to say the least. I can understand Apple wants developers to adopt the new features of iOS 4, but breaking zillions of Xcode projects is probably not a good way to win the hearts of those developers. Well, this is probably not Apple's goal anyway.

Sure there is a way to get your projects working again with the iPhone SDK 4, just set the Base SDK of your project to iOS 4:

and set the Deployment Target to iOS 3:

This will get your projects compile and run again on both iOS 3 and 4. That's fine. Well, except when you want to make sure your project do not use any new iOS 4 only API.

The problem is, code like this will now compile without any warning or error:

[[NSUserDefaults standardUserDefaults] setURL:defaultURL forKey:@"DefaultURL"];

It's easier than you think to use a shiny new API without even noticing you are using something not available on iOS 3. This setURL:forKey: method is new in iOS 4 so this code will fail with an unrecognized selector exception when run on iOS 3. Unfortunately, the only way to catch this kind of oversight is to run it on an iOS 3 device. Or you can read the documentation of every single method and function you are calling to make sure it was not introduced in iOS 4. But this does not seem very reasonable, does it? The tools should help us detecting these problems at compile time, not runtime!

Here is how to get Xcode 3.2.3 and iPhone SDK 4 working with SDK 3.1.3.

Log in to the iOS Dev Center
Download the iPhone SDK 3.1.3 into ~/Downloads
Run the install-iphone-sdk-3.1.3.sh script
Quit and relaunch Xcode
Duplicate your Debug configuration and rename it to SDK 3.1.3 Check
Set the Base SDK of this new configuration to iPhone Simulator 3.1.3
Add a User-Defined Setting GCC_OBJC_ABI_VERSION and set its value to 1 (one)
Select GCC_OBJC_ABI_VERSION and choose Add Build Setting Condition from the gear pop-up button at the lower left of the window.
Select Any iPhone Simulator and Any Architecture

There you go! By selecting the SDK 3.1.3 Check configuration, you get compile time check for misusing iOS 4 only APIs when targeting iOS 3.

Note that compiling with the iPhone Simulator 3.1.3 SDK and running in Xcode 3.2.3 simulator is not supported. What you get with this hack is just a compile time check of the APIs you are using. So do not expect to run your app on a 3.1.3 simulator.

Fixing -[NSMutableURLRequest setValue:forHTTPHeaderField:]

2010-06-02T08:51:00.017+02:00

The problem

From NSMutableURLRequest setValue:forHTTPHeaderField: documentation:

In keeping with the HTTP RFC, HTTP header field names are case-insensitive.

I see three problems with this.

Assuming all HTTP implementations are RFC compliant is foolish to say the least.
Enforcing case-insensitivity is nonsense.
This bit of documentation is accurate, the case of header fields is actually changed.

Trying this

    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://www.example.com"]];
    [request setValue:@"MyValue" forHTTPHeaderField:@"MyField"];
    NSLog(@"result: %@", [request allHTTPHeaderFields]);

outputs

    result: {
        Myfield = MyValue;
    }

Notice how the 'F' of MyField was lowercased, that sucks! If the HTTP server you are trying to communicate with is case-sensitive, you are screwed. I filed radar #8029516, which is a duplicate of radar #3131623, which means there is almost no chance to have this fixed anytime soon.

When this happens, you should contact the server administrator asking for a case-insensitive implementation. But in the meantime, if you badly need to preserve the case of your headers, read on.

The investigation

First, let's fire otx to disassemble the Foundation framework in order to have a look at setValue:forHTTPHeaderField: implementation. I strongly suggest you to use otx version from subversion trunk, as it is better at resolving symbols in tail call optimizations (fixed in r553).

Excerpt from otx 0.16b:

   +18  [...]  movl     %eax,0x08(%ebp)
   +21  [...]  leave
   +22  [...]  jmpl     0x002c52bb

Excerpt from otx trunk:

   +18  [...]  movl     %eax,0x08(%ebp)
   +21  [...]  leave
   +22  [...]  jmpl     0x002c52bb       _CFURLRequestSetHTTPHeaderFieldValue

Much better, isn't it?

So let's go through the function calls of setValue:forHTTPHeaderField:. With a basic static analysis of the Foundation and CFNetwork disassemblies, we can draw the following call path:

-[NSMutableURLRequest(NSMutableHTTPURLRequest) setValue:forHTTPHeaderField:]
    CFURLRequestSetHTTPHeaderFieldValue()
        URLRequest::setHTTPHeaderFieldValue()
            HTTPRequest::setHeaderFieldValue()
                CFHTTPMessageSetHeaderFieldValue()
                    HTTPMessage::setHeaderFieldValue()
                        _CFCapitalizeHeader()

_CFCapitalizeHeader looks like a very good candidate for being the bastard changing the case of our headers. A quick search reveals the source code of CFNetwork that was open source long time ago. Although the open source implementation does not exactly match what we see in the disassembly (it is now using toupper instead of ch + 'A' - 'a' for example), we are now absolutely sure that _CFCapitalizeHeader is the function responsible for messing with our headers.

Now, let's check is if there is a path that will not call _CFCapitalizeHeader and if we can somehow influence the condition that would avoid the call to _CFCapitalizeHeader. This is quickly checked, especially if you enabled the Separate logical blocks option of otx (-b option for cli).

HTTPMessage::setHeaderFieldValue(__CFString const*, __CFString const*)
    +0  000515a4  55                      pushl       %ebp
    +1  000515a5  89e5                    movl        %esp,%ebp
    +3  000515a7  83ec28                  subl        $0x28,%esp
    +6  000515aa  8b4508                  movl        0x08(%ebp),%eax
    +9  000515ad  8975f8                  movl        %esi,0xf8(%ebp)
   +12  000515b0  8b7510                  movl        0x10(%ebp),%esi
   +15  000515b3  897dfc                  movl        %edi,0xfc(%ebp)
   +18  000515b6  8945f4                  movl        %eax,0xf4(%ebp)
   +21  000515b9  8b450c                  movl        0x0c(%ebp),%eax
   +24  000515bc  890424                  movl        %eax,(%esp)
   +27  000515bf  e88a26fbff              calll       __CFCapitalizeHeader
   +32  000515c4  c744240cffffffff        movl        $0xffffffff,0x0c(%esp)
   +40  000515cc  89742408                movl        %esi,0x08(%esp)
   +44  000515d0  89c7                    movl        %eax,%edi

We see that there is no path that avoid the call to _CFCapitalizeHeader. So we are left with the last resort solution: patching _CFCapitalizeHeader. With APE Lite, function patching is very easy. You first use APEFindSymbol() to find the address of a non-exported symbol (i.e. __CFCapitalizeHeader), then APEPatchCreate() to replace a function implementation with your own, while still keeping a reference to the original implementation. On iPhone OS, you can use APE Lite+arm (my implementation of the APE Lite API using MobileSubstrate).

The solution

NSMutableURLRequest+CaseSensitive is a category on NSMutableURLRequest that adds these three methods:

   - (void) setAllHTTPHeaderFields:(NSDictionary *)headerFields caseSensitive:(BOOL)caseSensitive;
   - (void) setValue:(NSString *)value forHTTPHeaderField:(NSString *)field caseSensitive:(BOOL)caseSensitive;
   - (void) addValue:(NSString *)value forHTTPHeaderField:(NSString *)field caseSensitive:(BOOL)caseSensitive;

Just pass caseSensitive:YES for preserving the case of your header fields.

Warning: you SHOULD NOT use this in production code. But hey, HTTP implementations SHOULD be case-insensitive ;-)

ABGetMe with the iPhone SDK

2010-04-08T10:27:00.005+02:00

Unlike the Mac Address Book API, the iPhone Address Book API does not come with the ABGetMe function. That's a pity, but we can do something about it.

Recently, I used MFMailComposeViewController for the first time and I realized that it was displaying my e-mail address. Nicolas Seriot already demonstrated how to retrieve all your e-mail account information in SpyPhone, but I felt there was a more lightweight method for retrieving the e-mail addresses by taking advantage of the MessageUI framework. A class-dump and five minutes later, here is my solution:

Jasscore pour iPhone

2010-01-03T11:22:00.011+01:00

Ma première application iPhone, Jasscore (lien iTunes) est enfin disponible sur l'AppStore au prix de 1.10 CHF. C'est une ardoise virtuelle qui vous permet de compter vos points et ceux de votre adversaire au jass (chibre, mise, etc.)

Les features

En français et en allemand
Editez le nom des équipes et les scores à atteindre
Notez les scores et les annonces
Multiplication des scores de 1x à 7x
Grand affichage afin que tous les joueurs puissent suivre les scores

Les captures d'écran

Je suis ouvert à vos suggestions, alors n'hésitez pas à laisser un commentaire ou à m'envoyer un e-mail.

CLAlert: NSAlert done right

2009-11-07T17:30:00.002+01:00

From NSAlert documentation:

Currently, there is no visual difference between informational and warning alerts.

This was written at the time of Panther and this is still true in Snow Leopard. So why the hell is the setAlertStyle: method provided?

NSCriticalAlertStyle
This style causes the icon to be badged with a caution icon.

A caution icon, for a critical alert? That does not make sense!

Here are screenshots of the default behaviours with the three different alert styles:

The documentation is unfortunately right: there is no difference between the informational and the warning style. The critical style is indeed badged with a caution icon.

As you probably have guessed from the title of this post, I am not happy with this behavior, so I have written a class, CLAlert (MIT License) that displays alerts the way I think it should be done. I.e. a note icon for an informational alert, a caution icon for a warning alert and a stop icon for a critical alert as you can see on these screenshots.

CLAlert is a drop-in replacement for NSAlert. It requires at lest Mac OS X 10.5.

Watch a large number of icons with Preview.app

2009-11-05T21:49:00.007+01:00

Browsing .icns files in Preview.app can be painful. If you try to open all the icons of the CoreTypes bundle for example with the following command

open /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/*icns

you will get this view:

All the different sizes of the .icns are displayed, which makes it quite unpleasant to browse.

F-Script Anywhere to the rescue!

Install F-Script Anywhere into Preview, then do

FSA → New F-Script Workspace

Click the Browser For Target… button

Click on one of the icons

Choose the PVIKImageBrowserView object

In the F-Script Object Browser, name the PVIKImageBrowserView browserView

Finally, in the F-Script interpreter, paste the following code:

groups := browserView layoutManager groups.
count := groups count.
0 to:count-1 do: [:i | browserView collapseGroup:(groups objectAtIndex:i)]

Tada, a nice browsable view of your icons!

Booting from a dmg

2009-08-19T17:41:00.003+02:00

I was pointed by Jean-Francois Roy that it is possible to boot off a dmg.

It's a simple two steps process using bootfolder:

./makebootfolder /Path/to/OperatingSystem.dmg
sudo ./blessbootfolder /Path/to/OperatingSystem.bootfolder

But beware: you better not have a space in the path to the dmg or in the dmg itself. If you happen to try this trick with a space in the path to the boot folder, then your Mac will brick. In verbose startup, you will get

Error loading kernel 'mach_kernel' (0x9)

If you can't boot anymore, download rEFIt and burn it onto a CD. Then boot on the CD by pressing the C key. You should see something looking like this (maybe without the linux and windows partitions):

Just press enter and you should be able to boot your Mac.

Extract UIKit artwork

2009-04-08T22:39:00.008+02:00

While writing an iPhone application (more about it on this blog soon), I wanted to tint my UIAlertView with the same color I tinted my other controls. Maybe this is not a good idea, but I wanted to try anyway. Unfortunately, only UISearchBar, UISegmentedControl, UINavigationBar and UIToolbar have the tintColor property. So I started digging into UIKit. The first place to look was obviously the -(void)[UIAlertView(Private) drawRect:] method. To draw its background, a UIAlertView calls _popupAlertBackground which in turn call _UIImageWithName(@"UIPopupAlertSheetBackground.png"). This file probably lies inside the UIKit.framework would think a Mac developer. In fact it is not there. Only two pngs are there: DefaultWallpaper-iPhone.png and DefaultWallpaper-iPod.png. So, where is it?

It is in fact somehow embedded in the Other.artwork file which contains UIKit artwork. This file is memory mapped at application startup, probably for performance reasons and the content is easily accessed with the private _UIImageWithName() function. _UIImageWithName looks up in a dictionary that associates a file name to some memory location that contains the actual image data.

Now, it would be cool to extract all this content to see what artwork UIKit contains. It turns out to be quite easy. The only trick is to find a reference to the dictionary containing all the file names. Check my UIKit Artwork Extractor project on github to see how it works.

In an attempt to encourage comments, I'm offering a beer at NSConference to the first person who will clearly explain how to find the magic address of the images dictionary (except for Nicolas who knows the answer already) and I'm offering two beers to the one who provides a cleaner way to obtain a reference to the dictionary that is not UIKit version specific ;-)

Edit: I have updated the code so that it is not UIKit version specific, so I won the beers myself that I'm going to drink right away.

chmod, ACL and symbolic links

2009-03-23T09:34:00.016+01:00

Let's say you want to set an ACL on a symbolic link. So you try the -h option of chmod that is documented to change the mode of the link itself rather than the file that the link points to.

  $ ln -s aFileThatDoesNotExist myLink
  $ /bin/chmod -h +a "everyone allow delete" myLink
  chmod: Failed to set ACL on file 'myLink': No such file or directory

So, it seems myLink was followed even though we passed the -h option. Let's try with a link that points to an existing file:

  $ touch aFileThatExist
  $ ln -fs aFileThatExist myLink
  $ /bin/chmod -h +a "everyone allow delete" myLink
  $ ls -le myLink aFileThatExist
  -rw-r--r--+ 1 cluthi  staff   0  5 mar 18:11 aFileThatExist
  0: group:everyone allow delete
  lrwxr-xr-x  1 cluthi  staff  14  5 mar 18:12 myLink -> aFileThatExist

Our hypothesis is confirmed, the link was followed. Let's investigate and have a look at chmod source code (file_cmds-188 on darwinsource).

chmod.c:125 variable hflag is set to true if the -h argument is passed
chmod.c:388 function modify_file_acl() is called, the hflag is not passed to this function

Doh, lazy boys! Let's patch it and add a follow argument to the modify_file_acl() function:
int modify_file_acl(unsigned int optflags, const char *path, acl_t modifier, int position, int inheritance_level, int follow);
and call it with modify_file_acl(..., !hflag)

From acl_set(3) man: The acl_set_link_np() function acts on a symlink rather than its target, if the target of the path is a symlink. Perfect, that's what we need: we must call acl_set_link_np instead of acl_set_file in order not to follow the link.

chmod_acl.c:807 acl_set_file is called: (0 != acl_set_file(path, ACL_TYPE_EXTENDED, oacl))
Replace with (0 != (follow ? acl_set_file(path, ACL_TYPE_EXTENDED, oacl) : acl_set_link_np(path, ACL_TYPE_EXTENDED, oacl)))

With this small modifications, the -h option should be respected. Rebuild chmod and try again:

  $ ./chmod -h +a "everyone allow delete" myLink
  chmod: Failed to set ACL on file 'myLink': Operation not supported
  $ ln -fs aFileThatDoesNotExist myLink
  $ ./chmod -h +a "everyone allow delete" myLink
  chmod: Failed to set ACL on file 'myLink': Operation not supported

Now, whether the link points to an existing file or not, we get the Operation not supported error. That's better diagnostic, but not exactly what we expected :-( So, why is it not supported? Let's dig a bit more. acl_set_link_np implementation is found at Libc-498.1.5/posix1e/acl_file.c:175 and is:

  return(acl_set_file1(path, acl_type, acl, 0));

The last argument (follow) passed to acl_set_file1 is 0 and the first lines of acl_set_file1 implementation reads:

  if (follow == 0) {
    /* XXX this requires some thought - can links have ACLs? */
    errno = ENOTSUP;
    return(-1);
  }

We have the explanation of the Operation not supported error we got earlier. Note that the comment is not mine, it is actually in the libc source code!

Does it mean it is impossible to set an ACL on a symlink? Does it mean our only option is to file a bug asking some Apple engineer to think harder if links can have ACLs? Fortunately no. There is a third function in the acl_set(3) API: acl_set_fd, which acts on a file descriptor. Hopefully, getting the file descriptor of a symlink is as simple as open(path, O_SYMLINK).

That's it. With this patch, you'll be able to run ./chmod -h +a "everyone allow delete" myLink and have the ACL to be set on the symlink!

If you need to set ACLs on symlinks on a daily basis, I suggest you do not overwrite /bin/chmod but install the patched version of chmod in /usr/local/bin. Well, if you read that post till there, you probably know that already.

This bug has been reported to Apple and is known as radar #6264303 which is a duplicate of radar #5684438.

Using your own address book in the iPhone Simulator

2009-01-04T22:38:00.008+01:00

Jailbroken iPhone with openssh:

scp mobile@iPhone:~/Library/AddressBook/* ~/Library/Application\ Support/iPhone\ Simulator/User/Library/AddressBook

Non-jailbroken iPhone:

Say bye bye to John Appleseed & Co.

Kagi Registration Module (lack of) security

2008-10-15T21:06:00.005+02:00

I'm in the process of choosing an eCommerce partner for selling my future shareware. I have narrowed down to eSellerate and Kagi as they are widely adopted by Mac shareware developers. After reading their respecting obfuscated pricing policies, I decided to have a look at what they offer for integrating the purchasing process into the application.

Kagi offers the Kagi Registration Module (KRM) which is basically a library that provides an in-application one click purchase experience. Sounds pretty good. I start reading the KRM developer documentation and stumble on the Security section:

The ZonicKRM submits orders through an SSL connection for security, however pricing information is currently passed from the application to the ZonicKRM as an XML string.

If this data is not checksummed, or otherwise protected, a malicious user may be able to edit the XML string within an application's executable and submit an order with an invalid price.

In the long term, this attack will be denied by moving the responsibility for pricing information from the KRM library to the KRM server. When this process is complete, vendors will be able to override the pricing information in shipping copies of an application using their Kagi database entry.

WHAT THE FUCK ? The user is able to choose the price he wants to pay ? Can't be true, this part of the documentation must be outdated. Guess what... it's not, long term is long term!

Note that checksumming or protecting is pure bullshit as long as the price comes from the application and not Kagi's server.

I searched for the first shareware using KRM I found, opened it with an hex editor, did search and replace of the string 30.00 to 01.00 and I indeed successfully ordered the shareware for $1.

This is totally irresponsible from Kagi. I don't know how this registration scheme could have been designed this way in the first place. No sensible person can design an ordering system where the price is set by the client.

Please don't flame me, I'm a good guy. I contacted the $30 shareware author and offered to pay the remaining $29 I owe him. I should have searched a bit longer for a cheaper shareware. $1 + $29 is a bit expensive to demonstrate that KRM sucks ;-)

The Bottom Line
Don't use KRM as long as you can't set the price of your shareware on Kagi's server.

QuietXcode

2008-09-03T09:32:00.013+02:00

Have you ever noticed the Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x319a380, has non-zero refcount = 1 messages in the console ? Chris Espinosa replied about these warnings to Matt Neuburg:

The second one is an error deep in some system framework when running under Garbage Collection that we have not been able to track down yet. It simply means that somebody has neglected to do a final release on a memory block that nobody has kept a pointer to (making the final release technically impossible). The Garbage Collector knows the block is inaccessible and is freeing it, but is warning us that somebody forgot to formally release it before the pointer to it went out of scope. Bad form, but no actual harm.

I think it actually harms. These messages are filling the console so much it becomes unusable. I'm a big fan of GeekTool and I always have the tail of the console on the desktop. Now, it looks always the same and interesting messages from various applications are lost in the mass of free_garbage messages:

Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x319a380, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x31bf6e0, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x3263da0, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x3274eb0, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x319a380, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x31bf6e0, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x3263da0, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x3274eb0, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x201c8b0, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x3256110, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x201c8b0, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x3256110, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x2045540, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x208ca10, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x2045540, has non-zero refcount = 1
Xcode(19838,0xb0103000) malloc: free_garbage: garbage ptr = 0x208ca10, has non-zero refcount = 1

So I decided to tackle the problem and here is my Solution: QuietXcode 1.1.4 (5 KB). This is an Xcode plugin that patches the culpable call to malloc_printf("free_garbage: garbage ptr = %p, has non-zero refcount = %d", ...).

You can build the plugin either by typing xcodebuild in a terminal or by building it (⌘ + B) in Xcode. Building the plugin will also automatically install it into your ~/Library/Application Support/Developer/Shared/Xcode/Plug-ins folder.

Once it's installed, you have to relaunch Xcode. You should see the message <QuietXcode> loaded successfully in the console and no more free_garbage messages.

The plugin performs a safe patch, that is, if it does not find the expected call to malloc_printf and the expected Xcode version (greater than or equal to 3.1/1099), it logs a more or less comprehensive error to the console. Have fun browsing the source code, it demonstrates how to use the dyld and mach-o apis to locate non exported symbols and the mach api to dynamically patch code.

Note that the plugin is for i386 only, porting it to ppc and/or 64 bits is left as an exercise to the reader.

Exploring iPhone OS 2 files

2008-08-22T20:34:00.006+02:00

Update: This technique also works with iPhone OS 3.x. You will find the VFDecrypt keys on The iPhone Wiki Firmware page. Just select the appropriate iPhone model and Version/Build of your firmware.

It turns out to be pretty simple:

Download iPhone OS 2.0.2 (5C1)
curl -O http://appldnld.apple.com.edgesuite.net/content.info.apple.com/iPhone/061-5241.20080818.t5Fv3/iPhone1,2_2.0.2_5C1_Restore.ipsw

Unzip the ipsw which is actually a zip file
unzip iPhone1,2_2.0.2_5C1_Restore.ipsw

Download vfdecrypt
svn co http://iphone-elite.googlecode.com/svn/trunk iphone-elite

Compile vfdecrypt
make -C iphone-elite/vfdecrypt_win32

Decrypt the dmg (key from The iPhone Wiki)
./iphone-elite/vfdecrypt_win32/vfdecrypt -i 018-3978-1.dmg -k 31e3ff09ff046d5237187346ee893015354d2135e3f0f39480be63dd2a18444961c2da5d -o iPhoneOS-2.0.2.dmg

Mount iPhone OS dmg and start exploring
open iPhoneOS-2.0.2.dmg

Do not buy iQuarantine X

2008-08-22T20:05:00.009+02:00

From iQuarantine X website:

iQuarantine X is not a background script or a script that gets attached to files or folders.
iQuarantine X is the first application to make the LEOPARD FILE QUARANTINE ALERTS go away.
iQuarantine X is the easiest way to rid LEOPARD of all FILE QUARANTINE ALERTS.

So, if it's not a script, what is it (beside a scam) ?
It's a hack that binary patches a system framework (/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore) by short-circuiting the private function _FSAllocateQuarantineData.

So we have four good reasons not to buy it:

It has an unacceptable upgrade policy.
It binary patches a system framework.
Developer does not reply to e-mails.
You can disable the Leopard quarantine for free with an official technique.

The missing NSLocale documentation

2008-07-10T08:09:00.006+02:00

+ (NSArray *)preferredLanguages
Return Value
The user's language preference order as an array of NSString objects, each of which is a canonicalized IETF BCP 47 language identifier. This is defined by the user in System Preferences → International → Language.

For your information: this is stored in the gloal domain in the AppleLanguages key.

+ (id)currentLocale
Return Value
The logical locale for the current user. The locale is formed from the settings for the current user’s chosen system locale overlaid with any custom settings the user has specified in System Preferences → International → Formats.
This method may return a retained cached object.

+ (id)autoupdatingCurrentLocale
This one I have not understood how it is supposed to be used. If someone knows, please let us know in the comments.

Now, if what you want is the current language, you should not use either of these methods. Instead you should use something like NSLocalizedString(@"ISOLanguageCode", @"iso language code"). Then you have to define "ISOLanguageCode" = "en"; etc. in all your Localizable.strings files.

Mac OS X bug on non english systems

2008-06-10T21:13:00.003+02:00

Mac OS X 10.5 (Japanese): Disk Utility "internal error" alert with 7-pass erase or 35-pass erase

Symptoms
In the Japanese language version of Mac OS X 10.5, when performing a Secure Erase (7-pass or 35-pass erase) in Disk Utility, this alert may appear: "Disk Utility internal error. Disk Utility has lost its connection with Disk Management Tool."

Resolution
Change the Mac OS X language version to English before performing the secure erase.

I thought this kind of problem was Mac OS 9/Classic history.

Upgrading a System Preference pane

2008-02-14T10:42:00.002+01:00

The System Preferences application provides a convenient way to install a preference pane. Double-clicking the preference pane will prompt the user if he wants to install it for the current user only or for all users of the computer. Then System Preferences will copy the preference pane to ~/Library/PreferencePanes or /Library/PreferencePanes according to what was chosen asking for administrator password if necessary. Finally the preference pane will be loaded and presented to the user.

Now, let's see what happens when a preference pane is upgraded. Again, System Preferences is smart: it is able to detect if an older version of the same preference pane is installed and proposes to replace it [1]. Everything seems alright, but it is actually not! Things are more complicated if the preference pane to upgrade has already been loaded. That is, if the user already clicked the preference pane.

Indeed, preference panes are just a special kind of bundle which is loaded into System Preferences with the -(BOOL)[NSBundle load] method (cf. -(BOOL)[NSPrefPaneBundle instantiatePrefPaneObject] method of the PreferencePanes framework). The problem is that on Tiger, a NSBundle can not be unloaded. So when upgrading an opened preference pane, the old code is not unloaded and as a consequence the new code is not loaded. This is because System Preferences calls the -(BOOL)[NSBundle load] method which returns YES, meaning that the bundle was successfully loaded or that the code has already been loaded. In the case of an already opened preference pane, that's how the result of the load method should have been interpreted. Unfortunately, it is interpreted as if the bundle was successfully loaded and System Preferences thinks it has loaded the new bundle, but it has not.

This is very problematic because at this point, the resources (nib files, pictures etc.) of the new bundle have already been copied. So we have the old code which is accessing the new resources. I let you imagine the numerous problems this situation can cause. At best, exceptions will raise and your preference pane will be half working. At worst, your preference pane will simply crash.

So, how do we fix this problem?

First, the preference pane must detect itself when it's upgrading over an older already loaded version as System Preferences does not detect it [2]. This must be done as early as possible, i.e. at the very beginning of the - (id)initWithBundle:(NSBundle *) bundle method. It is possible to detect this situation with the help of the version of your NSPreferencePane subclass. See my detection snippet to understand how detection works.
Once this is detected, we must properly reload the new preference pane. This must be achieved by quitting System Preferences and relaunching System Preferences. This is the not that elegant solution to unload the old preference pane. The elegant solution would be to unload the bundle. This is left as an exercise to the Apple engineers for a future version of System Preferences.

Relaunching System Preferences and selecting the preference pane is quite tricky. A second executable must be responsible for relaunching the System Preferences application. Also, it is nicer for the user if the preference pane he just upgraded is automatically selected. Automatic selection of the pref pane is achieved through Apple Script. Please refer to my reload snippet for implementation details. Note that once you have compiled the reload executable, you have to place it inside the resources directory of your preference pane. Do not place it inside the executable directory (Contents/MacOS) if you do not want to see the reload application popping up in the Dock.

With this reload code in place, if the user ever happens to upgrade a preference pane while the older one was loaded, he will experience a System Preferences flicker as it will quit and reopen right away. While this might be surprising to him, this is still better than a half working preference pane or a crash.

If anything is unclear, just say it so in the comments and I will try to elaborate. If everything is clear, just pick up my code snippets and implement them in your preference pane as soon as possible ;-)

1. System Preferences uses the CFBundleGetVersionNumber function to retrieve the version numbers of the new and old bundles as an UInt32 in order to compare them. The documentation says If the bundle’s version number is a number, it is interpreted as the unsigned long integer format defined by the vers resource on Mac OS 9. What every developer understands is that if your Info.plist CFBundleVersion key represents a number (e.g. "519"), the value returned by CFBundleGetVersionNumber will be 519. This is not what actually happens. If you want CFBundleGetVersionNumber to return 519, you have to add an undocumented key in your Info.plist file: CFBundleNumericVersion. Make sure you define it as <integer>519</integer> and not <string>519</string>.↩

2. Note that on Leopard, this situation is actually detected and a dialog is presented to the user telling he must quit System Preferences and then open it again. Unfortunately, no automatic action is taken to circumvent this annoying behavior. System Preferences could restart itself or unload the bundle (this is possible since Leopard) but as of Mac OS X 10.5.2, none of this action is performed.↩

QuickTime 7.4 and Perian subtitles fix

2008-01-25T16:40:00.001+01:00

With QuickTime 7.4, subtitles automatically added by Perian have stopped working. In order to get them back, download and install Front Row Trailers, go to the QuickTime Components tab, and install Perian 1.0.0.2. If the proposed version is below 1.0.0.2, hold the alt (option) key while clicking the Refresh button.

For thoses wondering, this is an unofficial build of Perian 1.0 onto which two patches have been applied. Note that the future Perian 1.1 release will also be able to read subtitles.

Enjoy, QuickTime 7.4 can read subtitles again, no need to downgrade to version 7.3.

UPDATE: Perian 1.1 is now released and has addressed the problem. Note that subtitles still do not work in Front Row on Leopard.

keywords: QuickTime 7.4 Perian subtitles srt

BetterAuthorizationSample

2007-11-29T07:28:00.000+01:00

Finally, Apple posted BetterAuthorizationSample, a sample project that demonstrates how to securely use Mac OS X authorization API.

Apple's older sample code (AuthSample and MoreAuthSample) used a setuid root privileged helper tool. BAS uses launchd because it's more secure. In the BAS design, an attacker can't directly control the environment which the helper tool inherits, and that prevents a variety of potential attacks.

This sample code supersedes the four years old Project Builder MoreIsBetter/MoreSecurity sample code that warned: No matter what you do, the current AuthorizationExecuteWithPrivileges model allows for security violations [3093666]. It comes as a Xcode project that compiles without tweaking and with three documentation files that look quite complete: Design and Implementation Rationale, Performing Privileged Operations With BetterAuthorizationSampleLib and Read Me About BetterAuthorizationSample.

Front Row for Tiger

2007-11-19T10:55:00.001+01:00

Leopard users have the Front Row application in their Applications folder. It may be useful if you want to automatically launch front Row when your computer starts up by adding a login item for example.

Now, Tiger users can also use this convenient Front Row application. Leopard users who have accidentally deleted their Front Row application can also use it.

Front Row 1.0 (29 Ko)

I have not tested it on unsupported Macs, i.e. those without an Apple Remote. If you have such a Mac, please report in the comments if it works or if it still requires Front Row Enabler.

This Front Row launcher has been written from scratch. Here is the source code:

int main(int argc, char *argv[])
{
BSRemoteUIToggle();
return 0;
}

Region X Universal Binary

2007-09-12T17:29:00.000+02:00

Thanks to ben11, a member of the rpc1 forums, new RPC-1 firmware updates are available for Matshita drives. This is great, but something was missing: an universal binary version of Region X. An intel only version is available, but it's english only and well, an universal binary version is just better. Unfortunately, xvi — the author of Region X — retired several years ago. Fortunately, he made Region X sources publicly available. So I recompiled it as an universal binary and I updated the version number to 1.1.3. Feedback is welcome.

Region X 1.1.3

Version history (version 1.0.0 to 1.1.2 are actually from xvi)

Version 1.1.3 (2007-09-12)

* Recompiled as universal binary

Version 1.1.2 (2005-01-12)

* Corrected a case where settings were not properly stored

Version 1.1.1 (2004-05-09)

* Added RPC-1 drive warning
* Region not set and 5 changes left logic tuned

Version 1.1.0 (2004-04-25)

* Japanese localization added, by Satoshi Ash
* Chinese localization added, by 季娇

Version 1.0.9 (2004-03-21)

* Changes to the settings read/write system
* New icon

Version 1.0.8 (2004-02-07)

* Spanish localization added, by 宗次郎

Version 1.0.7 (2004-01-25)

* Greek localization added, by Alexandros Tr
* Drag and drop installation

Version 1.0.6 (2003-12-29)

* Enhanced current settings reading, now compatible with OS X on UFS partition
* Window position is now remembered across launches

Version 1.0.5 (2002-10-16)

* Added Region not set case handling

Version 1.0.4 (2002-06-25)

* For Mac OS X 10.1.5

Version 1.0.3 (2002-02-27)

* Added German localization (translation by Ralph and David)
* Added safety check for privileged attribute

Version 1.0.2 (2001-11-26)

* Changed handling of five changes left logic to be more user friendly
* Added Dutch localization (translation by iRob)
* Added Italian localization (translation by Michele)
* For DVD Player 3.0.1

Version 1.0.1 (2001-11-11)

* Improved region settings validity check
* Enhanced documentation now in Help menu
* Added my photo (that incredible feature was requested by my wife)
* Multilingual version, english and french

Version 1.0.0 (2001-10-18)

* First release for OS X, english only
* Full native Cocoa application

Looking for a german translator for Bandes-annonces Front Row

2007-05-23T18:11:00.000+02:00

The upcoming version of Bandes-annonces Front Row will be international. For those who don't know, Bandes-annonces Front Row enables you to change the trailers you watch inside Front Row. In the previous version, trailers came from AlloCiné, a french cinema site. In the upcoming version, the user will have several choices. I'm looking for a german translator as one of the source provides german trailers.

So if you are interested in watching german trailers inside Front Row and if you would like to spend a few minutes to translate Bandes-annonces Front Row, please post a comment.

Here are some screenshots so that you have an idea of what it looks like.

L'effet MacBidouille

2007-05-19T12:36:00.000+02:00

Le 7 mai, MacBidouille a parlé de Bandes-annonces Front Row dans ses news. Résultat: une augmentation de la fréquentation aussi spectaculaire que soudaine.
Mon hébergeur n'a d'aillers pas tenu le coup et certains ont eu des soucis pour télécharger Bandes-annonces Front Row. Je trouverai mieux pour la prochaine version, même si la fréquentation ne sera certainement pas aussi grande.

Front Row Trailers

2007-02-19T14:05:00.004+01:00

English version below

Front Row Trailers est le nouveau nom de Bandes-annonces Front Row depuis la version 2.1.

Front Row Trailers n'est plus disponible. Veuillez vous référer aux instructions pour restaurer les bandes-annonces originale d'Apple.

Foire Aux Questions

Q: Comment faire pour désinstaller Front Row Trailers ?
R: Il n'y a pas besoin de désinstaller Front Row Trailers, il suffit de sélectionner la source Apple (US) et les bandes-annonces d'origine seront de retour.

Q: Est-ce que Front Row Trailers est compatible avec Leopard (Mac OS X 10.5) ?
R: Oui

Q: Sur Leopard, je dois entrer mon mot de passe à chaque fois que je change de source, que puis-je faire pour éviter cela ?
R: Il suffit de taper la commande suivante dans le Terminal (une fois la commande entrée, il faut taper son mon de passe):

sudo chmod o+w /System/Library/PrivateFrameworks/BackRow.framework/Versions/A/Resources/Trailers.plist

Q: Est-il possible de désactiver les bandes-annonces ?
R: Depuis la version 2.1.1, Front Row Trailers le permet en choisissant la source spéciale Deny.
Sur Leopard, il est aussi possible de désactiver les menus iTunes Top Movies, iTunes Top Songs et iTunes Top Music Videos en entrant la commande suivante dans le Terminal:

defaults write com.apple.frontrow EnableITMS -bool NO

Attention: cette commande doit être entrée avant de choisir la source Deny dans Front Row Trailers.

Q: Sur Leopard, certaines bandes-annonces ne se lisent pas aussi bien que sur Tiger ou ne fonctionnent même pas du tout. Prévoyez-vous de distribuer une mise à jour ?
R: Front Row pour Leopard utilise une architecture très différente de celle de Front Row pour Tiger. Tandis que Front Row pour Tiger utilise QuickTime pour lire les bandes-annonces, Front Row pour Leopard semble utiliser son propre méchanisme passant outre QuickTime. Alors que les bandes-annonces se lisent bien dans QuickTime player, celles-ci peuvent ne pas fonctionner dans Front Row. C'est notamment le cas avec les bandes-annonces allemandes utilisant le codec Sorenson 3. Malheureusement, il n'y a rien que je puisse faire. Néanmoins, une future mise à jour de Front Row ou de QuickTime pourrait résoudre ces problèmes.

Historique des versions

Version 2.1.2 (2008-01-24)

* Ajouté Ciné.ch (source suisse romande)
* Détection correcte de la version de QuickTime

Version 2.1.1 (2007-12-18)

* Ajouté Lycos (source espagnole)
* Enlevé Cinefacts (l'accès à Front Row Trailers a été bloqué)
* Possibilité d'interdire les bandes-annonces

Version 2.1 (2007-10-15)

* Changement de nom
* Bandes-annonces haute définition
* 20 sources
* Traduction italienne
* Traduction danoise
* Options de tri
* Nouveau système de mise à jour

Version 2.0.2 (2007-08-20)

* Corrige un bogue dans la détection de Perian

Version 2.0.1 (2007-06-22)

* Corrige un bogue dans la détection des composants QuickTime

Version 2.0 (2007-06-21)

* Nouvelle interface
* 9 nouvelles sources de bandes-annonces à choix

Version 1.1 (2007-05-03)

* Suppresion des saccades

Version 1.0 (2007-02-19)

* Version initiale

Bandes-annonces Front Row is know as Front Row Trailers since version 2.1.

Front Row Trailers isn't available anymore. Please refer to instructions to restore factory Apple trailers.

Frequently Asked Questions

Q: How do I uninstall Front Row Trailers ?
A: There is no need to uninstall Front Row Trailers, just select the Apple (US) source and you will get the original trailers from Apple.

Q: Is Front Row Trailers compatible with Leopard (Mac OS X 10.5) ?
A: Yes

Q: In Leopard, I am prompted for my password every time I change the source, is there anything I can do about that ?
A: Just type the following command in the Terminal (you will have to type your password):

sudo chmod o+w /System/Library/PrivateFrameworks/BackRow.framework/Versions/A/Resources/Trailers.plist

Q: Is it possible to disable the theatrical trailers ?
A: Since version 2.1.1, Front Row Trailers is able to deny trailers access by choosing the special Deny source.
On Leopard, it is also possible to disable the iTunes Top Movies, iTunes Top Songs and iTunes Top Music Videos menus by typing the following command in the Terminal:

defaults write com.apple.frontrow EnableITMS -bool NO

Warning: this command must be typed before choosing the Deny source.

Q: In Leopard, some trailers won't play as smoothly as in Tiger or won't even play at all. Are you planing to release an update ?
A: Front Row for Leopard uses a very different architecture than Front Row for Tiger. Whereas Front Row for Tiger uses QuickTime for playing the trailers, Front Row for Leopard seems to uses its own mechanism ignoring QuickTime. While the trailers play fine in QuickTime Player, they may not play in Front Row. This is notably the case with german trailers using the Sorenson Video 3 codec. Unfortunately, I can not do anything about that. Nevertheless, a future update of Front Row or QuickTime may fix these issues.

Version history

Version 2.1.2 (2008-01-24)

* Added Ciné.ch (swiss french source)
* Correctly detects QuickTime version

Version 2.1.1 (2007-12-18)

* Added Lycos (spanish source)
* Removed Cinefacts (Front Row Trailers access has been blocked)
* Possibility to deny trailers access

Version 2.1 (2007-10-15)

* Name change
* High-definition trailers
* 20 sources
* Italian localization
* Danish localization
* Sorting options
* New update system

Version 2.0.2 (2007-08-20)

* Fixes a bug in Perian detection

Version 2.0.1 (2007-06-22)

* Fixes a bug in QuickTime components detection

Version 2.0 (2007-06-21)

* New interface
* 9 new trailers sources

Version 1.1 (2007-05-03)

* Trailers play more smoothly

Version 1.0 (2007-02-19)

* First version

Network Diagnostics cannot find server

2006-12-04T11:42:00.000+01:00

I doubt I typed the address incorrectly. :-)

zip vs dmg

2006-11-06T13:02:00.000+01:00

Most Cocoa developers use disk images (aka dmg) for distributing their softwares over the Internet. This is not really surprising as this is Apple's recommended practice for software distribution.

My gripe against this practice is simple: it's very slow. I did an experiment that I think is rather representative. I bundled a 1.9 MB application (Transmission) into both a zip file and a dmg file. I'm talking here about internet-enabled disk images, i.e. those which copy their content, unmount and go to trash automatically.

Here are the results of my experiment.

	Size	Time
zip	0.7 MB	0.16 sec
dmg	1.3 MB	9.02 sec

Impressing, isn't it ? The size is almost twice bigger for the dmg although I used maximum compression (zlib level 9). That's bad (not all Mac users have a broadband connection) but what is worse is the time to prepare the disk image, verify the disk image, mount the disk image, clean up, check the download files, prepare the disk image, mount the disk image, copy the disk image, unmount the disk image and clean up. Yes, these are the ten operations required for an internet-enabled disk image to achieve the decompression! Zip decompression requires only two phases: decompressing the zip file and checking the downloaded files, thus it is 56 times faster.
Results may vary depending on application size and may be slightly different for a ten MB application but I can't see how a disk image could be either smaller or faster to decompress than a zip archive. If you know such an exemple, please post a comment about it.

Since Mac OS X 10.3, zip file compression and decompression is natively supported. Prior to Mac OS X 10.3, StuffIt Expander was bundled with Mac OS X. A convenient Create archive of "..." stands in the File menu of the Finder. It's simple and efficient, so why not using it ?

Some may argue that disk images are nice for drag & dropping the software into the Applications folder. While this is true, this is also very slow. When using a non internet-enabled disk image, users have to copy the application into the Applications folder which takes much more time than moving it. Moreover, they have to go to the desktop in order to unmount the disk image.

You have understood by now, I hate disk images and I hope more and more developers will use zip files in the future to distribute their softwares in order to save their users' precious time. ;-)

Finally, I suggest you have a look at these movies (no faking) showing how fast and how long it takes to decompress respectively a zip file and a dmg file.

Jasscore

2006-10-21T19:08:00.000+02:00

Marquez les points au jass sur votre natel

Vous êtes accros aux cartes et à votre natel ? Alors je suis sûr que vous adopterez Jasscore. Avec ce midlet, vous pourrez tenir les scores d'une partie de jass (chibre, mise, etc.) encore plus facilement qu'avec une ardoise.

Je vous laisse juger par ces quelques captures d'écran.

Aucune documentation n'a été écrite car Jasscore devrait être assez intuitif. Si toutefois vous avez des questions, n'hésitez pas à laisser un commentaire ou bien à m'envoyer un message.

Téléchargement:
Jasscore 1.0 (6 Ko)

Installation:
Référez-vous à la documentation de votre natel. Si celui-ci supporte le bluetooth, il vous suffit d'envoyer le fichier Jasscore.jar et il devrait s'installer automatiquement.

Replacement icon for Mail.app

2006-10-04T18:20:00.000+02:00

I personally dislike the default Mail.app icon. Instead I chose to use the yellow mailbox from cocoricones. It looks really nice and is not blue as almost all other Apple icons!
You can also download it in .icns format ready to replace Mail.app icon.

keywords: Mail.app, icon, yellow, mailbox

This is too simplistic or systematic

2006-10-03T10:15:00.000+02:00

Indeed: way too simplistic! I should construct my password myself rather than relying on the Password Assistant :-)

Xcode and subversion 1.4 fix

2006-09-24T18:36:00.000+02:00

I was unsatisfied to have to revert back to subversion 1.3.2 because Xcode (v2.4) does not yet support the new format of subversion 1.4 .svn/entries file (see my previous blog entry: Xcode and subversion 1.4 incompatibility).

So I wrote a SIMBL plugin that adresses this problem.

Download and install SIMBL (Smart InputManager Bundle Loader) if not already installed

Download Xcode+svn-1.4 and decompress it

Move Xcode+svn-1.4.bundle into ~/Library/Application Support/SIMBL/Plugins

Relaunch Xcode, it is now compatible with svn 1.4 :-)

Update:

keywords: Xcode, SCM, subversion, svn, 1.4

Xcode and subversion 1.4 incompatibility

2006-09-21T14:11:00.000+02:00

Xcode will unfortunately not work with the latest version of subversion, i.e. version 1.4. The reason behind this dysfunctionment is the new format of the .svn/entries files (see subversion 1.4 release notes). The new format is no more friendly xml. Xcode thus does not find the url=... node and fails with this rather sparse warning: NSScanner: nil string argument.

The solution to this problem is to revert to subversion 1.3.2 until Apple fixes the subversion plugin for Xcode, maybe in the next version.

keywords: Xcode, crash, subversion, svn, 1.4

Dealing with outdated open source libs in Mac OS X

2006-07-09T14:09:00.000+02:00

Mac OS X system frameworks heavily rely on open source libraries. For example, the NSXML classes of the Foundation framework are wrappers around libxml2. The problem is that libxml2 bundled into Mac OS X (10.4.7 as of writing) is version 2.6.16, dating back from november 2004! Current version is 2.6.26 and obviously has fixed a lot of bugs since version 2.6.16.

A specific bug I discovered was rather annoying: NSXMLDocument's validateAndReturnError: method would validate an invalid document. You guessed it, an up-to-date version of libxml2 doesn't suffer from this bug. So the solution to the problem would be to compile the latest version of libxml2 yourself and use this one for your application instead of the system version. This sounds easy but is in fact far from being trivial.

Compiling an universal binary version of libxml2 is easy, this is achieved with the following commands:
$ env CFLAGS="-arch i386 -arch ppc" LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk" ./configure --disable-dependency-tracking --enable-static=no --without-python
$ make

Now, libxml2.2.6.26.dylib is almost ready to use inside the .libs directory. I said almost because its install_name is /usr/local/lib/libxml2.2.dylib. Unless you plan to make an installer for your application, you should change it so that it is relative to your application. For example, if your application bundle looks like this:
Contents Info.plist MacOS MyGreatApp PkgInfo Resources ... lib mygreatlib.dylib libxml2.2.6.26.dylib
copy the built library (so that you still have the original dylib in case of problem) and change its install_name with the following commands:
$ cp .libs/libxml2.2.6.26.dylib .
$ install_name_tool -id @executable_path/../lib/libxml2.2.6.26.dylib libxml2.2.6.26.dylib

Now, your application must link against your version of libxml2. To do so, add libxml2.2.6.26.dylib into your Xcode project and check that it has been added to the Link Binary With Libraries phase of your current target.

The latest step is to make sure your libxml2.2.6.26.dylib is going to be used instead of /usr/lib/libxml2.2.dylib at runtime. The problem is that /usr/lib/libxml2.2.dylib uses two-level namespace, meaning that the Foundation framework will always use this one instead of yours. The solution is to force flat namespace by setting the DYLD_FORCE_FLAT_NAMESPACE environment variable. This is achieved by adding the following key in your Info.plist file:
<key>LSEnvironment</key> <dict> <key>DYLD_FORCE_FLAT_NAMESPACE</key> <string>YES</string> </dict>

Your application now uses the latest bug-free version of the lib :-)

This example used libxml2 but obviously apply to any other open source library.

mach_inject, procmod group and security

2006-06-24T09:33:00.000+02:00

mach_inject is a very clever piece of hack that allows an application to inject and execute code in another running process. It was initially written for PowerPC Macs only. Recently, Bertrand Guihéneuf ported mach_inject for Intel Macs.
The big difference between the two version lies in the privilege level they require. The PowerPC version works with standard user privilege whereas the intel version requires more privileges to work.

mach_inject is used for example by virtual desktops applications like Desktop Manager and VirtueDesktops. They legitimately requires the ability to inject code in the Dock as it is the only process allowed to manipulate all the windows. But running code under the identity of another process is a high security risk. That's why Apple introduced a new security feature in Mac OS X 10.4.4 (for Intel Macs only) that prevents mach_inject to work. Technically, any process not belonging to the procmod group or not running as root will fail to call task_for_pid which is a necessary step in the process of code injection.

There are several solution to this problem which are not all equivalent from a security point of view.
The first solutions that surfaced were proposed by Jason Thames on osx86project forum.

His first proposal is to add yourself to the procmod group.
His second proposal is to change the security policy of the task_for_pid call.

Unfortunately, both solutions are bad solutions, the former at a single user level, the latter at the computer level.
Doing so would now allow any application to inject code into another process meaning that you would have annihilated the protection introduced by Apple. :-(

The good solution is to set the permission on a per application basis rather than on a per user/computer basis. Unix permission mechanism is perfectly suited to perform this task. You can do it manually with a terminal, Niko explains the procedure on his blog. This works very well but is a bit tedious for users reluctant to use a terminal.

The best solution is that developers who legitimately require mach_inject functionality make use of the Security/Authorization API for asking users their administrator password in order to be able to change their application's executable group to procmod and set it's set-group-ID-on-execution bit. VirtueDesktops is the first to my knowledge to do so. You can see the source on VirtueDesktops trac to understand how this can be performed.

I strongly encourage developers to use the self-authorizing mechanism mentioned above as this will be beneficial for users both in a security and an ergonomic point of view.

keywords: mach_inject, procmod, task_for_pid, security, intel

Attention: nouvelle campagne de phising contre PostFinance

2006-06-19T21:54:00.000+02:00

On ne le répétera jamais assez, votre banque ne vous enverra jamais d'e-mail vous demandant de vous authentifier dans le jour même sous peine d'avoir votre compte fermé!

Voici l'e-mail que je reçu aujourd'hui comme beaucoup d'autres:

Lorsque l'on passe le curseur sur l'URL, on constate vite la supercherie: l'URL n'est pas du tout la même que celle annoncée dans le corps de l'e-mail. Une petite vérification avec un whois nous confirme que ce n'est effectivement pas le site web de PostFinance.

La nouvelle sur PostFinance

mots clés: phishing, PostFinance

Using GNU lightning on an Intel Mac

2006-06-18T15:30:00.000+02:00

GNU lightning is a library that generates assembly language code at run-time. This is an useful tool for writing a Just-In-Time compiler.

While your jit compiled code will work on most systems, you will probably experience crash under Mac OS X with an EXC_BAD_INSTRUCTION exception on a movdqa %xmm0,32(%esp) instruction. The reason if this crash may seem obscure but is in fact simple: on Mac OS X, the stack must be 16-byte aligned at the point of function calls. This is documented in the Mac OS X ABI Function Call Guide.

So, how to fix this problem ? Align the stack manually by jit compiling special instructions before every function call depending on the number of parameters pushed ? This is quite tedious. A better solution is to use gcc's -mstackrealign switch.

Here is the documentation of this option:

-mstackrealign
Realign the stack at entry. On the Intel x86, the -mstackrealign option will generate an alternate prologue/epilogue that realigns
the runtime stack. This supports mixing legacy codes that keep a 4-byte aligned stack with modern codes that keep a 16-byte stack for SSE compatibility. The alternate prologue and epilogue are slower and bigger than the regular ones, and they require one dedicated register for the entire function. This also lowers the number of registers available if used in conjunction with the "regparm" attribute. Nested functions encountered while -mstackrealign is on will generate warnings, and they will not realign the stack when called.

Enjoy, your program is not crashing anymore. :-)

keywords: GNU lightning, Intel Mac, crash, EXC_BAD_INSTRUCTION, movdqa xmm0

Relaunch your Cocoa application by itself

2006-06-17T18:54:00.003+02:00

Here is a code snippet of a relaunch helper tool with instructions to use it.

keywords: self, restart, relaunch, cocoa, os x