TechTalk Compiles All the Android News You Need in One App

If you’re as obsessed with mobile devices as the vast majority of our forum … more

Android App Review: Google Inbox to Improve Your Life – XDA TV

Recently, Google+ exploded with the announcement of Google Inbox, as … more

Damp the LG G3 Thermal Throttling

As our mobile devices grow thinner and more powerfulwith each passing generation, it’s inevitable … more

Google Play Developer Distribution Agreement Due Tomorrow

Every once in a while, Google updates theGoogle PlayDeveloper Distribution … more
Post Reply

How Can Rooting Your Phone Alone Permanently Brick It?

OP ableright

8th April 2014, 06:12 AM   |  #21  
Senior Member
Thanks Meter: 53
 
257 posts
Join Date:Joined: Jul 2007
More
Quote:
Originally Posted by ableright

I get your point on that lol I just wish I had a definitive answer on whether or not a software issue alone on android can permanently brick your phone in suck a way that you can't fix it and how scientifically that's possible as I find this interesting!

As a PC tech, I have supported units where a BIOS firmware glitch permanently threatened the life of the pc. Some were corrected with chip / board replacement & for others, whole PC replacement was the most practical solution.

To expand on the earlier BIOS. analogy, let's focus it on the eeprom chip. We know by its name it is designed to be electrically eraseable & programable to keep the PC's POST & bootstrap code accessible. It is writeable media that can be made unusable in certain events.

Since BIOS eeprom useability depends on a correct set of firmware code, when some inappropriate code is inserted (like a scrambled power on password or some other damaged code), recovery options can be limited, often requiring specialzed single-purpose hardware to regain access. A "bad flash" where voltage is mishandled forms the bridge between software & hardware damage here.

The POSTing & bootstrapping in Android passes from CPU to nand flash media with generally similar dependencies & vulnerabilities to PC BIOS firmware. Namely, nand must present to the cpu a read/writeable partition containing the undamaged bootloader ready for execution.

It was correctly stated that rooting only enables the superuser and adds a binary. Just like with the PC the stakes are much higher when flashing is the method involved. I guess any true danger of bricking is not in the security changes rooting applies, but relates more to the risks & requirements of safe flashing in the process used.
9th April 2014, 10:44 AM   |  #22  
OP Junior Member
Thanks Meter: 0
 
26 posts
Join Date:Joined: Apr 2014
Quote:
Originally Posted by pc103

As a PC tech, I have supported units where a BIOS firmware glitch permanently threatened the life of the pc. Some were corrected with chip / board replacement & for others, whole PC replacement was the most practical solution.

To expand on the earlier BIOS. analogy, let's focus it on the eeprom chip. We know by its name it is designed to be electrically eraseable & programable to keep the PC's POST & bootstrap code accessible. It is writeable media that can be made unusable in certain events.

Since BIOS eeprom useability depends on a correct set of firmware code, when some inappropriate code is inserted (like a scrambled power on password or some other damaged code), recovery options can be limited, often requiring specialzed single-purpose hardware to regain access. A "bad flash" where voltage is mishandled forms the bridge between software & hardware damage here.

The POSTing & bootstrapping in Android passes from CPU to nand flash media with generally similar dependencies & vulnerabilities to PC BIOS firmware. Namely, nand must present to the cpu a read/writeable partition containing the undamaged bootloader ready for execution.

It was correctly stated that rooting only enables the superuser and adds a binary. Just like with the PC the stakes are much higher when flashing is the method involved. I guess any true danger of bricking is not in the security changes rooting applies, but relates more to the risks & requirements of safe flashing in the process used.


So what you're saying is that in these very rare circumstances hardware damage can actually occur?
9th April 2014, 10:54 AM   |  #23  
Junior Member
Thanks Meter: 8
 
25 posts
Join Date:Joined: Apr 2014
More
Quote:
Originally Posted by ableright

So what you're saying is that in these very rare circumstances hardware damage can actually occur?

I think, a real hardware damage is extremely unlikely.

But you can manage to overwrite the piece of software thats responsible of flashing software to the NAND. If you manage to do that, you'll need special tools to access the NAND (~~ EEPROM of the PC) and put in the original software (bootloader) there.

There are hardware mods to make some phones unbrickable, these work by changing the boot order of the phone processor. This is like making the phone boot from a usb flashdrive (which is in those case a pc connected using usb...).

In normal cases the phone will *always* boot from it's internal NAND, and if you destroy the bootloader, you'll need specific knowledge and tools.


(but: when everything is done right, the bootloader is not touched by rooting).
9th April 2014, 03:41 PM   |  #24  
Senior Member
Thanks Meter: 53
 
257 posts
Join Date:Joined: Jul 2007
More
The potential useability risks are contained in flash methodology.

Short of recklessness however, worst outcomes are rare.

If the storage media (nand) where the cpu bootstrapper code seeks the bootloader is rendered corrupt / unwriteable / inaccessible during a bad flash, one might say software procedures damaged the hardware.

It's theoretical. With due diligence, the risk factor is minor.
9th April 2014, 08:46 PM   |  #25  
OP Junior Member
Thanks Meter: 0
 
26 posts
Join Date:Joined: Apr 2014
Quote:
Originally Posted by DThought

I think, a real hardware damage is extremely unlikely.

But you can manage to overwrite the piece of software thats responsible of flashing software to the NAND. If you manage to do that, you'll need special tools to access the NAND (~~ EEPROM of the PC) and put in the original software (bootloader) there.

There are hardware mods to make some phones unbrickable, these work by changing the boot order of the phone processor. This is like making the phone boot from a usb flashdrive (which is in those case a pc connected using usb...).

In normal cases the phone will *always* boot from it's internal NAND, and if you destroy the bootloader, you'll need specific knowledge and tools.


(but: when everything is done right, the bootloader is not touched by rooting).

On windows though you can just replace replace the Master Boot Record At anytime with the stock one from a Live CD and that I've never seen not work to be honest!
9th April 2014, 09:05 PM   |  #26  
Senior Member
Thanks Meter: 53
 
257 posts
Join Date:Joined: Jul 2007
More
Quote:
Originally Posted by ableright

On windows though you can just replace replace the Master Boot Record At anytime with the stock one from a Live CD and that I've never seen not work to be honest!

Rewriting a PC's MBR is not an accurate comparison. The system disk's MBR is only a dependency for the OS' boot code. A PC with a corrupted BIOS that can't POST and can't bootstrap any OS more accurately resembles a bricked Android device.
10th April 2014, 12:28 AM   |  #27  
demkantor's Avatar
XDA: ASSIST
Recognized Contributor
Flag mpls
Thanks Meter: 2,867
 
5,979 posts
Join Date:Joined: Nov 2011
More
OK let's be clear, every android device is different and none can become a brick by the act of rooting in itself.
When an android device is bricked, be it by hardware or firmware fault it is unrecoverable. Most of the time that someone says they bricked their phone it is just in a bootloop because they erased their os or did something they don't understand etc. But these are not bricks as they device is often easily recoverable.
Now there are times when it isn't, and not just due to a hardware fault but from firmware (bootloader, radio, etc) which may have been the wrong image flashed, or flashed to the wrong partition or incomplete, whatever. This can lead to a brick, but this isn't the act of rooting that bricked it it was a mistake made by the user
Some devices even have a special download mode of sorts that allow you to fix this without JTAG, in this case it isn't truly bricked either, rather they still can use a fail safe to fix it, often rather easily.
On one of my devices a long time back I was wanting to play around with my own custom bootloaders, but prior to this I sent the phone to adam Outler (as I was uncomfortable doing the ultra fine soldering myself) and with a hardware mod changed the boot sequence which if I hadn't done this, during my many failed attempts, I could not have even accessed the download mode to fix my brick
Some people will insist that they did nothing wrong while rooting yet still got a brick. But again all devices differ as does the root method, sometimes they mistype a dd command and flash a recovery image to the radio or whatever, this wasn't root or the act of rooting that bricked their phone, it was their carelessness, or at least not understanding what they are doing when they do a battery pull while flashing firmware.
Sorry for the rant but this question has been around since the g1 days and the answer is still unequivocally no, the act of rooting itself can not brick your phone.

Sent from my Nexus 4 using XDA Premium 4 mobile app

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Top Threads in Android Q&A, Help & Troubleshooting by ThreadRank