3 Replies Latest reply on Mar 10, 2018 7:01 AM by anonymized013

    Installing Byteman agent in remote JVM


      as part of my master thesis I'm currently investigating Byteman's capabilities to extract data from applications or disrupt their program flow. Further, I hope to find ways how to prevent this. But for now I'm trying to install the Byteman agent in a remote JVM.


      My setup:

      • VM1: Fedora 24 x86, brigded mode, IP:, stopped firewalld service
      • VM2: Kali Linux x64, bridged mode, IP:

      On VM1 I started Wildfly 11, configured to listen on all interfaces, running a small web service. First test was to inject the agent locally from VM1 which worked like a charm. Next, I fired up VM2 and ensured that both VMs are able to ping each other. VM2 is also able to call the web service provided by VM1. Now I'm trying to inject the agent into VM1's Wilfdfly JVM via VM2, but to no avail.


      Executing netstat -anpt on VM1 returns, amongst others, the running Wildfly process:

      Proto Recv-Q Send-Q Local Address       Foreign Address     State   PID/Program name   
      tcp    0            0           0*     LISTEN    4457/java

      My first attempt was to execute following statement on VM2:

      ./bminstall.sh -b -h -p 8443 4457

      but I always get

      java.io.IOException: No such process


      I also tried other ports and even opened a new listening port via nc on VM1 but I always get the same error. Unfortunately, computer networking was never my strength

      Is, what I try to accomplish, even possible? And if yes, what am I doing wrong?

        • 1. Re: Installing Byteman agent in remote JVM



          I think this is in general not possible. Byteman agent is capable to join a java process on your local machine. What I know there isn't way to inject Byteman remotely. When Byteman agent is started then, by default, opens port where you can communicate. That means you can remotely command Byteman to add rules, change them etc., but first you need agent being started.


          Your example


          ./bminstall.sh -b -h -p 8443 4457 


          says - please install Byteman agent to local java process with pid 4457, when started please bind it to and waits there for further instructions (https://developer.jboss.org/wiki/ABytemanTutorial#how_do_i_install_the_agent_into_a_running_program ). Then you can sends rules to be injected to the running java program where the bmsubmit.sh connects to the agent (running at and provides rules to be installed.


          ./bmsubmit.sh -h -p 8443 path/to/script_file.btm


          What you need, I think, is to start the Byteman agent during launch of the java program on both VMs (see Byteman Programmer’s Guide, 4.0.1, Feb 19, 2018 ). So you will copy the byteman.jar to both machines first and then redefine JAVA_OPTS for the starting WildFly app server to start agent and listening for commands at some port (or you can directly inject rules just during program startup). See documentation here https://developer.jboss.org/wiki/ABytemanTutorial#how_do_i_run_jboss_as_with_byteman (and maybe some points here byteman-workshop/task1 at advanced_solution · ochaloup/byteman-workshop · GitHub )



          • 2. Re: Installing Byteman agent in remote JVM

            Ondra has almost got all the pieces of the puzzle in place. I'll just recap and clarify a few things.


            Let's assume you want to achieve this setup:


            • VM1 : Running JVM1, Byteman is installed in JVM1
            • VM2: Running JVM2, rules are uploaded to JVM1


            Then there are several things to note:


            1. You can only install Byteman into JVM1 from VM1
              a) You can do that from the java command line for JVM1 using -javaagent (see the first Byteman tutorial or programmers guide for details)
              b) You can do that after JVM1 has started using bminstall (see the first Byteman tutorial for details)
            2. You need to configure Byteman to listen on a public network interface and port for this to work (by default Byteman only listens on the loopback interface localhost using port 9090)
                a) for command line use pass host:ip_address_or_name and port:port_num as options for the -javaagent string
                b) for post JVM-startup agent load using bminstall pass arguments -h ip_address_or_name and -p port_num
            3. You don't actually need to run JVM2 on VM2 in order to upload rules into Byteman on VM1
                a) You can use bmsubmit to load the rules so long as you pass -h ip_address_or_name and -p port_num
            4. If you have JVM2 running on VM2 then you can use class Submit to upload rules to Byteman on JVM1
              a) See the javadoc for Submit for what info there is on how to use it's API


            A few important thing to realise are


            1. On Linux step 1a requires you to have login access to VM1 logged in with the same user id as was used to start Java
            2. On Windows step 1a requires you to have login access to VM1
            3. On Linux or Windows step 1 (a or b) requires you to have permission to listen on the selected interface port
            4. On Linux or Windows steps 3 or 4 require that clients from JVM2 are able to open client connections to the chosen port on JVM1 (for example, this might be disallowed by a suitably configured firewall on JVM1)


            In other words, the assumption you started with that you could just upload Byteman into JVM1 from JVM2 if true would constitute a gross security risk. Whereas the reality is that this setup can be made as safe as you want by restricting access to the target host and/or the port Byteman listens on using standard security measures.





            Andrew Dinn

            • 3. Re: Installing Byteman agent in remote JVM

              Thanks alot to both of you. It seems that it was a misconception on my end that I could remotely inject Byteman using bminstall -h. I just succesfully tested installing Byteman on VM1 and submitting rules via VM2. Thanks again for the clarification.