 So as I was saying, I basically brief everybody what is dynamic instrumentation, and then how do you do it on mobile, and what does it has to do with mobile security, and search and search. So before I start, I would like to do a survey. I would like to know if anybody does any of this on the presentation. Maybe one. OK, that's often. Yeah, exactly. So basically, that's how I started as well. So I'm a security engineer, and basically, I was really into hacking games, and then attaching my PSP firmware. That's how I got into this eventually. The hacking is more interesting than the game. So part of the motivation for this dynamic instrumentation is basically to understand how a code source system works. I know that this is an open source talk, but sometimes we need to integrate our open source software with some closed source system, and they might not necessarily share the API or the documentation. So reverse engineer will come into place, and dynamic instrumentation is one of the tools that you can use. And also, if you want to set up, we analyze the office data binary in the context of malware, reversing, or whatever, this could be used both ways. All right, so when you talk about dynamic instrumentation, what is it? Instrumentation is basically monitoring a binary behavior, or basically adding extra additional instruction onto the binary. So nDynamic Instrumentation is basically doing that while the binary is being executed. It is also known as function hooking or sizzling. And basically, in one sentence, it's executing your own debug script inside another process. So to illustrate this better, basically, on your left is basically the instruction that you will see when you are running the application on the CPU. There is one, two, three, four. And if you do some instrumentation, you would be able to modify the application behavior by adding additional instruction before and after, and even removing certain instructions. So how can you use it? You can basically use it to access process memory, to override functions when some application is running. You can basically, yeah, there's a lot of stuff that you can do. You could basically change the course of the application instruction set and do whatever things that you wanted to do. So why do I care? Because to me, as a secret engineer, unfortunately, this is one of the qualifications. A lot of times, we have to reverse engineer stuff, and sometimes even malware as well. And dynamic instrumentation is a very efficient way to understand how a binary works. So this is the site that I had to call for a bunch of security students in NTU. And so this is something that most students is involved in doing wantably to research and malware reversing and even hacking as well. It's just some points that are why they should care. So enough of abstract concept. There are some tools that you could use to basically try out mobile instrumentation, like Frida, X-Pose, and C-Script. Does anybody have any experience with any of those? Maybe one or two? X-Pose, C-Script? So Frida is something that I use a lot right now. X-Pose is, I guess, is what everybody is familiar with. And also C-Script is basically a mobile instrumentation that's very popular on iOS, built by Saurik. And the tool that I use a lot is Frida. Have anyone heard of Frida? Oh, that's actually not the Mexican painter. OK, that as well. So one of the reasons why Frida was popularly used and also why our team or anybody that I know in security engineers using this a lot is because it basically supports a lot of different operating systems. And what it does very interestingly is that unlike attaching your debugger onto a process, Frida basically injects a JIT, a JavaScript engine, like Ducktape or even Google's V8. And basically, the debug script that you wrote can be JavaScript. And I know that recently they even support WebAssembly as well, so there's even more stuff that you could do. So back then, there's a lot of instrumentation framework that has very limited support, maybe on your Linux or some money on Windows or Intel X86 architecture. But in this case, Frida basically put a lot of initiative to create different bindings onto a different operating system. So in this example, basically the debugging, which is the process that we're trying to debug, Frida will inject a shed library onto the application. And the shed library will wait for the debugger to send instruction to it, basically to see what your debug script has to do. The communication channel is basically debuts over TCP. And I'll share a little bit more about this later. So Frida, there's a lot of ways to do it. In mobile security, there's two ways that it matters to us. One is embedded, and another one is injection. Injection is really useful if you have a rooted Android device. But in the case of iOS, you might not have a Joe Brocken device all the time, and it's getting harder and harder to get one. So basically what you could do is you could basically embed the Frida agent as part of the adelip onto the application, and then it will load. And this will work in a Joe environment. There are some restrictions, but for normal debugging or instrumentation, it will work. All right. There's a very detailed Frida API. Not that detailed, actually. There's still a lot of stuff that happens. But it gives you a good idea of what it can do. But basically, for normal mobile security instrumentation, there is two things that we care about. How do you instantiate an object? And also, how can you hook onto the function? The second one is basically using Frida's APIs to hook on the string builder function. So when string builder function is being called, I could basically use this function to pass whatever argument that is affecting and hook onto it. And over here, it's basically when string builder function is being called, it will just console lock the new string builder function. And the first one is for you to instantiate a Java object. And this could be useful, because sometimes some function that you are hooking requires an object. So to give you a quick example of a very, very common case that we would use in dynamic instrumentation is when you're running any application, I think some of the popular banking apps or whatever apps, they usually would check whether if the Android device is rooted, which is very common. And the highlighted ones are some of the patterns that they will look for to check, whether if the SU binary, a binary is on whatever path. And if it is, then you return true. And there's more other condition as well. So there's a multiple to check. To bypass it, basically, like the API that we showed before, you were able to hook onto the function. So over here, basically, I hook onto this function, sg.vantagepoint.a.c. The reason why it is this is because the APK that was reverse engineering, it has pro-gut, and it was optimized. And so you could see over here that when this function, so the first one is that when a first function was hit, it basically just returns zero. So it means that it's false. So in a way, we kind of hook the function and return false, no matter whether if the application discovered powers that. So it's a very basic way of doing dynamic instrumentation. And then there's some other alternative way to do dynamic instrumentation as well. Because for the method that we showed before, you have to customize your debug script every single time when you want to instrument, you want to bypass the root detection. So this method, basically, it will hook on some Android function, such as activity or exit cost. When the root detection has been detected, it will usually exit the application. So we basically hook on those activity and preventing it from exiting itself. So some application, they will have secrets, and they store it. And if you wanted to print out the secret, you could able to hook on some, you could able to hook on the function that we're using and print out the argument or maybe the result so that you could see the secret. So basically, this is a script that I have. So I have a, I think there was a missing slide. But basically, my friend and I, we created some hacking challenges for you to practice dynamic instrumentation. It's called OWAPS, Crack Me, Mobile Crack Me. So if you're interested, you can check out. I think I have some video here. We still have a lot of time. OK. I could basically just show you guys what it is. So on my right, it's basically an emulator that already has a feedout running. And then on my left, it's basically I'm trying to run the feedout script. So you can see that when I execute the application, my Crack Me that we created, it would tell me that there was root detector on the device. And so on the terminal, it basically modified the onclick function. So when I click on it, it will usually trigger a function to exit the application. But right now, I hope onto the function and preventing it from doing anything. So even if I do onclick, it doesn't do anything. And right now, basically, I'm demonstrating hoping a decryption function. So even though on the terminal, you didn't see anything, but at the debug script, I basically hope onto the decryption and print out the argument and also the return value of what I was able to do. So this event, but things like this can be, this is just a Crack Me. It's a challenge created by humans or humans. So it could be irrelevant to what we're doing. So for example, this is something that I just added this morning, so maybe there's some error. So recently, I was reading through malware as well, because I think that it's fun. It's also another challenge that was created by humans or humans. So we're following Android malware. There's this very popular app called Anubis. And Anubis, they made some changes recently. They basically have a loader, so that when you're doing static reverse engineering on the malware, you're then able to mark the actual page. The payload will be executed when you are running the application. And the victim to know that there is actually a new payload that is replacing the actual application, the files will be deleted immediately. The whole process cannot be on Android, so that they need to write the file now. For reverse engineer, obfuscated application doesn't mean the actual payload. So like I mentioned earlier, I want to write a debug script, customize it all the time. So on it, which is a Lipsy, which is a low-level Android Lipsy function. And I basically hook on this high-level function that they use. And yeah, so over here, you can see that I intercept it by just printing a console wrong. Bring the file, print out, and that's it. So it doesn't do anything. So do note that not the resolution, but just that the color of the emulator is very different, because this is one of the pattern that the new Anubis malware did. So to inform the victim that the phone has been compromised, they try to change the color of the whole device as well. Not the whole device. Yeah, but basically, you see that it's very different. So Flash Player is the malware that they're trying to fit. This is the malware. OK. So basically, I basically log in SSH into my Android emulator. And I try to watch the data directory of the application. And basically, try to see whether if there is any payload that was created. Do note that the watch function, it's a two-second frequency. So the delete function should be executed even faster than me. So if you notice, so do note the Flash Player application. Once the malware has been executed, the icon is no longer there. I think it's pretty interesting. So it does a lot of things. It will basically mess up with your accessibility so that on your device, the whole thing will be different. And yeah, you can see that Flash Player is no longer there. And even on the terminal as well, we would not able to see any meaningful payload, because once the payload was created, it will be removed by the way. And so right now what I did is basically I removed the Android malware. And then I reinstalled again. This is a bad idea. Yeah, exactly. So certain malware, they are really smart. They only package the native library into ARM, ARM Binary, and can support ARM architecture, but just that it will be really, really slow. And they will sort of encourage user or US engineer to do it on their real phone, which is a bad thing. But yeah. So right now I'm reinstalling the malware, not learning my lessons. You can see that Flash Player is there. So the difference this time is that I will be initializing the application with Frida to perform what Frida called an early instrumentation. So when the application was being loaded, it basically prevented from executing any instruction that I have in the app binary. And they tried to hook onto the function before the actual function was executed. And the function that we hooked this time is basically a low-level function. I'm going to start my Frida server. So when I resume it, you can see that there's a lot of unlinked function that was being triggered. And then the Frida will basically try to hook onto every single one of them and replace it with this error message between us. Then you can see that the malware will be executed. And right now I'll basically SSH into the emulator again. And you will be able to see some differences. So I'm not sure if you can see. The Java file here and also the next file is basically the payload that the binary executed. To give you an idea of when you download the malware and this dump payload, what is the difference? Basically it's something like this. So it's all gibberish. And then if you compare to the dump malware, you can start seeing that it is copying intent. And also they are registering, register, and do even more stuff. So this is the actual payload. And if anybody would try to reverse engineer this static application, not running the malware itself, they will not be able to see anything. This is an example. And over here you can see that they basically use a lot of Java reflection to confuse the reverse engineer. And over here, most of the functions and stuff, you will be able to follow them. And you could start seeing even more Android-native. So this is just a small example. Frida has been an open source project since the start. And it came a long way. And if anybody wanted to get into dynamic instrumentation, I would recommend you guys to try it. So some recommendation for application developer. This means a different thing for you. If you're creating a game, anybody could be able to modify the app logic or what. It's very important for you to understand as an app developer or whoever, to consider what portion of the logic should be on the client side and what portion of the logic should be on the server side. Even in grab as well, it's a very hard thing because sometimes the developer wanted something to be optimized further. So they wanted the logic to be on client side, which is something that we always try to check with them. OK, this instrumentation thing happens. And the environment, it belongs to the hacker or whoever. So you have no control with that. All right, I think that's it. I mean, reversing mobile application is illegal. So do not do it. There is some practical use cases as well. There was this guy who built an iOS application. And he tried to reverse engineer it over app and all other applications. And coupled all the deep links that all other application registered in his application. So you could able to automate certain flow so that every 9 o'clock you order a grab car or Uber car from Lifelong Learning Institute with the airport. So he reverse engineer it and he built an application out of it and Apple eventually acquired it. I can't remember the name. So this is all my contact emails, if anything you could ask me. And yeah, not surprised grab is hiring. We're hiring software engineers, security guys, and also drivers as well if you can drive. Any questions? If anyone have any questions? OK. So it was this guy called Oli. I think he's from Norway. And then it was partially sponsored by this company called Now Secure.