>> Hi everyone, thank you for coming out.  Welcome to   Android Hacker Protection Level 0, and as of 24 hours ago, some black phone stuff that we're going to demo that this guy had lots of fun with. So just a quick who are we, this guy is Jay Case, I am Diff.  This is proof we are not the same person.  Many people thought that for many years that we are the same exact person.  He's CTO of Applied Cybersecurity, he's basically an expert troll, finds lots of stuff and has the biggest mouth in android is basically what we're saying. There's github, that's his Twitter, I think he beat Dan Rosenberg, so keep following him.
>> I am an Obfuscation Junkie, I work at Look Out Mobile Security, I do research and response. I pretend to know as much as this guy. That's also my github.
>> Why are we here?  If you Google around and look for android protection, a lot of people are Googling, how I protect my game, I don't want to be hacked, I don't want Malware injected into this. I don't understand this stuff.  All obfuscators are not created equal.  Well if you look at stuff, people are like, well what's a hacker protection factor?  That's just a marketing term somebody made up.  His obfuscator had a hacker protection level of 35, awesome.  35 levels of protection, that means nothing.
>> We wanted to demystify, obfuscation is not that magical.  You have to identify what's going on, is it a known packer, obfuscator, protector, what will you be able to do?  Also we wanted to be able to look at this. At Look Out, we do anti‑  malware and what you see a lot in the news is people say "the most sophisticated thing in the world just came out." They used a commercial packer and they didn't even actually notice that that was a commercial packer and they didn't actually do anything that sophisticated. But they bought a product that did it form them. They are really bad attackers, and they are not.  You have to just realize what you are dealing with, we wanted to take a look at that.
>> This is mainly for educational purposes, good people use these and we are not suggesting you go out and crack all the games that are doing this stuff   but bad developers use these tools as well to inhibit people like us trying to analyze malware and see like are people using exploits, are they stealing your contacts, what is going on? So it is very educational to be able to know how these type of systems work and how to pull them apart.
>> So what's out there? About two years ago I gave a talk, it was Dex Education 101, the slides are still online from BlackHat 201. There's a lot of proof of concepts out there, and a lot of anti‑  decompilation tricks, anti-analysis tricks, we just demoed one of the preliminary Dalvik unpackers.  Pretty cool.  A lot of people start integrating these into little one‑  off tools that will brick bahksmali, dex2jar, and IDA Pro. So it's really great.  Since we have tried to find a lot of these things to break all the tools, we got a lot of patches submitted, a lot of open‑  source tools and tools you can find online are already patched and you can't actually break them as easily anymore.  Now that these tools have caught up people are starting to use packer and protectors.  I will explain that.  It makes it so you can't do static analysis.  You have to do run‑  time analysis or go through hoops to unpack some code.  But the current tools will stand up against the tiny tricks we demoed in the past.
>> What are packer and protectors?  Hopefully you know a little about obfuscators, going to take what you write as a developer, get obfuscated, look a little different and hopefully be harder for someone to reverse your compiled code back to what you started with.  This is an example, basically, this is an optimizer/obfuscator. It's really good, everyone… you know, Google says you should be running this, like Pro guard and  look into more obfuscation. Essentially, the code on top is what you would be writing yourself. So basically its a reflection statement doing a system exit and on the bottom, that's actually when obfuscator will try to turn that into, as you can see it doesn't look that nice to look at.  We can see function calls with really funky names, special characters for the actual… so you get the class name, looks like con, and you get the special character for actual function, passing other things, calling an encryption method to decrypt, excuse me, its a decryption method to decrypt what the actual string is supposed to be.  You can't see Java link system anymore because they encrypted that and pulled it out. So if you were just running strings on the file, you won't see these type of calls.  You will have to go in, decrypt manually.
>> Protectors, this is what we dubbed. It's similar to a packer, but you will have your stub application.  That's what the protector is actually injecting.  They break your code so when someone is statically analyzing your application it just looks like it's all broken, all the tools will skip over this is bad I will insert an Opp. This is an invalid call, not going decompile that. They just don't understand what's going.  You run this on your phone, the stub application will fix the broken code in memory.  When the actual application hit that's code we originally thought was broken, and didn't analyze, it will be able to run fine.  It's protecting your application from static analysis but supposedly works on the actual system.
>> This is for normal packer, like the scheme of UPX or other X86 packers, sub application and that is wrapping the hidden and sometimes encrypted code.  Once it's executed the stub application launches, will unpack, decrypt, put into memory the actual executable code you want and proxies everything so when the system says this is what the user is sending to your activity, it just proxies the actual code, which is normally hidden from that static analysis.
>> I will throw it over to my buddy, JCase, for optimizers and obfuscators.
He is not actually throwing anything by the way.  
>> Yesterday I was supposed to do all these slides for this yesterday but instead of doing that, I bought a black phone which took up yesterday.  Optimizers and obfuscators.  Proguard is pretty much what I am going to talk about first, de facto standard for Android.  After I did a write up on breaking their licensing system, Google packed it in their SDK. So most Android Apps use it.  It's about eight years older than android, created by Eric la Forte, especially designed for Java, recommended by Google, optimizes code, shrinks code, obfuscates code.  Cool part is it's free, will reduce the size of the app, you can get more app on the phone.  Does a pretty good job of making things faster, removes a lot of garbage code, if you write bad code it kind of looks better when you reverse it. Yeah, it removes unnecessary, unused code, merges identical code blocks and, and Peep hole optimizations,  removes debug information which makes it easier to understand what you are reversing.  Can rename objects, mildly annoying, and restructures code.  On the slide here on the left‑  hand side is application that has not been protected with an obfuscator at all. It's actually and Android exploit i wrote. You see the PayPal SDK which has been obfuscated.  On the right‑  hand side is the same APK, same exploit with Proguard and primary difference here is classes are renamed and instead of saying hey this is a utilities class you have E. This is a Proguard,  I am removing some of the debug information, like the source name, source file.  Typically when you compile classes the source will tell you the file name that it originally came from.  A lot of obfuscators will completely remove it or insert false data.
>> The false data ones can be pretty annoying, but otherwise pretty simple.  Another thing that Pro guard, most obfuscators do is remove line numbers, your stack traces will be rather confusing, reduces the size of the decks, but not too big of a deal. Pro guards data is pretty easy.
>> Here's an example of a method that will actually give shell commands, on left‑  hand side we have the original source and right‑  hand side the decompiled Proguard protected output.
>> As you see, it's pretty easy to understand if you understand Java, it's not too strange.
>> Proguard, what's it good for, pretty much nothing except making the app smaller, faster.  Doesn't provide obfuscation, anybody who recommends it for obfuscation, is a little bit out there.  I have heard over and over, app developers say well I am protecting my app with this, it does nothing to stop reverse engineering. It has a Hacker Protection Factor of zero.
>> This I would like to talk about, favorite subject of mine. Dexguard is a commercial version of Proguard by the same author, pretty standard, but incredibly scary looking for somebody that doesn't know better. It optimizes shrinks, and does a pretty decent job of obfuscating and encrypting but not going to stop reverse engineering, somebody with a background at all.
>> It does pretty much everything Proguard does, adds automatic reflection, will take your standard API calls. And by reflection, this can screw with automatic analysis, make it a headache to look at, makes your app quite a bit slower.
>> It does streaming encryption, makes the app confusing, scary if you don't know what you are looking at, and slows that down.  Can provide access, embedded asset files for the app or does library encryption. Pretty simple, slows the app down, especially in the case of library which doesn't do anything, because they has beyond this which is  encrypted. Once they're on a disk we just pull them anyways. Class encryption, taking the original class file, encrypting, put inside the decks, and it does tamper detection as well, which I will not cover much because if you are looking at malware we don't really   care too much about tamper detection. 
>> Here's an example of the reflection and stream encryption, the top field will have the standard API   call system to exit.  The middle field is the same call but using reflection so its a little bit more confusing, a little bit larger, so your deck file size increases and the bottom is the reflection and a stream encryption which provides no hint to actually what it's doing.
>> Here's an example of the streaming encryption, the top tool shows an android 2.3 exploit that would  cause a device to reboot from no permissions.  The middle field shows how the dexguard or streams are encrypted… all the streams in the class file are stuck in a byte ray after being encrypted. The bottom field is the exploit to reboot the system with the streams encrypted.
>> So here's a decryption method on the left‑  hand side, original one and right‑  hand side the obfuscated one.  Pretty simple.  XML encryption, but I know how code works.  You delete the character and position and will decrypt the string… in the right field, byte ray… I am a little nervous, I have never spoken at one of these, so excuse me.  The asset library encryption is pretty simple too.  It's AES and the key and IB are in pretty much plain text right in front of you. Extracted and encrypted asset decrypted, writes a disk or do whatever you want with it. Pretty simple, just a few seconds to undo.  Class Encryption is pretty much the same thing. It packs the original class in a zip file, encrypts it, stores it in the main class, uses AES. It will store… you will have three large byte rays… I didn't have enough room for more Google slides plus I was hacking the black phone. It'll have three large byte rays and two small ones. The two small are IV and key and the first large is all the streams which we really don't care about.  The second is a class and third is a class.  Second is decrypted using reflection to run it. When they run it it will provide a new key and a new IV. They they decrypt the third one.  Automatic unpackers will do this in a matter of seconds, provides no real protection but will scare most, average pirates away.
>> This is actually how I was decrypting them.  He will append the strain to the head of the zip file so  after you decrypt it you will need to find the header, and then you can write the disk.  I have an automatic unpacker that will be on my github. It's currently broken with Java 8, I decided to work with the black phone instead of fix it.
>> Dexguard, I like it, I bought it, after seeing Russian malware with it, I emailed the author, he said reverse it, I said I already reversed it, here's the samples of the malware, I would like to buy it I want to use it in my product.  I bought it for some ridiculous amount of money, I ended up releasing an app connected with it and the source to it, he was kind of a little bit of a jerk, canceled my license for a few months.  Thought I was helping the hacking community by releasing the source to an app that had been obfuscated with it.  I won't recommended buying it if you plan doing an app, but you just want to protect your average application, it's pretty good, it will annoy most people.
>> It has some down sides and some ups.  May increase the dex file size, string encryption, reflection, makes the dex file bigger, slower, takes up more space on your phone.  Especially the reflection string encryption will slow down the application if you use it too much, so if you're going to use it, use it just on the important parts.  Don't go obfuscating the open‑  source library that ridiculous, but a lot of developers do.
>> Removes debug information, automatic string encryption which is a pretty decent automatic class access… library asset encryption.  Pretty much the best and most annoying feature, automatic reflection, pretty scary once they do the reflection the stream encryption you can't look and see what it's doing.
>> Moderately priced as far as obfuscators go but pretty expensive still.  Easy to use, you reverse by hand within a few hours, automatic unpacking in a matter of seconds.  While the author gives a hacker protection of 35, we're going to give it a one today.  [Laughter]
He might actually punch me if he ever sees me.  
>> Allatori isn't as good as Dexguard. I like it a lot better. I emailed the authors, they gave me a free license which was really cool. If you have a .edu email and have an academic purpose they will kick you one, originally designed for plain Java but works fine in Android Java. It's an obfuscator, water marker, it's priced in the lower end of 290.  Free academic license if you have an "edu" e‑  mail address, hit them up.  It doesn't do as much as Dexguard, but it does name obfuscation by changing the class names, controls flow obfuscation, debugging obfuscation and string encryption.
>> Here's another part from one of my exploits.  You see I am checking to see if  the file exists. If it exists, I do something. The bottom field is the same as the first, but now with the string encryption.  On the left‑  hand side is the standard Allatori string encryption, it's pretty simple.  The bottom part is the obfuscated, run the stream through and you get your original string. Again, quite simple like most obfuscates are.
>> Free for educational use, tends to increase the dex file size more than Dexguard because Dexguard inserts all the extras. Also  increase the app speed   a bit unless you're using heavy encryption, just like Proguard, Dexguard, removes bug information and doesn't do much in the way of obfuscation.  The authors are pretty cool especially giving a reverse engineer a free license.  Easier, give a .5 on the   Hacker Protection Factor but again, I support them.
>> Thank you for listening.
>> Thank you.
>>
[Applause]
 
>> I see a couple of people taking pictures.  It's small up there, but we will release the slides, you don't need to take pictures feel free to keep doing it if you want though.
>> On to Protectors.  This is really fun.  You may have run across it if you are looking for malware or just happen to love looking at Chinese applications, they love this one.  Chinese protector, made in China, obviously, multiple iterations of it, you may know it as APKProtect, but maybe you know it as or have seen it as APKProtect, Lite, PC, Advanced there's probably like retro in there. There's also DexCrypt for awhile, where it was just a script and he was letting people download it.  It appears to be active, but hard to tell who is using it.  The site is now nonfunctional.  There are Chinese clones now with similar techniques and websites almost identical.  It's hard to tell who is doing what.
>> The cost seems to be free, but also really expensive, but again, you can't go order it anymore, just goes to a PHP crash site but you can try, maybe drop the source or do something like that.  It's very similar to a packer, I gave that little demo where it's a sub application with a mangled code inside.  But unlike the…  the packer does not do mangled code where this protector does.  There are bug detectors, they have bugs in and anti‑  decompiling which is the main code.  You can't just run statically on that file.  This essentially looks like, it the top right corner, that is what it is going to look like if you're just going to try statically and you don't understand what's going on, you will see, Bahksmali, actually does decompile it or disassemble but you will see lots of things like oh I don't know where this is going, this is a really high number, doesn't make sense, just drop it in the comments, and they give you an Op statement. On the bottom right hand corner we see the Dalvik stub code.  Essentially this is the first line of code that the application is going to hit when it runs.  This is what they are injecting into your application.  We see end road manifest on the left, there's a package name,  a piece of malware, you see package name absolute garbage like that, pretty much will be malware and sends us a mess. Surprising.  They injected APK main app one, one, one, one, seven, seven. That's what will get hit first, when a user executes or it's going to be run.  What happens, it goes over to that loader stub, that loader stub will actually, it's loading a shared library, some native code over JNI and the actual part that will do the anti‑  emulation check, anti‑  debugging and fixes the broken stuff in memory.
>> I wrote some sudo code, hopefully you can read this and it's legible. Essentially what's going on here is the Dalvik, it's actual run time on the phone, when you install, it will optimize, it's called an O dex file. It takes that file and optimizes it. That's where you get an O dec from. It basically sees the bad parts, goes I don't care about these, skip it, leave it in memory and deal with it later.  Doesn't look like it's being run.  Upon actual execution, the stub loads, and it calls that a JNI on load function there.  Looking through, there's anti‑  debug call attached to itself to try and P-trace itself. This is an attempt to basically say if I am P‑  tracing myself then nobody else is in theory, is supposed to be able to P-trace me, that's easy to get around.  That's anti- debug number 1, trying to find its own O dex file, this is basically incase a reverser has wrapped the application and changed things around. They won't be able to find their own O dex so that's an anti‑  analysis thread trick.  If they detect you are doing this, go into an endless loop, sit there, causing IDA to hang.  What it does next is it looks for the QMUD process. So basically if you are running this inside an emulator, all the emulators are QMUD based, so it's looking for the daemon. And the code on the bottom is actually what it is doing. We released a hack that can hide your emulator, all it is doing is it basically hashes what the prockpid command is. So it looks to see has that system been QMUD'ed? If it sees that in the first, I believe thats going to be 101 processes, it will crash, not going to let you run this on an emulator, that's their anti‑  emulation technique. And it will basically patch O dex inside the memory. And all it's doing is it is basically looking inside its' memory to see where did the actual Dalvik run time unpack this, grab it, do an M protect, so that it can write it, fix that code in memory and then re‑protect the memory.  All we do to attack it is… here's a little… this is what you would see in static analysis and this is what you see after running it.  The easiest way is to do this is just to forget static analysis for a little bit of time and do the hard work. All we need to do is basically let them decrypt in memory, then detach to not the original process, but a cloned process and then we can just dump all of the memory and it's all easy right there.  You avoid all the QME stuff with an LD preload hack. We have that on our github. The clone processes, everyone forgets about those.  There's one process that's protected and there's maybe 20 that aren't.  Let's choose one of the 20 that are not.  There is more actual encryption in the dex file, this appears to be an option so most people only have the mangled code that gets unpacked into the memory, but there is, looks like dex trip style, a modified Base64 encryption and it's using DES as opposed to AES.  Looks like this guy threw this together,and encrypted some strings. Just dumped that from memory, you still need to do more reversing, it's not going to be just a normal… like the virgin code that was used from before being repacked.
>> It's really fun, awesome, really great example of someone trying to think outside the box.  Haven't been many changes in the product, at least in applications I have seen in a while.  There are tons of people using this, if you want to take a stab at looking at your first protector, this is a great one, loader stuff is easy to follow.  They didn't obfuscate the native binaries much.  You won't have to go through hoops of rebuilding import tables or any of that stuff.  There's logging statements they left in.  You will be able to go through and see stuff.  It's really great for beginners to try to get their heads wrapped around.
>> The interesting part about protectors and packers, they are hard once, once you figure out what they are doing you can ignore them the rest of your life.  You never have to look at this guy once you have done it once, unpack from memory, you are good.  Obfuscators tend to, their encryptions get munched a bit, start changing, each developer has a little different build, they all look a little different.  This is pretty much cookie‑  cutter for every single application that you find.  I gave it a hacker protection of 3.  Technically no public documentation on how to unpack this, until today I guess, so that's good.  Maybe it goes down to 1 now, I am not sure.  It's fun to look at, does a pretty good job and works pretty well for commercial product apparently.
>> Moving to packers, I love beating up on this one.  The guy's a nice guy, left a couple functions in there for me,  he actually has one that says, "Hi, Tim," because I always reverse , then tweet about it and give him crap about it.  It's really easy to hack this HoseDex2Jar. Excellent, we needed this.
[Laughter]
>>That's what I like to hear.
>> I will take a little break I guess.
>> I disagree that I need this. I am quiet good, from the fun from yesterday.
>> This will help.
>> Everybody loves Jack.
[Laughter]  
>>You can keep going.
>>Okay, this was a proof of concept.  I believe he's a  security…
>>Okay, stop.
>> Okay.
[Laughter]   
>> You know, out of all the rooms, this one is always the best at showing the love. So… 
[Applause ]
>> Thank you, guys.  You can just leave the bottle.
>> Nice try, I thought about that for a second.
>> Okay you guys are nice, but yeah thanks. So this guy was a security consultant and I believe was just doing this as a pitch to say look, I broke all these decompilers and you should maybe hire me or something.  I am not sure, it was really not pushed as a good commercial tool and really doesn't work that well.  It's a great proof of concept, though.  It uses the exact same "Dexception" attack that I outlined in the dex education 101. Cost was free but it appears to be offline now, they took down the site.  Just as an outline of how this would work, writing code, normal stuff, package up you APK,  go to their cloud service and their close service just bundles it and passes it back to you, you need to re‑sign, having the stub application.  The only little trick this is doing is actually stuffing it inside the dex header, the actual thing I demoed at BlackHat. So if we go over it. Detecting this was really easy. This is an ONL editor , with a colorized dex template, going down with it, this is like my favorite tool in the world for forensic stuff on Dex. But it makes its really easy.  You see red sections, and it says wow, something is wrong here. Clearly it looks like something is encrypted right after that header file. If you've ever looked at a dex file, it just doesn't look normal and the red should highlight that.
>> You can see the header size, normally 70 hex bytes is huge.  So clearly something has been injected.  Easy to see.
>> All this will do is static analysis will not really work because you will see this encrypted file, just run the tool against it, it ignores the encrypted file, throws it away, you can see in the loader stub so you'll see two classes in there.  What happens in memory, goes to optimized dex file, has the encrypted file, the interesting and secure thing this guy does, decrypts in memory and drops  on the file system unencrypted, so yeah, just grab it after it runs if you want.  That's your unpacker.
>> As a joke, this whole thing was supposed to be HoseDex2Jar. We wrote a tool where we used Dext2Jar on loader stub and wrote Java around it to use his own code to decrypt his code, like a nice jab back at him and I haven't seen the next iteration of his tool but it's always good to throw things back and forth at each other.
>> That one is really good, simple.  If you have never written a packer, don't understand what a packer is, you can go check this one out, it's a good one to look at. It's easy to reverse, it has been documented on twitter by us and a couple other people who want to troll him more.  It's easy to automate and unpack.  I've only seen it once in the wild, looked like someone was just testing, wrapping a piece of malware, and uploading it to virus total and everyone detected it anyway, so nobody cared.
>> Moving on, we see Pangxie, which is a Chinese packer. This one is kind of interesting, has fatal flaws, and doesn't appear to be active anymore.  There are quite a few samples in the wild but don't seem to be using it anymore.  The author got bored or maybe someone stole his code or something, it follows patterns in Chinese packers. Again, this one just doesn't appear to be used anymore.  Has anti‑  debug, anti‑  tamper, and looks like it has other functionality they just forgot to turn on and maybe stopped development of this.  It's interesting, though.
>> The cost, not sure, I can't find a website, my Chinese is not that great.  If you see one, let me know, maybe nobody else can find the website and that's why no one is using it.  All the normal part where they are basically giving you a stub application that has encrypted dex file.  I am not sure if you are uploading to a cloud service, because again I can't find their site for any of this stuff.
>> How this is working is relatively simple, on the first execution it goes into, says hey, is this my first time?  Let's go to the JNI, verifies integrity of the encrypted package.  When reversing you might get scared, oh my gosh, its using AES, it has encryption, but it's not actually doing anything with that.  Just checking a hash. Then goes to checking the decryption of dex file, relatively rudimentary, simple, on the next slide we will see why.  After it's done this once it keeps this in memory and… or no, excuse me, this one drops on to the file system, you can grab it there and on the second execution, it has already unpacked it, it's on the disk, loading directly, and just proxies everything over, using the  dex class loader. Which if you are familiar with Java, it's the same with the Java class load.  AES is used but only for the digest.  Here's the basic stub decryption.  You see there's only one byte per key and some magic going on, and that's your fancy decryption.  Just X-or everything, pretty easy to write a static unpacker for this one, you don't actually ever have to run it on a device, but if you were to run it on a device, you can actually see they are basically dumping out to data data package name app dex folder. That's going to have the folder with the encrypted and the decrypted copy.  You can grab that, and here's an example of seeing that run.  You see it, gets the updex and you have the classes that jar, and the dex file.  No work really needed, I guess.
>> This one is interesting.  Slightly increased, use the stub encrypting, works on almost all versions, I guess it stopped working, I was testing on 4.4, it appears to crash. It appeared to be not actively maintained, probably never going back.  Interesting thing with this, since it's such a simple packer you could likely just take it and hack your own things in, you don't actually need their tool since you know what they are doing for encryption/decryption, you could actually just change the keys just by patching it. Change that Xor key, push your own encrypted payload and without a source code you could start making your own knock‑off Pangxie packer. That would be a fun project to do.
>> I gave this one a 1.5 on the Hacker Protection Factor because it was interesting, but I wish they didn't just dump it on to the file system, kind of boring, but it was a little more difficult than HoseDex2Jar.
>> This is one a lot of people talk about online, a lot of people want to say, they post it everywhere, saying we've unpacked this. That's awesome.  Now go away, we will never tell you how to do it.  That's why, this is actually one of the inspirations for the talk, and another part of that inspiration was that they have a cloud service and are very adamant about saying "we never let any bad people use our packer." We will never pack anything bad, no malware will come through and we do our manual app with Google. That's great, but we found plenty of malware using this. But   they are doing a good job, not tons, but there's  definitely malware getting through. As we gave an example before, once you understand, you can inject your own application.  I am not saying I have seen people do that but could easily be done by some of these guys if they wanted to.  You can skip the cloud service check if you want to.  This is an interesting nuance of where we are today in the industry, where people used to download UPX and you can pack anything you want.  Now people say give it to me, I will check it out, send it back to you, using the cloud service to, via gateway, not let bad people use it, but bad people are using it.
>> The cost on this is pretty phenomenal.  I have heard higher estimates, but I personally saw some of the numbers are around $10,000 for this packer.  That's pretty beefy.  It stopped working on 4.4, but for $10,000 I assume they will release an update soon.  This one has anti‑debugging, anti-tamper, anti-decompilation and anti-runtime injection.  This is fun, harder than the others.  They hooked every single memory object they used, use to re‑  open and rebuild their own import table, they have encrypted all their own function names.  It's fun to go through.  I don't have enough time to go through every step, but basically on the first execution in Dalvik, it hits the loader stub that goes into a JNI   anti-debug launch, essentially this is what is checking to see am I being debugged? No. Alright, I will start working in two more process and P traces those two processes.  These are three processes running, talking to each other over P trace.  Won't be able to block their calls to that, won't be able to read their data,. It gets kind of annoying because they pass information back and forth the entire time.
>> One of those forked applications is what ends of decrypting the dex in memory so we're just going to let them do that and grab out of memory, we don't care what they are doing.  This is an example, as you launch the malware, you see three processes start up.  Normally you attach to the first but you can't because they are all talking to each other and they are all attached to each other. Which is a  nice anti‑debug trick. Though again all those cloned processes at the bottom, basically looking at the original process saying what are your tasks?  Cloned processes, like Linux.  What we will be able to do, say all right, the top three are attached, but none of the bottom are, so attach to those, but basically if you were to do a couple of core dumps, look for optimized dex file in the memory, save you time.  See the encrypted stuff in memory, the dot cache, classes by jar, classes of dex, still encrypted, but right below, every single time is where they are decrypted.  No indication, but the tool we wrote will start sniffing the memory it says, is this APK protect or this guy going to be bangle? It sees bangle, which is going to go into memory, and grab it out. And sine you control the device, encrypts out, O dex file, you  will be able to de-O dex it with bahksmali. The instructions are on the bahksmali website, sounds like I am speaking Swedish, is it Swedish?  Norwegian. Something like that.   Icelandic.  Thanks, Rob.
>> If I am speaking a different language, it's all documented online, and the tool we will release a script does this, really slow, a bad script and we rewrote it in C and it's lots of comments, DEF CON 101, so hopefully you guys can create some unpackers. I really like bangle, its awesome. It's probably going to be the most advanced one you see out there. There are a couple more packers emerging, you will see more. Lots of Chinese ones seem to be knocking each other off using the same string. Either someone compromised someone's code or someone sold it to everyone at wholesale but this is really fun and they actively develop it with that huge price tag they will keep on and once they see this talk they will maybe move that around in memory, do more trick and we will get to chase them again.  But they did a really good job, no actual tool you can download, you have to use the cloud service.  I am giving a hacker protection of 5, the best tool out there although I am not suggesting you use it for these applications because you will have the lag time of needing to update, go through them, they go through an approval process, I wouldn't really recommend using these tools.  Probably dex guard, maybe Allatori is what he was recommending.
>> Now what?
>> Quick thing on all of this. We have initialized that and put repo up there, I will push this once I get to the airport and on a more secure network maybe.  All the code is ready, so leave it unpacked, Bangle, APKProtect, these are really easy.  We want to make it more accessible for people.  There's going to be the samples of the malware that use these protectors, I will shoot them to Milla, upload the resource notes of when reversing this stuff and that unpacker code.  I put a lot of comments in there I normally wouldn't, just to explain the thought process, why are we doing this way.  Should get you there.
>> Moving on to the Black Phone, while you are all here.
>> Let's explain why I am incredibly hung over right now.  Yesterday I got paid for leading training, they had Black Phones for sale so we bought it.  I like rooted phones. We used three stages of exploit. I'm going to talk a little fast because we're running out of time. The export does require user interaction if you are writing about it. User interaction not remotely exploitable. User interaction required.
>> One of the first things they did, I ran into, disabled ADB debugging, means we can't get a shell or get debug apps on it. They turned it off by removing the button that lets you open the developer menu.  This took about 30 seconds to figure out a way around.  We fired off an intent to pop open the menu, upload the server, download, run apps, bypass their little trick.  They claimed it was because ADD crashed the phone, it worked fine for me. I can't get it to crash.
>> Encrypt your phone and try to run it, you'll be very unhappy.
>> Okay, thank you.  The second one is escalation beyond system.  They seem to have left a highly privileged application debuggable, you can't use run ads, but we can attach to it with debugger, execute whatever we want as the system user.  System user, pretty privileged, your hacks service is huge once you use it, if you have a system user you are going to ruin your phone.  Jay Freeman wrote how to use this, we found the application, took five minutes.  Followed his instruction and had a system user, really simple, basic CTS, Google's compatibility tests. This is a huge hit, they should have caught this. They didn't bother to run basic tests on this device, which is scary.  Google would never approve this device if they had Google apps on it.
>> The third stage. There are so many system to root exploits and vulnerabilities out there I won't actually disclose this one but the first two things, you already know how to do this too so we're going to keep it.
>> Stage one, fill the app with the code in the earlier slide; stage… Enable ADB, stage 2, 
>> It should work.
>> It's not playing. Stage 2 get the system user ID execution. Stage 3 root, and it's not playing the video.
>>It's playing.
>> Is it? Awesome, because we can't see it.  You can see me, I'm not being able to enable USB debugging, annoying, then you see me getting around that with my little tiny hack as an app.
>> Now you can see the root shell. I actually ran the other exploits. Again not remotely doable, user intention, if indeed they removed this because it crashes the phone and the product shouldn't have shipped. Total time to think of this was about five minutes.  Actually takes a little longer because we we were laughing.
[Laughter]
[Applause]
>> I will have more detailed instructions when I get home and the app source will be up on github as well.  So hopefully I will get it all fixed.
>> The second vulnerable was the action fix update.  I wasn't aware of this, and the phone they sold me did not have the update.  The second one is actually fixed so if you want to root the phone do it before you update.
>> I think we are out of time but you guys can come up here if you have questions, thank you for coming.
[Applause]