
Android Reverse Engineering - r11t
http://thomascannon.net/projects/android-reversing/
======
follower
Always enjoy reading articles like this that describe the process of reverse
engineering a particular technology or device.

Also appreciated the mention of the rageagainstthecage exploit which looks
like it could be used to enable a "full user data" backup to be made of a
device. One of my complaints about Android is that even the "owner" of the
device (without rooting & therefore warranty voiding) can't access all their
own data files if an application provides no way of doing so.

------
joe_the_user
Serious question: is there any application that could possibly resist
revealing it's information if it's working ram is written to memory?

~~~
jrockway
Of course not. Obfuscation gets you something (it takes few minutes of work to
get the key for new Blu Ray releases), but the only secure solution is
hardware that melts itself when you give it the wrong password. Even then,
things like this have been broken in the past. Given infinite time with access
to a device, anything that it is securing will be stolen. (The same goes for
physical systems. No safe is completely secure. They even got the gold out of
storage in _Cryptonomicon_ eventually!)

The real solution is, "if you have data that's so secure that stealing the
phone and running the software on a virtual machine threatens your security,
maybe the data should not be on a fucking cell phone".

------
kurtsiegfried
The main issue I have with this article is that it describes a very
implausible circumstance in my opinion. If you have an application with such
sensitive information on the phone to warrant this kind of testing, why would
you not take advantage of the device administration policies to enforce a
password policy and a password timeout policy?

[http://developer.android.com/reference/android/app/admin/Dev...](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html)

There doesn't seem to be a policy in the current API docs to prevent a user
from enabling USB debugging, but there is a rather large warning when that
option is selected.

Without USB debugging and using a password policy, the author's strategy would
not have worked. With the current strategy, this has nothing to do with
Android, and everything to do with having poorly designed and poorly
implemented security on the part of the application author.

~~~
thomas_c
The software under test is designed to allow employees to use their personal
phones for corporate use. Being a personal phone, corporate policies are
irrelevant because we cannot apply or enforce them. The software is in use by
some very large companies and being evaluated by others therefore it is far
from implausible that some of those personal phones haven't got a device lock
code set.

I agree it is not an Android issue though, it is the poor design of the app.

~~~
kurtsiegfried
@Thomas, thanks for the clarification, I guess I'm just used to companies with
more authoritarian policies. Something along the lines of: "If it connects to
our infrastructure, it gets policies enforced" (similar to what WMF said).

Nice work on taking apart the app though.

~~~
thomas_c
Yes that is my experience as well and is the case where I work. This seems to
be changing as more tech-savvy staff with highly capable devices push their
companies to "get with the times". So I guess that is why we're there to point
out the risks in doing so. Doing this was partly fun, and partly so we could
backup any statements we made about the risks of doing it.

Anyway, glad people enjoyed it. It's good to get some discussion going too.
Thanks =D

------
trotsky
Very interesting and in depth article, thank you very much for posting it.

Does anyone know why android chose not to use LSM or other kernel based
capability enforcement? It would seem like such a hands off platform would be
ideal for fine grained enforcement - allowing some amount of security to be
maintained even in light of a privilege escalation exploit.

------
Bud
Very detailed and entertaining to read.

------
jorgem
Cool article. "Someone" should hire you :)

