Third-party native code protectio

by Aubrey-Derrick Schmidt » Tue, 18 Aug 2009 15:12:41 GMT

Sponsored Links
 Hi William,

we share similar concerns about this topic. I have a master student who
just started his thesis aiming for detecting JNI invocations
statically/dynamically. Lets see, how well this goes.



Third-party native code protectio

by Dan Hein » Fri, 21 Aug 2009 13:47:28 GMT


I have a very similar question about native code.   However, my question is
how native parts of the core system can be extended (such as adding a new
native service) in a secure manner.  That is, outside the Dalvik VM, is
there a way to run native code as a "user" without root permissions?

The following example is a bit "out there", but it is intended to clarify
the above question with a concrete example.  So, let's just say I want to
build a native Apache webserver into my Android handset, perhaps for  a
piconet collaboration session with other users in the room.  How could I
start the Apache server securely if it lived in /system/bin, along side
other apps like telnetd which have uid=0 root, gid = 0 root?  Could I use
sudo?  Could I use chroot?

I am not a Linux security expert.  I imagine there is a fairly
straightforward way to do the above.  I just want some concrete examples.  I
would very much like to see one of the Android framework engineers



Sponsored Links

Third-party native code protectio

by Dan Hein » Fri, 21 Aug 2009 17:25:37 GMT


Thanks for the tips. I'll dig inot init.rc. The webserver was just an
example, but this is exactly the type of info I was seeking.

Do you know of any existing documentation that explains steps needed to
secure Android device (i.e. at the OEM level)?

1. sign userimage with vendor private keys
2. ensure system property set
3. ensure no root consoles left running (e.g. such as G1 RC29)
4. ensure build phase for generating dexopt files into system image
5. Other?


On Fri, Aug 21, 2009 at 11:20 AM, William Enck <> wrote:


Third-party native code protectio

by Dan Hein » Fri, 21 Aug 2009 17:29:07 GMT

  guess another question I have is how exactly a program like Apache drops
it's user level to non-root. Does anyone know the system call it makes to
run at a lower privilege level? Can (sudo, fork, spawn, exec) be used by
the executable on itself?

On Fri, Aug 21, 2009 at 11:20 AM, William Enck <> wrote:


Third-party native code protectio

by Chris Palmer » Mon, 24 Aug 2009 17:32:21 GMT

 Don't think of Java, perhaps especially Dalvik, as a way to protect against
kernel bugs. Userland can't generally "defend in depth" against kernel

Like all operating systems, Android trusts the kernel to uphold the kernel's
own design guarantees. If the guarantee is broken, that's a kernel bug and
should be fixed in the kernel.

I imagine some folks on this list have seen this (or a similar story): 

I haven't investigated it in any depth, but my speculation is that the
exploitation of the referenced kernel privilege escalation vulnerability ( ) results from
the ability to execute native code.

I understand the public pressure to allow native code, and that Android's
security model provides protection at the process level; however, as an
Android user, I would like the ability to disallow third party native
libraries for security purposes (defense in depth).

I imagine there is a library path that can be checked somewhere to ensure
JNI only allows the /system prefix. Alternatively, the LSM hook for mmap
could be useful.

While this won't stop users from rooting their devices when kernel privilege
escalation vulnerabilities inevitably emerge, it provides a nice buffer
between the time the vulnerability is found to the time a security patch is
deployed that will protect many normal users.

I'm going to take a look at generating a patch when I get a chance, but that
might not be for a little while. If anyone starts to work on this, please
let me know.


Third-party native code protectio

by Chris Palmer » Mon, 24 Aug 2009 19:02:31 GMT

 efense in depth mechanisms are good when they (a) don't break
legitimate features and (b) actually work. Your examples of a firewall
and native code exploit mitigations are good examples.

However, native code execution on Android is a legitimate feature, and
blocking its use would not actually work. Android uses Java source for
its convenience features, not for the VM's security features. The
Dalvik VM tries to be fast and small, but does not try to be a
security boundary (it's not a JVM). Furthermore, much of the platform
functionality is written as JNI and/or as a very thin wrapper around
native code -- it's not a long trip from Dalvik bytecode to machine
code in a lot of places. And that is perfectly ok.

If any Android platform distributor tried your idea, attackers would
probably not take too long to pop through to native code. And then
you'd have thrown away a good feature for no security benefit.

Defense mechanisms should rely on published API contracts, not
imagined guarantees. For example, VMWare does not claim to be a
security boundary, and it does way more separation work than Dalvik or
the JVM. And indeed, it can be popped:

The difference is that VMWare does not claim (that I can see) that its
product protects hosts from guests. Linux *does* claim to separate
UIDs, so when it doesn't, everyone should agree it's a bug. It's
reasonable to trust that Linux upholds its guarantee, even if
sometimes it doesn't; on the other hand, it's not reasonable to trust
that VMWare or Dalvik upholds guarantees they never actually made.

That's enough out of me. Now I'll go back to enjoying my
high-performance Android games and crypto library and DSP apps... ;)

On Mon, Aug 24, 2009 at 11:23 AM, William Enck<> wrote:

Third-party native code protectio

by Jean-Baptiste Queru » Tue, 25 Aug 2009 16:31:29 GMT

 llowing native code is something that developers have been screaming
for since pretty much day 1 of the SDK, and preventing apps from doing
so after all the efforts that have been put into officially enabling
it sounds like a huge step backward for the entire Android ecosystem.

On top of that, I personally see it as a goal that apps running within
the virtual machine should have access to all the capabilities that
their host process has, i.e. that the virtual machine itself should
impose no bounds. Developers writing code to run outside of the
virtual machine should only need to do that for pure performance
reasons when the intrinsic characteristics of the virtual machine give
native code a performance advantage, but they should not have to write
native code just to access capabilities that they can't otherwise get
to. Making developers write native code so that they can work around
arbitrary limitations imposed by the virtual machine is a step
backward in terms of security as far as I'm concerned, as I believe
that native code tends to be naturally more sensitive to bad data than
code running in a virtual machine like dalvik.

Finally, the more we prevent apps from doing things that they should
legitimately be allowed to do without actually improving security, the
more we give users incentives to bypass security mechanisms and
install unsupported versions of Android on their devices, including
versions where security is much worse.


On Mon, Aug 24, 2009 at 1:19 PM, William Enck<> wrote:

Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further

Third-party native code protectio

by Chris Stratton » Tue, 25 Aug 2009 19:50:47 GMT


And when I make that call with a path name like /system/../
whereeverIwant ?

Third-party native code protectio

by Chris Stratton » Wed, 26 Aug 2009 15:44:28 GMT


The problem with this that I see is that as soon as someone comes out
with a cool game that pushes the edge of the phone performance via
custom jni libraries, you are going to start to see applications
asking users to switch that protection off.  And the present PC
ecosystem seems to indicate that the majority of users will almost
reflexively choose the latest cool capability over vague security

That doesn't mean that I don't think there are applications where the
checkbox is useful and users who will leave the protection on, but it
does cause a concern that a small percentage of users will be
believing they get a security advantage from the VW, a belief which
the people maintaining the VM don't really seem to share or concern
themselves with - in no small part because for the majority of devices
breaking out of the VM will remain a single well documented and
exampled functional call.

Trusting something more than its authors do strikes me as unwise -
even if there is some real benefit of deepening defenses, I seems like
a dangerous path to start down.

Third-party native code protectio

by Dianne Hackborn » Wed, 26 Aug 2009 17:09:57 GMT

 t the end of the day, native code is an official part of the platform API,
and turning it off breaks compatibility. That particular cat is out of the
bag, and we can't (nor want to) stuff it back in. One can think that native
code is useless, and the world should run in a virtual machine, but that is
not the philosophy behind Android and in fact many of the fundamental design
decisions in the system are there to enable native code in a robust way.

That said, I can certainly see an argument for treating native code as
another permission, and thus showing to the user that an app contains native
code when it is being installed (as a secondary permission, though, since it
is not something most users would understand or care about). We'd probably
be open to accepting such a patch, but for it to be viable it would also
need to enforce that if it doesn't tell the user that the app contains
native code, then the app doesn't actually get to run native code. That
would be a significant challenge, since we never designed the system to care
about an app being able to run native code in its process, so in addition to
whatever enforcement in loading you need to implement in that VM, you'd need
to do an audit of all of the code accessible with JNI (including web kit and
PV) to have some confirmation that it doesn't present a back door.

On Wed, Aug 26, 2009 at 7:33 AM, Chris Stratton <> wrote:

Dianne Hackborn
Android framework engineer

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.

Third-party native code protectio

by Dan Hein » Thu, 25 Feb 2010 16:33:41 GMT

 Can someone describe how to create a signed for use with the
fastboot command "update"?  What tools are used?

Is there documentation on this somewhere?



Third-party native code protectio

by Nano Hacker » Thu, 25 Feb 2010 16:38:20 GMT

 Well you can always generate a sha256 hash or equiv on any file. But
remember that it is essentialy a piece of code that someone else wrote. I
believe the site has a section on signing your own apps
before they hit The market. Perhaps check their.

Can someone describe how to create a signed for use with the
fastboot command "update"?  What tools are used?

Is there documentation on this somewhere?



Third-party native code protectio

by William Enck » Thu, 25 Feb 2010 17:10:27 GMT


Good question. I haven't run across any documentation either. I've modified and
resigned a few official OTA files though. For that, I used the
signapk.jar utility that is built with Android

It works like this:

java -jar /path/to/signapk.jar \
/path/to/custom-ota.pk8 \ \

Look in build/target/product/security/ for the test keys, and for the
script that can be modified to make new OTA keys.

However, this all assumes that you have the directory structure correct inside
of (which I believe is the question you asking). Download one of
the official OTA .zip files and take a look at what you will need to recreate.
Specifically, look at META-INF/com/google/android/update-script.

On a related note, I was browsing through the source code checked out with repo
-b android-2.1_r1 and saw the build/tools/releasetools/ directory with
interesting files:

[android-2.1_r1/build/tools/releasetools]% ls
img_from_target_files ota_from_target_files sign_target_files_apks

I haven't had a chance to play around with them yet though.

Good luck!

On Feb 25, 2010, at 11:33 AM, Dan Hein wrote:

William Enck
PhD Candidate
Department of Computer Science and Engineering
The Pennsylvania State University

Third-party native code protectio

by Dan Hein » Thu, 25 Feb 2010 20:16:40 GMT


Thanks again!

I saw those tools in build/tools/releasetools as well. Thanks for the
instructions on signapk.jar.

And yes, you are correct. I was looking for documentation on the directory
structure archived within


On Thu, Feb 25, 2010 at 11:10 AM, William Enck <> wrote:


Third-party native code protectio

by William Enck » Fri, 26 Feb 2010 12:56:12 GMT

 rm, I should have checked before I sent my last email:

Basically, when you "make dist", it creates a bunch of files in out/dist/.
These are the files used by the scripts in the releasetools directory. It looks
like the script used for "fastboot update" is different than the OTA script
(according to the link above).

Looks really promising for what we need. Oh, and run the releasetools from the
top of the source tree. It seemed to work better that way (particularly,
sign_target_files_apks, which failed when I wasn't there). I had some errors
with the OTA script (ota_from_target_files), but that might be because I was
using "lunch 1" as my build target. The script used to create the "fastboot
update" .zip file (img_from_target_files) worked fine, however, but it doesn't
create the OTA directory structure, just a .zip with a bunch of .img files in
it (which makes sense for fastboot).


On Feb 25, 2010, at 3:16 PM, Dan Hein wrote:


Other Threads

1. PictBridge support on Android

Hi All,
I would like to know if Android have PictBridge and DLNA support, if
the board vendor decides to supports it??


2. Dynamically obtaining several instance of a view item defined in layout/xml file


Just inflate from the xml each time you want a new instance of that particular 
view. Like this:

View innerRL = LayoutInflater.from(context).inflate(R.layout.inner_view, null);


-----Original Message-----
[] On Behalf Of krishna
Sent: den 8 juni 2010 02:37
To: Android Developers
Subject: [android-developers] Dynamically obtaining several instance of a view 
item defined in layout/xml file

I have a relative layout (let's say innerRL place in layout
inner_view.xml) which I wanna add to another layout (main_layout), I
wanna dynamically add multiple instances of innerRL. Specifying
innerRL in xml gives me ease of maintenance (as against doing totally
in the code), however I want to be able to add several instances
dynamically. Using findViewById(resource_id) gives me that particular
instance, should I have to use clone()?

One other approach I see is ArrayAdapter, but it seems overkill.



3. Seemic ngga bs retweet

4. Developing HTC touchflo like inteface for android

5. Android display refresh problem.

6. how to develop a site client?

7. CS telkomsel = buku berbicar