This is the second part of the guide to smartcard-based authentication on Mac OS X. In this part of the guide, I’m going to assume that following Part 1, you have installed OpenSC, initialised your smartcard, and loaded or generated some certificates and private keys onto it. Now I’m going to show you how to use the card for actual authentication.
Interested in using a smartcard for secure two-factor authentication on OS X? What about E-mail signing and encryption, SSH key authentication, and more? All of these applications are possible, using the built-in smartcard support in OS X and open source software. What follows is the first part of a guide to using smartcards on OS X, using software from the OpenSC Project.
A little while ago I had a problem. My phone is a Sony Ericsson K800i, with 64MB of internal storage and a slot for Memory Stick expansion storage. I was using it as an MP3 player, and so had an 8GB memory stick in there to store MP3s.
When I connected it to my Mac in USB drive mode to transfer files, it appeared in the Finder as two storage devices, one for the internal storage and one for the memory stick. When I’d finished transferring files I would click Eject on the memory stick’s device to safely remove it. Then I’d do the same on the internal storage’s device, but this would eventually fail and report an I/O error. The phone’s screen would show that the USB connection had ended, but one of the devices would still show in the Finder. If I then unplugged the USB cable the Finder would tell me that data might have been lost since I didn’t eject the storage device properly.
I eventually found a workaround – go into the Disk Utility app, and Unmount (not Eject) one device, then Eject the other. The order didn’t seem to matter, as the Eject would cause both devices to disappear. However this required me to launch Disk Utility to do the unmounting every time I had to unplug the phone from the Mac.
I started to get fed up of the extra time and clicking involved, so I decided to write a single-function Service to do the unmounting. Check it out here.
Student Tech Meetup talk
On Wednesday, I gave a talk at the Student Techmeetup here in Edinburgh on DS homebrew development. As promised, I’ve uploaded the slides from that talk as a PDF here, with links to a few tutorials and resources included in them, along with some notes.
emitSMS plugin update
The emitSMS plugin has been updated with a small new feature – it will now strip out dashes and spaces from your phone numbers in Address Book before sending them to the phone, as most phones don’t seem to accept numbers in this format. Grab the new version here.
emitSMS plugin bug fix
Here’s a new version of the Address Book plugin for SMS sending, with a small bug fix intended to stop it hanging after sending an SMS. If you’ve seen this problem with earlier versions, please let me know if this version has fixed it or not 
emitSMS Address Book Plugin updated
In the distant past, the Address Book app in Mac OS X Tiger could send mobile SMS messages directly from within the app, if you paired your mobile phone with your Mac via Bluetooth. Along came Leopard, and the feature mysteriously vanished without trace or explanation, and hasn’t reappeared since. Missing the feature, I found a roundabout replacement in the emitSMS dashboard widget. It offers SMS sending via Bluetooth and can also search the Address Book for phone numbers. Having seen that the source code for emitSMS was released, I adapted the backend into a plugin for Address Book.app to provide the missing former functionality. read more…
Deflektor remake for Nintendo DS
Here is a project I’ve been working on for a few weeks to learn more about DS homebrew coding. It’s a remake of Deflektor, an old puzzle game that I played on the Amiga. I’ve tried to keep the retro feel of the original while updating it to use the touchscreen interface.
The aim is to rotate the mirrors (
) to reflect the laser beam from the source (
) to blow up all the triggers (
) and then enter the target (
). Rotate the mirrors by tapping on them and then dragging to align the mirror at a particular angle. You start with an amount of energy which is constantly declining (the green bar). Directing the beam into a spike (
) or reflecting the beam back to the source will cause it to overload (represented by the red bar). If the source is overloaded too much or if you run out of energy, you lose a life. There are also rotating blocks which only allow the beam to pass at a certain angle (
), teleports (
) which work in pairs, and blocks which randomize the beam direction (
). In addition, in some levels there are gremlins which roam about the board and mess with your stuff. You can get rid of them by tapping on them repeatedly.
There are a few things I’d like to add to the game, like highscore saving and a level editor, which might appear if I have time to work on it. For now it comes with all the levels from the original game. You can download it here. Any comments, bug reports, etc are welcome!
I’ve built a Mac (Intel) binary of DesMuME, from the latest SVN code, with a patch to enable masscat’s GDB stub. With it you can load a homebrew rom, connect to DesMuME with the copy of GDB that’s provided with devkitARM, and start debugging your homebrew code while it’s running in the emulator. For more details check out this post on the official forums.
The binary can be found here, and the modified parts of the source code can be downloaded here. Please let me know if you find any bugs related to using the GDB stub – I’ve tested it a bit and most features seem to work, but this is the first time I’ve worked on the DesMuME code and I may have overlooked something. I take no responsibility for bugs in the unmodified Mac version of DesMuME though 
How to use it:
Currently the only method of specifying the debugger ports to use is on the command line. So, open up Terminal.app and run DesMuME from there, like so:
orange:~ sigmaris$ /path/to/DeSmuME.app/Contents/MacOS/DeSmuME -arm9gdb 20000
Note the single dash before the argument. This will start the ARM9 stub listening on port 20000. You can also use -arm7gdb <port> to start the ARM7 stub. You can omit either of the arm9gdb or arm7gdb arguments and it won’t start the respective GDB stubs at all. If startup was successful you should see log messages like this on the console:
2009-04-05 22:32:41.896 DeSmuME[29404:10b] Using ARM9 GDB port 20000
Then go to the DesMuME window, set up a FAT image if necessary, and load your homebrew ROM. You’ll notice it doesn’t start immediately but just shows a white screen. It is waiting for GDB to connect, so go ahead and start it up (I assume you have devkitPRO installed in /usr/local)
orange:~ sigmaris$ /usr/local/devkitPRO/devkitARM/bin/arm-eabi-gdb homebrew.elf
You should point gdb to the compiled ELF file of the homebrew ROM that you loaded earlier. You should see the (gdb) prompt, now tell GDB to connect to the DesMuME stub:
(gdb) target remote :20000 Remote debugging using :20000 0x02000000 in _start () (gdb)
If you see the above output, you’re ready to start debugging. For example, set a breakpoint on a function that you use in your homebrew program, and then enter ‘cont’ to tell DesMuME to continue running the program. You should see your program run up to the breakpoint and then stop, and GDB will print a message saying it encountered the breakpoint. You can now examine the state of local variables, print a backtrace, or step line-by-line through your code.
Hopefully this will be useful for some homebrew DS developers on the Mac. Unfortunately, even with the GDB stub in place, DesMuME doesn’t catch many of the errors that would trip you up on a real DS like writes to invalid memory and other similar errors. But being able to jump in anywhere and examine the running state of your code is a step forward from just using tons of iprintf() calls