friTap pulls TLS keys out of a live process and decrypts the traffic

The problem with a ciphertext capture

friTap is described as a tool for assisting researchers in analysing network traffic encapsulated in SSL/TLS, and it automates the key extraction step that makes such traffic readable. The traditional workflow has two halves that have to be correlated. You capture the traffic with tcpdump or a similar tool and you separately obtain the session keys, and then you feed both into a tool such as Wireshark to see the plaintext. The correlation is the annoying part, because the keys and the packets come from different places and have to be lined up by time. friTap collapses that into one run: it attaches to the process, hooks the TLS library so the keys are captured as they are used, and writes the decrypted payload to a pcap while the capture is still going. The project is from Fraunhofer FKIE, the licence is GPL-3.0, the home page is fkie-cad.github.io/friTap, and the release history shows v2.5.2 in October 2026 after v2.3.1 in September 2026, with the last push to the repository on 2026-09-29.

What the tool does at runtime

The feature list describes the runtime capabilities precisely enough to plan around. TLS key extraction happens in real time and is written with the -k key.log option. Decryption of the TLS payload as a pcap in real time uses the -p plaintext.pcap option, and the documentation is careful that coverage varies by platform and library, pointing to a support table. Interactive TUI mode has a guided setup wizard, and running the tool with no arguments launches it. Plaintext hook output can be stored in its own .tap capture format and replayed with fritap -r saved_capture.tap, which is what makes the output useful in a scripted pipeline. The library scanning option, --library-scan, discovers renamed or statically linked libraries, and the heap memory scanning option, -ms or --memory-scan, recovers TLS secrets without hooking the TLS library at all. There is also Telegram and MTProto support, with -ms mtproto and -ms telegram, for cloud and end to end secret chat key recovery from heap memory. Most of the common SSL libraries are supported, including OpenSSL, BoringSSL, NSS and GnuTLS.

Attaching to a process, and to a mobile app

On Linux, Windows and macOS you attach to a process by entering its name or its PID, and the tool takes a capture path and the process as arguments.

$ sudo fritap --pcap mycapture.pcap thunderbird

For mobile applications you add the -m parameter to indicate that you are attaching to or spawning an Android or iOS app, with the package name as the target.

$ fritap -m -k keys.log com.example.app

The documentation adds one thing that is easy to miss, which is to ensure that the frida-server is running on the Android or iOS device. That is a separate piece of software on the device, it needs to match the Frida client, and it is the usual reason a mobile run fails while a desktop run works. The tool can also be used as a Python library inside your own project, with the SSL_Logger class imported from the friTap package, and INTEGRATION.md is the guide for that route. A custom Frida script can be passed with the -c parameter, and that script is invoked just before friTap applies its own hooks, which is how you extend the tool without forking it.

The TUI wizard and its capture modes

Running fritap with no arguments opens an interactive terminal user interface that walks through device selection, target process and capture mode.

$ fritap

The key map is published in the documentation and is worth knowing before you start. The d key selects the device, a attaches to a process and s spawns an application, Enter starts and stops the capture, v toggles verbose, p selects the protocol and q quits, with e toggling experimental mode. The capture mode numbers are the other half: 1 is full capture with keys and pcap, 2 is key extraction only, 3 is plaintext pcap, and 4 and 5 are live Wireshark, one piping and one auto-decrypting. The two live Wireshark options require Unix style FIFOs and are currently Linux and macOS only, so they are not supported on Windows. The TUI also supports device selection for local, USB and remote devices, and it can automatically install and start frida-server on connected devices, which removes one manual step from a mobile workflow.

Hooking a library that has no symbols

The most technically interesting part of the project is what happens when the usual approach fails. In certain scenarios the library you want to hook offers no symbols or is statically linked with other libraries, which makes it challenging to directly hook functions, and the documentation names two real cases, Cronet's libcronet.so and Flutter's libflutter.so, which are often statically linked with BoringSSL. Despite the absence of symbols, friTap can still be used for parsing and hooking. The approach is byte patterns. You provide friTap with a JSON file containing byte patterns for hooking specific functions, based on architecture and platform, using the --patterns option. The file format is per platform and architecture, and the repository ships an offsets_example.json and a pattern.json, plus a quic_patterns.json, and the agent source is written in TypeScript and compiled with frida-compile, with the main entry at agent/fritap_agent.ts. The pattern categories are Dump-Keys, Install-Key-Log-Callback, KeyLogCallback-Function, SSL_Read and SSL_Write, and each category has a primary and a fallback byte pattern, so a hook survives a build that moves the function.

The Python package layout, and what it pulls in

The repository is both a Python package and a Frida agent, and the two halves are visible in the tree. The agent/ directory holds the TypeScript sources for the various agent flavours, including an agent_ebpf/ directory, an agent_gdb/, an agent_lldb/ and an agent_debugger/, and the build scripts in package.json compile the agent sources with frida-compile into the friTap/ package directory, with a separate build target for the memory scan agent and a dev/ directory holding a compile_agent.sh script. The Python side lives in friTap/ with friTap.py at the root. The runtime requirements are listed in requirements.txt and they are substantial: frida and frida-tools, scapy for the packet handling, rich and textual for the TUI, pydantic, h11, hpack and pylsqpack for the HTTP layer, zstandard and brotli for compression, cryptography, and the tlsLibHunter and AppTap packages. The setup.py notes that the runtime crypto backend ships in the base install, with an optional TgCrypto-pyrofork AES-IGE accelerator wherever a wheel exists, and that requirements-minimal.txt exists for a lean install that skips the crypto backend.

Where friTap is the wrong tool

There are clear boundaries and one of them is legal rather than technical. friTap reads another process's TLS keys, so using it against an application, a device or a network you are not authorised to test is a criminal act in most jurisdictions, and the project says plainly that it is intended for malware analysis or investigating privacy issues in applications. The technical boundaries are different. If you only need a packet capture, tcpdump and Wireshark do that without touching the target, and adding Frida to the mix means root access on the device and a process that can be destabilised by a hook. The second boundary is library coverage, and it is the one that bites in practice, because the decryption step is the part that fails quietly. A capture can succeed and produce nothing readable if the target's TLS implementation is not on the supported list or if it was statically linked in a configuration the patterns do not cover, and the support table in the documentation is the thing to check first. The third is the mobile story, where frida-server has to be running, matched in version, and started on the device, and where the app may detect it. The fourth is that this is a research tool that expects a research workstation with root, and it is not something to point at a production server.

Editorial conclusion

Adopt friTap if you are analysing an application you own or are authorised to audit and you need the plaintext rather than a ciphertext capture, because key extraction and decryption in one pass removes the usual step of correlating a separate key log with a capture. Do not adopt it if you only need a packet capture, since tcpdump and Wireshark already do that without touching the target process. Verify two things before you plan the work: that the SSL/TLS implementation in your target is on the supported list, because coverage varies by platform and library and the decryption step is the part that fails quietly, and that your Frida version and the frida-server on the device match the supported range. The practical first step is to install the tool with pip3 install fritap, run it with no arguments to get the guided wizard, and confirm it can attach to a process you control before you point it at anything complicated.

Frequently asked questions

Official sources

1. fkie-cad/friTap on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases