2017-04-19 13:47 GMT+02:00 Roland Knall <[email protected]>: > 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 <[email protected]> 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 <[email protected]> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected]?subject=unsubscr >> ibe >> > > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscr > ibe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
