I'm working on building wireshark plugins on OSX. I've generated .dylibs some via rust crates wsdf and plugshark on my macOS 14.5, M1 and wireshark-devel files, libwireshark.etc, wireshark gui, tshark version all pointing to 4.4.1. Installed via brew.
I have a main project branch I'm working on here to solve some cross platform development issues here: https://github.com/amitrahman1026/wsdf/tree/amit/upgrade-ws
I want to konw what is the reason they get detected correctly by wireshark upon start up, i.e wireshark is able to correctly detect the plugin dylibs.
However, when I try to select them from the filter menu on wireshark they don't appear. If i try to run it using tshark they don't parse correctly either.
This situation is quite similar to that described here with screenshots of the gui: https://github.com/ghpr-asia/wsdf/issues/15
To share my investigations so far, this is what i found in the wireshark's source in /Users/amit/Rust/wsdf/epan-sys/wireshark/wsutil/filesystem.c which hints at how plugins are handled by wireshark over here: https://gitlab.com/wireshark/wireshark/blob/b1d69aff3c0428c0589c89582f661eca2482a15a/wsutil/filesystem.c#L271
```c
- It also says that the "PlugIns" directory *
- Contains loadable bundles that extend the basic features of your
- application. You use this directory to include code modules that
- must be loaded into your applicationbs process space in order to
- be used. You would not use this directory to store standalone
- executables. *
- Our plugins are just raw .so/.dylib files; I don't know whether by
- "bundles" they mean application bundles (i.e., directory hierarchies)
- or just "bundles" in the Mach-O sense (which are an image type that
- can be loaded with dlopen() but not linked as libraries; our plugins
- are, I think, built as dylibs and can be loaded either way).
````
I inspected the types of shared objects that I placed in the plugin dir, where I had copied over the plugins appropriately.
- libudp.so that was generated by
wsdfusingcargo build --features bindgen --examplesto generate fresh ffi bindings for my OSX. - libfoo.so that was generated by
plugsharkthe build script here https://github.com/Gbps/plugshark/blob/main/simple-example/build-and-test.sh
``` ❯ pwd /Applications/Wireshark.app/Contents/PlugIns/wireshark/4-4/epan
❯ file libfoo.so libudp.so ethercat.so libfoo.so: Mach-O 64-bit dynamically linked shared library arm64 libudp.so: Mach-O 64-bit dynamically linked shared library arm64 ethercat.so: Mach-O 64-bit bundle arm64
❯ otool -L ethercat.so libudp.so libfoo.so ethercat.so: @rpath/libwireshark.18.dylib (compatibility version 18.0.0, current version 18.0.1) @rpath/libwsutil.16.dylib (compatibility version 16.0.0, current version 16.0.0) @rpath/libglib-2.0.0.dylib (compatibility version 7601.0.0, current version 7601.6.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3) libudp.so: /Users/amit/Rust/wsdf/target/debug/examples/libudp-8ffa7cef0dd88156.dylib (compatibility version 0.0.0, current version 0.0.0) /opt/homebrew/opt/wireshark/lib/libwireshark.18.dylib (compatibility version 18.0.0, current version 18.0.1) /opt/homebrew/opt/wireshark/lib/libwsutil.16.dylib (compatibility version 16.0.0, current version 16.0.0) /opt/homebrew/opt/glib/lib/libgmodule-2.0.0.dylib (compatibility version 8201.0.0, current version 8201.2.0) /opt/homebrew/opt/glib/lib/libgthread-2.0.0.dylib (compatibility version 8201.0.0, current version 8201.2.0) /opt/homebrew/opt/glib/lib/libglib-2.0.0.dylib (compatibility version 8201.0.0, current version 8201.2.0) /opt/homebrew/opt/gettext/lib/libintl.8.dylib (compatibility version 13.0.0, current version 13.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2) libfoo.so: /Users/amit/Rust/plugshark/simple-example/target/debug/deps/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0) /opt/homebrew/opt/wireshark/lib/libwireshark.18.dylib (compatibility version 18.0.0, current version 18.0.1) /opt/homebrew/opt/wireshark/lib/libwsutil.16.dylib (compatibility version 16.0.0, current version 16.0.0) /opt/homebrew/opt/glib/lib/libgmodule-2.0.0.dylib (compatibility version 8201.0.0, current version 8201.2.0) /opt/homebrew/opt/glib/lib/libgthread-2.0.0.dylib (compatibility version 8201.0.0, current version 8201.2.0) /opt/homebrew/opt/glib/lib/libglib-2.0.0.dylib (compatibility version 8201.0.0, current version 8201.2.0) /opt/homebrew/opt/gettext/lib/libintl.8.dylib (compatibility version 13.0.0, current version 13.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2)
❯ nm -gU ethercat.so libudp.so libfoo.so
ethercat.so: 000000000000218c T _plugin_describe 0000000000002194 T _plugin_register 0000000000007fa8 S _plugin_version 0000000000007fb0 S _plugin_want_major 0000000000007fb4 S _plugin_want_minor
libudp.so: 000000000000f620 T _plugin_register 0000000000051410 S _plugin_version 0000000000051418 S _plugin_want_major 000000000005141c S _plugin_want_minor
libfoo.so: 0000000000001884 T _plugin_register 0000000000064010 S _plugin_version 000000000004e4f8 S _plugin_want_major 000000000004e4fc S _plugin_want_minor 000000000000e530 T _proto_reg_handoff 000000000000de0c T _proto_register_foo ```
For context, libudp.so and libfoo.so are dynamic libraries generated as .dylibs via the cargo toolchain that have renamed to have .so extension and moved into the plugins folder. ethercat.so was originally there built by wireshark during brew installation.
From my understanding both the ethercat.so and {libudp.so, libfoo.so} are loading from/linking to (correct me if my terminology is wrong) the same version of libwireshark.
Now my questions is what could be causing it not to be able to be available in the filter. I have not been able to glean any further understanding of what happens to how to further debug this from wireshark source code.
There seems to be quite a few issue on wsdf thats also face similar issues after on windows or macOS in detecting their plugin dylibs. I am not able to ascertain further details about their set up but I would be happy to provide any further information I can to help.
Some more relevant tags: #Plugin #rust #FFI #OSX #Cross-platform
