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]

Frank Sconzo wrote:

> 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]

On 2 May 2004 10:21:23 -0700, frank....@dowjones.com (Frank Sconzo)
wrote:

>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

Joe Smith <Joe....@inwap.com> wrote in message news:<17clc.16908$0H1.1577022@attbi_s54>...

[Tim Heaney]

frank....@dowjones.com (Frank Sconzo) writes:
>
> 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?

I think perhaps Outlook inverted things in a different sense than
is usual.

$ perl -M'Digest::CRC qw(crc_hex)' -le 'print reverse unpack "A2"x4,
crc_hex("ABCD",32,0,0,1,0x04C11DB7,1)'

b9ff53fa

For comparison, the usual CRC32 corresponds to

$ perl -M'Digest::CRC qw(crc_hex)' -le 'print crc_hex("ABCD",32,
0xffffffff,0xffffffff,1,0x04C11DB7,1)'

db1720a5

Tim

[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

Tim Heaney <the...@cablespeed.com> wrote in message news:<878yg96...@mrbun.watterson>...

[Tim Heaney]

frank....@dowjones.com (Frank Sconzo) writes:
> 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.

You're most welcome. I'm glad I could help!

> How in the world did you figure this out?

I just sort of guessed. I fiddled with the parameters a bit until
fa53ffb9 popped out and decided that was probably it with the bytes in
the wrong order. Lacking access to Outlook, I'll leave it to you to
verify it for more cases. You may still run into problems with those
"ignorable characters" you mentioned.

Good luck!

Tim