Public preview · Registration and live billing are not open.
Anti-AIClonePILOT

Log date · Wed

Frida 17.18.0: kernel-side and Barebone injected agents

Frida 17.18.0 expanded kernel-side and Barebone agents, a reminder that an app's in-process self-checks may observe from a lower vantage point than the analyst.

What happened on this date

At 2026-09-09T19:25Z (UTC), the frida/frida repository published 17.18.0, and the project's news page carried the release notes the same day. Per those notes, the main changes are: the XNU agent can be built as a macOS kernel extension that communicates through /dev/frida and covers the kernel side only; Barebone injected agents can enumerate processes, attach and run scripts across Linux, XNU and Windows environments; the Linux agent can be injected into a running kernel or loaded as a kernel module; scripts can list loaded kernel modules and symbols and query kernel type information through a new Btf namespace; Frida.Compiler moved to TypeScript 7.0 and gained an LSP-based language service API; and CI enabled Barebone on Android. This entry stays at release-note level and does not cover usage.

Why it matters for protecting app logic

For a cloner, the most realistic scenario is analyzing your app on a device they fully control. As dynamic instrumentation extends toward the kernel, the observer may sit at a lower layer than the app, while the app's in-process self-checks can only see what is visible from their own layer. That does not make runtime detection worthless: it raises cost, stops casual attempts and provides risk signals to the server. But describing it as preventing dynamic analysis is inaccurate. An honest threat model states that on a device the other party controls, client-side logic and data are ultimately observable, and protection serves to raise the cost of understanding and reuse.

Checks you can run

First, write the assumption that the other party controls the device operating system into your threat model, and mark which assets therefore cannot live only on the client. Second, keep decisive rules, keys and pricing logic on the server, and report client-side detection results as signals. Third, on your team's own test devices, include instrumented environments in pre-release regression so you can confirm the app degrades as designed when observed. Fourth, when reviewing a protection product's instrumentation-detection claims, check which tool versions its testing covered. Revisit these points whenever the tooling landscape shifts, not only once.

Your checklist

  • State in the threat model that the other party controls the device OS
  • Keep decisive rules and keys server-side; report client detections as signals
  • Check which tool versions a protection product's claims cover

Primary sources

All sources and reproduction status ↗