This site uses advanced css techniques
The Symantec pcAnywhere software keeps its per-host and per-caller information in small data files, and we've found out how to decode them. This includes:
We've not surprisingly been unable to find any documentation on the format of these files, so we have decoded them ourselves.
Quick Links
The .CHF file appears to always be 3,308 bytes long, and it's in a binary format with fields in fixed locations. They are located in the directory referenced by the registry key (pcainfo does not consult the registry):
HKEY_CURRENT_USER\ Software\ Symantec\ pcANYWHERE\ CurrentVersion\ Winaw32\ FileXferPrefs\ CurrentDirectory
The actual layout of the file is best determined by looking at the code, and we only discovered the location of the various fields by a lot of trial and error (we are quite sure we have not fully decoded the file). We have also decoded more fields than we display here: the goal of this program is to perform network surveillance during a penetration test, not to learn every aspect of the file: most of minor details can be discovered by simply loading the file into a local copy of pcAnywhere.
Field Name | Description |
---|---|
FilePassword |
Each .CHF file can be protected with a local password that prevents a workstation user from using this file in various ways. The file can be protected against executing, reading, or modifying. We don't decode exactly which attributes are being protected: we simply show the password if found. This has nothing to do with any auto-login password that might be found in the file. |
ConxType | This is the connection, which is usually "TCP/IP", but can also represent a modem or serial connnection. |
Hostname IPAddr |
These two fields seem to be incestuously related, ane we've not fully figure out just which ones are used when. So we show them both. |
Logname Password |
If auto-login has been enabled in this .CHF file, these fields show the login name and password to use. Note that disabling the auto-login simply puts a NUL byte at the start of these fields, so it's possible that remnants of a previous auto-login information can be found here. We represent NUL bytes with {NUL}. Note that the Logname field might contain an NT domain name followedby a \ if this has been specified. |
Area Code Phone Number Location |
For modem connections, the area code and/or phone number fields contain the remote number to dial. and the "Location" field is presumably used for making area-code selections. The GUI allows us to specify a phone number in several ways, and we've not really spent any time decoding it in any detail. |
Encrypt |
This defines the encryption algorithm to be used for this transaction:
|
Deny Lower Encr | If this is 1, lower levels of encryption than requested are simply not allowed. |
Private Key Cont CertCommonName |
The "Private Key Container" and "Certificate Common Name" fields are used for Public Key encryption. We don't know how they work. |
SaveSessionFile | This shows the pathname of a "session file" that pcAnywhere can save for later playback. |
Autorun File | pcAnywhere provides for a "Run upon connection" features, and this can either be an auto-transfer to send or receive a file, or to run an actual script. This field contians the value in the field, though we are quite sure we've not figured out even most of this. |
The .CIF file appears to always be 1,792 bytes long, and it's got exactly the same odd XOR decoding algorithm as in the .CHF format and found in the same directory. This was very convenient.
The file format is much simpler than the previous one:
Field Name | Description |
---|---|
Display Name | This is the name that is displayed in pcAnywhere to describe this caller. It's often the same as the filename. |
File Password | This password unlocks the .CIF file at the application level, and has nothing to do with the password that the user must present upon login. We don't show any of the detailed access-control flags (execute only, read only, etc.) |
Caller Name | This is the "login name" required to be entered by the user, along with the password in the next field. |
Caller Password | This password must be presented along with the Caller Name above. |
Note that the .CIF files are found only for "pcAnywhere" users: it's also possible to use the NT domain authentication to permit remote access, and we don't think these .CIF files are used for it at all.
The pcainfo program requires one or more .CHF or .CIF files to process, and they can either be named on the command line individually or processed by scanning a directory. There is no saved state, and each is picked apart independently.
Each file in turn is read, XOR decoded, and the fields picked apart. Only the non-blank fields are displayed,
C> pcainfo remotesite.CHF Processing remotesite.CHF ConxType = TCP/IP Hostname = server.remotesite.com Logname = {NUL}ill Gates Password = {NUL}erysecret Encrypt = 255 Location = United States of America (1)
Not all .CHF files include the login name & password - this requires that the user enter them for auto-login purposes - but even knowing the remote hostnames & IP addresses is often useful. In this case, we see that the used to be an auto-logon, and though the first bytes are missing, it's not that hard to fill in the blanks.
The supported command line paramters are:
The --dir= parameter also works for remote directories:
C> pcainfo --dir="\\machine\c$\Program Files\Symantec\pcAnywhere"
Note that under Windows, file globbing (*.chf) doesn't seem to work right, though we suspect we're just doing something wrong. Under WinNT/Win2000, we use the excellent ActiveState perl (www.activestate.com), and by putting the pcainfo.p in your normal search path (say, C:\BIN), it can be run just like a native NT command.
The pcainfo 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 pcainfo (the main driver) and pcadecode.pm (the actual decoder), and they can easily be separated should you care to use the modules separately.
• pcainfo.p - Perl program
There seems to be some confusion over the "Hostname" and "IP Address" fields - we haven't figured out just exactly why it sometimes uses one of the fields and sometimes it uses the other one. We also find that sometimes the field contains garbage.
We're pretty sure we are not handling the "gateway" mode because we don't really know how it works.