Always enjoy reading articles like this that describe the process of reverse engineering a particular technology or device.<p>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.
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?<p><a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html" rel="nofollow">http://developer.android.com/reference/android/app/admin/Dev...</a><p>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.<p>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.
Very interesting and in depth article, thank you very much for posting it.<p>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.