CRC on Unix vs Win32

[Frank Sconzo]

Hi,

I'm writing a perl module that sends rich-text messages to Microsoft
Outlook recipients from Unix. This involves generating CRCs of the
plaintext and rtf versions of the mail message.

Unfortunately, when I use perl modules to generate the CRC, the values
do not match those that the Outlook Client is expecting.

For example, I used the crc32 function from Digest::CRC to determine
the CRC of the string ABCD. I also sent a message from an Outlook
client containing only ABCD as the body text.

Digest::CRC::crc32 gives me the following for the CRC of ABCD:
db 17 20 a5

But the Outlook attachment contains a CRC of ABCD as:
b9 ff 53 fa

Anyone know why these wouldn't match?
If not, anyone know a way to reverse engineer the CRC Algorithm
Outlook uses based on an examination of computed CRCs from different
message texts? I can
run different texts through Outlook, snoop the attachments, and
extract the CRCs to get sample data.

I've checked the Microsoft documentation to see what they say about
the CRC, but it doesn't say anything about the algorithm or polynomial
value used to compute the CRC. It only mentions the following for the
field where it expects the CRC to be defined:

The PR_RTF_SYNC_BODY_CRC property contains the cyclical redundancy
check (CRC) computed for the message text. The RTFSync function
computes the CRC using only the characters that it considers to be
significant to the message. For example, some white space and other
ignorable characters are omitted from the CRC:
http://msdn.microsoft.com/library/en-us/mapi/html/_mapi1book_pr_rtf_sync_body_crc.asp

Thanks for insight anyone can provide!

Regards,
Frank

 

[Joe Smith]

I'm writing a perl module that sends rich-text messages to Microsoft
Outlook recipients from Unix. This involves generating CRCs of the
plaintext and rtf versions of the mail message.

Unfortunately, when I use perl modules to generate the CRC, the values
do not match those that the Outlook Client is expecting.

Richtext and plain text are non-binary files.
Non-binary files on Windows use "\015\012" at the end of each line
Non-binary files on Unix use "\012" at the end of each line.
When data is transfered in ASCII mode (as opposed to BINARY) mode,
the CRC will change. You need to convert one or both to canonical
form before performing a CRC check.
-Joe

 

[Geoff]

The RTFSync function
computes the CRC using only the characters that it considers to be
significant to the message. For example, some white space and other
ignorable characters are omitted from the CRC:

You appear to have the answer right there. Assuming Outlook is using
this function to do the CRC. Naturally they are not using all the
characters in the message for computation of the CRC as any _normal_
CRC would. Another undocumented proprietary implementation.

Perhaps you can guess the chars they are ignoring by eliminating
spaces, linefeeds and cr's from the chars you use in your CRC
computation. What other chars they may consider "not significant" is
anybody's guess.

 

[Frank Sconzo]

Joe,

Thanks for responding; you make a good point. Unfortunately, the
newline/carriage return issue is not the cause of the problem. The
sample text I tested contained only four characters: ABCD, no newlines
(not even at the end of the single line).

-Frank

 

[Frank Sconzo]

Tim,

Thanks very much for your response; I sincerely appreciate it! I've
been struggling over this for a few days, but you've solved the
puzzle.

How in the world did you figure this out?

Thank you,
Frank