# RMS (Runtime Mobile Security): a Frida web console for Android and iOS apps

> Runtime Mobile Security wraps Frida in a browser UI so you can list loaded classes, hook methods and trace arguments on a running Android or iOS app. It is a hands-on tool for reverse engineers, and it expects one device, a working frida-server and Chrome.

**m0bilesecurity/RMS-Runtime-Mobile-Security** — Runtime Mobile Security (RMS) 📱🔥  - is a powerful web interface that helps you to manipulate Android and iOS Apps at Runtime

- Repository: https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security
- Website: https://twitter.com/mobilesecurity_
- Stars: 3,098 · Forks: 413
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/m0bilesecurity-rms-runtime-mobile-security

## The gap RMS fills between frida-server and a REPL

Frida gives you a scripting runtime inside a running app, but the raw workflow is a REPL and a pile of JavaScript. RMS puts a web interface on top of that runtime. The README describes it as "a powerful web interface that helps you to manipulate Android and iOS Apps at Runtime", and the operations it names are concrete: dump all loaded classes and their methods, hook methods on the fly, trace method arguments and return values, and load custom scripts.

The audience is narrow and technical. This is for mobile reverse engineers and penetration testers who already have a jailbroken iPhone or a rooted Android device, who know what a class dump is, and who want to click through a method list instead of writing a new Frida script for every question. It is not an end-user security product, and it is not a scanner that produces a report. The README points to tutorial videos on solving the OWASP UnCrackable Android App Level 1 and Level 2 challenges, which is the clearest statement of intended use: teaching and doing manual runtime analysis.

If your job is to hand a PDF to a compliance officer, RMS is the wrong shape of tool. If your job is to find out what a method returns when you pass it a malformed string, it removes a lot of boilerplate.

## How the Node process, the Frida agent and the browser fit together

Three pieces. On the device, frida-server runs as the injection host. On your machine, a Node.js process started by the rms binary serves the web UI and talks to the device through the frida Node bindings. In the browser, a page connects back over socket.io, which is why the package depends on express, socket.io and nunjucks on the server side and on frida, frida-java-bridge and frida-objc-bridge for the platform bridges.

The injected side is a single compiled agent. The repository keeps the source at agent/RMS_core.js and the compiled output at agent/compiled_RMS_core.js, and package.json wires the build with "compile": "frida-compile agent/RMS_core.js -o agent/compiled_RMS_core.js -c". That split matters if you plan to modify behavior: the README states that new features added to the agent require recompiling, either through npm run compile or directly with frida-compile agent/RMS_core.js -o agent/compiled_RMS_core.js.

Data flow is therefore: browser action, HTTP or socket message to the Node process, Frida RPC into the agent inside the target process, result back up the same path. The README notes that sockets do not work on Safari and asks for Chrome instead, so the transport is not incidental to the experience; it is part of the supported configuration.

## Installing RMS and hooking your first method

Prerequisites are Node.js and Frida's CLI tools on your computer, plus frida-server running on the target device. The README links to the official Frida Android and iOS setup pages for the server side.

Before installing anything, confirm the device is reachable. The README calls this the quick smoke-test and recommends it explicitly.

```bash
frida-ps -U
```

You should see a table of running processes with PID and NAME columns, for example com.facebook.katana on Android or Facebook on iOS. If that list does not appear, RMS will not detect the device either.

Install the CLI globally through npm:

```bash
npm install -g rms-runtime-mobile-security
```

The README warns that the frida-node dependency can fail to install on some Node.js versions and links to a troubleshooting post about choosing a different Node.js version.

Start RMS after frida-server is up:

```bash
rms
```

The same binary is also available as RMS-Runtime-Mobile-Security. Then open the interface in Chrome:

```
http://127.0.0.1:5491/
```

Port 5491 is the default. The README explains that it changed from 5000 because macOS Ventura uses 5000 for Control Center, and that you can override it:

```bash
rms --port 9000
```

From the UI, the first real task is a class dump: load the target process, list the loaded classes, then pick a method and attach a hook to watch its arguments and return value. The README also documents loading custom scripts, and the repository ships a custom_scripts directory plus DEMO/Android and DEMO/iOS example files to work from.

## Where RMS breaks: one device, Chrome only, and fragile method loading

The README is unusually candid about limits, and they are worth reading before you commit to a workflow.

Single device only. RMS cannot recognize multiple devices, and the README instructs you to connect no more than one at a time. On a bench where you are switching between an emulator and a physical handset, that means disconnecting one before the other is usable.

Startup order is strict. RMS must be started after frida-server. The README also lists killing RMS and starting it again as a remedy when the device is not detected, which suggests detection is not always reliable on the first attempt.

Complex methods can fail to load. The README states that RMS sometimes fails to load complex methods and suggests using a filter, or improving the algorithm in agent/RMS_core.js. That is a real ceiling on large obfuscated apps, and the fallback is either narrowing your view or patching the agent yourself.

Browser support is not general. Sockets do not work on Safari, so the README directs you to Chrome, which it calls fully supported. If Chrome is not an option in your environment, the UI degrades.

The README also says the code is not optimized. Take that at face value: this is a tool built for interactive exploration, not for long-running instrumentation at scale. The author's own closing note invites pull requests with JavaScript scripts to bundle as default scripts in future releases, which tells you where maintenance effort has historically come from.

## RMS against writing Frida scripts by hand

The honest alternative is Frida itself, without RMS. You install the frida-tools CLI, write a JavaScript agent, and inject it with frida -U -f com.example.app -l script.js. Everything RMS does at runtime is reachable that way, because RMS is a front end over the same runtime.

The difference is in the loop. With hand-written scripts, every new question is an edit, a re-inject and a re-read of console output, and you keep your own library of snippets. With RMS, class enumeration, hooking and argument tracing are already wired to buttons and forms, and the results stream into a browser console. For exploratory work on an unfamiliar app, that saves the mechanical part of the job.

The trade runs the other way for anything repeatable. A script is versionable, reviewable, and runnable in CI against a fixed target. The RMS web UI is an interactive session, and the README's own note about recompiling the agent after changes means that extending RMS is a heavier change than editing a standalone script. If you already have a mature Frida script collection, RMS adds a second place to maintain logic.

There is also a middle path the README points at: use RMS to find the method and arguments you care about, then move that knowledge into a standalone Frida script once the target is understood.

## Maintenance, licence and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-03. Releases are irregular rather than frequent: 1.5.25 on 2026-07-01, 1.5.24 on 2025-11-15, and 1.5.23 on 2024-10-05. The current package.json version is 1.5.25. Plan around that cadence rather than assuming a steady stream of fixes.

Upgrades carry a specific risk because of the agent compile step. Because the injected code is built from agent/RMS_core.js into agent/compiled_RMS_core.js, any local modification to the agent has to survive your next install. If you patched the method-loading algorithm to handle the complex methods the README mentions, that patch lives outside the published package and will need reapplying.

Dependency drift is the other cost. The package depends on frida ^17.15.3, frida-java-bridge ^7.0.13 and frida-objc-bridge ^8.0.6, and the README already flags that frida-node can fail to install depending on your Node.js version. A Frida major upgrade is the kind of event that makes a pinned toolchain worth having.

The licence is GPL-3.0, as stated in package.json and the LICENSE file. That is a copyleft licence, and it matters if you plan to redistribute RMS or ship a modified version inside a product. This is not legal advice; if you intend to embed it, read the licence text and talk to someone qualified.

## Conclusion

Adopt RMS if you already run Frida and want a browser front end for class dumps, hooks and argument tracing on one connected device, and if you are comfortable with a GPL-3.0 tool whose README admits the code is not optimized. Skip it if you need multi-device support, Safari compatibility or a maintained security guarantee, since the README lists those as known issues rather than features. Before you rely on it, run frida-ps -U to confirm the device is visible, start RMS after frida-server, and check that only one device is attached.

## FAQ

### Is the mobile security app safe?

RMS is a runtime analysis tool for Android and iOS apps, not a consumer security app, so the question of safety applies to how you use it. The README requires frida-server running on the target device and instructs you to connect only one device, which implies a controlled test environment rather than a production phone.

### What are the different types of mobile security?

RMS sits in one specific category: runtime manipulation of Android and iOS apps through Frida, covering class dumps, on-the-fly hooks and argument tracing. The README positions it alongside reverse engineering and mobile security testing work, and links to OWASP UnCrackable challenge walkthroughs as examples.

### What is mobile app security?

The README frames RMS as a tool for manipulating Android and iOS apps at runtime, which is the analysis side of mobile app security. It dumps loaded classes and methods, hooks methods on the fly, traces arguments and return values, and loads custom scripts.

## Sources

- [License: GPL-3.0](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security/blob/master/LICENSE)
- [m0bilesecurity/RMS-Runtime-Mobile-Security on GitHub](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
- [Project website](https://twitter.com/mobilesecurity_)
- [README](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security/blob/master/README.md)
- [Releases](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/m0bilesecurity-rms-runtime-mobile-security