Tag: android

Recovering data off a bootlooping Nexus 5

The situation

The Nexus 5 that I've had for almost 5 years started bootlooping repeatedly.

I've replaced/repaired multiple parts of it over the years but lately it had been more flaky than usual. For example:

  • Sometimes when booting it would show a "Firmware update in progress, don't disconnect your computer" message, even though there was nothing connected to the USB port.
  • It would randomly freeze and soft reboot when using it about once a week.
  • When propping it up on a book or something to angle the screen towards me, the screen would sometimes turn off and on (as it turns out, this was a warning sign)

I've been ready to replace it for a while, but couldn't justify it while this one was perfectly (ok, mostly) functional. That changed today when I tried to turn it on and it started bootlooping.

So buy a new phone and move on, right? Right, except I committed the cardinal sin of living in the digital age - not having complete backups. Yeah, yeah, I know.

I got most of it. I'd been using Syncthing to automatically back up photos, videos, and other files to my home server every night so they were all good. The problem was that I had been using FreeOTP-export to back up my 2FA secrets manually and the latest backup was missing a bunch of logins.

So I needed to somehow get into my non-booting phone and pull the data off it. At least because I was replacing it, all destructive options were on the table.

Diagnosis

The first step was seeing if other people had this problem. Some searching revealed that it was most likely the power button gone bad and being stuck in the pressed position.

To confirm this, I rapidly hammered the power button on a hard surface while booting, hoping that the jarring would un-stick it and let it boot. This sort of worked in that it would boot, but stopping at any point would result it it powering off again. It was also extremely difficult to tap it consistently enough to keep the phone on for long enough to pull any data off it.

The issue I mentioned earlier where propping the phone up made the screen turn on and off now made sense. I'm guessing this was causing a slight flexing of the power button switch, causing it to close and trigger. Over time this must've permanently bent something so it stayed closed, causing the bootloop.

Now that I had pretty much confirmed that it was something physically wrong with the power button circuitry, I messaged my friend Mike. When it comes to electronics, he's definitely more experienced than me. Plus, he lets me borrow his tools :)

The "fix"

The next day Mike came over with his soldering iron and we started brainstorming.

The plan of attack was to just take the power button off the board entirely. It can't always be pressed down if it's not on the board right?

In preparation for this, I wanted the phone to automatically boot when it was plugged into a charger so I wouldn't have to manually short the pins on the board. Fortunately this can be done with a fastboot command: fastboot oem off-mode-charge 0 (basically: don't allow charging while off, therefore turn on when charging).

After desoldering the power button from the main board, it was still bootlooping. Not good. I went back and cleaned up the solder to make absolutely sure that the power button signal pins weren't connected in any way. Still bootlooping when powered on. It would get to the bootloader and stay there, meaning the power button wasn't being pressed anymore, but when launching to either recovery or the main OS, it would immediately restart.

Looked into dumping data from the bootloader - impossible.

Reflashed the boot and recovery partitions - same thing.

Tried booting into recovery using fastboot boot <recovery-image> - bootloop.

sounds like it's time to cry

-- Someone on Freenode's #lineageos-dev channel after I explained the situation

Thankfully, it was not. Right after that, someone else asked if I had reconnected the battery. I had not.

Turns out that a working battery is required to boot the phone, even when it's plugged in. I had taken the battery out to desolder the power button and never put it back in since the phone seemed to boot fine without it. Whoops.

After plugging the battery into the board and booting the phone, it launched the main OS without any issues. Huge relief.

Recovering the data

With the phone booted up normally I used adb (running as root) to pull the 2FA codes and other important things that I knew I needed over to my laptop.

I really don't trust myself to remember everything so I booted the phone into recovery mode and pulled a complete backup of /data/data, /data/app, and /storage/sdcard (not actually an sdcard) to my laptop as well.

To make absolutely sure I didn't miss anything, I also pulled a raw image of the entire flash memory (disk-based encryption was not enabled) using adb pull /dev/block/mmcblk0 mmcblk0.img. Everything I need should be in the normal backups, but if not, I can always go spelunking through that image.

Lessons learned

  • If it's important, back it up automatically. If it's not automatic, at some point it will be missed.
  • Make sure you have the ability to get root access on every device you own before you need it - in this case I wouldn't've been able to pull the 2FA codes or do full backups without it.

Future plans

For the Nexus 5, I'm planning on either buying a replacement power button or maybe just soldering some wires to the exposed pads and snaking them out of the phone to an external button if I can't find one. The phone can then continue to be used as an app development testbed, a Chromecast remote, or as a basic emulation console until it dies for real. In theory I could keep using it as a phone too, but at this point I just don't trust it enough.

For my next phone, I've decided on the Xperia XZ1 Compact. It's a smaller phone that's mostly waterproof (IP68), has a fast SoC (Snapdragon 835), a headphone jack, SD card support, and great battery life. I have high hopes for it. Also, as evidenced by this post, having root access to the OS is pretty critical at times so I'll be flashing LineageOS on it ASAP.


Adding Xbox 360 controller support to a Nexus 5

Update

CyanogenMod has effectively been replaced by LineageOS. The links in this article originally all pointed to CyanogenMod but since it no longer exists, I've updated them to use the LineageOS equivilents where possible. The instructions will also need to be slightly modified for use with LineageOS builds.

Introduction

I finally just bought a new phone (a Nexus 5), and after flashing CyanogenMod onto it, I've been messing around with its OTG support. My old phone (a Nexus 4) didn't have the capability so being able to plug in keyboards, mice, external hard drives, and various other peripherals was (embarrassingly enough) a thrill.

Keyboards worked, mice worked, but when an Xbox 360 controller was plugged in, nothing happened. Turns out that while the kernel didn't have support for it enabled out of the box, getting it enabled and pushing the change upstream into the CyanogenMod project was easier than I thought.

Beware that this post is going to be more of a record of what I did so that I can do it again and less of a coherent tutorial.

Building CyanogenMod

First step was to download and compile CyanogenMod for my phone. I'm not going to go into this in any detail on this because there's already a good overview on the CyanogenMod wiki that covers the entire process, as well as a customized guide for the Nexus 5. If those articles are followed correctly, you should be able to build a fresh CyanogenMod image with:

1
brunch hammerhead

Enabling the kernel module

Once the image was flashed to the phone and verified to be working, the next step was to enable the xpad kernel module.

Copy current kernel config to the kernel directory for editing:

1
2
cd <build dir>/kernel/lge/hammerhead/
cp arch/arm/configs/cyanogenmod_hammerhead_defconfig .config

Edit the config:

1
make menuconfig ARCH=arm

At this point, a menu will come up. Search for xpad (type /xpad), and take note of the paths. ESC out of the search, navigate the tree and enable the modules found with the search. Save and exit.

Copy the config back and clean up any stray *.o files:

1
2
cp .config arch/arm/configs/cyanogenmod_hammerhead_defconfig
make mrproper

After enabling the module, rebuild CyanogenMod using the normal brunch hammerhead and flash it to the phone.

Submitting the change upstream

Since Xbox controller support had already been requested in a JIRA ticket(dead link), I went through the process to submit the change on the CyanogenMod Gerrit instance for inclusion in the next release. There's a guide for this here. As well as the guide, I found the people in #cyanogenmod-dev on Freenode to be very helpful.

A short while after submitting the change to Gerrit, it was merged into the cm-11.0 branch as commit i7ef4f6a and pushed out in the next nightly build (changelog screenshot).

Wrap-up

It feels great to be able to contribute to an amazing open source project that had at least a million people using it at one point or another. I recognize that the change by itself was just changing a config file to enable functionality that already existed, but it's helped me get through some of the non-coding hurdles of contributing to an Android fork like CyanogenMod (adb, fastboot, unlocking and rooting phones, compiling AOSP, flashing images, the contribution process, etc). This time the actual contribution itself was minor, but it's gotten me more familier with the process, hopefully making it easier to contribute something more substantial in the future.

In the end, I learned a lot about Android development and how all the different pieces that I had read about at one point or another actually fit together. During the whole process I also lost a lot of the fear I had about messing with phones and other more expensive locked down devices. Going forward, I'm going to attempt to compile and flash open source operating systems like CyanogenMod onto more devices that I own. I like being able to tweak things and feel like I really own them, hardware and software.


Fixing save file corruption in Ridiculous Fishing

Ridiculous Fishing is a game by Vlambeer about fishing. That's if you can call chainsawing fish and blowing them out of the sky with a bazooka "fishing".

I've been playing this game on and off for a while now, but just recently I had a problem where my save file somehow got corrupted, making the app refuse to open.

The problem first manifested as the game freezing for up to 5 seconds when navigating around the UI or buying items in the in-game store. Since I was running the game on a Nexus 5 (not the latest and greatest, but pretty close), it seemed weird. The delay got longer and longer until the game eventually crashed and refused to reopen.

Since I was pretty far into the game (I only needed to catch one more species of fish!), I opted to try to fix it instead of just wiping the app's data and starting again. I initially tried clearing the app's cache and reinstalling the app, but the problem persisted.

The next step was to dump the games's data to my computer so I could do some analysis on it. Some exploration on the device revealed that the settings and data were stored in the folder /data/data/com.vlambeer.RidiculousFishing.humble (I have the Humble Bundle version of the app).

To pull that folder to my current directory, I used ADB:

1
2
adb root #Restart adbd on the device with root permissions
adb pull /data/data/com.vlambeer.RidiculousFishing.humble/

A quick du -h revealed that something was very wrong in the files/Library/Preferences/com.vlambeer.RidiculousFishing.humble.plist file. It should've been just a text document, but was well over 200MB.

After trying out of habit to open the file in Vim and having it hang (oops), I paged through the document with less. About halfway through the file, there was a line containing &amp;lt;message&amp;gt;@eggbirdTBA Take it to the Smartypants Bar (no, that's not a formatting error, in the plist there's XML data stored in a <string> element, requiring the < and > characters to be escaped) followed by about 200MB of garbage.

Apparently there are ways to load huge files in Vim, as well as other text editors that handle them nicely, but since I already knew what line was causing the issue, a simple sed command would do the trick.

1
sed '/Take it to the Smartypants Bar/d' com.vlambeer.RidiculousFishing.humble.plist > temp.plist

Total size of temp.plist: 107.11KB. Much better.

After going though and deleting some lines around the one that was removed (to make the XML valid again), I pushed the file back to the device:

1
adb push temp.plist /data/data/com.vlambeer.RidiculousFishing.humble/files/Library/Preferences/com.vlambeer.RidiculousFishing.humble.plist

Success! The game opened properly, all the freezing issues were gone, and my save data was still there.

Now to find that stupid Mimic Fish...

© Carey Metcalfe. Built using Pelican. Theme is subtle by Carey Metcalfe. Based on svbhack by Giulio Fidente.