tl;dr
eBPF (extended Berkeley Packet Filter) is slowly taking over as a programmatic way for (generally privileged) users to invoke Linux kernel APIs and performantly execute semi-arbitrary code without having to load it from a custom kernel module. eBPF is a general means to load memory safe restricted code that reduces the risk of crashes, deadlocks, and infinite loops of inherent to the kernel module alternative.
In this post, we describe how to effectively use eBPF to trace Linux kernel functions. We also discuss how we implemented our eBPF-based tracing tool that can sniff Unix domain sockets across an entire Linux host (this “impossible” task was what got us started with eBPF). You can install it with sudo -H pip install unixdump (or from our repo), but it requires BCC to be installed separately. But, if you just want to see some of what it can do, click here.
If you’re looking to get into building custom eBPF-based Linux kernel tracing tools, we recommend starting with BCC, busting out its reference guide, and pinning a tab to the Linux kernel codebase.
Background
Unix domain sockets1 are a core OS-provided IPC (inter-process communication) mechanism that enable processes on the same host to communicate through send(2)/sendto(2)– and recv(2)/recvfrom(2)-able file descriptors similarly to network sockets. Unix domain sockets use a file path (or in the case of Linux’s abstract namespace, a key string) as the bind(2)/connect(2) “address;” additionally, “unnamed” Unix domain sockets may be created in connected pairs through the socketpair(2) syscall. Traditionally, Unix domain sockets are often used when applications or services require bidirectional communication between related processes or communication between unrelated ones that may enforce OS-backed permission checks (though the checks differ between Unixes2). Depending on the internal implementation, Unix domain sockets are often significantly more performant than loopback-networking as they do not go through the networking stack. One downside of this is that Unix domain sockets are extremely difficult to inspect as there is no simple interface or API for intercepting Unix domain socket traffic, such as the pcap(3) APIs for network traffic. Instead, when needing to observe Unix domain socket traffic, one often resorts to interposing a forwarding daemon with a middle Unix domain socket that the connect(2)/sendto(2)-ing peer will actually communicate with. In the case where file descriptors are being passed or peer credentials are being validated, and it may be overly complicated to run such a daemon with the right process information, function hooking (typically LD_PRELOAD-alikes) may be used to interdict libc stubs used to invoke the communication syscalls. Both methods have drawbacks and additionally require more than a cursory understanding of how an application is already using Unix domain sockets in order to intercept them. Additionally, neither method scales across an entire host and may only be used to individually intercept Unix domain socket traffic for single applications and services. Intercepting all Unix domain socket traffic across a host will require dumping the data directly from the kernel; we can do this by tracing the kernel.
Kernel Tracing and Instrumentation
Generally, kernel tracing utilities enable one to obtain very basic information about the execution within the OS kernel. Most implementations provide the ability to dump metadata about executing functions, including their arguments and return values. Often, this data is very limiting as the relevant information is embedded within structs and arrays for which only the pointer address is returned. Fewer OS kernels directly provide instrumentation APIs that enable deeper information to be gleaned from executing functions and kernel memory. The gold standard for such functionality is DTrace. DTrace was originally developed for Solaris, and has since been ported to FreeBSD and macosx (where, unfortunately, it has been purposefully weakened to align with other DRM-related changes and will deny attempts to trace binaries from core system directories). DTrace has also been ported to Linux, twice; once as a /proc/kallsyms-based kernel module that implements its own function hooking, and, more recently, by Oracle, who relicensed it under the GPL (for kernel code). Unfortunately, the former is essentially unmaintained and fails on current Linux distributions, and the latter is effectively locked to Oracle Linux at the moment and it is unclear if it will be accepted into upstream.
Due to the long period without DTrace on Linux and the eventual realization of the need to have useful debugging features within the kernel, Linux has played fast and loose with a number of tracing frameworks that mostly constitute dead ends. Chief among the failures is SystemTap, which has a painful installation process requiring installation of kernel debug symbols and uses a frustrating NIH clone of the DTrace scripting syntax to dynamically generate kernel modules. Needless to say, one is probably better off writing their own function hooking kernel modules. Sysdig, on the other hand, is a useful tool (but doing anything fancy might involve Lua scripting…). Unfortunately, is not capable of drilling down into arbitrary kernel structures in memory as it is based entirely on Linux’s built-in tracepoint definitions (primarily those for syscalls and process scheduling events), which provide only specific pre-defined values that the kernel’s developers felt would be useful for debugging and tracing kernel functionality.
Linux’s Lego Problem
Linux’s in-kernel tracing features are very similar to other facets of modern Linux, specifically containers. Linux slowly gained a number of “namespacing” features that were eventually composed to form the “concept” of “containers,” an ape of purpose-built sandboxing technology such as FreeBSD’s jails and Solaris’ zones. Containers have only recently started to see legitimate security hardening materialize for normal users within the past few years, most notably with the introduction of user namespaces, a feature feared by Linux distros, but which wipes out a number of container escapes by isolating privileges to the container’s namespaces. Jessie Frazelle sums up the “concept” distinction nicely in her infamous blog post comparing them. We will only add that if you decide to make an ocean out of the Death Star set, it will cost $500 and your ocean will be a murky gray.
The Linux kernel has several different inter-related features that support dynamic instrumentation and tracing (for a more thorough introduction, see Julia Evans’ overview on Linux’s tracing systems):
kprobes: Kernel API via
register_kprobe(struct kprobe*)that can register callback functions to handle a breakpoint injected at an arbitrary memory address (typically the start of a function). The handlers are provided astruct pt_regs*containing the architecture-specific register values.ftrace: A function tracing API provided by the Linux kernel built on lower-level APIs such as kprobes and tracepoints, that provides a filesystem-based userland API (
debugfs) to configure and enable various tracing and profiling operations.perf (aka perf_events): Kernel API for hardware performance monitoring counters (e.g. number of instructions executed), timed sampling (e.g. find where in the callstack time is spent), and userspace mapped ring buffers via
perf_event_open(2)/mmap(2)syscalls.tracepoints: Kernel API with tracepoints declared through the
TRACE_EVENTmacro, inserted via calls to the tracepoint “function,” and callbacks registered throughtracepoint_probe_register(struct tracepoint*,void*,void*). TheTRACE_EVENTmacro creates metadata useful for perf and ftrace to instrument by tracepoint name.
Some of these are implemented in terms of each other, and several of their subsystems interact with or support each other. But, up until recently, if you wanted to directly interact with any of these things in a meaningful way, you needed to write a bunch of GNU-flavored C in a kernel module and implement your own scheme for communicating data back to userspace (assuming you want something more performant than printk). This is essentially how every single tracing “framework” is implemented, and one of the common things they seem to share is that they all tend to set up their own ring buffer from scratch that is mmap(2)’d using a file descriptor obtained by open(2)-ing a special path registered by the module (implementations vary heavily, from use of cdev_add to mounted in-memory filesystems).
eBPF: Lego Grout
eBPF (extended Berkeley Packet Filter) is an in-kernel JIT-ing virtual machine that adds extra computational resources (more registers, direct ISA mapping to major CPU architectures, and fast C interop with internal Linux kernel functionality)3 to the classic BPF virtual machine and bytecode instruction set; it is referred to as bpf in the Linux source, APIs, syscalls, etc. eBPF is slowly taking over as a “programmatic” way for users, often privileged ones, to invoke Linux kernel APIs and execute “performant” code in kernel space (which limits context switches) without necessitating the development and loading of a custom kernel module in an unsafe or dangerous language. eBPF is not specifically a tracing or instrumentation feature, but a general means to load memory safe restricted code that reduces the risk of crashes, deadlocks, and infinite loops of inherent to the kernel module alternative. Given that eBPF itself has already introduced vulnerabilities (Though, being honest, what revolutionary new feature hasn’t had bugs?), it is exacerbating the failings of the Linux capability “model” and raising concerns about the balance between functionality and security. But if the intention behind eBPF is to keep mortals from writing buggy kernel modules, it may well succeed and improve the security status quo in doing so.
eBPF is slowly but surely becoming a framework within the kernel with an ever-increasing menagerie of features, programming capabilities, kernel-backed (and userland-mapped) data structures, helper functions (for which an in-eBPF implementation would otherwise violate the safety restrictions), and pluggable APIs. These include multiple forms of packet and socket filtering and processing, an interesting API for adding encapsulation to packets based on route tables, shenanigans to hook bind(2) to “fix” broken apps that run in containers, and multiple APIs to attach them to all manner of kernel-based tracing and instrumentation mechanisms. The last of these is most relevant to our purposes, but we will nonetheless remind folks to stay safe and make sure to properly account for variable-length headers when processing packets with eBPF.
BCC: C to eBPF By Way of the Long Way Round
BCC (BPF Compiler Collection) is a toolkit for having userland code (generally Python) interact with kernel space eBPF code, and includes an LLVM-based cross-compilation toolchain that compiles C code into eBPF bytecode. At a very high level, this toolchain is based on using Clang’s RecursiveASTVisitor AST traversal library to modify the C code into a “suitable” format and then use LLVM’s eBPF backend to emit the bytecode. These modifications exist primarily to replace external memory accesses with equivalent eBPF memory accessing helper functions and expand other simplified C coding constructs such as BCC library functions and “magic” semantics introduced by BCC that are used to denote the eBPF attach target (e.g. kprobe__funcname to attach the eBPF-compiled function as a kprobe hook on funcname). For a slightly deeper dive into how BCC C code works and how eBPF kprobes are registered, see our talk given recently at the 35C3 conference.
BCC and eBPF Bytecode Validator Hell
To make eBPF “safe,” the Linux kernel validates all eBPF code before loading it. For example, eBPF code is not allowed to “loop” (to prevent infinite loops), so any attempt to run code at an address/offset before the currently running eBPF instruction will be deemed illegal (This restriction has been weakened slightly in newer versions of Linux to reduce code bloat, but is still enforced by default.). Additionally, the eBPF validator may detect loops when there are none in the source code; this can happen due to compiler optimizations or because of faulty identification of normal function calling operations as being loop-like. As such, BCC C often uses unrolled loops and inlined functions. The eBPF validator additionally has a number of call-site validations and register taint tracking logic that attempt to ensure that helper functions, such as those used to manipulate memory-mapped tables and access kernel memory, are only passed “safe” argument values. This “logic” is problematic as it is often not thorough enough to properly determine value bounds. This problem is further complicated by the fact that BCC compiles code with -O2; most naïve attempts to make such bounds “more obvious” are likely to be optimized out by Clang. Additionally, updating BCC (and possibly the Linux kernel) may potentially result in a slightly different bytecode output that trip the validator. However, this is generally not the case for very simple code, such as that of the tools and examples code within the BCC repo itself. We have also observed errors when using certain Linux/BCC versions where the use of a bool function parameter was not tolerated in certain variants of our code (e.g. different filtering comparisons being applied) and integer types were not tolerated in the others; we originally had to solve this by using #ifdef magic to control the parameter’s type depending on the variant of the code until a BCC update unbroke it. These issues are so pervasive that the BCC developers themselves appear to believe that certain tolerable code constructs, such as variable-length byte copies, are not possible in eBPF because the idiomatic code C is not accepted by the eBPF validator.
While these issues present challenges when attempting to develop portable BCC/eBPF-based tooling, it is useful to be able to disable these inane validations when simply attempting to quickly trace a kernel function and extract some interesting data. Unfortunately, the current validator implementation suffers from high coupling-low cohesion as the validation routine itself pre-processes the bytecode and configures the internal kernel data structures responsible for running it. As a result, the validation routine cannot be bypassed directly with a NOP or by stomping over its implementation with a return 0. Instead, one has to individually clip the strings of the eBPF validator’s golden fiddle by performing a number of nigh-surgical function hooks that will both bypass lower-level state validation checks and override registers with safe bound values. We have implemented a set of such hooks that have bypassed the more pernicious and maddening errors that we have experienced while writing our Unix domain socket sniffer tool. While we do not recommend using it in production as it can definitely lead to unstable and, more importantly, unsafe eBPF code, our yolo-ebpf kernel module can help in a pinch when attempting to reverse engineer applications on the fly. And if you still happen to hit an incorrect eBPF validator error while using it, please send us an issue. It is disappointing that such tomfoolery is needed in the first place, but eBPF and BCC are both relatively new and these things take time.
unixdump: An eBPF-based Unix Domain Socket Sniffer
unixdump is a full-featured utility for passively capturing Unix domain socket traffic from Linux hosts built on top of eBPF and BCC. It can capture all traffic across a host, including file descriptor transfers and Unix credential passes. unixdump supports fine-grained filtering based on Unix domain socket paths (including abstract namespace keys) and PIDs, and can perform both inclusive and exclusive filtering of PIDs. unixdump additionally supports outputting to readable log files amenable to extracting binary content (We are currently looking into outputting to the pcapng format, which can support ancillary data, but performantly and accurately timestamping events may pose a challenge).
Design and Implementation
As with other BCC-based tools, our userland event handling code is written in Python and our kernel space kprobe hook that generates events is written in C. Essentially, the C code is what performs the important operations; in our case, this is the retrieval and filtering of metadata and content from sockets and other kernel structures. This code then marshals the event data into a struct that is unpacked on the Python side. The Python code then processes the event stream into a more user-friendly data output.
This flow is implemented through the use of two ring buffers, one the perf_event ring buffer, and the other a custom ring buffer built on top of an eBPF map. Events are pushed to userspace through the perf_event ring buffer using perf_submit calls in the C code. The Python userspace code constantly poll(2)s file descriptors associated with these ring buffers to detect event submissions. The Python code then attempts to read the rest of the data from the asynchronously updated custom ring buffer mapped into userspace. Following this, the Python code process the data and clears the custom ring buffer entry.
In unixdump, we are extracting the data sent over Unix domain sockets at one of the lowest possible levels, from the internal msghdr structs holding them. When the send syscall is invoked on a Unix domain socket, a msghdr parameter, msg, gets passed along. The data in the msghdr struct is contained within another structure, iov_iter, that is embedded into the msghdr as its msg_iter field. iov_iters can wrap several kernel buffer structures, but in our case, it uses the const struct iovec* iov union variant, which is a simple structure that contains a buffer base pointer, iov_base, and a buffer length, iov_len, that together refer to our Unix domain socket message content.
We extract this data using the bpf_probe_read() helper function, which acts as a “safe” memcpy enabling eBPF programs to read arbitrary kernel memory into their own memory space. An interesting quirk of how BCC works is that function calls to bpf_* functions, which are part of the kernel’s eBPF API, and other BCC-specific helper functions/methods (yes, “methods”) are rewritten using an LLVM-based code generation pass. This enables the helper functions to be translated into the appropriate bpf_call instructions and is additionally used to translate all kernel memory dereferences into bpf_probe_read() calls.
Unix domain sockets also allow processes to pass file descriptors to one another (SCM_RIGHTS), and authenticate their identity (or act on behalf of another) by passing user credentials (SCM_CREDENTIALS) through the kernel. This “ancillary data” takes the form of several cmsghdr structures and CMSG_DATA payloads lined up within a single byte buffer blob. This blob is pointed to by the void* msg_control field of the msghdr struct and the size_t msg_controllen field specifies the total size. To differentiate and identify the raw contents of the CMSG_DATA payloads, the cmsghdr struct stores metadata about the type and size of the data. For example, if the int cmsg_type field is SCM_RIGHTS, the particular CMSG is being used to pass file descriptors. An interesting quirk of the CSMG system in the kernel is that separate CMSG objects of the same type will be combined into one CMSG observed by the receiver. Like most ad-hoc data structures in the Linux kernel codebase, CMSG blobs are not simple to parse given eBPF’s constraints. In particular, these blobs are typically iterated through by using multiple layers of pointer shifting macros that embed a for-loop construct to iterate the initially unknown number of CMSG objects; it is worth keeping in mind that the msghdr.msg_controllen field refers to the byte length of the whole CMSG blob, and is used to ensure that CMSG objects are not iterated or processed past the end of the buffer allocated to them. To get around the eBPF limitations, we use CLI flag-based tunables to guide (hacky string concat) code generation of C code that statically iterates these blobs, if present, and copies the metadata and typing information into our ring buffer; we feel this was still less painful to implement than it would have been to copy the entire blob to userspace and process it in Python.
BCC, providing a userland interface on top of a kernel-only one, enables BCC C code to specify I/O data structures that map to the ones in unixdump uses a BPF_PERCPU_ARRAY() to store (potentially large) message content as it enables easier iterating of ring buffer slots. For simpler one-off event notifications, BCC C supports setting and registering a perf_event output ring buffer-based output struct through BPF_PERF_OUTPUT(); the perf_submit() helper function may then be called on the output object declared by the macro. This function call is actually translated into a bpf_perf_event_output() helper function call through BCC’s code generation.
Dividing our message content and event metadata across these two storage mechanisms enables us to better tune memory usage; and detect, mitigate, and report when unixdump is bottlenecking against the system. One major difference between these two I/O mechanisms is that BPF_PERF_OUTPUT()-registered data structures will be automatically parsed/deserialized by BCC, whereas BCC-registered tables/arrays/maps will be provided to registered event handlers as raw byte buffers, necessitating the use of custom Python ctypes parsing logic. However, One major pain point to be aware of with this behavior of BCC is that in the former case, char[] fields will be parsed as NUL-terminated C strings, and all data after a NULL byte will be lost; it may not be recovered by using ctypes.string_at. The solution is to use uint8_t[] for non-C string data, as it will result in BCC reading all of the data.
When writing unixdump, we quickly learned that display server traffic (e.g. X11) for terminal applications goes over Unix domain sockets. A naive implementation would quickly result in a feedback loop that would suck up memory and CPU resources. Since we wanted to avoid locking up the system, and since we also wanted to capture tunable amounts of data larger than the eBPF stack size (since eBPF cannot perform dynamic allocations), we went with a CLI-configurable ring buffer for content storage. The current implementation will simply drop events (but notify userland of the drop with additional metadata) if the ring buffer slot is still in use by the time it is needed again. We also do not directly perf_submit the large slots of the ring buffer as this resulted in a large number of kernel-dropped perf events. Instead we perf_submit smaller event metadata, which includes information like PIDs, socket paths, and the index of the ring buffer slot synced to userspace using the bpf_map_* APIs. This results a slight “race condition” in that the ring buffer slot may not yet be accessible to userspace by the time we attempt to access it. However, this delay is not subject to the ABA problem or any similar use-after-free-like issues as the userland pages will have always been cleared by the userspace code prior to being updated by the kernel. We use a few fallback mechanisms to poll at it depending on whether or not event order preservation is necessary, but will give up after a few tries as we have observed complete losses of the data in some circumstances where the slot never updates. It is currently unclear if this is due to a flaw in BCC or the Linux kernel itself.
For better throughput, we perform various checks to determine whether it is worth it to continue processing. For example, we will bail out early if various validation checks do not pass (e.g. if certain metadata is missing or unexpected). On top of this, we provide a number of in-kernel filters to reduce and refine the amount of processing done in the kernel. Users can filter on specific Unix domain socket paths (or match path prefixes) and PIDs. It is also possible to exclude certain noisy PIDs altogether (e.g. the GUI terminal process rendering the output of its own Unix socket communication with the display server, or the display server itself). Using the filters will reduce the amount of data copied to the fixed-size perf_events ring buffer and therefore help to prevent it from overfilling and dropping (“missing” in the Linux parlance) events that cannot fit. We also support configuring the size of this buffer should stable throughput still be too much for the default size.
Case Study: Sniffing Frida C2 Traffic
Frida is a popular “cross-platform dynamic instrumentation toolkit” that injects a JavaScript interpreter into a target process and uses it to run a semi-DSL of JavaScript function hooking code. The impetus for unixdump was part of a greater desire to answer a seemingly simple question: “How does Frida work?” More specifically, we were looking to find out how Frida’s agent communication protocol works. At a high-level, Frida works by attaching to a target process using platform-specific debugging APIs (i.e. ptrace(2) on Linux, task_for_pid()/mach_vm_*() on macosx, and OpenProcess()/VirtualAllocEx()/WriteProcessMemory()/CreateRemoteThread() on Windows), and then uses them to inject an “agent” that runs within the target. This agent is what runs the instrumenting JavaScript code and performs the lower-level operations invoked by it (e.g. function hooking, memory reads/writes, etc.). While Frida does support non-interactively loading a single JavaScript file, its primary mode of operation involves the use of a “client” process that interacts with the agent running within the target. In addition to the protocol used for direct attachment, Frida also supports having the client connect to a frida-server instance that makes direct attachments to targets. While we are interested in the goings-on of the direct attachment/connection case, it is worth noting that a frida-server can be loaded into a given process through frida-gadget, and that the frida-server and client libraries support several protocols to enable remote attachment to hosts over TCP and mobile devices using a TCP-forwarding mechanism to connect to a a frida-server on a USB-attached device (e.g. ADB’s TCP forwarding for Android, and usbmuxd TCP forwarding) for iOS).
Through strace(1)-ing the client, it became clear early on that the direct attachment communication protocol had to be transported over Unix domain sockets with dynamically-generated paths. The problem was that multiple such Unix domain sockets are created, and it wasn’t clear which ones were being used. Additionally, because the Frida client is still ptrace(2)-ing the target, we cannot simply strace(1) it, as strace(1) uses ptrace(2) and a process can only be ptrace(2)-d by one tracer at a time. While we could have tried to hack up a sniffer by instrumenting the Frida client itself to hook its Unix domain socket I/O, this was not an ideal solution for a number of reasons, and we instead tried to solve the Unix domain socket traffic sniffing problem once and for all (on Linux at least). After we got the MVP version of the eBPF hooks running, it quickly became obvious that Frida uses DBus to serialize custom API calls over Unix domain sockets. In fact, outside of specific protocols to initialize direct connections between Frida clients, servers, and targets, pretty much all of Frida’s communications use the DBus protocol.
Frida Agent Script Communication Protocol
Using the code in the first example defined in the Frida documentation, we demonstrate unixdump’s ability to intercept Unix domain socket traffic. Knowing (from strace(1)) that Frida’s Unix domain socket paths begin with /tmp/frida, we can instruct unixdump to filter for messages starting with that path name:
sudo unixdump -s '/tmp/frida' -b
We then proceed to start our target binary, hello, and our Frida hook script, hook.py, passing the latter the PID from of the hello process:
./hello ./hook.py $FUNCTION_VALUE
- When Frida starts, it begins authenticating via DBus and the hooked process begins to send Unix credentials to identifying itself (in this case,
hellowas run as root):
Output
==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 1 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ancillary data sent (attempted): 1 CMSG observed SCM_CREDENTIALS: pid=26525 uid=0(root) gid=0(root) ---- 00000000: 00 . ==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 6 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ---- 00000000: 41 55 54 48 0D 0A AUTH.. ==== STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 46 command[26527]: 'python ./hook.py 0x55bd9092f155' command[26525]: './hello' ---- 00000000: 52 45 4A 45 43 54 45 44 20 45 58 54 45 52 4E 41 REJECTED EXTERNA 00000010: 4C 20 41 4E 4F 4E 59 4D 4F 55 53 20 44 42 55 53 L ANONYMOUS DBUS 00000020: 5F 43 4F 4F 4B 49 45 5F 53 48 41 31 0D 0A _COOKIE_SHA1.. ==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 18 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ---- 00000000: 41 55 54 48 20 45 58 54 45 52 4E 41 4C 20 33 30 AUTH EXTERNAL 30 00000010: 0D 0A .. ==== STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 37 command[26527]: 'python ./hook.py 0x55bd9092f155' command[26525]: './hello' ---- 00000000: 4F 4B 20 36 37 36 39 37 34 36 38 37 35 36 32 32 OK 6769746875622 00000010: 65 36 33 36 66 36 64 32 66 36 36 37 32 36 39 36 e636f6d2f6672696 00000020: 34 36 31 0D 0A 461.. ==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 19 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ---- 00000000: 4E 45 47 4F 54 49 41 54 45 5F 55 4E 49 58 5F 46 NEGOTIATE_UNIX_F 00000010: 44 0D 0A D.. ==== STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 15 command[26527]: 'python ./hook.py 0x55bd9092f155' command[26525]: './hello' ---- 00000000: 41 47 52 45 45 5F 55 4E 49 58 5F 46 44 0D 0A AGREE_UNIX_FD.. ==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 7 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ---- 00000000: 42 45 47 49 4E 0D 0A BEGIN..
- Afterwords, Frida performs a
GetAllrequest of the DBus properties:
Output
====
STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 156
command[26527]: 'python ./hook.py 0x55bd9092f155'
command[26525]: './hello'
----
00000000: 6C 01 00 01 24 00 00 00 01 00 00 00 68 00 00 00 l...$.......h...
00000010: 08 01 67 00 01 73 00 00 01 01 6F 00 1E 00 00 00 ..g..s....o.....
00000020: 2F 72 65 2F 66 72 69 64 61 2F 41 67 65 6E 74 53 /re/frida/AgentS
00000030: 65 73 73 69 6F 6E 50 72 6F 76 69 64 65 72 00 00 essionProvider..
00000040: 03 01 73 00 06 00 00 00 47 65 74 41 6C 6C 00 00 ..s.....GetAll..
00000050: 02 01 73 00 1F 00 00 00 6F 72 67 2E 66 72 65 65 ..s.....org.free
00000060: 64 65 73 6B 74 6F 70 2E 44 42 75 73 2E 50 72 6F desktop.DBus.Pro
00000070: 70 65 72 74 69 65 73 00 1F 00 00 00 72 65 2E 66 perties.....re.f
00000080: 72 69 64 61 2E 41 67 65 6E 74 53 65 73 73 69 6F rida.AgentSessio
00000090: 6E 50 72 6F 76 69 64 65 72 31 32 00 nProvider12.
====
STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 151
command[26525]: './hello'
command[26527]: 'python ./hook.py 0x55bd9092f155'
----
00000000: 6C 01 00 01 1F 00 00 00 01 00 00 00 68 00 00 00 l...........h...
00000010: 08 01 67 00 01 73 00 00 01 01 6F 00 19 00 00 00 ..g..s....o.....
00000020: 2F 72 65 2F 66 72 69 64 61 2F 41 67 65 6E 74 43 /re/frida/AgentC
00000030: 6F 6E 74 72 6F 6C 6C 65 72 00 00 00 00 00 00 00 ontroller.......
00000040: 03 01 73 00 06 00 00 00 47 65 74 41 6C 6C 00 00 ..s.....GetAll..
00000050: 02 01 73 00 1F 00 00 00 6F 72 67 2E 66 72 65 65 ..s.....org.free
00000060: 64 65 73 6B 74 6F 70 2E 44 42 75 73 2E 50 72 6F desktop.DBus.Pro
00000070: 70 65 72 74 69 65 73 00 1A 00 00 00 72 65 2E 66 perties.....re.f
00000080: 72 69 64 61 2E 41 67 65 6E 74 43 6F 6E 74 72 6F rida.AgentContro
00000090: 6C 6C 65 72 31 32 00 ller12.
====
STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 48
command[26525]: './hello'
command[26527]: 'python ./hook.py 0x55bd9092f155'
----
00000000: 6C 02 01 01 08 00 00 00 02 00 00 00 18 00 00 00 l...............
00000010: 08 01 67 00 05 61 7B 73 76 7D 00 00 00 00 00 00 ..g..a{sv}......
00000020: 05 01 75 00 01 00 00 00 00 00 00 00 00 00 00 00 ..u.............
====
STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 48
command[26527]: 'python ./hook.py 0x55bd9092f155'
command[26525]: './hello'
----
00000000: 6C 02 01 01 08 00 00 00 02 00 00 00 18 00 00 00 l...............
00000010: 08 01 67 00 05 61 7B 73 76 7D 00 00 00 00 00 00 ..g..a{sv}......
00000020: 05 01 75 00 01 00 00 00 00 00 00 00 00 00 00 00 ..u.............
- Frida then instructs the script to open and waits for a confirmation that the open succeeded:
Output
====
STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 132
command[26527]: 'python ./hook.py 0x55bd9092f155'
command[26525]: './hello'
----
00000000: 6C 01 00 01 04 00 00 00 03 00 00 00 70 00 00 00 l...........p...
00000010: 08 01 67 00 03 28 75 29 00 00 00 00 00 00 00 00 ..g..(u)........
00000020: 01 01 6F 00 1E 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 50 72 a/AgentSessionPr
00000040: 6F 76 69 64 65 72 00 00 03 01 73 00 04 00 00 00 ovider....s.....
00000050: 4F 70 65 6E 00 00 00 00 02 01 73 00 1F 00 00 00 Open......s.....
00000060: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe
00000070: 73 73 69 6F 6E 50 72 6F 76 69 64 65 72 31 32 00 ssionProvider12.
00000080: 01 00 00 00 ....
====
STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 132
command[26525]: './hello'
command[26527]: 'python ./hook.py 0x55bd9092f155'
----
00000000: 6C 04 01 01 04 00 00 00 03 00 00 00 70 00 00 00 l...........p...
00000010: 08 01 67 00 03 28 75 29 00 00 00 00 00 00 00 00 ..g..(u)........
00000020: 01 01 6F 00 1E 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 50 72 a/AgentSessionPr
00000040: 6F 76 69 64 65 72 00 00 03 01 73 00 06 00 00 00 ovider....s.....
00000050: 4F 70 65 6E 65 64 00 00 02 01 73 00 1F 00 00 00 Opened....s.....
00000060: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe
00000070: 73 73 69 6F 6E 50 72 6F 76 69 64 65 72 31 32 00 ssionProvider12.
00000080: 01 00 00 00 ....
====
STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 32
command[26525]: './hello'
command[26527]: 'python ./hook.py 0x55bd9092f155'
----
00000000: 6C 02 01 01 00 00 00 00 04 00 00 00 10 00 00 00 l...............
00000010: 08 01 67 00 00 00 00 00 05 01 75 00 03 00 00 00 ..g.......u.....
====
STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 148
command[26527]: 'python ./hook.py 0x55bd9092f155'
command[26525]: './hello'
----
00000000: 6C 01 00 01 1C 00 00 00 04 00 00 00 68 00 00 00 l...........h...
00000010: 08 01 67 00 01 73 00 00 01 01 6F 00 18 00 00 00 ..g..s....o.....
00000020: 2F 72 65 2F 66 72 69 64 61 2F 41 67 65 6E 74 53 /re/frida/AgentS
00000030: 65 73 73 69 6F 6E 2F 31 00 00 00 00 00 00 00 00 ession/1........
00000040: 03 01 73 00 06 00 00 00 47 65 74 41 6C 6C 00 00 ..s.....GetAll..
00000050: 02 01 73 00 1F 00 00 00 6F 72 67 2E 66 72 65 65 ..s.....org.free
00000060: 64 65 73 6B 74 6F 70 2E 44 42 75 73 2E 50 72 6F desktop.DBus.Pro
00000070: 70 65 72 74 69 65 73 00 17 00 00 00 72 65 2E 66 perties.....re.f
00000080: 72 69 64 61 2E 41 67 65 6E 74 53 65 73 73 69 6F rida.AgentSessio
00000090: 6E 31 32 00 n12.
====
STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 48
command[26525]: './hello'
command[26527]: 'python ./hook.py 0x55bd9092f155'
----
00000000: 6C 02 01 01 08 00 00 00 05 00 00 00 18 00 00 00 l...............
00000010: 08 01 67 00 05 61 7B 73 76 7D 00 00 00 00 00 00 ..g..a{sv}......
00000020: 05 01 75 00 04 00 00 00 00 00 00 00 00 00 00 00 ..u.............
- Following this, Frida creates the JavaScript to be injected:
Output
====
STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 251
command[26527]: 'python ./hook.py 0x55bd9092f155'
command[26525]: './hello'
----
00000000: 6C 01 00 01 83 00 00 00 05 00 00 00 68 00 00 00 l...........h...
00000010: 08 01 67 00 02 73 73 00 01 01 6F 00 18 00 00 00 ..g..ss...o.....
00000020: 2F 72 65 2F 66 72 69 64 61 2F 41 67 65 6E 74 53 /re/frida/AgentS
00000030: 65 73 73 69 6F 6E 2F 31 00 00 00 00 00 00 00 00 ession/1........
00000040: 03 01 73 00 0C 00 00 00 43 72 65 61 74 65 53 63 ..s.....CreateSc
00000050: 72 69 70 74 00 00 00 00 02 01 73 00 17 00 00 00 ript......s.....
00000060: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe
00000070: 73 73 69 6F 6E 31 32 00 00 00 00 00 00 00 00 00 ssion12.........
00000080: 76 00 00 00 0A 49 6E 74 65 72 63 65 70 74 6F 72 v....Interceptor
00000090: 2E 61 74 74 61 63 68 28 70 74 72 28 22 39 34 32 .attach(ptr("942
000000A0: 37 32 36 36 32 37 32 39 30 34 35 22 29 2C 20 7B 72662729045"), {
000000B0: 0A 20 20 20 20 6F 6E 45 6E 74 65 72 3A 20 66 75 . onEnter: fu
000000C0: 6E 63 74 69 6F 6E 28 61 72 67 73 29 20 7B 0A 20 nction(args) {.
000000D0: 20 20 20 20 20 20 20 73 65 6E 64 28 61 72 67 73 send(args
000000E0: 5B 30 5D 2E 74 6F 49 6E 74 33 32 28 29 29 3B 0A [0].toInt32());.
000000F0: 20 20 20 20 7D 0A 7D 29 3B 0A 00 }.});..
====
STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 44
command[26525]: './hello'
command[26527]: 'python ./hook.py 0x55bd9092f155'
----
00000000: 6C 02 01 01 04 00 00 00 06 00 00 00 18 00 00 00 l...............
00000010: 08 01 67 00 03 28 75 29 00 00 00 00 00 00 00 00 ..g..(u)........
00000020: 05 01 75 00 05 00 00 00 01 00 00 00 ..u.........
- Frida then signals the agent to load the script:
Output
==== STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 132 command[26527]: 'python ./hook.py 0x55bd9092f155' command[26525]: './hello' ---- 00000000: 6C 01 00 01 04 00 00 00 06 00 00 00 70 00 00 00 l...........p... 00000010: 08 01 67 00 03 28 75 29 00 00 00 00 00 00 00 00 ..g..(u)........ 00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid 00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1 00000040: 00 00 00 00 00 00 00 00 03 01 73 00 0A 00 00 00 ..........s..... 00000050: 4C 6F 61 64 53 63 72 69 70 74 00 00 00 00 00 00 LoadScript...... 00000060: 02 01 73 00 17 00 00 00 72 65 2E 66 72 69 64 61 ..s.....re.frida 00000070: 2E 41 67 65 6E 74 53 65 73 73 69 6F 6E 31 32 00 .AgentSession12. 00000080: 01 00 00 00 .... ==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 32 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ---- 00000000: 6C 02 01 01 00 00 00 00 07 00 00 00 10 00 00 00 l............... 00000010: 08 01 67 00 00 00 00 00 05 01 75 00 06 00 00 00 ..g.......u.....
- The injected script, when run, returns the requested data through the socket:
Output
====
STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 180
command[26525]: './hello'
command[26527]: 'python ./hook.py 0x55bd9092f155'
----
00000000: 6C 04 01 01 2C 00 00 00 08 00 00 00 78 00 00 00 l...,.......x...
00000010: 08 01 67 00 07 28 75 29 73 62 61 79 00 00 00 00 ..g..(u)sbay....
00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1
00000040: 00 00 00 00 00 00 00 00 03 01 73 00 11 00 00 00 ..........s.....
00000050: 4D 65 73 73 61 67 65 46 72 6F 6D 53 63 72 69 70 MessageFromScrip
00000060: 74 00 00 00 00 00 00 00 02 01 73 00 17 00 00 00 t.........s.....
00000070: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe
00000080: 73 73 69 6F 6E 31 32 00 01 00 00 00 1B 00 00 00 ssion12.........
00000090: 7B 22 74 79 70 65 22 3A 22 73 65 6E 64 22 2C 22 {"type":"send","
000000A0: 70 61 79 6C 6F 61 64 22 3A 31 7D 00 00 00 00 00 payload":1}.....
000000B0: 00 00 00 00 ....
====
STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 180
command[26525]: './hello'
command[26527]: 'python ./hook.py 0x55bd9092f155'
----
00000000: 6C 04 01 01 2C 00 00 00 09 00 00 00 78 00 00 00 l...,.......x...
00000010: 08 01 67 00 07 28 75 29 73 62 61 79 00 00 00 00 ..g..(u)sbay....
00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1
00000040: 00 00 00 00 00 00 00 00 03 01 73 00 11 00 00 00 ..........s.....
00000050: 4D 65 73 73 61 67 65 46 72 6F 6D 53 63 72 69 70 MessageFromScrip
00000060: 74 00 00 00 00 00 00 00 02 01 73 00 17 00 00 00 t.........s.....
00000070: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe
00000080: 73 73 69 6F 6E 31 32 00 01 00 00 00 1B 00 00 00 ssion12.........
00000090: 7B 22 74 79 70 65 22 3A 22 73 65 6E 64 22 2C 22 {"type":"send","
000000A0: 70 61 79 6C 6F 61 64 22 3A 32 7D 00 00 00 00 00 payload":2}.....
000000B0: 00 00 00 00 ....
====
STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 180
command[26525]: './hello'
command[26527]: 'python ./hook.py 0x55bd9092f155'
----
00000000: 6C 04 01 01 2C 00 00 00 0A 00 00 00 78 00 00 00 l...,.......x...
00000010: 08 01 67 00 07 28 75 29 73 62 61 79 00 00 00 00 ..g..(u)sbay....
00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1
00000040: 00 00 00 00 00 00 00 00 03 01 73 00 11 00 00 00 ..........s.....
00000050: 4D 65 73 73 61 67 65 46 72 6F 6D 53 63 72 69 70 MessageFromScrip
00000060: 74 00 00 00 00 00 00 00 02 01 73 00 17 00 00 00 t.........s.....
00000070: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe
00000080: 73 73 69 6F 6E 31 32 00 01 00 00 00 1B 00 00 00 ssion12.........
00000090: 7B 22 74 79 70 65 22 3A 22 73 65 6E 64 22 2C 22 {"type":"send","
000000A0: 70 61 79 6C 6F 61 64 22 3A 33 7D 00 00 00 00 00 payload":3}.....
000000B0: 00 00 00 00 ....
---snip---
- This message repeats with the payload incrementing by
1as specified in the example code. When the user is done using Frida, Frida will instruct the agent to unload the injected script:
Output
==== STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 132 command[26527]: 'python ./hook.py 0x55bd9092f155' command[26525]: './hello' ---- 00000000: 6C 01 00 01 04 00 00 00 07 00 00 00 70 00 00 00 l...........p... 00000010: 08 01 67 00 03 28 75 29 00 00 00 00 00 00 00 00 ..g..(u)........ 00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid 00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1 00000040: 00 00 00 00 00 00 00 00 03 01 73 00 0D 00 00 00 ..........s..... 00000050: 44 65 73 74 72 6F 79 53 63 72 69 70 74 00 00 00 DestroyScript... 00000060: 02 01 73 00 17 00 00 00 72 65 2E 66 72 69 64 61 ..s.....re.frida 00000070: 2E 41 67 65 6E 74 53 65 73 73 69 6F 6E 31 32 00 .AgentSession12. 00000080: 01 00 00 00 .... ==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 32 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ---- 00000000: 6C 02 01 01 00 00 00 00 0B 00 00 00 10 00 00 00 l............... 00000010: 08 01 67 00 00 00 00 00 05 01 75 00 07 00 00 00 ..g.......u.....
- The injected script is then closed by Frida:
Output
==== STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 112 command[26527]: 'python ./hook.py 0x55bd9092f155' command[26525]: './hello' ---- 00000000: 6C 01 00 01 00 00 00 00 08 00 00 00 60 00 00 00 l...........`... 00000010: 08 01 67 00 00 00 00 00 01 01 6F 00 18 00 00 00 ..g.......o..... 00000020: 2F 72 65 2F 66 72 69 64 61 2F 41 67 65 6E 74 53 /re/frida/AgentS 00000030: 65 73 73 69 6F 6E 2F 31 00 00 00 00 00 00 00 00 ession/1........ 00000040: 03 01 73 00 05 00 00 00 43 6C 6F 73 65 00 00 00 ..s.....Close... 00000050: 02 01 73 00 17 00 00 00 72 65 2E 66 72 69 64 61 ..s.....re.frida 00000060: 2E 41 67 65 6E 74 53 65 73 73 69 6F 6E 31 32 00 .AgentSession12. ==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 132 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ---- 00000000: 6C 04 01 01 04 00 00 00 0C 00 00 00 70 00 00 00 l...........p... 00000010: 08 01 67 00 03 28 75 29 00 00 00 00 00 00 00 00 ..g..(u)........ 00000020: 01 01 6F 00 1E 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid 00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 50 72 a/AgentSessionPr 00000040: 6F 76 69 64 65 72 00 00 03 01 73 00 06 00 00 00 ovider....s..... 00000050: 43 6C 6F 73 65 64 00 00 02 01 73 00 1F 00 00 00 Closed....s..... 00000060: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe 00000070: 73 73 69 6F 6E 50 72 6F 76 69 64 65 72 31 32 00 ssionProvider12. 00000080: 01 00 00 00 .... ==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 32 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ---- 00000000: 6C 02 01 01 00 00 00 00 0D 00 00 00 10 00 00 00 l............... 00000010: 08 01 67 00 00 00 00 00 05 01 75 00 08 00 00 00 ..g.......u.....
- And, for the final step, Frida instructs the injected agent to unload:
Output
==== STREAM PID 26527.0xffff8cd6e81ad700 (S) > 26525.0xffff8cd6e81ad000 (C), length 120 command[26527]: 'python ./hook.py 0x55bd9092f155' command[26525]: './hello' ---- 00000000: 6C 01 00 01 00 00 00 00 09 00 00 00 68 00 00 00 l...........h... 00000010: 08 01 67 00 00 00 00 00 01 01 6F 00 1E 00 00 00 ..g.......o..... 00000020: 2F 72 65 2F 66 72 69 64 61 2F 41 67 65 6E 74 53 /re/frida/AgentS 00000030: 65 73 73 69 6F 6E 50 72 6F 76 69 64 65 72 00 00 essionProvider.. 00000040: 03 01 73 00 06 00 00 00 55 6E 6C 6F 61 64 00 00 ..s.....Unload.. 00000050: 02 01 73 00 1F 00 00 00 72 65 2E 66 72 69 64 61 ..s.....re.frida 00000060: 2E 41 67 65 6E 74 53 65 73 73 69 6F 6E 50 72 6F .AgentSessionPro 00000070: 76 69 64 65 72 31 32 00 vider12. ==== STREAM PID 26525.0xffff8cd6e81ad000 (C) > 26527.0xffff8cd6e81ad700 (S), length 32 command[26525]: './hello' command[26527]: 'python ./hook.py 0x55bd9092f155' ---- 00000000: 6C 02 01 01 00 00 00 00 0E 00 00 00 10 00 00 00 l............... 00000010: 08 01 67 00 00 00 00 00 05 01 75 00 09 00 00 00 ..g.......u.....
Frida CLI Tab Completion Protocol
The Frida command line tool has a tab completion-based prompt that allows quick access to all of its features. We will examine the communications that occur while Frida is performing a tab complete operation.
- Frida starts the interaction by sending a
PostToScriptcommand to the injected script. The script sent callsObject.getOwnProperties()on thethisobject:
Output
==== STREAM PID 26851.0xffff8cd6a8a25900 (S) > 26847.0xffff8cd62e7e9100 (C), length 220 command[26851]: '/usr/bin/python /usr/local/bin/frida -p 26847' command[26847]: './hello' ---- 00000000: 6C 01 00 01 5C 00 00 00 0B 00 00 00 70 00 00 00 l..........p... 00000010: 08 01 67 00 07 28 75 29 73 62 61 79 00 00 00 00 ..g..(u)sbay.... 00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid 00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1 00000040: 00 00 00 00 00 00 00 00 03 01 73 00 0C 00 00 00 ..........s..... 00000050: 50 6F 73 74 54 6F 53 63 72 69 70 74 00 00 00 00 PostToScript.... 00000060: 02 01 73 00 17 00 00 00 72 65 2E 66 72 69 64 61 ..s.....re.frida 00000070: 2E 41 67 65 6E 74 53 65 73 73 69 6F 6E 31 32 00 .AgentSession12. 00000080: 01 00 00 00 4A 00 00 00 5B 22 66 72 69 64 61 3A ....J...["frida: 00000090: 72 70 63 22 2C 20 35 2C 20 22 63 61 6C 6C 22 2C rpc", 5, "call", 000000A0: 20 22 65 76 61 6C 75 61 74 65 22 2C 20 5B 22 4F "evaluate", ["O 000000B0: 62 6A 65 63 74 2E 67 65 74 4F 77 6E 50 72 6F 70 bject.getOwnProp 000000C0: 65 72 74 79 4E 61 6D 65 73 28 74 68 69 73 29 22 ertyNames(this)" 000000D0: 5D 5D 00 00 00 00 00 00 00 00 00 00 ]].......... ==== STREAM PID 26847.0xffff8cd62e7e9100 (C) > 26851.0xffff8cd6a8a25900 (S), length 32 command[26847]: './hello' command[26851]: '/usr/bin/python /usr/local/bin/frida -p 26847' ---- 00000000: 6C 02 01 01 00 00 00 00 10 00 00 00 10 00 00 00 l............... 00000010: 08 01 67 00 00 00 00 00 05 01 75 00 0B 00 00 00 ..g.......u.....
- This causes the Frida agent within the target process to evaluate the script and return all properties of the
thisobject, the possible actions and available commands we are attempting to tab complete:
Output
====
STREAM PID 26847.0xffff8cd62e7e9100 (C) > 26851.0xffff8cd6a8a25900 (S), length 1736
command[26847]: './hello'
command[26851]: '/usr/bin/python /usr/local/bin/frida -p 26847'
----
00000000: 6C 04 01 01 40 06 00 00 11 00 00 00 78 00 00 00 l...@.......x...
00000010: 08 01 67 00 07 28 75 29 73 62 61 79 00 00 00 00 ..g..(u)sbay....
00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1
00000040: 00 00 00 00 00 00 00 00 03 01 73 00 11 00 00 00 ..........s.....
00000050: 4D 65 73 73 61 67 65 46 72 6F 6D 53 63 72 69 70 MessageFromScrip
00000060: 74 00 00 00 00 00 00 00 02 01 73 00 17 00 00 00 t.........s.....
00000070: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe
00000080: 73 73 69 6F 6E 31 32 00 01 00 00 00 2C 06 00 00 ssion12.....,...
00000090: 7B 22 74 79 70 65 22 3A 22 73 65 6E 64 22 2C 22 {"type":"send","
000000A0: 70 61 79 6C 6F 61 64 22 3A 5B 22 66 72 69 64 61 payload":["frida
000000B0: 3A 72 70 63 22 2C 35 2C 22 6F 6B 22 2C 5B 22 6F :rpc",5,"ok",["o
000000C0: 62 6A 65 63 74 22 2C 5B 22 4E 61 4E 22 2C 22 49 bject",["NaN","I
000000D0: 6E 66 69 6E 69 74 79 22 2C 22 75 6E 64 65 66 69 nfinity","undefi
000000E0: 6E 65 64 22 2C 22 4F 62 6A 65 63 74 22 2C 22 46 ned","Object","F
000000F0: 75 6E 63 74 69 6F 6E 22 2C 22 41 72 72 61 79 22 unction","Array"
00000100: 2C 22 53 74 72 69 6E 67 22 2C 22 42 6F 6F 6C 65 ,"String","Boole
00000110: 61 6E 22 2C 22 4E 75 6D 62 65 72 22 2C 22 44 61 an","Number","Da
00000120: 74 65 22 2C 22 52 65 67 45 78 70 22 2C 22 45 72 te","RegExp","Er
00000130: 72 6F 72 22 2C 22 45 76 61 6C 45 72 72 6F 72 22 ror","EvalError"
00000140: 2C 22 52 61 6E 67 65 45 72 72 6F 72 22 2C 22 52 ,"RangeError","R
00000150: 65 66 65 72 65 6E 63 65 45 72 72 6F 72 22 2C 22 eferenceError","
00000160: 53 79 6E 74 61 78 45 72 72 6F 72 22 2C 22 54 79 SyntaxError","Ty
00000170: 70 65 45 72 72 6F 72 22 2C 22 55 52 49 45 72 72 peError","URIErr
00000180: 6F 72 22 2C 22 4D 61 74 68 22 2C 22 4A 53 4F 4E or","Math","JSON
00000190: 22 2C 22 44 75 6B 74 61 70 65 22 2C 22 50 72 6F ","Duktape","Pro
000001A0: 78 79 22 2C 22 52 65 66 6C 65 63 74 22 2C 22 42 xy","Reflect","B
000001B0: 75 66 66 65 72 22 2C 22 41 72 72 61 79 42 75 66 uffer","ArrayBuf
000001C0: 66 65 72 22 2C 22 44 61 74 61 56 69 65 77 22 2C fer","DataView",
000001D0: 22 49 6E 74 38 41 72 72 61 79 22 2C 22 55 69 6E "Int8Array","Uin
000001E0: 74 38 41 72 72 61 79 22 2C 22 55 69 6E 74 38 43 t8Array","Uint8C
000001F0: 6C 61 6D 70 65 64 41 72 72 61 79 22 2C 22 49 6E lampedArray","In
00000200: 74 31 36 41 72 72 61 79 22 2C 22 55 69 6E 74 31 t16Array","Uint1
00000210: 36 41 72 72 61 79 22 2C 22 49 6E 74 33 32 41 72 6Array","Int32Ar
00000220: 72 61 79 22 2C 22 55 69 6E 74 33 32 41 72 72 61 ray","Uint32Arra
00000230: 79 22 2C 22 46 6C 6F 61 74 33 32 41 72 72 61 79 y","Float32Array
00000240: 22 2C 22 46 6C 6F 61 74 36 34 41 72 72 61 79 22 ","Float64Array"
00000250: 2C 22 70 61 72 73 65 49 6E 74 22 2C 22 70 61 72 ,"parseInt","par
00000260: 73 65 46 6C 6F 61 74 22 2C 22 54 65 78 74 45 6E seFloat","TextEn
00000270: 63 6F 64 65 72 22 2C 22 54 65 78 74 44 65 63 6F coder","TextDeco
00000280: 64 65 72 22 2C 22 70 65 72 66 6F 72 6D 61 6E 63 der","performanc
00000290: 65 22 2C 22 65 76 61 6C 22 2C 22 69 73 4E 61 4E e","eval","isNaN
000002A0: 22 2C 22 69 73 46 69 6E 69 74 65 22 2C 22 64 65 ","isFinite","de
000002B0: 63 6F 64 65 55 52 49 22 2C 22 64 65 63 6F 64 65 codeURI","decode
000002C0: 55 52 49 43 6F 6D 70 6F 6E 65 6E 74 22 2C 22 65 URIComponent","e
000002D0: 6E 63 6F 64 65 55 52 49 22 2C 22 65 6E 63 6F 64 ncodeURI","encod
000002E0: 65 55 52 49 43 6F 6D 70 6F 6E 65 6E 74 22 2C 22 eURIComponent","
000002F0: 65 73 63 61 70 65 22 2C 22 75 6E 65 73 63 61 70 escape","unescap
00000300: 65 22 2C 22 67 6C 6F 62 61 6C 22 2C 22 46 72 69 e","global","Fri
00000310: 64 61 22 2C 22 53 63 72 69 70 74 22 2C 22 57 65 da","Script","We
00000320: 61 6B 52 65 66 22 2C 22 5F 73 65 74 54 69 6D 65 akRef","_setTime
00000330: 6F 75 74 22 2C 22 5F 73 65 74 49 6E 74 65 72 76 out","_setInterv
00000340: 61 6C 22 2C 22 63 6C 65 61 72 54 69 6D 65 6F 75 al","clearTimeou
00000350: 74 22 2C 22 63 6C 65 61 72 49 6E 74 65 72 76 61 t","clearInterva
00000360: 6C 22 2C 22 67 63 22 2C 22 5F 73 65 6E 64 22 2C l","gc","_send",
00000370: 22 5F 73 65 74 55 6E 68 61 6E 64 6C 65 64 45 78 "_setUnhandledEx
00000380: 63 65 70 74 69 6F 6E 43 61 6C 6C 62 61 63 6B 22 ceptionCallback"
00000390: 2C 22 5F 73 65 74 49 6E 63 6F 6D 69 6E 67 4D 65 ,"_setIncomingMe
000003A0: 73 73 61 67 65 43 61 6C 6C 62 61 63 6B 22 2C 22 ssageCallback","
000003B0: 5F 77 61 69 74 46 6F 72 45 76 65 6E 74 22 2C 22 _waitForEvent","
000003C0: 49 6E 74 36 34 22 2C 22 55 49 6E 74 36 34 22 2C Int64","UInt64",
000003D0: 22 4E 61 74 69 76 65 50 6F 69 6E 74 65 72 22 2C "NativePointer",
000003E0: 22 4E 61 74 69 76 65 52 65 73 6F 75 72 63 65 22 "NativeResource"
000003F0: 2C 22 4E 61 74 69 76 65 46 75 6E 63 74 69 6F 6E ,"NativeFunction
00000400: 22 2C 22 53 79 73 74 65 6D 46 75 6E 63 74 69 6F ","SystemFunctio
00000410: 6E 22 2C 22 4E 61 74 69 76 65 43 61 6C 6C 62 61 n","NativeCallba
00000420: 63 6B 22 2C 22 43 70 75 43 6F 6E 74 65 78 74 22 ck","CpuContext"
00000430: 2C 22 53 6F 75 72 63 65 4D 61 70 22 2C 22 4B 65 ,"SourceMap","Ke
00000440: 72 6E 65 6C 22 2C 22 4D 65 6D 6F 72 79 22 2C 22 rnel","Memory","
00000450: 4D 65 6D 6F 72 79 41 63 63 65 73 73 4D 6F 6E 69 MemoryAccessMoni
00000460: 74 6F 72 22 2C 22 50 72 6F 63 65 73 73 22 2C 22 tor","Process","
00000470: 54 68 72 65 61 64 22 2C 22 42 61 63 6B 74 72 61 Thread","Backtra
00000480: 63 65 72 22 2C 22 4D 6F 64 75 6C 65 22 2C 22 4D cer","Module","M
00000490: 6F 64 75 6C 65 4D 61 70 22 2C 22 46 69 6C 65 22 oduleMap","File"
000004A0: 2C 22 49 4F 53 74 72 65 61 6D 22 2C 22 49 6E 70 ,"IOStream","Inp
000004B0: 75 74 53 74 72 65 61 6D 22 2C 22 4F 75 74 70 75 utStream","Outpu
000004C0: 74 53 74 72 65 61 6D 22 2C 22 55 6E 69 78 49 6E tStream","UnixIn
000004D0: 70 75 74 53 74 72 65 61 6D 22 2C 22 55 6E 69 78 putStream","Unix
000004E0: 4F 75 74 70 75 74 53 74 72 65 61 6D 22 2C 22 53 OutputStream","S
000004F0: 6F 63 6B 65 74 22 2C 22 53 6F 63 6B 65 74 4C 69 ocket","SocketLi
00000500: 73 74 65 6E 65 72 22 2C 22 53 6F 63 6B 65 74 43 stener","SocketC
00000510: 6F 6E 6E 65 63 74 69 6F 6E 22 2C 22 53 71 6C 69 onnection","Sqli
00000520: 74 65 44 61 74 61 62 61 73 65 22 2C 22 53 71 6C teDatabase","Sql
00000530: 69 74 65 53 74 61 74 65 6D 65 6E 74 22 2C 22 49 iteStatement","I
00000540: 6E 74 65 72 63 65 70 74 6F 72 22 2C 22 49 6E 76 nterceptor","Inv
00000550: 6F 63 61 74 69 6F 6E 4C 69 73 74 65 6E 65 72 22 ocationListener"
00000560: 2C 22 49 6E 76 6F 63 61 74 69 6F 6E 43 6F 6E 74 ,"InvocationCont
00000570: 65 78 74 22 2C 22 49 6E 76 6F 63 61 74 69 6F 6E ext","Invocation
00000580: 41 72 67 73 22 2C 22 49 6E 76 6F 63 61 74 69 6F Args","Invocatio
00000590: 6E 52 65 74 75 72 6E 56 61 6C 75 65 22 2C 22 41 nReturnValue","A
000005A0: 70 69 52 65 73 6F 6C 76 65 72 22 2C 22 44 65 62 piResolver","Deb
000005B0: 75 67 53 79 6D 62 6F 6C 22 2C 22 49 6E 73 74 72 ugSymbol","Instr
000005C0: 75 63 74 69 6F 6E 22 2C 22 58 38 36 57 72 69 74 uction","X86Writ
000005D0: 65 72 22 2C 22 58 38 36 52 65 6C 6F 63 61 74 6F er","X86Relocato
000005E0: 72 22 2C 22 53 74 61 6C 6B 65 72 22 2C 22 53 74 r","Stalker","St
000005F0: 61 6C 6B 65 72 49 74 65 72 61 74 6F 72 22 2C 22 alkerIterator","
00000600: 50 72 6F 62 65 41 72 67 73 22 2C 22 5F 5F 63 6F ProbeArgs","__co
00000610: 72 65 2D 6A 73 5F 73 68 61 72 65 64 5F 5F 22 2C re-js_shared__",
00000620: 22 50 72 6F 6D 69 73 65 22 2C 22 72 70 63 22 2C "Promise","rpc",
00000630: 22 72 65 63 76 22 2C 22 73 65 6E 64 22 2C 22 73 "recv","send","s
00000640: 65 74 54 69 6D 65 6F 75 74 22 2C 22 73 65 74 49 etTimeout","setI
00000650: 6E 74 65 72 76 61 6C 22 2C 22 73 65 74 49 6D 6D nterval","setImm
00000660: 65 64 69 61 74 65 22 2C 22 63 6C 65 61 72 49 6D ediate","clearIm
00000670: 6D 65 64 69 61 74 65 22 2C 22 69 6E 74 36 34 22 mediate","int64"
00000680: 2C 22 75 69 6E 74 36 34 22 2C 22 70 74 72 22 2C ,"uint64","ptr",
00000690: 22 4E 55 4C 4C 22 2C 22 63 6F 6E 73 6F 6C 65 22 "NULL","console"
000006A0: 2C 22 68 65 78 64 75 6D 70 22 2C 22 4F 62 6A 43 ,"hexdump","ObjC
000006B0: 22 2C 22 4A 61 76 61 22 5D 5D 5D 7D 00 00 00 00 ","Java"]]]}....
000006C0: 00 00 00 00 00 00 00 00 ........
- Seeing this list, we begin to type out
File.and hit tab to see our options.Object.getOwnProperties()is called again, but now it is called onFile. This returns us the following attributes:prototype,length, andname:
Output
====
STREAM PID 26851.0xffff8cd6a8a25900 (S) > 26847.0xffff8cd62e7e9100 (C), length 1220
command[26851]: '/usr/bin/python /usr/local/bin/frida -p 26847'
command[26847]: './hello'
----
00000000: 6C 01 00 01 44 04 00 00 0C 00 00 00 70 00 00 00 l...D.......p...
00000010: 08 01 67 00 07 28 75 29 73 62 61 79 00 00 00 00 ..g..(u)sbay....
00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1
00000040: 00 00 00 00 00 00 00 00 03 01 73 00 0C 00 00 00 ..........s.....
00000050: 50 6F 73 74 54 6F 53 63 72 69 70 74 00 00 00 00 PostToScript....
00000060: 02 01 73 00 17 00 00 00 72 65 2E 66 72 69 64 61 ..s.....re.frida
00000070: 2E 41 67 65 6E 74 53 65 73 73 69 6F 6E 31 32 00 .AgentSession12.
00000080: 01 00 00 00 30 04 00 00 5B 22 66 72 69 64 61 3A ....0...["frida:
00000090: 72 70 63 22 2C 20 36 2C 20 22 63 61 6C 6C 22 2C rpc", 6, "call",
000000A0: 20 22 65 76 61 6C 75 61 74 65 22 2C 20 5B 22 74 "evaluate", ["t
000000B0: 72 79 20 7B 5C 6E 20 20 20 20 20 20 20 20 20 20 ry {n
000000C0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000000D0: 20 20 20 20 20 20 20 20 20 20 28 66 75 6E 63 74 (funct
000000E0: 69 6F 6E 20 28 6F 29 20 7B 5C 6E 20 20 20 20 20 ion (o) {n
000000F0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000100: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000110: 20 20 20 5C 22 75 73 65 20 73 74 72 69 63 74 5C "use strict
00000120: 22 3B 5C 6E 20 20 20 20 20 20 20 20 20 20 20 20 ";n
00000130: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000140: 20 20 20 20 20 20 20 20 20 20 20 20 76 61 72 20 var
00000150: 6B 20 3D 20 4F 62 6A 65 63 74 2E 67 65 74 4F 77 k = Object.getOw
00000160: 6E 50 72 6F 70 65 72 74 79 4E 61 6D 65 73 28 6F nPropertyNames(o
00000170: 29 3B 5C 6E 20 20 20 20 20 20 20 20 20 20 20 20 );n
00000180: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000190: 20 20 20 20 20 20 20 20 20 20 20 20 69 66 20 28 if (
000001A0: 6F 20 21 3D 3D 20 6E 75 6C 6C 20 26 26 20 6F 20 o !== null o
000001B0: 21 3D 3D 20 75 6E 64 65 66 69 6E 65 64 29 20 7B !== undefined) {
000001C0: 5C 6E 20 20 20 20 20 20 20 20 20 20 20 20 20 20 n
000001D0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000001E0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 76 61 va
000001F0: 72 20 70 3B 5C 6E 20 20 20 20 20 20 20 20 20 20 r p;n
00000200: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000210: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000220: 20 20 69 66 20 28 74 79 70 65 6F 66 20 6F 20 21 if (typeof o !
00000230: 3D 3D 20 27 6F 62 6A 65 63 74 27 29 5C 6E 20 20 == 'object')n
00000240: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000250: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000260: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 70 20 p
00000270: 3D 20 6F 2E 5F 5F 70 72 6F 74 6F 5F 5F 3B 5C 6E = o.__proto__;n
00000280: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000290: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000002A0: 20 20 20 20 20 20 20 20 20 20 20 20 65 6C 73 65 else
000002B0: 5C 6E 20 20 20 20 20 20 20 20 20 20 20 20 20 20 n
000002C0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000002D0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000002E0: 20 20 70 20 3D 20 4F 62 6A 65 63 74 2E 67 65 74 p = Object.get
000002F0: 50 72 6F 74 6F 74 79 70 65 4F 66 28 6F 29 3B 5C PrototypeOf(o);
00000300: 6E 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 n
00000310: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000320: 20 20 20 20 20 20 20 20 20 20 20 20 20 69 66 20 if
00000330: 28 70 20 21 3D 3D 20 6E 75 6C 6C 20 26 26 20 70 (p !== null p
00000340: 20 21 3D 3D 20 75 6E 64 65 66 69 6E 65 64 29 5C !== undefined)
00000350: 6E 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 n
00000360: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000370: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000380: 20 6B 20 3D 20 6B 2E 63 6F 6E 63 61 74 28 4F 62 k = k.concat(Ob
00000390: 6A 65 63 74 2E 67 65 74 4F 77 6E 50 72 6F 70 65 ject.getOwnPrope
000003A0: 72 74 79 4E 61 6D 65 73 28 70 29 29 3B 5C 6E 20 rtyNames(p));n
000003B0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000003C0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000003D0: 20 20 20 20 20 20 20 7D 5C 6E 20 20 20 20 20 20 }n
000003E0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000003F0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000400: 20 20 72 65 74 75 72 6E 20 6B 3B 5C 6E 20 20 20 return k;n
00000410: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000420: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000430: 20 7D 29 28 46 69 6C 65 29 3B 5C 6E 20 20 20 20 })(File);n
00000440: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000450: 20 20 20 20 20 20 20 20 20 20 20 20 7D 20 63 61 } ca
00000460: 74 63 68 20 28 65 29 20 7B 5C 6E 20 20 20 20 20 tch (e) {n
00000470: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00000480: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 5B [
00000490: 5D 3B 5C 6E 20 20 20 20 20 20 20 20 20 20 20 20 ];n
000004A0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000004B0: 20 20 20 20 7D 22 5D 5D 00 00 00 00 00 00 00 00 }"]]........
000004C0: 00 00 00 00 ....
====
STREAM PID 26847.0xffff8cd62e7e9100 (C) > 26851.0xffff8cd6a8a25900 (S), length 32
command[26847]: './hello'
command[26851]: '/usr/bin/python /usr/local/bin/frida -p 26847'
----
00000000: 6C 02 01 01 00 00 00 00 12 00 00 00 10 00 00 00 l...............
00000010: 08 01 67 00 00 00 00 00 05 01 75 00 0C 00 00 00 ..g.......u.....
====
STREAM PID 26847.0xffff8cd62e7e9100 (C) > 26851.0xffff8cd6a8a25900 (S), length 240
command[26847]: './hello'
command[26851]: '/usr/bin/python /usr/local/bin/frida -p 26847'
----
00000000: 6C 04 01 01 68 00 00 00 13 00 00 00 78 00 00 00 l...h.......x...
00000010: 08 01 67 00 07 28 75 29 73 62 61 79 00 00 00 00 ..g..(u)sbay....
00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1
00000040: 00 00 00 00 00 00 00 00 03 01 73 00 11 00 00 00 ..........s.....
00000050: 4D 65 73 73 61 67 65 46 72 6F 6D 53 63 72 69 70 MessageFromScrip
00000060: 74 00 00 00 00 00 00 00 02 01 73 00 17 00 00 00 t.........s.....
00000070: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe
00000080: 73 73 69 6F 6E 31 32 00 01 00 00 00 57 00 00 00 ssion12.....W...
00000090: 7B 22 74 79 70 65 22 3A 22 73 65 6E 64 22 2C 22 {"type":"send","
000000A0: 70 61 79 6C 6F 61 64 22 3A 5B 22 66 72 69 64 61 payload":["frida
000000B0: 3A 72 70 63 22 2C 36 2C 22 6F 6B 22 2C 5B 22 6F :rpc",6,"ok",["o
000000C0: 62 6A 65 63 74 22 2C 5B 22 70 72 6F 74 6F 74 79 bject",["prototy
000000D0: 70 65 22 2C 22 6C 65 6E 67 74 68 22 2C 22 6E 61 pe","length","na
000000E0: 6D 65 22 5D 5D 5D 7D 00 00 00 00 00 00 00 00 00 me"]]]}.........
- Back in the UI, we tab cycle to the
lengthattribute and hit enter onFile.length. This tells the injected script to callevaluateonFile.length. The script responds with an array indicating that the type of the evaluated expression is"number"and the value is2:
Output
====
STREAM PID 26851.0xffff8cd6a8a25900 (S) > 26847.0xffff8cd62e7e9100 (C), length 200
command[26851]: '/usr/bin/python /usr/local/bin/frida -p 26847'
command[26847]: './hello'
----
00000000: 6C 01 00 01 48 00 00 00 0D 00 00 00 70 00 00 00 l...H.......p...
00000010: 08 01 67 00 07 28 75 29 73 62 61 79 00 00 00 00 ..g..(u)sbay....
00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1
00000040: 00 00 00 00 00 00 00 00 03 01 73 00 0C 00 00 00 ..........s.....
00000050: 50 6F 73 74 54 6F 53 63 72 69 70 74 00 00 00 00 PostToScript....
00000060: 02 01 73 00 17 00 00 00 72 65 2E 66 72 69 64 61 ..s.....re.frida
00000070: 2E 41 67 65 6E 74 53 65 73 73 69 6F 6E 31 32 00 .AgentSession12.
00000080: 01 00 00 00 35 00 00 00 5B 22 66 72 69 64 61 3A ....5...["frida:
00000090: 72 70 63 22 2C 20 37 2C 20 22 63 61 6C 6C 22 2C rpc", 7, "call",
000000A0: 20 22 65 76 61 6C 75 61 74 65 22 2C 20 5B 22 46 "evaluate", ["F
000000B0: 69 6C 65 2E 6C 65 6E 67 74 68 22 5D 5D 00 00 00 ile.length"]]...
000000C0: 00 00 00 00 00 00 00 00 ........
====
STREAM PID 26847.0xffff8cd62e7e9100 (C) > 26851.0xffff8cd6a8a25900 (S), length 32
command[26847]: './hello'
command[26851]: '/usr/bin/python /usr/local/bin/frida -p 26847'
----
00000000: 6C 02 01 01 00 00 00 00 14 00 00 00 10 00 00 00 l...............
00000010: 08 01 67 00 00 00 00 00 05 01 75 00 0D 00 00 00 ..g.......u.....
====
STREAM PID 26847.0xffff8cd62e7e9100 (C) > 26851.0xffff8cd6a8a25900 (S), length 212
command[26847]: './hello'
command[26851]: '/usr/bin/python /usr/local/bin/frida -p 26847'
----
00000000: 6C 04 01 01 4C 00 00 00 15 00 00 00 78 00 00 00 l...L.......x...
00000010: 08 01 67 00 07 28 75 29 73 62 61 79 00 00 00 00 ..g..(u)sbay....
00000020: 01 01 6F 00 18 00 00 00 2F 72 65 2F 66 72 69 64 ..o...../re/frid
00000030: 61 2F 41 67 65 6E 74 53 65 73 73 69 6F 6E 2F 31 a/AgentSession/1
00000040: 00 00 00 00 00 00 00 00 03 01 73 00 11 00 00 00 ..........s.....
00000050: 4D 65 73 73 61 67 65 46 72 6F 6D 53 63 72 69 70 MessageFromScrip
00000060: 74 00 00 00 00 00 00 00 02 01 73 00 17 00 00 00 t.........s.....
00000070: 72 65 2E 66 72 69 64 61 2E 41 67 65 6E 74 53 65 re.frida.AgentSe
00000080: 73 73 69 6F 6E 31 32 00 01 00 00 00 3B 00 00 00 ssion12.....;...
00000090: 7B 22 74 79 70 65 22 3A 22 73 65 6E 64 22 2C 22 {"type":"send","
000000A0: 70 61 79 6C 6F 61 64 22 3A 5B 22 66 72 69 64 61 payload":["frida
000000B0: 3A 72 70 63 22 2C 37 2C 22 6F 6B 22 2C 5B 22 6E :rpc",7,"ok",["n
000000C0: 75 6D 62 65 72 22 2C 32 5D 5D 7D 00 00 00 00 00 umber",2]]}.....
000000D0: 00 00 00 00 ....
eBPF Coding Tricks
While writing unixdump, we spent an inordinate amount of time attempting to please the eBPF bytecode validator with code constructs it would accept. Most of the time, it would not like idiomatic code that was correct; this was seemingly due to compiler optimizations used by the BCC toolchain. Regardless, we often had to obscure our code in ways that would enable it to pass inspection, and, as a result, the code likely performs worse than if the validator worked correctly in the first place. Additionally, as some of the data structures we needed to parse are dynamically sized and based on dynamic offsets, we had to write (or generate) inline code to parse them directly without loops or recursion. And then there are the generic eBPF hoops that need to be jumped through on a regular basis.
eBPF Gotchas
No Loops, No Jumper Cables
eBPF doesn’t like loops, that much is clear; but we often still need to perform such operations. Abusing the eBPF memcpy-alike, bpf_probe_read will only get one so far, especially if one needs to NULL out a struct. In practice, short statically-bounded loops will be unrolled by the compiler and work, but longer loops will not and won’t. However, it is simple to unroll loops with statically-known bounds using compiler pragmas:
#pragma unroll for (size_t i=0; i < 30; i++) { arr[i] = arr[i] + 1; }
This is a fairly useful construct that be ruthlessly applied to a number of different problems.
Uninitialized Memory
One of the things to be careful about with eBPF is that when attempting to copy data from the eBPF stack elsewhere, if any uninitialized memory would be copied, the validator will error with offending stack offsets that are entirely unhelpful. Usually, this is the result of having padding between fields in your structs. A simple way of handling this is to use an unrolled loop akin to memset-ing zero; where possible, such code will be optimized to use 8-byte writes. However, this is computationally wasteful. Instead, another option is to carefully control field types and ordering to fill in all gaps. Failing this, explicitly declaring settable padding values and padding unions can enable a programmer to manually elide double writes to the struct. And lastly, one can always use a packed struct (e.g. struct __attribute__((__packed__)) foo {...}); this may require more byte shuffling operations to write and read, but can be of help when the limiting factor of the eBPF code is the effective rate/drop limit of perf_submit, by reducing the overall amount of data sent.
eBPF Chicanery
For unixdump we had a number of operational needs based on correctness or performance goals that required writing a significant amount of non-idiomatic C code and code generation tooling. While none of this is especially groundbreaking, it is worth discussing how to perform common programmatic tasks while under constraints like those imposed by eBPF.
Ratcheting
In addition to managing memory shared between kernel space and userspace, we also needed to maintain state of the current position within the custom ring buffer. This is achieved simply enough by using another per-CPU ring buffer, one that only holds a single value. This provides a separate position value associated with each per-CPU ring buffer. However, the problem with this setup is not in the data itself, but the mechanism by which it is incremented, or, more importantly, wrapped. The eBPF validator was displeased with any ratchet that tried to perform the wrap via a specific switch case. Instead only it accepts implementations where wrapping is only performed using the default: label; attempts to wrap the value in the last “valid” case or “guess” the wrapping position will fail, even if the default: code also wraps. For example, the following is an eBPF-valid position counter ratchet implementation:
u32 pos = UINT32_MAX; int key = 0; sync = sync_buf.lookup( key); if (!sync) { return 0; } pos = 0; switch (sync->next) { case 0: { pos = 0; sync->next = 1; break; }; case 1: { pos = 1; sync->next = 2; break; }; default: { pos = 0; sync->next = 1; } }
Dynamic Structure Parsing
While writing unixdump, we got the crazy idea to keep track of all ancillary data (e.g. file descriptors) passing over Unix domain sockets. While this is of great benefit for tracking how processes are passing file handles, sockets, and other descriptors to each other, the “format” into which the data is marshalled is very fluid and poorly specified. For example, similarly to SMS messages, received messages may have a different structure from what what actually sent; in particular, multiple messages of the same type may be coalesced into a single message containing multiple values, regardless of the order in which they were sent.
In unixdump, we use unrolled nested loops to iterate through the CMSG structures containing ancillary data. Where possible, we use the CMSG_* macros to index into the buffer and access fields; however, we reimplemented several of these macros to be compatible with BCC’s pointer dereference instrumentation which was unable to handle all of the CMSG_* macros. To store the data and report it back to userspace, we used a typed union struct that can store both SCM_RIGHTS (file descriptors) and SCM_CREDENTIALS (Unix credentials), which additionally keeps track of the count of the former and whether or not the last element returned to userspace was actually the last element of the in-kernel CMSG structure. Both the max count of copyable CMSGs and slots within a CMSG (for storing SCM_RIGHTS file descriptors) are configurable via the CLI; this also modifies the unrolled loop counts.
Static Data Structures and Algorithms
To appropriately handle the glut of data caught by unixdump, we needed to performantly filter PIDs (inclusively or exclusively) in eBPF C code, so as to limit the amount of data and number of events sent to userland. Iteratively comparing each one would be extremely costly, so we instead opted to use a binary search tree. As a recursive binary search implementation will trip the loop check, we instead generate the entire static C implementation (dynamically in Python) for the values being filtered. For reference, the implementation can be found here.
Dark eBPF Thaumaturgy
Even with all of the above tricks to keep it happy, the eBPF validator’s muse is still a fickle miscreant with a very short attention span. Be it due to changes in the toolchain or the Linux kernel itself, the validator may look upon your overly clever code and decide to smite you where you stand. Sometimes, appeasing the validator requires ever greater sacrifices of idiomaticity.
Dynamic Length Byte Copies
Per the issue mentioned earlier, it is not immediately clear that variable length byte copies from kernel memory are possible with eBPF. Given that the recommended solution is to use a helper function for copying NUL-terminated C strings, this would be a problem when the variable length data is binary content that may contain NULL bytes. However, this is not the case, and such copies can be performed, albeit with some careful slight slight-of-hand. While this is not an issue for socket paths, of which the sun_path field of struct sockaddr_un is guaranteed to be at least UNIX_PATH_MAX (108) bytes long, this is an issue for copying arbitrary socket data. While it is important to ensure that stack-based arrays are fully written to (e.g. write NULL bytes to the remainder of arrays), this limitation does not exist for eBPF map structures as they are zero-initialized by the kernel to prevent information leaks. Instead, the trouble occurs when one attempts to truncate the copy length. Between BCC and the eBPF validator, it is often the case that a byte copy of the length of an array or less is considered unsafe, and therefore rejected. Instead, when tapering off the array length, it was previously necessary to cap the copy length to sizeof(buffer)-1. The odd behavior here is that if the source length is the same as the destination length, it must still be truncated. Additionally, to prevent optimizations that may elide certain comparisons needed to provide the eBPF validator with register bounds, we found that it was possible to simply wrap the desired code in a static inline function to shadow the variables in play. For example, in unixdump we perform this copy and track whether or not the data was truncated in the following code:
inline static void copy_into_entry_buffer(data_t* entry, size_t const len, char* base, u8 volatile* trunc) { int l = (int)len; if (l < 0) { l = 0; } if (l >= BUFFER_SIZE) { *trunc = 1; } if (l >= BUFFER_SIZE) { l = BUFFER_SIZE - 1; } bpf_probe_read(entry->buffer, l, base); }
Note: This behavior has changed a few times between BCC and Linux kernel versions, and when using current versions of both, it is possible to implement the optimal case of copying right up to the end of the array; however, to support older versions we continue to use the less optimal “truncate on equal” version shown above.
Type Juggling
Another spooky behavior we observed with a previous version of BCC (which we have not observed since) was an interesting case where the return type of a function could cause the validator to raise an error. While it may be simple enough to imagine such a situation involving mixing signed and unsigned integers, this instance related to the use ofbool as both the return and variable type, which was eventually casted to size_t. In some versions of our code, the validator would raise an error if the return value was bool, but in others it would raise an error if the return value was size_t. For context, unixdump will, based on CLI options for certain features, enable or disable certain kprobe functionality with #if(def)s. As a result, we simply used the same feature detections to set a BOOL_TYPE define used as the return and variable type with either bool or size_t. At the time, we did not bother to triage this issue (sorry!), but it does not affect the current unixdump code when using a current BCC. As for whether or not this is because the current BCC fixed the issue, or our current code is unaffected, it is a mystery.
Obfuscation, or: How I Learned to Stop Worrying and Outsmart the Compiler
When writing eBPF code, one’s greatest enemy is often the compiler’s optimizers. eBPF’s most glaring flaw is that the compiler and the validator have no means to communicate other than through the generated code. Try as you might to write your code in a concise way that would otherwise ensure its correctness, the compiler may simply optimize out all of your “unnecessary” data validation checks, leaving the validator to complain that you are not “properly” validating all of the edge cases. While sometimes, one can get around such occurrences with the volatile keyword, other times it will be necessary to rework the code over and over in an attempt to fool both the compiler and eBPF validator. As noted earlier, we have observed that placing code verbatim within an inline static function would result in certain offending code passing validation. This appeared to be due to the fact that certain assumptions on the “parameters” could no longer be made, preventing the compiler from eliding code required by the validator. However, it is worth noting that because of such blunders within the validator, one’s code must sometimes be implemented suboptimally, which will incur unnecessary performance penalties. We still prefer to accept such specific penalties over configuring BCC to compile eBPF C code with -O0.
Conclusion
While it can be a bit tricky to write anything more than the sorts of very simple eBPF kernel tracing tools currently promoted as BCC reference examples focused on basic system profiling, it is very much possible to use eBPF to develop full-featured tracing tools and tooling. Additionally, though the developer experience has a tendency to be extremely perplexing, it does appear to be actively improving over time, given the lessened need for hacky validator appeasement rituals.
We got our feet wet in the world of eBPF-based kernel tracing by attempting to solve a somewhat niche problem, but the outcome seems promising. Our initial test case for eBPF, unixdump, is open source and available on GitHub; check it out here: https://github.com/nccgroup/ebpf/tree/master/unixdump. We plan to continue to add features and filters to unixdump, and would greatly appreciate any contributions. The next features on the roadmap are proper timestamping, and outputting to pcapng so that one can load Unix domain socket traffic dumps into Wireshark/tshark and apply their vast repertoire of protocol dissectors.
Depending on your OS, Unix domain sockets may be described in
unix(7),unix(4), orsockaddr(3socket).↩︎While Linux enforces file path permissions on file path-based Unix domain sockets, this behavior is not consistent across all Unix implementations. However, in general, Unix OSes have similar sets of APIs enabling Unix domain socket peer processes to verify each other’s identity.↩︎
https://www.kernel.org/doc/Documentation/networking/filter.txt↩︎
