SHRDLU

Music reverse engineered: Ommadawn live in Montreux

Fri, 29 Sep 2017 18:52:03 -0000

Here's the transcript of an excerpt of Mike Oldfield's Ommadawn (live in Montreux). It's the electric guitar part starting at around 1:07:45 right after the fluty fantasia...

Enjoy! \m/

Ommadawn_Montreux.txt

Music reverse engineered: Incantations (excerpt)

Sun, 24 Apr 2016 15:52:03 -0000

Here's the transcription of a small piece from Mike Oldfield's Incantations 1 & 2 - from the Exposed album (13:12min - 14:17min). Actually it's the beginning of Part 2 played on an electric guitar.

Incantations.txt

Music reverse engineered: Shabda & Aurora

Wed, 25 Dec 2013 13:20:12 -0000

I have ignored Music of the Spheres for a long time. After a discussion with my friend a few weeks ago I decided to give it another try. Conclusion: I'm still not sure how to compare it to classics like Hergest Ridge, Ommadawn, etc. but it certainly doesn't deserve to be ignored. And Shabda is a masterpiece.
Here's transcriptions for Shabda and Aurora. I hope you enjoy playing!
Suggestions and corrections are highly appreciated.

Merry Christmas!

Using Bonjour for iPhone/desktop application sync

Mon, 14 Jul 2008 13:58:08 -0000

Many Cocoa developers might want to port their application(s) to the iPhone. I'm one of these developers and the first problem I ran into was how to sync my desktop application's data with it's iPhone pendant. Some applications like OmniFocus use MobileMe or any WebDav server for synchronisation. Unfortunatly this is not an option for me because I don't want my users to have a MobileMe account or a Server just to sync with my app.

My solution uses Bonjour to synchronize my app's data to the iPhone via the network. You can download this demo project which contains a proof of concept version of my solution. The demo project consists of two XCode Projects. One desktop app and it's iPhone pendant.

The idea is pretty simple: The desktop application needs to share it's data with the iPhone app via the network. Therefore the iPhone app creates a sync service and publishes it using the Bonjour technology. This way, the desktop application "sees" all iPhones (which are running the sync service) in the local network and offers the user a list from which he can choose the iPhone to sync with.
The application's data is then transfered onto the iPhone where it is saved as a file. The iPhone app can now work with this data.

As I'm short of time at the moment I could only implement this basic solution yet but I'm sure I will extend it as soon as I'll find the time.
In a real world scenario the synchronization process might be a bit more complex. In most cases you may want to import your iPone app's data into your desktop app and vice versa. For this I'd suggest to put the whole sync logic into your desktop app and perform something like this:

Fetch the data from the iPhone
Check it against your desktop app's data
Resolve conflicts if they exist
Import the data into your desktop app
Put the whole data back to the iPhone

Most Important: Security
Whenever you deal with network services you have to keep security in mind. When you start a network service on your iPhone it might be a potential security risk, since it opens a "door" to your applications data and everyone in the local network may be able to download this data.

So you may want to create some kind of pairing or authentication protocol as well as encryption for your sync service. This means that when the app syncs for the very first time the user must enter some "secret" which identifies the the iPhone whic the user wants to sync with. Of course this mechanism becomes useless when you use an unencrypted protocol so you should think about encryption too.
Besides, you shoud ensure that the sync service is only stated when it is really needed. E.g. stop the service when the user swithes to some view other than the sync view, etc.

Conclusion
Since the iPhone supports Bonjour, it could be used to sync data with any desktop application.
A full featured example project resides on your HD in /Developer/Examples/Foundation/PictureSharing and /Developer/Examples/Foundation/PictureSharingBrowser. This is where I took some code from :).

Since I've never held a real iPhone in my hands I only tried the example Project with the simulator. It would be nice to see if it works on real hardware. So, if you have tried it, please drop me a line.

Ojective-C dot notation

Sun, 13 Jul 2008 10:53:03 -0000

This blog post by Marcus Zarra made me happy. Now I know that I'm not the only person who dislikes the dot notation which has been introduced in Objective-C 2.0.
The "Properties" feature is great, since it takes a lot of work writing accessor methods away from the developer. But accessing your object members sing the dot syntax makes your code ugly and cofusing.

Ok, what shall I say? Marcus' post says it all ...

simpleTAN translated into english

Sat, 12 Jul 2008 14:43:35 -0000

Did I mention that s~~impleTAN~~ is available in english? At the moment we are working on translating the website but it seems to take us longer than we thought. But if you want, you can give the app a try. A short description is available via this recent Blog Post. Enjoy using it :).

Edit: simpleTAN isn't available anymore. The project has been closed. If you are interested in it give me a shout and I'll send you a copy. But I'm pretty sure it won't run on OS X >= 10.5.7

Relaunch an application

Wed, 02 Jul 2008 00:23:00 -0000

Some tasks, e.g. restoring an application's data files from a backup should be performed while the application is not running to make sure there won't be any concurrent access to the files. A desirable behaviour would be: Quit the application, perform the work and finally relaunch the application - just as Sparkle does when installing an update.

I've created a simple but well-working solution for that problem. My solution is using a small helper application which performes the work which has to be done while the main application is not running and relaunches it afterwards. You can download the sample project to try it out by yourself.

The RelaunchHelper is just an ordinary binary which has to be launched by your application just before it terminates itself. Of course, you can pass arguments to the RelaunchHelper. In the example project the path to the main application's bundle is the sole argument. After invoking the helper, your application should terminate itself and let te helper take over.
I let the helper app sleep for a few seconds befor it relaunches the application to ensure, all files opened by the main application (in this example this is not an issue) are properly closed.

These are the steps you have to follow to create a project:

Create a target for the helper
Add all needed source files to that target
Make that target a direct dependency of your main app's target to make sure the helper is also build when you build your main app
Create a Copy Files build phase for your main app's target and add the helper to it. This is necessary to make the helper binary appear in your app's bundle
Build and go :)

So, that's my solution to the relaunch issue. Maye it's not the most elegant way to do this. If you have a better solution, let me know. I really appreciate any comment.

Update:
A much better way to implement a relaunch helper has been provided by Cédric Luthi in his Blog post.
Please check it out.

Synchronizing the content of multiple NSArrayControllers

Mon, 30 Jun 2008 13:17:01 -0000

As an application grows and it's UI becomes more complex, you definetly want to split the UI into multiple views and hold each of it in a seperate Nib File. This makes your project a lot more cleaner and helps you to keep overview.

If you're using Core Data and you want to access your entities from all of your views you need to put an Array Controller in each of your Nib. But now you're running into the problem of synchronizing the contents of your Array Controllers since you have to provide the complete application data to all the views in which you need it. Fortunatly Cocoa Bindings help you to solve this issue quite elegantly.

Download this sample project which is an excerpt of a project I'm currently working on.

Now, let me explain what this project does in general: Basically you need some

"Master Array Controller" which is bound to your applications ManagedObjectContext and actually holds your application' data. Then you need to bind the arrangedObjects key of the Array Controller(s) which you want to synchronize with the Master Controller to the Master Controllers contentArray. Then, you need to bind the managedObjectContext of your Slave Controller(s) to the app delegate's managedObjectContext. That's it! Here's some code which illustrates this process:

    [[(MainWindowController*)[self windowController] arrayControllerMaster] bind:@"contentArray" toObject:slaveArrayController withKeyPath:@"arrangedObjects" options:nil];
    [slaveArrayController bind:@"managedObjectContext" toObject:[NSApp delegate] withKeyPath:@"managedObjectContext" options:nil];

`
This example assumes, that the Master Controller is accessible in some way. In my example, I put it in the MainWindowController class and created a read-only accessor method. Take a look at the sample project to see what I mean.

Conclusion:
As you can see, Cocoa Bindings enable you to synchronize the ArrayController of your application in a very easy manner. This helps you to keep your Nib Files and controller classes clean and well arranged.

simpleTAN Beta Announcement

Mon, 09 Jun 2008 12:00:20 -0000

The work on simpleTAN is coming to a close. Today I can proudly announce that the simpleTAN Beta is available for ~~download~~. simpleTAN is a TAN management application for MAC OS X focusing on security and usability.
You can comfortably enter your TANs and carry them with you securcely encrypted using the AES256 standard. When you need a TAN to perform a transfer just enter your passphrase and the TAN will be available instantly. You can also store the ammount and the reason for payment of every transfer. It's easy, give it a try ...

Edit: simpleTAN isn't available anymore. The project has been closed. If you are interested in it give me a shout and I'll send you a copy. But I'm pretty sure it won't run on OS X >= 10.5.7

Debugging BAD_ACCESS with NSZombieEnabled

Fri, 04 Apr 2008 09:02:52 -0000

Everyone who had to debug a segmentation fault within an application, knows, how tricky it can be to detect such a bug. The reason for that is, that in most cases the crash doesn't occur in the line of code where the actual bug is. Instead your application crashes somewhere else, usually in some piece of code which doesn't have anything to do with the code that contains the bug.

Fortunately, Cocoa offers a cool feature which greatly enhances your capabilities to debug such situations. It is an environment variable which is called NSZombieEnabled. When set to YES,this variable causes Cocoa actually not to release an object after it has received a release message. Instead Cocoa just "remembers" that the object has received the release message
and on any subsequent messege sent to this object, a log message
is pribted to the console and SIGTRAP is thrown. The debugger immediately interrupts your application when you try to access an invalid object. A backtrace shows you the exact line of code which caused the BAD_ACCES.

To enable NSZombieEnabled simple open the Info panel of your application executable within XCode and set it to YES.

Now write some lines of code to see how it works:

NSDate *date = [NSDate date];
NSLog(@"Date: %@", date); /* good access */
[date release];
NSLog(@"Date: %@", date); /* bad access, causes a crash */

Now, if you run this code inside the debugger, your application will stop when the bad access occurs and with a backtrace you can easily find the line of code which caused it.

Cool, isn't it?
Remember to turn of NSZombieEnabled after you have finished the debugging.

Introducing simpleTAN

Tue, 01 Apr 2008 23:10:44 -0000

SimpleTAN, the application I am working on at Bidli Software is a
TAN management tool for Mac OS X. If you're doing online banking
with PIN/TAN and use tools like GPG or aespipe to securely take
your TAN's with you on your laptop or simply store them on your
mac to have them right at hand when you need them, then you'll
love simpleTAN. It lets you easily enter your TAN numbers and you
can retrieve them just by entering your password. After you have
used the TAN, you can mark it as used (and optionally store the
amount and purpose of your transaction with it). So you can easily
track which TAN you have used when and for what transaction. Of
course, all your TAN's are stored encrypted (using aes256, which is
also used by Apple's FileVault) in the database. SimpleTAN focuses
on both, security and ease of use. It will be shipped soon. Stay tuned
to find out more ...

Core Data Encryption

Sat, 29 Mar 2008 23:08:30 -0000

I recently wondered how to encrypt the attributes of a Core Data
application. The encryption should be transparent to the application,
which means the entity objects should do all of the encryption/
decryption work and the rest of the application doesn't even know
that there is something happening. This way, you can continue using
bindings with Interface Builder and all the other convenient stuff
which Core Data offers without worrying about your encryption/
decryption.

You can download the Demo Project (created with Xcode 3.1 beta).
Note: The Demo Project includes the SSCrypto Framework. Please
respect it's copyright.

But how do you actually encrypt stuff using Cocoa? Obviously Cocoa
doesn't offer any suitable objects - but Mac OS X does. Mac OS X
ships with OpenSSL, a powerful and robust tool which offers many
important cryptographic functions. OpenSSL is also a full-featured
library (libcrypto). This library is exactly what we need to perform
encryption within a Core Data application. If you take a closer look
at the OpenSSL library functions, you may find them a bit difficult
to use (especially if you have only a basic knowledge of all the
cryptographic stuff), but furtunatly there is SSCrypto - an easy-to-use
Cocoa Framework wich wraps around OpenSSL and does all the
tricky stuff for us.

This sounds pretty good, does it? So let's see, how to put all this
together in a Core Data application.

Core Data doesn't support encryption as well. If you're coding for
Leopard only, maybe you can use an Atomic Store to encrypt/decrypt
your whole Persistent Store (I haven't tried this yet, since my apps
have to be Tiger compatible).

Instead we will use Transient Attributes to transparently encrypt the attributes of our entities.
Each of the attributes we want to encrypt must be transient and
must have a corresponding "Data Attribute" of type "Binary Data"
which is persistent and actually holds the encrypted data. In XCode
your model could look like this:

Now we need to create a NSManagedObject subclass which represents
the entity. If you create this class with the XCode wizard, don't let it
create Objective-C 2.0 Properties since we need to add custom
accessor methods. The class interface looks as follows:

@interface Item :  NSManagedObject  
{
}

- (NSString *)itemName;
- (void)setItemName:(NSString *)value;

- (NSData *)creationDateData;
- (void)setCreationDateData:(NSData *)value;

- (NSData *)itemNameData;
- (void)setItemNameData:(NSData *)value;

- (NSNumber *)itemId;
- (void)setItemId:(NSNumber *)value;

- (NSData *)itemIdData;
- (void)setItemIdData:(NSData *)value;

- (NSDate *)creationDate;
- (void)setCreationDate:(NSDate *)value;

@end

We don't have to touch the accessors for the "Data Attributs" but the
accessors for the transient attributes need to be customized in order
to perform encryption/decryption.
Let's take a look at -(NSString *)itemName which performs
decryption of the attribute "itemName":

- (NSString *)itemName 
{
    NSString * tmpValue;

    [self willAccessValueForKey:@"itemName"];
    tmpValue = [self primitiveValueForKey:@"itemName"];
    [self didAccessValueForKey:@"itemName"];

    if(!tmpValue || [tmpValue isEqualToString:@""]) {
        NSData *encryptedData = [self valueForKey:@"itemNameData"];

        /* if there are any encrypted data, decrypt it */
        if(encryptedData) {
            /* init SSCrypto with the stored key from the PasswordController */
            SSCrypto *crypto = [[SSCrypto alloc] initWithSymmetricKey:[[PasswordController sharedInstance] keyData]];
            [crypto setCipherText:[NSKeyedUnarchiver unarchiveObjectWithData:encryptedData]];

            NSData *decryptedData = [crypto decrypt:@"aes256"];

            /* some debugging output. maybe useful. you can wrap them with #ifdef/#endif directives to enable them only in debug configuration */
            NSLog(@"Using symmetric key: %@",       [[crypto symmetricKey] hexval]);
            NSLog(@"Archived itemName: %@",         [encryptedData hexval]);
            NSLog(@"Encrypted itemName: %@",        [[crypto cipherTextAsData] hexval]);
            NSLog(@"Decrypted itemName: %@",        [crypto clearTextAsString]);

            tmpValue = [[NSString alloc] initWithData:decryptedData encoding:NSUTF8StringEncoding];
            [self setPrimitiveValue:tmpValue forKey:@"itemName"];

            [crypto release];
        }

        else {
            /* insert the defalt value here */
            tmpValue = @"Default Value";
            [self setItemName:tmpValue];
        }
    }

    return tmpValue;
}

Basically, this method loads the encrypted data (if it exists) and
decrypts it. The decrypted data is stored in the primitive value so
it doesn't need to be decrypted each time it is accessed - only when
it is read for the first time. If there is no encrypted data (a new
entity is inserted), then the default value is used.

The set accessor for the itemName attribute works in a
similar way. It performs the following steps:

If the new value equals the old one, return. This avoids any
unnecessary encryption which dramatically reduces cpu load, since
Core Data acesses the attributes quite heavily
Store the new value in the primitive value
Encrypt the new value and store it in the "Data Attribute"

Here's the code:

- (void)setItemName:(NSString *)value 
{
    NSString * tmpValue;

    [self willAccessValueForKey:@"itemName"];
    tmpValue = [self primitiveValueForKey:@"itemName"];
    [self didAccessValueForKey:@"itemName"];

    /* if the new value is equal to the old value, return. this improves the performance a lot, since core data
     accesses the attributes quite heavily and encrypting them would stress the cpu when it's not really necessary*/
    if([tmpValue isEqualToString:value])
    return;

    [self willChangeValueForKey:@"itemName"];
    [self setPrimitiveValue:value forKey:@"itemName"];
    [self didChangeValueForKey:@"itemName"];

    SSCrypto *crypto = [[SSCrypto alloc] initWithSymmetricKey:[[PasswordController sharedInstance] keyData]];
    [crypto setClearTextWithData:[value dataUsingEncoding:NSUTF8StringEncoding]];
    NSData *encryptedData = [crypto encrypt:@"aes256"];

    NSLog(@"Encrypting itemName: %@",               value);
    NSLog(@"Encrypting itemName: %@ with key: %@",  value, [[crypto symmetricKey] hexval]);
    NSLog(@"Encrypted itemName: %@",                [encryptedData hexval]);
    NSLog(@"Archived itemName: %@",                 [[NSKeyedArchiver archivedDataWithRootObject:encryptedData] hexval]);

    /* archiving the encrypted value ensures, that it can be saven as plain-text xml */
    [self setPrimitiveValue:[NSKeyedArchiver archivedDataWithRootObject:encryptedData] forKey:@"itemNameData"];

    [crypto release];       
}

In prinziple, this is how the encryption works. But what key is
used to encrypt the data and where does it come from? In our
example the key is entered by the user. I have created a class
called PasswordController which stores the key data.
This class is designed to be a singleton because only one instance
of it is needed within the whole application.

When the application is launched, I use the
-applicationDidFinishLaunching method to request the
key from the user and store the data in the PasswordController.
When you take a look at the console, while you launch the app,
you will notice, that there is happening a lot of stuff before
the user has entered the key. This is because Core Data accesses
the attributes right after the Nib-Files have been loaded. But the
-applicationDidFinishLaunching method is called after that.
I haven't found any issues with this yet. If you find any problems,
please let me know.

Another aspect I'd like to mention is, that the demo application
cannot determine if the user has entered the wrong key. In that
case, the decryption simply does not work and any newly created
items are encrypted with the other key, which produces a
currupted Persistent Store (it's not really "damaged", but unusable.
Try it, you'll see what I mean).

This issue coud be addressed by including a digest (sha1, or
something) of the key in the Persistent Store and compare it each
time the user has entered the key. The Metadata Dictionary of the
persistent Store would be a good place to put it in. This is not yet
included in the demo application since I didn't find the time yet.
Maybe I will do it in some future version. Sorry for that!