PAD

Choice of environments

Since the Pilot is a relatively new platform, the major obstacle to be overcome with this project has been finding a development environment to work in. The only offical such environment is the CodeWarrior platform for Macintosh, which is infeasible for me as I have neither a Macintosh nor the $300 with which to purchase the CodeWarrior package. the CodeWarrior for Pilot for Windows is currently in beta testing and not yet available as I'd hoped. Working in a non-USR-sanctioned development environment has had two large drawbacks: 1) There is not yet any interface to the built-in TCP/IP stack, wiping out the possibility of doing direct network communications between the desktop and the Pilot, as I'd originally planned, and 2) Most of the third-party development environments are extremely poorly documented, if at all, and sample code is scarce and hard to come by. This problem was minimized by using a commerical third-party language instead of a freeware package.

Environments that exist:

1. asdk: ASDK is the Alternate Software Development Kit for Pilot. ASDK includes PILA, the pilot assembler, which translates 68000 assembly into .prc files for the Pilot. I discarded this environment fairly quickly, as it's been a very long time since I've done any assembly, and never on the Macintosh. This was just too daunting to even consider on any kind of a schedule.
2. gcc for win32 for pilot: This looked the most promising, as C is one of my languages of choice, the Macintosh development environment uses C, and much of the source code available on the web is written in C. However, the only distribution I could track down (after many broken links) seemed to be missing a few key files and would not compile a running application.
3. JUMP: This was my second choice. JUMP is a backend translator that takes Java code (sprinkled with PalmOS API calls) as input and generates 68000 assembly that can be fed into PILA. I have done Java programming in the past, so this seemed like a good choice. Unfortunately, after a week or two and some unrelated sample programs, I realized that Java has no unsigned numeric variables, and thus no way to do bit operations. At this point, the clock was starting to tick, and I had no intention of trying to piece together Java classes to treat signed variables as unsigned. I moved on.
4. CASL: I had originally not considerd CASL (Compact Application Solutions Language) as a good candidate for doing real development on the Pilot, as it's a scripting language and is fairly limited in it's numeric function. However, failing with all of the other environments, I sent some mail to the author of CASL, who informed me of the binary array variable in CASL. I would have to write some functions to treat groups of 8-bit fields as 32-bit words, but that didn't seem so difficult. And indeed, it only took a few days to get those functions completely finished and tested. The current version of PAD, described in the next section, is implemented as a CASL script. This is good because it works. This is bad because it works slowly. The lack of speed is partially because the Pilot has a relatively basic processor (compared to any modern desktop), but also because of the inherent overhead in any scripting language. I hope to one day translate it to C, but as this project is as much about proof of concept as it is about workable final product, CASL will have to do for now.

   Other tools

   • CoPilot: Written by Greg Hewgill, the author of JUMP, CoPilot is an invaluable programming tool. Using the ROM extracted directly from the Pilot, CoPilot provides seamless Pilot emulation on the desktop, yet can be loaded with applications without being assigned a serial port for hotsync. Running on the PC, it can also execute much faster than the Pilot itself (There's a selector called Frames per Second, which I think affects speed, but whatever I have it set at runs roughly twice as fast at the Pilot), and there's no risk of losing precious data on the real Pilot during testing.

   Current Status

   The Pilot Authentication Device consists of two programs - a desktop version (server) and a Pilot version (client). The protocol is as follows:
   1. The server generates a random challenge + datestamp, appends the private key of the user, and hashes the concatenation with SHA. Challenge + Datestamp, 448 bits + Key, 64 bits = 512 bits = 1 SHA message block.
   2. The challenge + datestamp is sent to the Pilot as the authentication challenge.
   3. The Pilot appends the private key (supplied by the user and NOT stored) to the challenge, and hashes the concatenation using SHA.
   4. The Pilot sends the hased response back.
   5. The server checks the response against its own response and grants or denies access.
   The SHA processing portion is completed. A hash of a random value gives the same result as the hash generated by the server, so I know it's working. This took longer than I expected, both because I ended up having to write 32-bit rotate and add operations for dealing with arrays of 8-bit cells and because there turned out to be a bug in the not operator in the implementation of CASL. This bug took a few days to track down and isolate, but was eventually bypassed by substituting "255 - X" for "not X". After this workaround was implemented, the Pilot version began spitting out the right hash (defined as being identical to the server output). The basic algorithm was nearly trivial to code in C under unix.
   Screen capture of the unix server output and the Pilot program output (running on CoPilot) with random hardcoded non-zero input:

   

   The framework for user input is in place, but has not yet been spliced into the rest of the program. Unfortunately, as alluded to earlier, the preferred method of TCP/IP communication has been replaced with manual i/o. The manual input is tedious and slow, but there is really no alternative at this time. The calculation of the hash is slow, but hopefully the speed could be increased by recoding in C. The 80 iterations of SHA take collectively a good five minutes, which is certainly too slow for regular use. The speed of the desktop program is negligable. The only portion of the desktop program that is finished is the actual hash computation, as I wanted to get the Pilot version working before filling out the UI. The next step is to have the server generate its random challenge and output the random challenge + timestamp. Then, I will code the appending of the private key to the challenge and the verification of the answer.