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
AFAIK you can get for example AT&T/sprint/tmo version without simlock from someone. Or get international version of SGSe (i9300)
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.
So the sprint version of phone should be compatible with VZN network. Its now just a simlock problem - em i right?
. . . 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.
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.
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.
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
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
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.
Heh, this isn't off-topic--the carrier subsidy model is what allows them to lock bootloaders.
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
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]
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.
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
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.
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
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
Invisiblek succesfully booted to android using "adb reboot recovery" with his modified recovery.img.
Basically we made it look as if going to recovery, but actually continuing onto boot.img.
<ID:0/008> Firmware update start..
<ID:0/008> boot.img
<ID:0/008> NAND Write Start!!
<ID:0/008> FAIL! (Auth)
<ID:0/003> Firmware update start..
<ID:0/003> recovery.img
<ID:0/003> NAND Write Start!!
<ID:0/003>
<ID:0/003> Complete(Write) operation failed.
kexec -l /sdcard/kernel --reuse-cmdline --ramdisk=/sdcard/ramdisk
mount /dev/block/mmc1... /system