ARTist - A Novel Instrumentation Framework for Customizing and Analyzing Apps
Schranz, Oliver
In this talk, I will give an introduction to a novel instrumentation framework called ARTist, the Android Runtime instrumentation and security toolkit, which allows to arbitrarily modify the code of installed apps. Similar to existing approaches, such as Frida and XPosed, this can be used for modding applications (adding or removing functionality) and app analysis (record traffic, change files, modify databases). However, it does not break the app signature and hence modified applications still receive updates without compromising on security. Additionally, it is capable of modifying not only apps, but also the system server (Package Manager, Activity Manager Service, ...) and application framework classes (everything within framework.jar, ...). I will first outline the basic architecture of ARTist that is built on top of the Android Runtime's (ART) on-device compiler. We will have a look at the underlying design decisions and the deployment options, from regular (rooted) devices to custom ROMs. Then, I will introduce the ARTist SDK that allows developers to easily create own Modules to adapt the functionality of their favorite apps to their needs. The goal is to make you comfortable with creating own extensions for your installed apps. And finally, it will showcase some interesting Modules for different use cases, such as app reversing and analysis for pentesters and researchers, and app customization and modding for developers and power users. By the end of this session, you will be able to judge which problems ARTist can solve and how to get started with your first Module right away.
 Hi everyone, my name is Oliver Schrands, PhD student and researcher at the CIS Biomass Institute. So actually on the large research site at Zahn University and today I'm going to talk about the research of us based on Android security. So what we're doing in this talk is actually instrumenting, so modifying and analyzing random third party applications. All right, so as we're coming from the security domain, there's quite a lot of motivation behind this because there's a lot you can do with app instrumentation and modification. For example, you want to analyze and reverse apps, of course, particularly the bad ones, but generally you want to understand what's under the hood, what's going on. You want to do some app behavior monitoring, you want to see what the app is doing at runtime. In some cases you even want to hot patch vulnerabilities, which means you want to patch vulnerability in the app without relying on the developer to patch them. For example, we had this in earlier talk, we have a lot of vulnerabilities in libraries and this might be a possibility to patch the library in an app without waiting for a new app release. So this is typical examples how we use modification on the app analysis in the security domain, but there's also a lot of use cases outside of that. So hands up whoever heard of XDA. Quite some. Okay. So very broadly, XDA is a developer community for people that like to roughly speaking make Android their own, which means they want to mod applications, they want to mod the operating system and they just want to apply any changes here. So it could be anything from just patching YouTube so it keeps playing music by going to the background, just dropping ads or whatever you can think of, you can even paint Facebook red, even though that's probably not very useful, but you could do it. So this is actually the main we're coming from. We want to do modification of apps and we have quite some use cases for that. And what we're actually coming from here is at some point we saw that there is a new thing in Android called Android runtime, it was already mentioned today this morning in the keynote and the idea is that we now have a native compiler on the device that is translating our byte code to actually native code of this platform. So let's have a look at how it works out. So there's this new component called Dex2Oat because it literally translates the Dex byte code to a new native file format. So essentially OAT files, old files are on ELF files, which is received a new name. And if you follow the flow here, we first transform this Dex byte code into an intermediate representation, which is really common for compilers. And then the compiler is invoking some optimizations on that, so everything from that code emulation to constant value propagation, so on so, the usual things. And this is something that Google created from scratch. So we now have a complete compiler framework on the device itself. And the reason that many people didn't even notice is because Google did really a great job of hiding this. You still write your apps in Java and Kotlin, have byte code, translate it to Dex byte code and now actually execute native code. But you never get ZegFold. You just get null point exceptions because they embed the complete Java semantics into the native code, which is kind of nice. So actually as developers, we don't see this quite often. We don't care about art at all. But at some point we decided this is quite interesting, so we wanted to have a look. And what we did here was we embedded a complete instrumentation framework into this compiler. So this is what we call artist. The Android runtime instrumentation and security toolkit. And if you have a look what actually changed is that we added a pre-processing step. So first we have an arbitrary Java library or Kotlin library that we merge into the app. So if I want to modify an application, this is actually my business logic. Something that I want to add to the app. For example, an inland reference monitoring implementation or chain tracking, whatever. So this is merged into the app. And if you know a bit about APKs, you know that by this I actually break the app signature, which means it doesn't get any updates now. This is actually a problem for us, but I will come to that. And then this new code also includes our code, is transformed to its intermediate representation. And the very interesting step here is that we added another step here. And this artist instrumentation essentially is applying all the changes that we want to have in the app. So kind of this code that's executed now is stitching together the original app and a new app code. So kind of this is the duct tape. This is the glue sticking everything together. And what's really nice about the solution is that this is completely transparent to the compiler. The compiler believes he's just executing arbitrary optimizations. Because we're used to optimizations changing the code a lot, it doesn't bother that we are actually changing the code at will here. And in return, this means we can change it at will. And we can do anything. And the good thing here is that we are completely platform-independent because this happens before the code generators kick in and generate native code. So this works out of the box for all hardware platform for Android. Second, we have closed in a runtime overhead because we don't have any expensive fucking like expose or something. We just do this in the compiler. It's a compiled app and then we're done with it. Also I mentioned the app signature. And this is a common problem of bytecode instrumentation approaches where people just change the APK with, for example, APK to repackage it. We don't have this problem right here because we're only working on this copy over here. And actually we don't change the original APK. And the copy is just dropped afterwards. We just change this compiled version. So in the end, everything we need to do is we take the new compiled version, the new OAT file, and replace it with the old one. So this is kind of a swap operation. And we can redo this any time. So we can also revert this. And this is not very intrusive, which means we're not touching the operating system at all. Including we are not touching the original compiler. So actually how do we deploy this then? If we don't replace the original decks to old with our version of artist. So the idea is that we have a wrapper application. Since I'm horrible at names, I just named this artist's GraphQL user interface. So the idea here is that we take the new compiler version and you can think of it just as a binary. You invoke it with arguments and the arguments being installed applications. And it outputs OAT files. So what we do here is we use artist.goo. And people can just select applications they have installed, click on instruments, recompile, whatever. And then in the background, we execute our artist framework. And now we have a new OAT file and the original one that the system generated. And we hot swap this. So actually after that, the application that will be run will be the new one. And as I said, you can revert this at any time. So now it completely depends on what you actually want to do with that. So we are very generic to the instrumentation framework. So what we're actually changing about the code is up to the module developer. But I'll get to that later. Very briefly, you can also do this in the operating system. So if you're not focusing on running on stock devices, if you want to have your own A with P fork or do this on your own device, you can of course replace the original compiler with our version. And then of course you lose this, that you don't change too much about the system. But you can also instrument not only apps, but also system components. As you can see on the one side here, services jar. This is actually the jar that complains to complete system server, which means package manager service, application, activity manager service, all this stuff. So this is roughly 25,000 methods written in jar. And for the fun of it, we wrote a module that will instrument them. So into all those 25,000 methods, in each single basic block in the control program, we injected a call that used reflection to get the method name. I know it's dirty, but still there with me for that one. And this method name is then printed to lockhead. So this is quite a lot, right? For everything that's happening in Android now, there's lockhead entry with the name of the method. And actually this works quite well. So if you run this on x86 emulator, it's hardly slow, of course, but it works, proving that artists are really robust and also are scaled. We have quite some interesting products here, instrumenting the compiler and the operating system. But due to time constraints, just ask me later if you're interested. All right, at this point, you might be interested in why am I introducing yet another instrumentation framework. Well, we have exposed. And maybe some of you heard of Frida, anyone? OK, I see some hands. Well, it's a bit more popular in the kind of flurzing domain. So let's have a look why another one. We believe that artists will first kind of a sweet spot in the design space, because on the one hand, we are in contrast to Frida, not only targeting developers, but also end users. So if you don't need a device or device connected to a PC and an ADB connection, we just need to install artists going on a router device. That's it. And actually, the route is just required for this one step where we change the compiled version of the original one from the system with ours. That's the only step. So actually, route is way overprivileged for our case, but if you don't want to change the operating system, we cannot do a thing about it. So as a leaguer, time would be perfectly fine, but unfortunately, we cannot do this right now. So in general, as you can see in the table, the idea is that we are not very invasive. We don't need any custom recovery. You don't have to flash anything. Just a regular user having a router device downloading your app, importing modules, and you can freely start modifying applications and analyzing them at will. So I've been talking about modules a bit, so let me make sure we're on the same page about that. Whenever I've heard you in modules, I'm talking about kind of a world-structured, abstract functionality that is self-contained. For example, I mentioned earlier, I can have 10 tracking, I can have ad blocking, and all of those would be modules. Think of them like niggle stones that you just put on other apps. You can just add this, this modular functionality. You can inject it into arbitrary applications. Well, from ARTIS, you have actually two parts. We already saw there's an optimization pass, so whatever the compiler believes is actually an optimization, but it's a glue code. And then what we call the code clip is just a random Java or Kotlin library that you write. So you write all your business logic in Java and Kotlin, and then it will be injected into the target app, and the ARTIS optimization pass is kind of stitching all the pieces together. And of course, we also have some metadata like the maintainers on. So this is pretty new, but we're expanding on that. So let's make an example. Whoever heard of the Stevo library? Cool. Nice. Then I don't have to explain a lot. I'm a big fan, I have to say, because if you have to, actually, in your debug version of the app, it connects your app to the Chrome developer tools. And you can do a lot like intercepting network traffic, read all the files, access a database. There's a lot you can do. You can even execute JavaScript in the context of an app. That's a good idea. It's a different thing, but it's possible. So I said this is meant to be included in the debug version of your app. But what if there are some researchers that try out to inject this into arbitrary applications? And this is exactly what we did, and I will try a live demo now. Let's see if that one is working. All right. So you should see now my device here. Good. It works. And you see the Chrome developer tools. So actually, we haven't connected now. I just skipped instrumentation part for time reasons. And we can have an impact here on the complete UI. We can inspect it. We can change the values. We can also, let me just reload this, we can see live to traffic coming in here. We scroll a little bit. As you can see, as you're used to when working with web apps, and TLS doesn't scare us here because we're getting all the traffic before it is encrypted or after it was decrypted. And what you can do is put this pretty cool is you can have a look at the databases. So what you see is a regular Reddit app. We didn't change anything, but applying one of our modules. So this is the one from Google Play Store, and you can probably just redo this demo at some point. And we can have a look, for example, in the database where you have different subreddits. You can see which one actually has advertisements or not. You can see all the descriptions. It's not that nice on the screen right now, but I invite you to check this yourself as soon as we're also releasing the server module. So in general, I just wanted to show you, you can do quite a lot. And whatever you can change in the code, you can do with artist. So at some point, even some of the heevees had some fun and added here to several recommends to the Google Play Store or like this really nice post-effect overflow. Of course, that actually never existed. It was just locally on the device, but it's nice for some fake screenshots, right? Okay. Of course, we did also some more meaningful modules, particularly as part of our research. So in the original paper, we had the taint tracking system, which means we're following the flow of information through a program and try to reconnect all the different information flows. And the idea was that if an application is, for example, reading your local files or some pictures, is this application in the end sending this to the internet? And of course, then we want to ring an alarm and ask a user if that's actually what the user intended. It's quite involved and also prototype, but it's also a second product that I really like and this is actually joined by a couple of my colleagues that's also here. So the idea is that we took apart an application, we moved the complete advertisement code into a different app. So what used to be a regular library call is now an inter-process communication. And we reconnected it through a custom binder protocol and all of this on a rooted stock device. So no operating system, the changes involved, which is the magic of artists. So this worked kind of well for advertisements. It was just still displaying the advertising as a remote floating view on top of the app. The user didn't see any difference, but now from a system perspective, you would argue that the advertising library is now what we call a distinct security principle, which means the system can distinguish between library and application. So it can now revoke permissions only from the library or only from the application without impacting the other, which is kind of nice. So we're doing quite a lot here, but again, for time reasons, if you're interested in that, just drop by and ask us something. So if you want to create all modules, for example, if you want to instrument this awesome Broadcom Berlin app, then you can do so because everything is open source. We have an SDK now. This is helping you writing this native code. You know how to write Java encoding code. For the native code, it's a bit involved. We have a template code lab and template module, the two parts that stick together. And actually, after checking them out from GitHub, you can change them. You just have to build them by running a single make command because we already have all the build tools and some make scripts ready. So this is straightforward. Push the module, which is a zip file to the device. And Archus Gui actually has a UI where you can just tap on the plus and then you can select it from the file chooser. So it is really straightforward. And then you have this nice screen where you choose the applications. You can choose which modules you want to apply and you can change this at any time for each application. So this is actually on demand. We just entered the beta phase. Like on Friday, the last things were published and also versioned and so on. So we tried to follow semantic versioning. We heard earlier that it's very important. We have this new module management in the SDK and some new documentation. So I ask all of you interested in that to try it out. And of course, we're not done yet, not even close. On the developer side, we want to be more professional about this, like having automatic releases, having more tests. We want to have a public module place, like you know it from XPost, where people just can maybe immediately from the app download modules from the web and just apply them to the applications. And there's one student of mine working on the bridge between XPost and Altist. So some of the XPost modules are automatically translated to an artist module, which means the store would start with just immediately hundreds of modules readily available. And again, if you just don't want to kind of flash something through the device and just want to route it, then probably artists might be an option for you. And also what I showed you, replacing the system compiler to kind of instrument the system server and framework class and so on. Maybe you can even get to that point without changing the compiler. Maybe you just have to again recompile everything, switch the files and reboot the device. I'm not sure, but I think this is possible. So let's see. So in the end, this is a community project. Well, it's pretty young. We are not that many developers right now, but it's actually bleeding edge research. So please have a look. Tell us what you think. We're really waiting for feedback. And since we're pretty young project, you can already get the same project. So if you kind of want to contribute and have some interesting use cases, then just let us know. We are happily talking about this. Talking about which, we have a Jitter Chat and we have most of it. So everything besides the step-by-step module right now, I have on GitHub. And essentially, that's it. So I want to say thank you for attending the talk. And I'm happy to take any questions now. Thank you. Thank you so much. Questions? Perhaps about the community for how long have you been working? Well, actually, the roots of this project go back until end of 2015. So actually, I started this as my master thesis, the initial version of Artists, but it was pretty focused. It was a team-tracking part. And after that, we noticed, well, if we have this compiler, it has pretty nice opportunities. And it just created a generic instrumentation framework from that. So this is actually the reason where we started. And from that, we just iterated. And with new research projects, we extended the API because we needed new modules. So I think, well, we started, yes, we started 2015 and was open sourced last year. But just this new iteration, what we just called it, the first beta version, I released just on Friday. So right in time for DroidCon. Thank you, Sumit. Thank you. Any other questions? Hi. So having worked with Xposed a lot before, do you have any way to better deal with obfuscated apps, like AppStudios ProGuard? How do you instrument those? Because methods, signatures, names, they change all the time with every update. I see. Well, this is actually a shared problem. So Xposed, well, as you said, you have the problem, it's hard to detect the method you want to target. For artists, you have similar problems because most of the filters or most of the modules right now are written against a filter API. And most of the time, you just search for method name. But we have one advantage, which is, I did very briefly on the table, that Xposed is working, the funds I know on the method level, like you can hook a method, replace it. But artists is working on the instruction level, which means you can even kind of detect a method and just change a plus to a minus or something, which means you can be way better in fingerprinting methods. If you know enough about your method, you can find it outside of the method name just by looking at the code, for example. You still have the problem of obfuscation, so this is shared, but it might help you. So you can get even deeper into that. Because I really have to think about this, you see the complete code in the contract, in control flow graph, each instruction is represented in this representation as kind of an object. So this object-oriented version of the code. This is kind of nice. You can work with that and you can extend it as well.
 Hi everyone, my name is Oliver Schrands, PhD student and researcher at the CIS Biomass  Institute.  So actually on the large research site at Zahn University and today I'm going to talk  about the research of us based on Android security.  So what we're doing in this talk is actually instrumenting, so modifying and analyzing  random third party applications.  All right, so as we're coming from the security domain, there's quite a lot of motivation  behind this because there's a lot you can do with app instrumentation and modification.  For example, you want to analyze and reverse apps, of course, particularly the bad ones,  but generally you want to understand what's under the hood, what's going on.  You want to do some app behavior monitoring, you want to see what the app is doing at runtime.  In some cases you even want to hot patch vulnerabilities, which means you want to patch  vulnerability in the app without relying on the developer to patch them.  For example, we had this in earlier talk, we have a lot of vulnerabilities in libraries  and this might be a possibility to patch the library in an app without waiting for a new  app release.  So this is typical examples how we use modification on the app analysis in the security domain,  but there's also a lot of use cases outside of that.  So hands up whoever heard of XDA.  Quite some.  Okay.  So very broadly, XDA is a developer community for people that like to roughly speaking make  Android their own, which means they want to mod applications, they want to mod the  operating system and they just want to apply any changes here.  So it could be anything from just patching YouTube so it keeps playing music by going  to the background, just dropping ads or whatever you can think of, you can even paint Facebook  red, even though that's probably not very useful, but you could do it.  So this is actually the main we're coming from.  We want to do modification of apps and we have quite some use cases for that.  And what we're actually coming from here is at some point we saw that there is a new thing  in Android called Android runtime, it was already mentioned today this morning in the  keynote and the idea is that we now have a native compiler on the device that is translating  our byte code to actually native code of this platform.  So let's have a look at how it works out.  So there's this new component called Dex2Oat because it literally translates the Dex byte  code to a new native file format.  So essentially OAT files, old files are on ELF files, which is received a new name.  And if you follow the flow here, we first transform this Dex byte code into an intermediate  representation, which is really common for compilers.  And then the compiler is invoking some optimizations on that, so everything from that code emulation  to constant value propagation, so on so, the usual things.  And this is something that Google created from scratch.  So we now have a complete compiler framework on the device itself.  And the reason that many people didn't even notice is because Google did really a great  job of hiding this.  You still write your apps in Java and Kotlin, have byte code, translate it to Dex byte code  and now actually execute native code.  But you never get ZegFold.  You just get null point exceptions because they embed the complete Java semantics into  the native code, which is kind of nice.  So actually as developers, we don't see this quite often.  We don't care about art at all.  But at some point we decided this is quite interesting, so we wanted to have a look.  And what we did here was we embedded a complete instrumentation framework into this compiler.  So this is what we call artist.  The Android runtime instrumentation and security toolkit.  And if you have a look what actually changed is that we added a pre-processing step.  So first we have an arbitrary Java library or Kotlin library that we merge into the app.  So if I want to modify an application, this is actually my business logic.  Something that I want to add to the app.  For example, an inland reference monitoring implementation or chain tracking, whatever.  So this is merged into the app.  And if you know a bit about APKs, you know that by this I actually break the app signature,  which means it doesn't get any updates now.  This is actually a problem for us, but I will come to that.  And then this new code also includes our code, is transformed to its intermediate representation.  And the very interesting step here is that we added another step here.  And this artist instrumentation essentially is applying all the changes that we want to  have in the app.  So kind of this code that's executed now is stitching together the original app and a  new app code.  So kind of this is the duct tape.  This is the glue sticking everything together.  And what's really nice about the solution is that this is completely transparent to  the compiler.  The compiler believes he's just executing arbitrary optimizations.  Because we're used to optimizations changing the code a lot, it doesn't bother that we  are actually changing the code at will here.  And in return, this means we can change it at will.  And we can do anything.  And the good thing here is that we are completely platform-independent because this happens before  the code generators kick in and generate native code.  So this works out of the box for all hardware platform for Android.  Second, we have closed in a runtime overhead because we don't have any expensive fucking  like expose or something.  We just do this in the compiler.  It's a compiled app and then we're done with it.  Also I mentioned the app signature.  And this is a common problem of bytecode instrumentation approaches where people just change the APK  with, for example, APK to repackage it.  We don't have this problem right here because we're only working on this copy over here.  And actually we don't change the original APK.  And the copy is just dropped afterwards.  We just change this compiled version.  So in the end, everything we need to do is we take the new compiled version, the new  OAT file, and replace it with the old one.  So this is kind of a swap operation.  And we can redo this any time.  So we can also revert this.  And this is not very intrusive, which means we're not touching the operating system at  all.  Including we are not touching the original compiler.  So actually how do we deploy this then?  If we don't replace the original decks to old with our version of artist.  So the idea is that we have a wrapper application.  Since I'm horrible at names, I just named this artist's GraphQL user interface.  So the idea here is that we take the new compiler version and you can think of it just as a  binary.  You invoke it with arguments and the arguments being installed applications.  And it outputs OAT files.  So what we do here is we use artist.goo.  And people can just select applications they have installed, click on instruments, recompile,  whatever.  And then in the background, we execute our artist framework.  And now we have a new OAT file and the original one that the system generated.  And we hot swap this.  So actually after that, the application that will be run will be the new one.  And as I said, you can revert this at any time.  So now it completely depends on what you actually want to do with that.  So we are very generic to the instrumentation framework.  So what we're actually changing about the code is up to the module developer.  But I'll get to that later.  Very briefly, you can also do this in the operating system.  So if you're not focusing on running on stock devices, if you want to have your own A with  P fork or do this on your own device, you can of course replace the original compiler  with our version.  And then of course you lose this, that you don't change too much about the system.  But you can also instrument not only apps, but also system components.  As you can see on the one side here, services jar.  This is actually the jar that complains to complete system server, which means package  manager service, application, activity manager service, all this stuff.  So this is roughly 25,000 methods written in jar.  And for the fun of it, we wrote a module that will instrument them.  So into all those 25,000 methods, in each single basic block in the control program,  we injected a call that used reflection to get the method name.  I know it's dirty, but still there with me for that one.  And this method name is then printed to lockhead.  So this is quite a lot, right?  For everything that's happening in Android now, there's lockhead entry with the name  of the method.  And actually this works quite well.  So if you run this on x86 emulator, it's hardly slow, of course, but it works, proving  that artists are really robust and also are scaled.  We have quite some interesting products here, instrumenting the compiler and the operating  system.  But due to time constraints, just ask me later if you're interested.  All right, at this point, you might be interested in why am I introducing yet another instrumentation  framework.  Well, we have exposed.  And maybe some of you heard of Frida, anyone?  OK, I see some hands.  Well, it's a bit more popular in the kind of flurzing domain.  So let's have a look why another one.  We believe that artists will first kind of a sweet spot in the design space, because  on the one hand, we are in contrast to Frida, not only targeting developers, but also end  users.  So if you don't need a device or device connected to a PC and an ADB connection, we just need  to install artists going on a router device.  That's it.  And actually, the route is just required for this one step where we change the compiled  version of the original one from the system with ours.  That's the only step.  So actually, route is way overprivileged for our case, but if you don't want to change  the operating system, we cannot do a thing about it.  So as a leaguer, time would be perfectly fine, but unfortunately, we cannot do this right  now.  So in general, as you can see in the table, the idea is that we are not very invasive.  We don't need any custom recovery.  You don't have to flash anything.  Just a regular user having a router device downloading your app, importing modules, and  you can freely start modifying applications and analyzing them at will.  So I've been talking about modules a bit, so let me make sure we're on the same page  about that.  Whenever I've heard you in modules, I'm talking about kind of a world-structured, abstract  functionality that is self-contained.  For example, I mentioned earlier, I can have 10 tracking, I can have ad blocking, and all  of those would be modules.  Think of them like niggle stones that you just put on other apps.  You can just add this, this modular functionality.  You can inject it into arbitrary applications.  Well, from ARTIS, you have actually two parts.  We already saw there's an optimization pass, so whatever the compiler believes is actually  an optimization, but it's a glue code.  And then what we call the code clip is just a random Java or Kotlin library that you write.  So you write all your business logic in Java and Kotlin, and then it will be injected into  the target app, and the ARTIS optimization pass is kind of stitching all the pieces together.  And of course, we also have some metadata like the maintainers on.  So this is pretty new, but we're expanding on that.  So let's make an example.  Whoever heard of the Stevo library?  Cool.  Nice.  Then I don't have to explain a lot.  I'm a big fan, I have to say, because if you have to, actually, in your debug version  of the app, it connects your app to the Chrome developer tools.  And you can do a lot like intercepting network traffic, read all the files, access a database.  There's a lot you can do.  You can even execute JavaScript in the context of an app.  That's a good idea.  It's a different thing, but it's possible.  So I said this is meant to be included in the debug version of your app.  But what if there are some researchers that try out to inject this into arbitrary applications?  And this is exactly what we did, and I will try a live demo now.  Let's see if that one is working.  All right.  So you should see now my device here.  Good.  It works.  And you see the Chrome developer tools.  So actually, we haven't connected now.  I just skipped instrumentation part for time reasons.  And we can have an impact here on the complete UI.  We can inspect it.  We can change the values.  We can also, let me just reload this, we can see live to traffic coming in here.  We scroll a little bit.  As you can see, as you're used to when working with web apps, and TLS doesn't scare us here  because we're getting all the traffic before it is encrypted or after it was decrypted.  And what you can do is put this pretty cool is you can have a look at the databases.  So what you see is a regular Reddit app.  We didn't change anything, but applying one of our modules.  So this is the one from Google Play Store, and you can probably just redo this demo  at some point.  And we can have a look, for example, in the database where you have different subreddits.  You can see which one actually has advertisements or not.  You can see all the descriptions.  It's not that nice on the screen right now, but I invite you to check this yourself as  soon as we're also releasing the server module.  So in general, I just wanted to show you, you can do quite a lot.  And whatever you can change in the code, you can do with artist.  So at some point, even some of the heevees had some fun and added here to several recommends  to the Google Play Store or like this really nice post-effect overflow.  Of course, that actually never existed.  It was just locally on the device, but it's nice for some fake screenshots, right?  Okay.  Of course, we did also some more meaningful modules, particularly as part of our research.  So in the original paper, we had the taint tracking system, which means we're following  the flow of information through a program and try to reconnect all the different information  flows.  And the idea was that if an application is, for example, reading your local files or some  pictures, is this application in the end sending this to the internet?  And of course, then we want to ring an alarm and ask a user if that's actually what the  user intended.  It's quite involved and also prototype, but it's also a second product that I really  like and this is actually joined by a couple of my colleagues that's also here.  So the idea is that we took apart an application, we moved the complete advertisement code into  a different app.  So what used to be a regular library call is now an inter-process communication.  And we reconnected it through a custom binder protocol and all of this on a rooted stock  device.  So no operating system, the changes involved, which is the magic of artists.  So this worked kind of well for advertisements.  It was just still displaying the advertising as a remote floating view on top of the app.  The user didn't see any difference, but now from a system perspective, you would argue  that the advertising library is now what we call a distinct security principle, which  means the system can distinguish between library and application.  So it can now revoke permissions only from the library or only from the application without  impacting the other, which is kind of nice.  So we're doing quite a lot here, but again, for time reasons, if you're interested in  that, just drop by and ask us something.  So if you want to create all modules, for example, if you want to instrument this awesome  Broadcom Berlin app, then you can do so because everything is open source.  We have an SDK now.  This is helping you writing this native code.  You know how to write Java encoding code.  For the native code, it's a bit involved.  We have a template code lab and template module, the two parts that stick together.  And actually, after checking them out from GitHub, you can change them.  You just have to build them by running a single make command because we already have all the  build tools and some make scripts ready.  So this is straightforward.  Push the module, which is a zip file to the device.  And Archus Gui actually has a UI where you can just tap on the plus and then you can  select it from the file chooser.  So it is really straightforward.  And then you have this nice screen where you choose the applications.  You can choose which modules you want to apply and you can change this at any time for each  application.  So this is actually on demand.  We just entered the beta phase.  Like on Friday, the last things were published and also versioned and so on.  So we tried to follow semantic versioning.  We heard earlier that it's very important.  We have this new module management in the SDK and some new documentation.  So I ask all of you interested in that to try it out.  And of course, we're not done yet, not even close.  On the developer side, we want to be more professional about this, like having automatic  releases, having more tests.  We want to have a public module place, like you know it from XPost, where people just  can maybe immediately from the app download modules from the web and just apply them to  the applications.  And there's one student of mine working on the bridge between XPost and Altist.  So some of the XPost modules are automatically translated to an artist module, which means  the store would start with just immediately hundreds of modules readily available.  And again, if you just don't want to kind of flash something through the device and just  want to route it, then probably artists might be an option for you.  And also what I showed you, replacing the system compiler to kind of instrument the  system server and framework class and so on.  Maybe you can even get to that point without changing the compiler.  Maybe you just have to again recompile everything, switch the files and reboot the device.  I'm not sure, but I think this is possible.  So let's see.  So in the end, this is a community project.  Well, it's pretty young.  We are not that many developers right now, but it's actually bleeding edge research.  So please have a look.  Tell us what you think.  We're really waiting for feedback.  And since we're pretty young project, you can already get the same project.  So if you kind of want to contribute and have some interesting use cases, then just let  us know.  We are happily talking about this.  Talking about which, we have a Jitter Chat and we have most of it.  So everything besides the step-by-step module right now, I have on GitHub.  And essentially, that's it.  So I want to say thank you for attending the talk.  And I'm happy to take any questions now.  Thank you.  Thank you so much.  Questions?  Perhaps about the community for how long have you been working?  Well, actually, the roots of this project go back until end of 2015.  So actually, I started this as my master thesis, the initial version of Artists, but it was  pretty focused.  It was a team-tracking part.  And after that, we noticed, well, if we have this compiler, it has pretty nice opportunities.  And it just created a generic instrumentation framework from that.  So this is actually the reason where we started.  And from that, we just iterated.  And with new research projects, we extended the API because we needed new modules.  So I think, well, we started, yes, we started 2015 and was open sourced last year.  But just this new iteration, what we just called it, the first beta version, I released  just on Friday.  So right in time for DroidCon.  Thank you, Sumit.  Thank you.  Any other questions?  Hi.  So having worked with Xposed a lot before, do you have any way to better deal with obfuscated  apps, like AppStudios ProGuard?  How do you instrument those?  Because methods, signatures, names, they change all the time with every update.  I see.  Well, this is actually a shared problem.  So Xposed, well, as you said, you have the problem, it's hard to detect the method you  want to target.  For artists, you have similar problems because most of the filters or most of the modules  right now are written against a filter API.  And most of the time, you just search for method name.  But we have one advantage, which is, I did very briefly on the table, that Xposed is  working, the funds I know on the method level, like you can hook a method, replace it.  But artists is working on the instruction level, which means you can even kind of detect  a method and just change a plus to a minus or something, which means you can be way better  in fingerprinting methods.  If you know enough about your method, you can find it outside of the method name just  by looking at the code, for example.  You still have the problem of obfuscation, so this is shared, but it might help you.  So you can get even deeper into that.  Because I really have to think about this, you see the complete code in the contract,  in control flow graph, each instruction is represented in this representation as kind  of an object.  So this object-oriented version of the code.  This is kind of nice.  You can work with that and you can extend it as well.
_DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_0_599.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_600_3011.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_3012_8243.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_8244_9827.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_9828_11867.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_11868_12335.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_12336_13679.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_13680_15167.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_15168_15347.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_15348_16031.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_16032_16163.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_16164_16667.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_16668_16895.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_16896_16955.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_16956_17003.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_17004_17255.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_17256_17555.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_17556_18047.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_18048_18191.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_18192_18611.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_18612_20819.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_20820_22187.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_22188_22631.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_22632_24071.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_24072_24911.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_24912_28979.png _DCBerlin18_405_Schranz_ARTist_A_Novel_Instrumenta_w2FWoaRoQLs_28980_28985.png
Hi everyone, my name is Oliver Schrands, PhD student and researcher at the CIS Biomass Institute. So actually on the large research site at Zahn University and today I'm going to talk about the research of us based on Android security. So what we're doing in this talk is actually instrumenting, so modifying and analyzing random third party applications. All right, so as we're coming from the security domain, there's quite a lot of motivation behind this because there's a lot you can do with app instrumentation and modification. For example, you want to analyze and reverse apps, of course, particularly the bad ones, but generally you want to understand what's under the hood, what's going on. You want to do some app behavior monitoring, you want to see what the app is doing at runtime. In some cases you even want to hot patch vulnerabilities, which means you want to patch vulnerability in the app without relying on the developer to patch them. For example, we had this in earlier talk, we have a lot of vulnerabilities in libraries and this might be a possibility to patch the library in an app without waiting for a new app release. So this is typical examples how we use modification on the app analysis in the security domain, but there's also a lot of use cases outside of that. So hands up whoever heard of XDA. Quite some. Okay. So very broadly, XDA is a developer community for people that like to roughly speaking make Android their own, which means they want to mod applications, they want to mod the operating system and they just want to apply any changes here. So it could be anything from just patching YouTube so it keeps playing music by going to the background, just dropping ads or whatever you can think of, you can even paint Facebook red, even though that's probably not very useful, but you could do it. So this is actually the main we're coming from. We want to do modification of apps and we have quite some use cases for that. And what we're actually coming from here is at some point we saw that there is a new thing in Android called Android runtime, it was already mentioned today this morning in the keynote and the idea is that we now have a native compiler on the device that is translating our byte code to actually native code of this platform. So let's have a look at how it works out. So there's this new component called Dex2Oat because it literally translates the Dex byte code to a new native file format. So essentially OAT files, old files are on ELF files, which is received a new name. And if you follow the flow here, we first transform this Dex byte code into an intermediate representation, which is really common for compilers. And then the compiler is invoking some optimizations on that, so everything from that code emulation to constant value propagation, so on so, the usual things. And this is something that Google created from scratch. So we now have a complete compiler framework on the device itself. And the reason that many people didn't even notice is because Google did really a great job of hiding this. You still write your apps in Java and Kotlin, have byte code, translate it to Dex byte code and now actually execute native code. But you never get ZegFold. You just get null point exceptions because they embed the complete Java semantics into the native code, which is kind of nice. So actually as developers, we don't see this quite often. We don't care about art at all. But at some point we decided this is quite interesting, so we wanted to have a look. And what we did here was we embedded a complete instrumentation framework into this compiler. So this is what we call artist. The Android runtime instrumentation and security toolkit. And if you have a look what actually changed is that we added a pre-processing step. So first we have an arbitrary Java library or Kotlin library that we merge into the app. So if I want to modify an application, this is actually my business logic. Something that I want to add to the app. For example, an inland reference monitoring implementation or chain tracking, whatever. So this is merged into the app. And if you know a bit about APKs, you know that by this I actually break the app signature, which means it doesn't get any updates now. This is actually a problem for us, but I will come to that. And then this new code also includes our code, is transformed to its intermediate representation. And the very interesting step here is that we added another step here. And this artist instrumentation essentially is applying all the changes that we want to have in the app. So kind of this code that's executed now is stitching together the original app and a new app code. So kind of this is the duct tape. This is the glue sticking everything together. And what's really nice about the solution is that this is completely transparent to the compiler. The compiler believes he's just executing arbitrary optimizations. Because we're used to optimizations changing the code a lot, it doesn't bother that we are actually changing the code at will here. And in return, this means we can change it at will. And we can do anything. And the good thing here is that we are completely platform-independent because this happens before the code generators kick in and generate native code. So this works out of the box for all hardware platform for Android. Second, we have closed in a runtime overhead because we don't have any expensive fucking like expose or something. We just do this in the compiler. It's a compiled app and then we're done with it. Also I mentioned the app signature. And this is a common problem of bytecode instrumentation approaches where people just change the APK with, for example, APK to repackage it. We don't have this problem right here because we're only working on this copy over here. And actually we don't change the original APK. And the copy is just dropped afterwards. We just change this compiled version. So in the end, everything we need to do is we take the new compiled version, the new OAT file, and replace it with the old one. So this is kind of a swap operation. And we can redo this any time. So we can also revert this. And this is not very intrusive, which means we're not touching the operating system at all. Including we are not touching the original compiler. So actually how do we deploy this then? If we don't replace the original decks to old with our version of artist. So the idea is that we have a wrapper application. Since I'm horrible at names, I just named this artist's GraphQL user interface. So the idea here is that we take the new compiler version and you can think of it just as a binary. You invoke it with arguments and the arguments being installed applications. And it outputs OAT files. So what we do here is we use artist.goo. And people can just select applications they have installed, click on instruments, recompile, whatever. And then in the background, we execute our artist framework. And now we have a new OAT file and the original one that the system generated. And we hot swap this. So actually after that, the application that will be run will be the new one. And as I said, you can revert this at any time. So now it completely depends on what you actually want to do with that. So we are very generic to the instrumentation framework. So what we're actually changing about the code is up to the module developer. But I'll get to that later. Very briefly, you can also do this in the operating system. So if you're not focusing on running on stock devices, if you want to have your own A with P fork or do this on your own device, you can of course replace the original compiler with our version. And then of course you lose this, that you don't change too much about the system. But you can also instrument not only apps, but also system components. As you can see on the one side here, services jar. This is actually the jar that complains to complete system server, which means package manager service, application, activity manager service, all this stuff. So this is roughly 25,000 methods written in jar. And for the fun of it, we wrote a module that will instrument them. So into all those 25,000 methods, in each single basic block in the control program, we injected a call that used reflection to get the method name. I know it's dirty, but still there with me for that one. And this method name is then printed to lockhead. So this is quite a lot, right? For everything that's happening in Android now, there's lockhead entry with the name of the method. And actually this works quite well. So if you run this on x86 emulator, it's hardly slow, of course, but it works, proving that artists are really robust and also are scaled. We have quite some interesting products here, instrumenting the compiler and the operating system. But due to time constraints, just ask me later if you're interested. All right, at this point, you might be interested in why am I introducing yet another instrumentation framework. Well, we have exposed. And maybe some of you heard of Frida, anyone? OK, I see some hands. Well, it's a bit more popular in the kind of flurzing domain. So let's have a look why another one. We believe that artists will first kind of a sweet spot in the design space, because on the one hand, we are in contrast to Frida, not only targeting developers, but also end users. So if you don't need a device or device connected to a PC and an ADB connection, we just need to install artists going on a router device. That's it. And actually, the route is just required for this one step where we change the compiled version of the original one from the system with ours. That's the only step. So actually, route is way overprivileged for our case, but if you don't want to change the operating system, we cannot do a thing about it. So as a leaguer, time would be perfectly fine, but unfortunately, we cannot do this right now. So in general, as you can see in the table, the idea is that we are not very invasive. We don't need any custom recovery. You don't have to flash anything. Just a regular user having a router device downloading your app, importing modules, and you can freely start modifying applications and analyzing them at will. So I've been talking about modules a bit, so let me make sure we're on the same page about that. Whenever I've heard you in modules, I'm talking about kind of a world-structured, abstract functionality that is self-contained. For example, I mentioned earlier, I can have 10 tracking, I can have ad blocking, and all of those would be modules. Think of them like niggle stones that you just put on other apps. You can just add this, this modular functionality. You can inject it into arbitrary applications. Well, from ARTIS, you have actually two parts. We already saw there's an optimization pass, so whatever the compiler believes is actually an optimization, but it's a glue code. And then what we call the code clip is just a random Java or Kotlin library that you write. So you write all your business logic in Java and Kotlin, and then it will be injected into the target app, and the ARTIS optimization pass is kind of stitching all the pieces together. And of course, we also have some metadata like the maintainers on. So this is pretty new, but we're expanding on that. So let's make an example. Whoever heard of the Stevo library? Cool. Nice. Then I don't have to explain a lot. I'm a big fan, I have to say, because if you have to, actually, in your debug version of the app, it connects your app to the Chrome developer tools. And you can do a lot like intercepting network traffic, read all the files, access a database. There's a lot you can do. You can even execute JavaScript in the context of an app. That's a good idea. It's a different thing, but it's possible. So I said this is meant to be included in the debug version of your app. But what if there are some researchers that try out to inject this into arbitrary applications? And this is exactly what we did, and I will try a live demo now. Let's see if that one is working. All right. So you should see now my device here. Good. It works. And you see the Chrome developer tools. So actually, we haven't connected now. I just skipped instrumentation part for time reasons. And we can have an impact here on the complete UI. We can inspect it. We can change the values. We can also, let me just reload this, we can see live to traffic coming in here. We scroll a little bit. As you can see, as you're used to when working with web apps, and TLS doesn't scare us here because we're getting all the traffic before it is encrypted or after it was decrypted. And what you can do is put this pretty cool is you can have a look at the databases. So what you see is a regular Reddit app. We didn't change anything, but applying one of our modules. So this is the one from Google Play Store, and you can probably just redo this demo at some point. And we can have a look, for example, in the database where you have different subreddits. You can see which one actually has advertisements or not. You can see all the descriptions. It's not that nice on the screen right now, but I invite you to check this yourself as soon as we're also releasing the server module. So in general, I just wanted to show you, you can do quite a lot. And whatever you can change in the code, you can do with artist. So at some point, even some of the heevees had some fun and added here to several recommends to the Google Play Store or like this really nice post-effect overflow. Of course, that actually never existed. It was just locally on the device, but it's nice for some fake screenshots, right? Okay. Of course, we did also some more meaningful modules, particularly as part of our research. So in the original paper, we had the taint tracking system, which means we're following the flow of information through a program and try to reconnect all the different information flows. And the idea was that if an application is, for example, reading your local files or some pictures, is this application in the end sending this to the internet? And of course, then we want to ring an alarm and ask a user if that's actually what the user intended. It's quite involved and also prototype, but it's also a second product that I really like and this is actually joined by a couple of my colleagues that's also here. So the idea is that we took apart an application, we moved the complete advertisement code into a different app. So what used to be a regular library call is now an inter-process communication. And we reconnected it through a custom binder protocol and all of this on a rooted stock device. So no operating system, the changes involved, which is the magic of artists. So this worked kind of well for advertisements. It was just still displaying the advertising as a remote floating view on top of the app. The user didn't see any difference, but now from a system perspective, you would argue that the advertising library is now what we call a distinct security principle, which means the system can distinguish between library and application. So it can now revoke permissions only from the library or only from the application without impacting the other, which is kind of nice. So we're doing quite a lot here, but again, for time reasons, if you're interested in that, just drop by and ask us something. So if you want to create all modules, for example, if you want to instrument this awesome Broadcom Berlin app, then you can do so because everything is open source. We have an SDK now. This is helping you writing this native code. You know how to write Java encoding code. For the native code, it's a bit involved. We have a template code lab and template module, the two parts that stick together. And actually, after checking them out from GitHub, you can change them. You just have to build them by running a single make command because we already have all the build tools and some make scripts ready. So this is straightforward. Push the module, which is a zip file to the device. And Archus Gui actually has a UI where you can just tap on the plus and then you can select it from the file chooser. So it is really straightforward. And then you have this nice screen where you choose the applications. You can choose which modules you want to apply and you can change this at any time for each application. So this is actually on demand. We just entered the beta phase. Like on Friday, the last things were published and also versioned and so on. So we tried to follow semantic versioning. We heard earlier that it's very important. We have this new module management in the SDK and some new documentation. So I ask all of you interested in that to try it out. And of course, we're not done yet, not even close. On the developer side, we want to be more professional about this, like having automatic releases, having more tests. We want to have a public module place, like you know it from XPost, where people just can maybe immediately from the app download modules from the web and just apply them to the applications. And there's one student of mine working on the bridge between XPost and Altist. So some of the XPost modules are automatically translated to an artist module, which means the store would start with just immediately hundreds of modules readily available. And again, if you just don't want to kind of flash something through the device and just want to route it, then probably artists might be an option for you. And also what I showed you, replacing the system compiler to kind of instrument the system server and framework class and so on. Maybe you can even get to that point without changing the compiler. Maybe you just have to again recompile everything, switch the files and reboot the device. I'm not sure, but I think this is possible. So let's see. So in the end, this is a community project. Well, it's pretty young. We are not that many developers right now, but it's actually bleeding edge research. So please have a look. Tell us what you think. We're really waiting for feedback. And since we're pretty young project, you can already get the same project. So if you kind of want to contribute and have some interesting use cases, then just let us know. We are happily talking about this. Talking about which, we have a Jitter Chat and we have most of it. So everything besides the step-by-step module right now, I have on GitHub. And essentially, that's it. So I want to say thank you for attending the talk. And I'm happy to take any questions now. Thank you. Thank you so much. Questions? Perhaps about the community for how long have you been working? Well, actually, the roots of this project go back until end of 2015. So actually, I started this as my master thesis, the initial version of Artists, but it was pretty focused. It was a team-tracking part. And after that, we noticed, well, if we have this compiler, it has pretty nice opportunities. And it just created a generic instrumentation framework from that. So this is actually the reason where we started. And from that, we just iterated. And with new research projects, we extended the API because we needed new modules. So I think, well, we started, yes, we started 2015 and was open sourced last year. But just this new iteration, what we just called it, the first beta version, I released just on Friday. So right in time for DroidCon. Thank you, Sumit. Thank you. Any other questions? Hi. So having worked with Xposed a lot before, do you have any way to better deal with obfuscated apps, like AppStudios ProGuard? How do you instrument those? Because methods, signatures, names, they change all the time with every update. I see. Well, this is actually a shared problem. So Xposed, well, as you said, you have the problem, it's hard to detect the method you want to target. For artists, you have similar problems because most of the filters or most of the modules right now are written against a filter API. And most of the time, you just search for method name. But we have one advantage, which is, I did very briefly on the table, that Xposed is working, the funds I know on the method level, like you can hook a method, replace it. But artists is working on the instruction level, which means you can even kind of detect a method and just change a plus to a minus or something, which means you can be way better in fingerprinting methods. If you know enough about your method, you can find it outside of the method name just by looking at the code, for example. You still have the problem of obfuscation, so this is shared, but it might help you. So you can get even deeper into that. Because I really have to think about this, you see the complete code in the contract, in control flow graph, each instruction is represented in this representation as kind of an object. So this object-oriented version of the code. This is kind of nice. You can work with that and you can extend it as well.
security. So what we're doing in this talk is we use modification on the app analysis in the roughly speaking make Android their own, which of this platform. So let's have a look at how it framework into this compiler. So this is what we and security toolkit. And if you have a look what break the app signature, which means it doesn't arguments being installed applications. And it But you can also instrument not only apps, but dirty, but still there with me for that one. And another one. We believe that artists will first only targeting developers, but also end users. So abstract functionality that is self-contained. it will be injected into the target app, and the you can have a look at the databases. So what you And whatever you can change in the code, you can your local files or some pictures, is this application in the end sending this to the different app. So what used to be a regular remote floating view on top of the app. The user because everything is open source. We have an SDK of instrument the system server and framework contribute and have some interesting use cases, until end of 2015. So actually, I started this as instrumentation framework from that. So this is