Recommendations

Solutions for this class of problem have been historically difficult [7,25]. Rollback, in particular, makes the tracking of potentially legitimate patching problematic. For example, take a natural scenario as shown in Figure 7.

Figure 7: Functions {1,2,3} with corresponding Addresses {A,B,C}

Assuming that the structure in the trap dispatch table for Function 1 is modified to point to a new Address, D (Figure 8), it would be up to the program that introduced the modification to keep track of the original value.

Figure 8: Function 1 patched to point to Address D. Address D hands off to the original location, Address A, upon completion.

If yet another patching program is introduced, it would note the native location of Function 1 as Address D. In this case, the second program has no way of knowing that it did not store the original address of Function 1. Upon the first program returning Function 1 to Address A, the second program can still rollback, pushing the return location back to that of Address D.

Potential exists for periodic checks against vendor-published hash tables to avoid the rollback scenario. It is envisioned that vendors would publish and cryptographically sign a list of the entry points to the various functions. Checks could be made on the portable devices themselves. The Palm OS could also create a list of entry points of newly installed applications and, upon execution, check the stored values against the live values noting discrepancies. A message box or other user alert would be shown should the necessity arise. A cryptographic coprocessor, such as [8,26], could assist in the secure storage of these entry points.