Android Reverse Engineering

http://thomascannon.net/projects/android-reversing/

by r11t • 16 years ago

67 11 16 years ago

trotsky• 16 years ago

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• 16 years ago

Very detailed and entertaining to read.

follower• 16 years ago

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• 16 years ago

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

jrockway• 16 years ago

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".

kurtsiegfried2• 16 years ago

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

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_c2• 16 years ago

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.

wmf• 16 years ago

A more common policy in my experience is that any phone that has any company data on it must be company-managed. In other words, you pay for it but the company really owns it.

kurtsiegfried2• 16 years ago

@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.

jorgem• 16 years ago

Cool article. "Someone" should hire you :)

Android Reverse Engineering

Related Stories