# Learn Android Hacking! - University Nevada, Las Vegas (2024)

## Метаданные

- **Канал:** LiveOverflow
- **YouTube:** https://www.youtube.com/watch?v=fPt6fJDjKKM
- **Источник:** https://ekstraktznaniy.ru/video/23413

## Транскрипт

### Segment 1 (00:00 - 05:00) []

All right. I will still say that the Google has a really nice bug bounty program for Android Pay really well. So if you want to get a little extra cash for Android Hacking mobile VRP. All right, Fabian, take it away. Thank you very much. Hello, everybody. Who has done some Android stuff before or is this all new to you? Okay, perfect. So then I hope I can give you, like, a quick start into Android hacking. So I'm Fabian, I'm from Germany. I'm a security consultant. By day. I do like code audits and report vulnerabilities and online. I'm also known as LiveOverflow. I have a YouTube channel hopefully, like you are basically my target audience. So if you don't know the channel, check it out. Like subscribe. And hopefully, you know these videos help you also further in your journey, maybe into security. So why am I here right now? You see the logo Hextree. We actually, together with Google, created Android application security courses. So if you fall asleep now during this short presentation or something, this is the only thing I want you to remember. There are some free courses thanks to Google sponsoring that. And hopefully, as Hlynur said, this should get you from zero to being able to find bugs in Google applications. So if that is a field that is interesting to you, yeah, check it out. Now for this presentation, I wanted to give you some tools at hand to basically learn hacking of everything. And this is a question I obviously get a lot how to hack a phone, how to hack Facebook, website, or whatever. So this is a very common question I get, but this question is way too broad. Like if you have these kind of questions, you will not be able to hack whatever you want to hack. And so in this short presentation, I want to give you basically the analytical tool, the approach, how you can answer these kind of questions yourself with the example of how to hack an Android app. All right. To answer this question, you want to first break it down into, I think the two most important questions. If you ever want to hack something. And that's basically where is the attacker located and what can the attacker given that position reach. We can also often it's basically the threat model where the attacker is sitting. And what the attacker can reach is usually the threat surface given that position. And now to now, we want to drill down further into these questions like what does this even mean for the threat model? Actually, the Google VRP has a really nice page talking about the different threat models for mobile applications. And so this is a table from the mobile VRP. And it basically shows you different categories. In these categories are exactly these attacker positions. And they are basically also ordered here in severity. So of course a remote no user interaction exploit. Basically use it right there with your laptop. And I'm up here with my phone. If you can manage to hack this application, that would be obviously the worst case. And then you see some variations there. And then of course based on the impact that what you can do with whatever threat model you have, then there are certain rewards. So it's lucrative. You should check it out. But for us the important part is of course now the attacker position here. And so what we can basically learn from this is that we have the threat model of the attacker controlling a website. It's very likely that you can get a victim to click on a website. So if you send me a DM on Twitter and I will for sure click on it and hopefully that doesn't do anything bad. So there is the attacker positioned in a website basically. And now the question would be what can that attacker reach from that position. Then we also have the case of malicious applications. There could be the case that a malicious application sneaks through and is able to be in the Play Store. But for Android especially, there are lots of alternative app stores as well. Or people download like cracked mobile games. So the threat model exists of you accidentally installing a malicious application. And so this is another position an attacker can have be in control of an application, and can it do anything bad with another application. And then also Google has here another position of an attacker which is sitting in the network being able to intercept the traffic and potentially do something bad to an Android app Now also one example of a bad

### Segment 2 (05:00 - 10:00) [5:00]

threat model because they are. You want to answer this question generally, like if you want to hack something, what is the threat model? And a bad threat model? For example, for a mobile app is consider your gallery, your photo gallery with all your private images. That's obviously a worthwhile target. It would be bad if your images somehow could get accessed, but if your phone is unlocked and you give it physically to the attacker, obviously there's no expectation to protect that kind of threat model. So you always want to think about what are reasonable security boundaries. What position is the attacker in that is like a reasonable attack that makes sense. Right. And this does not make sense. So always answer try to figure out the threat model where is the attacker. And once you know that you can think about the second question which is what can then an attacker reach. So given all these different. positions of an attacker. What is the threat surface? What is even exposed? Of course, in the remote threat surface, for example, like you sitting there attacking my phone here, the threat surface is very minimal. A lot of apps like the photo gallery for example, like it doesn't even make sense to think about the threat model, because there's probably no way to reach that gallery from the outside. But a messaging app or Gmail, for example, there's a small threat surface, you can send an email and it lands in my Gmail app. So there's a small remote threat surface. So this is always what you have to think about and consider when looking into an application and looking for vulnerabilities. Now this question what can an attacker reach is also one where you need to develop a lot of skills and experience and understand what even an application does and how applications work. And to answer this question, you basically think about actually the inputs, what are malicious inputs into an app, and who could answer this question? Best developers. These apps are developed. Developers have thought about the different inputs into their app. They have implemented app to app communication. So for example, when you are in your gallery app and you press on a photo, you click share. Then a small pop up will come up displaying you different applications, and you click on that and suddenly that image shows up in the other app. So there must be some kind of app to app communication where this gallery app sends the photo to this other application. And so this is something developers implemented. And so if you understand how applications are built and all these features and the Android concepts of how apps. Yeah this app chat communication works. With this knowledge you will also be able then eventually to attack these applications and break logic that was maybe implemented badly. And so one of the important steps is so that we need to learn Android app development in order to understand how to attack applications. Now, in the specific case of Android, it's I mean, it's true for anything you want to hack. Ideally, you want to understand the developer perspective, but in specifically for Android also, it even makes sense for two reasons. The first one is that you saw in the Google VRP table that a malicious application is a valid threat model, and somebody the attacker has to develop a malicious application. So you need basic app development skills to build that malicious application. And so we need some basic app development skills. And it's not enough. It's not much. We don't need to have any good designs or clean code. Even like we can write a very shitty app which probably just has a button. You click on it and something happens. That's what you need to learn. And then secondly, as I mentioned before there's a lot of app to app communication happening on Android. And so you want to familiarize with this yourself and go through the Android tutorials. How to build an app. And if you have never done like Android development, then all these terms mean nothing to you right now. But these are very, very important to understand when you want to hunt for bugs. These are concepts of the Android operating system concepts implemented by the Android SDK. Activities, for example, are the UI that you see. So each interface you see is usually an activity. The activity then render renders the layout Broadcast Receivers and Services are running in the background. You don't see them, but you can trigger them from another app and execute them. These are all concepts that right now make no sense to you. But if you start following the most basic Android app development tutorials, you will learn them and

### Segment 3 (10:00 - 15:00) [10:00]

you will intuitively understand them. And then you can also start thinking about attacking these concepts. And so basically to answer the question how to hack an Android app, we learned that we first want to figure out how we can build an Android app. And then you can transition to hacking an Android app. Now this is pretty much true for anything you want to hack, but especially in Android. Again, there's like a small middle step if you want to actually hack an application. And that is that we require reverse engineering. A lot of applications are built APKs from the Play Store, and you need to figure out the logic that these specific applications are implementing. And then once you have that knowledge now you can think about attacking that certain application. So how do we learn Android reverse engineering. I want to give you now again another analytical approach how to think about this kind of question. Even in a more general sense, how you basically can learn reverse engineering anything, whether it's a game or a microcontroller, binary or something. The method is so simple but very effective. What I will show you next. And for that we need, in the case of Android, we want to have Android Studio to build an application. That's the main software to develop apps. It has all the features for debugging. You can easily manage different Android versions, the SDKs it can you can use it with debugging, step through the code and really see what's happening. And you can manage your emulators in it. That's just the development environment that all the developers use. And the second tool we want to use is Jadx, which is the Dex to Java Decompiler. It's actively maintained. It's like basically the industry standard of reverse engineering Android applications. And so with these two tools together, the development side by side and the reverse engineering side Putting them together. We can learn Android reverse engineering. And let me show you how we do it. We just fire up Android Studio, maybe with a app development tutorial. We select, you know, we create a new project I generally always recommend with empty views. Activity that's the best one to start with. For our use case. We don't need anything else. We enter the application name. We just follow through all these wizards to set up a project. I also recommend to you to choose Java. Android wants to push regular developers to using Kotlin, and it probably makes sense for development, but for historical reasons because it always has been Java and so forth for our purpose, it's probably makes the most sense to stay with Java. And then Android Studio will generate a basic application structure that you can even. What? Okay. That's it. Oh, there we go. Okay. It generates a basic application structure. And even at the top there with the green button, you can hit play and if you have an emulator installed, the app will even show up. And that is so cool already you basically implement your first Android app. If you connect the phone in developer mode, it even will show up on your real phone. And I think that's a really cool experience too. But yeah, it generates some files, for example, the AndroidManifest. And now the magic trick to learn reverse engineering is we compile this into an APK, and we throw that into Jadx and compare it to the original. And this is very, very powerful. During reverse engineering you get overloaded with lots of information and lots of unnecessary stuff that you don't even care about. But if you know the development experience and you know what matters, you can ignore things that don't matter. So, for example, this AndroidManifest is very long. I have to scroll down here while the AndroidManifest in Android Studio is very short, there's a merged manifest button there and it shows you the combined manifest. But the reason for that is that there are libraries and the basically the Android SDK is adding some other features into there that do matter. Like if you want to hunt for Android bugs, like deeper in like the operating system, kind of like lower level. Then of course these things are interesting. Maybe you want to dig into how these actually work, but for the application itself, we can ignore them. So you know these provider that are there, they are like Android standard stuff. They are not the application logic the developer actually like implemented themselves. And so these are the kind of tricks and tools that you can use to now compare them. Now just briefly, the AndroidManifest is one of the most important files that you basically want to look at first. Any time it tells you basically declaratively what's the attack surface of an application?

### Segment 4 (15:00 - 20:00) [15:00]

Almost anything you can reach from the outside. The inputs have to be declared in that manifest. There are few exceptions. Maybe an app could start a web server or a socket or something. Or you have also dynamically registered Broadcast Receivers. So there are a few exceptions, but I would say 99% of the time the threat surface. What can be reached in that application is declared in that file. And so you want to be very familiar with and understand what it lists in there. And so when you reverse engineer at some point your first Android app, you want to look. This should be the first look that you ever do to check to see what it exposes. And it even goes a step further because Android you. If your application wants to use certain permissions, you even have to declare that. So this also tells you how critical or risky an application is. An application that does not use any permissions, for example, is probably like a non-important target. There might not be even anything like super critical, although it might be a small application, but then you have applications that register lots and lots of permissions so they can do things. And if you're then able to abuse that application, you can achieve quite a lot. So that also tells you is it a worthwhile target to go afterwards? There are certain vulnerabilities that depend on some of the declarations basically. So you can specifically hunt for these bugs and all these kind of experience you get, of course, when you start learning about it. Anyway, let's continue with our learning Reverse engineering. Besides the AndroidManifest, Android Studio also generated a MainActivity Java file that's kind of like the entry point into the application. It's like in C code, like the main function. This is basically what is executed when the app launches. And in this case the main activity has an oncreate method. And in that Oncreate method. You can see it's just a few lines, but there's for example set content view and that basically renders the UI interface. In this case it's referencing the Activity_main layout. So it's rendering the Activity_main layout that we will also see in a moment. And again we compile this and look at it in the Decompiled state. And this is how it looks like. And it's basically the same. And now you know that it's basically what the developer also implemented in CSS. And again here also you see another method that was added that was not in the original file that just some SDK added, which you can probably ignore because the main stuff is in the Oncreate method. This is where a developer probably adds some logic in that you want to actually analyze, and all the other files that you see, you know, like all the other libraries, come Google Android X, probably you can ignore this is not what we implemented. It's not nothing we had to do actually with. So you can just move straight to the main activity and look at that code as well. Now some let's dig a bit deeper. Let's have a look at this Activity_main layout in Android Studio. You have this nice interface where you can create your app layout. This is the layout that Android Studio created with this basic example. I didn't add anything. This is literally the template that it generates and it's just a single layout. Main layout with a text view and some text in the middle. But from the file name in the top you can see it's an XML file. So this is just the visual representation of the XML file. And so when we actually look at this file in the decompiler, of course we don't get a nice visual interface. We can find it in the resources layout folder. There's the Activity_main XML file. And that's the source XML file that basically creates the UI layout you see. And so we can see this layout has a text view. And by looking at that if you understand how this works you now understand okay. It's just a very simple layout. It has a TextView. Exactly. Here you can also enter it in the top right. You can see there are three buttons. You can even look at the XML view as well. So you can see again how the developer view relates to the actual decompiled view. And then I mentioned before, we want to add maybe a simple button because we want to build an app, a tech app where you click the button and maybe it does something. So let's see how that looks like. When we reverse engineer it in the visual view, we drag and drop a button in. And then of course in the generated XML file, we can see a button magically appears in the on the Android Studio view in the top right under the attributes. There's also an ID button. So these IDs are important. These IDs are referenced in the code. So when you are looking for what does this like if you open the app and you see this button and you want to

### Segment 5 (20:00 - 22:00) [20:00]

figure out what this button does, you maybe identify the layout XML. You see the ID that this button Spartan users. And you remember this because then later in the code we can then reference it. And so let's add an onclick handler to that button. So we call findViewById Android automatically generates like Java integers, like integers that you can reference directly in the code. So the resource ID button references that one button. It's the ID button. So we get the reference to the button. And we set an onClick listener there with an overridden onClick method. This is just basic stuff you learn in any Android tutorial. It's nothing fancy and then you see the logic in there. It takes the text view element that we saw the reference of that sets the text on it. And now we have a cool interactive app where you can click the button and something happens. And again we can look in the reverse engineered code. How that looks like it of course looks a little bit less nice. You know, if the developer added any comments and so forth, it's fun, but it's still the same thing. The fine view by ID you see the button is reference. This is set on Click listener and you see the onclick method executing. Then findViewById on the TextView and setting the text on the button press. Basically exactly the same. And now you reverse engineered the application. Yeah. Congratulations. You basically reverse engineered your first Android application and you have learned how a basic application is developed. Congratulations. Of course, on Hextree we go a lot deeper. We have lots of courses. We also start of course with a basic implement tutorial. So if you if this is interesting to you should check out these courses. We also have a course on reverse engineering Android apps. And I've heard that there's a challenge in the CTF that you can do in just a moment. And maybe for that one challenge, Some of the topics mentioned here could help you get started with that challenge. So maybe remember that title or so, or maybe you can peek in there and if you get stuck. But I also, of course encourage you to just try it without looking at this. Everything I showed you basically in this talk is a good start to get started with that challenge already. All right. Stay curious and keep hacking. And thank you so much for your attention. Yeah, thank you for that. And that means it's time to get serious