>> 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]