remote-method-guesser: a vulnerability scanner aimed at Java RMI endpoints

One protocol, scanned thoroughly

remote-method-guesser, shortened to rmg, is described as a Java RMI vulnerability scanner used to identify and verify common security vulnerabilities on Java RMI endpoints. That is a narrow remit, and the narrowness is the point.

Java RMI is an attractive target because it exposes remote object binding, method invocation and Java serialization in one protocol, and the topic tags on the repository show the shape of the concern: java-rmi, rmi-registry, rmi-server, remote-method-guessing, deserialization and deserialization-attacks, with cve-2019-2684 named explicitly and codebase-attacks and bruteforce as further tags. The class of problem is that a server which binds a remote object may expose a method that a remote caller cannot be expected to know the name of, and a server which deserializes input from an unauthenticated caller may be exploitable through that channel.

The tool was presented at Black Hat USA 2021 in the Arsenal sessions, and the slides and the session recording are linked publicly, which is a reasonable indicator that the author intended wide defensive use rather than a narrow offensive one. The licence is GPL-3.0, the primary language is Java, the build system is Maven, and the project requires Java 8 or later.

Because the tool is aimed at one protocol, the wrong-tool case is easy to state. It will not help you sweep a network for open ports, audit a web application or check a host for missing patches. Those jobs need different instruments.

The operation list is the documentation of what it probes

The table of contents in the project documentation lists the operations, and reading them tells you what the scanner actually does.

The enumeration family is the core. The enum operation enumerates remote objects on a registry. The guess operation guesses method names on a remote object. The known operation uses a list of known method names instead of guessing. The objid operation works with object identifiers. The scan operation is the broad sweep, and the codebase operation is the one associated with the deserialization attack path, which is why the repository carries the codebase-attacks and cve-2019-2684 tags.

The rest describe what you do with what you find. The call operation regularly calls a method with the specified arguments, the bind operation binds an object to the registry pointing at a listener, the listen operation starts a listener, the serial operation handles serialization, and the roguejmx operation deals with JMX. The bind and listen pair is the mechanism for a rogue registry, which is how a client-side deserialization target gets a callback.

The usage output in the documentation shows the tool is a single command with a positional action, for example:

[qtc@devbox ~]$ rmg -h
usage: remote-method-guesser [-h] action ...

rmg v4.0.0 - a Java RMI Vulnerability Scanner

The action is chosen by name or number, and the parameters depend on the action. That structure is why the documentation points at the docs folder for detailed descriptions of each operation and on Java RMI in general, rather than trying to fit the whole surface into a command reference.

Building the jar with Maven

Installation is described as straightforward because the project is a Maven project. With Maven installed, three commands produce an executable jar:

$ git clone https://github.com/qtc-de/remote-method-guesser
$ cd remote-method-guesser
$ mvn package

Prebuilt packages exist for each release, and packages for the development branch are produced automatically and published on the GitHub actions page. That matters for an audit workflow, because you can pick a known artefact rather than compiling whatever the branch head happens to be.

There is also bash autocompletion. It requires the completion-helpers project to be installed, and the setup is a copy of a shipped script:

$ cp resources/bash_completion.d/rmg ~/bash_completion.d/

Note the path in that command. The documentation says to copy the script into your .bash_completion.d folder, and the example command shows ~/bash_completion.d/ without the leading dot, so if your shell has no completion for rmg, the directory name is the first thing to check.

The Docker image is built the same way the jar is, with a multi-stage Dockerfile. A maven:3.8.6-openjdk-8-slim builder compiles the project, a second stage links a trimmed Java 11 runtime with jlink using the modules java.desktop, java.rmi, java.management.rmi and jdk.unsupported, and the final alpine stage carries the jar at /opt/rmg.jar with the entrypoint java -jar /opt/rmg.jar, running as an unprivileged user.

Three practice servers ship with the project

The repository includes three example servers under the docker folder, and they are the reason this project is usable as a teaching and testing tool rather than only as a scanner.

The rmg-example-server exposes regular RMI services that can be enumerated and exploited using remote-method-guesser. The rmg-ssrf-server exposes an HTTP service vulnerable to SSRF that runs RMI services listening only on localhost, so the RMI services can be reached through the HTTP entry point. That server exists to practise the --ssrf and --ssrf-response options, and it makes a point that is easy to miss otherwise: an RMI service that is not exposed to the network can still be reachable if the application in front of it can be made to connect outward.

The spring-remoting-server exposes RMI interfaces created through Spring Remoting, which are not identical to regular Java RMI, so it exists to exercise the associated Spring Remoting integration of the scanner. A scanner that only understands classic RMI would miss that case.

All three are published as containers in the GitHub Container Registry, and you can either build them yourself or pull them directly. Each also has its own workflow badge in the repository, which means they are built on every change rather than being static artefacts. Practising against these first is the difference between learning what the tool reports and learning what a real deployment looks like.

ysoserial is deliberately not bundled

The most consequential detail in the installation notes is that rmg does not include ysoserial as a dependency. To enable ysoserial support you either pass the path to your ysoserial.jar as an additional argument, for example --yso /opt/ysoserial.jar, or you change the default path in the configuration file at src/config.properties before building the project.

That is a deliberate separation between the scanner and the payload library, and it has a clear effect on what you can run out of the box. Operations that need ysoserial, which in practice means the deserialization and codebase paths, will not function until you supply the jar yourself. Someone auditing a deployment without understanding this will see the tool fail on the checks that matter most and may misread that as a clean result.

The Docker image resolves the same question differently. The final stage downloads the jar directly at build time with wget from the ysoserial release page into the home directory of the created user, so a container run has ysoserial present while a local jar built from source does not. That difference between the two packaging paths is worth knowing before you compare behaviour.

The general principle here is worth carrying to other offensive tooling: the scanner and the exploit payload are separate components with separate licences and separate update cycles, and a deployment that expects the scanner to be self-sufficient will quietly under-test.

What a clean scan does and does not tell you

The tool verifies specific weaknesses on specific endpoints, and its output should be read as evidence about those endpoints rather than as a verdict on the application.

The first limit is the guessing model. The guess operation works on method names that a caller is not expected to know, so the coverage of the method surface depends on the naming patterns an application uses. A service with unusual method naming will yield fewer candidate methods, and the known operation covers only the names in its list. A clean result therefore means that the endpoints it reached did not expose the problems it knows how to look for, not that the RMI surface is free of issues.

The second limit is reachability. The SSRF practice server exists because RMI services bound to localhost are still reachable through an application that can be induced to connect outward. A scanner run from outside the network will simply not see those services, so a scan that reports nothing may reflect the scanner's position rather than the server's configuration.

The third is the version gap. The tagged releases are v5.1.0 from 2024-06-26, v5.0.0 from 2023-12-23 and v4.4.1 from 2023-06-22, while the last push to the repository was on 2026-09-03. Development continues on the branch, and the usage text in the documentation still shows rmg v4.0.0, so the version numbers in the documentation and the current release line do not line up. If you need a specific behaviour, check which artefact you are actually running rather than trusting the version banner.

For an audit trail, GPL-3.0 has a practical consequence worth flagging early. If you distribute the tool or a build of it inside another product or a hosted service, the copyleft obligations attach to that distribution, so the licence position should be checked before the tool becomes part of a shipped pipeline.

Editorial conclusion

Adopt remote-method-guesser when you are auditing Java RMI services and need enumeration and verification of the classic RMI weaknesses in one tool, and you can host the three practice servers for your own testing. Skip it for general host or web scanning, since every operation assumes RMI, and skip it if you cannot obtain ysoserial, because the codebase and serial operations depend on it. Verify first that the target exposes a registry you are authorised to enumerate, and run the rmg-example-server container locally before pointing the scanner at anything you do not own.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. qtc-de/remote-method-guesser on GitHub
4. README
5. Releases