yGuard is now open source - obfuscation easy as pie

L. Berger — Wed, 08 Jan 2020 14:53:21 +0000

Disclaimer: This is not a sponsored post. However so my current employee pays me for maintaining the repository, so it's fair to mention them.

I work for a company called yWorks. They make libraries for graphs that are (imho) state of the art, and also are a fun company to work at 🍺

Because these libraries are sophisticated the company is very inclined to protect their intellectual property. In the golden age of Java (which was right about the time they put this onto the market) it would have been crucial to implement some sorts of protection in order to ensure this IP. This is why yGuard was initially developed (side note: when I first touched the repository, some assets were as old as 11 years).

I love open source - period. Knowing this, my CTO approached me a while ago, certain I would be all 🔥 for making this product available for a wider audience. We had a brief discussion and off I went on my journey to make it open-source.

I made a checklist of things that needed to be addressed before releasing it to the public on GitHub:

relicense everything that can be relicensed ✅
replace proprietary code with libraries or rewrite it if necessary ✅
replace ancient build system and dependencies with up-to-date ones ✅
set up tests and CI so it stays in good shape ✅
add extensive documentation and sample code ✅
add contribution guidelines ✅

With this list done, I'm thrilled to announce: we released yGuard into the wild (a while ago)!

This post however should not only be a mere release announcement, but I am going to put some sample code here, so it becomes clear what this obfuscation actually does 💡

Say, we have a rather complete Java application that has an entrypoint like so:

package com.yworks.example;

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

Now, given we use Gradle as our build system, we could use a very simple yguard task to obfuscate the resulting .jar

task obfuscate {
  dependsOn jar

  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: archivePath.replace(".jar", "_obf.jar"))
      shrink(logfile: "${buildDir}/yshrink.log.xml") {
        keep {
          method(name: "void main(java.lang.String[])", "class": application.mainClassName)
        }
      }
      rename(mainclass: application.mainClassName, logfile: "${buildDir}/yguard.log.xml") {
        property(name: "error-checking", value: "pedantic")
      }
    }
  }
}

This tells the build system:

configure an Ant task so we can use yguard
execute the yguard task with an input and output .jar
shrink the resulting .jar, leaving only classes and methods that are loaded from main
obfuscate all class names, function names, variable names, ... except for main

Once we call gradle obfuscate this will produce an obfuscated .jar, leaving nothing but a weird trail of characters in the file names and classes.

Did you notice the logfile property? This is the best part. We can use the mapping established during obfuscation to unscramble stacktraces!

I could write a rather lengthy article about all the possible configurations that you can use, which would far exceed a simple introduction. Maybe someday, somewhen I'll give a nice talk about how it all works 😎. In the meantime, please have a look at the extensive documentation and examples, which covers all of these options.

Why "babeling"-up harms the open source community

L. Berger — Wed, 08 Aug 2018 14:43:21 +0000

Preamble

This article is meant as a discussion in particular about the technical attitude towards progressiveness. It is in neither way meant to insult or diminish the great work of the folks behind babel or similar tools that are mentioned. Please keep it up, you rock and the open source world definitely needs you!

"Babeling-up" and why it harms us

So you've built that brand new website, or service, or piece of code. Now it's time to go awesome and ship it to the world! Okay, let's make a checklist

[x] make sure all bugs are fixed before release
[x] make sure you have an awesome release name
[ ] make sure it runs everywhere
[x] package it, upload it. There you go. The world loves you ❤️

Now. The third part on our list is particularly cumbersome. From my experience working with the folks behind Inexor I know that this can be almost all the work. You think you're done with shipping an amazing release, but the pages turned against you and it's double the amount of time now to get it work everywhere. So this happened to me once, twice, a third time, over and over. Full stop. One time it took me and my coworkers an entire week to make our latest feature available on IE10. I was wondering why it'd had to be this way, and it kind of makes sense for the commercial sectors. However, there is a worrying trend in the open source community, that tries to workaround this issue. Some projects that spring off my mind are:

TypeScript
CoffeeScript
Babel
Webpack

These all try to solve a common problem: bring an new featureset to older platforms.
We are trying to comfort our users with polyfills, and at the end of the day we've spent an insane amount of time supporting all of the deprecated environments out there. I'd say this has to stop.
The question that came up next in my mind was: "how do we make our technologies more progressive". I remember when I once helped a colleague of mine submit a feature proposal to the python committee, and as far as I can tell, it was an awfully hard experience. Reading through the W3C standards group, and the ECMA standards proposals is neither satisfying.
It should be significantly easier to write and test enhancements. This is particularly true for browser standards, where a new idea can take years to centuries to be implemented. Therefore I suggest to those projects (yes, I am looking at you libcef, although you do much better recently) to provide mechanisms to write and ship language and framework enhancements conveniently.

Why pushing the implementation burden isn't enough

Given we had those amazing API's and workflows to write enhancements, that wouldn't really change a thing. It's a good first step towards progressing technology. In the aftermath though it doesn't really change a thing. When we take a closer look at the history of software industry, there has been a huge efforts to improve this situation. Why hasn't it succeeded yet? The answer is pretty much: mindset. Most developers fear the urge of unpleasing their users with updates. This might be unfeasible for a business. For open-source, this attitude actively hinders development. We, as a community should be forcing users to keep at pace. Why support IE10? Why support Windows XP? Honestly, nobody should use that, and we should protect the software community as a whole from using deprecated environments. This is an encouragement article! Don't fear your users. Break their workflow. Progress open source. Only with a mindset where we force users to use up-to-date environments, change will finally come.
So please: next time you start a new project, don't use babel, don't use python2, don't use node4. If your user can't switch their environment, it's certainly not your responsibility to deal with. Remember: You give your free time and effort to that project. If your user can't update because he or she is in a protected environment, hack, they should demand their administrators to make it possible!. Only such an attitude will put enough pressure on the end users, hence make progress possible.

DEV Community: L. Berger

yGuard is now open source - obfuscation easy as pie

Why "babeling"-up harms the open source community

Preamble

"Babeling-up" and why it harms us

Why pushing the implementation burden isn't enough