Last updated October 21, 2013 10:32, by Koka
==Shield4J - Java class and Android protection==
======[http://shield4j.com Shield4J] is a Java class and Android APK (dex) obfuscator, encrypter, shrinker and merger based on a powerful, easy-to-use and cheap online service.======
'''But why is it so simple?'''
The simplicity of this service consists of it not needing to be configured (e.g. with complex scripts), all you have to do is to upload the Jar files to be protected, select a profile representative of your application type (self-contained Main or JWS based, JavaFX, Android .apk, Applet, Web Servlet or generic), optionally set the encryption options and the packages, classes, methods or fields to be ignored during the obfuscation process, and finally, download your single-protected Java file after the process finishes.
'''And... what exactly does it do?'''
The protection process starts with a bytecode obfuscation, including the renaming of all member types (packages, interfaces, classes, methods, fields and local names) to shorter, random and unique names and it continues by removing unused class file information at execution time such as debugging information, unnecessary attributes, unused members and unused instructions, resulting in a reduction of class size. After that, a string encryption is optionally performed and, depending on the application type, a class encryption preventing decompilers from showing the obfuscated code is applied. Finally and optionally, Shield4J can sign the output file protected (.jar, .apk or .war) before the downloading.
* All JDK/JRE versions to date supported (mainly tested on JRE 1.4, 1.5, 1.6 and 1.7).
* Name obfuscation of all member types (packages, interfaces, classes, inner-classes, enumerations, methods, fields and local variables), by changing them by short and inexpressive characters, nonsense names and randomly chosen Java reserved words.
* Code cleaning (unused code and unreferenced members removal).
* Code structure, comments and line numbers in exceptions stack trace removal (made via JVM class attributes suppression).
* Annotations and generics support (from Java 5).
* String encryption support (except string constants in annotations).
* Automatic reflection and introspection handling support.
* Automatic serialization handling support.
* Inheritance, overriding and abstract members support.
* Automatic resource files path adapting, according to the obfuscation changes.
* Automatic handling of unfound referenced dependent classes (e.g. from libraries), skipping them from being obfuscated. If any Jar library license prevents it from being modified, simply do not upload it. The rest of your obfuscated code will work correctly.
* Automatic RMI handling support (holds the class _Skel and _Stub suffixes for the classes generated by the RMI compiler).
* Automatic JNI handling support (excluding native method names and their classes from being renamed).
* Cross Jar merging.
* Class file keyless encryption support (only for main-based apps, JWS, JavaFX and applets).
* Multiple Java archive input files (.jar, .zip, .apk and .war formats accepted).
* Single merged and compacted output file (.jar, .apk or .war).
* Optionally configure the packages, classes, methods or fields to rename during the obfuscation process (e.g. if you need to expose some public API of certain classes to 3rd-party).
* Automatic MANIFEST.MF file processing (including intelligent-merging if more than one is detected and, for main-based and JavaFX apps, Main-Class and JavaFX-Application-Class attributes remapping according to the obfuscation changes).
* Automatic FXML (.fxml) and CSS (.css) files processing for members remapping (in JavaFX apps only), according to the obfuscation changes.
* Automatic web.xml file processing for classes remapping (in servlets-based web apps), according to the obfuscation changes.
* Signing the output file with Shield4J's demo private-key and public-key certificate or with yours.
'''And furthermore, for Android APKs...'''
* Fully-compatible with the latest Dalvik VM to date (mainly tested on Android 4.3 platform).
* Automatic AndroidManiest.xml processing and remapping, adapting its content according to the obfuscation changes.
* Automatic APK resources (.xml, bitmaps, etc) and resources.arsc content processing and remapping, adapting resource file names and content according to the obfuscation changes.
* No sign-up necessary. Test and use the service without any registration. All you have to do is to introduce a valid email before clicking on start protection process.
* Easy-to-use online protection dialog, based on a 4-step tabbed-wizard (1-Upload Java files, 2-Set options, 3-Start protection, 4-Download protected file).
* Simple file upload manager, with actions like add (upload new), replace and remove Jar files or select/unselect for protecting.
* Protection based on profile, according to your application type. Under each profile, the service internally and automatically applies the necessary configuration parameters to protect it, transparent to the user. Currently, Shield4J supports the following 4 profiles: self-contained Main or JWS based, JavaFX, Android APK, Applet, Web Servlet and generic or undefined.
* Unlimited protections. You can apply the online protection (trial or full) as many times as you need until you have confirmed that your protected .jar, .apk or .war works as expected.
* Downloadable protected file. After the protection process finishes, you can download the protected files all the times you need within the link expiration interval (1 days for trial protections and 30 days for full protections).
* Online viewable and downloadable mapping file. The mapping file contains the translation between the original member names (packages, classes, methods and fields) and their corresponding obfuscated ones, useful for debugging purposes.
* It is very simple!. In just a few clicks your code will be protected, with minimal or no configuration and without any sign-up.
* Completely web-based. Since Shield4J is an online service, you do not need to install any desktop app or similar onto your machine in order to achieve the protection.
* The protection process is quick. It takes less than a minute to process several MB of input Jar files.
* The obfuscation makes the reverse-engineering and piracy of your code stronger and almost impossible, since human-semantic information and structure disappear. It is therefore extremely difficult to derive the original purpose of the obfuscated code.
* The obfuscation also reduces the generated .jar, .apk or .war size (but only if no encryption is present), meaning faster VM class loading and lower VM memory consumption.
* The string encryption avoids the string constants to be shown as plain text when classes are disassembled.
* The class encryption (where applicable) prevents decompilers from showing the obfuscated code, since encrypted classes are not bytecodes and do not have any file format.
* The protected .jar and .war are 100% fully compliant Java bytecode or Dalvik bytecode for Android .apk (if no class encryption is present) and remains fully portable.
* Functionality unchanged. Your apps will remain functionally equivalent.
[http://shield4j.com Go to Shield4J homepage]