Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/142 Thanks!
So this topic will be held by Colin.
He is a researcher at
Systems Security at
the North Eastern
University.
He has a huge interest in
security in mobile and embedded
application. And as far as I can tell
from the description, you are going to
tell us about a new way to investigate
on Android application
running on the Dalvik virtual machine,
right? Yeah, so thank you for calling.
Yeah, Ben, thank you for the introduction
and good afternoon. Good afternoon,
everybody.
So, yeah, let's
talk will be about dynamic
instrumentation of Dalvik applications
on Android or any other platform
that runs the Dalvik VM.
So a little bit about me.
I'm a post-doc at the Northeastern
University in Boston.
I do, yeah, mobile phone stuff.
A lot of different mobile phone stuff.
As you can see, I'm
also one of the authors of this fine
book, which will hopefully be released
next year in April.
So Android
application security is pretty
interesting for various reasons.
Maybe you want to find vulnerabilities,
analyze malware,
maybe you just want
to reverse engineer a reverse engineered
application to see what it's doing
and finally want to maybe attack an
application attack the US.
And currently
people were like, just like really
disassembling
Dalvi Core to looking at like the Somalia
output or running an application
and emulator or sandbox and look at all
traces of execution traces or network
traces, or maybe
do some static instrumentation, so adding
some code on application.
But this talk is really about dynamic
instrumentation. So at the runtime,
like during runtime, and
we're not going to really look at
bytecode, so you don't need to worry that
you have to like know about Dalvik
bytecode or anything.
It's a much cleaner, easier way to do
instrumentation.
Of course, I was not the only one who is
like investigating that.
So the Cydia substrate framework
for Android also has the same
capabilities.
But it's really super complex
and parts of the source code as a no and
not available. And also there is the
exposed framework, but this is more
like design for doing like or as smart.
And my framework is really small.
It's built for security.
It's really easy to understand and to
use, and it's really designed to
integrate it into your own application.
And of course, it's really going to its
release and full source code.
So right now, people
who are doing static instrumentation, so
they would take an APK
unpackaged, which like
the converting the manifest
file back to plaintext and so on.
Of course, there are nice tools for that.
And then they will. Just like this, you
would look at the disassembly of the text
files and then you would add, modify
or add your own code to the Somali code
and then repackage, compile, sign.
And then you would install and run it.
And then you would hope it would work
because maybe your patch code has some
bugs or there are some tiny self
integrity check.
And then maybe you have to like, repeat
and repeat this process in order to do
some instrumentation.
That's what people are using used to do.
So what is the dynamic instrumentation,
so it's really about changing and
modifying applications during runtime?
You can.
It's basically a technique that allows
you to remove to add and remove
code and hooks on the fly.
This is a dynamic.
Instrumentation has been around for a
number of years, but this
talk is really about solving
instrumentation, and you can do like
very simple instrumentation.
You just like library calls
of standard libraries, and then you can
really easily see already what an
application is doing as a system.
Of course, if you want to do application
or target specific instrumentation
still needs to disassemble the target
application to actually find the points
you want to instrument and hook.
But unlike some of the really basic
advantages of doing dynamic
instrumentation on Android for
the main advantage of one of the main
advantages say that you don't need to
unpack, disassemble, modify a
compiler repack.
You don't have to do all this, so you
save a lot of time.
Obviously, you don't need to modify the
target APK so that really
simple integrity checks
are still
still working. Or if you have maybe an
application that assign
higher privileges like
the platform's signature, you
cannot like repackage that without
modifying or killing that signature.
But the thing is, of course, Android
applications are written in Java and
they're run a virtual machine.
So instrumentation is a little bit
different than an instrument like a
native binary code.
Just a quick overview.
So this is this Android
platform picture, which everybody loves
and hates, and we are going to look
at only this part, which basically runs
everything like all the applications
in the UI. You see so small yellow
boxes, the virtual machine and then you
have those qual- over said this is
more or less the interesting thing for
us.
So how does that actually the Android
runtime work and how does an Android
process look like?
Of course, you have the virtual machine
and the libraries
and every application or any system
process on that, and that's
executable code looks like this.
You have a process
that links through like the standard
library, Lipsy
lives that live JPEG and so on.
And of course, the live D.V.M..
That's actually virtual machine.
And then, of course, the process also
contains the Dalvik class
that it wants to execute.
And really every application like if you
install, I know Facebook
or something that basically works
like this. And also the system processes
like zygote or the system server,
which execute the framework they work
in the same way.
So let's start with looking
at the instrumentation.
So the basic idea really of the
instrumentation is we convert
and Dalvik method to a native method
more specific to a Jane eye
to a Java native interface called.
This is how we get control of the
execution.
And from there, we can call different
from once we execute in the G
and I call the call back
to the to the framework
and we can call the original function we
just took so we can just create a really
easy in line hook.
And the nice thing is when
our code executes and Jane I, we're in
the land of sea.
So all the Java protections
like private, protected and so on,
they don't exist for us so we can access
anything in the in that VM,
which is really, really handy if you want
to do instrumentation.
So they give you a
very, very brief overview of
Jane Eye.
You really don't need to understand,
Jane, I want to understand the stock, but
if you want to write your own instruments
later, you have to like, look into a eye.
So it's basically a standardized
interface to call
it native code from Java,
and you can almost write any any code
that you can write in Java in this Jane
eye interface.
But you have to do a lot of work, and
the basic signature of a of a
Jane icon looks like this.
You have a method name, you have a result
and they have the Jane Eye environment
and then you have a bunch of parameters.
And so the Jane Eye interface
provides us with a bunch of
functionalities like Fine Class, which
gives you like a reference to a class if
you can create new objects and so on.
It's it's a really, really simple
interface.
So the actual instrumentation, how does
it work?
And the actual instrumentation is based
on injecting a shared object.
So on Linux.
This is just like a dot s o file
into the into the running process.
And this shared object provides some very
basic native code that
does native code
hooks into the D.V.M.
or talks to the D.V.M..
It resolves a bunch of methods to
like resolve classes,
and it provides the functionality to hook
methods and call original methods.
So this is our basic process
again, but this time we already added our
own code.
So how does the hook to hook actually
work?
First, we need to find the lower
classes or references to lower classes
and methods, and we will
find methods, classes and methods by
just they're fully fully qualified class
name
and the
method by the name and the
method signature.
So this is an example for like accessing
the compare to method in the
string class.
And it takes us an argument, a string
and an integer,
depending on what kind of methods,
what kind of if the best method is
original method or a direct message, you
have to use different chords.
But this is in the library, all
abstracted for you.
And so in the main, the
main idea is your resolve for class
method
change,
some stage change, some of its internal
parameters to convert it back
to or to make it a native
class. And the most important ones are
those who change the
argument to Janee argument and First
Order. The Jane is subsystem
can pass the method arguments.
And the most important one is the
excellence flags.
You just add
one 100,
which defines this method
to be a native method will.
And then you have your your piece of
code, which is a replacement function.
So this is the function to replace the
compare to function.
You see the native, the gene
environment, the reference
to the to the object and
the parametres, the string
object
and
then every call after this.
And then, of course,
the used gene Everage, that's basically
you give it.
So what's this function?
We find the the the method
descriptor versus like returned on this
like metal
variable. And then we just use tells
the D.V.M., Hey,
this method, please use this
native function,
Diavik function hook in this
case to to
execute this compared
to a function very simple.
Yeah, yeah, we need to
modify a few settings of of
this method, and
my most specific is the
the register size
and the argument count.
And depending on what kind of argument
you pass your past to the method,
you have to yeah, f yeah,
give it a I've got a number of
arguments. You want to pass
a register size?
Sorry.
Um yeah, this is pretty well documented
on the VM. And yeah, for example,
this this method takes
it has insides of tool because
it takes one object
as a parameter.
And of course, it's not a static
method. So it has also this
value on or like
an instance instance parameter.
And then once your code executed,
you want to, of course, recall the
original functionality in order to like,
not break break
the application.
Of course, in some cases you might not
want to call the original functionality,
but this part, then we already covered.
And to do this, you
basically have to look up the method and
the class again
can
revert the parameters.
So all the parameters, like the register
size you have to store and then you
reverted and then you just like use
one of the Jane functionalities
in this call method.
Pass the arguments back and you
get the original function to execute
the sounds, of course, like very
complicated and cumbersome.
You don't want to like rides this by hand
for every method.
So I created this like, really nice, easy
to use Loop
Dalvik Hook Library.
And what you basically could do is
say, OK, I want to set up a hook, your
password, the name of the class,
the method name, the method signature,
the size of the registers
and a function pointer, which is
a function. OK?
And then you just call Hook.
And that's it. From then on,
this function will be used whenever
this method in this class is being
executed.
And of course, we also have like a
functionality to
call the
original function.
Some you just have to call the prepare
call useless, call
something method and from the Jane
eye interface.
You get the result and then you just
like, reinstall you, hook.
Since we're doing it in line, hope you
always have to do this. Prepare a call
room post code
structure.
But in the end effect, it will have like
three lines of code every time.
And if it simply just want to unhook
something, you just call the prepared
statement and in the
library. I think there's I put in
a marker, which basically is on the hook.
So very, very easy to use.
OK, but how do we actually install
a hook into the system
or into an application for the site
created? And this hijack tool, which is
basically a part and some enhancements
offer a very simple Linux shared library
injector
and the steps you have to do after you
create your library or your personal
library to a data lock attempt.
If you want to also load additional
DEX classes, which are going to tell you
about in a few minutes, you also have
to change the style of the cache directly
to be world right? Right?
And then you always use the hijack tool
provides a wide of the target process
and the full path to the library.
And then you just run it, and that
injects the library
into the writing process, and it really
works for any Dalvik based process
on an Android system.
So for your normal application, but also
for zygote and system server, so you can
do modifications deep down
in the core framework on on your
running device.
Yeah, so but sometimes you don't you want
to instrument applications very early,
maybe before start up
in order to like see really everything
what the application is doing in in order
to do this. We actually have to
instrument or trace
a zygote.
And we have to do this because
can you actually read that?
Probably not.
Anyway, so zygote just like
the base and process on the system.
So every time, every time you like,
start a new application like hit some
icon on the application launcher,
it's activity manager sends a message
to zygote and zygote like Fox,
a new process and
specializes to that by loading
the specific classes.
And then like, you have a new process
that's like runs your application
and in order to hijack or
inject your own code during
that startup process
instead of tracing or instead
of binding to the idea of the target
process, which doesn't exist at that
time, we just supply the iPad
of Zygote
GIF again, the pass to the library
and add the special.
This string,
which is the the full class name
of the application
that has to like match to the to the app,
to the main to the main activity that
that is launched,
which is very easy. So normally when you
start the process for the first time, you
can just like run apps and then you see
the class name or you have to look in the
manifest file.
And so just
run this command, then you can either
manually press on on the button
to launch a target application and before
the actual application code is executed,
the libraries are injected and into the
process and you
can start instrumenting.
I saw some, some special features
or you also actually saw this, you also
have to add the minus
z switch and then the
SS really the full class name.
If you do stuff on like really all
Android devices, you also have to add the
minus m switch
to blue calling of M
Protect.
And then
you can get some more output from the
high tech tool by just adding more debug
level.
So
let's take a look at the whole actually
the instrumentation and code flow works,
so we have some application
and some method in it.
If we like it,
the application would go down and your
hook will be executed.
And yeah,
your hook might or might not then go down
and call the original function.
And then apparently at some point
return the the
execution back to the main application.
So very, very simple.
And if you just want to like, look at
what an application is doing, you can
build like a very simple proxy,
which is really,
yeah,
take the parameters, maybe
lock them, call the original function
and return.
So.
So is this technique you can already do
with some some light weight monitoring
and reversing, so maybe
have an application where it's just
like somehow obfuscated, maybe there is
like some string encryption or
maybe some reflection to do more
sophistication?
And yeah, so I created
a small, a small tool or a
small demo library, which is called
string monitoring, where just
hook into various string classes
like string buffer to string comparison
functions. Always interesting because
applications might use
this like control flow changing
operations.
That's the interesting points
in the application and of other
like. There are a bunch of string classes
and then of course, like gets method,
which just like used in part of
reflection. So you can see actually
what methods are being used.
Very, very simple demo.
Yeah, I have something later on that,
too.
You can just continue on if you say, Hey,
if you don't call the original code.
You can also do, like do some other
stuff. And one very interesting
thing for me was like, let's just
disable digital signature
verification.
And this is like really used for
all kinds of different things.
And this is like a really, really easy
hack can just take
this Java
signature verify method overwrite
it replaces versus like one line
to a line of C code, which just returns
one.
And if you if you load it into the
application, that application will think
all all, the signature it's
it's going to check are valid.
And yeah, you can.
You can do amazing things already
with that capability.
So these are very like these two things,
very just like either monetary stuff or
like really disabled some checks.
That's like that's only the beginning
if you want to do a more sophisticated
instrumentation stuff, you already, of
course want to like, write more code
and
fighting all this like code or
that interacts with Android application
in the Android framework.
You really want to do that in Java
and
don't want to, like, write everything and
see Gee and I.
So I added small functionality,
which just like loads an additional class
until into the into the
into the process.
And actually, all this functionality
again was available in the D.V.M..
And just like added like some some nice
wrappers around it.
So what you basically can do, you can
just write your or your your, your
your your Android code in
Java compiler.
It was like even just like Eclipse.
And then you can just like take your your
classes to Dex file, throw it onto
the device
and
then you can just load it.
You have to like, just, yeah, give it the
DEX file and of course, tell the
the and which class to load from the text
file.
Yeah. And then we when we want to load
additional classes, the flow of the
of the application or the flow of the
instrumentation looks like that.
And the first that we have the benign
process and this and this and
the second step
we load our native code,
which then calls to the D.V.M.
and can hook stuff.
And this code can also
load a class
and call methods of this class.
So the lower side we have like
our own classes, which
has all like instrumentation caught in
it.
Yeah, and a lot of classes can just be
used like any other class.
They also can load additional things.
The only complication so far, if you want
to use in our classes and your
and your instrumentation class, you have
to define and like add one
line of of
class loading for each of those in their
classes.
Yeah. One thing to load additional
classes, you have to, you know, make
the start Dalvik Cache Directory.
Right, right, right.
And in order to update your RODOLPHE
code, you have to or you inject
the Dalvi code, you have to delete
the cached version from the directory at
each time.
So while you're developing your
instrumentation, you have to always make
sure to really delete those file
because otherwise you will only loading
your your old
version
and with this will come
to the instrumentation code for version
two. So from
the hook, we now can load an application
loader. Yeah, load
a class into our application or
into our target process
and then call methods
in which I like written in Java
that perform instrumentation
or a utility for you for
your instrumentation.
So now we have code that's running
inside the target application, either
native code or a Java code.
But we really want to interact with a
target application and of course, the
Android framework.
But in order to access
or to interact with the application,
you really need access to the
applications object, such as the class
instances.
And there are a couple of methods you can
use for that, for example, like methods
or parameter scraping, so you can just
hook a method and
the process that gets like, for example,
a context parameter passed in like
Android content context.
And then you can just take the the
instance of the pointer
to that class instance and you and
pass it along to our to our
instrumentation framework, which then
can, for example, send intends on the
system and so on.
Yeah. What else?
Yeah, you can also access fields.
So what do you if
you know, like the name of a field
or like a part, like
a class field, you can just like find
the class, get the field ID and then just
read it.
They're also very simple.
Yeah. And there is like more stuff you
can do. You can also, if you like, only
have access to an internet class.
You can easily get the point
or reference to the outer class, which
just like this, generates a
very regular.
This is
there's this zero
dollar zero, which just like points
to the to the object class,
just multiple methods to like
get pointers to the
to the class.
Yeah.
Well, yeah, there's.
If you if you don't like
Nieto, have like very specific
ways to or if you call it basically
runs in the UI thread, you can also just
like use this activity thread
and you can just like get from from this
activity thread, you can just like it
a pointer to an application
context very easily.
So it really depends on
where you instrumentally instrumented
instrumentation logs if
you're running in the right thread and so
on.
So what what did we do as a cell
phone
for like a paper
earlier this year?
We yeah,
we wanted to change to
the local of on an Android
phone
and for the paper we
took them and took the
the Android source code and modified
it and then compiled it.
And of course, it's like very tedious and
you don't want to like, do this all the
time.
So at a later point, I
just took my framework and we implemented
that and we really we hooked on
the Android internal telephony.
Some estas petrosa.
This is the method
that is called when every time an eSIM
comes into your system
and then in the nice part of this
instrumentation, you can just go
instead of re compiling everything your
boat, your instrumentation framework and
save a lot of time.
And you can build your tool or your
instrumentation library once
and then deployed on like five different
Android devices, which maybe run
on based on different source.
So it's really a huge time saver, even
for like stuff that's not directly
security related if you just want to like
prototype software, prototype
or as extensions and so on.
Yeah, and
whenever you like, dig around other
applications and maybe
want to look at classics
like how what are the methods, what
are the method parameters, what are the
internal
values, variables and so on.
You can use like
some functionality from the D.V.M.
does class dumping and just
like, say, Hey, what?
What's actually inside this class?
And again, I just for for
an example, I just use a string class.
You can see all the different methods.
Of course, I retracted something just
because the slightest very big.
So you to look very easy, look inside
how their classes are looking like.
And then from from this, you can very
easy to just like copy paste, the
parameter list or the signature
into your instrumentation code.
Yeah. So
now we can we know how to modify
applications and.
But can you also
modify stuff globally?
Yeah. And of course, you can modify
modify stuff globally if you just inject
our modification into the zygote
process.
Is this modification gets
distributed to every application that has
started or forked off
from zygote after he and
added instrumentation.
Yeah, ah, yeah.
We can also inspect stuff into the system
server, which like runs part
of the framework, so if you want to do a
modification, be done in the framework.
Yeah, you just push your instrumentation
into the system server.
So one thing you can do is like, hey,
let's disable signature checking on the
device globally, then you can just like
to inject like our
verify that always returns one
and to zygote and then like basically
signature verification is like gone
everywhere in the whole system
until, of course we would.
But there, like many other applications
where you want to do like global
instrumentation.
OK, so I showed you some very
basic stuff, but of course, you're not
here to only like, say, like, Hey, we can
like print out what string functions are
called.
So
yeah,
we yeah, for a proof
of concept, we built
a nice little attack.
And let's look into
that. So I guess everybody who
has like an Android device knows about
this and application billing can.
So you can not only buy applications,
but you can also download free
application on the application.
You can just like buy like coins or
like remove the ads or convert it
to a full version.
And yeah, Google takes us there
30 percent and they say, Oh yeah, we make
a lot of money of it. So a lot of people
apparently use it.
And if you look at this, this
is quite some money you can spend on,
just like buying some coins and in
a stupid game.
So how does this thing actually
work? So you have your own application
on the left and then you have your
the Android market
and there is basically just like a
and an IPC mechanism.
They can like request billing
and then they Google will take
a request, send it to the backend server,
sign and send it back to you.
And then the application they tell you,
Yeah, the user paid,
No, you get like your thing in the
application and then you have a bunch
of extra stuff.
The yeah,
some applications like full use, like
a backend server,
and
they actually showed you the backend
server, as you will see in the second.
So the goal was, Hey, can we
can we trick
this payment thing?
The payment
to actually get free content, unlock full
versions, get some coins.
And of course, people have
done that. People have modified their
application, for example,
to like, just skip the payment and just
give you whatever like you're you're
you're selecting and the buy a screen,
or you can very invasively like modify
the market application, but just breaks
the lot. And of course, every time
something updates, all of the stuff has
to be redone and you don't
really don't want to like screw with the
market application of your device.
Yeah, so what what do we use, of course,
we use our dynamic instrumentation tool,
and the nice thing you can build is this
attack, which you can start and stop on
demand. So if you say, OK, I want to play
this game, I want to get some coins.
It just like started playing the game
and then after, which can be kind of
like, really stop it.
And the nice thing is, we never actually
have to look at how an application works,
the tech. It's completely transparent
towards the application.
So if the application is updated,
we don't even care.
Of course, if like there was really,
really specific changes in the market
API, of course, then you have to adapt.
But really, the key point is,
yeah, you don't have to touch individual
applications to attack them.
You install your tool and everything that
used that IPA API is
on.
So now be coming back to the signature
verification. So because normally after
something as bog, you get some
information
which is signed by by Google
and in your application, it's like, Hey,
is this thing?
Is this it's a signature
good. And if it's good, you say, OK, this
item is what?
Let's yeah.
Here you can have it.
So, yeah, of course, we can just
override that, and the signature part
is gone.
And then we just have to instrument
some API here, which
is basically only one column.
So instrumentals one call in the
application or in the market application
and
bing,
you get free stuff
and
everybody likes a good
demo, but
I only have a video.
So.
It's only four minutes.
So let's start this application first
for the ones who don't know how
the payment works, so a quick
run through of the payment
may go best.
Everybody knows for the scheme.
So let's get some stuff.
So, of course, we want to buy something
and you see, OK, buy this.
And so, OK, this would be five, $5
normally, so OK, let's let's not buy
it.
And as you can see, you can also pay not
only your credit card, but also via your
phone bill.
Yeah, so there like a lot of different
nice payment options.
Yeah.
Let's just like to show a bunch of
a bunch of games and how much
they charge
30 bucks.
To.
OK, let's
let's start our tool.
Of course, for all the instrumentation
stuff you need to have like Root on your
device.
You know, it's this is a very
old world, and so it has some there's
still some shell scripts involved.
So now let's go back to the game
and see
what's happening.
Let's try the expensive one,
since it's probably free, you know, 20
bucks, and then we go back and
you see.
Oh.
Because it's so nice that's just trials
of the cheap one and
the more
coins added.
OK.
That's why something here.
OK, so so far, this was like
pre-installed applications, so I could
have like modified something, so let's
select I will download
something directly from the markets and
right from the market screen.
We can start the application.
You will see it's also applying there.
So we don't really there's no
like reverse engineering modifying of the
applications.
Yeah. Let's go
to the market
yet.
In store this thing.
And let's see if you can.
OK.
The the screen will flip because of the
specific game and not a perfect
choice, but.
So let's get some coins.
I can see.
Let's go back
if to go back on multiple times because
we need to get back to the game.
And.
Judging.
Yeah.
So freshly installed from the
market, so.
So and I'm already almost at the end,
so dynamic instrumentation
of Android of the Android runtime really
allows to modify applications
on the framework and memory.
You don't break any signatures,
it's really your instrumentation.
Tools are really portable across devices.
The trick is actually
super stable because it's not a hack.
That's just like, how is JNI interface on
Android works?
So far, we can only replace complete
functions, so we don't like, modify
bytecode yet.
Actually, I'm working on this a little
bit as a side project.
Yeah, and
I think you can you can like
should be able to like steer of the whole
like Android application security scene a
little bit, because all the obfuscation
and the use of reflection is kind of
useless
because during runtime, everything
is there at the time you want to use it.
And if you can just like Hook and
you
can see and modify all the stuff,
yeah, at our lab, we have
various projects where students
are like using that to do other
interesting things.
So there should be some more upcoming fun
things. And of course, the whole
framework is open source
and released.
You can just like go to my guitar page
and download everything.
Yeah, including the injection
tools, examples for the likes
of string monitoring, for hooking
the semester spectrum.
But of course, no, no source
for the Google Play attack
because you don't want to.
Yeah, take away like the the money from
all the developers who like spent hours
so like right after this is like purely
to show like the powerful
possibilities you have is this framework
and also the use of framework to like do
good stuff. So we brought
a third party patching
framework
for Android.
So if you have an old device and don't
get updates anymore and those security
patches, you can
yeah. Yeah, install our
patches and we have like a demo
version
on
Ricky today. Or is anybody buddy?
Remember, it's like this master key
series of bugs.
Yeah, there is
a patch of that for that.
You can directly install them.
And I am through.
I would thank you everybody for
listening. I think we have time for
questions, do we?
Let's go to a question for microphone
number four, sorry.
Colin?
Yes.
Have you checked your software again?
Sorry, anti-virus software.
No, not yet.
OK.
You mean like instrumenting antivirus
software or. No.
Well, with antivirus software
was claims that your software is
not good software.
I I we haven't released any
of the instrumentation tools directly.
So this is really the tools.
It's like really to for yourself to like,
build tools and then distribute
some. I didn't.
I don't I don't have like a
tool like in the store, which I can check
against.
OK, so.
Um, yeah, no one.
So recently there has this
Android runtime been introduced,
which is, as I understood it, they
compiled the stuff now
to a more low level code
and executed natively.
They have to do you have any research
in in the R T in
the Android runtime, which is now
rolling out? Or is it really only Dalvik
for him? So because you only talked about
Dalvik now, I guess
A.R.T. is the future.
So what?
So I haven't looked into the A.R.T.
stuff yet, but
it basically just this ahead of time
compilation. So they compile that over
quarter native code.
I think last year I did a talk about
like how to instrument native code on
Android, so you could use that.
But if you've just like want to get stuff
out of the out of like some application,
you can still just change for $10, like
an art and as a resource
vehicle, which just like tools, mostly
AR, you can just like
not switch to art for now and use that.
But yeah, I haven't looked into art at
all, but a good point.
Thanks.
Things falling for the nice stock.
Is there any difference
between cooking some custom
code to normal up or
in a big room service?
Oh, no, no, so you can just talk only
like if if there is a service, if a
service is running and it's on process or
like inside another process, you can you
can hook everything.
So I also we hook the system
framework. So just like system
underscores server process or you?
Yeah, you basically can.
So far, we didn't have any problems
to hope something just left.
Sometimes we really have to be careful of
us like threading, of course,
because if you code executes in the
wrong, in the wrong, wrong thread,
you will crash would probably.
But so far, we could like
and place folks like everywhere,
especially like the string monitoring
stuff. It's very simple and you can just
like really just like install it
in any or inject it into any application
and.
No, there wasn't one
question when you want to hook something
system wide, you need to hook it on a
zero two process, so.
So is there any chick serve
self-check in the zero two process?
Did it has some changed
execution flow or something in it or not?
Oh, so far there is nothing,
nothing like that.
Of course, if you have like one
of the newer devices with like
SELinux and everything you have to do,
switch off a lot of like system system
security settings in order to like use
instrumentation or to even like run code
with root privileges.
But I my my code works under
the the prefix that your rooted
your device and have full control
because of course of the system prevents
you from
working with other processes and the
library injection works via Petraeus.
So if Petraeus is disabled.
Of course, you cannot do the injection.
So.
So with your will your
code work on Android KitKat
4.4 because it's a bit hard to
get
the root
you need, it should work on any device
that runs Dalvik when you have root
privileges. So the I'm
not like really in the business of like
rooting rooting phones there,
like a lot of other people are, it's
like you have made that their primary
hobby, but it's not mine.
Think of um.
There is also a question from the signal
engine I see.
Yeah, regarding the back
end circuit for the in
app payment,
there is the question what are the pros
and cons to use one?
So if you don't use the back end for
your own application for payment,
then you can.
Your application can be was like an
attack similar to ours.
You can like get everything for free
basic what you have to do, you have to
take them to the signature
or the signed data you get from the
place Play Store application and send
that to your back end server to those
signature verification there and sends
the answer back because now you could
also still modify the application to
check to, like, disable
the signature
or or the response like
fake a positive response from the server.
But from for that, you have to like,
disassemble the application, understand
how the application works, and that's way
more work.
So without a back end server,
without doing the the signature check off
device, yeah, you're
you're really make your save, make
yourself very vulnerable
to attacks like that.
So I think that's pretty much it.
Thank you very much comment.