Fridare automates renaming and repackaging of frida-server, frida-agent and frida-tools across iOS, Android, Linux and Windows, primarily for authorized mobile security assessments and reverse-engineering labs.
| Tool | suifei/fridare — automated Frida repackaging/modification toolkit with CLI and Fyne GUI, written in Go |
| Category | Dynamic instrumentation / binary patching tooling |
| Primary Use | Renaming, port reconfiguration and protocol-identifier rotation of frida-server, frida-agent, gadget and frida-tools for authorized app analysis and penetration testing on owned devices |
| Safe Use | For authorized penetration tests, mobile app security assessments on devices you own or have written permission to test, and defensive research into how instrumentation frameworks are detected |
| Telemetry Note | Modified binaries still exhibit Frida's behavioral surface — thread creation, ptrace-adjacent activity, GumJS runtime signatures, RPC traffic patterns — so defenders should rely on behavioral detection rather than static string matching; the README itself repeatedly notes the output is 'not AV bypass' |
Fridare occupies a peculiar niche in the mobile security toolchain: it does not exploit anything itself, it repackages the instruments. Written in Go with roughly 923 stars and an MIT license, it automates the modification of frida-server, frida-agent, frida-gadget and the frida-tools Python package so that their well-known identifying strings, names, ports and protocol markers no longer match what stock detection libraries look for. The stated purpose in the README is explicitly framed around authorized reverse engineering and security testing on iOS, Android, Linux and Windows, and the author is unusually candid that the output is, in their own repeated words, not an antivirus-evasion product — a disclaimer repeated on nearly every release entry.
The architecture is what makes this project interesting from an engineering standpoint. Fridare offers two distinct modification tracks. Track A is a fast, static hex-patching route: it performs byte-level replacements on downloaded binaries, renaming identifiers across Mach-O, ELF and PE formats in seconds without any toolchain on the host. Track B is the heavier option: a Docker-contained source recompilation pipeline, tagged deep, which clones Frida's actual source, applies stealth-oriented patches (symbol stripping, what the README calls junk-instruction obfuscation, behavior-marker removal) and rebuilds — a process the author honestly labels as taking hours rather than seconds. Crucially, all configure and make steps run inside the container; the host never executes the build.
The protocol-synchronization problem is where most naive Frida renamers fail, and the README documents this failure mode in detail. Frida's runtime uses a cluster of correlated identifiers: D-Bus-style object paths containing /re/{magic}/, interface prefixes like re.{magic}., RPC channel tags shaped as {magic}:rpc, and the Frida.* API surface. If you rename only the obvious re.frida. strings in the server but leave the client untouched, sessions fail with UNKNOWN_METHOD errors. Fridare's contract is that the server binary and the host-side client wheel must be generated as a matched pair sharing the same five-character lowercase magic name, and it enforces the a-z five-character constraint for consistency with its hex-replacement engine.
The release history is dense with operational hardening detail that reveals real-world iteration. The kxmwp-17.17.1 tag is built from official Frida 17.17.0 sources with a linux-x86_64 deep recompile; kxmwp-16.7.19 covers eight platforms using Android NDK r25 plus host wheels pinned to Frida 16.7.19. The 16.x and 17.x toolchains cannot be mixed, and the README warns about a subtle packaging bug where older Android arm64 zips shipped a helper DEX still referencing re/frida while native code referenced re.kxmwp, causing a backend_class != null abort. There is also a documented undefined symbol: kxmwp_agent_main failure in frida-ps on 16.x, resolved by regenerating patched agent ELFs whose GumJS global was renamed to Kxmwp.
Frida 17 compatibility notes are equally instructive. The frida CLI and frida-trace bundle java-bridge, but Python-driven session.create_script workflows must handle frida:load-bridge manually or scripts hit Java is not defined — native Interceptor usage is unaffected. This is the kind of friction documentation that tells you the maintainer actually uses the tool against real targets in lab conditions, and it is valuable reading for anyone building custom instrumentation pipelines regardless of whether they use Fridare.
The GUI, introduced in v4.0.0 and built on the Fyne framework, bundles three separate binaries: fridare-gui for the main interface, fridare-create for packaging, and fridare-patch for patching. It supports drag-and-drop file handling, live progress and log panes, and a one-click deep-customization button that chains the development-stage renames with the Docker build. The Windows story is notably thorough: v4.0.0 implemented a native deb parsing, modification and repacking pipeline on Windows without WSL, including cross-platform ar and tar.gz handling and preservation of Debian control files and permissions — meaning iOS deb packages can be customized entirely from a Windows workstation.
The README also contains a small essay on Windows batch scripting pitfalls that is worth more attention than it appears to get: on Chinese-locale Windows, cmd.exe interprets .cmd and .bat files using the system code page (typically GBK/CP936), not UTF-8, so non-ASCII characters in batch scripts cause silent parsing corruption and broken if/goto control flow. The repository ships its win/patch-frida.cmd, win/patch-frida-tools.cmd and ui/build.bat scripts in ASCII-only form with CRLF line endings, plus a win/test_cmd_ascii.ps1 self-check. This is a genuine portability lesson for anyone distributing tooling to East Asian Windows environments.
Installation is deliberately simple for the CLI path, and the one-line bootstrap is representative of the project's polish: curl -s https://raw.githubusercontent.com/suifei/fridare/main/fridare.sh | bash -s install. Building the GUI locally requires Go 1.21+, CGO and a native C compiler (MinGW on Windows), via cd ui && ./build.sh; the CLI utilities can be built fully static with CGO_ENABLED=0, and precompiled Windows GUI packages are published on the Releases page for users who do not want a toolchain. That limit of two invocation examples is worth respecting here — the rest of the workflow is GUI-driven or configuration-file driven.
An unexpected component is the built-in AI agent introduced around v4.0.4, which talks to OpenAI-compatible endpoints with a connection-test button and, notably, defaults to bypassing the GUI's configured proxy for those requests. Combined with the Docker-only compilation policy and the seeded MinGW wrap scripts staged into /work, this suggests the author is optimizing for a repeatable, isolated build environment where cross-compilation to windows-x86_64 via x86_64-w64-mingw32 just works.
For defenders, Fridare is more useful as a teaching artifact than a threat. Its existence is a map of exactly which static indicators mobile anti-tampering products over-rely on: process names, the frida-server default port, re.frida. strings, frida:rpc markers, and the GumJS runtime global. The correct defensive posture, which the project's own 'not AV bypass' disclaimers hint at, is behavioral: monitor for dynamic-code page allocations, suspicious thread creation in third-party apps, D-Bus-style RPC over local sockets with nonstandard but structurally valid object paths, and unsigned injected libraries. A repackaged Frida changes its clothes, not its skeleton.
Used within its intended bounds — your own devices, your clients' apps under signed authorization, lab environments for detection research — Fridare removes a tedious, error-prone manual chore from instrumentation workflows. Its documentation quality, dual-track architecture and honest failure-mode records make it worth studying even by practitioners who never run it.
suifei/fridare.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.