GSoC — Rizin: Week 2

Hi again, everyone. This is my second update on rz-frida, the Frida plugin for Rizin I'm building this summer for GSoC 2026.

Last time I’d just finished the foundation, the URI grammar, the session obj, the reply format, the build. I ended that post saying I wanted to “go live” next, actually reach real devices and real processes instead of just parsing strings about them. So that’s what this one is about.

The work here is rz-frida#2, now merged. It takes the session layer from “can describe a target” to “can find, open, drive, and clean up a real one”, across local, USB, and remote.

Going live

The foundation could describe a target but couldn’t touch one. So the first job was wiring the session layer to actual frida-core.

Started with devices. fridad/ fridadj ask the frida device manager for what's connected, local, usb, remote, and list them as JSON. Then the things running on a device: fridap/ fridapj enumerate processes, fridaa/ fridaaj enumerate applications (the apps view is the Android-flavoured one). By default these hit the local device, but you can point them at a phone or a remote frida-server by handing them a frida://list/usb/... or frida://apps/remote/host:port URI, so the same cmd works across transports.

To make that work I had to grow the frida:// grammar from the foundation. It now carries a transport segment ( local, usb, remote) and a device segment that's either empty, a device id, or a host:port. The resolver picks the device by transport: by id for usb, by host:port for remote, by type for local. And it rejects nonsense early, a list or apps URI shouldn't carry a target, but usb is allowed to skip the device id (you usually have just one phone plugged in, atleast this was my case :/).

Then the part I’d actually been waiting for, opening a session. fridao/ fridaoj will attach to a pid or a process name, spawn a target suspended, or launch and immediately resume it. Spawning suspended is the useful one for instrumentation, you get the process frozen at the very start before any of its own code runs. fridar/ fridarj resumes it when you're ready, and fridac/ fridacj closes the session. fridas/ fridasj now also reports the live pid, action, and target while a session is running.

A few small things that I took care of: the backend refuses to open a second session while one’s already active (instead of quietly leaking the first), and on cleanup it kills a target that was spawned-but-never-resumed, rather than leaving a frozen zombie process behind on your device. Little stuff, but it’s the diff b/w a plugin you trust and one you don’t (haha, jk).

Testing this was its own adventure. I’m on WSL2 with my A15 Android, and USB passthrough (usbipd) kept dropping mid-session and wedging frida. After fighting it for a while I switched to wireless adb, adb tcpip on the Windows side, adb connect from WSL, and suddenly it was stable. The first time fridaoj frida://spawn/usb//<some app> actually came back with a real pid and a suspended process on my phone, I felt relieved. The parser I'd written at the very start finally pointed at sth real.

Review

Then my favourite part, review. This PR got a proper pass and I learned a few things.

The biggest one: I had a rz_frida_backend_init that set up the frida runtime, and a reviewer asked, basically, "can this be called more than once? if so you want a ref counter." And ya, it absolutely can, init runs per RzCore, and Cutter can hold several cores open at once, plus plugin reload repeats init/fini in the same process. So a plain init/deinit would let one core tear frida down while another is still using it. I added a refcount, modelled on how rz_cons does it: bump on the first user, actually deinit only on the last release. The kind of thing that's invisible until it bites someone, and much nicer to fix before it ships.

I was also told to move all the doxygen out of the headers and into the .c files. Rizin's convention is fcn docs live above the definition, types stay documented in the header. Easy change, and the headers do read cleaner now.

Then some YAML. My cmd tree lives in a cmd_descs.yaml that gets generated into C, and a few of my description lines were long enough to trip yamllint's 80-col limit. Got pulled up on it and switched those to YAML's long form.

About fridacj, it was asked, reasonably, "why does a close command need JSON output? and btw we end JSON cmds with j." The j convention I'd actually followed, fridac is just the parent in the tree and only fridacj is invokable, so that was a quick clarification with a screenshot. The JSON-for-close bit I pushed back on a little: every o/p returns the same {"ok":...} envelope, and a close can fail (a detach error), so fridaoj → fridarj → fridacj being a consistent JSON flow felt right for anyone scripting the lifecycle. Was agreed upon to keep as it is, pointing out people may want to drive this over rz-pipe, where JSON for every step is actually useful.

Where I’m at

This one’s merged. Device, process, and app enum, the attach/spawn/launch/resume/close lifecycle, all of it across local, USB, and remote, with JSON envelopes, and the live path verified against an actual Android target. Both the frida-enabled and the frida-disabled builds pass every unit suite.

Next week

So now I can reach a process and drive it from the outside, find it, freeze it, resume it, clean up after it. But it’s still a black box I’m poking through a keyhole. The next step is to get inside: inject a script into the target and actually hold a conversation with it, run code, get answers back, stream its output.

Thanks for reading, see you in the next one.

Originally published at http://github.com.