Re: Specifying dissectors declaratively

[Pascal Quantin <pascal.quantin () gmail com>]

2017-04-19 13:47 GMT+02:00 Roland Knall <rknall () gmail com>:

> Generally speaking we can divide new protocol languages in two different
> classes:
>
> - interpreting ones
> - compiled ones
>
> The interpreting class has LUA and wsgd as representative. They have their
> benefits, but I do not really like the approach of interpreting at runtime.
>
> CSjark seems interesting, but in my view is way to complicated, as goes
> for the kaitai-to-wireshark structure
>
> ASN.1 is a language apparently very much used in the telephone community.
> (Anders, Pascal - any input here?), which has a lot of code already in
> existence. But in my opinion not really usable for most other protocols
> which include bigger state machines (like industrial ethernet protocols).

It's true that it is used a lot for telephony business. ASN stands for
Abstract Syntax Notation and defines a grammar that is independent of the
encoding used. Then you have all the encoding variants: (aligned or not)
PER, BER, DER, XER, GSER, OER, etc... It could be used for any protocol,
but it's encoding is complex and not as friendly as a basic TLV one for
humans like us :)

asn2wrs is really specialized for (un)aligned PER and BER, so not relevant
to any other protocol (and should not be extended to something else other
than ASN.1 variants).



> Kaitai seems very interesting to just have a short look at. But the
> question is still, not really which language to use, but what should the
> integration be like.
>
> A basic LUA translation does not make much sense to me, as this can easily
> be achieved by just investing the same amount of time in learning LUA. So
> it should be a more native approach. And with that it is a question of what
> can be used from other projects. I think only the
>
> The main problem with Kaitai is the fact, that it uses scala as
> development language. This would mean another language for us developers to
> install and test. Just using the compiler with Wireshark opens up a lot of
> issues, which I do not want to have. wsgd does not have those issues, but
> as it is a plugin and doing interpretation, a more compile-like alteration
> might do the trick.
>
> You have basically two options here:
>
> - Just use Kaitai syntax but rewrite the parser as a c-library to include
> with wireshark
> - Extend wsgd to be able to achieve what you want and help bring that
> mainstream (which I have no idea about if this is actually wanted at all)
>
> If a new language is being added to mainstream it should not be another
> interpreting language, but rather a compiled language, preferable using a
> c-library or python scripts which can be easily built across developer
> consoles without pre-existing conditions (e.g. another compiler) on the
> build-environment. Something python-based may have a good chance as well.
>
> cheers
> Roland
>
>
> On Wed, Apr 19, 2017 at 11:27 AM, Ahmad Fatoum <ahmad () a3f at> wrote:
>
> > Hello everyone,
> >
> > I want to update a game protocol dissector I wrote, and would love to be
> > able to rewrite all those game commands in a declarative manner.
> > What I've found so far:
> >
> > • ASN.1: asn2wrs, part of Wireshark and supports packed encoding rules
> > (PER), but I believe it's not possible to decode an arbitrary non-ASN.1
> > encoded protocol [1]. Is that right?
> >
> > • Wireshark Generic Dissector: A plugin that can read a DSL and dissect
> > packets accordingly [2].
> >
> > • CSjark: C structs to Lua dissectors [5].
> >
> > • Kaitai Struct: A declarative language written for decoding arbitrary
> > formats [3]. There's a basic Wireshark LUA dissector generator [4].
> >
> >
> >
> > In essence, I want something to turn struct-like definitions for an
> > arbitrary protocol into a dissector. Should support:
> > • struct pascal_string { u16 len; u8 bytes[len] };
> > • continue till character: e.g. for nul-terminated strings
> > • pattern matching: struct { u8 0x64; /* 0x64 specific fields */ },
> > struct { u8 0x10; /* 0x10 specific fields */ }
> > • arbitrary nesting thereof
> > • endianness specification
> > • code generation: The protocol in question is encrypted. So e.g. the
> > generic dissector plugin is insufficient.
> >
> > Having readily available parser generators for the format would be a huge
> > plus. Kind of like lex/yacc, but for binary data and with a Wireshark
> > backend.
> >
> > So, what are your experiences with declaratively parsing binary data?
> > What are your thoughts on having a declarative format for dissectors?
> > Have you tried it before?
> > If the ASN.1 support in Wireshark isn't fit for this task, what would
> > need to be done to make it so?
> > Would you be interested in a kaitai2wrs generator? Or maybe
> > another_format2wrs? I'd be willing to try.
> >
> >
> > This was raised multiple times before on the mailing list, the most
> > extensive one being this, I think:
> > https://www.wireshark.org/lists/wireshark-dev/201207/msg00110.html
> >
> >
> > Nevertheless, things might have changed?
> >
> >
> > Looking forward to feedback.
> >
> > Best regards,
> >
> >
> > [1]: https://wiki.wireshark.org/Asn2wrs
> > [2]: http://wsgd.free.fr/
> > [3]: http://kaitai.io/
> > [4]: https://github.com/joushx/kaitai-to-wireshark
> > [5]: https://github.com/eventh/kpro9
> >
> > ____________________________________________________________
> > _______________
> > Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> > Archives:    https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >              mailto:wireshark-dev-request () wireshark org?subject=unsubscr
> > ibe
>
>
> ____________________________________________________________
> _______________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscr
> ibe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe