Building Keyring.jib

You will need to convert java source files into a .jib file suitable for the firmware revision of your ring. If you have the iB-IDE, fantastic - use that. If you don't go and get it. If it doesn't run, welcome the to the club. Although this has become a much more exclusive club now that the iB-IDE runs under linux. It also requires a 1.2 jdk. Get one from blackdown if you run linux, or straight from sun for solaris.

I have found that guavac is quite adequate for compiling the class files manually, but that kaffe refuses to run the BuildJiBlet application from jibkit092. Note that you need to compile the class files against an iButton.jar file that is specific to your firmware revision. You also need to use a firmware-specific jibdb file to convert the class files into a downloadable .jib format. Once again, this is all nice and easy with iB-IDE, and somewhat strenuous otherwise, as the only other way to get the requisite files is by politely asking jibsupport@dalsemi.com.

The actual conversion to a .jib file is done by the BuildJiBlet application, which you can find inside jibkit092. I've found that kaffe is not up to the task of running it. At least, not on Linux/Alpha.

Now, having said all that. Here is a .jib file built for my revision of the java iButton, which is: Java Powered iButton - Firmware Version 1.11.0006

How do you find out the revision of your iButton? I'm glad you asked. Not. You ask it nicely with the appropriate APDU. The appropriate APDU has a class byte of 0xd0, an instruction byte of 0x95, and parameter bytes of 0x1 and 0x0, like so:

%eris[25]~> jibapdu 0xd0 0x95 1 0                                                                                                                       18:39
resp len 32 sw 9000
0x31 0x4a 0x61 0x76 0x61 0x20 0x50 0x6f 0x77 0x65 0x72 0x65 0x64 0x20 0x69 0x42
0x75 0x74 0x74 0x6f 0x6e 0x20 0x2d 0x20 0x46 0x69 0x72 0x6d 0x77 0x61 0x72 0x65
0x20 0x56 0x65 0x72 0x73 0x69 0x6f 0x6e 0x20 0x31 0x2e 0x31 0x31 0x2e 0x30 0x30
0x30 0x36
%eris[25]~>                                                                                                                                             18:39

Useful, isn't it? As you might be able to detect from the output, jibapdu doesn't know about strings. But, luckily enough, we can use perl to convert it in just half a dozen tedious steps. Seriously, the hex bytes output that you see consist simply of a length byte (0x31) followed by the ASCII bytes of the version string. To cut a long story short, this is how I convert it. Note firstly the sed expression to insert commas between them (thus turning the output into a valid perl argument list), and secondly skipping the length byte when cut and pasting.

%eris[26]~> jibapdu 0xd0 0x95 1 0 | sed -e 's/ \|$/, /g'                                                                                                18:42
resp, len, 32, sw, 9000, 
0x31, 0x4a, 0x61, 0x76, 0x61, 0x20, 0x50, 0x6f, 0x77, 0x65, 0x72, 0x65, 0x64, 0x20, 0x69, 0x42, 
0x75, 0x74, 0x74, 0x6f, 0x6e, 0x20, 0x2d, 0x20, 0x46, 0x69, 0x72, 0x6d, 0x77, 0x61, 0x72, 0x65, 
0x20, 0x56, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x20, 0x31, 0x2e, 0x31, 0x31, 0x2e, 0x30, 0x30, 
0x30, 0x36, 
%eris[26]~> perl -e 'print pack("C*", 0x4a, 0x61, 0x76, 0x61, 0x20, 0x50, 0x6f, 0x77, 0x65, 0x72, 0x65, 0x64, 0x20, 0x69, 0x42,                         18:42
quote> 0x75, 0x74, 0x74, 0x6f, 0x6e, 0x20, 0x2d, 0x20, 0x46, 0x69, 0x72, 0x6d, 0x77, 0x61, 0x72, 0x65, 
quote> 0x20, 0x56, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x20, 0x31, 0x2e, 0x31, 0x31, 0x2e, 0x30, 0x30, 
quote> 0x30, 0x36) . "\n"'
Java Powered iButton - Firmware Version 1.11.0006
%eris[27]~>                                                                                                                                             18:43

Don't look at me like that. I told you this would hurt.

Now, having built your applet, you need to download it onto your Java iButton. For this, you can use the loadapplet application from libow. loadapplet requires three arguments, being a pin, an AID, and the .jib file. The AID that keymgr tries to talk to is 1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:10. Catchy, huh? You may ask, why? And the answer is that it's an easy string to detect in a hexcode dump. But I digress.

The pin is supplied in the same format - colon separated hex bytes. The default pin on the Java iButton is blank, and can be specified on the command line as ''. So, here's an example using a null pin, the wrong AID and the wrong .jib file.

%eris[119]~/.j> loadapplet '' 2:3:4:5:6 HelloWorld.jib                    18:25
***Sending 114 bytes, 0 done, 255 to go
resp len 0 sw 6301
***Sending 114 bytes, 114 done, 141 to go
resp len 0 sw 6301
***Sending 27 bytes, 228 done, 27 to go
resp len 0 sw 6a81
Unknown status: 6a81zsh: exit 65    loadapplet '' 2:3:4:5:6 HelloWorld.jib
%eris[120]~/.j>                                                           18:25