[BOOTLOADER] Locked bootloader research and news [Updated: 7/16/2012]

tehh4ck3r · Jul 8, 2012

AdamLange said:
AFAIK you can get for example AT&T/sprint/tmo version without simlock from someone. Or get international version of SGSe (i9300)

None of those would work on verizon's network

neyenlives · Jul 8, 2012

Every one of the US versions, Sprint, ATT, TMobile, Verizon all have different hardware radio inside. So a Sprint phone works on Sprint only, Verizon on Verizon only, TMobile on TMobile only, ATT on ATT only. We shop by service first, hardware second. That's mainly because none of the networks work with each other. LTE on ATT is not the same as LTE on Verizon. 4G on TMobile is not the same as 4G on Sprint. Even though they sometimes use similar frequencies, they use different hardware on the towers and in the devices.

tekhna · Jul 8, 2012

jamesnmandy said:
Every one of the US versions, Sprint, ATT, TMobile, Verizon all have different hardware radio inside. So a Sprint phone works on Sprint only, Verizon on Verizon only, TMobile on TMobile only, ATT on ATT only. We shop by service first, hardware second. That's mainly because none of the networks work with each other. LTE on ATT is not the same as LTE on Verizon. 4G on TMobile is not the same as 4G on Sprint. Even though they sometimes use similar frequencies, they use different hardware on the towers and in the devices.

Stupidest system ever. Kill the carrier subsidy model.

ooofest · Jul 8, 2012

AdamLange said:
So the sprint version of phone should be compatible with VZN network. Its now just a simlock problem - em i right?

Maybe not:

. . . there are some technical reasons for why AT&T's and Verizon's LTE networks are incompatible with each other and every other wireless carrier in the world. Some operators use completely different spectrum frequencies for their LTE service. For example, AT&T and Verizon are using 700 MHz spectrum, while Sprint is using 1900 MHz and some 800 MHz spectrum. That's why those networks are incompatible, even though the underlying technology is the same.

. . . the 700 MHz chunk of spectrum was split into two parts, an upper portion and a lower portion. And because of interference issues, different band plans were adopted for the spectrum, making it so the two portions couldn't interoperate.

Verizon got a nationwide license in the upper C block. That's what it's using to provide its 700 MHz spectrum. AT&T bought smaller licenses in the lower portion of the 700 MHz band.

. . .

Berry, who sat down to chat with me in an interview this week, believes AT&T and Verizon have cleverly engineered their networks and the spectrum they are using to ensure that they don't have to provide this interoperability. But the FCC could figure out a way to get all wireless carriers using the 700 MHz band on the same page, he said, eventually there could be interoperability across the entire band.

- ooofest

neyenlives · Jul 8, 2012

tekhna said:
Stupidest system ever. Kill the carrier subsidy model.

I have no problem with it because all the other carriers have crap service compared to Verizon. I would not want a bunch of customers from Sprint bogging down the Verizon network because Sprint has not invested in their network.

Service comes first. Hardware second. As it should be. It does me no good to get a wonderful handset like the HTC EVO 4G if the network is garbage.

tekhna · Jul 8, 2012

jamesnmandy said:
I have no problem with it because all the other carriers have crap service compared to Verizon. I would not want a bunch of customers from Sprint bogging down the Verizon network because Sprint has not invested in their network.

Service comes first. Hardware second. As it should be. It does me no good to get a wonderful handset like the HTC EVO 4G if the network is garbage.

The carrier-subsidy model is anti-competitive because it forces consumers into long-term contracts. In places without the carrier-subsidy model prices are lower, networks tend to be higher quality, and consumers can truly vote with their dollars. You'd see better networks in the US in general if we got rid of this nonsense.

neyenlives · Jul 8, 2012

tekhna said:
The carrier-subsidy model is anti-competitive because it forces consumers into long-term contracts. In places without the carrier-subsidy model prices are lower, networks tend to be higher quality, and consumers can truly vote with their dollars. You'd see better networks in the US in general if we got rid of this nonsense.

I don't see the problem. I have been renewing my Verizon contract, every two years, for 10 years or so now. In exchange for that they have built the largest and fastest LTE network around. I get crazy stupid speeds everywhere I go and because I have been with them all along I got to keep my unlimited data. I get better reception than all the other carriers everywhere I go. I get a 24% discount from my employer as well. They also have one of the best device selections. The Razr Maxx and GSIII to name two which I own. If the only thing I have to give up is a locked bootloader on the GSIII, I'm fine with that.

We are now off topic a bit much so lets get back to locked bootloader discussion.

tekhna · Jul 8, 2012

jamesnmandy said:
I don't see the problem. I have been renewing my Verizon contract, every two years, for 10 years or so now. In exchange for that they have built the largest and fastest LTE network around. I get crazy stupid speeds everywhere I go and because I have been with them all along I got to keep my unlimited data. I get better reception than all the other carriers everywhere I go. I get a 24% discount from my employer as well. They also have one of the best device selections. The Razr Maxx and GSIII to name two which I own. If the only thing I have to give up is a locked bootloader on the GSIII, I'm fine with that.

We are now off topic a bit much so lets get back to locked bootloader discussion.

Heh, this isn't off-topic--the carrier subsidy model is what allows them to lock bootloaders.

neh4pres · Jul 8, 2012

AdamLange said:
OK, so as far as the specs data are accurate the SPRINT's version of SGS3 covers THE SAME network ranges/types as VZN ones.

Cellular_Networks: CDMA800 (BC0), CDMA1900 (BC14)
Cellular-Data+Links: cdmaOne, CDMA2000 1xRTT, CDMA2000 1xEV-DO Rel. 0, CDMA2000 1xEV-DO Rev A

So unlocked sprint's version (without simlock) + the VZN card should do the job

u will get the unlocked bootloader and still using VZN services

Verizon uses the 700mHz band for their gsm lte.. 800mhz for cdma voice.. and 1900mhz cdma 3g

Sent from my SCH-I535 using xda premium

BeansTown106 · Jul 8, 2012

could be a good chance we can use our old trusty "bootmenu" from the droid x and modify it in a way that we modify hijack to pull the bootmenu and then bootmenu would have options for reboot to cwm reboot to normal kernel and reboot to modified kernel.. if stock it would just continue boot if cwm or custom kernel it would flash that selection to recovery partition and reboot to recovery partition making u either boot to cwm or to ur custom kernel.. also it would have a default setting option for u to choose wether it be custom or normal kernel so u dont always have to use it while booting.. this is just me and wizard0f0s brainstorming but to me it makes perfect sense.. now i just need my phone to come in so i can play guinny pig on this whole thing

basically between this and the possibility of kexec working too we have options and im pretty much sure at this point we will be flashing custom kernels.. slim slim chance we wont be but imho way higher of a chance of a workaround

jgrimberg1979 · Jul 8, 2012

AdamLange said:
Because of? they are incompatible with anything?

so you cant just buy a phone from a shop and use VZN simcard in it? thats weird. And they still got clients?

@jamesnmandy: i got a weird feeling that youre somehow connected to VZN ...

No ****, I got the same feeling.. Sounds like your in bed with Verizon

jmacko · Jul 8, 2012

Is this of any help? (On further review, it's the MSM8660, not the MSM8960 we have.) I'll keep looking....

From: http://www.anyclub.org/2012/05/how-to-enabledisable-secure-boot.html

And perhaps:
http://www.anyclub.org/2012/05/qpst-emergency-download-support.html

Maybe someone over there, that knows the SOC better (or has the SOC documentation) might be able to collaborate to understand how to work around our issues, or at least point out the most efficient attack vector.

neyenlives · Jul 8, 2012

jgrimberg1979 said:
No ****, I got the same feeling.. Sounds like your in bed with Verizon

sorry, just very happy with my service......and have been using a Charge forever that never got any CM/AOSP love either, so I have seen what is possible as long as you have root, debloat and custom Touchwiz based roms...and it is good. Not as good as CM/AOSP granted like on the Fascainte, but still not a deal breaker all things considered.

BeansTown106 · Jul 8, 2012

jmacko said:
Is this of any help?

From: http://www.anyclub.org/2012/05/how-to-enabledisable-secure-boot.html

How to enable/disable the secure boot authentication feature on MSM8660 by using the JTAG
Notes: This solution does not apply all version MSM8660

This solution does not apply to the RPM JTAG disable cases

This solution only uses for debug purpose.

For some reasons, if you need to to run unsigned software on a secure boot enabled (the AUTH_EN bit in SECURE_BOOT1 register is blown) MSM8660 chip, the following instruction is able to disable the secure boot authentication by using RPM-JTAG.

1. Launch the Daisy Chain RPM-JTAG shortcut (i.e modem_proc\tools\t32\DC7_ARM7_RPM).

2. Execute the cmm script which contain the following command:

system.option resbreak on
system.up
g 0x7ce8 /o /cmd "r.s r0 0x0" ;0x0 for disabling the secure boot authentication
wait 1ms
g

Of course, you can simply modify the cmm script (listed below) to enable the secure boot authentication without blowing SECURE_BOOT1 register on MSM8660 chip by using RPM-JTAG or short the GPIO_76 pin.

system.option resbreak on
system.up
g 0x7ce8 /o /cmd "r.s r0 0x1" ;0x1 for enabling the secure boot authentication
wait 1ms
g

And perhaps:
http://www.anyclub.org/2012/05/qpst-emergency-download-support.html

Maybe someone over there, that knows the SOC better (or has the SOC documentation) might be able to collaborate to understand how to work around our issues, or at least point out the most efficient attack vector.

if thats the snapdragon s4 then i'd assume so.. we might just have 3 options now.. granted this would be the best as it would just be like having an unlocked phone

Imatoasta · Jul 8, 2012

Maybe this guy could help with JTAG?

http://www.youtube.com/watch?v=XnA8Djs55Ds

ooofest · Jul 8, 2012

tekhna said:
Heh, this isn't off-topic--the carrier subsidy model is what allows them to lock bootloaders.

This.

Fewer providers and proprietary networks means they easily lock us into whatever they decide to charge and provide. Plus, we get the added limitation (for LTE) that phones are only "investments" within the same provider network - again, we're locked into their proprietary scheme. Sounds like Apple products.

It used to be that we rented phones from Ma Bell. Times have changed for landlines, but we're doing much of it all over x100 for wireless networks, IMHO.

- ooofest

preusstang · Jul 8, 2012

beanstown106 said:
could be a good chance we can use our old trusty "bootmenu" from the droid x and modify it in a way that we modify hijack to pull the bootmenu and then bootmenu would have options for reboot to cwm reboot to normal kernel and reboot to modified kernel.. if stock it would just continue boot if cwm or custom kernel it would flash that selection to recovery partition and reboot to recovery partition making u either boot to cwm or to ur custom kernel.. also it would have a default setting option for u to choose wether it be custom or normal kernel so u dont always have to use it while booting.. this is just me and wizard0f0s brainstorming but to me it makes perfect sense.. now i just need my phone to come in so i can play guinny pig on this whole thing

basically between this and the possibility of kexec working too we have options and im pretty much sure at this point we will be flashing custom kernels.. slim slim chance we wont be but imho way higher of a chance of a workaround

Hells yes! Beans and wizard are now on the bandwagon! In case you guys don't know they've worked magic with MIUI and more on the DX. I'm so glad you guys are jumping ship with me. Can't wait for Fedex tomorrow!

Sent from wizards MIUI on DX.

Quize · Jul 8, 2012

Let me just preface this post with I am not a rom developer, so some of the assumptions listed below might not be correct. It is just based on my understanding of what I have researched so far. Also, this information is based off of the secure boot feature in the MSM7XXX chipset, but I don't think the procedures/sequences should differ too much. If someone has a way to analyze which qfuses are blown, I think it might help greatly in finding a way to get around the signed boot loader.

Qualcomm secure booting sequence on an MSM7XXX phone

From the now-deleted QC BQS Analyzer: Booting Sequence Explained

1. QBL (OTP)------------Check of QCSBL header and Config Bits (30 Bit) -> Value hardcoded (Func at FFFF0674)
Load of QCSBL header and Config Bits (Func at FFFF0396)
Check of PBL (SHA1) -> Value hardcoded (Func at FFFF03A0)
Load of PBL (Func at FFFF0260), Entrypoint : 0x0, with given QCSBL Header

2. PBL -------Check of QCSBL (SHA1 + RSA-2048-SHA1 Signature Decryption from QCSBL) (Func at 0xBC)
Load of QCSBL (Func at 0x2FC), Entrypoint : 0x02D4C01C

3. QCSBL--------Check of OEMSBL (SHA1 + RSA-2048-SHA1 Signature Decryption from OEMSBL) (Func at 02D4C118)
Init of OEMSBL (Func at 0x2D4C2A0), Entrypoint : 0x02D9C354
Loading of OEMSBL (Func not yet found)
Check of AMSS (SHA1 + RSA-2048-SHA1 Signature Decryption from AMSS)(Func at 02D4C15C)
Loading of AMSS (Func at 0x02D4C060), Entrypoint : 0x0]

An explanation of what qfuses are

Qfuses

Qfuses are one-time-programmable (OTP) elements that are used to enable and disable security and debug features of the MSM7xxx device. The Qfuses are implemented as anarray of one-bit fuse blocks. The Qfuse banks are used for two purposes — providing non-volatile, immutable storage of data, and configuration of hardware features. For immutabledata storage, the Qfuses are read via a shadow register which contains the actual valuestored and includes error correction.For configuration, each Qfuse is associated with a one-time write register. The value of each Qfuse is sensed at powerup and stored in a register. Blowing Qfuses is done byplacing a value to a register and applying current to the fuse. The fuse registers areaccessible through JTAG and software readable address locations.

How to blow the qfuses

Qfuse Programming

To blow a fuse a number of steps must be completed.
1. Apply the proper voltage to the VDD_EFUSE pin, typically 2.9 +/- 0.1 V.
2. Select the proper fuse chain with the EF_CHAIN_SEL register.
3. When you blow the first fuse in a chain, put a 0x1 in the EF_BLOW_VALUE register.Otherwise make this register 0x0. For each subsequent fuse to be blown in the samechain, you will be shifting the '1' in the e-fuse chain to the next fuse to be blown.
4. Program the EF_SHIFT_VAL to shift the '1' to the proper fuse.
Name Type Description
BOOT_SCUR Input pin If this pin (GPIO 95) is enabled (high), it forces the SBL or anysubsequent code to be authenticated for security. This pinfunction is available only if FORCED_TRUSTED_BOOT fuseis not blown, otherwise it is used as a GPIO.
5. Set the EF_BLOW_TIMER to the correct value, typical blow times are 10 µs. Thetimer is the number of clock cycles the current will be applied to the fuse. The clock isTCXO, typically 19.2 MHz.6. Write a 0x0 and then a 0x1 to the EF_STATUS register. This starts the blow fuseshardware state machine.7. Poll bit 1 in the EF_STATUS register. When it is a '1', the fuse has been blown.8. Finally, when all of the desired fuses are blown, the chip must be reset (power-onreset) so that the fuses values can be sensed

Qualcomms secure boot configuration which is enabled our phones

Secure boot configuration
The MSM7xxx device can be configured to boot in secure mode using the BOOT_SCUR pin or the FORCE_TRUSTED_BOOT Qfuse.

■The BOOT_SCUR pin (N5) determines the boot mode of the MSM7xxx IC. TheMSM7xxx IC can be booted in secure mode and it then follows the boot processdescribed in the previous section. If the device is booted in non-secure mode,authentication of the boot code is not performed.The MSM7xxx IC is booted in non-secure mode when BOOT_SCUR = 0. When theBOOT_SCUR pin is pulled to high (BOOT_SCUR = 1) then the MSM IC is booted insecure mode and all subsequent code is authenticated. This configuration is only validwhen the FORCE_TRUSTED_BOOT Qfuse is NOT BLOWN.The BOOT_SCUR pin functionality is shared with GPIO[95]. When the pin is used asBOOT_SCUR, the GPIO functionality is not available.

■The MSM7xxx IC can be configured to boot in secure mode by blowing theFORCE_TRUSTED_BOOT Qfuse. If this fuse is blown, the SBL and any subsequentcode are authenticated for security. The BOOT_SCUR pin becomes meaninglesswhen the fuse is blown and does not need to be configured for secure boot. Once theFORCE_TRUSTED_BOOT fuse is blown, the GPIO[95] is available for use.

The debug qfuse

DEBUG_EN_KEY Considerations and RMASupport
The DEBUG_EN_KEY is a customer specific key that is used to enable debug featuresthat have been disabled by blowing other Qfuses. The DEBUG_EN_KEY is a 63-bit fusechain that must be blown by customers with a unique value for their products or a uniquevalue for each of their MSM7xxx device models. Customers must take caution NOT toblow a unique value for each MSM7xxx device. Customers must keep track of the value of a key once it has been blown to enable debug features. The DEBUG_EN_KEY provides amethod to enable the debug interfaces for testing. Qualcomm will provide a secure/safeportal site to the customer, and the customer can give the debug key information(encrypted). This key is required by Qualcomm to enable debug features when performingRMA testing on any material. If the DEBUG_EN_KEY is not available, the RMAtesting cannot be performed
. Qualcomm requires the debug buses to be enabled in orderto perform testing on RMA parts from customers. Without the DEBUG_EN_KEY, RMAtesting cannot be fully performed - ATE and failure analysis (FA) test coverage will belimited. SURF testing capability will be fully available but with just SURF testing, fullanalysis cannot be performed. Please contact https://support.cdmatech.com for moreinformation regarding securely sharing the DEBUG_EN_KEY with Qualcomm forcomplete RMA testing and other questions regarding ATE, FA, and SURF test coverage

So from my understanding of this, unless someone can analyze and is willing to blow the qfuses on their phone to see what will work, we might have to wait on a signed engineering bootloader leak. Of course, that is all based on the assumption that the secure boot in MSM8960 is still similar/identical to the secure boot feature in the MSM7XXX chipsets. Like I said though this is all based on my understanding of it, so someone with more experience could see a different solution from the information above.

Sources for the info in quotes:
http://www.scribd.com/doc/51789612/80-V9038-15-APPLICATION-NOTE-MSM7XXX-QFUSES-AND-SECURITY

neyenlives · Jul 8, 2012

eorsini said:
Lol dude I WORK for VzW and idk if I could have talked like that.. He's a true believer in the service.. lol

Sent from my Galaxy Nexus using Tapatalk 2

i spent many years traveling the country with phones from every major carrier, that's how I know it's the best, that and years of watching people on other networks complain about how their service sucks.....it's not hard to see

Schaweet · Jul 8, 2012

jamesnmandy said:
i spent many years traveling the country with phones from every major carrier, that's how I know it's the best, that and years of watching people on other networks complain about how their service sucks.....it's not hard to see

This is an important thread. Let's all stay on topic pleas.

Sent from my DROIDX using xda app-developers app

[BOOTLOADER] Locked bootloader research and news [Updated: 7/16/2012]

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Inactive Recognized Developer

Senior Member

Member

Senior Member

Inactive Recognized Developer

Senior Member

Senior Member

Senior Member

Member

Senior Member

Senior Member

Similar threads

Top Liked Posts