Obfuscating jars created with the Spring Boot framework

May 9, 2018 5777 Views Johnny

Welcome to the Support Corner, where we’ll occasionally talk about topics that we’re seeing while working with our customers. If you’d like to see more like this, please click the Support Corner Category.

Recently, we’ve worked with a handful of customers who are using the Spring Boot framework. Spring Boot provides a simple way to create Spring-based applications. This blog explains how to protect jars created with the framework.

Spring Boot jars use an embedded class file structure which DashO does not directly recognize. DashO processes the regular class and package hierarchy. However, it does not embed the class files from the BOOT-INF/classes directory when writing the obfuscated jar.

To process the Spring Boot jars, first extract the jar file and provide the extracted BOOT-INF/classes directory as input to DashO. Then run DashO obfuscation, and re-jar the directory with BOOT-INF/classes properly embedded in the jar.

Spring Boot jars also don’t use the usual Main-class entry point. Spring Boot provides a specific entry point (org.springframework.boot.loader.JarLauncher). For Spring Boot jars, you will need to explicitly define the application's Main method in the DashO Entry Point section, so that at runtime the jar is able to execute properly. This differs from non-Spring Boot jars, where DashO will automatically use the Main-Class Entry Point as defined in the jar manifest.

We’ve created a simple Spring Boot obfuscation project which automates the process of extracting, obfuscating, and recreating the jar file with obfuscated contents.

Download the Spring Boot with DashO Sample.

The archive contains an Ant file which:

1. Extracts the contents of the Spring Boot jar
2. Obfuscates the classes within the BOOT-INF/classes directory
3. Copies the obfuscated classes back to the exploded directory
4. Re-creates the jar file (called obfuscated.jar) with the obfuscated class files
5. Cleans any temporary or intermediate files

You will need to set DASHO_HOME to the DashO installation directory for the script to run properly. There is also a DashO config file (.dox) that contains the DashO project settings.

Please note: this is a basic Spring Boot example. In applications with more complexity, there may be additional configurations necessary, such as rename exclusions or additional jars on the DashO classpath. For more details, please see the DashO userguide.

If you have any feedback on this topic, or other topics you would like us to discuss in the Support Corner, please feel free to contact us at support@preemptive.com.

Latest Blog Posts

Protecting C# Applications That Use Dynamic Types

The dynamic type in C# provides flexibility that is not available in other statically-typed languages. Since its introduction in C# 4.0 (.NET 4.5), we have worked with customers who wanted to know more about how dynamic types are impacted by the obfuscation process.

Malicious actors — like any thieves — live by a simple rule: If the front door is locked, break the window.

It’s why threats like fileless malware and crypto-jacking have seen substantial gains over last few years. It’s why — despite increasing employee education and IT training — hackers are still hooking phish by developing more sophisticated and authentic-looking email spoofs. Cybercriminal communities, meanwhile, continue to grow on the dark web, allowing attackers to share info, purchase exploit kits and identify potential targets.

What does this mean for CISOs? That typical defense efforts are being outpaced as familiar attack vectors are replaced with non-traditional threats. But it’s not all bad news; here are three questions every CISO needs to ask to help close the doors, bolt the windows and leave hackers out in the cold.

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

Our customers build a lot of really innovative apps that enable their users and customers to do new and cool things. These apps frequently run on untrusted client computers/devices and they control access to customer’s sensitive data or critical devices.

And after all the effort of designing, building, debugging, and deploying their applications, the last thing they want is for an attacker to steal their work or use it to look for vulnerabilities to break into their system.

Long ago, we built a Java code optimizer, but it became clear to us that our customer cared more about the obfuscation effects of the optimization than the actual performance improvement. That is when we really began to focus on app protection. First with Java, then .NET, Android, iOS, Xamarin, JavaScript, etc.

Gartner calls In-App Protection “crucial” in their July 2019 Market Guide for In-App Protection In-App Protection. The guide’s summary advises security and risk management leaders to “take due care in protecting their application clients” in order to avoid “security failure.”

This raises the question – what constitutes “due care?” Obviously, no development organization looks to recklessly expose their applications or sensitive data to attack or compromise. On the other hand, over-engineered (or poorly engineered) security controls can quickly lead to excessive development costs, performance and quality issues, and, ultimately, unacceptable user experiences. While terms and terminology may vary, there is broad consensus on how to best define “due care” for any given application/user scenario.

If you don’t follow application security closely, you might think of application obfuscation and symbol renaming as being synonymous – and with good reason. Many platforms and languages, like .NET, Java, and JavaScript have popular obfuscators that do little else--our own Dotfuscator Community Edition for .NET and ProGuard for Java are good examples. However, obfuscation is far more than symbol renaming – and in-app protection is far more than obfuscation. Much of this expansion has been driven by new security requirements, shifting attack vectors, the rise of mobile and IoT computing and, lastly, the growing recognition inside regulations and legislation of the exposure that can result from inadequately protected software.

Obfuscating jars created with the Spring Boot framework

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Latest Blog Posts

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Twitter