Archive for February, 2016

The Kobalt diaries: testing

Kobalt automatically detects how to run your tests based on the test dependencies that you declared:

dependenciesTest {

By default, Kobalt supports TestNG, JUnit and Spek. You can also configure how your tests run
with the test{} directive:

test {
    args("-excludegroups", "broken", "src/test/resources/testng.xml")

The full list of configuration parameters can be found in the TestConfig class.

Additionally, you can define multiple test configurations, each with a different name. Each
configuration will create an additional task named "test" followed by the name of
that configuration. For example:

test {
    args("-excludegroups", "broken", "src/test/resources/testng.xml")
test {
    name = "All"

The first configuration has no name, so it will be launched with the task "test",
while the second one can be run with the task "testAll".

The full series of articles on Kobalt can be found here.

The Kobalt diaries: templates

The latest addition to Kobalt is templates, also known as “archetypes” in Maven.

Templates are actions performed by plug-ins that create a set of files in your project. They are typically used when uou are beginning a brand new project and you want some default files to be created. Of course, nothing stops you from invoking templates even if you already have an existing project since templates can generate pretty much any kind of files. Here is how they work in Kobalt.

You can get a list of available templates with the --listTemplates parameter:

$ kobaltw --listTemplates
Available templates
  Plug-in: Kobalt
    "java"              Generate a simple Java project
    "kotlin"            Generate a simple Kotlin project
    "kobalt-plugin"     Generate a sample Kobalt plug-in project

You invoke a template with the --init parameter. Let’s call the "kobalt-plugin" template:

$ ./kobaltw --init kobalt-plugin
Template "kobalt-plugin" installed
Build this project with `./kobaltw assemble`
$ ./kobaltw assemble
          | Building kobalt-line-count |
----- kobalt-line-count:compile
----- kobalt-line-count:assemble
  Created .\kobaltBuild\libs\kobalt-line-count-0.18.jar
  Created .\kobaltBuild\libs\kobalt-line-count-0.18-sources.jar
  Wrote .\kobaltBuild\libs\kobalt-line-count-0.18.pom

The template was correctly installed, then it provided instructions on what to do next, which we followed, and now we have a fully working project. This one is particular since it’s a Kobalt plug-in and I’ll get back to it shortly. But before that, let’s drill a bit deeper into templates.

Templates would be pretty useless if they were limited to the default Kobalt distribution, so of course, you can invoke templates on plug-ins. Even plug-ins that you haven’t downloaded yet! Kobalt can download plug-ins from any Maven repository and run them.

To illustrate this, let’s see what templates the Kobalt Android plug-in offers:

$ kobaltw --listTemplates --plugins com.beust:kobalt-android:
Available templates
  Plug-in: Kobalt
    "java"              Generate a simple Java project
    "kotlin"            Generate a simple Kotlin project
    "kobaltPlugin"      Generate a sample Kobalt plug-in project
  Plug-in: Android
    "androidJava"       Generate a simple Android Java project
    "androidKotlin"     Generate a simple Kotlin Java project

Several things happened here. First of all, we are invoking the same --listTemplates command as earlier but this time, there is a new --plugins parameter. You pass this parameter a list of Maven id’s representing the Kobalt plug-ins you want Kobalt to install. This is similar to declaring these plug-ins in your build file, except that typically, when you run a template, you don’t have a build file yet. So this is an easy way to install plug-ins without requiring a build file.

Finally, notice that the Maven id used above, "com.beust:kobalt-android:" doesn’t have a version number and instead, ends with a colon. This is how you ask Kobalt to locate the latest version of the plug-in for you.

Kobalt responded by determining that the latest version of the Kobalt Android plug-in is 0.40, downloading it, installing it and then asking it what templates it provides. The Kobalt Android plug-in provides two templates, both of them creating a full-blown Android application, one written in Kotlin and one in Java. Let’s install the Kotlin one:

$ kobaltw --plugins com.beust:kobalt-android: --init androidKotlin
Template "androidKotlin" installed
Build this project with `./kobaltw assemble`
$ find .
$ ./kobaltw assemble
          ? Building kobalt-demo ?
----- kobalt-demo:generateR
----- kobalt-demo:compile
----- kobalt-demo:proguard
----- kobalt-demo:generateDex
----- kobalt-demo:signApk
Created kobaltBuild\outputs\apk\kobalt-demo.apk
----- kobalt-demo:assemble

We now have a complete Android application written in Kotlin.

Let’s go back to the template we built at the beginning of this article: the Kobalt plug-in called "kobalt-line-count-0.18.jar". It’s a valid Kobalt plug-in so how do we test it? We could upload it to JCenter and then invoke it with the --plugins parameter, but Kobalt provides another handy command line parameter to test such plug-ins locally: --pluginJarFiles. This parameter is similar to --plugins in that it installs a plug-in, except that it does so from a local jar file and not a remote Maven id.

Let’s install this plug-in and see which tasks are then available to us:

$ ./kobaltw --pluginJarFiles kobaltBuild/libs/kobalt-line-count-0.18.jar --tasks
List of tasks
  ----- kobalt-line-count -----
    dynamicTask         Dynamic task
    lineCount           Count the lines

As you can see, Kobalt has installed the kobalt-line-count plug-in, which then added its own tasks to Kobalt’s default ones. The Kobalt plug-in template appears to work fine. From this point on, you can edit it and create your own Kobalt plug-in.

Speaking of plug-in development, how hard is it to add templates to your Kobalt plug-in? Not hard at all! All you need to do is to implement the ITemplateContributor interface:

interface ITemplateContributor {
    val templates: List<ITemplate>

Each template provides a name, a description and a function that actually generates the files for the current project. Feel free to browse how Kobalt’s Android plug-in implements its templates.

The full series of articles on Kobalt can be found here.

Old school Apple ][ cracking

My first steps in programming probably go back about thirty-five years on the HP-38 and HP-41 but nothing will ever top the amazing times I had cracking games on the Apple ][ in the early 80s.

The Apple ][ and its DOS were extremely fertile grounds for software protection that led to some of the most fascinatingly intricate approaches to making sure that your program could not be easily copied. I’m not going to dive very deep into technical details about the Apple ][ architecture but the short version of it is that this computer let you reimplement how bytes are stored on the diskettes that you ship your software on, so needless to say that companies selling software for a living were more than happy to go ahead and do just that in attempt (mostly futile) to curb piracy.

I did a lot of cracking back in these days, mostly for the fun of it. Actually, I enjoyed getting my hands on games more for the pleasure of cracking them than actually playing them. However, one particular game resisted my attempts: “The Blade of Blackpoole”. A pretty mediocre adventure game in the style that was very popular then.

This copy protection used a lot of tricks that I just was not able to handle at the time. Remember, this was the early 80s. There was no Internet and pretty much nobody around me with enough technical knowledge of the Apple ][ to help me out. I had to figure things out on my own.

Recently, I had the crazy idea to revisit this old skeleton of mine and see if I can do better now, given all the tools and technology that the 21st century affords me. So I grabbed an image of the protected version of the game, fired a few emulators (I did this work both on Windows and Mac OS) and went to task.

It was slow at first but I was spooked to realize how much I actually remember of the Apple ][‘s internal architecture. And what I didn’t remember, the Internet happily provided for me. As it turns out, the Apple ][ cracking scene is still quite active (shout out to my inspiration for this work: a2_4am, who’s been actively cracking hundreds of Apple ][ games this past year alone]).

I carefully documented all my work cracking the Blade of Blackpoole in this document. I decided to store it in a separate file because it’s long and gruesome and goes into excruciating details about the Apple ][ and 6502 assembly. It’s not for the faint of heart, but I think you might find it interesting to follow even if you’re not completely familiar with all the technical details because it captures pretty accurately the timeless struggle between programmers who write copy protections and programmers who defeat them.

Fast forward to 2016. Copy protection is more alive than ever and the producer side seems to have struck a very serious blow to the cracking scene with Denuvo, a system that is proving extremely hard to crack and, to everyone’s surprise, which is actually an anti-temper mechanism and not an anti-piracy technology. There is so much to say about this that I’ll probable save it for another post, but in the meantime, I hope you enjoy my old school cracking report.