[Roland Knall <rknall@xxxxxxxxx>]

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@xxxxxx> 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@xxxxxxxxxxxxx>
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