 Good afternoon. Our one o'clock speaker is Doki Doki on one step before GameHackers. Hello. Thanks for coming here. My name is Yongseong and I'm delighted to be here to talk in Defcon. Today I'm going to talk about Android emulators like Bluestack, Nox or something like that and the hooking techniques on the emulator. Originally, Nevermoe who is my friend was going to give this presentation but unfortunately he was unable to come here so I'm covering for him. He's a security engineer working for DNA. And my name is Yongseong. I work for Line as a security engineer. Okay, then let's finish the introduction and let's start with the agenda. This is today's agenda. Background of this research, emulator internals, hooking and demo and conclusion. We define three roles in the game treating threat model. Users, cheaters and vendors. For PC games all three of these roles have full control over their pieces. They are allowed to install or run privileged code but on mobile devices it's different. The user usually don't have permission to access over devices unless they rotate their devices and this is the same for game developers. However, the cheaters usually won't rotate devices then the cheaters are the most powerful. No one can stop them from cheating but this doesn't mean the cheaters can make a profit. Actually, yes it is true that the cheaters can hack their devices but if they want to sell their cheating tools to users they will have to persuade their users to route their devices. Which is not an easy task. So for cheaters they think of an easy way to distribute their cheating tools. The emulators. Especially Bluestacks and Nox but not AVD from Android Studio. AVDs from Android Studio are basically for x86 emulation which does not support APKs with ARM library only. Or for ARM emulation which is super slow. On the other hand, commercial emulators like Bluestack and Nox use a technique called Houdini which I will discuss later. For these commercial emulators they have a highly unified environment so you don't need to turn your software to a different firmware. API level, etc. And what is better here is that the emulators are usually very easy to route or they are shipped with a routed environment in the first place. According to my investigation the most popular cheating approach on emulator is touch simulation. And it requires route privilege or shell access. But it does not involve modification of game binary or hooking skills. This means touch simulation is a gray zone. You can say it is cheating but you can hardly say it is a crime. On the other hand you can say that a cheat by hooking does not show up on emulators. This is because game codes are usually native and on commercial emulators they use Houdini to translate ARM codes to x86 and runtime. So this makes it difficult to hook on emulators than on physical, pure devices. So the purpose of my research is to enable hooking on commercial Android emulators. Especially hooking native ARM binaries on x86 emulator machines. The emulators target I have investigated are below the blue stacks, nox and radian. You can tell from the table that these emulators are very much alike. Maybe they chose these emulators coincidentally, I'm not sure but it could be. If you try to run an ARM binary on emulators command line, you will find it will be executed properly. This is because the emulators is the feature on Linux called binFMTMISC. With this feature you can register on certain binary signature or magic number with a certain loader. In our case when we execute on ARM binary on an emulator which is an x86 machine, Houdini will be used to execute the ARM binary. In this case it is easy to inject your ARM library to the target process using LD preload and perform hooking from your injected library. However, another popular inline hooking techniques using ptrace doesn't work. If you try to call x86 version ptrace, you won't make it work directly because you can't call x86 version dlopen system call to open ARM library. Maybe you want to try to run an ARM version ptrace so that you can call ARM version dlopen but this doesn't work either because ptrace is not fully translated by Houdini. Then can we inject our ARM library using LD preload and also take advantage of it in our Java application? The answer is no and I'll show you why in the following slides. To use LD preload we can use the red property provided by Android. When you set the red property the application startup is like this. The Jigoth is listening on a socket and ready to fork itself whenever a startup request comes. After the child process is forked from Jigoth it executes the shell first instead of executing an application directly and then executes the application with the shell. This is the detail of the call stack. You can see that after the Jigoth forked itself the function exit application will be called and this function in concatenate some command line strings including our LD preload parameters and executes the command string with the shell. So you can see that the final command of starting an application with red property looks like this. The LD preload is correctly injected into the command line. So far it looks fine that we can inject our library to the Java application using LD preload but look carefully. The shell command under system-bin folder is of x86 and the library we want to inject is of ARM. So we cannot use LD preload in Java application. So now we have to dig deeper into Houdini. For Android 5 with ART, if the application startup request from activity manager is received the Jigoth forked itself and it is at a time that Houdini is initialized. By the function initialize native bridge. What initialized native bridge function does is very simple. It just registers some callbacks to a structure called native bridge callbacks from LibHoudini SO file. Note with the function load library and get trampling. You can think of them as an ARM version DL open and DLCM. Whenever the Java layer wants to load on native ARM library it calls this load library function. You can find that a structure called native bridge LTF and some function pointers are there. These function pointers will be eventually registered to the native bridge callbacks structure. In contrast, in Android 4 which comes with Dalvik virtual machine we have to modify Dalvik virtual machine code directly to use Houdini because Android developers hadn't expected Android to run on x86 architecture at that time. Here you can see how Houdini is initialized. In hook DL open function it first tries to open target library by calling the x86 version DL open. And if it fails it registers Houdini's DVM2 DH DL open handler inside the Houdini hook init function. Finally it calls the handler to open on ARM library. There were interesting facts that I found when conducting my research. As far as I know Houdini was developed by Intel and they didn't provide any commercial license of Houdini publicly. As you can see there is another emulator called GenMotion which is also famous but not included in my research. It was not bundled with Houdini when it was released in order to avoid breaching license. Instead it encourages users to download and install Houdini by themselves. But you can see blue step. It is using Houdini from its release. And deliberately or not it seems that they are trying to hide their using Houdini binaries. As you can see from the decompiled code of DVM it tries to open lib3 bit.sfl which doesn't look like Houdini. But when it fails to open it looks the message which says it fails to load lib Houdini. Now let's see some existing hooking frameworks. First exposed works by substituting the app process binary with a patched one. So it loads each one JAR file as startup. Exposed is a only Java layer hooking framework. And Frida is my favorite one and it can do almost everything across massive platforms, layers and architectures. But according to the authors it will not support commercial emulators like notes for now. And substitute also works in Android but it is outdated so I won't discuss it now. This is a normal hooking process using ptrace. The tracer calls ptrace to attach to the target process. And then use ptrace to call dlopen to load hooking library into the target process. After injection library is loaded into the target process memory the function in the library is executed to perform the hooking stage such as modifying the entry address of target function. Here comes my first idea of hooking on emulators which use Houdini. It's only one more step than normal process. I called ptrace to attach to a target process and to load the x86 version hooking library inside the x86 version SO file. You call the Houdini's load library to load the ARM version hooking library. Finally inside the ARM version's library it hooks and modifies the instructions of the original ARM SO file on the memory. The best part is that all the modifications on the ARM SO file will be automatically retranslated to x86 instruction by Houdini. After I completed my hooking framework by utilizing convenient interface provided by Houdini I realized that the key point to hook on emulator is to inject your ARM library to the target process. And being aware that exposed has already enabled you injecting Java code to target process you can just take advantage of this feature to call system.load library in the target process. Note that the system.load library function will take care of architecture-dependent native library so you don't even need to know how Houdini works. Method A and B have their one marriage and de-marriage. Method A utilize the ptrace function so it is more stable and method B enables you to early trace excluding some extreme conditions and does not trigger any anti debug mechanism. I'll give you a simple demo which just changed the demo games result by hooking. This is the original play and before the second play I hooked the game to make it always win. This is the second play even if it loads I always win. Note that this game is shipped with ARM library only and it is running on NOX emulator. Conclusion. Not only mobile games but also cheating is getting more popular and I expect a cheating use hooking becomes more popular on mobile games like cheating on PC games. And I would like to know what is going to be changed after my presentation. Might nothing be happened but some of game vendors might reconsider their attitude to emulators. Thanks for listening and if you guys have any questions I will be outside so please ask.