[Xperia Arc General] scholbert:
I know that there are many guides about unlocking bootloader and things have been posted a million times.

From what i've learned from various sources all over the web there's still a lot of confusion,

if and how a device could be unlocked and what is really happening under the hood.

In fact i didn't want to create yet another unlocking bootloader thread, but hopefully a collection of facts,

already known about the process and if it's safe or could be done this way or the other.

Another thing i'd like to put some light on, are some details about the boot process in general.

Please refer to this older thread as well:

http://xdaforums.com/showthread.php?t=1429038

Noob's posting will never end, unless we lift some secrets and make more clear how the processes are basically working.

This should as well cover some basics on how the bootloader/kernel are protected by the manufacturers.

Would be better to use the term security locked/unlocked bootloader anyway.

See this nice page (also referenced in the thread above), which describes the whole boot process on Qualcomm CPU's:

http://www.anyclub.org/2012/02/android-board-bring-up.html

You'll find a link to the original document in the 2 post.

Please prepare for some boring technical details, but as well for some essential guidelines,

how to proceed with your device. Anyway, consider this as a starter...

Enough talking, let's define some headlines or topics to be discussed.

Bootmodes and Protocols

Just to sum up three known modes residing in different stages of bootcode:

- QDL

(PBL loader, lowest level, entered by powering up without battery and testpoint pulled to GND)

- QHUSB_LOAD

(a.k.a. SEMC USB Flash, a.k.a green LED mode, entered by powering up with back button pressed)

- FASTBOOT

(a.k.a blue LED mode, entered by powering up with menu button pressed)

unlocking security vs. SIM-lock

Description:

Locked/unlocked security of the bootloader and SIM-lock are different tracks,

though there's an important dependency between them.

Your device is SIM-locked if service menu gives "bootloader unlockable: no"

or simply refuses SIM-cards from another carrier.

What we know:

- fastboot is disabled on SIM-locked phones

- without removing the SIM-lock there's no way to unlock these phones for free

- normally you may purchase SIM unlock code from your provider

- removing the SIM-lock seems to give access to the fastboot option (confirmed by gen_scheisskopf, thanks!!)

- some devices seem to have restrictions here, result: no fastboot even after removing SIM-lock (this was pointed out once in another thread)

What we need to know:

Please confirm, if bootloader unlock is working after SIM-lock is removed!

In other words will you get fastboot feature after removing SIM-lock?

See the feedback from gen_scheisskopf:

http://xdaforums.com/showpost.php?p=36783582&postcount=8

Result:

As long as you're able to remove the SIM-lock and your phone is old security you would be able to unlock bootloader as well!

old security vs. new security

Description:

Old/new security is independent of the EROM version (e.g. 1241-3656 R9B031) but relates to certain manufacturing dates,

or better the CPU types.

I got trustworthy reports about R9B031 getting unlocked with s1tool.

This date code may vary between the device models, but it seems to be proven,

that devices manufactured in Q2 2012 and later (~12W11..12W16) are new security.

I found out as well, that the manufacturing date of the device and the mainboard may be different.

This might explain why there are some diverging reports for devices in this period.

From what i got so far, the chain of trust includes the secondary bootloader (SBL) on all devices.

In other words SBL is signed code in any case.

At least the fuse setup for this feature is common on most of the Xperia 2011 series.

On a new security device patching or replacing the SBL (s1boot) will fail because OTP ROM could not be cheated.

If you got the "qcreceivepacket" error, your device is new security or at least not supported by s1tool (e.g. MSM8255T models seem not to work).

Only known method to unlock new security is Sony official method (grey market may work as well...).

What we know:

- testpoint method does not work on new security

- it should be safe to try the testpoint method because it won't break anything (if it is done correctly)

- right now there's only one way to check for new security (try and error)

- breaking new security would take ages or is impossible

What we need to know:

Perhaps someone needs to confirm that official Sony method works without flaws on new security.

Result:

Testpoint method should not result in a bricked device.

Official method should do it in these cases.

SEMC patch (testpoint method) vs. Sony official (oem key method)

Description (need some feedback though):

Sony official method to unlock security in the bootloader is done by flashing a generated key to a certain region of NAND.

The keys are device specific and the IMEI is part of the key generation (maybe serial number as well).

The fastboot command oem with the valid key certifies the unlock process and device specific key gets written in the TA section.

Unpatched SBL (s1boot) will always scan for a valid key in this section of NAND.

If there's a valid key, routine will report success and security checks of kernel code will be overriden.

The testpoint method seemse to make use of a bug inside the chips primary bootloader (OTP PBL).

It had been found out that this bug existed in the early Xperia 2011 series and could be used to rewrite parts of NAND flash.

This opened the door to patch parts of the NAND bootcode (s1boot) or even replace the bootloader code.

As a result, the bootloader leaves further security checks aside and continues booting even with an unsigned kernel.

So how could we apply a patch to the bootloader?

By setting the testpoint to GND (force WE# of NAND to GND) external NAND is blocked and the phone gets started on the bare metal.

Only PBL is running at that point.

Though the procedure is not 100% understood, it is for sure that a tiny loader is transfered to the SoC's IRAM and gets executed.

This loader then allows to overwrite first blocks of external NAND memory and replace or at least patch the bootloader.

What we know:

Sony way:

- Sony official method works well with fastboot enabled devices

- DRM get's lost with Sony official method and could not be reverted (it's gone... and yes: no way back!!!)

- If using Sony official method, bootloaders could be re-locked by deleting the key

S1tool way:

- testpoint method does not work on new security (and will never work!)

- By pressing the restore button in S1tool everything is virgin again

- OS is not aware of the patched bootloader

- FOTA will cause bricks

What we need to know:

Basically we need so more details about bootloaders on Xperia 2011 from the cracks here...

Result:

Better understanding of "black box" procedures.

Debugging features at boot level

Description:

Parts of the boot code could still be dumped from memory with Android up and running.

We could dump the specific memory areas by reading the content with tools, such as viewmem.

The areas of interest are accessible in RAM area at:

0x00000000 - ~0x000023a0
0x00090300 - ~0x000ab190

By disassembling these dumped areas or simply extracting the strings of that region you may get a clue of the bootloaders secrets.

For the geeks and kernel developers its even more interesting to follow the startup procedure of the bootloader and early kernel inits,

with a console hooked up on a serial interface.

In fact we got this debug UART on most of the Xperia 2011.

This interface is present as dev/ttyMSM2 in the Android base system as well and is attached to UART3 of the MSM8255 SoC.

See this post for details:

http://xdaforums.com/showpost.php?p=37660319&postcount=76

The debug UART was at least identified on the MK16i mainboard.

If you need more details, please ask!

We got the testpoints confirmed to be working on lt18i as well.

See here for the location:

http://xdaforums.com/showpost.php?p=37701777&postcount=82

... and the logs:

http://xdaforums.com/showpost.php?p=37983019&postcount=109

Thanks a lot for contribution!

See this beautiful hack for the X8/10 as well:

http://xdaforums.com/showthread.php?t=2064108

What we know:

- parts of NAND could only be accessed with some "evil" tricks (e.g. kexec method)

- there are extensive debugging features available in our bootcode

What we need to know:

It would be nice to find a way to activate a cmdline interface at bootlevel.

Result:

Get some insights of the implemented functions in bootcode.

O.k. i'll stop writing for now.

If this thread will draw some attention, i'll continue ;)

You're always welcome to correct me or leave a comment here.

If you like more technical reading tell me as well.

Opinions and discussion welcome!!!

P.S:

If anyone could point me to some code to write a NAND mtd mapper for 2.6.32-9 stock kernel, you're welcome!

Background: I'd like to get mtdblock4 & 5 access on rooted but security locked device.

CREDITS (no particular order):

Dilesh Perera (for s1tool logs, which helped a lot to draw some conclusions)

gen_scheisskopf (for very useful discussion all over this thread)

hillbeast (for confirmation of UART3 testpoints on LT18i and logs)

...all others who helped to get a better understanding of the fuse registers!

Hugh thanks!!!

TBC

Cheers,

scholbert