 I'm Tony Trummer. This is my colleague Tishar Dolly. We're both penetration testers at LinkedIn. First of all, we want to thank everyone involved with DEF CON for inviting us to speak here and for putting on this event every year that all of us love. So to keep our suits happy at our company, obviously our opinions are our own and don't reflect those of our employer. So jumping right in, the reason we're here today is to introduce a tool we've developed called Quark. It stands for the quick Android review kit. We decided to build Quark after surveying all the open source tools available for Android application security and feeling more could be done. So we took ideas from the best of them, added some things we think are innovative and duct taped it all together with some poorly written Python. At least the parts I wrote anyway. The results are an automated static code analysis tool and attack framework for auditing and exploiting Android applications. The reason for building the tool was obviously to secure our own applications, first and foremost. But we wanted to share what we built in order to help raise the bar for Android application security overall. After all, the less vulnerable apps there are in the world, the less we have to worry about in our apps from them attacking us and obviously the safer all of us Android users will be in general. One of Quark's key objectives is to provide users with informative, authoritative sources of information. So if they're not familiar with Android AppSec, they can learn and then subsequently teach others around them about potential security issues. Again, we're trying to increase the collective knowledge around Android application security. We wanted to make Quark available to everyone. So even if you're one of those one person shops, you can assure your apps are secure. Even if you have no security budget, no security team whatsoever. We're sure there are some big name static code analysis tools you could buy that do as good or not maybe better job than we do. But hey, Quark's free and you can always use that first and see where you stand and then move on if you need to. We don't require any complex setup. There's no consultants that have to come on to integrate into your SCLC. As you'll see, we've got some features that aren't available in other tools that we know of and using Quark is as simple as could be. So obviously we're not the only people interested in protecting Android applications. So we figured by open sourcing Quark, not only would other people get to benefit from it, but all of you could help contribute back to it to make it even better. So if we fail to look for a bug that you know of, maybe we didn't write the check write or maybe we're just idiots in some other fashion, let us know and we'll fix it, add it, modify it, whatever. If you're a developer who isn't scared of looking at my sacrilegious Python code, we'd encourage you to go ahead and contribute directly to improve it. And lastly, we hope that some people might look and say, hey, if these two guys can build this in a couple of months, maybe we could do something more on our side. We think it would be awesome if the app store owners across the world would possibly scan applications before allowing them into the stores, notifying the developers, possibly the security teams, and ideally the consumers about potential security risks associated with that application, although the latter is probably a bit of a fantasy. So what are the top issues in the Android ecosystem? Primarily, unfortunately, the number one issue is completely out of our hands and that's fragmentation, right? Due to a finger pointing and failure to act on the parts of the OEMs, the carriers, Googles, et cetera, we're left with a world where somebody go out and buy a device today that's vulnerable to stage fright and potentially other vulnerabilities and it may remain that way for years and there may be no way for them to get a timely update if one even exists. It's so bad that customers have actually resorted to class action lawsuits against these different entities just to try to get updates. I'm not going to opine on that but you can ask yourself what does it say about the prioritization of security when those are the lengths that the customers have to go to just to get a fucking update. The flip side of this is, of course, you can't rely on the users to necessarily update the OS or the apps themselves. So as a producer of mobile applications, you may inadvertently ship a vulnerable app only to then have to cross your fingers or pray for some sort of mitigation on the server side for months or even possibly years after you've already fixed it just because you have users who are slow to update. So all this really puts a premium on getting it right the first time every time. Another very common issue with Android apps, researchers are constantly finding that they're failing to validate X509 certificates when they're doing TLS handshaking. And this leaves countless apps vulnerable to mount men in the middle attacks and they're plenty that just say screw it and don't use TLS at all. With the frequent use of web views, which are those mini browsers inside of your apps, we're so vulnerable to most, if not all of the OS top ten legacy bugs, you know, cross site scripting cross site has forgery, et cetera. But there are some unique twists and thankfully there are some limitations. But in this way, we have to assume that all the apps on the device could potentially be malicious as well. So we're operating in an environment where they may pass tainted data into our applications via these various IPC mechanisms to attack our applications. So if we care about our users, we additionally have to put in mitigation sometimes to protect them from bugs in the underlying operating system again due to the fragmentation of the ecosystem as we mentioned earlier. So when I grew up in IT, we had a saying which was if you lose physical control of your computer, it's no longer your computer, right? The reality is that that expectation no longer holds for mobile devices due to the increased likelihood they might be lost, stolen or subject to law enforcement snooping. Despite strides towards improving physical security on Android devices, again, mostly due to fragmentation, we're not currently at a point where we can say that all devices require strong authenticators or make use of full disk encryption. Unfortunately, many applications continue to store PII and other sensitive data unnecessarily within the client even after you log out simply because they don't want to make another network request, which is often not a worthwhile trade off from a security perspective. And finally, we have those special developers who can't seem to get their head around the fact that these apps are all reversible and anything you put in them eventually will be found by an attacker, right? So we get API keys, et cetera. So there have always been numerous countless, excuse me, countless publicly reported bugs with people hard coding secrets and stuff into mobile applications. And while CORT does look for some of these, as one of our esteemed colleagues stated, these bugs are kind of lame so it's not really the primary focus of what CORT does. So why do we go through all the work of creating and open sourcing a security tool for Android? Fundamentally, most pentesters are lazy and once we know something, we don't want to have to keep redoing the same thing over and over again, right? So we want to automate it. We want to get back to doing other more important stuff, right? Much of CORT is based around the manual security process we used to do but with some added features that make validation of vulnerabilities a lot easier. Apparently our crazy boss expects that every time we ship an app, it's free of vulnerabilities before it ever reaches our members' devices. It's pretty crazy, right? Many of the apps we publish are, sorry, with as many apps as we publish and their associated updates, the stream of work for reviews would be quite heavy if we were actually trying to do this manually for every iteration, right? If we're going to review every line of code for each release, we'd be swamped with doing nothing but that. So we wanted to be more agile and mirror the pace of development in our company. Everybody knows developers are some of the laziest creatures on the planet and normally this is just annoying, right? But when faced with those nagging warnings from their IDEs or compilers about something they're doing wrong from a security perspective, what do they do? They just turn it off, right? Drive on. From what I've read, the go-to fail bug never would have happened if a developer hadn't done exactly that. Point being, we can't rely solely on the potentially false assumption that these checks are in place and being acted upon accordingly during the development process. As I mentioned earlier, once we understand a bug and get it fixed, we want to automate it out of existence, right? If there's one thing we can't stand, it's a repeating bug or a bug that gets reintroduced as a regression. Lastly, many widely installed apps are developed by these very small companies, right? Flappy burgers or something like that, right? That it just goes viral and catches on and ends up on millions of devices with no consideration for security whatsoever. Not saying anything about flappy birds in specific just an example. These potentially vulnerable applications, however, somewhere down the road might integrate with an application like yours or mine, right? And so it actually might be important for us that those are secure. Because ultimately, they could put our member data at risk, either because they're a platform for attack or because they're awawthing to us or something like that, right? So under the hood of Quark, sorry, to deal with all these issues that we talked about, we decided to create Quark and it grew very organically using the very rigorous but less known, oh yeah, we should add that to development model. We didn't necessarily reinvent the wheel for basic functionalities but chose instead to leverage what was already available. We happened to luck out and find a Java tokenizing library called PLYJ, which we used to process the Java files which make up the core component of most Android applications. It has certain problems with Android specific constructs but for the most part it was functioning very well and it was the best thing we could find at the time. So we also use common things like beautiful soup and mini DOM to parse XML files and again it's all glued together. It was some horribly written Python. And you'll notice that we used several different decompilers and I'll let Tashar explain to you why that is but this is one of the interesting parts about Quark. And lastly we do implement the instrument, the Android SDK in the exploitation phase which Tashar will demonstrate for you shortly. So if you have no idea what an Android application is built of, this is it in a nutshell. They're essentially APK files which is just a compressed archive consisting of the directories and resources listed here, slightly abbreviated just so we could have prettier slides. Many of these have actual relevance to security in one way or another but Quark mainly focuses on the two sort of at the top center there, the Android manifest.xml and eventually the classes.dex file. They're really the heart of the Android application. For those that don't know, the Android manifest.xml defines all of the app's capabilities including all of its components which we'll discuss shortly, whether the app can be debugged, whether a person with physical access can create a backup of the data, which permissions it uses or declares and the versions of Android that the app was built to run on, which you'll see is important to how the app needs to be protected. So to begin testing an already built Android app, the normal process is that you'd have to reverse it, right? We used to have to use APK tool to extract the manifest and decompress the archive. Once we decompress, we'd have access to the classes.dex file, but we need to convert, which is Dalvik bytecode, not human readable. And then we used to have to convert that to a jar file containing Java bytecode and then finally we would have to use a tool like JD GUI to retrieve the underlying Java classes and we'd finally be back to something very similar to what their developer had originally wrote. That is assuming that the decompiler did an adequate job. Don't worry if you didn't take notes on any of this because now that we've covered all of it, you never have to do any of it again. So the days of manually reversing Android apps are officially over as far as we're concerned. Cork handles all of that for you and can even pull the APK off the device for you. So you don't even have to know how to use ADB. And if you don't know how to use ADB, don't worry because Cork also helps teach you that along the way as well. Yes, we Googled it all for you. So these features alone are reason enough to find Cork useful, but once it's acquired and decompress the APK, it quickly parses the manifest looking for vulnerability or potential vulnerabilities and immediately reports any findings. But I'll let Cheshire show you all that cool stuff. This functionality is similar too, but we feel an improvement upon the attack service functionality offered in some other Android tools. Cork does factor in the permissions, versions specific vulnerabilities, et cetera, to let you know how your app will be vulnerable on the specific API levels you choose to support. Of course, before you can properly audit an application, you have to know what the potential sources of tainted data are, right? You have tainted data in Android applications which come from malicious sites via the web view content or deep link URLs. Then there is also the potential for IPC-based attacks originating from malicious apps on the same device. These primarily come in the form of intense, but possibly including other things such as messages or AIDL. Each of these along with the insecure network requests I mentioned earlier can carry potentially harmful data, cause data leakage from your application, or invoke unwanted actions in your application. Quickly going over the components. After reversing the app and inspecting the manifest, a review would usually start by looking at these, specifically the exported components. Exported means that they're available for other apps to talk to on the device via these various IPC mechanisms that we just spoke about. Reviewing the different component types, we have activities, services, providers, and receivers. Quickly activities are all the visual screens that you see are the little things you tap on. Services are the long-lived and they run in the background and do backgroundy service-y things. Providers facilitate access to files or databases and receivers basically just hang around and wait for someone to talk to them. Each of these have listed life cycle methods which we refer to as entry points that execute at various times during the application life cycle depending on what the app is doing, what you're doing in the app, what the app is doing in the background or what data it may be receiving from the system or other applications. In particular, each has a primary method or methods such as on create where another application can pass data in, usually via an intent. Since this data can be malicious, it can cause undesired consequences. We begin our examination of flows there. Now that we covered the basics, let's go over what makes Cork unique. Unlike some Android security tools we've seen, Cork doesn't stop at the manifest. Once we've defined the attack surface, Cork begins trying to tie it all together. It takes the information from the manifest and then finds the classes which map to the vulnerable components. For those that don't know, there's a direct relationship between the components named in the androidmanifest.xml and the underlying class files. So for example, if you were to have a Foo.activity declared in the manifest, you would find a Foo.activity.java file in the project. From here, it begins parsing all the classes and locating all those entry point methods that we covered. As again, these are the places where the potentially tainted data can get into your application. Once we've identified the sources of tainted data, we attempt to follow them through the code, looking for wherever it passes through what we would consider to be a sensitive sink. Essentially, we're looking for anything that performs an action which could have negative results for the application or user, such as retrieving, modifying, or accessing or writing data or accessing sensitive device functionality, which would normally require permission. Since not all the vulnerabilities are evident from the outside in, the court continues the examination process by looking for issues which originate from the app itself, such as a web view configurations, data sent from the app, such as broadcast intents which get sent out to all the apps on the device, anybody who wants to listen. Sticky broadcasts which are basically the same except they remain persistent for some time. And pending and possibly insecure pending intents, which cannot allow another app to use your UID and permissions. For web view issues, court also includes HTML files to demonstrate vulnerabilities or configuration issues, allowing you to either load them locally or host them yourselves in case you don't trust us. We also include links to our site, if you do trust us, where we host them in case you can't host them for yourself for some reason. With that, Tashar will show you what court does. Thanks. Thanks, Tony. Can you guys read on the screen or do you want a bigger font? You're going to get lots of colors. Before we begin the demo, let me talk a little bit about the installation process. We have tried to keep it fairly self-contained in the sense that all of the dependencies are included by default when you download the source. That being said, the only thing that you need to provide as part of the setup is the location to the Android SDK. If you are an Android developer, you already have the SDK on your system so you can just run the tool, point the location to the tool and you're ready to go. If you do not know what specific Android components are needed in order to use Quark, don't worry. Quark will actually download and setup the SDK for you and it's also going to save this into a configuration file so that you don't have to repeat this process every time you run the tool. That being said, we only support Mac and Linux for now. If you are on Windows, we recommend running a VM. If you want to contribute a patch for it to run on Windows, we are more than happy to include it. So we just run Python Quark and as Quark starts, you would notice that the flow is quite simple. So as a starting point, we give you two options. You can either start from an APK or raw Java source code. So in both cases, the code flow is the same. The only reason why we give you two different options is so that let's say if you are a developer and you want to run checks on your Android application as you keep adding more features to the application, then you would probably start scanning the source code. And if you are an auditor or let's say a penetration tester for your company, then, you know, or maybe you would want to take a holistic view of the attack surface. You can start with the APK. So for the demo, let's take APK for now. So at this point, Quark will ask you for the location to the APK. So this could be either off of the file system or you can also pull it off of the device. And it actually comes very handy when you do not have the app listed on the app store. For example, the pre-rendered applications that come installed on your devices. So let's go ahead and pull the APK off of the device. So what it's going to do is as soon as you connect your device to the computer, which I have, it's going to take a list of all the applications that are there on the device and you can select the APK that you want. So since we don't want to get sued and we don't want to drop an ODE on someone's Android application, we're going to choose the code droid application. So for those of you who do not know what code droid is, it's essentially an Android application with intentionally created vulnerabilities in there for educational and research purpose. So once we do that, it's going to deflate the APK and read the manifest out of it. So if you guys have ever decompiled an APK, you would have realized that the Android manifest is not directly in a readable format. So we just give you an easy option to inspect the manifest and it's just going to display the contents of the manifest. So you would recall that Android manifest is the most important part of the APK or the most interesting part because it kind of gives you an idea of what's within the application. So you can see what kind of services, activities, broadcast receivers, everything that's there, what kind of permissions are required by the application to run correctly or what permissions are required by the other applications to invoke some components from within your application. You have things like min SDK version, target SDK version, bunch of other things. For example, the vulnerable versions of Android OS on which your application may eventually land. So if you do not know what to make sense out of it, don't worry. Quark will find the attack surface, the potential attack surface and report it for you. So most of the entries are pretty much self-explanatory and wherever possible will give you credible sources of information which you can reach out to learn more about those kind of issues. So for example, the debuggable flag is set to true which of course you wouldn't want to do on your production applications. You can also see a bunch of activities that are predicted, that are not predicted by any permissions and are marked exported. So we'll save this information for the exploitation phase. Again, you can see a bunch of other services and receivers that are not predicted by any permissions. So one of the other things as Tony mentioned Quark does is that it's going to look for the minimum SDK version and based off of that it's also going to recommend or show you a few other vulnerabilities that could exist outside your application ecosystem that may affect the integrity of the application. So far it's a good rate. But in order to go in depth we actually need access to the raw JavaScript code. So if you started off with the raw JavaScript code as the starting point, you're good to go. And in case of an APK such as this, we actually need to reverse the DEX file to class and then class to the raw JavaScript code. So Quark automates this for you and you would see that we are running multiple decompilers on the same JAR file and the reason for that is there are times where a particular decompiler may not be able to decompile all the files correctly and whereas some other decompiler may be able to decompile some of those files. So the idea here is that because each decompiler fails in a predictable way, we leverage this fact to identify which files are corrupt and we see if some other decompiler was able to decompile one of those corrupt files successfully. So it's going to take, can you guys say it? Sure. So as you can see, because of this technique, we were able to restore about 11 out of 13 corrupt files and that's almost 85% in terms of recovery. So we have listed out the potential attack surface and now we have the raw JavaScript code to begin the static code analysis. So all of the checks you see here are actual checks we run on the raw Java source code to find those type of vulnerabilities and you would see in a moment that the results are going to be color coded to kind of give you a sense of confidence we have in those type of results. So included in this checks are the standard Android security link checks, some research done by security researchers in the industry and also some research that we did on our own. Again, this list is not exhaustive and we are still adding more and more checks so we are more than happy to receive a patch and include it and even if you guys have an APK, you can say, hey guys here's an APK and this is the type of bug that we think should be able to find. We'll write a patch for it. So all of the entries you see here are actually the entry points we found from the manifest declaration and we are going to look for vulnerabilities in those files or the other way around which is hey, we scan for these files and we are sure that there are no problems here because sometimes it's essential to realize whether something was not flagged as a vulnerability because the file couldn't be passed properly or if it was passed correctly but we didn't find any vulnerabilities in there. So and we actually want to show you that this file is part of the attack surface because this is something that's accessible through other applications. So for example, you can see that there is an activity that's not predicted by any permissions and is actually setting a result via the set result method. So in short, your app may leak data through this if some other application tries to speak with it. Again, we'll save this information for the exploration phase and because we are not trying to sell you anything, we will not give you a false sense of security by hiding errors in the application. So whenever there is a passing error, we'll actually display it on the terminal so you can verify those files manually for any type of vulnerabilities. And these errors could occur because of maybe there's an Android specific construct that the pass couldn't understand or simply because the decompilation period. So again, if you started off with the ROJ also scored as a starting point, then probably you wouldn't get these kind of issues. So moving down, you know, you can see that Quark has found a potential vulnerability and more than just saying what's wrong with the exported component, we actually do a source to sync mapping of the entire Java file, we tokenize it and see if there's a source to sync mapping. And if it exists, you know, we term it as a potential vulnerability. So we also give you the details of what exactly we need in order to exploit this potential vulnerability. So for example, it says here to exploit, you would need to send an intent with a specific key of the type string, the same with message and soft type string. So we'll keep saving this information for the exploration phase. Some of the other kind of issues that we can detect with Quark are certificate validation issues. We'll give you credible sources of information wherever possible. There are a few pending intent issues that we can see. The other type of issues that we can detect with Quark are insecure default configurations for webviews. Or if there are any security impacting configurations that were overwritten by the developers. So we break it down by file names and we'll start all the configuration for that particular webview. So we'll see how we can use that in the exploration phase. So at this point, this is something that you can see with a bunch of other tools as well. But the real question is, can a real world application actually exploit these vulnerabilities? So for this, we're actually going to give you a couple of options. The first one is to use ADB commands. So wherever possible we'll give you specific Android ADB commands that you can run on your computer while your device is connected to it in order to see if you can exploit those vulnerabilities. So as you can see here, Quark has listed out a bunch of ADB commands that you can actually run. And wherever possible, for example here, we're going to give you possible extras that you need to send with the intent in order to see if you can do anything meaningful with that intent. So at this point, all of the information can be seen here. We create an HTML report. It's probably too small to cramp it down, but on a regular screen you would see the potential vulnerabilities, any warnings, debugs. Again, everything that you saw on the terminal can be found in the HTML report. And it's pretty self-explanatory, for example, you know, will it start potentiary vulnerabilities and what exactly do you need in order to exploit it. And you would notice that we actually term everything as potential vulnerability and not a vulnerability because we don't want strip-critics to run this tool on your application and send it to you saying, hey, this is a vulnerability go fix it. We would actually give you the opportunity to say for yourself whether this is exploitable or not. So conservatively we'll speak everything as warnings unless we deem it as potential vulnerability. So you have the web reassures, certificate validation issues, all the ADB commands listed out here. I promise this looks better on a regular screen. Again, references to OS-specific bugs, passing errors if any. So you can look for these files manually. But now for the fun part. So we're going to attempt what no tool has done until now. So we'll give you the option to create a custom APK for exploitation. So we do that. And what it's going to do is that we gathered all the information from the manifest attack surface and we have the source to sync mapping from the raw Java source code static analysis. So we are going to save this information into a templated APK and try to create an APK that you can deploy on the phone in order to exploit the application that you're just about to test. So think of this as an evil twin for the application that you're testing. And hopefully this should build successfully. All right. So we say yes, we want to install this to the device. Success. So Tony is now going to demonstrate the actual attack thing. Just so you don't think we're pulling shenanigans, we're going to try a live demo. We do have it recorded if it's either not visible or doesn't work for some reason. Can you guys? So hang on. Let it auto focus. Is that better? A demo win. I think I probably left the auto adjust on and then probably readjust it as soon as I took my finger off of it. So let's give it one more shot. Oh, you know what? Yeah, we actually had this blinder. We meant to do this. You're going to hold it? I feel so special. Okay. Better? Yeah? Start the application okay. All your critics. So when you start up work, there's nothing interesting to see here. We have this drop down menu that shows you all of the different features. Sucks. Sucks. We're going to go to the recorded demo and then we'll come back just to demo the actual exploitation thing. Okay. So this is much better, right? Okay. Sorry. We luckily this was recorded midnight last night so good to go. Very well prepared. So anyway, okay. Again, blank screen, drop down menu. So first thing was the bottom. I'll have to play around here. Pause. Really? Come on. You can't be that difficult. Pause. Okay. So the very bottom menu is the play button. Okay. So I'm going to start in sort of like a reverse order to save the cool stuff last. But the bottom thing is a send custom intent. Basically this is a tool that anybody who's testing Android applications would need, right? You need to be able to modify things and maybe we just didn't pick it up quite right and you want to tweak some things or you want to test. Provides. Also it makes it flexible so you don't necessarily uninstall it every time you test a new app. But obviously to get the full value of it you want to do that. So in here we have several fields that are required for most intents that you need to fill out. You know, there's the component name, the package, the intent action. Everybody knows. If you don't know you can use ADB to push keyboard commands to the phone so you don't have to manually type them. But if you must we try to make it as easy as possible for you. So whenever possible we have these fields that activate and they're prepopulated with the most common things you need to put in there in the first place. Just to save your thumbs. So you can see each of the fields in the bottom we have this intent extra section. So we will list out any intents that we were able to scrape out of the application in the report so that you can play around with them. And then you can go ahead and put them in here and then try different values and whatever to go with them. If you need more you press a little plus sign there and it will create another key value pair set that you can play. And you get to this screen. So the, let's try this magic again. Play and even recorded demos can have problems, right? Let's see. Come on. Okay. And menu. So different intents can invoke different actions in the applications, right? So we give you this drop down list to choose what it exactly it is you're trying to do with it. For example, starting activity will just open up the UI element but if you start activity for result it will listen to see if anything was returned which can be an information leakage bug or something like that. So anyway once you're done filling out all the fields and selecting the proper settings you go ahead and you press send and of course the app crashes. That's just because that's the way Android handles when you send something that doesn't make any sense. So the next thing is obviously a file browser. You obviously need this to know if you want to look around and say maybe we reported there's some world readable file or something on the SD card that you want to look at or something like that. Basic functionality that any Android tester would need. Glad I spent so much time demonstrating the files. The next demonstration of the configuration options for a WebView. Thank you. So what they're doing is just showing you what different features look like when they're turned on or turned off. Also because it is version aware you'll notice if you click into some you'll actually see the application says this is not the right version for this test. So these things include like whether or not JavaScript is enabled. Okay. So this one tells you whether or not JavaScript is enabled and then it demonstrates the difference in the bottom left hand corner. I don't know if you can see it saying click here and I'm clicking it but it's nothing happening. It's actually trying to run an alert box but because in certain WebViews the alert box actually doesn't work. So it depends on which WebView client you're using. So if you're doing cross-site scripting tests you need to be aware of that. Whereas if I go into the Web Chrome it'll show you the alerts enabled. Also that's a no script block so if it were JavaScript were not enabled you would see a different view. So it's just letting you know what it would look like. If you click on any of the ones that aren't applicable for the device that you're on it will tell you this is not the right version for this test because obviously if you're doing API version specific testing you have to be on a device that matches the version you're up for. People will tell you tap-jacking is not an issue in Android but clearly it is. We stole this code from Invisium so thanks for publishing it so we can steal it. But basically you just put a transparent overlay over things so you could see that in fact we are overlaying over it and we can pass the touches through to the application behind it. This is just very similar to click-jacking on a website. You put some sort of opaque overlay on an app and then they play a game and it's sending all their bank account information to you or whatever you want to do via tap-jacking. Lastly, this is the most boring demo ever and this is the intense. All this is a background service that sits and listens for broadcasts from the application so if it sends a broadcast out it's just going to sit and listen. Unfortunately those are life cycle events that don't always happen so you have to just wait so there's nothing to show here. The cooler parts are the exported activities here, the exported components. So in this one it just pops open a UI element nothing to see here. Unless it's bypassing an off-screen or something like that it's probably not important. This is a login one but it's a little bit different because there's actually a result from this one and as you can see here our application grabbed the session cookie that was returned as part of the login process because it was not going to work. Here there's a username that it asks for and if you don't put anything in nothing happens so that's why it's important to know that there's these extras are supposed to be there so if you do submit the right extra with a value you'll see it returns the GPS location. So it's just showing you that context awareness is important, right? Finally we have a broadcast receiver and this is where we would, do we like it? This is where we want to do the real demo part real quick. The only thing is we know what you guys are going to do if we show you the phone number. So we don't want you guys texting us for the next six months or something like that. What we did is during the static code analysis phase we derived the you want to put it in? We derived the fact that there is an intent or broadcast receiver that was listening for something that had a phone number and an SMS message as the parameters it was expecting. We provided that to you to fill in with whatever value you wanted to and here's Tashara trying to hide his phone number and there you go. We were able to send a text message and the thing that you might not be aware of here is that our app doesn't have the ability to send text messages. What it's doing is it's proxying through the other to send the text message through it using its permissions. So I know we got to wrap up real quick here. All right. Let's just go back to this because I don't think we have time for anything else. Okay, so I think I got the two minutes left. To recap some of the unique aspects of Cork, unlike any tools we're aware of anyways, we do improve the chances of you decompiling the APK using multiple decompilers. It builds an APK for manual testing which includes some pre-built functionalities that you'll need for any Android tests. It creates ADB commands so that you can demonstrate common vulnerabilities via CLI and it finally creates a custom built APK built to attack the one you're testing. We really wanted to stay away from the forensics analysis type things. This is where we're headed and we wanted to stay away from the forensics analysis type stuff because those bugs are kind of lame and usually a simple grep away but if there's something you think we should include in that venue just let us know as long as it's not like grep minus our password or something like that. We'd be happy to add it. Cork isn't yet a dynamic analysis tool but that's simply due to time constraints. The entire thing was built in about three months and mostly in our spare time but with some gracious donations it should be. Cork has plenty of things to add in the future running out of time so we do plan on adding dynamic analysis, small inspection for improved results, non-Android specific Java vulnerabilities, ODEX support. We want to make them more accessible for you all and we're asking for your help if you know of bugs, if you're a developer whatever. Just if you know of a vulnerability maybe an old app that you guys patched a long time ago and you just want to make sure we have our WR labs for making Drozor which is kind of the inspiration for this, for the WebView exploits and Visium for the tap checking code and all the open source community for helping us, Jason Haddick and some other people for donating some vulnerable APKs for us to test on. Here's our contact information and if you want this will be on LinkedIn's GitHub repo later on this week. So, thanks a lot.