I realize this is an unusual request. What I need to do is programmatically
retrieve the current encrypted PalmOS system password. So far I have
determined it is stored in the Unsaved Preferences database and is 32 bytes
long. What I'm trying to use is:
// get size of preference record first
result = PrefGetAppPreferences('psys',wID,NULL,&wSize,false);
where wID is the preference number and wSize is defined as a Word at the
start of my function and initialized to 0. The last parameter being false
should indicate to retrieve from Unsaved Preferences. The problem is
determining what wID should be to retrieve the password record as there are
several prefs owned by 'psys' in the file. Maybe I'm overlooking something,
but I'm thinking I just need the right ID. I tried looping through the first
dozen or so but didn't come across a 32-byte record... so I could be way off
in this approach.
It's a long story as to why I need to do this, but it is for an enterprise
solution wherein we have flashed a number of PalmOS devices with a custom
ROM image for our customer. The image contains a special boot-up program,
and on a specific lot of units, the start-up code got corrupted before
flashing and just happens to clobber the system password record thereby
setting the password to a garbage value (this prevents the user from
synching to their desktop). We've since corrected the ROM image for
subsequent units, but that leaves a number of affected units out in the
field currently in use, and it is not practical to recall them for a
re-flash. My approach is to add a "patch" to our enterprise app that will
load and examine the system password to see if it looks like the clobbered
one. If so, it will call PwdRemove() to clear it out. This then has no
effect on real use of the password feature, which is a priority for our
customer.
Another way of detecting the clobbered password is figuring out if the
encryption scheme is a simple XOR or the like. Then I could manually decrypt
the "garbage" password value and use that in a call to PwdVerify. That would
probably work prior to OS 3.5, which is the case here (v3.2). I doubt the
encryption is that weak, but I don't really know what is used by the OS. I
could also write a program to crank away at PwdVerify on a bad unit until it
discovers the garbage password by brute force, but I would think that would
take a ridiculously long time.
Thanks in advance...
--
Geoff Shepherd
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
