CRC on Unix vs Win32

Discussion in 'Perl Misc' started by Frank Sconzo, May 2, 2004.

  1. Frank Sconzo

    Frank Sconzo Guest

    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
    Frank Sconzo, May 2, 2004
    #1
    1. Advertising

  2. Frank Sconzo

    Joe Smith Guest

    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
    Joe Smith, May 2, 2004
    #2
    1. Advertising

  3. Frank Sconzo

    Geoff Guest

    On 2 May 2004 10:21:23 -0700, (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.
    Geoff, May 2, 2004
    #3
  4. Frank Sconzo

    Frank Sconzo Guest

    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 <> wrote in message news:<17clc.16908$0H1.1577022@attbi_s54>...
    > 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
    Frank Sconzo, May 3, 2004
    #4
  5. Frank Sconzo

    Frank Sconzo Guest

    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 <> wrote in message news:<>...
    > (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, May 3, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    12
    Views:
    1,618
    Dave Thompson
    Jan 10, 2005
  2. Replies:
    18
    Views:
    609
    Dave Thompson
    Jan 10, 2005
  3. Mamut

    crc-8 and crc-16 code...

    Mamut, Feb 21, 2007, in forum: C++
    Replies:
    5
    Views:
    4,021
    Victor Bazarov
    Feb 22, 2007
  4. `Zidane Tribal
    Replies:
    1
    Views:
    2,505
    Joe Smith
    Jul 28, 2007
  5. `Zidane Tribal
    Replies:
    3
    Views:
    241
    Sisyphus
    Jul 27, 2007
Loading...

Share This Page