Hacker News Reader

Comment by AdmiralAsshat | Hacker News Reader

Granted we understand "brick" to mean the device cannot boot, but this comes pretty damn close on some phones, it seems.

> "After setting the image in question as a wallpaper, the phone immediately crashed. It attempted to reboot, but the screen would constantly turn on and off, making it impossible to pass the security screen," he noted.

> Restarting the device in safe mode (by holding down the volume button during boot-up) did not fix the issue."

If restarting doesn't fix it, and not even safe mode will allow you to change the wallpaper to get around it, what method of recovery is left for the affected user? Factory reset from recovery mode?

View on HN

It depends. If the bootloader is unlocked, they could boot a custom recovery and alter the system image to try and insert a workaround (such as deleting the buggy library and dealing with the resulting breakage). If the data partition is fully unencrypted, they can even delete the offending file straight from recovery. On a bootloader-locked, fully encrypted device (the default nowadays) they'd be SOL and have to use the stock recovery or bootloader to force a factory reset - not only would that involve obvious data loss, but they would even have to deal with FRP afterwards.

You can also delete the offending file with a fully encrypted main storage, since twrp supports decrypting and mounting the storage on demand.

> since twrp supports decrypting and mounting the storage on demand.

It advertises that support, but I've never really seen it work. It seems that modern FDE on Android is such that you can only really "decrypt" from the system environment itself, not from different code - and it's not clear how to fix this.

>It advertises that support, but I've never really seen it work

works for me. it really depends on whether your TWRP distribution implemented it properly. AFAIK android phones don't have a mechanism to bind encryption keys to a system state (similar to sealing keys to PCRs for TPMs on PCs), so I don't think your theory is correct.

Last time I checked it was possible to factory reset the device from the bootloader menu thing. It causes the device to go in to an anti theft mode where you have to log in to the last google account the device was used with but it should be able to solve this issue.

Perhaps the only way to fix it would be get into fastboot mode and enable USB debugging, then look for that arcane settings file on the file-system which your OEM decided to use for configuring wall-papers and fix that file. I see no other way.

Wouldn't that settings file be on the user data partition, which is encrypted and thus not normally accessible in recovery mode?

(We detached this subthread from https://news.ycombinator.com/item?id=23404703, since that was just a terminological dispute and we changed the title to defuse it, but this subthread contains more information)

Reply on news.ycombinator.com