Fridare: repackaging Frida so instrumentation is harder to spot

What the tool does to a Frida build

Fridare is described as an automated repackaging tool for Frida aimed at iOS, Android, Linux and Windows. The README says plainly what it changes: the name, the port and the protocol surface identifiers, in order to lower the hit rate of common environment detection.

That is the whole mechanism, and it is worth being precise about it because the phrase can be read more broadly than it should. Fridare does not exploit anything, does not patch the target application and does not add any capability to Frida. It repackages Frida's own binaries so that the artefacts on the device look different from the ones an application's detection logic is written to look for. The functionality of the instrumentation framework is unchanged; what changes is the surface it presents.

The classical capabilities section of the README lists what the tool does with a version: it automatically downloads and modifies the frida-server, the agent and the gadget of the version you specify, and it lets you set a custom name and port, with arm and arm64 among the supported targets. So the deliverable is a renamed, repointed Frida distribution for a chosen architecture and version.

The project is written in Go, with shell scripts for the automation and a Fyne based graphical interface, and it is MIT licensed. The last push was on 2026-09-11, the repository is not archived, and the release record shows v4.0.8 on 2026-08-13 and v4.0.7 the same day, with the current Frida artefact tagged kxmwp-17.17.1.

The naming convention for the artefacts is itself a signal of what the tool is for. A Frida release is patched under a marker, and the current one uses kxmwp, so the release is distinguishable from the official build at a glance, which is good practice for a tool that ships modified binaries.

Two routes: static patch in seconds, source rebuild in hours

The v4.0.4 release introduced what the README calls the dual technical route, and the table comparing them is the most useful thing in the document.

Route A is the static patch, and it is the default. The GUI offers frida repack, frida-tools repack and iOS DEB handling, it needs no Docker, it takes seconds, and it is meant for the everyday work of renaming, changing the port and keeping the tools aligned with the server.

Route B is the source recompile, which the README calls optional and deep customisation. The GUI entries are source recompile and a one-click deep customisation. The constraint that defines it is that compilation happens only inside Docker on Linux, so the host machine never runs configure or make, and the MinGW cross build produces a Windows server from a Linux host. The cost is hours, and the payoff is deeper hiding, protocol surface synchronisation and the Windows MinGW server.

The Docker-only rule is the interesting engineering decision. Building Frida from source needs a toolchain that is easy to get wrong on a developer machine, and confining it to a container means the host is not modified, the build is reproducible from the image, and the same command produces the same artefact. The README's feature table states it as a property: Docker-only compilation, the host never executes configure or make, and MinGW cross produces the Windows server.

GUI：打开「源码重编译」→ 选 deep →「一键深度定制（①+② deep）」
Host：只跑 GUI / AI 改挂载源码 / docker 客户端
Docker：clone · configure · make（含 MinGW windows-x86_64）
产物：catalog/<ver>/<target>/<magic>/binaries/*-server.exe + python/host wheels + PROTOCOL-SYNC

For someone evaluating the tool, the practical question is which route they need. Most people who want to test an application that blocks Frida need the rename and the port change, and that is seconds of work. The deep route exists for the cases where renaming is not enough, and the README's own release notes are careful to say that neither route makes the tool undetectable.

The paired server and client contract, and the magic marker

The most important technical detail in the whole project is that the server and the client must be patched together, and the README is emphatic about it.

The protocol surface that has to stay in sync is listed as re.{magic}. for the object prefix, /re/{magic}/ for the path, {magic}:rpc for the transport, and the Frida.* API surface. The server and the host client wheel must be paired, with the same magic value, and the object path has to contain /re/{magic}/ rather than only re.frida., because changing only the prefix leaves the client calling a method the server does not know and the result is an UNKNOWN_METHOD error.

The magic value itself is a contract: the README says the modified name is fixed at five lowercase letters from a to z, matching what the hexreplace tool expects. So the whole chain, the static patch, the compiled server, the host tools wheel and the naming, agrees on one five letter token, and getting it wrong produces a connection that fails in a way that is hard to diagnose from the client side.

The v4.0.7 release added stealth switches on the source page, which remove symbols, add obfuscated instructions and change behaviour markers, and the static repack can also strip symbols. The v4.0.8 release fixed the renaming of inject resources, a dependency on the obfuscated instruction feature in ninja, and snapshot handling for the 16.x line, and the GUI path was compiled against both 16.7.19 and 17.17.1.

The version matrix in the repository's documentation is explicit that the 16 and 17 tools cannot be mixed, and there are separate document folders for each, including a comparison document for 16 versus 17. That is the practical shape of the project: it tracks Frida's release cadence closely, and the documentation follows the versions.

The install notes, and the errors they are really about

The installation notes are the most practically useful part of the README for anyone who has actually tried to use a patched Frida, because they are written as symptom to cause.

The host wheels are the first trap. The tools file name has to be a PEP 440 local version with a plus sign in it, and the README gives the exact names, frida_tools-14.10.4+frida.17.17.0.fridare.kxmwp-py3-none-any.whl for the 17 line and frida_tools-13.7.1+frida.16.7.19.fridare.kxmwp-py3-none-any.whl for the 16 line. Writing 14.10.4.frida. instead produces an Invalid wheel filename error, which is filed as issue 36. The old host-wheels.zip is also called out, because the tools file inside it lacks the local version marker and pip refuses to install it.

The second trap is a mismatch between what was patched and what was shipped. The Android kxmwp-server abort with backend_class not equal to null means the helper dex inside the archive is still the old re/frida one while the native side is already re.kxmwp, and the fix is to download the archive for that tag again. The 16.x frida-ps failure with undefined symbol: kxmwp_agent_main has the same shape, and the README explains why: the patch only changes the hash in the agent ELF and renames the GumJS globals to Kxmwp, and it does not write Frida. back into the artefact.

The third is the Java bridge in Frida 17. The frida CLI and frida-trace ship the java bridge, but Python code using session.create_script has to handle frida:load-bridge itself, otherwise the error is Java is not defined. Native Interceptor use is unaffected, and the README points at the version-specific document for the details.

The Windows advice is a separate, very practical section. cmd.exe on a Chinese Windows installation does not read UTF-8, it reads the system code page, so batch files in this repository should contain only ASCII, and they must use CRLF line endings, since some environments fail to parse a batch file saved with LF. The repository's own win/patch-frida.cmd, win/patch-frida-tools.cmd and ui/build.bat are written that way, and there is a self-check script, powershell -File win\test_cmd_ascii.ps1, for verifying a change.

The GUI, the embedded agent and the release pipeline

The interface is a Fyne application, and the feature table lists what it covers: download, repack, tools, DEB, source recompile and settings, plus the one-click deep customisation. The Windows DEB route deserves a note, because the table says it extracts, patches and repacks the package natively without needing WSL, which removes the usual requirement for a Linux environment when working with the iOS package format.

There is also a built-in AI agent with an OpenAI compatible endpoint, a test endpoint connection action, and a proxy setting that does not apply to the endpoint by default but can be enabled. The endpoint is used to drive the repackaging and the source modification, which is a sensible use for it, and the default of not routing the endpoint through the GUI proxy avoids a configuration where the tool cannot reach its own model.

The build system is a Makefile with the version as a variable, VERSION ?= 4.0.4, and the formal output under dist. The targets cover help, clean, build, build-windows-amd64, release, release-all, tools-host, deploy and all, and on Windows the work is done by PowerShell scripts, scripts/build-release.ps1, which the Makefile invokes. The legacy build path is fridaare.sh build -latest, which the help text calls the legacy patch pipeline.

The repository layout matches the product. The hexreplace directory is the static patching tool, toolkit holds the helpers, ui is the Fyne application, win holds the Windows batch scripts and their documentation, scripts holds the release scripts, and docs holds the version documents. There are shell test scripts, test_binary.sh and test_fridare_helpers.sh, a C test program with a Windows binary beside it, and a NOTICE.md file alongside the LICENSE, which is the usual sign of a project that ships third party components.

What the project says about detection, and the boundary it leaves

The release table has a phrase attached to nearly every row, and the phrase is 不是免杀, that is, this is not immunity from detection. It appears on v4.0.8, on v4.0.7 and on the kxmwp artefacts.

That is the most important sentence in the README, and it is worth taking at face value. A renamed binary with a different port and different protocol markers defeats the checks that look for the known strings and the known port. It does not defeat a check that looks at timing behaviour, that inspects the process list for an unusual name, that verifies the integrity of the injected module, or that uses a server-side attestation. The project's own release notes for v4.0.7 mention behaviour markers among the stealth switches, which is an acknowledgement that name and port are the easy part.

The boundary the project leaves is the authorisation one, and it is implicit rather than stated. A tool whose only function is to make an instrumentation framework less visible to the software it instruments has a legitimate use in exactly one situation, which is when you are authorised to test that software and need to work around an anti-instrumentation check to do so. It has no legitimate use against software you have no permission to test, and in that case the modification of the artefacts is what turns an ordinary research tool into an evasion tool.

The project is candid about the first point and silent about the second, which is a gap worth noting rather than repeating. The rest of the surface is ordinary engineering: a fast route and a slow route, a paired server and client contract, a version matrix that follows Frida's releases, and a Windows section that solves a problem most projects would ignore.

There is a community around it, on QQ with the group number in the README, on GitHub issues where the author asks people to file issues before asking in the group, on X, and a GitHub streak badge. The issue-first request is a reasonable convention for a single maintainer, and the release cadence through 2026 suggests the work is ongoing rather than a one-off publication.

Editorial conclusion

Adopt Fridare when you are assessing an application that blocks Frida, since repackaging the server is the standard way to find out whether the block is the only thing standing between you and the runtime, and the project ships both a fast static route and a deeper source rebuild for that case. It is the wrong tool if your goal is to instrument an application you have no authorisation to test, since the tool's only function is to make the instrumentation less visible, and the project itself is careful not to claim otherwise. Before using it, read the release notes for the Frida version you are targeting, because the server and the host tools must be patched with the same marker, and use the static route first, since it takes seconds against the hours the Docker rebuild takes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. suifei/fridare on GitHub