0

Scenario

Suppose a Java application is being developed. Assume it contains functions which are in need of being hidden. Decompiling Java is not really an issue, besides a lot of information can be obtained from just opening the JAR with an archive manager, such as 7zip.

There are tools such as ProGuard:

https://www.guardsquare.com/en/products/proguard/manual/examples#application

Such tools can be used to obfuscate the Java codebase, however, there are some issues with this, e.g. a lot of logic can still be derived with some, at best, moderate effort. In addition, some codebases cannot be effectively processed with ProGuard.

Ultimately, there are just cases, where I need to use some Java API and pass it some credentials. But these credentials - no matter how safely stored - can be read on runtime, by simply attaching a debugger and then viewing these in plain text, or if they are stored C++ side, they can be extracted with a new JAR by accessing the C++ function, etc.

Question

The problem itself is not really relevant to my question, but it got me wondering - is there a way to wrap entire Java functionality using C++, i.e. write functions in Java, then in some way package them into a DLL?

I am aware of the existence of JNI, where I can access C++ functionality provided via DLL using native functions (this is already heavily utilized in my application in fact). But what if I intend to store Java functions in a DLL and then provide them to the JVM directly, without having to unpack them into a JAR first? If you are thinking of a VM - this is somewhere along those lines.

Example

Suppose I have something like this in my Java codebase:

import io.sentry.Sentry;
import io.sentry.SentryClient;

public class SentryController
{
    private version = "someversion";
    private superSecretSentryString = getSecretStringFromKMS(); // beautiful alliteration

    public SentryController()
    {
        Sentry.init( superSecretSentryString ); // stored safely in KMS, but easily read on runtime
        Sentry.getStoredClient().setRelease( version ); 

        // ...
    }

    // ...

}

Assume I do not want anyone to see this class and aim to move it to a DLL entirely, while still being able to use import io.sentry.Sentry and therefore be able to access the Sentry API.

Disclaimer

I am aware that in all likelihood no such API / wrapper exists, i.e. what I am looking for is not possible. This question is to assure that there is no possibility that I am unaware of.

This question is a followup on this:

Java / C++ Encryption and the JNI interface

I have considered putting it on the security SE:

https://security.stackexchange.com/

However I think the sole question (bold print above) is detached from the reason described, i.e. I am not looking for a sensible way to prevent readout of credentials or decompilation of functions, but I am curious to know whether whole Java functionality can be encapsulated in a DLL.

Community
  • 1
  • 1
Koenigsberg
  • 1,726
  • 1
  • 10
  • 22
  • Go read the JNI docs again. Embedding JVMs in native (C/C++) apps is perfectly possible – hardillb Nov 06 '19 at 13:27
  • It might, still reading. I have looked for the keyword *embed* after your comment and came accross this as well. – Koenigsberg Nov 06 '19 at 13:30
  • Let me review the other question, if there are no significant differences, then I will accept the duplicate mark. Thanks in advance – Koenigsberg Nov 06 '19 at 13:31
  • If I understand correctly, this creates and initializes a JVM when executing native code. I am left wondering where the Java source is stored in this case? – Koenigsberg Nov 06 '19 at 13:35
  • I assume the Java source is passed to the JVM using `vm_args.classpath = ...;`, so it is still stored in a `.class` and can be decoompiled with relative ease, unless I misunderstand something. – Koenigsberg Nov 06 '19 at 13:39
  • If you are worried about decompiling your classes that is totally separate question and you should go read about custom classloaders, you can store your classes how ever you want as long as you can later provide them as a byte stream to the classloader. – hardillb Nov 06 '19 at 13:46
  • Then I consider this question answered. Thanks! – Koenigsberg Nov 06 '19 at 13:55

0 Answers0