yashsingh1/xdaforums huggingface dataset:
[Xperia Arc General] Dilesh Perera:
hi Scholbert

i asked odie70 to come visit this thread and get some help :) im pretty much sure his phone can be unlocked by testpoints but my guess he's

not following procedure correctly . i will post the place where i got my S1tool here when i go home :)
[Xperia Arc General] gen_scheisskopf:
It's

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

Sorry for the confusion caused, I didn't check previous posts carefully enough
[Xperia Arc General] odie70:
This my Phone Identity using S1TOOL I found in sticky post in Xperia Ray Android Development Section.
[Xperia Arc General] scholbert:
Hi odie70!

That looks o.k. for me at the first sight.

So maybe you mixed things up a little bit while pulling the testpoint to GND.

Please also make sure, that you refer to the correct pic for the testpoints for Xperia Ray (ST18i).

Normally there's a message of a packet error if your device is "new" security.

Your message is strange though:

FATAL ERROR [ SECURITY_CLASS, SIN_header_verification_failed ]
error while uploading HDR block
LOADER NOT STARTED

I've never seen this before :confused:

Good luck!

scholbert
[Xperia Arc General] odie70:
So that mean i cannot unlock my Ray with regular way?
[Xperia Arc General] Dilesh Perera:
http://xdaforums.com/showthread.php?t=1730874

http://androidflip.com/unlock-xperia-phones-bootloader-without-losing-drm-data-track-id-working/

again do it from the step 1. maybe u can get sucess
[Xperia Arc General] scholbert:
If you refer to Sony official method (= regular way), then yes, it should work i guess.

Official way should always work as long as bootloader "unlockable = yes" and working fastboot mode.

Please refer to the guides out there in web how to proceed with Sony official method.

Guiding you through this is getting off topic here...

Regards,

scholbert
[Xperia Arc General] odie70:
Oke thanks for all.
[Xperia Arc General] Jeybird:
Hey, I just tried to unlock bootloader on a SK17i mini pro, 12w26, S1 boot version:1241-3656 R9B031.

testpoint method failed! (qcReceivePacket)

so I can confirm new security.

Regards

Jeybird

Welcome to S1 tool.
That is small and crippled subset of SETOOL2 service tool.

DETACH USB CABLE FROM PHONE
REMOVE BATTERY FROM PHONE
ATTACH TESTPOINT
PRESS "READY", THEN ATTACH USB CABLE TO PHONE

PROCESSING ...
REMOVE TESTPOINT NOW, THEN PRESS "READY"

qcReceivePacket: can't get packet start.
Elapsed:125 secs.
[Xperia Arc General] scholbert:
... just a sum up

Hi,

today i finally unlocked my Xperia Pro successfully by using the s1tool.

So again to write it down clearly:

The "new" security device could not be identified by the EROM version the device is running.

It all relies on the PBL version flashed to the CPU OTP-ROM.

There could be some unknown fuse setups as well, which made it possible to exploit the bug inside this ROM.

We don't know that for sure, because there are no details to be found about this bug.

As stated many times this PBL version is depended on the manufacturing date of the device/mainboard.

The PBL of my device ("old" security) responds to version request with: PBL_DownloaderVER1

See this post for details:

http://xdaforums.com/showpost.php?p=38839325&postcount=118

So, if someone is willing to try my script and do a PBL version request on a "new" security device,

i will put it down here to try.

This may even give us more insights to report in this thread.

Anyway to sum it up again, my device's manufacturing date is 12W11 and CPU sticker is 11W44.

The booloader software versions before unlocking:

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

... and after the successful run:

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

Again you'll see that the EROM got replaced during unlock and within the version strings "R" changed to "r".

You'll find similar reports all over here... this indicates unlocked bootloaders using the testpoint method.

If using the s1tool failed for your device, there's nothing we could do.

You won't find any help here, because this is an educational thread and these devices could not be unlocked for free using the testpoint method.

Please refer to the Omnius server threads or Sony's official website to unlock your device.

Best regards,

scholbert
[Xperia Arc General] scholbert:
... strange fastboot excurse... caused bootloop

Hi again,

by accident i just went through some exciting thing... and thought for a second that i bricked my device in some way.

Fortunately my phone is up and running again and i think i'll have to sort out what happened in detail.

Maybe this is completely normal behaviour, but it made me wonder for a little while...

Here's what i did:

- after testpoint unlock everything was nice, phone unlocked and booting up as usual with stock kernel, no issue

- powered down the device

- held the menu key and without being attached via USB to my host i hit the power button to enter fastboot mode

- then i attached my phone to my host and realized that the device was not recognized

- i plugged out the cable and took of the battery, re-inserted battery and pressed power button to boot up normally

- the device then entered a bootloop with the blue led turning on after some time

- removed battery again and put it right back

- pressing the power button again leds to a bootloop with blue led lightning up

- took out the battery

- then i re-installed the fastboot drivers

- this time i insert the battery, held the menu key and attached the USB cable to my host

- luckily my phone then got recognized as fastboot device

- at the fastboot console i typed: fastboot reboot

- phone rebooted and immediately entered charging mode, instead booting up normally

Anyway i removed the cable at this point and powered up the device by pressing the power button.

Everything nice again :p

Thesis:

By pressing the menu key+power button to enter fastboot mode without the cable attached i entered into some other mode...

Maybe fastboot commands are then taken by serial line (remember my debug UART hack).

After a while there might be a timeout, which leds to reboots and if nothing gets attached... reboots again... and again...

If you got some similar behaviour or realized other strange bootloader related stuff you may leave a comment here.

Regards,

scholbert
[Xperia Arc General] nobodyAtall:
Interesting behavior. Why don't you get the serial port output when this happens?
[Xperia Arc General] scholbert:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood? (Update 26.02.1

Simple: I use my device as a phone at the moment.

No wires soldered on the mainboard... no UART connected ;)

Might try it sooner or later...

Regards,

scholbert
[Xperia Arc General] scholbert:
bootloader cmdline ???

Hi again,

i just want to give another short update about some things i tried to enter bootloader cmdline...

I made some logs while i tried to reproduce the behaviour i wrote down a few posts ago.

This time i was not able to enter this bootloop mode again and i guess it was a one-shot.

During various starts i found out that the bootloader got a special feature to seperate between short power button press and long power button press.

This detection is involved in the board start up procedure and is initiated by this message:

...
Configuring long press:800
...

If power button is pressed short, board starts up but stops at the end giving this message:

...
Longpress NOT OK - startup inhibited

By pressing the power button again shortly it will re-enter this mode and halt.

If power button is pressed long the platform boots up normally.

Anyway nothing useful again.

This made me refer to one of my earlier posts.

Please refer to these comments:

http://xdaforums.com/showpost.php?p=37738620&postcount=88

At the end of the post, there's a log from entering flash mode and it is little different to all other logs:

...
Service Mode Config From TA (ver 1.0): KEYS:1 USB:eek:N SERVICEMODE:USB SERVICE_PIN
:ENABLED
Service key was pressed
Modem cold start
S1 BOOT waiting for USB connection
Will set FlaFla
OTP User segment locked
TCB_VerifyASAHISignature hashLength=[0x14] ASAHILength=[0x23f]
TCB_VerifyASAHISignature: S1_VerifySignature OK

It seems that on the MK16 the back key is handled as service key, because the log reports "Service key was pressed".

I'll concentrate on this mode for now and probably re-check my hardware dongle.

EDIT:

Done... re-checked my hardware, especially re-checked the TX channel from the host to the device.

The level-shifter is working properly, but no response to any key i hit on the keyboard during start-up.

I guess it will need much more work on the disassembly of bootcode, to understand if and how the commandline interface could be activated.

Maybe another mechanism is required to get a command line and maybe some certification procedure is needed as well.

I'm really in doubt, if it's worth all that...

BTW, i don't know if there's still interest in these kind of reports, so i guess i will only write another update if i find something useful.

Thanks for your interst so far and keep hacking :D

P.S.: If anyone knows anything about FlaFla, tell me...

Regards,

scholbert
[Xperia Arc General] u.b.o.o.t:
Hi Scholbert,

many thanks for you efforts! I have news: my MK16i (Xperia Pro) is 12W11 and doesn't have a simlock, but S1tool failed:

18.04.2013 21:50:16 RUNNING S1_EROM VER "R9B031"
18.04.2013 21:50:16 SOFTWARE AID: 0001
18.04.2013 21:50:16 LOADER AID: 0001
18.04.2013 21:50:17 FATAL ERROR [ SECURITY_CLASS, SIN_header_verification_failed ]
18.04.2013 21:50:17 error while uploading HDR block
18.04.2013 21:50:17 LOADER NOT STARTED

...tried many times, always the same result.

The kernel is latest stock kernel (4.1.B.0.587).

Just the system partition is "custom". Could this be the cause? Is the sys partition involved in the testpoint bootloader unlock procedure?

Otherwise my device would disproof that 12W11 means "safe to unlock via testpoint / S1tool"...

EDIT: according to this thread, devices >=12W11 have new security: http://xdaforums.com/showthread.php?t=2067008
[Xperia Arc General] muell_matto:
Hi,

Could you please share some pictures of your wirering? (especially ground) I am planing to get early-Kernel-boot-msg with an arduino, too. I need those logs to get my b2g port booting. At the moment it crashes before i get a connection to adbd.

greetings

matto
[Xperia Arc General] Sahaab:
I have a arc s

12W46 manufacturing date

My phone always fails when trying to unlock via official method

Havnt tried test point method yet

My bootloader is unlockable

Is there any way i can unlock my bootloader?

I thnk its MSM7x30
[Xperia Arc General] mai006:
Rsa2048 签名

Annex extracted from 4SETOOL LT15 mobile phone unlocking BL SIN required

s1_qc8255_boot_4se.sin brush into the NAND flash absolute address 0X00000000-0X00020000 for 128K total size is S1BOOT

You can not modify S1BOOT s1_qc8255_boot_4se.sin the certificate and code, it has RSA2048 signature protection. You need to understand the content of those addresses on S1BOOT a signature to edit your S1BOOT code and replace the corresponding certificates.
[Xperia Arc General] gen_scheisskopf:
S1BOOT is most likely launched via PBL- first stage bootloader hardcocded into the SoC. PBL checks S1BOOT digital signature using built-in keys before executing or flashing it, it's very likely that "new security" devices have different keys provided with PBL or some of the keys ae marked as invalid.

So to prepare anything valid to be flashed you must use Sony or Qualcomm's private key(RSA consists of a pair of keys)- if it's RSA2048 forget about cracking, you'd need dozens of years
[Xperia Arc General] mai006:
rsa 2048 Sony private key can not solve

rsa 2048 Sony private key can not be solved, even hundreds of years. But you can replace the public S1BOOT lock, and then use your own private key to sign on S1BOOT

For 12W10 old security algorithm previous Sony phone, SETOOL SE4TOOL tool box to use TESTPIONT brush to write their modified PBL S1BOOT.SIN to the phone after the lifting of BL lock. Tool box developers know the modified PBL S1BOOT goes public with lock certificate to sign a specific area, they are replaced by the male lock certificates generated by the public OPENSSL lock, and then use the corresponding private key pairs generated OPENSSL sign S1BOOT .

Tool box solution ARC phone network lock principle:

TA zone box to modify the phone unit's power button is pressed within S1_HWConf_Root_08af0 s1_qc8255_boot_4se.sin lock card will inspect public areas TA does not boot signature is not shake, so they replaced the S1_HWConf_Root_08af0 public brush into the phone lock generation s1_qc8255_boot_4se_hwconf.sin .

---------- Post added at 11:36 AM ---------- Previous post was at 11:32 AM ----------

rsa 2048 Sony private key can not be solved, even hundreds of years. But you can replace the public S1BOOT lock, and then use your own private key to sign on S1BOOT

For 12W10 old security algorithm previous Sony phone, SETOOL SE4TOOL tool box to use TESTPIONT brush to write their modified PBL S1BOOT.SIN to the phone after the lifting of BL lock. Tool box developers know the modified PBL S1BOOT goes public with lock certificate to sign a specific area, they are replaced by the male lock certificates generated by the public OPENSSL lock, and then use the corresponding private key pairs generated OPENSSL sign S1BOOT .

Use TESTPIONT reflash phone he would not test. SIN firmware in the head.

Tool box solution ARC phone network lock principle:

TA zone box to modify the phone unit's power button is pressed within S1_HWConf_Root_08af0 s1_qc8255_boot_4se.sin lock certificate will inspect public areas TA does not boot signature is not shake, so they replaced the S1_HWConf_Root_08af0 public brush into the phone lock generation s1_qc8255_boot_4se_hwconf.sin . Then you can successfully boot phone
[Xperia Arc General] mai006:
Signature data decimal 256

. jpg marked signature data for S1BOOT

You modify or replace public S1BOOT code lock certificate you have recalculated this signature data, but you have to know is goes public certificate to verify the lock.
[Xperia Arc General] scholbert:
partitions and physical offsets in NAND

Hey,

interesting stuff had been posted here...

Though i got some trouble to understand what mai006 exactly is trying to teach us here :confused:

Anyway looks very interesting and seems to explain how security could be cheated on old security devices.

Especially this sentence sounds very exciting:

If anyone might comment on this, you're welcome.

Another thing to mention is, that i wrote down some stuff and recalculated some physical offsets in NAND memory.

Though most are already explained elsewhere i thought this would be a good moment and place, to share it with you.

Have a look at the following lists... ;)

Partition table contents from bootloader are multiples of 128k blocks (0x20000):

PartID Descr Attribs StartBlock NumBlocks UsedAs	physical offsets	physical size
0x00000001 S1Boot 0x00000022 0x00000000 0x00000001	0x00000000-0x00020000	0x00020000
0x00000002 TA 0x00000001 0x00000008 0x00000008	0x00100000-0x00200000	0x00100000

0x00000005 ModemSW 0x40000022 0x00000010 0x000000e4 mARM image	0x00200000-0x01e80000	0x01c80000
0x00000006 ModemFS 0x40000001 0x000000f4 0x00000068 mARM-FS image	0x01e80000-0x02b80000	0x00d00000

0x00000008 AppDSP 0x40000022 0x0000015c 0x0000006c aDSP image	0x02b80000-0x03900000	0x00d80000

0x0000000b FOTA0 0x40000022 0x000001c8 0x0000005c	0x03900000-0x04480000	0x00b80000
0x0000000c FOTA1 0x40000022 0x00000224 0x0000005c	0x04480000-0x05000000	0x00b80000

0x00000003 Linux 0x80000022 0x00000280 0x00000064 aARM image	0x05000000-0x05c80000	0x00c80000	(12M)
0x00000004 AppsFS1 0x80000001 0x000002f4 0x00000c80 system image	0x05e80000-0x1ee80000	0x19000000	(400M)

0x00000010 AppLog 0x80000001 0x00000f74 0x00000030 appslog image	0x1ee80000-0x1f480000	0x00600000	(6M)
0x0000000f AppsFS3 0xc0000001 0x00000fa4 0x0000032c cache image	0x1f480000-0x25a00000	0x06580000	(101M)

0x00000009 AppsFS2 0x80000001 0x000012d0 0x00000d20 userdata image	0x25a00000-0x3fe00000	0x1a400000	(420M)

Additionally these memory regions got prepared further down in bootcode:

NAND MPU Partition 0 start:0x00000280 end:0x00001ff0 //kernel+initrd
NAND MPU Partition 1 start:0x00000fa4 end:0x000012d0 //cache

After jumping to kernel code this leads to the following kernel output...

At first atags get parsed from bootloader:

Partition (from atag) system -- Offset:2f4 Size:c80
Partition (from atag) appslog -- Offset:f74 Size:30
Partition (from atag) cache -- Offset:fa4 Size:32c
Partition (from atag) userdata -- Offset:12d0 Size:d20

Then after NAND is initialized by kernel code this leads to 4 MTD partitions:

Creating 4 MTD partitions on "msm_nand":
0x000005e80000-0x00001ee80000 : "system"
0x00001ee80000-0x00001f480000 : "appslog"
0x00001f480000-0x000025a00000 : "cache"
0x000025a00000-0x00003fe00000 : "userdata"

So in the end these are the partitions to be found at userland :D

Have fun!

scholbert
[Xperia Arc General] scholbert:
... some words on the ATAG section

Hi again,

just to add some more things here and make the boot process even clearer :D

The ATAG section is located in RAM at 0x00200100 and could be dumped after the system has started up!

00000000 02 00 00 00 01 00 41 54 04 00 00 00 05 00 42 54 |......AT......BT|
00000010 00 00 20 01 03 ad 3a 00 1e 00 00 00 70 4d 53 4d |.. ...:.....pMSM|
00000020 73 79 73 74 65 6d 00 00 00 00 00 00 00 00 00 00 |system..........|
00000030 f4 02 00 00 80 0c 00 00 00 00 00 00 61 70 70 73 |............apps|
00000040 6c 6f 67 00 00 00 00 00 00 00 00 00 74 0f 00 00 |log.........t...|
00000050 30 00 00 00 00 00 00 00 63 61 63 68 65 00 00 00 |0.......cache...|
00000060 00 00 00 00 00 00 00 00 a4 0f 00 00 2c 03 00 00 |............,...|
00000070 00 00 00 00 75 73 65 72 64 61 74 61 00 00 00 00 |....userdata....|
00000080 00 00 00 00 d0 12 00 00 20 0d 00 00 00 00 00 00 |........ .......|
00000090 20 00 00 00 09 00 41 54 74 6f 74 61 6c 6d 65 6d | .....ATtotalmem|
000000a0 3d 30 78 32 30 30 20 73 74 61 72 74 75 70 3d 30 |=0x200 startup=0|
000000b0 78 30 30 30 30 30 30 30 31 20 73 65 72 69 61 6c |x00000001 serial|
000000c0 6e 6f 3d xx xx xx xx xx xx xx xx xx xx 20 62 74 |no=xxxxxxxxxx bt|
000000d0 30 2e 69 65 65 65 5f 61 64 64 72 3d xx xx 3a xx |0.ieee_addr=xx:x|
000000e0 xx 3a xx xx 3a xx xx 3a xx xx 3a xx xx 20 77 69 |x:xx:xx:xx:xx wi|
000000f0 66 69 30 2e 65 74 68 5f 61 64 64 72 3d xx xx 3a |fi0.eth_addr=xx:|
00000100 xx xx 3a xx xx 3a xx xx 3a xx xx 3a xx xx 00 a2 |xx:xx:xx:xx:xx..|
00000110 00 00 00 00 00 00 00 00 ATAG section ends here! |................|

Content:
[B]0x54410001[/B] 0x00000002 -> ATAG_CORE, length 2 words no further data

[B]0x54420005[/B] 0x00000004 -> ATAG_INITRD2, length 4 words data:
0x01200000 0x003aad03 -> start and size in bytes

Size seems to be adjusted by bootloader dynamically

[B]0x4d534d70[/B] 0x0000001e -> ATAG_MSM_PARTITION, ("MSMp") length 30 words data:

0x73,0x79,0x73,0x74,0x65,0x6d -> system (char name[16])
0x000002f4 -> Offset:2f4 (__u32 offset)
0x00000c80 -> Size:c80 (__u32 size)
0x00000000 -> Flags:0 (__u32 flags)

0x61, 0x70, 0x70, 0x73, 0x6c, 0x6f, 0x67 -> appslog (char name[16])
0x00000f74 -> Offset:f74 (__u32 offset)
0x00000030 -> Size:30 (__u32 size)
0x00000000 -> Flags:0 (__u32 flags)

0x63, 0x61, 0x63, 0x68, 0x65 -> cache (char name[16])
0x00000fa4 -> Offset:fa4 (__u32 offset)
0x0000032c -> Size:32c (__u32 size)
0x00000000 -> Flags:0 (__u32 flags)

0x75, 0x73, 0x65, 0x72, 0x64, 0x61, 0x74, 0x61 -> userdata (char name[16])
0x000012d0 -> Offset:12d0 (__u32 offset)
0x00000d20 -> Size:d20 (__u32 size)
0x00000000 -> Flags:0 (__u32 flags)

[B]0x54410009[/B] 0x00000020 -> ATAG_CMDLINE, length 32 words data (2 + ((length_of_cmdline + 3) / 4))

This part of cmdline is parsed by bootloader and is concatenated to kernel default cmdline per default:
totalmem=0x200 startup=0x00000001 serialno=xxxxxxxxxx bt0.ieee_addr=xx:xx:xx:xx:xx:xx wifi0.eth_addr=xx:xx:xx:xx:xx:xx

[B]0x00000000[/B] 0x00000000 -> ATAG_NONE, length 2 words; empty tag used to end list

That's it by now.

Have fun!

scholbert
[Xperia Arc General] scholbert:
Hey CTCaer!

Thanks for appreciation and joining us over here :D

As you may noticed i dumped some parts of RAM as well, but never enhanced the viewmem tool.

So it became little uncomfortable for larger areas... so which tool do you use?

Very intersting findings... as for the s1boot:

Remember that the first CPU involved in the boot process is the ARM9 baseband processor...

Later on the Scorpion jumps in and starts the kernel.

So during the low level boot initializations there's some memory remapping and code parts will be shuffled all around.

Nice!

Whatever this is used for, we need some crypto experts i guess :laugh:

Some words on 0x047000000:

AFAIK the bootloader drops the uncompressed kernel image at this offset and jumps to kernel piggy loader then.

You'll notice the uncompressing Linux message afterwards.

The kernel then remaps itself and starts over...

Cool... maybe this could be useful for the daily users in the end as well.

No need to hurry here, long winter nights will come...

Take your time and good luck for your exams :good:

I probably will tweak around a little bit with RAM borders ;)

Yepp do that... keep in mind LVTTL@1.8V is used for the logic!

Cheers and thanks again!

scholbert
[Xperia Arc General] CTCaer:
Viewmem did the job for me.

You can completely dump 0x0 to 0x1000 0000 and 0x4000 0000 to 0x5000 0000.

Trying at 0x1000 0000 crashed the phone (probably ARM9 but didnt checked last_* files).

I'm sure the gpu uses some address space there like 0x3500 0000 but don't remember exacts.

For sure is a completely locked area and probably only for real hardware. But i'll try more addresses when i have time.

Normally at 0x6000 0000 + 2MB (that's why i could recover 2mb there) is the start of vmalloc userspace side. So any dump there is useless.

So I'll try and take dumps from 0x0 to 0x6000 0000, with as much coverage I can, and upload it somewhere. Ask in PM for dumps though,

because of private info inside them. Also I'll take 2nd dumps from recovery with no android binary or framework running, for differences in ARM9 area.

Good, so the 16mb margin is good for a starting point. I'll check with GPS also on because it uses ARM9. And maybe a call also.

More dumps, more info.

Until honami mini comes out, I'll juice out the mogami baby I have.

If we could get some logs from L4 microkernel would be good also. I'm very interested in memory mappings and i/o maps.
[Xperia Arc General] CTCaer:
Check this

Boot partition has special configuration, so it can be used correctly.

No status read before data, 4 spare bytes and some other bits and bytes.

Don't know what you used, but it's worth to check the above commit

---EDIT---

Oh, you are talking about s1boot partition... Uni exams studying melted my mind.

Well, it may use the same configuration like kernel partition. And probably all other hidden partitions too.

---EDIT2---

Also about the RAM, from here

EBI0 MPU Partition 0 start:0x03e00000 end:0x04328530
EBI1 MPU Partition 0 start:0x04700000 end:0x0694a000
EBI1 MPU Partition 1 start:0x04500000 end:0x04700000

We have that the memory protection unit (mpu) kicks in at the end of the 1st RAM bank.

Only 0x04328530 to 0x04500000 and 0x0694a000 to 0x07000000 seems unprotected.

I can't count the days to go back and start messing with my kernel ram banks again.

Also any info on the Attributes on partitions? Seems like a restriction, that goes through hex masking.

1st group with hex values like 01 and 22 and 2nd group with hex values of 00000000, 40000000, 80000000, c0000000.

Maybe the 2nd group says from where can be accessed? And probably 01 at 1st group is full rw perms and 22 read only?