yashsingh1/xdaforums huggingface dataset:
[Xperia Arc General] gen_scheisskopf:
TrimArea I guess?

As for fastboot:

So it is most likely executed the same way as flashmode.

Regarding loader.sin- this file is NOT flashed, it is used by flashtool/emma/however SEMC flash software is called. My guess-it's something like fastboot.bin for Tegra devices, a kind of "flash operations only" binary.

Found this by accident- newest flashtool whined about missing loader_unlocked.sin file, quick search revealed that this file should be provided with flashtool. However it it still the same file provided in official tft packs.
[Xperia Arc General] scholbert:
Yeah maybe... no way to access i guess.

Yes sure i know how to enter fastboot... you got me wrong here.

I just ment that i have not logged the output while entering fastboot mode and i wonder if something like a bootloader cmdline interface could be activated over the serial line.

Yes this is correct.. it is a helper tool during flash procedures... it in fact is a loader :p

Just to add that again... while in testpoint mode a.k.a QDL mode on other devices, we're talking to the SoC itself (Zeus.inf -> VID_05C6&PID_9008).

Something like a external USB boot mode is entered in this case. Anyway PBL will accept only signed binaries in this mode i guess.

Try search for these VID/PID and you'll find a lot similarities to other devices, even USB modems.

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)

Regards,

scholbert
[Xperia Arc General] gen_scheisskopf:
Flashtool can edit/backup/whatever TrimArea, however I didn't check this function

---------- Post added at 04:35 PM ---------- Previous post was at 03:53 PM ----------

This may be a simple check on USB plug (see- DIY dongles for Samsung hardware).

VBus may reffer to +5V line grounded or 4th (mostly used to sense USB host adapter cables) pin grounded.

Did you try sending anything to the Xperia during boot process? Maybe a simple keychar (enter, space etc) can interrupt the boot process and open communication (at least this was found in "leaked" SBL sources for s3c6410)
[Xperia Arc General] scholbert:
Yes sure, that's about the VBus detect message.

Compare first log (standard boot up, no cable attached):

VBus is low, SoftService is not asserted...
HW_REVISION_NUMBER = 0x205720e1

With second (flash mode, USB cable attached):

VBus is high, SoftService is not asserted...
HW_REVISION_NUMBER = 0x205720e1

So this was easy :p ...i am talking about SoftService message.

Yupp, i did that... but it seems not that easy... though i would not exclude problems with connection at this point.

Needs further investigation though.

BTW, where are the other curious people... no comments, no questions here :confused:

Maybe this is getting to geeky :eek:

Time for the weekend anyway!

P.S.:

For low level surgery (QDL mode) we may modify this tool and see what we can get from it :cool:

https://github.com/Fuses/emmc_recover

Quoting the author (Fuses):

Source: http://xdaforums.com/showpost.php?p=23134083&postcount=33

Just for fun...................................

Cheers,

scholbert
[Xperia Arc General] Dilesh Perera:
hi scholbert

nice to see the thread is alive and you two discovering things. :)

and thanks for the credit in the 1st page. im really happy to know i gave some small support. :)

cheers
[Xperia Arc General] scholbert:
... how does s1tool basically work and unlocks the bootloader

Hi again!

Yes, thanks a lot for passing the s1tool logs from your device.

This indeed helped to get things rolling...

So how does s1tool basically work and unlock our mobiles?

As i stated before, it is necessary to access the SoC in a real low level mode to get things done.

The testpoint pad is connected to the NAND flash WE# signal.

In regular usage this signal is used to write to I/O latch of the flash device.

Data and commands are shifted into the chip at the rising edge of WE#.

By temporary pulling this signal to GND the flash stays in write mode, I/O becomes input and ignores any reads.

In this mode no valid data is put on the bus by the flash device and it becomes "invisible" by the SoC.

This way the SoC stays in PBL code (onchip OTP ROM) and "searches" for alternativ boot mechanism, e.g. external USB mode.

PBL then listens to certain commands and can enter QDL-mode.

In QDL-mode binaries could be transfered to the SoC as well.

This happens when we press the ready button with the testpoint grounded.

In the next step a signed loader binary (qcldr.bin) gets transfered and is put into IRAM by PBL loader.

At some point this loader gets executed and listens for a file to get flashed into NAND.

This file is either a patched EROM or even an engineering EROM (dbl.sin), which is version R9A021 and properly signed as well.

To flash the new EROM to NAND we have to release the grounded WE# (a.k.a. testpoint) to make the flash chip operable again.

Then EROM area gets rewritten and i guess some TA write oerations are required as well to finish the process.

Now we got unlocked EROM r9A021 on our devices.

See the logs, from Dilesh Perera who was on EROM R9B031 and successfully unlocked his st18i using s1tool

Before:

RUNNING S1_EROM VER "R9B031"
SOFTWARE AID: 0001
LOADER AID: 0001
PM FLASH ID: "0098/00B3"
PM LOADER VERSION: "R4A069"

After:

RUNNING S1_EROM VER "r9A021"
SOFTWARE AID: 0001
LOADER AID: 0001
FLASH ID: "0098/00B3"
LOADER VERSION: "r4A069"

So thanks again for the logs, Dilesh!

... hope it is O.K. to put them down here.

That's it for now.

Questions and statements welcome ;)

Regards,

scholbert
[Xperia Arc General] Dilesh Perera:
hi scholbert :) Very informative..............
[Xperia Arc General] gen_scheisskopf:
So if anything had changed in PBL (command, data to be received, keys etc) s1tool is screwed- either it can't communicate with the SoC or dbl.sin signature is not correct.

Theory of new batch of SoC-s installed since 12W14 seems quite probable then.
[Xperia Arc General] scholbert:
Thanks for appreciating

Yeah, that basically hits the point, though flashing the dbl.sin is the last step in the chain.

The first thing that really has to be successfully completed is the transfer of the loader binary (qcldr.bin) i already refered to.

I found that binary after a lot of research and it contains Qualcomm and Sony signatures.

The version of the code is R4A062.

This stuff will get loaded to IRAM and started by PBL.

The message people find in their s1tool logs "qcreceivepacket can't get packet start" when unlocking fails, is not to be found in this binary.

So my guess is, that this is a response from the PBL in OTP ROM on the new security devices.

At least it might be a result of unresponsive PBL in QDL mode...

In other words new security SoCs refuse to load or execute signed loader R4A062 which is needed for the unlock process.

Anyway, this raw mode of the SoC is very interesting (at least for me...).

You may have a look at this:

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

There are some good guys talking about QDL and other stuff.

Though it refers to MSM8960 this is some essential comment on PBL's chain of trust and stuff:

http://xdaforums.com/showpost.php?p=37379841&postcount=30

http://xdaforums.com/showpost.php?p=37421993&postcount=33

The posts are quite new there.... and the_laser just has joint as well.

Unfortunately the_laser sells his tools and crypted all EROM files to be found in the packages.

No chance to read anything useful out of it.

... anyway most of the short statements from him sheds light and of course s1tool helped many people out there.

So no need to cry...

What ever, i guess many details are already lifted and personally i'm very interested in the technology used in the guts of my cell phone.

I really hope people enjoy the reading as well :laugh:

Cheers,

scholbert
[Xperia Arc General] gen_scheisskopf:
I think it is safe now to define Old and New security

Method: date code found on the sticker under the battery

a) older than 12W13= Old security- s1tool works

b) 12W14="Whish me luck" security- s1tool may work but no guarantee

c) 12W15 and older= New security- s1tool will fail

EDIT:

@scholbert- I'll dump bootloader boot log when I'll have some time (msm8255t, unlocked using testpoint method, seems like Old security)
[Xperia Arc General] scholbert:
Yes kind of... as i wrote at the very beginning of this thread mainboard manufacturing date and device manufaturing date my differ.

If only PBL code is responsible for the failure there might be some later ones working as well, because there could be some mainboard using old SoC (PBL gets definitely programmed during manufacturing phase at Qualcomm).

If it's an additional fuse bank or key section responsible to make PBL fail, then it may more strictly related to the date of device manufacturing and it's like you pointed out.

Fuses could be burned by Sony that's for sure.

Anyway we got many confirmations of failed attempts which won't harm the device in any way (at least more than brick reports).

This leds me to the following after all this discussion.... Try and error should work as well :p

But O.K. seems more likely to give people a guidance.

EDIT: Corrected a typo...

BTW, my device date is 12W11 and i will give a try soon, that's for sure :laugh:

Yeah sure what ever you like... no need to hurry and don't mess up your phone with high voltage :fingers-crossed:

Best rergards,

scholbert
[Xperia Arc General] gen_scheisskopf:
That's why "Whish me luck" option is for

If "new security" PBL refuses to use Qualcomm's signed qcloader.bin then I guess change is rather in PBL itself and not in the fuses

That was my point

And why not? Maybe if it receives 15-20V I could OC it to 3GHz :P

(this is a joke, don't try it)
[Xperia Arc General] scholbert:
Yupp!!

Could be the key section in use as well. I read that OEMs could choose between different keysets selected by fuse bits.

Whatever, it's somewhere in the guts and i don't really care, because we'll never break that :angel:

Good intent!

Most things will cause confusion anyway :eek:

Prepare for limited battery lifetime then :D

Just another interesting thing here....

I'm in doubt that someone could ever be able to hack the bootcode and sign it properly without the private keys.

So my guess is, that R9A021 is in fact an engineering loader, which leaked somewhere.

Remember my post with the certificate names of R9B031?

See: http://xdaforums.com/showpost.php?p=37417901&postcount=64

Compare the certificate names with these taken from r9A021:

R0TMAGIK

S1_Loader_Root_773f0
S1_Loader_Root_773f0

S1_EROM_Root_d6010
S1_EROM_Root_d6010

S1_SW_Root_883f0
S1_SW_Root_883f0

S1_Cust_Root_96030
S1_Cust_Root_96030

S1_SL_Root_c4220
S1_SL_Root_c4220

S1_HWConf_Root_08af0
S1_HWConf_Root_08af0

S1_Loader_test_Root_xxxx0
S1_Loader_test_Root_xxxx0

S1_EROM_test_Root_4c370
S1_EROM_test_Root_4c370

S1_SW_test_Root_3f3c0
S1_SW_test_Root_3f3c0

S1_Cust_test_Root_87ee0
S1_Cust_test_Root_87ee0

S1_SL_test_Root_xxxx0
S1_SL_test_Root_xxxx0

S1_HWConf_test_Root_xxxx0
S1_HWConf_test_Root_xxxx0

Pretty sure the "xxxx" marked are engineering ones (should be called brown signature AFAIK).

Remember i'm no security expert, but trainee ;)

I'll do some experimental stuff with the PBL loader these days i guess.

Best regards and happy hacking,

scholbert
[Xperia Arc General] gen_scheisskopf:
If we're talking about RSA all you need to do is to find a prime number that is "paired" with the one in the public key (simplified explanation), it's lenght depends on key lenght- 256/512/1024/2^n bits. If you can wait let's say 40-50 years or longer- go for it ;)
[Xperia Arc General] Jonfensu:
Whatthe.....Where is my previous comment? :mad: Come on....
[Xperia Arc General] scholbert:
Hoho... i knew about it and i don't want to digg for any primes.

Just wondering if the bootcode got patched in a way by exploiting the bug mentioned on the old sec devices PBL,

or if it's really a leaked engineering loader by SEMC.

The_laser should come around here and leave a statement... :p

Have seen no comment :confused:

Wrong thread or maybe lost in translation :laugh:

Have a nice day,

scholbert
[Xperia Arc General] Jonfensu:
No No, I posted it here :cowboy: . Well Here I go Again :p

My Phone is a Neo V (MT11a) SIM-Unlock (I bought it 1 year ago)

I unlocked the bootloader via TestPoint without Errors

I can flash any Kernel and Any ROM (SE Based or CM, AOSP, AOKP based ROMs) without troubles

The problem is the following:

The touchscreen does not work with:

- CM, AOSP, AOKP based ROMs (The device start up into the System/ROM, but I cant play with it, there is not feedback from the touchscreen, only the physical buttons -power,volume etc - works)

- Aroma Installer (Only works with physical buttons)

That does not happen with SE based ROM (MIUI, UHD etc.)

I don't know whats the problem. Unlock Method related?

I am facing this problem from the first time that i have unlocked the bootloader

What do you think about this?

Thanks

PS. Its the worst bug that I faced :crying: :mad: (I just can not feel the taste of JB ROMs) :(
[Xperia Arc General] hillbeast:
Thanks a million for this information. I've been looking for UART inside my device so I can get some serious development going on.

Gonna attach some test points when I get home from work and start messing with this thing properly. Hopefully I can help FXP with the kernel 3.4 porting now.
[Xperia Arc General] scholbert:
Hi!

Though this is off-topic here and i'd like to avoid to get the thread flooded with related stuff, i'll give a short comment on this ;).

No i don't think that it is related to the unlock process... but it call it a "side-effect", because afterwards you started flashing custom kernels. So as a short result, your touchscreen issue might be kernel related or even ROM related.

Touchscreen needs a driver framework (which is kernel stuff) and a firmware to load to the touch-controller (part of ROM) for working properly.

Do a little research with this information and/or ask the developers of your custom stuff accordingly.

Anyway, i hope you'll fix it and please understand, that i'd like to focus on bootloader related stuff and low level debugging here!

Thanks for appreciation!

I'm pretty sure these testpoints will do it on the Arc. You might do some pics when you open up the case :D

BTW, which version are you refering to, LT15 or LT18?

I'm looking forward to the log.

What is your bootloader version?

Concerning kernel...

We really should give the kernel development a blast, so hopefully others might join.

Few days ago i had a look around in the sources. The code is still in very early stage right now and needs work to get it booting on our phones.

I doubt that i'll find the time to do so, but i may have a look at the mk16 related stuff.

If you got questions about the serial connection, i'll try to answer them :fingers-crossed:

Best regards,

scholbert
[Xperia Arc General] hillbeast:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood? (Update 08.02.1

LT18i, so the Arc S. The test points are exactly as shown in the image, but I used a different location for the ground as it was more convenient. I'll take a photo of how I got the wires out of the case, but what I did was melt the plastic a tiny bit under the SIM card and ran the wires up through there. They are long enough to reach my Arduino, but also short enough so I can wind them back up inside the back panel so I can continue using the device as normal.

I'll take photos probably tomorrow as its late here. Ill post the logs in a few minutes though.
[Xperia Arc General] gen_scheisskopf:
Which method did you use to unlock bootloader? S1tool or official?
[Xperia Arc General] hillbeast:
I used Sonys official method on their website. I didn't care about my warranty. I've had the device for less than an month and have opened it several times already, and done soldering inside it.
[Xperia Arc General] scholbert:
Hey hillbeast,

some pics would be nice though it might not be that urgent, because it seems the pic i already posted it good enough to locate the testpoints.

Anyway, thanks a lot for contributing and especially for posting your logs.

These are the lines i'd like to read more often here... perhaps we should create a sticker:

...soldering inside (TM) :victory:

BTW, i revisited your logs and compared to mine.

Though these are differnent models most of the bootcode is shared between them.

So messages are mostly the same as well.

Locked bootloader (my mk16i):

...
Fastboot emulation not selected
ARM ELF image (0x0028), entry point @ 0x04700000
ARM ELF image (0x0028), entry point @ 0x03e00000
ARM ELF image (0x0028), entry point @ 0x00208000
plf_ta_cmd_params()
Boot parameters found in config data
...

Unlocked by official sony method (hillbeast's LT18i):

...
Fastboot emulation not selected
ARM ELF image (0x0028), entry point @ 0x04700000
ARM ELF image (0x0028), entry point @ 0x03e00000
SIN Verification of aARM failed!
ARM ELF image (0x0028), entry point @ 0x00208000
plf_ta_cmd_params()
Boot parameters found in config data
...

It's little strange that unlocked loaders give this message...

Sure this states kernel is not signed, but this shows as well that even on unlocked bootloader signature gets checked,

... but a failed check only results in a message. All ELF images are executed regardless.

I assumed that signature checks would completely be skipped, with Sony's unlock key written to TA.

To be considered as loud thinking... :p

Regards,

scholbert
[Xperia Arc General] nickholtus:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood? (Update 08.02.1

I will ask alejandrissimo, he has pictures of test point on all 2011 devices
[Xperia Arc General] Dilesh Perera:
believe these are the pics u referring....

test points of xperia 2011
[Xperia Arc General] gen_scheisskopf:
These are well known.

But UART testpoints are still more or less unknown
[Xperia Arc General] nobodyAtall:
Just found this thread. Nice work on the 2011 devices!

Question: did you find a way to get into 'command line mode' (if such a mode exists) for the s1 loader via uart?

It would be interesting if such a thing exists...

Thanks.
[Xperia Arc General] scholbert:
Talking to PBL...

Hi,

today i had a little chat with the primary bootloader on my MK16i.

I used a tweaked version of qdload to translate because i don't speak DMSS natively ;)

So i removed the battery, placed a jumper permantly on my testpoint and attached the MK16 via USB cable to my linux notebook...

lsusb
Bus 002 Device 005: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)

./qdl-msm8255.pl --version
Requesting SoftwareVersion...
SENDING: 7e 0c 14 3a 7e
RECEIVED: 0d 14 50 42 4c 5f 44 6f 77 6e 6c 6f 61 64 65 72 56 45 52 31 2e 30
Version: PBL_DownloaderVER1

./qdl-msm8255.pl --lreset
Requesting Reset...
SENDING: 7e 0a 22 5f 7e
requestReset send ok
RECEIVED: 02 6a d3
Param: 02

./qdl-msm8255.pl --params
Requesting SoftwareVersion...
SENDING: 7e 0c 14 3a 7e
RECEIVED: 0d 14 50 42 4c 5f 44 6f 77 6e 6c 6f 61 64 65 72 56 45 52 31 2e 30
Version: PBL_DownloaderVER1
Requesting Params...
SENDING: 7e 07 c7 84 7e
RECEIVED: 08 06 01 01 00 90 00 00 14 70
Params: 06 01 01 00 90 00 00

EDIT:

Some words on the params response from the phone...

Params: 06 01 01 00 90 00 00

Version = 0x06 (PBL DMSS protocol version)
Min.Version = 0x01 (minimum required version)
Packet size = 0x100 (256 bytes limit for single write command packet)
Model = 0x90 (MOB_MODEL -> phone hardware model number)
Flash size = 0x00 (no NOR flash, flash programming not directly supported*)
Flash type = 0x00 (only valid if NOR flash is used)

*our phones do not use NOR flash, for NAND programming we need flash loader binary)

I guess apart from the hex values, the output is more or less self explaining... :p

For details please refer to this document:

http://xdaforums.com/showpost.php?p=38323955&postcount=51

Credits:

jcsullins (for improvements and features of qdload: http://github.com/jcsullins/qdloader)

afkfurby (for posting the DMSS document)

P.S.: If there's interest i'll put down my tweaked version (qdl-msm8255.pl) here as well...

Cheers,

scholbert
[Xperia Arc General] danielgek:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood? (Update 26.02.1

Cool ;)
[Xperia Arc General] Nosferatu Alucard:
I don´t know if this helps, but to me this topic is very interesting and I want to contribute something, so I ran the viewmem commands

from the second post on my SK17i (11w33), here is the output:

Hardware ID:

00000000 e1 20 57 20 |. W | 00000004

TCSR_CONF_FUSE_0..5:

00000000 4b 6d 71 00 47 14 04 c8 15 08 04 28 80 9f 00 4b |Kmq.G......(...K|

00000010 b0 01 00 20 |... |

00000014

Hope this helps somewhat, I have no idea how to read/interprete that :D

//edit: I unlocked my phone with the testpoint method, if it matters ^^
[Xperia Arc General] scholbert:
Hi Nosferatu Alucard,

thanks for contributing, but i guess we're finished with reading the fuses...

Again this helps us to understand that the fuse bits and CPU types are identical for the different models.

So to put it in a comparable arrangement this gives us:

MSM8255 based (hardware id = 205720e1):

Xperia Mini Pro (SK17i)

FUSE(0-5): 00716d4b c8041447 28040815 xxxxxxxx 200001b0 00000000

... which are the same values as to be found on other phones.

No surprise here anymore ;)

Anyway, thanks for the output!!

Regards,

scholbert
[Xperia Arc General] odie70:
Can someone explain this? i have follow all of the step, but always like this. unlockbootloader status = yes, and Sim lock is free.
[Xperia Arc General] gen_scheisskopf:
It's most likely that you have the "new security" device (however this version of s1boot didn't surface here yet).

Please check the datecode- it's on the sticker under the battery.

If the code is 12W14 (2012, week 14) or later than the only the official unlock will work.
[Xperia Arc General] odie70:
My code is 11W52
[Xperia Arc General] gen_scheisskopf:
Which phone do you have exactly? S1tool should (judging by the data we already have) work for 11W52 device.

However R9B031 s1boot (slightly newer than yours) was reported as not "compatible" with s1tool so maybe bootloader itself is reposnsible for security setup (not fuses)?
[Xperia Arc General] odie70:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood? (Update 26.02.1

Thats only my phone. Thats the data from one phone bro,,

Is there any posibility that i have wrong install the zeus driver and fastboot drive?

I actualy not sure,cause all driver seems work properly.
[Xperia Arc General] gen_scheisskopf:
Drivers are ok- phone is recognized.

Sony changed internal security at some point (12W14 was known point) which makes s1tool unusable, the only way to unlock the bootloader is the official way
[Xperia Arc General] scholbert:
Hi!

... as gen_scheisskopf already requested, please tell us your phone model!

Though you stated your phone is not simlocked, there's some trouble with the s1boot certificate.

Normally by pressing the identify button it should state something like "SEMC certifcate".

Please make sure you use the right testpoint during the process.

Where did you grab s1tool?

There are different versions floating around.

It's even confirmed by Dilesh Perera to be working on 12W05 with EROM bootloader version R9B031.

Please let's try to not mix things up again...

The R9B031 is not responsible if unlocking fails. It depends on the PBL version of the chip, maybe in combination with "newer" fuse setup.

AFAIK considering the R9B031 as a prooven indicator for new security was a wrong conclusion.

Because this is the latest EROM we find on Xperia 2011, most of new security chips came with this bootcode pre-installed.

As a result this was seen as the reason for failed unlocks...

Anyway it is possible to unlock a device with R9B031, if the chip comes with old security PBL installed.

Regards,

scholbert