diff --git a/src/main/java/ysoserial/exploit/JBoss.java b/src/main/java/ysoserial/exploit/JBoss.java
index 2d904a0..c3a7e61 100644
--- a/src/main/java/ysoserial/exploit/JBoss.java
+++ b/src/main/java/ysoserial/exploit/JBoss.java
@@ -70,6 +70,8 @@ import ysoserial.payloads.ObjectPayload.Utils;
  * 
  * An exploitation client for JBoss AS/Wildfly JMX
  * 
+ * JBoss is using a custom tunneled protocol for JMX, this is a client for this protocol.
+ * 
  * This is not as readily exploitable as in other pieces of software:
  * 1. they only allow authenticated access by default
  * 2. they have a very strict module architecture:
@@ -77,7 +79,15 @@ import ysoserial.payloads.ObjectPayload.Utils;
  * - the module classloaders do not even expose the full boot classpath, so we cannot readily use stuff like
  * com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl
  * 
+ * This client enumerates all application exported MBean method which are then called 
+ * delivering the specified payload.
  * 
+ * I.e. you can succesfully exploit that
+ * - you have access to the interface 
+ *    (username/password can be specified via URL, note: despite not noticeable, 
+ *    local connections implicitely use authentication) 
+ * - there is an application exported MBean
+ * - that application imports the classes required for the gadget chain
  * 
  * @author mbechler
  *
diff --git a/src/main/java/ysoserial/exploit/JRMPClient.java b/src/main/java/ysoserial/exploit/JRMPClient.java
index 3808bf6..81345bd 100644
--- a/src/main/java/ysoserial/exploit/JRMPClient.java
+++ b/src/main/java/ysoserial/exploit/JRMPClient.java
@@ -19,6 +19,12 @@ import ysoserial.payloads.ObjectPayload.Utils;
 
 
 /**
+ * Generic JRMP client
+ * 
+ * Pretty much the same thing as {@link RMIRegistryExploit} but 
+ * - targeting the remote DGC (Distributed Garbage Collection, always there if there is a listener)
+ * - not deserializing anything (so you don't get yourself exploited ;))
+ * 
  * @author mbechler
  *
  */
diff --git a/src/main/java/ysoserial/exploit/JRMPListener.java b/src/main/java/ysoserial/exploit/JRMPListener.java
index 54a5a0c..ecd73a7 100644
--- a/src/main/java/ysoserial/exploit/JRMPListener.java
+++ b/src/main/java/ysoserial/exploit/JRMPListener.java
@@ -28,6 +28,11 @@ import ysoserial.payloads.util.Reflections;
 
 
 /**
+ * Generic JRMP listener
+ * 
+ * Opens up an JRMP listener that will deliver the specified payload to any
+ * client connecting to it and making a call.
+ * 
  * @author mbechler
  *
  */
diff --git a/src/main/java/ysoserial/exploit/JSF.java b/src/main/java/ysoserial/exploit/JSF.java
index 396405a..480da95 100644
--- a/src/main/java/ysoserial/exploit/JSF.java
+++ b/src/main/java/ysoserial/exploit/JSF.java
@@ -15,6 +15,20 @@ import ysoserial.payloads.ObjectPayload.Utils;
 
 
 /**
+ * JSF view state exploit
+ * 
+ * Delivers a gadget payload via JSF ViewState token.
+ * 
+ * This will only work if ViewState encryption/mac is disabled.
+ * 
+ * While it has been long known that client side state saving
+ * with encryption disabled leads to RCE via EL injection,
+ * this of course also works with deserialization gadgets.
+ * 
+ * Also, it turns out that MyFaces is vulnerable to this even when 
+ * using server-side state saving
+ * (yes, please, let's (de-)serialize a String as an Object).   
+ * 
  * @author mbechler
  *
  */
diff --git a/src/main/java/ysoserial/exploit/JenkinsCLI.java b/src/main/java/ysoserial/exploit/JenkinsCLI.java
index cbbca3c..cdbd4a4 100644
--- a/src/main/java/ysoserial/exploit/JenkinsCLI.java
+++ b/src/main/java/ysoserial/exploit/JenkinsCLI.java
@@ -26,6 +26,14 @@ import hudson.remoting.ChannelBuilder;
 import ysoserial.payloads.ObjectPayload.Utils;
 
 /**
+ * Jenkins CLI client
+ * 
+ * Jenkins unfortunately is still using a custom serialization based
+ * protocol for remote communications only protected by a blacklisting
+ * application level filter.
+ * 
+ * This is a generic client delivering a gadget chain payload via that protocol. 
+ * 
  * @author mbechler
  *
  */
diff --git a/src/main/java/ysoserial/exploit/JenkinsListener.java b/src/main/java/ysoserial/exploit/JenkinsListener.java
index 1cb84a5..64c2adb 100644
--- a/src/main/java/ysoserial/exploit/JenkinsListener.java
+++ b/src/main/java/ysoserial/exploit/JenkinsListener.java
@@ -32,6 +32,17 @@ import ysoserial.payloads.util.Reflections;
 /**
  * CVE-2016-0788 exploit (1)
  * 
+ * 1. delivers a ysoserial.payloads.JRMPListener payload to jenkins via it's remoting protocol.
+ * 2. that payload causes the remote server to open up an JRMP listener (and export an object).
+ * 3. connect to that JRMP listener and deliver any otherwise blacklisted payload.
+ * 
+ * Extra twist:
+ * The well-known objects exported by the listener use the system classloader which usually
+ * won't contain the targeted classes. Therefor we need to get ahold of the exported object's id
+ * (which is using jenkins' classloader) that typically is properly randomized.
+ * Fortunately - for the exploiting party - there is also a gadget that allows to leak
+ * that identifier via an exception.
+ * 
  * @author mbechler
  */
 @SuppressWarnings ( {
diff --git a/src/main/java/ysoserial/exploit/JenkinsReverse.java b/src/main/java/ysoserial/exploit/JenkinsReverse.java
index 057c216..ba4d3fe 100644
--- a/src/main/java/ysoserial/exploit/JenkinsReverse.java
+++ b/src/main/java/ysoserial/exploit/JenkinsReverse.java
@@ -15,6 +15,12 @@ import ysoserial.payloads.ObjectPayload.Utils;
 /**
  * CVE-2016-0788 exploit (2)
  * 
+ * - Sets up a local {@link JRMPListener}
+ * - Delivers a {@link ysoserial.payloads.JRMPClient} payload via the CLI protocol 
+ *   that will cause the remote to open a JRMP connection to our listener
+ * - upon connection the specified payload will be delivered to the remote 
+ *    (that will deserialize using a default ObjectInputStream)
+ * 
  * @author mbechler
  *
  */