Can we obfuscate spring boot war file ?

[mazaharulhq]

Can we obfuscate spring boot war file ?

[thomasbehr]

yGuard does not support war files. You need to rebundle your code into a "regular" jar (i.e. no code in BOOT-INF), obfuscate the regular jar, repackage the obfuscated jar for Spring Boot (and place it back into a war file, I guess).
The processing example shows the necessary steps for Spring Boot jars.

[Fargys1879]

I obfuscate springBoot app like this with gradle

task obfuscate {
    dependsOn jar
    group 'yGuard'
    description 'Obfuscates and shrinks the java archive.'
    doLast {
        ant.taskdef(
                name: 'yguard',
                classname: 'com.yworks.yguard.YGuardTask',
                classpath: sourceSets.main.runtimeClasspath.asPath
        )

        def archivePath = jar.archiveFile.get().asFile.path

        ant.yguard {
            inoutpair(
                    in: archivePath,
                    out: layout.buildDirectory.file("tmp/example-plain-obf.jar").get().asFile.path
            )
            rename(
                    mainclass: 'com.example.ExampleApplication',
                    logfile: "${buildDir}/${project.name}_renamelog.xml",
            ) {
                keep {
                    'attribute'(
                            name: 'MethodParameters'
                    )
                    'class'(
                            name: 'com.example.ExampleApplication',
                            methods: 'private',
                            fields: 'private'
                    )
                }
                property(name: "error-checking", value: "pedantic")
            }
        }
    }
}

tasks.register('rePackObfuscatedClasses', Copy) {
    dependsOn obfuscate
    description 'Read obfuscated plain jar and move all *.class files to build/classes directory.'
    delete layout.buildDirectory.dir("classes/java/main/com")
    from(zipTree(layout.buildDirectory.file("tmp/example-plain-obf.jar"))) {
        include "com/**/*.class"
        eachFile { fcd ->
            fcd.relativePath = new RelativePath(true, fcd.relativePath.segments.drop(1))
        }
        includeEmptyDirs = false
    }
    into layout.buildDirectory.dir("classes/java/main/com")
}

task deleteLibs(type: Delete) {
    description 'Remove build/libs directory.'
    dependsOn rePackObfuscatedClasses
    mustRunAfter rePackObfuscatedClasses
    delete layout.buildDirectory.dir("libs")
    followSymlinks = true
}

bootJar.configure {
    dependsOn deleteLibs
    mustRunAfter deleteLibs
}

[thomasbehr]

@Fargys1879 Extracting an obfuscated jar to the file system is kind of dangerous. yGuard may produce class names that only differ in casing (like A and a). This will cause problems in case-insensitive files systems like the Windows file systems. yGuard might even create class names that contain characters that are not allowed in filenames in your file system.

[Fargys1879]

Do you have a guide on how to correctly do obfuscation for the boot Jar command in gradle? The fact is that ant.guard {...} produces a plain-jar (not executable) and it does not participate in the creation of an executable jar file.SpringBoot jar has its own structure with BOOT0-INF

[yGuy]

What's wrong with the approach in comment#2 ?

[thomasbehr]

The "guide" is my first comment and you are not far off: instead of extracting the obfuscated jar to the filesystem, copy the obfuscated classes from the obfuscated jar to your Spring Boot jar directly. (I do not know how to do that with Gradle, but with ANT this is accomplished using a zipfileset.)

[Fargys1879]

The comment contains a link to an example only for maven config.Some developers using gradle would also like to see an example of the configuration.Because it is not quite obvious how to use zipfileset in the gradle.

[yGuy]

So this looks more like a gradle question to me. Not so much a yGuard question, which is an Ant Task for working with jar files.

Adding support for spring boot war files is currently not on the roadmap, but has been requested before. If someone creates a PR, we are happy to review, but it should be "small" and layered on top of the existing functionality as we do not want to increase technical debt in the core just to support yet another non-standard tool or file format.