[Wireshark-dev] Lua dissector for raw 802.11 data frames
?Hi,
I am working on a dissector that dissects a proprietary protocol that uses raw
802.11 data frames. The protocol specification is not open so I won't be able
to contribute the dissector. I've therefore chosen to implement it in Lua.
Without patching Wireshark's 802.11 dissector I'm not able to register my own
dissector. So seeking advice on proper ways to proceed and implement.
I can get it working by adding support for heuristic sub-dissectors on 802.11
data frames. An unfinished example uploaded here:
https://code.wireshark.org/review/#/c/27641/?
With that patch applied a Lua dissector can then register for and analyze the
frames like this:
local proto_example = Proto("example", "example protocol")
function is_example_protocol(tvb, pinfo)
-- check frame header and decide whether example protocol
return true
end
function proto_example.dissector(tvb, pinfo, tree)
if not is_example_protocol(tvb) then
return 0
end
-- Skip 802.11 frame header
local n = 30
pinfo.cols.info = ""
pinfo.cols.protocol = "Example"
tree = tree:add(proto_example, tvb)
tree:add(f.data, tvb(n));
return tvb:len()
end
proto_example:register_heuristic("wlan_data", proto_example.dissector)
f = proto_example.fields
f.data = ProtoField.bytes("example.data", "data")
/Mikael
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Asciidoctor PDF generation
On 5/17/18 11:55 PM, Jaap Keuter wrote:
> Hi list,
>
> Working on a Debian testing system, the packagers have come so far as to
> package the recent update to Asciidoctor. This allows to generate the
> Wireshark documentation (WSUG/WSDG) with the proper layout. One stage is PDF
> generation, which requires an additional backend, being asciidoctor-pdf.
> This, not being in the Debian repository, is to be installed though gem,
> which works perfectly fine.
>
> Still, for this to work with the Wireshark documentation generation (PDF
> versions of it) there needs to be an additional option to the asciidoctor
> command line, otherwise it will not be aware of the PDF backend and fail. The
> addition is to the cmake/modules/FindAsciidoctor.cmake file, to the macro
> ASCIIDOCTOR2PDF. In there the parameter ‘--require asciidoctor-pdf’ needs to
> be added.
>
> Before pushing a change, I wanted to confirm that this additional parameter
> would not interfere with other doc build setups. Can you ‘Asciidoctor-J’
> people out there confirm?
>
> --- /tmp/5T9mK4_FindAsciidoctor.cmake
> +++ src/wireshark/wsug_mate/cmake/modules/FindAsciidoctor.cmake
> @@ -127,6 +127,7 @@
> ${_output_pdf}
> COMMAND ${_asciidoctor_common_command}
> --backend pdf
> +--require asciidoctor-pdf
> ${_asciidoctor_common_args}
> --out-file ${_output_pdf}
> ${CMAKE_CURRENT_SOURCE_DIR}/${_asciidocsource}
`asciidoctorj --backend pdf --require asciidoctor-pdf` works fine for me here.
We should probably make the PDF targets depend on AsciidoctorJ or
asciidoctor-pdf as discussed in https://code.wireshark.org/review/#/c/26129/ .
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
Hey folks, Here's what I'm thinking at this point: a new block type for SSL/TLS keylogs and another block type for DTLS keylogs. The contents of each will be the format as described here: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format Any number of these blocks can be included. For each block encountered, ssl_load_keyfile will be called, with the correct per-protocol master key map included. Some code refactoring to ssl_load_keyfile will likely be required since we're dealing with an array of bytes instead of a FILE. One thing I'm unclear on is how to trigger a reparse of previously processed packets when a keylog block is encountered at e.g. the end of the file. Is that possible? Thanks, Ben On Sat, May 5, 2018 at 2:19 AM, Guy Harris wrote: > On May 5, 2018, at 2:07 AM, Ahmad Fatoum wrote: > > >> On 5May 2018, at 10:47, Guy Harris wrote: > >> > >> That doesn't require "some authority that allocates protocol > identifiers", because it doesn't require protocol identifiers; all that > needs to be done is to allocate pcapng block types to those protocols that > require some additional information to decrypt its traffic. > > > > I like the idea of a "universal" key pcapng block more than requiring > each interested protocol to request its own block. > > Each protocol's key format has to be documented, to allow arbitrary > programs to use the block, so they'll have to request it *anyway*, > supplying the key format as part of the request. > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject= > unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
On Fri, May 18, 2018 at 11:44:12AM -0700, Ben Higgins wrote: > Hey folks, > > Here's what I'm thinking at this point: a new block type for SSL/TLS > keylogs and another block type for DTLS keylogs. The contents of each will > be the format as described here: > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format The key log file format is the same for TLS and DTLS, but due to an implementation detail (two separate preferences for DTLS and TLS in Wireshark), they are different. I am not opposed to having two different blocks, but would it make more sense to combine them and create a single "TLS key log" block and have both the DTLS and TLS dissectors read it? > Any number of these blocks can be included. For each block encountered, > ssl_load_keyfile will be called, with the correct per-protocol master key > map included. Some code refactoring to ssl_load_keyfile will likely be > required since we're dealing with an array of bytes instead of a FILE. Ok, doable. > One thing I'm unclear on is how to trigger a reparse of previously > processed packets when a keylog block is encountered at e.g. the end of the > file. Is that possible? Decryption currently requires keys to be available on the first pass. I guess that for offline capture files, one needs to adjust pcapng_open and add something similar to "pcapng_process_idb", but then for decryption blocks. Kinds regards, Peter ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
On May 18, 2018, at 5:51 PM, Peter Wu wrote: > On Fri, May 18, 2018 at 11:44:12AM -0700, Ben Higgins wrote: > >> One thing I'm unclear on is how to trigger a reparse of previously >> processed packets when a keylog block is encountered at e.g. the end of the >> file. Is that possible? > > Decryption currently requires keys to be available on the first pass. > I guess that for offline capture files, one needs to adjust pcapng_open > and add something similar to "pcapng_process_idb", but then for > decryption blocks. pcapng_process_idb is called from pcapng_open only for IDBs at the *beginning* of the file. There's no guarantee that IDBs won't appear after packet blocks; the only requirement in pcapng is that you can't have packets for a particular interface without the IDB for that interface having appeared. So "[adjusting] pcapng_open and [adding] something similar to "pcapng_process_idb", but then for decryption blocks." would work for keylog blocks that appear at the beginning of the file, but it won't help with keylog blocks at the end of the file. The *only* way to handle keylog blocks at the end of a file would be to make *two* passes over the file, with the first pass just reading blocks and *not* doing any dissection, and with all dissection done *after* all blocks have been read. This would be a *significant* change to the way Wireshark works, and wouldn't work very well at all for one-pass TShark or live capture). The same applies for any *other* program that would read pcapng files and do decryption. So I would strongly advise doing whatever is necessary to put keylog blocks *before* any packet that requires them. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
On Fri, May 18, 2018 at 5:51 PM, Peter Wu wrote: > On Fri, May 18, 2018 at 11:44:12AM -0700, Ben Higgins wrote: > > Hey folks, > > > > Here's what I'm thinking at this point: a new block type for SSL/TLS > > keylogs and another block type for DTLS keylogs. The contents of each > will > > be the format as described here: > > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/ > NSS/Key_Log_Format > > The key log file format is the same for TLS and DTLS, but due to an > implementation detail (two separate preferences for DTLS and TLS in > Wireshark), they are different. I am not opposed to having two different > blocks, but would it make more sense to combine them and create a single > "TLS key log" block and have both the DTLS and TLS dissectors read it? > Yes, I think having one block would make more sense. The only reason I proposed two was because I noticed this Wireshark implementation detail :-) > > Any number of these blocks can be included. For each block encountered, > > ssl_load_keyfile will be called, with the correct per-protocol master key > > map included. Some code refactoring to ssl_load_keyfile will likely be > > required since we're dealing with an array of bytes instead of a FILE. > > Ok, doable. > > > One thing I'm unclear on is how to trigger a reparse of previously > > processed packets when a keylog block is encountered at e.g. the end of > the > > file. Is that possible? > > Decryption currently requires keys to be available on the first pass. > I guess that for offline capture files, one needs to adjust pcapng_open > and add something similar to "pcapng_process_idb", but then for > decryption blocks. > > Kinds regards, > Peter > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject= > unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
On Fri, May 18, 2018 at 6:02 PM, Guy Harris wrote: > On May 18, 2018, at 5:51 PM, Peter Wu wrote: > > > On Fri, May 18, 2018 at 11:44:12AM -0700, Ben Higgins wrote: > > > >> One thing I'm unclear on is how to trigger a reparse of previously > >> processed packets when a keylog block is encountered at e.g. the end of > the > >> file. Is that possible? > > > > Decryption currently requires keys to be available on the first pass. > > I guess that for offline capture files, one needs to adjust pcapng_open > > and add something similar to "pcapng_process_idb", but then for > > decryption blocks. > > pcapng_process_idb is called from pcapng_open only for IDBs at the > *beginning* of the file. > > There's no guarantee that IDBs won't appear after packet blocks; the only > requirement in pcapng is that you can't have packets for a particular > interface without the IDB for that interface having appeared. > > So "[adjusting] pcapng_open and [adding] something similar to > "pcapng_process_idb", but then for decryption blocks." would work for > keylog blocks that appear at the beginning of the file, but it won't help > with keylog blocks at the end of the file. > > The *only* way to handle keylog blocks at the end of a file would be to > make *two* passes over the file, with the first pass just reading blocks > and *not* doing any dissection, and with all dissection done *after* all > blocks have been read. This would be a *significant* change to the way > Wireshark works, and wouldn't work very well at all for one-pass TShark or > live capture). > > The same applies for any *other* program that would read pcapng files and > do decryption. > > So I would strongly advise doing whatever is necessary to put keylog > blocks *before* any packet that requires them. > Roger that. Sounds like it'd still be fine for there to be multiple keylog blocks, but, as you say, they must occur before any packets that require the secrets contained therein. Is that correct? > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject= > unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
On May 18, 2018, at 6:08 PM, Ben Higgins wrote: > Sounds like it'd still be fine for there to be multiple keylog blocks, Yes. > but, as you say, they must occur before any packets that require the secrets > contained therein. Is that correct? Yes. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
On Friday, May 18, 2018, Guy Harris wrote: > On May 18, 2018, at 6:08 PM, Ben Higgins wrote: > > > Sounds like it'd still be fine for there to be multiple keylog blocks, > > Yes. > > > but, as you say, they must occur before any packets that require the > secrets contained therein. Is that correct? > > Yes. Great, thanks. I plan to have us implement this feature accordingly. Should we file a new ticket along these lines or will the existing ticket suffice? ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
Hello Ben, Similar to the way that IDBs must be preceded by any EPBs that reference it, Apple's tcpdump can augment pcpang files with proprietary process information blocks. EPBs are augmented with proprietary options that can reference any preceding process information blocks. Unfortunately Apple in their infinite wisdom opted not to register reserved values for their packet information blocktype number nor for the various process information related EPB option numbers. Instead Apple opted to go the lazy route and simply used "local use" values. Please do not Apple's mistake of using "local use" values in pcapng capture files that will be publicly available. Late last year I submitted a hacky and currently stalled WIP attempt to process these proprietary Apple blocks and options in change 24641. The fact that Apple used "local use" values (and choose specific "local use" values that arguably are more likely to be used by others) it is not likely my patch or anything better will be merged unless parsing and processing of the Apple propriety block and options pcapng are optional and disabled by default. I'll be looking forward to seeing how you implement the SSL keylog info into pcapng. Good luck and best regards, Jim Y. On Fri, May 18, 2018 at 10:05 PM, Ben Higgins wrote: > > > On Friday, May 18, 2018, Guy Harris wrote: > >> On May 18, 2018, at 6:08 PM, Ben Higgins wrote: >> >> > Sounds like it'd still be fine for there to be multiple keylog blocks, >> >> Yes. >> >> > but, as you say, they must occur before any packets that require the >> secrets contained therein. Is that correct? >> >> Yes. > > > Great, thanks. I plan to have us implement this feature accordingly. > Should we file a new ticket along these lines or will the existing ticket > suffice? > > >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject= >> unsubscribe > > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject= > unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Embed SSL keylog file in pcap-ng
On Fri, May 18, 2018 at 7:49 PM, Jim Young wrote: > Hello Ben, > > Similar to the way that IDBs must be preceded by any EPBs that reference > it, Apple's tcpdump can augment pcpang files with proprietary process > information blocks. EPBs are augmented with proprietary options that can > reference any preceding process information blocks. > > Unfortunately Apple in their infinite wisdom opted not to register > reserved values for their packet information blocktype number nor for the > various process information related EPB option numbers. Instead Apple > opted to go the lazy route and simply used "local use" values. > > Please do not Apple's mistake of using "local use" values in pcapng > capture files that will be publicly available. > > Late last year I submitted a hacky and currently stalled WIP attempt to > process these proprietary Apple blocks and options in change 24641. The > fact that Apple used "local use" values (and choose specific "local use" > values that arguably are more likely to be used by others) it is not likely > my patch or anything better will be merged unless parsing and processing of > the Apple propriety block and options pcapng are optional and disabled by > default. > > I'll be looking forward to seeing how you implement the SSL keylog info > into pcapng. > Thanks for the background, Jim. I don't think it makes sense for there to be anything proprietary in this block. The contents of this block will be what Wireshark already supports for key log files, described here: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format The big win is that a single pcapng file can contain everything needed for Wireshark to decrypt its contents. Today, the user has to jump through some hoops (either clicking through dialog boxes or knowing the (perhaps undocumented?) command-line option) to select a keylog file. We want to improve on that experience. Ben Good luck and best regards, > > Jim Y. > > On Fri, May 18, 2018 at 10:05 PM, Ben Higgins wrote: > >> >> >> On Friday, May 18, 2018, Guy Harris wrote: >> >>> On May 18, 2018, at 6:08 PM, Ben Higgins wrote: >>> >>> > Sounds like it'd still be fine for there to be multiple keylog blocks, >>> >>> Yes. >>> >>> > but, as you say, they must occur before any packets that require the >>> secrets contained therein. Is that correct? >>> >>> Yes. >> >> >> Great, thanks. I plan to have us implement this feature accordingly. >> Should we file a new ticket along these lines or will the existing ticket >> suffice? >> >> >>> ___ >>> Sent via:Wireshark-dev mailing list >>> Archives:https://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscr >>> ibe >> >> >> >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscr >> ibe >> > > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject= > unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
