Could this work for applications run by wine?

[yoshimo]

Imagine a Windows application using QT5 and Chromes framework and probably using boringssl and ms schannel inside that runs under Linux via wine.
Is there a backend that should cover this scenario?
It's not good when the user has to know which way the application handles its tls connections.

[dosubot[bot]]

Hi @yoshimo! I'm Dosu and I’m helping the ecapture team.

Unfortunately, eCapture won't work for Windows applications running under Wine. Here's why:

1. Wine is not a supported platform - eCapture uses uprobe-based eBPF hooking that targets native Linux applications with ELF binaries and dynamically linked shared libraries. Windows support is explicitly not planned for the near future.

2. MS SChannel is not supported - eCapture only supports OpenSSL, GnuTLS, NSPR/NSS, and GoTLS. There's no implementation for Windows TLS backends.

3. BoringSSL limitations - Even for native Linux apps, Chrome's BoringSSL is statically linked with stripped symbols, making it impossible for eCapture to locate and hook the necessary SSL functions.

The fundamental issue is that eCapture detects TLS libraries by reading version information from .rodata sections of native Linux shared objects and attaching uprobes to their exported symbols. Wine applications use Windows PE binaries that don't expose this metadata in a way eCapture can access.

For your use case, you might need to look at network-level interception (like mitmproxy) or application-specific debugging approaches instead.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}