[Q] Rooted Android security (bootloader/recovery)

---

I know this idea has been tossed around quite a bit, but I had an idea...

Scenario - You have a rooted Android phone (Froyo/Gingerbread) with a strong PIN or password lockscreen, not a pattern. You also have a protection app that you can use remotely to sound an alarm, track, or wipe the data.

Problem is, knowing what I currently know now, if I was a thief, I would immediately pull the battery until I got to a safe place. That renders the protection app useless until the phone is turned on. But all of that is pointless if I know how to start the bootloader and get to the recovery. Once in recovery, I can backup all of the info that is on the phone for investigation later, I can wipe the phone with a new ROM, rendering ALL protection apps useless, and I can swap out the ESN.

Now, if I was the victim, my first priority is data protection. If I had a protection app, I would naturally enable it (more about that later), and I would report the phone stolen to my wireless provider.

So, my question is, can we secure the bootloader and/or the recovery? I know that recoveries can be touch-based, which means that we can have a strong password that is also easy to enter. The bootloader would be a problem though, since we can only use hard key buttons. However, we never use the bootloader except to flash recoveries, or to enter the recovery if we are away from a computer. So, my idea is, since we never have to use the bootloader, make it accessible only if the password is entered via an ADB shell? Once the bootloader is up and running, it easily processes commands from ADB, so let's password protect it that way. And to prevent brute-forcing, after 3 failed attempts, the phone bricks itself. The phone is reported stolen anyways, so you don't care about it, but this is a damn good F.U. to the thief. Also, it does prevent any backups from being done that he can access. Backups with personal info on them shouldn't be on the SD card, so if he gets that, who cares, SD cards are $10.

Thoughts?

Originally Posted by smmiller506

I know this idea has been tossed around quite a bit, but I had an idea...

Scenario - You have a rooted Android phone (Froyo/Gingerbread) with a strong PIN or password lockscreen, not a pattern. You also have a protection app that you can use remotely to sound an alarm, track, or wipe the data.

Problem is, knowing what I currently know now, if I was a thief, I would immediately pull the battery until I got to a safe place. That renders the protection app useless until the phone is turned on. But all of that is pointless if I know how to start the bootloader and get to the recovery. Once in recovery, I can backup all of the info that is on the phone for investigation later, I can wipe the phone with a new ROM, rendering ALL protection apps useless, and I can swap out the ESN.

Now, if I was the victim, my first priority is data protection. If I had a protection app, I would naturally enable it (more about that later), and I would report the phone stolen to my wireless provider.

So, my question is, can we secure the bootloader and/or the recovery? I know that recoveries can be touch-based, which means that we can have a strong password that is also easy to enter. The bootloader would be a problem though, since we can only use hard key buttons. However, we never use the bootloader except to flash recoveries, or to enter the recovery if we are away from a computer. So, my idea is, since we never have to use the bootloader, make it accessible only if the password is entered via an ADB shell? Once the bootloader is up and running, it easily processes commands from ADB, so let's password protect it that way. And to prevent brute-forcing, after 3 failed attempts, the phone bricks itself. The phone is reported stolen anyways, so you don't care about it, but this is a damn good F.U. to the thief. Also, it does prevent any backups from being done that he can access. Backups with personal info on them shouldn't be on the SD card, so if he gets that, who cares, SD cards are $10.

Thoughts?

Back ups can get quite big in size, and using internal memory to store them is not very wise. Good perspective on the idea.