Does this site look plain?

This site uses advanced css techniques

The Windows-based Eudora email client from Qualcomm uses a EUDORA.INI file that contains all the parameters required to connect to the mail servers, and this often includes the user passwords in obscured form. This program and associated module (both written in perl) are used to read the .INI file and un-obscure that password. We also describe the obscuring algorithm so that others don't need to reinvent the same wheel we did.

Quick Links

EUDORA.INI File Format

This WIN.INI-style file is typically located in the Eudora directory, and this is usually C:\Program Files\Qualcomm\Eudora. But the official location of all the Eudora components is found in the system registry under: 

HKEY_CURRENT_USER\
        Software\
        Qualcomm\
        Eudora\
        CommandLine\
        current

This value contains three tokens separated by spaces, which are

This registry value doesn't seem to permit filenames with spaces, even if quoted. This seems lame to us.

Once the file has been located, eudinfo reads from that file and picks apart the information it finds. Most of the parameters in the EUDORA.INI file are unintersting to a security tester (such as colors and window locations), but several are quite interesting. Of particular note is SavePasswordText, which contains the obscured password. But the password is not useful without knowing the name of the POP server and login name: these are located also.

Eudora supports the notion of "Personas", which allows the user to manage more than one email account. Each persona can have a separate email address and associated mail servers, and each is stored in the INI file in a separate section. The "default" settings are found in the [SETTINGS] section, and each persona is found in a [Persona-personality name]. When we parse the file, we decode and report each one separately.

Password Obscuring Algorithm

User passwords are obscured by Eudora with a simple algorithm that operates three characters at a time, turning each input triple into four output bytes using a limited alphabet. Every obscured password is a multiple of four bytes.

Three cleartext eight-bit bytes at a time are converted into four six-bit tokens, and each of the resulting six-bit tokens is converted to an ASCII byte using a 64-bit restricted alphabet: 

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

Each six-byte token indexes into this string to yield a printable character, and this is added to the password string. But if the six-bit token contains no bits from a user password character, a "=" character is used for padding. Recalling that we process three cleartext password bytes at at time into a buffer, the tail end of a password might be AB (in binary, 01000001 01000010).

The resulting 24-bit buffer has only 16 bits of "actual" user password data, with the final 8 bits being zero filled. The entire 24-bit buffer is used for generating the output tokens, and we see that output token #3 only contains a few bits of the user password, and #4 contains none. This means that output byte #4 is = for padding.

Eudora obscuring bit buffer

Un-obscuring a password works in reverse. Encoded bytes are taken four at a time and convered from printable base-64 alphabet characters to the internal six-bit token and put into a 24-bit buffer (if any obscured password byte is NOT in the alphabet, it's an invalid encoding). Obscured bytes of "=" at the end are ignored and NOT considered in the count of bits found in the buffer. Once the buffer is full, output bytes are generated eight bits at a time, but only when that eight-bit byte actually contains a bit that came from the encoded input.

Command Line Usage

eudinfo mainly reads EUDORA.INI files specified on the command line, and it outputs the interesting parameters (including the decoded password). Many more items are available in the file than are shown, but most are not intersting for us. This can be extended by inspecting the code.

We also support the --encode and --decode parameters that allow for manual encoding and decoding of Eudora passwords. They do no file I/O and have nothing to do with the .INI file. 

$ eudinfo eudora.ini
--> {default}
  Password     = he11o43
  MailType     = IMAP
  RealName     = Stephen J. Friedl
  POPServer    = lnx.unixwiz.net
  LoginName    = steve
  SMTPServer   = lnx
  ReturnAddr   = steve@unixwiz.net
  POPAccount   = steve@lnx.unixwiz.net

$ eudinfo --encode=hello
Encoding {hello} --> aGVsbG8=

$ eudinfo --decode=aGVsbG8=
Decoding {aGVsbG8=} --> hello

$ eudinfo --decode=aGVsbG8
Decoding {aGVsbG8} --> (invalid password)

The last example shows eudinfo correctly reporting an invalid encoding: it's not an even multiple of four characters (there are other reasons for failure, but we don't enumerate them).

This program is a single, standalone perl file that doesn't require any special setup (v1.0 did require stuff like this) because we have concatenated the eudpass.pm perl module to the end of the main program. But it's easy to split out the perl module for use in your own code - it's obvious from looking at the source.

Under WinNT/Win2000, we use the excellent ActiveState perl (www.activestate.com), and by putting the eudinfo.p in your normal search path (say, C:\BIN), it can be run just like a native NT command. But, a limitation of NT is such that it can't read from the standard input. So we had to disable the stdin mode for this reason. Bummer.

Download

The eudinfo software is written in perl and comes in two parts, but for easy distribution on the web we've combined them as mentioned above. It's built from eudinfo (the main driver) and eudpass.pm (the actual password decoder), and they can easily be separated should you care to use the modules separately.

Bugs & TODO List

Fun Stuff

This was recently posted on BugTraq (The FOCUS-MS list) regarding Eudora:

Also, if you have access to someone's eudora.ini file (locally or remotely) and want to have fun with them, you can add the following lines: 
[Debug]
LogLevel=127
When they start Eudora, all email transactions in and out will be verbosely logged to a eudora.log file (no notice anywhere that it is happening) in their email folder. This way you can get their username, password, email data, etc in one simple file. Even if they use SMTPS and POP3S, the resultant cleartext data (even uname and password) is still written to the file. Fun stuff.

Revision History