Julien Kerihuel | 20 Jan 2007 08:46
Favicon
Gravatar

[Devel]: TDR layer decoding in ndrdump

Morning all,

I've been working on a way to include TDR layer decoding in ndrdump.
Here's a reminder on how we currently decode EcDoRpc packets:

NDR layer: EcDoRpc
subcontext with obfuscation: MAPI_DATA
TDR layer: MAPI_DATA content (uint8 *)

Until now when running ndrdump on known EcDoRpc packets when had a blob
of data displayed rather than the decoded structure implemented in the
IMAPISession idl.

In order to add TDR layer, I have modified ndr_mapi.c and the function
ndr_print_MAPI_DATA - casted the uint8_t *content + other fields to fit
in a MAPI_REQ or MAPI_REPL structure.

The only real problem I had was how to keep the inout state at
ElementLevel. At first I based the inout check on the EcDoRpc_action
value, but this naming is wrong and Fabien provided me rpcsniff reports
where we have 0x0 both for in and out packets. So we can't rely on this
field and we'll need to change the IDL.

Finally I modified the Samba4/NDR/Parser.pm to add the NDR_IN and
NDR_OUT flags to the ndr->flags field (patch in attachment). There's
maybe a better way to proceed and the patch may induce unwanted side
effects I didn't notice. 

Jelmer do you see another way to handle this or is the current one
correct?
(Continue reading)

Jelmer Vernooij | 21 Jan 2007 00:26
Picon
Favicon

Re: [Devel]: TDR layer decoding in ndrdump

Hi Julien,

On Sat, 2007-01-20 at 08:46 +0100, Julien Kerihuel wrote:
> The only real problem I had was how to keep the inout state at
> ElementLevel. At first I based the inout check on the EcDoRpc_action
> value, but this naming is wrong and Fabien provided me rpcsniff reports
> where we have 0x0 both for in and out packets. So we can't rely on this
> field and we'll need to change the IDL.
> 
> Finally I modified the Samba4/NDR/Parser.pm to add the NDR_IN and
> NDR_OUT flags to the ndr->flags field (patch in attachment). There's
> maybe a better way to proceed and the patch may induce unwanted side
> effects I didn't notice. 
> 
> Jelmer do you see another way to handle this or is the current one
> correct?
This is definitely incorrect. The NDR_IN and NDR_OUT flags are never checked in the ndr->flags field.
NDR_IN is defined as 1, which is the same thing as LIBNDR_FLAG_BIGENDIAN and NDR_OUT is defined as 2, which
is the same thing as LIBNDR_FLAG_NOALIGN. Are you sure this patch fixes it? Maybe you just need to set
flag(NDR_NOALIGN) somewhere?

Cheers,

Jelmer
--

-- 
Jelmer Vernooij <jelmer <at> samba.org> - http://samba.org/~jelmer/
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
(Continue reading)

Julien Kerihuel | 21 Jan 2007 16:05
Favicon
Gravatar

Re: [Devel]: TDR layer decoding in ndrdump

Hi Jelmer,

You are right, I should have been looking at libndr.h.

Here is another patch which fixes the problem by adding a uint8_t inout
in the ndr_print struct and assign the flags to ndr->inout in ndrdump.c.
This way we keep the ndr flags untouched and we don't have to modify NDR
Parser.

About NDR_NOALIGN, I doubt we can use it since we need to use the
NDR_IN|NDR_OUT flags within the deobfuscated MAPI_DATA context - next
applied with the mapi.idl (TDR one).

On Sun, 2007-01-21 at 00:26 +0100, Jelmer Vernooij wrote:
> Hi Julien,
> 
> On Sat, 2007-01-20 at 08:46 +0100, Julien Kerihuel wrote:
> > The only real problem I had was how to keep the inout state at
> > ElementLevel. At first I based the inout check on the EcDoRpc_action
> > value, but this naming is wrong and Fabien provided me rpcsniff reports
> > where we have 0x0 both for in and out packets. So we can't rely on this
> > field and we'll need to change the IDL.
> > 
> > Finally I modified the Samba4/NDR/Parser.pm to add the NDR_IN and
> > NDR_OUT flags to the ndr->flags field (patch in attachment). There's
> > maybe a better way to proceed and the patch may induce unwanted side
> > effects I didn't notice. 
> > 
> > Jelmer do you see another way to handle this or is the current one
> > correct?
(Continue reading)

Julien Kerihuel | 21 Jan 2007 20:44
Favicon
Gravatar

Re: [Devel]: TDR layer decoding in ndrdump

Hu :/

sorry for mail duplication. Seems like the mail server has bugged once again.

 
On Sunday 21 January 2007 16:05, Julien Kerihuel wrote:
> Hi Jelmer,
>
> You are right, I should have been looking at libndr.h.
>
> Here is another patch which fixes the problem by adding a uint8_t inout
> in the ndr_print struct and assign the flags to ndr->inout in ndrdump.c.
> This way we keep the ndr flags untouched and we don't have to modify NDR
> Parser.
>
> About NDR_NOALIGN, I doubt we can use it since we need to use the
> NDR_IN|NDR_OUT flags within the deobfuscated MAPI_DATA context - next
> applied with the mapi.idl (TDR one).
>
> On Sun, 2007-01-21 at 00:26 +0100, Jelmer Vernooij wrote:
> > Hi Julien,
> >
> > On Sat, 2007-01-20 at 08:46 +0100, Julien Kerihuel wrote:
> > > The only real problem I had was how to keep the inout state at
> > > ElementLevel. At first I based the inout check on the EcDoRpc_action
> > > value, but this naming is wrong and Fabien provided me rpcsniff reports
> > > where we have 0x0 both for in and out packets. So we can't rely on this
> > > field and we'll need to change the IDL.
> > >
> > > Finally I modified the Samba4/NDR/Parser.pm to add the NDR_IN and
(Continue reading)


Gmane