I am happy to share some amazing news here. I will briefly talk about each point and have more details below, so you can first read the TL;DR version and then jump to the detailed versions.

First and foremost, the team behind ARTist proudly presents our beta release! This is a major step that includes the new module sdk that allows to create modules locally on your machines without requiring a setup AOSP build & environment. Batteries are included, the beta comes with a build toolchain, documentation and a template module to give you a head start. We are really excited about this and look forward to what you will build with it =)

Second, in order to spread the news about this new tech, we applied for speaking at well-known conferences where we can reach Android developers and researchers, and guess what? We got accepted into droidcon Berlin (end of June) and Black Hat USA (beginning of August). More details below.

Well, it’s a lot, so let’s tackle one thing after another.

Beta

Since the initial release during EuroS&P last year, we have been busy to continuously improve ARTist and its ecosystem. However, from all the improvements we have been preparing, there was one thing that we really strived for. Something that has been envisioned since the very beginning and that will save all of us a lot of hassle when further working with ARTist: The module SDK.

When we started, ARTist was a nice project that was hacked into the Android Runtime (ART) and hence required to set up a complete build environment for AOSP, which is not only a daunting task to many, but also requires substantial resources in terms of computing power, storage and also personal time. It was always clear that this was not optimal and there have to be better solutions. At first, we worked around this by creating helper scripts to quickly build ARTist in the context of AOSP and to deploy it via an app (ArtistGui) so there was no need to run a custom emulator, and so on. But while we extracted the initial use case we had for ARTist (taint tracking) and wrapped it in a general instrumentation framework, the resulting modularization was the first important step towards broader applicability. But it had to go further. It’s been a long time since then and fast forward to today, we finally managed to extend the modularization to get rid of the AOSP requirement when building modules. The module SDK is essentially a compilation of compile-time dependencies required to build ARTist modules that can be installed on your system (deb, rpm , or manually via zip). It contains the full build toolchain so everything you need to do now to build ARTist modules is to fork the template-module and CodeLib repos, implement your ideas and run a regular make in the module project. The SDK will do all the heavy lifting. We are very very excited about this and we welcome any feedback on the matter.

While the main feature of our beta is clearly the module SDK, there are other maybe more subtle changes and improvements that are worth noting. We are well aware of the fact that in particular art and ARTist have complicated inter-dependencies and therefore it is not always immediately clear which states or commits are compatible with each other. Add other projects like the module SDK and ArtistGui to the mix and it will become even more confusing. To remediate this problem, we are introducing a versioning scheme for all projects that allows to decide which components are compabitible with each other. Let me outline the most important ones. Since art and ARTist are dependent on each other, they will share a version number so you always know which versions can be paired. Furthermore, we will use semantic versioning and the corresponding API will be the one exposed by ARTist. In case you missed it, we recently introduced a new folder structure for ARTist that differentiates between api and internal. Changes to internal will only trigger patch version bumps, changes to api will change the version depending on whether it will break compatibility (i.e., signature changes). We will generate an artifact for each art/ARTist combination that will include the libraries and dex2oat binary we have always been using in ArtistGui. Also, by definition we need new module SDK versions for all but patch versions. So those will be generated as well and also carry the art/ARTist API version number. Non-library projects like ArtistGui will also receive versions and there will be artifacts as well, in our case with the correct art/ARTist artifact embedded.

Of course there is more and if you are interested, you can have a look at our new branching model for GitHub, the new filesystem helper, our support for compiling the system server and other system components, and so on.

On a side note, since this a beta, everything is experimental and bleeding-edge by definition, and hence if you find problems let us know in Gitter or GitHub. Also, we are currently only able to support Android 7 & 7.1 with the full palette of beta changes, but we are working on also bringing Marshmallow and Oreo up-to-date again. Also, due to the fact that we did not really find a way to write to any directory during the system server compilation, the new module SDK way of writing modules for ARTist only works through ArtistGui and NOT if you use ARTist as an alternative to the system compiler. We always try to operate in the least intrusive way possible but adding filesystem helper support and module loading to the system server would right now require to change or subvert dex2oat’s SELinux policy, which is clearly NOT what we want. If you have any ideas, let us know.

Finally, after you made it through this wall of text above, please feel free to try and use ARTist and the other projects, and let us know what you think. We have ready-made versions of ArtistGui with the correct ARTist binaries, and precompiled modules that can be installed into ArtistGui from the user interface. Just have a look at our binaries page. In the end, we want developers to use ARTist and write own modules, so don’t be shy =)

Droidcon Berlin

Having our new and shiny module SDK in place, the one thing we want to see happening is the creation of fun and helpful modules. And what is the best place possible to reach Android developers with an open mindset that are hungry for the newest tech and ideas? Right, this sounds a lot like Droidcon, the annual Android developer convention. In our case, I applied to give a talk about using ARTist to analyze and modify Android applications, and I was lucky enough to be chosen one of the speakers for this year’s event in Berlin. I am particularly looking forward to talk to as many Android developers as possible to hear what they think about ARTist and where to apply it. In the end, I envision a rich set of publicly available ARTist modules that can be downloaded into ArtistGui to analyze, extend and also secure your apps. Are you attending Droidcon Berlin this year and want to chat about ARTist? Drop me a message!

Black Hat USA

This year, it seems I am incredibly lucky with my (non-academic) submissions since I also made it into Black Hat USA, one of the world’s most biggest and renowned hacker conferences. In my talk, I will shed some light on how to employ ARTist to build security-relevant app modifications and reverse app internals. Coming from the security community, this topic is particularly close to my heart and I am looking forward to receive feedback from industry veterans and attendees.

Conclusion

If I would need to summarize this post, it would be:

ARTist is easier to use and more powerful than ever, and I am looking forward to present it at droidcon & black hat this year to collect opinions and feedback.

Also, if you made it down here, I want to say thank you for your interest in our project. The team appreciates it =) And while we are talking about it, a huge thank you to all of you who helped and worked on the various part of the ARTist ecosystem. Anyway, hope you are following along since we are planning a lot of interesting stuff, including some nice & fun modules in particular for the security domain.

~schrnz