I was aware that the work you have done is still in the early stages.
In fact, I already spotted a problem where the MAPI Logon response was
not properly handling the padding between the first and second strings.
It's an excellent start, and I would be interested in doing more work on
the dissector.
My thought for reverse engineering the protocol was basically as
follows:
Write some win32 code using the MAPI API to exercise each of the
individual MAPI calls separately. This would allow us to better decode
the frames because we would know which frames for a given trace
correspond to which MAPI calls. We would also have the source code that
originated the call, which is useful in locating 'flags' fields, etc. I
think this would be better than using just an MS Exchange server trace,
which makes tons of calls when you start it up.
Perhaps we should get together a library of traces that are as simple as
possible for any given request type?
I believe you are correct that documentation is very scarce on the
protocol itself. There was a thread over on the Evolution Hackers
mailing list where Luke Kenneth Casson Leighton indicated the use of
xor'ing 0aA5 as the obfuscation (which it looks like you already knew
about and incorporated into the dissector). Other than that, I have
found very little. It looks like HP OpenMail needed an MAPI alternative
to be installed on the Exchange client, and Ximian appears to be using
webDAV to access MS Exchange. From this one can gather that neither
successfully reversed engineered the MAPI protocol.
-Devin
On Fri, 2002-06-21 at 11:11, Ronnie Sahlberg wrote:
> Hi,
>
> Be aware that the MAPI support is currently extremely limited.
> Basically limited to a few function names and some of the parameters for
> Logon and Logoff.
> It is not really too useful right now.
>
> I did not find any proper documentation on MAPI and reverse engineering
> showed to be more
> work than first expected.
> Basically, the interesting data is not marshalled in NDR encoding (which
> would make it easy to read)
> nor is it obvious what fields/aggregates that data contain. :-(
> I did not have the time required to continue looking at it and got
> distracted with more immediate needs.
>
> If you are interested in generating traffic and reverse engineering the
> protocol I may be interested in
> assisting you with this task.
>
>
> ----- Original Message -----
> From: "Devin Heitmueller"
> Sent: Thursday, June 20, 2002 8:01 AM
> Subject: [Ethereal-dev] MAPI capture sample on ethereal website
>
>
> > Has anyone noticed that the MAPI sample capture on the Ethereal website
> > is invalid? The trace doesn't appear to include the DCE/RPC bind
> > request, so Ethereal doesn't know to use the sahlberg's dissector on the
> > session.
> >
> > The only reason I mention it is because I spent half an hour trying to
> > figure out why the MAPI dissector wasn't working, only to find the trace
> > was invalid.
> >
> > --
> > Devin Heitmueller
> > Senior Software Engineer
> > Netilla Networks Inc
> >
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc
