Remote Dynamic Blackbox Java App Analysis

Java Bytecode Debugging and Dynamic Instrumentation Through Eclipse

Run whatever code you want inside of a blackbox java jar

Server side setup

Find supported JVM

On the device running the jar file, you will need to make sure that your local JVM supports debugging.

You can check by running the application with either of the two commands below:

java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1234 <Application.jar>
java -agentlib:jdwp=transport=dt_socket,server=y,address=1234,suspend=y <Application.jar>

If your JVM does not support debugging, you will see an error message similar to below:

$ java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1234 <Application.jar>
Unrecognized option: -xDebug

JVMs like JAMVM do not support the -xDebug flag

Identify supported JVM

The default JVM may not support the xDebug flag, however there may be multiple JVMs installed on the device. Reading the jvm.cfg file located at the java install will show which JVMs are available.

$ cat /usr/lib/jvm/default-java/jre/lib/amd64/jvm.cfg
# Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
...
# and may not be available in a future release.
#
-server KNOWN
-client IGNORE
-zero KNOWN
-dcevm KNOWN

#Adding the server JVM flag will force java to call the server JVM
java -server -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1234 <Application.jar>

Further, if there are folders in your JRE lib folder with other JVMs, you can safely add those JVMs to the JVM.cfg

#client and server are folders that can be added as known JVMs to the jvm.cfg file
ls /home/user/test/jdk1.8.0_181/jre/lib/arm/
client              libhprof.so          libjpeg.so        libnpt.so
jli                 libinstrument.so     libjsdt.so        libresource.so
jvm.cfg             libj2gss.so          libjsig.so        libsaproc.so
libattach.so        libj2pcsc.so         libjsoundalsa.so  libsctp.so
libawt_headless.so  libj2pkcs11.so       libjsound.so      libsplashscreen.so
libawt.so           libjaas_unix.so      libkcms.so        libsunec.so
libawt_xawt.so      libjava_crw_demo.so  liblcms.so        libt2k.so
libbci.so           libjava.so           libmanagement.so  libunpack.so
libdcpr.so          libjawt.so           libmlib_image.so  libverify.so
libdt_socket.so     libjdwp.so           libnet.so         libzip.so
libfontmanager.so   libjfr.so            libnio.so         server

Client Side Setup

Installation

Eclipse 4.3 is required for the bytecode visualizer plugin required to debug these applications.

Install Eclipse Kepler and the Bytecode Visualizer plugin.

Navigate to: Help -> Eclipse Marketplace

Search for "bytecode visualizer" and install Dr. Garbage's Bytecode Visualizer

Project Creation

This portion taken directly from crowdstrike

Once Eclipse restarts, close the Welcome tab, and in the menu bar go to File → New → Java Project. Specify any project name you like and press the Next button:

In the Java Settings window, click the Libraries tab. In the Libraries tab, press the Add External JARs button and select the JAR file you want to debug, thereby adding it to the Java project’s build path:

In the Package Explorer tab, expand your project’s Referenced Libraries to find your JAR file. Right-click on the class you want to debug and select Open with Bytecode Visualizer:

Set breakpoints

With the JAR’s code now visible in Bytecode Visualizer, you can set breakpoints by double-clicking on the vertical gray bar to the left of the disassembled Java code:

Debug Setup

Create a debug configuration and put in the server's IP and port information.

Running code

Open the "Display" view in eclipse. Window -> Show View

Once a breakpoint has been triggered or a thread has been suspended, code can be written into the Display frame and selected to run inside the suspended thread given the current context of the thread.

References

https://www.crowdstrike.com/blog/native-java-bytecode-debugging-without-source-code/