Re: Specifying dissectors declaratively

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

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=
> unsubscribe
___________________________________________________________________________
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