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.
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
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
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
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
internal. Changes to
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
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
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
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
policy, which is clearly NOT what we want. If you have any ideas, let
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 =)
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.
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.