Obfuscating jars created with the Spring Boot framework

May 9, 2018 4574 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 NIST publication reinforces Developer Obligations (and liability)

On June 11, NIST released Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework. While a solid piece of work in its own right, this document is noteworthy because it stands as one more proof point - in an already long list of proof points, that development processes, the developers themselves, and the organizations they belong to, ALL share some degree of responsibility (liability) for:

Untrusted Environments, Valuable Apps? Put the Protection in the App.

IT environments are evolving. Disappearing are the days of in-house, fixed-endpoint, limited access server stacks — replaced instead by a combination of private and public cloud solutions, mobile applications and IoT devices.

As noted by research firm IDC, public cloud spending now outpaces all other IT infrastructure with a growth rate topping 10 percent year-over-year, while Statista reports that users downloaded more than 178 billion apps in 2017 alone — and are on track to break 250 billion over the next few years.

What does this mean for organizations? That application environments are quickly moving beyond the purview of in-house IT, exposing both apps and network services to steadily growing risk. It creates a paradox: Companies can’t deny the benefits of third-party environments and application partnerships, but also can’t ignore the threat of app and data compromise or reverse-engineering and tampering.

In a recent developer survey, Xamarin.Android developers were 50% less likely to have included rooted device detection or anti-tamper prevention as their Java Android peers were. Yet, both sets of apps are being deployed through the same marketplaces onto the same devices and are governed by the same regulations (PCI, GDPR, HIPAA to name just a few that expect these kinds of controls).

Why are more Xamarin.Android apps going unprotected?

I recently had the opportunity to sit down with Sebastian Holst, PreEmptive’s Chief Strategy Officer, to talk about his most recent trip to Capitol Hill where the topic of the day was copyright protection for small businesses – and for development shops in particular.

The life of a security architect is rarely simple. Assessing, defending and improving corporate networks requires thorough knowledge of industry best practices designed to secure critical data, combined with real-world understanding of hacker tricks and tactics meant to undermine this purpose.

As noted by the InfoSec Institute, this is an in-demand job that often comes with high expectations, odd hours and the need for constant professional evolution to stay ahead of cybercriminal threats. Complicating matters is the breakneck pace of technological advancement. The rapid rise of cloud deployments, mobile applications and IoT devices can make even best-laid security strategies seem like flies in amber — hopelessly out-of-date and effectively immobile.

Here’s a look at what’s really bugging security architects — and how they can break the mold of static security to combat emerging threats.

Obfuscating jars created with the Spring Boot framework

Latest NIST publication reinforces Developer Obligations (and liability)

Put the Protection in the App

Untrusted Environments, Valuable Apps? Put the Protection in the App.

Are Xamarin.Android app users at risk?

Changes are coming for US Copyright – Should Developers Even Care?

Fly in Amber: What’s Bugging Infosec Architects?

Latest Blog Posts

Latest NIST publication reinforces Developer Obligations (and liability)

Put the Protection in the App

Are Xamarin.Android app users at risk?

Changes are coming for US Copyright – Should Developers Even Care?

Fly in Amber: What’s Bugging Infosec Architects?

Twitter