Posted
by
CmdrTacoon Thursday July 15, 2010 @09:55AM
from the now-that's-evil dept.

An anonymous reader writes with some discouraging news for hack-oriented purchasers of the new Droid X phone: "If the eFuse fails to verify [the firmware information (what we call ROMS), the kernel information, and the bootloader version], then the eFuse receives a command to 'blow the fuse' or 'trip the fuse.' This results in the booting process becoming corrupted, followed by a permanent bricking of the phone. This FailSafe is activated anytime the bootloader is tampered with or any of the above three parts of the phone has been tampered with."

No, just an excuse to stay away from the Droid X. The Droid line has a number of phones from different manufacturers that make it. The original Droid and Droid X are made by Motorola while the Droid Incredible is made by HTC. Only the Droid X (so far) suffers from this problem that will likely have a way around it soon enough.

TFA doesn't explain what an "eFuse" is, but if it's anything like an actual fuse, then shorting it should be easy enough.

If you follow the link in the story to here [mydroidworld.com], it says:

The eFuse is coded with information that it either looks for or is passed to it from the bootloader. The bootloader is loaded with information it looks for when it begins the boot-up process. (I have seen the sbf file look for a certain bootloader when it begins so its safe to assume that this is the process).

Once the the eFuse verifies that the information it is looking for or that has been passed through to it by the bootloader is correct then the boot process continues. What type of information is written to the bootloader? So far i've been able to verify that the firmware information (what we call ROMS), the kernel information, and the bootloader version.

If the eFuse failes to verify this information then the eFuse receives a command to "blow the fuse" or "trip the fuse". This results in the booting process becoming corrupted and resulting in a permanent bricking of the Phone. This FailSafe is activated anytime the bootloader is tampered with or any of the above three parts of the phone has been tampered with.

Basically, they've added trusted computing to a phone.

The eFuse is the gatekeeper -- if it detects that you've done something they haven't approved, it causes the phone to self destruct.

http://en.wikipedia.org/wiki/EFUSE [wikipedia.org] "By utilizing an eFUSE (or more realistically, a number of individual eFUSEs), a chip manufacturer can allow for the circuits on a chip to change while it is in operation."

I understand how someone can decide not to officially support modding since that could translate into more costs, but actually investing time and money to prevent modding?Seriously, whats wrong with them? They are supposedly part of the Open Handset Alliance.

Hey moto, most people actually want to run other andriod "mods" (such as cyanogenmod) in order to have the latest and greatest android version, since you guys are obviously too uninterested in keeping your own phones updated. Most of them don't actually care about platform development.

I hope you realize you should actually support - at least not make it difficult to - flash alternate operating systems. Providing an unlocked bootloader is a big first step which should be almost cost-free to do and can IMHO only bring you benefits. (Ever heard of the Nexus One's "oem unlock" command?)

Its designed obsolescence. I learned this the hard way with my Samsung behold II, Samsung wants you to buy a new phone, and tries hard to lock you out of self updates so that the only option you have is to buy a new piece of hardware. The market has designed itself in such a way that its business model is dependent on people buying a new device every 2 years. If they let you openly hack your phone they cut into their bottom line. Hopefully the new players like HTC that are a bit more open will help change the marketplace.

"Written in JTAG" implies a program written in a language called JTAG.

The problem is that JTAG is a standardized electrical communications protocol used to support debugging of ICs, and often also used to program them.

Nothing can be "written in JTAG" because it isn't a programming language. I question whether the poster on that forum has any clue what's really going on. So far the only evidence of this is one forum post that has very little detail and has some glaring technical/grammatical errors (see above). I'll believe it when I see a more in-depth analysis.

To be fair, OS X doesn't implode if you recompile the bootloader, which is open source under Darwin. You can either download apps for OS X (many free), make your own using Apple-supplied tools (XCode), third-party paid tools (why?), or use free-as-in-speech-and-beer OSS tools.

This can be done in any combination of interfaces, from CLI and X11 to Cocoa and Carbon.

None of this, or even (to make an accurate analogy) installing Windows or Linux on your Mac, is going to make the Mac go boom. In fact, if you buy the system and install the exact same Linux distro as you did on your IBM or Compaq... it'd work.

It's not even clear if this information is real. TFA [mobilecrunch.com] links to a forum post [mydroidworld.com] which doesn't seem to actually contain a source of the information (the OP states it's a mix of "hard information" and "conjecture"). Said forum post then links to the eFUSE wikipedia [wikipedia.org] article, which lists Droid X as having an implementation of eFUSE. However, if you look at the Droid X wikipedia page linked to from there, you'll see the original mobilecrunch.com is what is cited for the eFUSE inclusion bit.

I'm not saying there is something fishy going on, but this could easily not be true.

You can thank Motorola for this gaff, not Verizon.
Motorola Bootloader Lockdown Explained [androidcentral.com]
It seems that, since the Droid X is using part of Motorola's code along with the Android OS, they did not want that open. Part of protecting their IP I suppose.

The Droid moniker is licensed by Verizon from Lucas Arts. It is used for Android phones on the Verizon network, including those produced by Motorola (Droid, Droid X) and HTC (Droid Eris, Droid Incredible)

We understand there is a community of developers interested in going beyond Android application development and experimenting with Android system development and re-flashing phones. For these developers, we highly recommend obtaining either a Google ADP1 developer phone or a Nexus One, both of which are intended for these purposes. At this time, Motorola Android-based handsets are intended for use by consumers and Android application developers, and we have currently chosen not to go into the business of providing fully unlocked developer phones.

The use of open source software, such as the Linux kernel or the Android platform, in a consumer device does not require the handset running such software to be open for re-flashing. We comply with the licenses, including GPLv2, for each of the open source packages in our handsets. We post appropriate notices as part of the legal information on the handset and post source code, where required, at http://opensource.motorola.com./ [opensource.motorola.com] Securing the software on our handsets, thereby preventing a non-Motorola ROM image from being loaded, has been our common practice for many years. This practice is driven by a number of different business factors. When we do deviate from our normal practice, such as we did with the DROID, there is a specific business reason for doing so. We understand this can result in some confusion, and apologize for any frustration.

You basically have a software programmable 2-watt transmitter that can easily stomp over lots of spectrum if some clown mucks about with its code. This is also the reason there is a semi-retarded "AT" interface to the phone on most devices doing the call placement etc. The code that actually connects to towers, does the signaling etc is well programmed, fairly well tested by the FCC for compliance and then locked up out of harms way with a simple API.

This gives you a robust phone that plays nicely with others instead of (god forbid) a Windows Mobile device having to manipulate the air interface directly.

is that Verizon will be the first one out of the gate with Block C 700MHz LTE service -- which will put them on the spot: they are *required by the terms of the license* -- thanks, Google -- to allow any device that meets their published tech specs to connect to that network.

So if the do this to their handsets for LTE700, then they'll just lose sales *directly*.

eFUSE can be used to change chip logic on the fly based on the operation,, or, as Motorola is using, can be used to modify the programming of the chip itself to render the device nonfunctional without a reflash.

If you could figure out the necessary code to flash to the chip - which wouldn't be easy - yeah, you could reflash the chip via the JTAG port.

Given that HTC and others aren't locking the phones down in a method where the phone deliberately tries to use a device to brick if the phone's firmware/kernel/bootloader is not official, crackers are more likely to ignore the phone. And given the publicity ("Motorola phones have chip that self destructs"), ordinary consumers could be scared off too.

Baseband firmware's separate from Android. Nobody else locks it down like that, and if Moto was so worried about fiddling with the baseband, then burn it into an non-writable ROM chip. The eFuse is watching for any modifications to the OS Kernel and Bootloader, the "computer bits."

If you wanted to be pedantic, it should be "written in BSDL" as that is the language in which you directly control JTAG. Many people that have used JTAG wouldn't care about the distinction. And yes you can write code in BSDL to control JTAG. It sucks (I know from experience), but it can be done.

In most Qualcomm processors (The MSM series used in most smartphones/PDA phones), there are dual ARM cores. This isn't a "dual core" system in the traditional sense, the cores are NOT identical and one is designed to handle radio functions and one is designed to handle application functions. On every phone I've seen, the radio is very well protected and the application side far less so. (Which is why, for example, WinMo phones tend to be "SuperCID" unlocked long before they get SIM-unlocked.) The dual-CPU nature makes this kind of protection approach (one side heavily protected, one far less so) much easier than trying to protect only certain code within a single CPU.

However, the Droid X apparently uses a TI OMAP. I'm not sure if these have the same dual-core architecture that the Qualcomm MSMs do. For this reason it may be much harder to be confident about locking down the radio side to enforce SIMlocks and FCC rules without locking down the application side too.

That's actually pretty much even with other smartphones in its class. The trouble is, most carriers(at least in the US); subsidize handsets but don't offer less expensive plans to those who BYO hardware...

If there were a "zOMG Free Phone* *(with $$$$/month contract)" option and a "Pay full retail phone price, or bring your own, $$/month for voice/data" option, the American preference for crippled carrier phones would be an example of the "stupid consumers, only looking at upfront costs" phenomenon. As it is, though, you pretty much choose between getting a subsidized phone, then having the subsidy(and some extra) gouged out month by month, or you pay full price, and then face exactly the same monthly costs. This adds up to paying a fairly major premium to purchase your own device.

Think a better analogy would be "you replace the ECU and a couple of chunks of thermite set off and cut through your engine, transmission, weld your differential and compromise the temper of the frame. Completely disabling the car and costing your more than the price of the vehicle to repair it.

In fact the "eFUSE" feature is present in a staggeringly common component [stevenbird.info] in many different Android (and other...) devices, so the presence of an eFUSE is not in any way demonstrative of the functionality claimed.

The use of open source software, such as the Linux kernel or the Android platform, in a consumer device does not require the handset running such software to be open for re-flashing. We comply with the licenses, including GPLv2, for each of the open source packages in our handsets.

(my emphasis)

This is exactly the sort of thing GPLv3 was intended to circumvent. Whether that's because the FSF foresaw a future where there were so many locked down devices that most people simply wouldn't buy a general purpose PC any more or because they simply thought it was a bit disingenuous to provide source but no way of running the compiled code is another matter altogether.

Apparently this is blown out of proportion:
http://www.boygeniusreport.com/2010/07/15/reality-check-modding-the-droid-x-may-not-lead-to-a-bricked-phone/ [boygeniusreport.com]
"This breaking news may not be as dire as many are claiming, as a google search of OMAP3 and e-fuse reveals that current OMPA handset already have e-fuse in place as part of the M-Shield hardware security technology built into TI’s OMAP system on a chip. It is on the very hackable DROID and the not-so-hacking-friendly Milestone, but it is not being used by Motorola to lock the bootloader of the handset. "
etc...

That particular quotation was taken directly from here [mydroidworld.com].

While “trip” is not the correct word to use in correlation to a fuse, this isn’t really a fuse [wikipedia.org] – it’s on-chip circuitry:

If certain sub-systems fail, or are taking too long to respond, or are consuming too much power, the chip can instantly change its behavior by 'blowing' an eFUSE. This process does not physically destroy the eFUSE, so it is reversible and repeatable, using JTAG programming.

As such (IMHO, at least), “trip” actually does seem to be a fairly acceptable word for this action.

In case you hadn't noticed, this is a technology site where a large number of people are dedicated to "fucking with stupid shit" on a regular basis. So talking about modding your phone is kind of right up the proverbial alley here...

Is all the GPL code in Android under such a version of GPL, that this is legal? I mean, it prevents the user from changing certain parts of the GPL software, something which at least some versions of GPL require, as far as I understand.

GPLv2 only requires that you give out source to the GPLed components that you use (as well as any modifications); it doesn't require that the source actually be usable.

This process has become known as TiVoization, after TiVo, who locks things down in a similar way.

This endaround the GPL is one of the main reasons that GPLv3 was created; what Motorola is doing here is not legal with GPLv3 code (note that the Linux kernel is, and probably always will be, GPLv2...).

There's a reason AT&T lost their little lawsuit over the "There's a Map For That" ad campaign that Verizon ran.There's a reason I don't use AT&T, Sprint, and T-Mobile- I use the "slower" 3G in more places than the others offer.

Since that's the case, I can't very well use an OpenMoko phone until someone makes a CDMA one and then Verizon decides to honor their publicly stated commitment for an "Open Network" that allows me to bring that phone over to their network. I can't as readily take the access hit for the things I do with the phone and go to another network that I could use an OpenMoko phone on.

Changing base boot and operating software would be like swapping the engine (or ECU) from a BMW into a Toyota and expecting the manufacturer to honor the warranty.

Actually, they do. Or they have to be able to prove that the modification is what caused the problem.

For example, I have a third-party ECU in my Audi. If I have a problem with, say, the suspension, Audi would have to prove that the ECU modifications were the cause of my suspension problems. It's not up to me to prove that they weren't.

Not true. When you buy the phone, liquidated damages (something called an "Early Termination Fee") gets tacked on if you don't complete the contract. It's your property the moment the credit card gets swiped through the reader or the cash goes in the register.

By law, if you request that your phone's SIM-lock (if GSM) be removed, or that you be given its MSL code (if it's CDMA), the phone company MUST give it to you as long as 30 days have elapsed since purchase. I'm not 100% sure, but I think even the 30-day waiting period can be eliminated if you waive your right to cancel the plan or return the phone.

American phone companies (at least Verizon and AT&T by virtue of being AT&T's offspring) aren't allowed to keep the phones as secured assets or lease them due to the consent decree that broke up AT&T's monopoly 25 years ago that prohibited them from forcing customers to lease phones instead of purchase them from independent sources on their own. I'm not sure, but I think the FCC incorporated its terms directly into its own regulations, so they probably apply to Sprint & T-Mobile as well. On the other hand, that might be the reason why Verizon was grudgingly forced to open its network to any phone you can physically figure out how to make work, while Sprint can get away with refusing to let anyone use any phone not purchased from Sprint.

I believe the first cell phone companies tried to lease phones to customers, but were prohibited from doing so by the FCC out of concern that if carriers were allowed to lease phones, the price of purchased phones would be wildly inflated and customers would be forced into leasing anyway. As a practical matter, subsidies turned out the same way (in the US, at least, though Google's fought the hard fight to at least try and change it a little).

Because in America, an Openmoko is a nearly-useless GPRS paperweight. Ditto for Trolltech GreenPhone, and every other "open" phone. They couldn't do EDGE (in the US, lack of EDGE is a nearly automatic deal-breaker, because even today, few AT&T or T-Mobile customers can truly depend on UMTS working everywhere they go), let alone 1700/2100 or 850/1900 UMTS. IMHO, it's a major reason those phones have all largely failed.

Their argument that they were "development" phones not intended for real use was stupid. Very, very few businesses are going to buy a relatively expensive phone for pure abstract "development", and no slightly geeky elite user is going to spend that much money on a phone that's borderline useless as a phone ready to be tweaked, extended, and made MORE cool.

The US isn't the entire world market, but it's a big, important chunk of it, and any project that effectively writes it off completely is probably doomed from birth. The same is probably true of any American project that completely ignores Europe. Just look at Palm -- they released the Pre for Sprint while the rest of the world was literally begging for it. At the VERY least, they should have released a 1900/2100 UMTS Pre simultaneously with the CDMA Pre. Someday, companies in the US and Europe will realize that it's worth making at least a half-assed effort to ensure that anything that works in one place will at least have a chance of working in the other, because it's cheaper to spend a little more and end up with one device that works in both places than two devices that can independently flop and leave the vendor with useless, expensive inventory.

Google was smart -- they made sure the Nexus one would work fully in both Europe AND the US. Admittedly, T-Mobile wasn't the greatest choice of American networks, but their only real alternative would have been to have released it with 850MHz support from the start (frankly, I'm shocked they didn't), or go with a (still slightly experimental, apparently) tri-mode chipset capable of GSM800/900/1800/1900, UMTS850/1700/1900/2100, and CDMA2000@800/1800/1900 so it would work on Verizon & CDMA carriers in Latin America, Australia, New Zealand, Korea, and China.