Wireshark · Ethereal-dev: Re: [Ethereal-dev] MAPI and Exchange

[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

Hi Sebastien,

Afaicr (as far as i can recall) Exchange relies heavily on two DCE/RPC
interfaces:
NSPI(memory may be wrong here) and MAPI.

NSPI would be reasonably trivial to rev engineer (but timeconsuming) since 
NetMon dissects this protocol.      VI + TEXT2PCAP + NETMON would be the tools
to use here and it would be reasonably easy to rev eng it, albeight boring work
(and semi-pointless since this is not (afaik) too interesting unless
MAPI is rev enged at the same time).


MAPI on the other hand is a different issue.
For MAPI, the meat of what happens and 99% of all that goes on is
inside the payload of  function 2 on this interface : EcDoRpc.

While Ethereal can "decrypt" the payload (using super-complicated
decryption algorithms)    the payload itself is in some (to me)
unknown marshalling ruleset.
As far as i can tell   it is definitely not BER/DER/NDR or any other
known and common encoding used.
It could theoretically be PER, but then again, PER results in
semi-random modem-noice style output and would be virtually impossible
to decode by looking at packet dumps.

There are however patterns in the EcDoRpc payload so I dont think it
is PER encoded at all,   maybe it is some homebrewed encoding
mechanism, maybe it is some sort of byte-code thing?  Who knows.
It looks nothing like any of the encoding rules I am familiar with and
thus i lost interest in it.
With a lot of time, a lot of controlled sample data/captures and a lot
of time I am certain one could theoretically rev eng it. It would be a
lot of hard work though.
There are suffiicient amounts of reoccuring patterns in the payload to
work from.


The hexdump you provided looks nothing like the usual payload data I
saw inside the EcDoRpc payloads at all.  Maybe they have changed it in
exchange 2k3  or maybe you are looking at something different.


A possible way to start would be to create a large number of very very
small and controlled captures for very simple controlled operations of
exchange and try to spot patterns in the resulting wire encoding.  A
lot of work, but should be possible.


I wish you good luck.

ronnie sahlberg

On Tue, 22 Jun 2004 11:57:51 +0200 (CEST), Sebastien morin  wrote:
> 
> Hello,
> 
>        We work on the Openchange Project
>        Openchange intends to provide an Open-Source implementation of Microsoft
>        Exchange Server 2003 under Unix Platforms.
> 
>        I work on the Openchange Part and hard for Stub data after
>        Bind & Bind Ack on the port mapper 135 between a Exchange server
>        and a outlook client.
> 
> see below the 132 bytes
> 
>                                                 01 00   ........ ........
> 0050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
> 0060  00 00 02 00 00 00 4b 00  00 00 4b 00 00 00 05 00   ......K. ..K.....
> 0070  13 00 0d e0 f5 44 15 3c  61 d1 11 93 df 00 c0 4f   .....D.< a......O
> 0080  d7 bd 09 01 00 02 00 00  00 13 00 0d 04 5d 88 8a   ........ .....]..
> 0090  eb 1c c9 11 9f e8 08 00  2b 10 48 60 02 00 02 00   ........ +.H`....
> 00a0  00 00 01 00 0b 02 00 00  00 01 00 07 02 00 00 87   ........ ........
> 00b0  01 00 09 04 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
> 00c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 04 00   ........ ........
> 00d0  00 00                                              ..
> 
> I have identifers some parts of this, but many things remain fuzzy.
> 
> I would like to gather informations of people who worked above to advance
> more quickly and to be able to divide it.
> 
> Thks for your suggestions.
> 
> --
> Sebastien Morin
> Epitech
> Openchange Project : http://www.openchange.org
> 
> > Unfortunately no.    No one has as far as i know worked on trying to rev
> > engineer the rpc protocol implemented ontop of
> > MAPI yet.
> > As far as i could tell when i looked at it about 2 years ago, it did not
> > look like any known encodings like BER/DER  NDR etc etc.
> > Could be PER but I dont know.
> 
> > If one knew what DLLs are used with the process maybe one can make a
> > guess on what kind of wire encoding is used.
> 
> > But i fear it would be a lot of work required to reverse engineer it. A lot
> > of work.
> > It would probably also require one to have a full blown exchange setup with
> > clients where one can make a small operation and see
> > what rpc they generate.
>