Swipe that yellow bar to the left and you might see a password request

2018 Note: These instructions are from 2013 – so unless you find a 2013 era Kindle Fire that has not had its software updated, the below instructions might not do you much good. I don’t know, as I don’t own a Kindle Fire personally.

I recently came across a Kindle Fire nearby where I work at the university. A colleague and I assumed it must have been owned by a student or teacher who worked in our building, so she posted signs up around the building stating that a lost Kindle Fire (original, not HD) had been found and that the owner could pick it up in her office. Months went by, and I was tormented by the sight of it in her office, sitting unreclaimed on a stack of paperwork.

She tried contacting Amazon, asking if they could help us locate the owner if we gave identifying numerical information about the device. They (perhaps wisely) refused to do so, but tempted to coax the information out of us anyway so that they could remotely brick the device and render it useless “for security reasons.” I assume then they’d ship us a postage-paid box that we could return the dead device in, and they’d take care of contacting the owner themselves.

Hah, I thought to myself. What a roundabout journey this poor Kindle will have to take, when all we need is just to reset/delete a lockscreen password. So I rolled up my sleeves and got to work. It ended up being a lot more involved than I had thought it would, thanks to some variations between how Amazon has modified Android from Google’s original designs. The purpose of my blog post here is not to introduce new information or research (I’m a repair and maintenance guy, not a programmer) but instead to merely tie together a myriad of information that I had to use on my journey of discovery.

  1. First order of business was researching where Gingerbread (Android 2.3, or what came as stock on the original Kindle Fires) stores the database for lockscreen passwords. XDA-Developers reveals it here; to summarize:
    data/data/com.android.providers.settings/databases/settings.db
  2. It’s an SQLite database, so you will of course need the application sqlite3 to edit it. The problem is that while stock Android comes with this executable, the Kindle Fire does not. If you try to edit this file, even on a rooted Kindle Fire, it will merely tell you – I don’t know what to do with this file.
  3. I didn’t have any rooted Gingerbread-era phones lying around to rip the binary executable off of, so I downloaded and installed the Android developer SDK on my computer. If you have one, you can use that, and skip this extra time-consuming step. This site here has instructions for installing the SDK, and adding Gingerbread as an installed operating system/environment.
  4. Once you have Gingerbread open in a cute little window on your computer, you can use these instructions to find where the SQLite3 executable is found, and how to yank it off of the emulated Gingerbread virtual machine and onto your computer.
  5. Now, you know where the .db file is (theoretically) and you have a sqlite application ready to be put on your locked Kindle Fire. But of course, in order access your own Kindle Fire’s /data/data folder you will need to root it. But people should be rooting their own devices anyway, and it’s not like you can’t undo it, so I didn’t feel bad about rooting this lost Kindle Fire in order to find the owner. Plug the Kindle Fire in, and follow these instructions here for the original Kindle Fire Utility to root it – the interesting thing is that for all of the Kindle Fire’s weird eccentricities, like not including SQLite3, they still leave debug mode enabled by default, which is kind of key for this to work if you can’t get to the home screen and settings.
  6. Now that you’re rooted, you can use these instructions to get ADB (android debug mode) going in a terminal window on your computer. Use push to get that sqlite binary onto the Kindle Fire in the /data/data folder. I rebooted the Kindle after doing that, then opened up ADB in a terminal window again.
  7. Success! Now, going way back up to that first instruction website from step #1, you can get into the settings.db file and delete the lock screen password with the following commands:
    sqlite> update secure set value=0 where name=’lockscreen.password_salt’;
    sqlite> update secure set value=0 where name=’lockscreen.password_type’;
    sqlite> update secure set value=0 where name=’lockscreen.lockoutattemptdeadline’;
    sqlite> update secure set value=0 where name=’lock_pattern_visible_pattern’;
    sqlite> update system set value=0 where name=’lockscreen.lockexchange.enable’;

I rebooted one last time, and this time, instead of the lock screen, the system rebooted right to the user’s home screen. I went to the “About Kindle” page on the device and found the user’s full name, looked him up on the Wisc database, and sent an email off of to him letting him know that we had recovered his device. I even dropped it off for him; he seemed surprised that I had taken the time and effort to track him down, but pleased to have it back. He was clutching an iPad when I came to his office, so something tells me that the temporary loss of a $199 device wasn’t devastating to him.

Anyway, I hope that this amalgamation of instructions can prove helpful to someone who’s in a similar situation.