[PATCH] nstring and astring support in PIDL and Wireshark

[Julien Kerihuel]

Hi Lists,

First of all, sorry for this cross-posting, non-subscriber post which
furthermore also includes attachments. This probably breaks some of the
most elementary mailing-list rules, so feel free to mention if it's
inappropriate and/or where these emails better belongs in the future.

Introduction:
=============
I'm currently working on improving the MAPI wireshark dissector - add
support for Exchange 2003/2007/2010 RPC functions (EcDoConnectEx and
EcDoRpcExt2, respectively 0xA and 0xB).

The OpenChange IDL is pretty big, it works smoothly with Samba4, but the
point is that MAPI structures are non-NDR compatible and passing the IDL
to pidl Wireshark's parser produces numerous errors.

The series of patches I'm working on are trying to solve these
incompatibilities issues, providing (as much as possible) an
auto-generated dissector rather than a long, painful and prone errors
hand-written one.

nstring and astring patch explained:
====================================
One of the recurrent type of strings we are using in OpenChange for MAPI
structures are astring and nstring. These are strings which are not
prefixed with any NDR fields such as [size][offset][length] and which
overall length is found by parsing the string until we find NUL
terminated characters.

To make it more obvious, a classical NDR-encoded string would be:
[size][offset][length][my super string][NULL]

The astring version would be:
[my super string][NULL]

Wireshark is already providing an API for UTF8 strings with the
tvb_get_stringz family in epan/tvbuff.c.

This patch adds:
- similar support for Unicode strings in epan/tvbuff.c
- dissect_nastring function in packet-dcerpc.c for pidl which will let
pidl generate code both for astring and nstring.


Notes:
======
In this case, the provided pidl patch is naive, probably have side
effects and surely require changes. It basically fails back to
dissect_nastring if the string couldn't be handled by previous cases.
There's probably a saner way to do this.

Regarding the wireshark patch, the only thing I'm not really happy with
is the guint16_find function which clearly extends its intended scope
and assume the tvbuff parameter IS an unicode string.

Furthermore, the way to detect unicode end of string is pretty bad, but
I followed the *_fake_unicode wireshark's logic here.

Conclusion:
===========
The wireshark patch can be applied independently from Samba's PIDL one.
The new functions won't impact the existing wireshark source code.

Some wireshark's developers may be reluctant adding such non-NDR
compatible dissection functions to packet-dcerpc.c but I really do think
this is a worthwhile move to speed up MAPI dissector development.

For the record, I'm currently developing the new MAPI dissector on a
separate repository where I can play, apply changes to pidl and save
wireshark patches properly, until this goes upstream (or not):

$ svn co https://svn.openchange.org/dissector openchange_dissector


Cheers,
Julien.

-- 
Julien Kerihuel
j.kerihuel at openchange.org
OpenChange Project Manager

GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 001_wireshark_nstring_astring_support.diff
Type: text/x-patch
Size: 12691 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100114/a805cd4f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pidl_nastring.diff
Type: text/x-patch
Size: 656 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100114/a805cd4f/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100114/a805cd4f/attachment.pgp>