00:00:00.417-->00:00:05.417 >> So um good morning, thank you for attending a Sunday morning uh talk. So today we’re going to 00:00:07.917-->00:00:12.917 talk about Android packers, how do they work. And we’re gonna analyze a few of them and um I’m 00:00:15.750-->00:00:20.750 going to show a method we developed a tool that can handle most uh uh it’s a generic way to 00:00:23.708-->00:00:28.708 handle most of the packers in the the market. So who are we? I am Avi.I’m uh currently a 00:00:33.208-->00:00:39.583 founder at myDRO but uh I was formally a Mobile R&D Team Leader at Check Point for a few 00:00:39.583-->00:00:44.583 years and this is where I did, did this uh research. And before that I was in security research 00:00:47.500-->00:00:52.500 in Lacoon Mobile Security. And uh unfortunately sla.. Slava, my uh co-presenter could not attend 00:00:54.625-->00:00:59.625 today. But except being a very uh talented researcher and a good friend, he also did a lot 00:01:01.708-->00:01:06.708 of the heavy lifting around this research. We miss you Slava. So uh let’s go to business. So uh 00:01:10.958-->00:01:17.667 Boxing Apps. Okay, so Malware authors use various uh boxing or packing techniques to prevent 00:01:17.667-->00:01:24.000 Static Code Analysis and Reverse Engineering. Uh Malware author invested a lot of time in 00:01:24.000-->00:01:30.333 developing his cool Malware. And he doesn’t want you know uh security guys to understand 00:01:30.333-->00:01:35.833 what’s happening, detecting it through, they’re using their automatic tools or uh with 00:01:35.833-->00:01:41.250 manual reverse engineering. This is the same as in the PC world where most of the packers and 00:01:41.250-->00:01:46.250 most for he malware today are packed. So how can one um protect his code. So they can 00:01:48.458-->00:01:53.458 use a proprietary technique or a third party software that can uh protect the apps code. So what 00:01:57.083-->00:02:02.083 does this software should do? So this includes code protection, anti debugging, anti tampering, 00:02:04.458-->00:02:11.333 dumping, all of the methods that would prevent the security guys um the static code analysis 00:02:11.333-->00:02:16.625 engines, the reverse engineering from understanding what’s happening inside the app, the 00:02:16.625-->00:02:21.625 malware. And what was our motive to this research. So in the PC..PC world it’s it’s for years 00:02:25.458-->00:02:30.458 now that Malware’s are uh uh are uh packed by uh different packers. Also we see this trend 00:02:34.167-->00:02:41.083 rising in the Android world. And this is a snapshot of an analysis done in a checkpoint 00:02:41.083-->00:02:46.083 system from uh May. And we saw that almost 25 percent that the packed apps were detected by us 00:02:53.333-->00:02:58.750 as malware. And we asked ourself.. can we um improve the detection, is this really the 00:02:58.750-->00:03:04.000 amount of malicious apps from the all the pack apps or maybe we’re missing something because 00:03:04.000-->00:03:11.583 we’re not going and doing static code analysis or fool static code analysis for this app. 00:03:11.583-->00:03:19.958 These apps because they’re packed. So this was our motive and saw uh in order to 00:03:19.958-->00:03:24.875 understand how packing works and to find a generic way to unpack them. So uh what techniques 00:03:24.875-->00:03:33.958 exist to protect an app’s code. So let’s talk about the main three. We have Obfuscater’s, 00:03:33.958-->00:03:42.833 Packer snap Protectors. So what is Obfuscation? So Obfuscation is um adding redundant code the 00:03:42.833-->00:03:54.542 uh to the main app’s code. It doesn’t affect the functionality of the app and changing the 00:03:54.542-->00:04:01.083 function name and the variable names and this is done in order to prevent or reverse engineer 00:04:01.083-->00:04:06.833 to understand what’s happening inside the app. And uh today in the Android world there’s a 00:04:06.833-->00:04:13.917 default uh obfuscater tool called ProGuard which comes with Android studio and used by most 00:04:13.917-->00:04:22.667 of the Android developers. And.. but I have to say it’s not the best obfuscater in the market 00:04:22.667-->00:04:29.292 and for uh.. really not really experienced reverse engineerer it shouldn’t be any problem to 00:04:29.292-->00:04:34.958 understand what’s happening inside the app. And another method which we are going to 00:04:34.958-->00:04:44.292 concentrate here today in our talk is uh Packers And what does Packing do So let’s say Ive 00:04:44.292-->00:04:52.917 an APK, an Android app. And it contains um a DEX file. What’s a DEX file? It’s a small byte code 00:04:52.917-->00:04:59.625 that what’s happen..happens to the.. the code after it’s being compiled. And um this is what 00:04:59.625-->00:05:08.875 Android executes. So I have the original uh code and what does the packet process do? It takes 00:05:08.875-->00:05:14.167 this original code and encrypts it, packs it in some in some manner. And the way it opens it, 00:05:14.167-->00:05:21.875 it adds a packer loader which will be the now the entry point for the execution of the app and 00:05:21.875-->00:05:26.042 once the app is executed the packet loader will take.. take the bundled original encrypted 00:05:26.042-->00:05:33.333 DEX file and load it to the memory, unpack it and load it to the memory so it can be used by 00:05:33.333-->00:05:44.583 the app. And um. there’s also Protectors. That. uh that works. uhh in a better or 00:05:44.583-->00:05:51.333 different way. They take the original DEX file but they don’t only uh encrypt but they also 00:05:51.333-->00:05:57.125 modify it. Uh why they’re doing that, they want to add another layer or protection. Let’s say 00:05:57.125-->00:06:05.542 one of the protectors uh that we saw uh in the wild adds an encryption in the class level. 00:06:05.542-->00:06:18.042 Meaning if only when the class is initiated, uh eh hmm. lovely. Um, the encrypted uh, 00:06:18.042-->00:06:26.417 only when a class is initiated it will be decrypted. And what’s surprising here that we didn’t 00:06:26.417-->00:06:34.750 see.. see.. saw uhh a large use of protects, protectors in the wild. And our, what we thought 00:06:34.750-->00:06:42.333 is it might because it might effect the.. the logic of the malware. Malware offers uh don’t 00:06:42.333-->00:06:51.875 use it as much as packers. So we decided to concentrate in our research on packers. So in order 00:06:51.875-->00:06:57.750 to understand more on how Packers work. We need to go back a bit to basics and understand 00:06:57.750-->00:07:05.292 some things about uh Android. So let’s talk a bit about ART. The Android RunTime VM, this is a 00:07:05.292-->00:07:12.917 schematic of how things looks in Andorra 6, which is good enough for us to understand this world. 00:07:12.917-->00:07:21.042 So what happens? How does Android uh RunTime Vm works? So the Android RunTime VM can work 00:07:21.042-->00:07:28.208 in two modes. One, interpreting the small byte code and the second is working with a 00:07:28.208-->00:07:34.292 compiled byte code. Ahead of Time compilation. That was something that was intercede in 00:07:34.292-->00:07:41.000 Android 4 point 4. And what happens is when you install an app, it goes through a process 00:07:41.000-->00:07:47.583 of compilation and then the VM will work on a compiled uh ELF code. And while this was done 00:07:47.583-->00:08:00.667 and this allows to gain uh a lot of improvements in ram, battery uh performance, and run time 00:08:00.667-->00:08:04.208 start up run time of the application. But it’s important to remember that the VM can work 00:08:04.208-->00:08:11.542 in both ways. Interpreting a [inaudible] code or what uh a compiled eh native. So what 00:08:11.542-->00:08:19.417 happens when you load a DEX file? Uh when you start an app. So uh you trigger the zygote 00:08:19.417-->00:08:27.625 process which is an empty process that contains preloaded classes and it’s diagrammed to 00:08:27.625-->00:08:33.708 show the startup time of the app. And what happens the cyber process forks itself into an 00:08:33.708-->00:08:41.708 empty app process and loads the app code.. the uh uh the OAT file. But what happens if the 00:08:41.708-->00:08:47.583 OAT file is missing? So what will happen is it will trigger DEX2oat, that’s the process that 00:08:47.583-->00:08:54.583 compiles the DEX file into an OAT file. And we’ll use the oat file in order to execute the 00:08:54.583-->00:09:03.667 app. So I talked a bit about Oat files. So let’s try to explain what what is it? So Oats file is 00:09:03.667-->00:09:11.625 basically an ELF file with some uh added sections. One of them is Oats data which contains the 00:09:11.625-->00:09:22.458 original DEX file and one of the is the oat exec which contains the compiled version of the DEX 00:09:22.458-->00:09:31.708 file. And both of this sections are used uh by Android the ART Vm when executing an app. One is 00:09:31.708-->00:09:36.958 for uh creation of different headers and one for inter..interpreting the app. But 00:09:36.958-->00:09:43.875 it’s important again to note that you don’t have to have the native file. All of the Oat exec 00:09:43.875-->00:09:50.292 in order to execute an app. You can back fall uh to the interpreted uh to the smaller 00:09:50.292-->00:10:00.542 version and interpret the code. So now that we understand a bit more about Android. Let’s try to 00:10:00.542-->00:10:07.292 think about ways to unpack an App. So the first one can be finding the algorithm. We can 00:10:07.292-->00:10:15.917 try the different packers. Try to analyze how do they pack an app, which algorithm do they 00:10:15.917-->00:10:22.125 use. And do the back steps in order to decrypt the app. The problem with this is this 00:10:22.125-->00:10:27.583 doesn’t scale. You need to understand each packer, how it works and even if a packer only 00:10:27.583-->00:10:35.083 do uh a minor modification to the packing algorithm, the script will break and you need 00:10:35.083-->00:10:41.583 to start your research again. So this is not the way you want to go. Another method could be 00:10:41.583-->00:10:48.875 extracting a DEX file from the compiled OATs. As we said we have the DEX file inside the 00:10:48.875-->00:10:54.417 OAT. But what we saw in different packers is you don’t have to have the DEX file inside 00:10:54.417-->00:11:01.042 the oat, you need only part of it. So some of the packers delete the DEX file from the 00:11:01.042-->00:11:09.042 Oat. So you can just take it and use use the DEX file. Another method might be just dumping the 00:11:09.042-->00:11:16.125 DEX file from the memory. But again this is not uh uh always work, does not always work 00:11:16.125-->00:11:26.417 because uh the DEX file the DEX might be missing and the packer will use the oat file. So we 00:11:26.417-->00:11:33.375 wind up thinking about using a custom Android ROM. Which uh this is something we already do 00:11:33.375-->00:11:40.292 in Check Point. We have amec analysis engine and uh maybe introducing a few modifications 00:11:40.292-->00:11:47.042 to the custom Android Rom that will allow us to dump uh to place a few hooks in interesting 00:11:47.042-->00:11:52.833 places. And this will allow us to dump the DEX file and pass it to our uh static code analysis 00:11:52.833-->00:12:03.083 engine. So before continuing on I want to uh talk about a few notable works that was done in 00:12:03.083-->00:12:08.125 this area. One of them was Android Hacker Protection Level uh Zero and it was presented 00:12:08.125-->00:12:12.708 here at Def Con a few years ago. And it was a very goo talk that talks about the different 00:12:12.708-->00:12:19.708 packers and protecters uh in the wild and they also released a few set of scripts that dumps 00:12:19.708-->00:12:26.583 uhm that work on some of the packers and dumps uh DEX file. Another very interesting talk 00:12:26.583-->00:12:32.833 from the guys that released the DEX hunter tool which is a modified version of Android 00:12:32.833-->00:12:42.208 Dalvik/ART VM and it really reconstructs a new DEX file from.. from the memory. While 00:12:42.208-->00:12:48.375 this was a very interesting project, it was not what we aimed for. We wanted to get the 00:12:48.375-->00:12:55.000 original DEX file before the packing process was begin uh was began in order to have the 00:12:55.000-->00:13:03.500 same hash as the original file. So we want to go in a different path. So what was our approach? 00:13:03.500-->00:13:11.083 We wanted to find a solution that would require minimal changes to the Android source 00:13:11.083-->00:13:17.292 code. So it will be portable. And it will work on most of the packers. So how how did we do 00:13:17.292-->00:13:22.333 it, how did we address the problem. So we took the most popular packers that we 00:13:22.333-->00:13:28.583 witnessed in our systems and reversed them. We additionally analyzed the way Android loads a 00:13:28.583-->00:13:35.417 DEX file in order to understand truly how it works. The results was a patch of a few Android uh 00:13:35.417-->00:13:42.667 lines the Android runtime that will allow us to dump the files and uh analyze it in our static 00:13:42.667-->00:13:51.667 code analysis. So what were the analyzed packers that we looked on. So the most popular packers 00:13:51.667-->00:13:59.875 encountered were um Baidu, Bangle, Tencent, Ali, and 360 Jiagu. And what’s uh Baidu is 00:13:59.875-->00:14:06.208 the same huge Baidu Chinese company that you know. They also have a packing service. It’s a 00:14:06.208-->00:14:14.125 web service, you send an APK and you get the packed version of of it. It was very surprising to 00:14:14.125-->00:14:20.917 see that they offer this kind of service. So in this talk, I am going to talk about Baidu and 00:14:20.917-->00:14:27.667 Bangle. And what’s interesting about them is they work in a bit different method but covering 00:14:27.667-->00:14:33.375 both of them allowed us to find a solution that works on almost all the packers we encountered, 00:14:33.375-->00:14:45.042 encountered. So let’s try to think about the abstract way in which a packer should work. So 00:14:45.042-->00:14:53.667 um as I said, you have the packer loader it will load the bundled packed DEX. So it will 00:14:53.667-->00:15:02.542 load the DEX, this will trigger libart, the ART VM um to uh work. And opening the DEX file, 00:15:02.542-->00:15:10.167 map it’s data to the memory. Uh then you have the DEX in the memory. But something is missing 00:15:10.167-->00:15:18.917 here, where does the unpacking process takes place. So what we thought is that most of the 00:15:18.917-->00:15:29.417 packing uh unpacking process will be inside a native a native lib function and uh file. 00:15:29.417-->00:15:36.208 And why? Because reversing of a native file its it will be harder for uh reverse engineers. 00:15:36.208-->00:15:43.000 So it’s a good idea to put your unpacking logic in an obfuscated and protected manner and for 00:15:43.000-->00:15:49.208 that you need to not do it in the in the java byte code packer loader but in a separate 00:15:49.208-->00:15:57.667 native file. And what does this native file do? It needs to interject itself somewhere so it 00:15:57.667-->00:16:06.417 could decrypt and unpack the packed file. So he will do it with hooking. It might hook lib 00:16:06.417-->00:16:15.208 art lib c and uh during now when lib art will open the file the unpacking process will take 00:16:15.208-->00:16:25.375 place. And then libART will eh get the original DEX file that it can execute. So cool. Now 00:16:25.375-->00:16:32.667 that we thought about an hypothesis of how packers should work we want to verify if it’s 00:16:32.667-->00:16:40.917 really what we see in the field. So let’s look about uh the first packer, Bangcle. So in order to 00:16:40.917-->00:16:48.500 identify Bangcle it.. its very easy it has uh uh various classes we chose in every packed 00:16:48.500-->00:16:54.625 up by Bangcle. And um different files. One of them is the native packer which is used to unpack 00:16:54.625-->00:17:05.083 an app. And the packed version of the text DEX file which is Bangcle classes. And this is a 00:17:05.083-->00:17:14.417 snippet of the java loader implementation. And we can see that Bangcle loads a native 00:17:14.417-->00:17:21.917 lib a native lib file. And calls fu-JNI which is a bridge between java and uh calling native 00:17:21.917-->00:17:28.958 functions to uh functions from this native file. And then it loads the DEX file which will 00:17:28.958-->00:17:38.583 trigger uhh libART SO. So we wanted to understand what’s happening inside the native 00:17:38.583-->00:17:50.500 file. So we try uh.. open it with IDA and it crashed. And uh this is one step afterwards and 00:17:50.500-->00:17:54.125 uh we could uh after we fixed it, I’ll explain in a second how we did it. Uh but what we 00:17:54.125-->00:18:00.875 noticed here is we didn’t see uh any mapping between the native functions and the functions uh 00:18:00.875-->00:18:06.708 names in the java interface. Meaning something is missing here where does this mapping 00:18:06.708-->00:18:15.292 happens? So what what we needed to do is understand the mapping. So I’ll take a step backwards 00:18:15.292-->00:18:21.917 and I said that IDA crashed, why did IDA crash? We know that this file is in use so it should work 00:18:21.917-->00:18:28.250 but when we dumped um the file headers was using, the file headers we saw that some of this 00:18:28.250-->00:18:35.208 uh some of the segments were missing. We didn’t see the text segment. So um eh what we 00:18:35.208-->00:18:41.250 noticed is it defined in the dynamics section and we had to manually reconstruct the 00:18:41.250-->00:18:48.125 different sections in the file. Um from the info we got from he dynamics section. And then we 00:18:48.125-->00:18:55.458 could eh eh analyze it in IDA. But that wasn’t enough because even uh when we uh. opened the 00:18:55.458-->00:19:01.208 file in IDA uh the entry point was not valid. It didn’t point to anything interesting so uh 00:19:01.208-->00:19:07.542 something else is happening here. So what happens here is there’s a call to an INIT 00:19:07.542-->00:19:17.125 function eh from the dynamic section. What does this INIT function do? So what it does is 00:19:17.125-->00:19:24.042 the native file contains a compressed section of the code. And the INIT uh function 00:19:24.042-->00:19:30.250 decompresses this uh code and overrides the text section. And now the entry point, the 00:19:30.250-->00:19:38.083 original entry point of the ELF is valid. And what we saw is that one of the functions inside 00:19:38.083-->00:19:45.208 the native file is JNI OnLoad. And JNI OnLoad provides the mapping between the functions in 00:19:45.208-->00:19:55.083 the native file to the JNI, the java. So now we can understand what does uh what does the 00:19:55.083-->00:20:04.792 function do. Okay. So, now let’s see how Bangcle works. So um the first function, extract a file 00:20:04.792-->00:20:11.500 from the assets. And the second one, which is the interesting one uh forks three different 00:20:11.500-->00:20:18.625 processes. The first one is just the apps uh process. The second one is an anti debugging process 00:20:18.625-->00:20:25.583 which does different tricks in order to prevent us to uh understand what’s happening. And 00:20:25.583-->00:20:35.042 um. the fourth third one only executes when the OAT file does not exist. And as we know this 00:20:35.042-->00:20:41.500 mostly is the first time when the dynamic uh DEX when the DEX is loaded. But it doesn’t 00:20:41.500-->00:20:50.833 executes DEX2oat uh in a regular way but it uses a LD preload in order to hook some of the 00:20:50.833-->00:21:00.208 functions in DEX2oat and create a special kind of version of uhh an oat file. This oat file will 00:21:00.208-->00:21:12.500 later be used by RTM when executing the file. I hate windows. Okay, so what does the 00:21:12.500-->00:21:22.750 hooking and uh and uh in Bangcle do? So um on the left so uh it hooks 8 different functions and 00:21:22.750-->00:21:27.625 we have here an example of one of the functioned hooks and the way it hooks them. So we can see 00:21:27.625-->00:21:33.917 it on the left uh an open app fun..function uh without any hooking. And on the right we can 00:21:33.917-->00:21:42.458 see uhh.. the uhhh the hooked version and we can see that the first bytes were over read and 00:21:42.458-->00:21:48.167 um the what it does it changes the PC register in order to change the flow of execution to 00:21:48.167-->00:22:00.958 the pack unpacking process of the app. So let’s do a recap of Bangcle and how it works. So it 00:22:00.958-->00:22:07.458 creates a stop.. a packer loader as a Java activity to load the native library. The native 00:22:07.458-->00:22:13.292 library is protected with different anti uh research techniques that we have to 00:22:13.292-->00:22:23.500 bypass and what it does it hooks libc and uh for um for the unpacking process and what it 00:22:23.500-->00:22:31.875 does is when a libART encounters the OAT file it will unpack it and provide an unpacked version 00:22:31.875-->00:22:41.792 to the libART VM. So we understand how Bangcle works. Let’s look at Baidu. So again 00:22:41.792-->00:22:47.208 for classification this is pretty straight forwarded, we can see that if we have a stub 00:22:47.208-->00:22:53.125 application and the stub provider and again a native lib and uh the packed original DEX. 00:22:53.125-->00:23:08.875 And again the same we couldn’t see um the mapping between the native functions used in uh in 00:23:08.875-->00:23:20.542 the loader to uh to the functions in the native lib and uh you can see that uh that um 00:23:20.542-->00:23:29.208 again uh by the used the INEX section in order to decompress some of the code. Because again 00:23:29.208-->00:23:34.292 we couldn’t see it in IDA and only after the decompression we could understand whats happening 00:23:34.292-->00:23:44.500 inside the file. And uh again it’s using the JNL OnLoad function to provide uh to 00:23:44.500-->00:23:51.000 provide the mapping and do some uh other interesting stuff. And these are the things it does. So 00:23:51.000-->00:23:56.417 it has an anti-debugging technique that I will, I will elaborate. And uh registration 00:23:56.417-->00:24:03.458 of the native methods meaning the mapping between the JNI and the native functions. And it 00:24:03.458-->00:24:11.500 extracts the packed DEX from the assets and creates an empty DEX file, not an OAT file but a DEX 00:24:11.500-->00:24:20.458 file.And provide the hooking. So what are the anti-debugging techniques used in Baidu so we 00:24:20.458-->00:24:27.167 have obfuscation, uh log disabling, uh it checks that gdb isn’t executed and JDWP isn’t 00:24:27.167-->00:24:38.792 executed and a few uh more other anti-debugging techniques. And we can see that the hooking and 00:24:38.792-->00:24:44.958 libART in Baidu is a bit different. It hooks the Android log print function in order to 00:24:44.958-->00:24:50.750 prevent any logging so uh if you try to debug it, you can’t. It will be harder for you to 00:24:50.750-->00:24:59.000 understand what is happening. And uh it hooks the EXECV function. Uh and when DEX2OAT is 00:24:59.000-->00:25:09.417 executed, by Android, it prevents the compilation of uh the DEX file. Meaning the Oat 00:25:09.417-->00:25:15.958 DEX section it will be it won’t be empty but uh Android won’t use it to execute the logic of 00:25:15.958-->00:25:24.000 the app. It will fallback to uh the file encode. And it hooks the function open. Meaning with 00:25:24.000-->00:25:33.667 Android tries to look for the one dot jar file instead it will decrypt the uh packed uh DEX 00:25:33.667-->00:25:45.583 file and supply it to libART VM. So again, let’s see what Baidu does. So it creates a stub in 00:25:45.583-->00:25:52.500 the Java activity. It uh The native lib is protected with different anti research 00:25:52.500-->00:26:03.625 techniques. And it hooks libART for handling, opening of the DEX file. Well this looks familiar. 00:26:03.625-->00:26:09.458 But this is a different packer or almost a different packer. So uh what’s.. what can we 00:26:09.458-->00:26:17.458 understand from here. That most of the pack.. unpacking process might be generic with a few 00:26:17.458-->00:26:25.917 minor changes. We can see that the trigger for the decryption by the different packers is uh 00:26:25.917-->00:26:35.292 when the..when libC opens the file. And in Bangcle it’s when it’s opening classes an OAT 00:26:35.292-->00:26:46.792 file. In Baidu it’s when it’s opening the DEX file. And if a hook plays hooks in the first 00:26:46.792-->00:26:54.458 places in uh the libART VM process when uh it tried to open a OAT file and a DEX file. And 00:26:54.458-->00:27:00.500 dumped the files, we should have the decrypted version, the unpacked version of the DEX 00:27:00.500-->00:27:13.625 file. So that’s exactly what we did. We understood the way an app is loaded uh by the artVM 00:27:13.625-->00:27:22.167 and where is the first places we can place a hook uh in the VM uh in the code uh in the flow uh of 00:27:22.167-->00:27:29.083 loading. So we can dump the the files. So one function in the OAT file loading process and in 00:27:29.083-->00:27:37.500 the DEX loading process. And as you can see it’s only a few lines of code. One is three and 00:27:37.500-->00:27:48.167 ones a few more And this allows us to dump the decrypted version of uh packed filesPacked 00:27:48.167-->00:28:03.625 DEX files. So let’s see a demo. Okay. I’ll try to cool. So this is a demo of a tool we created 00:28:03.625-->00:28:12.708 that uh that will can gen.. generate and unpack most of the packers. And what you see now in 00:28:12.708-->00:28:22.458 the in the background we open now an app which is packed and you can see by Bangcle and you 00:28:22.458-->00:28:26.375 can see the DEX file, the packed DEX file. Which you can’t really understand what’s happening here 00:28:26.375-->00:28:36.083 because it’s packed. Now we execute our app. And uh it’s our tool which is uh uh a forked 00:28:36.083-->00:28:44.042 version of the AL spawn of Android. And I’ll try to fast forward this and unfortunately I 00:28:44.042-->00:28:51.958 can’t so we’ll have to wait. So what’s happening here is Android emulator is loading and once 00:28:51.958-->00:29:00.333 it’s loaded we will uh load the app and our hooks our two different hooks will dump two 00:29:00.333-->00:29:06.750 versions of the DEX file. One should be valid and one should be not. It depends how the 00:29:06.750-->00:29:13.500 packer works. Some the packer hooks in both places some of them hooks only one of the 00:29:13.500-->00:29:23.083 loading uh in one of the loading uh flows. But this enables us to unpack the apps. So um well this 00:29:23.083-->00:29:33.917 will take a few more seconds. Um sorry. Okay. So how are you guys today. [Audience Repsonds] Um 00:29:33.917-->00:29:41.417 what I can mention is the hooking used by the packers is not persistent they placed the 00:29:41.417-->00:29:50.458 hooks during the loading process and then they remove it. It’s it’s. it’s a good uh it was we 00:29:50.458-->00:30:00.208 had to really understand when the hooks are placed so we could decrypt uh dump the DEX file in 00:30:00.208-->00:30:06.792 the right time. Because trying to connect uh later on uh with GDB and dump the memory or 00:30:06.792-->00:30:13.750 execute or just dump it in uh afterwards after the app is already uh executed won’t always 00:30:13.750-->00:30:21.083 work. So it was crucial for us to understand the DEX loading process. And um.. wow Android is 00:30:21.083-->00:30:33.958 so slow. [Laughs] Oh man. [Audience laughs] [Laughs] [Clapping] Okay you’ll believe 00:30:33.958-->00:30:41.000 believe it it works but you don’t need to believe me. You can download the tool.. uh for 00:30:41.000-->00:30:50.292 yourself from our repository and uh it’s it’s it’s not a compiled version of Android but a patch 00:30:50.292-->00:30:56.667 that you can apply and the script that wraps the unpacking process. And you can go over 00:30:56.667-->00:31:07.042 them, uh execute them and see that it works and uh uh enjoy. So uh sorry, so we understood 00:31:07.042-->00:31:15.500 how the packing process works by different packer and we only introduce a few changes over the 00:31:15.500-->00:31:20.042 ART VM. And this enabled us to work with like 90 percent of the packers we encountered in the 00:31:20.042-->00:31:29.667 systems. And what was very interesting we quit this uh change allowed us to uh to send 00:31:29.667-->00:31:36.250 an unpacked of the DEX files to our static code analysis systems and we got a 50 percent increase 00:31:36.250-->00:31:42.917 and detection of malciusouness of packed apps from this uh from this feature. Which is uh was 00:31:42.917-->00:31:50.292 very good for us. [Applause] Thank you thank you, you’re far too kind. [Applause] And uh 00:31:50.292-->00:00:00.000 that’s it um if you have any questions um feel free to ask. [Applause]