[Sebastien morin <morin_s@xxxxxxxxxxx>]

On Tue, 22 Jun 2004, ronnie sahlberg wrote:

Thks for your response.

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

	I am ok with you, it seems to be some else.

>
> 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).

	yes long and boring, i will ...
>
>
> 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.

	In the first 70 packets transmit between Exchange and Outlook
	there is no changement with 2003 2000 and 5.5

	The dump i provide is the Stub data of Outlook request to the port
	mapper.
	We can detect the UUID, The Transfert Syntax, some kind of
	version, some fixed data 00 13 00 0D which seems to prevent a UUID
	or transfert syntaxt beginning.
	So i m not here for details, but these packets seems to be always
	the same, and unchangeable.

	I have detected neer 50% of the data in these packets, but
	marshalling as you said is unknown.

	thank you for your precise details, I would announce advance of
	the project, it should be useful.
>
>
> 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.

	Thks
>
> 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                                              ..

-- 
Sebastien Morin
Epitech
Openchange Project : http://www.openchange.org