Nice wallpaper you've got there. It would be a shame if it bricked your phone A picturesque Android wallpaper image is exhibiting some unwelcome side effects on most Android phones, effectively "soft-bricking" them until the user manages to perform a factory reset. Soft-bricking is the nicer, less permanent version of hard-bricking (the latter irreparably damages the physical hardware or firmware). …
"It's a bit ironic that a 'Mountain View' causes so much grief to the unwary."
Not really. It's been done before ...
> The correct terminology is: "It's 2020 and you can still pwn Android with a JPG"
Meanwhile, over in Apple land...
https://arstechnica.com/information-technology/2020/06/apple-fixes-bug-that-could-have-given-hackers-unauthorized-to-user-accounts/
Software is growing ever more complex, and a lot of this stuff is buried under countless layers of abstraction.
Sadly, since no-one has an army of infinite flying monkeys to thrash their way through every possible permutation of data and actions, some things are always going to be found reactively.
And so we fix them, check to see if anything else has a similar issue, update our processes to catch any future examples, and move on.
Or at least, that's the theory. Over in the real world, time and resource constraints can lead to some or all of the post-fix actions being skipped.
And that's when we need to take note, or at least point and laugh.
Because as the old saying goes, "fool me once..."
Amazing how you can come to that conclusion completely on your own and then start criticising based on what is essentially an uninformed wild guess.
User input has already been checked: the file has to have been parsed to identify the need for a colour space conversion. And based on the brief description in the article it doesn't sound like a buffer overflow. My hunch would be a maths issue, a division by zero or something like that.
This post has been deleted by its author
Not to worry. You can determine the voracity yourself. Just download the image and try to use it as a wallpaper. You can get it from the linked tweet. I urge you to enable USB debugging and approve your computer before you try it though--it might help with the reset process. In fact, it's possible you might be able to use ADB to reset the wallpaper setting depending on how much access you have. No guarantees though.
Well there's this new-fangled thing called automatic bounds checking. If you try to access an out of range index it throws an exception and your code catches... Oh.
Well, the worst that can happen is it safely takes out the process without corrupting memory. It can then be restarted and... Oh.
Maybe we do need to think about this a bit more carefully. This error checking stuff is quite hard, isn't it?
Did I get it right, any JPG picture using a RGB color space crashes all Android versions?
It's below script kiddie difficulty, it's "little sibling" level stuff. I expect floods of stunning "backgrounds for your phone" appearing as it must be the easiest way to ruin peoples' phones (and thus lives)...
(Yes I know, it doesn't actually ruin the phone, but by resetting it you'll lose everything you had on it, which for most younger people is "everything".)
What?, the same Google who can't be arsed keeping their own products fully patched, and who've deliberately timebombed support for Chromebooks running Chrome OS (they don't tell you about the AUE on those updates you don't have to worry about in their shitty shiny ads for the things)
I used to have a "prototype" phone - IMEI contained country code "testing" or something similar. (It was a pain to get Verizon to activate it, their systems said it didn't exist.) As it wasn't intended to be used by a consumer, the carrier didn't ever have patches for it. Ever. Not one single patch in the couple of years I used it. Having Google provide the patches would have been a significant improvement, and they're better about keeping an OS up to date than a carrier that just wants to sell you the newest phone.
Pity it got broken, it was much better than my current phone.
"any JPG picture using a RGB color space crashes all Android versions?"
I wouldn't have thought it is that simple, there have been many Android versions and billions of phones and many many backdrops. And this has only turned up now in 2020.
So, either its an unexpected side effect of COVID, or the JPEGs need to be a specific sort with colour values that, when translated to sRGB go out of range.
Of course, now that the problem is known...
As they phrase it in software development courses, provided example code is usually devoid of all the error and bound checking that would be required in production code.
Also, does this mean that nobody at Google ever in the history of Androd tried to test this 'app' with an RGB image? For a core service whose functioning determines whether a phone works or is just a useless brick stuck in an endless reboot loop?
That seems hard to swallow, but then again, we are talking about software development here...
It looks like most RGB images will work because they will translate successfully. Only ones that go out of bounds during an RGB-SRGB conversion will cause the crash. I don't know what the conversion process looks like, but you can probably find the algorithm out there. Any RGB picture that pushes one of the components over 256 should do it.
If you do find that algorithm, please replace any mathematical formulas with min(255,[original_formula]) and send that in to Google. I think that might earn you a nice job as best programmer on the core system UI team. If you want to go for the ultimate job security, you might prove to them that you can think ahead by doing a max(0,...) check as well.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
