Frida • A world-class dynamic instrumentation toolkit

Frida 17.22.1 Released

2026-10-04T11:35:42+02:00

A bugfix release, with @hsorbo behind most of the fixes, and a new contributor making the C++ bindings a bit more complete.

Memory scans finding themselves

Håvard noticed that a pointer scan on Linux could find the very values it was looking for, in a stack that no thread was using anymore. The workers of a scan spill their search values onto their stacks, and once the pool was freed and its extra workers had exited, glibc kept their stacks around for reuse, with everything above the exiting frame still mapped and readable. After our deferred cleanup had uncloaked them, the next scan happily found its own leftovers. The same goes for anything that ran on the script scheduler’s thread pool.

The fix is to discard what a Gum thread spilled on its stack right as it exits, from the finalize callback that frida-glib runs on the thread itself, before the thread library gets to cache the stack. Other libcs unmap exited stacks outright, so only glibc pays for the extra syscall.

Other fixes

Håvard also fixed two more Linux-related issues. Instrumenting a function again while its last listener’s detach was still pending, which is what GumJS does within its script-wide transaction, could resolve a stale redirect into a trampoline that was then freed along with the old context. The function is now treated as still instrumented, reusing its context when both old and new instrumentation are of the default type, and otherwise deactivating it on the spot. And dlsym() no longer crashes on modules that were pulled in as dependencies by dlopen(), where glibc has yet to compute a local scope for the link map we used as the handle.

Last but not least, @mnalmahmud made it possible to attach probes to arbitrary instructions from the C++ bindings, through a new ProbeListener interface, so that no longer requires dropping down to the C API.

Enjoy!

Changelog

glibc: Discard dead Gum thread stacks on exit, so memory scans no longer find leftovers from the scan workers or the script scheduler’s pool. Thanks for tracking this one down, @hsorbo!
interceptor: Fix re-attach during a pending detach, which could resolve a stale redirect into a trampoline that was then freed. Thanks @hsorbo!
linux: Fix dlsym() crash on modules discovered as dependencies of a dlopen(), by creating the handle on demand with RTLD_NOLOAD. Thanks @hsorbo!
gumpp: Add probe listener support, exposing gum_make_probe_listener() as a ProbeListener interface accepted by Interceptor::attach() and detach(). Thanks @mnalmahmud!
frida-compile: Create the output file’s directory as needed, both in frida-tools and in the npm package. Thanks @fourcels!

Frida 17.22.0 Released

2026-10-03T07:56:25+02:00

Yesterday’s two releases made patterns a first-class citizen for agents and for tools. This one is about sharing them: frida-compile can now build a library, so a package on npm can ship its patterns alongside its TypeScript, and anyone can import it. We also have @hsorbo to thank for the Swift ApiResolver now working on Linux, with Windows support landing right behind it.

Libraries

Say you’ve written a few patterns and some helpers around them, and want to publish them for other agents to use. Up until now that meant running frida-compile once to get the pattern typings, then tsc to emit the package, with a tsconfig.json carefully matched to how Frida.Compiler resolves imports. Two compilers over the same sources is one too many.

With frida-compile –library, Frida.Compiler does the whole job. Here’s lib/index.ts in a package that finds players in a game:

import { Player } from "./patterns/player.hexpat";

export function findPlayers(range: RangeDetails, health: number): Player[] {
    const pattern = Player.pattern({ health });
    return Memory.scanSync(range.base, range.size, pattern)
        .map(({ address }) => Player.at(address));
}

export function describe(player: Player): string {
    const { x, y, z } = player.position;
    return `health=${player.health} lives=${player.lives} at (${x}, ${y}, ${z})`;
}

Next to it sits lib/patterns/player.hexpat:

#pragma abi native

struct Player {
    u32 health;
    u32 lives;
    Vec3 position;
};

struct Vec3 {
    float x;
    float y;
    float z;
};

And that’s all the source there is. The package.json needs no typescript, no @types/frida-gum, and no tsconfig.json, only frida-compile from npm:

{
  "name": "frida-module-example",
  "version": "1.1.0",
  "main": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "files": ["/dist"],
  "type": "module",
  "scripts": {
    "prepare": "frida-compile --library lib/index.ts -o dist"
  },
  "devDependencies": {
    "frida-compile": "^19.1.0"
  }
}

Running that build gives us:

$ frida-compile --library lib/index.ts -o dist
$ find dist -type f | sort
dist/index.d.ts
dist/index.js
dist/index.js.map
dist/patterns/player.hexpat
dist/patterns/player.hexpat.d.ts

One module and one declaration file per source, with the patterns copied alongside and their generated typings next to them. The declarations are exactly what you’d hope for:

import { Player } from "./patterns/player.hexpat";
export declare function findPlayers(range: RangeDetails, health: number): Player[];
export declare function describe(player: Player): string;

Note that the pattern is shipped as source, and not as the JavaScript that Frida.Compiler turns it into. That’s deliberate: the generated code leans on a runtime that the consumer’s build provides and dedupes across packages, the pattern can be imported by other patterns and by tools such as Luma, and the pattern language is a far more stable interface than our emitted code. The consumer’s Frida.Compiler compiles it as part of their build, in milliseconds, and caches the result.

Which brings us to the consumer. After npm install frida-module-example, an agent can use both the helpers and the pattern itself:

import { findPlayers, describe } from "frida-module-example";
import { Player } from "frida-module-example/dist/patterns/player.hexpat";

const arena = Memory.alloc(Player.size * 2);
const alice = Player.at(arena);
alice.health = 100;
alice.lives = 3;
alice.position.z = 1.5;

for (const player of findPlayers({ base: arena, size: Player.size * 2 } as RangeDetails, 100))
  console.log(describe(player));

$ frida -q -p 0 -l agent.ts
health=100 lives=3 at (0, 0, 1.5)

A few more details:

-w keeps the library fresh as you edit, which pairs nicely with npm link while iterating on a package together with an app.
Source maps are emitted next to each module, with the sources inlined, so consumers get real stack traces without you shipping lib/. Pass -S to leave them out.
Errors are reported just like for agents, with paths relative to the project, and nothing is written when there are any:

lib/broken.ts:1:14 - error TS2322: Type 'string' is not assignable to type 'number'.
compilation failed

The output mirrors your source tree under its common directory, so lib/index.ts lands at dist/index.js. If your tsconfig.json sets rootDir, that’s honored instead.
This is Compiler.build_library() and Compiler.watch_library() in frida-core, so it’s available from all of our language bindings, and frida-compile exposes it both in frida-tools and in the npm package.

Swift

The Swift ApiResolver, which learned to find types, protocols and conformances yesterday, was until now only functional on Apple platforms. It looked for libswiftCore.dylib, borrowed free() from libsystem_malloc, and matched metadata sections by their Mach-O names, so on Linux every query failed with “unsupported Swift runtime”.

Håvard fixed all of that: the resolver now names the Swift core library and the metadata sections per platform, takes free() from the C runtime where there is no libsystem_malloc, and keeps its demangler per instance, as on Linux a dlclose() unmaps libswiftCore and a cached pointer could outlive it. He also made our Swift tests actually run on Linux CI, where they had been silently skipping all along, and report skips as skips rather than as passes. Thanks a lot, Håvard!

With that groundwork in place, Windows was a small step: swiftCore.dll, the .sw5* sections, and freeing demangled names through the UCRT. One Windows quirk worth knowing is that swiftrt.obj brackets each metadata section with zeroed start and stop markers, which the resolver now skips. So wherever a Swift runtime is loaded, new ApiResolver(‘swift’) and its functions:, types:, protocols: and conformances: queries now work the same.

EOF

Enjoy!

Changelog

compiler: Add library builds, through Compiler.build_library() and Compiler.watch_library(), exposed as frida-compile –library. (Covered above.)
swift-api-resolver: Add Linux support, naming the Swift core library and metadata sections per platform, and keeping the demangler per resolver instance. Thanks @hsorbo!
swift-api-resolver: Add Windows support, including skipping the zeroed section markers that swiftrt.obj emits.
swift-api-resolver: Find the Swift toolchain in tests, so they run on GitHub’s Ubuntu runners instead of silently skipping. Thanks @hsorbo!
gumjs: Handle every arm64 vector arrangement when parsing instruction operands. Single-lane and narrow arrangements such as v0.b[0] reached an unreachable default, which crashed the process once assertions were compiled out. Thanks @hsorbo!
windows: Fix section names and sizes. Names of exactly eight characters lack a NUL terminator, and sizes are now the virtual size rather than the file-aligned raw size, as the loader sees them.
swift: Regenerate the bindings for library builds.

Frida 17.21.0 Released

2026-10-02T20:28:35+02:00

Two releases in one day? Software is hard, and APIs are harder. But this one is worth it: @hsorbo has taught the Swift ApiResolver to find types, protocols and protocol conformances, and the new PatternCompiler API has been reshaped to work on files, so patterns can import each other on the host side as well.

Swift

Frida’s ApiResolver(‘swift’) has been around for a while, letting you find Swift functions by their demangled names, with globs. Behind the scenes it walks the Swift metadata that the compiler emits into every Swift binary, which is also where the information about types and protocols lives. Håvard has been hacking on this resolver since 2023, and in 17.20.0 he made it work in a lot more processes by demangling through libswiftCore, which is always present when Swift code is running, instead of libswiftDemangle, which typically isn’t.

With that out of the way, this release adds three new kinds of queries. First, types: and protocols: match nominal types and protocols by their full name, giving you the address of the context descriptor:

const resolver = new ApiResolver('swift');

for (const { name, address } of resolver.enumerateMatches('types:*!Swift.Int'))
  console.log(name, address);

for (const { name, address } of resolver.enumerateMatches('protocols:*!Swift.Hashable'))
  console.log(name, address);

/usr/lib/swift/libswiftCore.dylib!Swift.Int 0x19bf8009c
/usr/lib/swift/libswiftCore.dylib!Swift.Hashable 0x19bf7c490

The part before the ! matches the module, like with the other resolvers, so types:*libswiftCore*!Swift.Dictionary* narrows things down to a specific library, and finds nested types as well:

/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary 0x19bf7abe8
/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary.Keys 0x19bf7ac54
/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary.Values 0x19bf7ac90
/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary.Keys.Iterator 0x19bf7accc
/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary.Values.Iterator 0x19bf7ad08

Second, conformances: matches protocol conformances by type and protocol name, giving you the address of the conformance descriptor. This is the one I’m most excited about, as it answers questions like “which protocols does this type implement?”:

for (const { name, address } of resolver.enumerateMatches('conformances:Swift.Int!Swift.*'))
  console.log(name, address);

Swift.Int!Swift.Encodable 0x19bf5f6c4
Swift.Int!Swift.Decodable 0x19bf5f6d4
Swift.Int!Swift.CodingKeyRepresentable 0x19bf5f984
Swift.Int!Swift.CustomReflectable 0x19bf612ec
Swift.Int!Swift._CustomPlaygroundQuickLookable 0x19bf612fc
...

And the other way around, “which types implement this protocol?”, which is where it gets interesting in a big app:

const encodable = resolver.enumerateMatches('conformances:*!Swift.Encodable');
console.log(encodable.length, 'types conform to Encodable');
for (const { name, address } of encodable.slice(0, 3))
  console.log(name, address);

3735 types conform to Encodable
UIIntelligenceSupport.IntelligenceElement.Axis!Swift.Encodable 0x2a5e0a1c8
UIIntelligenceSupport.IntelligenceElement.Image!Swift.Encodable 0x2a5e0a9d0
UIIntelligenceSupport.IntelligenceElement.CustomAppEntity!Swift.Encodable 0x2a5e0b0e8

From the conformance descriptor you can get to the witness table, and from the context descriptor to the type’s metadata, fields and methods. So these are the building blocks for anything that wants to understand a Swift program’s types at runtime, from pretty-printing a value to hooking every type that implements a certain protocol. Expect to see more built on top of them.

He also fixed the /i suffix, which the Swift resolver accepted but didn’t actually honor. Thanks a lot, Håvard, for all the excellent work on this!

PatternCompiler

This morning’s release introduced the PatternCompiler API, which compiles a pattern on the host and decodes memory against it. It took a source string, which seemed convenient, but meant it had no idea where that source lived, so a pattern could not import anything but the std library. That’s fixed now, and the API mirrors Compiler.build(): you hand it a path, and optionally a project root, with the latter inferred from the entrypoint when left out. Say we have proj/player.hexpat, importing a Vec3 from proj/common.pat:

#pragma abi native

import common;

struct Player {
    u32 health;
    Vec3 position;
};

Imports resolve exactly like they do when Frida.Compiler builds an agent: relative to the importing file, then from node_modules. Each type now tells you which file it was declared in, and so does each diagnostic, with paths relative to the project root, the same way build diagnostics are reported:

import frida

module = frida.PatternCompiler().compile("proj/player.hexpat")
for d in module.diagnostics:
    print(f"{d.file}:{d.line + 1}:{d.character + 1}: {d.message}")
for t in module.types:
    print(f"{t.file}: {t.kind} {t.name}, {t.size} bytes")

With a semicolon missing in common.pat, that reports:

proj/common.pat:5:1: expected ;

And once fixed:

proj/common.pat: struct Vec3, 12 bytes
proj/player.hexpat: struct Player, 16 bytes

The language server got the same treatment, so a .hexpat that imports an unsaved buffer in another tab resolves it, and problems stay attributed to the file they’re in. Our Swift bindings have been regenerated accordingly, and the other bindings pick this up automatically.

This is a breaking change to an API that shipped this morning, so hopefully nobody has built anything on it yet. If you have, the migration is to write your pattern to a file and pass its path.

EOF

Enjoy!

Changelog

swift-api-resolver: Add types: and protocols: queries, matching the descriptors in __swift5_types, __swift5_types2 and __swift5_protos by full name. Thanks @hsorbo!
swift-api-resolver: Add conformances: queries, matching __swift5_proto records by type and protocol name. Also make /i take effect. Thanks @hsorbo!
compiler: Compile patterns from files, with imports and includes resolving the way they do in agent builds, and the file of each type and diagnostic named relative to the project root. (Covered above.)
compiler: Fix crash on a relative project root, which took down the whole process from inside the TypeScript compiler’s virtual filesystem.
swift: Regenerate the PatternCompiler bindings.

Frida 17.20.0 Released

2026-10-02T03:11:53+02:00

For as long as Frida has existed, dealing with structs has been one of its weak spots. Say you’ve found a Player struct in a game, and you want to read its lives field. What you’d end up writing is something like:

const lives = player.add(4).readU32();

That magic 4 is an offset you worked out by hand, readU32() is a type you also worked out by hand, and neither is written down anywhere except in that one line. Multiply that by every field of every struct you care about, and you end up with scripts that are brittle, hard to read, and where the layout can’t really be shared with anyone. And if the struct looks different on 32-bit vs. 64-bit, you get to maintain two sets of offsets.

I’ve been pondering this for years. What I really wanted was a typesafe approach, where the TypeScript compiler knows which fields exist and what their types are, so typos get caught at compile time, and the editor can auto-complete field names. It was kind of a given that this would require a codegen step, and that always felt like too much friction to put on users.

But then Frida.Compiler came along. It hasn’t been around since the beginning, but now that it’s here, powering frida-compile, the REPL, and tools like Luma, that codegen step can be made entirely invisible. So that’s what this release is about.

Patterns

Rather than inventing yet another struct description language, we’ve adopted the pattern language from ImHex. It’s a C-like language for describing binary data, originally created for ImHex’s hex editor, with structs, unions, enums, bitfields, pointers, conditionals, dynamically sized arrays, and a standard library. There’s an ImHex-Patterns repository full of patterns for common file formats, and the language has since been adopted elsewhere, too: x64dbg supports it through the DataExplorer plugin, and radare2 through r2hexpat. So chances are you’ll find existing patterns you can reuse, and the patterns you write for Frida are useful in those tools as well.

Frida 17.20.0 implements this language in Frida.Compiler, in Go, right next to the TypeScript compiler. Let’s take it for a spin. Here’s game.hexpat:

#pragma abi native

struct Player {
    u32 health;
    u32 lives;
    Role role;
    Vec3 position;
    Player* next;
};

struct Vec3 {
    float x;
    float y;
    float z;
};

enum Role : u8 {
    Warrior,
    Mage,
    Rogue,
};

If you’ve written a C struct you already know how to read this. The one thing that stands out is #pragma abi native, which we’ll get back to in a moment.

From agent.ts we then import the pattern as if it were any other module:

import { Player, Role } from "./game.hexpat";

const roster = Memory.alloc(Player.size * 3);

const alice = Player.at(roster);
alice.health = 100;
alice.lives = 3;
alice.role = Role.Mage;
alice.position.x = 1.5;
alice.position.y = -2;
alice.position.z = 3;

const bob = Player.at(roster.add(Player.size));
bob.health = 42;
bob.lives = 1;
bob.role = Role.Warrior;
alice.next = bob;

const carol = Player.at(roster.add(Player.size * 2));
carol.health = 100;
carol.lives = 3;
carol.role = Role.Rogue;
bob.next = carol;

console.log("Player.size:", Player.size);
console.log(JSON.stringify(alice, null, 2));
console.log("alice.next.next.role:", Role[alice.next!.next!.role]);

In a real-world scenario the game would obviously own these structs, and we’d have found them through Interceptor, memory scanning, or similar. But to keep the example self-contained we allocate three of them ourselves.

Let’s run it:

$ frida -q -p 0 -l agent.ts
Compiling agent.ts...
Compiled agent.ts (20 ms)
Player.size: 32
{
  "health": 100,
  "lives": 3,
  "role": 1,
  "position": {
    "x": 1.5,
    "y": -2,
    "z": 3
  },
  "next": "0x140cb5bc0"
}
alice.next.next.role: Rogue

A few things to note here:

Each struct becomes a class. Player.at(address) gives you a live view of the memory at that address, where each property reads or writes the underlying memory directly. Nothing is copied, so what you see is always what’s in memory right now.
Nested structs like position are views too, and pointer fields like next give you a view of the pointee, or null. Assigning to a pointer field accepts either a view or a NativePointer.
Enums become objects with a reverse mapping, so Role[alice.role] gives you “Mage”.
Player.size is the struct’s size in bytes, and JSON.stringify() just works.
Nothing was compiled ahead of time. The REPL handed agent.ts to Frida.Compiler, which spotted the .hexpat import, compiled the pattern to JavaScript, and bundled it with the agent. The same happens if you run frida-compile agent.ts -o _agent.js, where the resulting bundle is self-contained and can be loaded by any of our bindings.

Native layout

Since the pattern language was designed for file formats, ImHex lays out structs packed, with no padding between fields, as that is what file formats usually look like. Frida on the other hand needs to deal with in-memory structs as well, as laid out by a C compiler, and those are padded to natural alignment. That’s where #pragma abi native comes in. It only exists in Frida’s dialect of the language, and tells the compiler to lay out structs the way the target’s C compiler would. In the example above, role is a single byte, followed by three bytes of padding so that position ends up 4-byte aligned, and next ends up 8-byte aligned on a 64-bit process. Hence Player.size being 32 rather than 25. Leave the pragma out and you get ImHex’s packed layout, which is what you want when decoding a file format that happens to be mapped into memory.

The generated JavaScript also takes the target’s ABI into account. Pointer fields such as next are 8 bytes on a 64-bit process and 4 bytes on a 32-bit one, which shifts the offsets of everything after them, and the alignment rules differ between e.g. 32-bit Windows and 32-bit Linux. Frida.Compiler computes the layouts for all of these at compile time, and the generated code picks the right one at runtime based on the process it ends up in. So a single compiled agent supports any target Frida supports, with no per-architecture offsets to maintain.

Type-safety

This is the part that I’m most excited about. When Frida.Compiler loads a .hexpat, it also generates TypeScript declarations for it, written next to the pattern as game.hexpat.d.ts:

export declare class Player {
    constructor(address: NativePointer);
    static at(address: NativePointer): Player;
    static readonly size: number;
    static pattern(fields: Player.Fields): string;
    static parse(address: NativePointer, size?: number): Player.Parsed;
    readonly $address: NativePointer;
    readonly $size: number;
    health: number;
    lives: number;
    role: Role;
    readonly position: Vec3;
    get next(): Player | null;
    set next(value: Player | NativePointer | null);
    toJSON(): Player.Values;
}

This means the TypeScript compiler knows exactly which fields are available and what their types are. Misspell a field and you get a compile error. Your editor auto-completes field names. Add a char name[16] to the struct and it shows up as a read-only string, and the compiler will tell you if you try to assign to it. (As it told me while writing this post.) Mistakes in the pattern itself are reported with file and line, just like TypeScript errors:

$ frida-compile agent.ts -o _agent.js
game.hexpat:5:5 - error TS-1: unknown type Badge
compilation failed

You may want to add *.hexpat.d.ts to your .gitignore, as these get regenerated on every build.

Scanning

Now for the part that makes this feel like magic. Say we’re looking for a Player with full health and three lives, but we have no idea where in memory it might be. Each generated class has a static pattern() method that takes a subset of the fields and produces a match pattern for Memory.scan(), with the fields you leave out wildcarded:

const pattern = Player.pattern({ health: 100, lives: 3 });
console.log("pattern:", pattern);

for (const { address } of Memory.scanSync(roster, Player.size * 3, pattern)) {
  const p = Player.at(address);
  console.log(`${address}: ${Role[p.role]} with ${p.lives} lives`);
}

Which gives us:

pattern: 64 00 00 00 03 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
0x140cb5ba0: Mage with 3 lives
0x140cb5be0: Rogue with 3 lives

Endianness, field offsets, padding: all taken care of. In a real game you’d scan the heap ranges from Process.enumerateRanges(‘rw-‘) instead of our little roster, and perhaps throw in an enum value or a nested field to narrow things down, e.g. Player.pattern({ role: Role.Rogue, position: { z: 3 } }).

Beyond the view

The live view covers structs that are plain data, which is most of what you’ll run into inside a process. But the pattern language can do a lot more: arrays sized by earlier fields, conditionals, pointers with custom bases, locals, functions, attributes like [[format]] and [[color]], the std library, and so on. For those there’s parse(), which decodes a snapshot of the memory with the full ImHex semantics. Let’s try it on something every process on macOS and iOS has: the Mach-O header of its main executable. We’ll put this in macho.hexpat:

#pragma endian little

struct MachO {
    MachHeader header;
    LoadCommand commands[header.ncmds];
};

struct MachHeader {
    u32 magic [[color("FF8800")]];
    CpuType cputype;
    u32 cpusubtype;
    FileType filetype;
    u32 ncmds;
    u32 sizeofcmds;
    u32 flags;
    u32 reserved;
};

struct LoadCommand {
    u32 cmd;
    u32 cmdsize;
    u8 payload[cmdsize - 8] [[sealed]];
};

enum CpuType : u32 {
    X86_64 = 0x01000007,
    ARM64 = 0x0100000C,
};

enum FileType : u32 {
    Object = 1,
    Execute = 2,
    Dylib = 6,
};

MachO macho @ 0x00;

Note the lack of #pragma abi native here, as this is a file format. Also note the placement at the end, which is how ImHex patterns typically declare what’s at the start of the file. In our case the “file” is a chunk of memory, and a pattern with placements gives us a parse() export that decodes them:

import { parse, MachHeader, CpuType, FileType } from "./macho.hexpat";

const base = Process.mainModule.base;

const header = MachHeader.at(base);
console.log("magic:", header.magic.toString(16), CpuType[header.cputype],
    FileType[header.filetype]);
console.log("ncmds:", header.ncmds);

const image = parse(base, 4096).macho;
console.log("commands:", image.commands.length);
for (const cmd of image.commands.slice(0, 3)) {
  console.log(`  cmd=0x${cmd.cmd.toString(16)} cmdsize=${cmd.cmdsize}`,
      `@ ${cmd.$address}`);
}

$ frida -q -p 0 -l macho.ts
Compiling macho.ts...
Compiled macho.ts (19 ms)
magic: feedfacf ARM64 Execute
ncmds: 20
commands: 20
  cmd=0x19 cmdsize=72 @ 0x102a64020
  cmd=0x19 cmdsize=312 @ 0x102a64068
  cmd=0x19 cmdsize=152 @ 0x102a641a0

The second argument to parse() bounds how much memory it may read, which is a good idea when a pattern’s arrays are sized by data you don’t fully trust yet. The result is a tree of plain values, with $address and $size on each struct, so you know where every piece came from. And MachHeader.at() still works alongside it, as a live view, since that struct is plain data.

Patterns can import other patterns, with imports resolved relative to the importing file, and then from node_modules, so patterns can be published as npm packages. The std library is built in, so import std.mem; just works. We run the ImHex-Patterns corpus as part of our test-suite, and 303 of its 312 patterns compile as-is, with the rest depending on ImHex itself, or failing there too. Visualizers, i.e. hex::visualize(), are evaluated by the host-side API covered next, and ignored inside agents.

PatternCompiler

Frida.Compiler takes care of agents, but tools built on top of Frida often want to decode memory on the host side, without injecting any pattern code into the target. For that there’s a new PatternCompiler API in frida-core, which the auto-generated bindings, i.e. frida-python, frida-node and frida-swift, pick up automatically. You hand it a pattern source, and it hands you a PatternModule that describes the types the pattern declares, and that can decode a chunk of bytes against any of them. Let’s use it from Python to decode the same Mach-O header we looked at above:

from pathlib import Path

import frida

session = frida.attach(0)
script = session.create_script("""
rpc.exports = {
  mainModule() {
    const { base, name } = Process.mainModule;
    return [name, base.toString()];
  },
  read(address, size) {
    return ptr(address).readByteArray(size);
  },
};
""")
script.load()

name, base = script.exports_sync.main_module()
base = int(base, 16)
data = script.exports_sync.read(base, 4096)

module = frida.PatternCompiler().compile(Path("macho.hexpat").read_text(),
                                         platform="darwin", arch="arm64")
assert len(module.diagnostics) == 0

macho = module.decode("MachO", data, base)
header = macho.fields[0]
print(f"{name} @ {macho.address:#x}")
for field in header.fields:
    print(f"  {field.name:<11} {field.type_name:<10} "
          f"{field.label or field.value!s:<10} {field.color or ''}")
commands = macho.fields[1]
print(f"  {commands.name}: {commands.count} load commands, "
      f"{commands.size} bytes")

$ python3 decode.py
Python @ 0x104ec0000
  magic       le u32     4277009103 FF8800
  cputype     CpuType    ARM64
  cpusubtype  le u32     0
  filetype    FileType   Execute
  ncmds       le u32     20
  sizeofcmds  le u32     1232
  flags       le u32     2097285
  reserved    le u32     0
  commands: 20 load commands, 1232 bytes

The decoded tree carries everything a UI needs: the address, offset and size of each value, enum labels, [[format]] output, [[comment]], [[color]], and any visualizer the pattern attached to it, along with the visualizer’s evaluated arguments. Rendering is up to the tool. The module also describes the declared types, with their fields, offsets and sizes, so you can build a type browser without decoding anything. Patterns may declare in variables, which you supply by name when decoding, and if a pattern attaches a button visualizer, call_function() lets you press it. Compile errors don’t throw. They end up in diagnostics, with line and column, so they can be shown in an editor.

Speaking of editors: the Frida.LanguageServer API introduced in 17.18.0 now serves .hexpat and .pat documents as well, with diagnostics, completion, hover, document symbols, folding ranges, semantic tokens, go-to-definition, and color swatches for [[color]] attributes. Completion knows about the std library and the visualizer names. And when you’re writing a TypeScript agent that imports a pattern, completion of its fields comes for free through the generated declarations.

Luma

All of this is already put to use in Luma, the official Frida GUI, as of its upcoming release. Luma gains a Patterns section in the sidebar, where patterns and shared libraries live, with an editor backed by the language server:

Each file expands to show the types it declares, so you can jump straight to a struct. Hex views, whether from a memory insight or a REPL hexdump, get a “Decode at … as…” context menu, listing the types from your pattern library. Pick one and the bytes light up with a colored outline per field, with a tree next to it showing names, types and values. Clicking a byte selects the field it belongs to, and selecting a field scrolls the hex view to it. Here’s a Mach-O header decoded straight out of a running process:

The visualizers are where it gets really fun. The pattern language lets you attach a visualizer to a field, such as an image, a line plot, a 3D model, coordinates on a map, audio samples, a timestamp, a bitfield as a digital signal, or a disassembly, and Luma renders them:

And because Luma’s REPL, custom instruments and tracer hooks are all compiled through Frida.Compiler, they get the same treatment as the agent we wrote above: import a pattern, and you get live views, pattern() for scanning, parse() for the full language, and completion of the fields while typing.

EOF

There’s also a bunch of other changes in this release, so definitely check out the changelog below.

Enjoy!

Changelog

compiler: Add ImHex pattern language support. (Covered extensively above.)
gumjs: Let NativePointer reads and writes take an optional offset, e.g. p.readU32(4), so a field can be accessed without allocating a NativePointer for its address. This is also what the generated pattern views use under the hood.
gumjs: Return the pointer from writeVolatile(), for consistency with the other writers.
api-resolver: Descend the Darwin export trie when an exports query is a literal prefix followed by a trailing wildcard, such as exports:*!pthread_*, instead of enumerating every export of every matching module. With 676 modules loaded, 243 such queries went from 35 s to 65 ms. Thanks @hsorbo!
swift-api-resolver: Demangle using swift_demangle() from libswiftCore, which is always present in Swift processes, instead of libswiftDemangle, which typically isn’t loaded. Also resolve it lazily, so the resolver starts working once libswiftCore gets loaded. Thanks @hsorbo!
arm64: Bound the relocator’s reachability scan. Its 1024-byte budget was reset for each block, so the scan would follow branch targets without limit, which on Android made hooking branchy code cost hundreds of milliseconds per target.
exceptor: Stop saving the signal mask on each try, which cost a syscall per attempt and wasn’t needed.
payload: Fix Android agents crashing on load, caused by the module registry reading /proc/self/auxv before the libc shim had set up its stdio registries.
barebone: Make the macOS Android emulator a first-class target. The shim has been rewritten as a CModule so the hot path runs lock-free, all cores are resumed, registers are pushed straight to the vcpu, trapped debug-register accesses are handled instead of aborting the VM, and idle scheduler hits are filtered natively. Apps can also be enumerated and spawned.
barebone: Inject the agent into SMP arm64 Linux, report thread state and registers on Linux, name Linux processes by their cmdline, and keep the arm64 copy off huge pages.
linux-kernel-image: Mine kallsyms from 32-bit kernels and arm64 kernels with VA_BITS=48, including Rust symbol names longer than 80 characters.
barebone: Fix the build without the Droidy backend, and the 32-bit Arm build.
base: Keep Posix types out of the API, so consumers of frida-base no longer need posix.vapi.
compiler: Prefer UCRT64 when building with cgo on Windows, probing for the MinGW compiler per flavor.
node: Escape reserved words in parameter names, and zero GValues of options constructed from objects.
python: Marshal null variants as None.
swift: Bind the pattern compiler types, as well as variants, lists and dictionaries. Release owned return values, and declare out params with their C type so UInt64 out params compile on LP64 Linux.

Frida 17.19.0 Released

2026-09-25T13:15:55+02:00

This release brings Frida to the PlayStation 5, expands Barebone’s reach across virtual machines and kernels, and fixes a range of injection and instrumentation issues.

prospero: Add a PS5 backend and ship builds of frida-server, portal, inject, Gadget, and the devkits. The backend can enumerate apps, spawn programs and apps, and inject agents within the console’s restrictions.
barebone: Add support for the Android emulator. Kernel symbol discovery now handles more Linux images and older kernels, while new hostlink options include pipe-over-vsock and serial connections.
barebone: Extend WinNT support to arm64, including process injection, and add support for VirtualBox and Parallels guests. Numerous fixes improve agent reliability across Windows and Linux kernels.
device: Add connection-progress events, so applications can show what Frida is doing while a device connects or a Barebone agent is uploaded. The new signals are also available in the bindings.
fruity: Fix RSD port discovery on macOS 27 and refresh the service snapshot when a newly published service is not found. A new force_transport=usbmux channel option lets callers choose usbmux even when a tunnel is available. Thanks to @mrmacete for the option.
darwin: Fix an iOS 27 injection leak that could retain a 40 MB agent blob after each attach. Also improve memory protection handling and preserve suspension across policy softening. Thanks to @jiska for these fixes.
gum: Improve arm64 relocation and Interceptor handling of function prologues, including cases where X16 and X17 are both in use. Grafting now uses Arm64Relocator, allowing PC-relative instructions to be relocated. Thanks to @jiska and @daniillnull for their work here.
interceptor: Track the C stack associated with each frame, improving handling of stackful coroutines. Thanks to @wertyutreethgfd for the contribution.
linux: Reclaim temporary stack and TLS mappings after kernel-assisted injection, and release the loader region when an agent unloads. Validate auxiliary-vector program headers before reading them, fixing a problem exposed by Wine’s preloader. Thanks to @tntljc for the latter fix.
socket: Handle a peer disconnecting between the WebSocket handshake and connection acceptance instead of aborting the process. Thanks to @it4ch1-007 for the fix.
darwin: Use jailbreak-provided memory hooks when available. Thanks to @devnoname120 for the contribution.
gdb: Improve thread selection, timeouts, stop handling, and compatibility with stubs that do not support binary writes.

There are also fixes for Windows unwinding through Interceptor trampolines, Swift event delivery and variant lifetimes, generated bindings, and a variety of platform-specific build issues.

Frida 17.18.0 Released

2026-09-09T20:37:30+02:00

Frida 17.18.0 is here, and Barebone takes a big step forward. Our XNU agent can now be loaded as a macOS kernel extension, Linux agent gains broader architecture support and access to the kernel’s own type information, and the backend can instrument both the kernel itself as well as user mode processes across Linux, XNU, Windows NT, and even Windows 9x. We have also upgraded Frida.Compiler to TypeScript 7.0 and added a new Frida.LanguageServer API alongside it.

One of the exciting additions is the ability to build the XNU agent as a .kext. Previously, getting it into the kernel meant injecting it from the outside through a GDB-compatible remote stub, such as QEMU’s, or through a hardware debugger using JTAG/SWD. Now macOS can load the agent itself, and /dev/frida provides the channel for configuring and communicating with it. This opens up another way to use Frida for kernel instrumentation. The kext currently supports the kernel side; placing agent copies into user processes still requires the injected XNU agent.

There is a lot more to Barebone in this release. The injected agents now bring familiar Frida workflows into guest processes: enumerate them, attach, run scripts, hook functions, and spawn programs with instrumentation in place before they start running. This work spans Linux, XNU, Windows NT in both word sizes, and 32-bit Windows 9x. Linux agent injection now covers x86, x86-64, Arm, and Arm64, and the Linux agent can be injected into a running kernel as well as loaded as a kernel module.

On Linux, scripts can now discover loaded kernel modules and their symbols, with the module registry tracking drivers as they come and go. The new Btf namespace also lets scripts query the kernel’s BTF type information, where available. Structure sizes, field offsets and types, enums, constants, and function signatures are available directly from JavaScript. For example:

if (Btf.available) {
  const module = Btf.getStruct('module');
  console.log('struct module size:', module.size);
  console.log('name offset:', module.getOffsetOf('name'));
  console.log('name field:', JSON.stringify(module.fields.name));
  console.log('MODULE_STATE_LIVE:', Btf.getConstant('MODULE_STATE_LIVE'));
}

This means scripts can ask the kernel how its structures are laid out, avoiding hard-coded offsets tied to a particular build. Underneath it is a new GumJS native API registry, which lets embedders expose namespaces of native functions independently of the JavaScript runtime in use.

Meanwhile, Frida.Compiler has been upgraded to TypeScript 7.0. The new Frida.LanguageServer API brings the same compiler’s language services to tools embedding Frida. It speaks the Language Server Protocol for TypeScript and JavaScript projects: create a server for a project directory, start it, send JSON-RPC messages through post(), and receive replies and notifications through its message signal. This makes it possible to integrate editor features such as completion with Frida’s bundled typings and compiler configuration. The compiler and language server also share a parse cache, so the same file contents do not have to be parsed separately for each.

Other highlights and fixes:

barebone: Add public APIs for adding and removing Barebone devices, with caller-supplied IDs, names, and icons. Expose configuration for injected and resident agents, including explicit hostlink addresses.
barebone: Add process spawning and spawn gating across the Linux, XNU, and Windows agents, plus application enumeration on XNU and Windows and application launching on XNU.
barebone: Improve module and thread observation, fault recovery, process cleanup, and cloaking of the agent’s own threads and mappings.
barebone: Improve transport delivery and wakeups across the agents, including large messages and binary script-message payloads. Keep resident agents alive when a session detaches.
barebone: Add XNU kernel text patching through writable aliases, and improve code allocation and pointer authentication at the kernel boundary.
barebone: Expose Linux kernel-module symbols from kallsyms and export tables, and unregister APIs and module observers during teardown.
barebone: Move Linux memory operations into the guest, with proper handling of writable and executable mappings. Extend remapping and patching across x86, x86-64, Arm, and Arm64.
barebone: Halt the guest while accessing QEMU’s physical-memory mode, and fix kernel text patches being silently dropped when shadow pages originated in Linux’s linear map.
barebone: Place x86 aliases in kernel space, fixing CModules faulting when accessing their data. Allow virtual-memory scans to span multiple leaf tables.
barebone: Add Arm address translation and kernel-space aliases, widen page addresses in 32-bit remapping requests, and flush Arm instruction caches directly instead of attempting a userspace syscall from the kernel.
barebone: Report the actual stack space available to the JavaScript runtime, preventing ordinary script recursion from overflowing a Linux kernel stack.
barebone: Size the Linux kernel using _end, avoiding unrelated mappings that could make a 32-bit kernel appear gigabytes larger. Read copied kernel images through GumElfModule without dereferencing pointers into the live kernel.
barebone: Fix and complete the Linux kernel-module build, including constructor array boundaries and flavor-specific runtime dependencies.
linux: Add kernel-assisted injection when the Frida kernel module is loaded, falling back to the existing injection paths when it is absent.
gdb: Use binary packets for memory writes and honor the target’s register sizes.
interceptor: Fix Arm trampoline addressing when writable and executable views use different mappings.
memory: Skip bad pages when finding pointers. Thanks @IPMegladon!
memory: Allow wildcards at scan pattern edges, including in Barebone. Thanks @Xoffio!
arm64: Avoid BTI where no landing pad is available. Thanks @inforcqb!
arm64: Detect branches into the instructions being relocated, so Interceptor can choose a smaller redirect instead of branching into overwritten code and crashing. Thanks @WHW0x455!
cmodule: Move CModule from GumJS into Gum, making it available independently of the JavaScript bindings. Thanks @cputnam-a11y!
elf-module: Read program headers from the file, fixing modules whose headers have been moved by tools such as patchelf. Bound the fallback read when only a live mapping is available. Thanks @tracyliving!
windows: Tweak ACLs to improve injection success rate. Thanks @jamiechapmanbrn!
python: Fix typing imports on Python versions older than 3.11.
ci: Build the XNU kernel extension, additional Linux agents, and the required Barebone SDKs and devkits. Enable the Barebone backend on Android.
deps: Slim down Capstone in Barebone SDKs, reducing its archive from roughly 29 MB to 4.4 MB. Let freestanding GLib builds use the C library’s smaller printf implementation, and trim locale and filename-conversion support.
deps: Optimize QuickJS to reduce its stack consumption, and tweak GLib to reduce our footprint in Barebone scenarios.

Frida 17.17.0 Released

2026-08-05T00:47:29+02:00

This is a big release with lots of bare-metal goodness. The Barebone agent— written in Rust and embedding the GumJS devkit—previously supported only XNU. It can now also run in the Linux kernel, where a small C shim provides the kernel glue.

The agent is packaged as a .ko: load it with insmod, then exchange length-prefixed GVariant messages through /dev/frida. Configure the Barebone backend to use this transport, and run frida-server --device=barebone on the device. Here it is running on my Pixel 6 Pro:

Build the module for your device

The release page has a GumJS devkit for the none-arm64-softfloat target. You do not have to build Gum yourself. The steps below make a frida-agent.ko for a Pixel 6 Pro. Other arm64 Linux systems use the same steps with a different kernel.

Do the build on an x86-64 Linux host. The kernel build tree contains x86-64 programs.

Install the tools:

sudo apt-get install build-essential clang binutils-aarch64-linux-gnu
rustup target add aarch64-unknown-none
rustup component add rust-src

Your clang must be version 19 or newer. GCC does not implement the soft-float ABI.

Download the source:

git clone --recurse-submodules https://github.com/frida/frida-core.git
cd frida-core

Download the devkit:

version=17.17.0
base=https://github.com/frida/frida/releases/download/$version
curl -LO $base/frida-gumjs-devkit-$version-none-arm64-softfloat.tar.xz
mkdir -p ~/gumjs-devkit
tar -C ~/gumjs-devkit -xf frida-gumjs-devkit-$version-none-arm64-softfloat.tar.xz

Download the SDK:
```
releng/deps.py sync sdk none-arm64-softfloat_nopic ~/sdk-none-arm64-softfloat_nopic
```
The SDK contains picolibc and the compiler-rt builtins. The devkit needs them.
Read the kernel version from the device:
```
adb shell uname -r
6.1.145-android14-11-gc1de4747ac59-ab14219743
```
The name ends with the GKI commit and the build number. Here the commit is c1de4747ac59. The build number is 14219743.

Download the kernel files:

commit=c1de4747ac59
build=14219743
ci=https://ci.android.com/builds/submitted/$build/kernel_aarch64/latest/raw
mkdir -p ~/kernel-prepared ~/kernel-source
curl -sSL $ci/modules_prepare_outdir.tar.gz | tar -xz -C ~/kernel-prepared
curl -sSL $ci/kernel_aarch64_Module.symvers -o ~/kernel-prepared/Module.symvers
curl -sSL https://android.googlesource.com/kernel/common/+archive/$commit.tar.gz \
    | tar -xz -C ~/kernel-source

Build the module:

make -C src/barebone/agent/linux \
    FRIDA_SDK=$HOME/sdk-none-arm64-softfloat_nopic \
    GUMJS_DEVKIT_DIR=$HOME/gumjs-devkit \
    AGENT_LD=aarch64-linux-gnu-ld \
    AGENT_AR=aarch64-linux-gnu-ar \
    AGENT_NM=aarch64-linux-gnu-nm \
    AGENT_OBJCOPY=aarch64-linux-gnu-objcopy \
    KDIR=$HOME/kernel-source \
    KOUT=$HOME/kernel-prepared \
    LLVM=1

Load the module:

adb push src/barebone/agent/linux/frida-agent.ko /data/local/tmp/
adb shell su -c 'insmod /data/local/tmp/frida-agent.ko'

The module loads only on the kernel build that you made it for. The kernel compares the version string exactly. A different build of the same kernel branch does not work.

For more information, read the module README.

Full changelog:

gumjs: Fix a detach hang when a native fault inside JS is recovered by a later handler. We now rebalance the Interceptor transaction when the thread survives, instead of ending it twice. Kudos to @pandasauce for reporting the issue and helping track it down.
arm64: Detect branches into the range being relocated, preventing Interceptor from rewriting a branch so that it lands in the middle of its own redirect patch. Thanks to @WHW0x455 for this fix.
python: Fix the linker_notifier_offsets keyword argument to attach(), restore the default port for Script.enable_debugger(), and reinstate marshalling of certificate options for remote devices and related APIs.
barebone: Add support for running the agent as a Linux kernel module. The agent now starts inside the target as a .ko, exposes a character device for transport, and can be reached through a regular frida-server --device=barebone instance.
deps: Add a soft-float bare-metal SDK comprising picolibc and compiler-rt. This gives the none-arm64-softfloat flavour a libc and runtime that agree on passing floating-point values through general-purpose registers.
deps: Build the soft-float SDK in CI, check for published bundles before spending time installing a toolchain, keep libc headers out of devkit headers, use the SDK as the sysroot, and ensure configure-time link checks resolve libc correctly.
deps: Bump GLib, libffi, and QuickJS for freestanding fixes, vector assembler directive fixes, the precedence-climbing parser, and the corresponding x18 fix.
arm64: Avoid FP and SIMD code on soft-float targets by using scalar fallbacks for memcpy, pointer scanning, and Interceptor’s register shuffling.
gumjs: Bound the QuickJS stack on bare metal, re-enabling its stack check so the parser stops before exhausting the small stacks such hosts may provide.

Frida 17.16.4 Released

2026-07-22T00:30:23+02:00

Quick bug-fix release to restore some Python binding API and typing surface area that regressed in the recent bindgen rewrite:

bindgen: Restore the remaining public names. The cancellable decorator, RPCResult, make_rpc_call_request(), make_auth_callback(), and ScriptExportsAsync are now exposed again from frida.core.
bindgen: Generate signal callback overloads for the facade’s on()/off() helpers. This means malformed signal handlers should now be caught by type checkers instead of silently passing as any callable.
bindgen: Restore missing facade members omitted by the .gir-based generator: get_device(), get_device_matching(), enumerate_devices(), shutdown(), Cancellable.connect(), and Cancellable.disconnect().
bindgen: Restore the facade typing surface. The generated package once again ships the expected type aliases and annotations, including module functions, read-only options properties, and the _frida.pyi entries that went missing.

Frida 17.16.3 Released

2026-07-20T17:56:10+02:00

Another quick bug-fix release, addressing two issues in the Python bindings:

bindgen: Fixed marshalling of option keyword arguments. None values are now omitted instead of being passed to typed setters.
bindgen: Fixed collection-valued keyword arguments by mapping them to the appropriate select_ or add_ methods while traversing the parent chain. This affects specs, omits, externals, PIDs, and identifiers.

Frida 17.16.2 Released

2026-07-19T22:25:34+02:00

Another quick bug-fix release, fixing an issue where frida-helper on Darwin and Linux kept the embedder’s stdio pipes open.

The helper previously inherited these streams at launch so they could later be used by Device#spawn() with stdio='inherit'. The streams are now passed to the helper with each such request instead.

darwin: Redirect the helper’s own stdin, stdout, and stderr to /dev/null.
linux: Apply the same fix as on Darwin.