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

finally i managed to get it :) thanks a lot for ur time

app_36@android:/ $ su

app_36@android:/ # cd /data/local

app_36@android:/data/local # chmod 0755./viewmem

Usage: chmod [OPTION] <MODE> <FILE>

-R, --recursive change files and directories recursively

--help display this help and exit

0xab60005c 0x4 |hexdump -C <

[INFO] Reading 4 bytes at 0xab60005c...

00000000 4b 6d 71 00 |Kmq.|

00000004

xab600060 0x4 |hexdump -C <

[INFO] Reading 4 bytes at 0xab600060...

00000000 47 14 04 c8 |G...|

00000004

x600064 0x4 |hexdump -C <

[INFO] Reading 4 bytes at 0x600064...

00000000 7f 5d c3 e3 |.]..|

00000004

ab600068 0x4 |hexdump -C <

[ERR] Wrong arguments!

[INFO] ./viewmem <0xABCDEF> [0x10] [/dev/kmem]

xab60006c 0x4 |hexdump -C <

[INFO] Reading 4 bytes at 0xab60006c...

00000000 b0 01 00 20 |... |

00000004

app_36@android:/data/local #,

app_36@android:/ $ su

capp_36@android:/ # cd /data/local

app_36@android:/data/local # chmod 0755./viewmem

Usage: chmod [OPTION] <MODE> <FILE>

-R, --recursive change files and directories recursively

--help display this help and exit

0xab60005c 0x14 |hexdump -C <

[INFO] Reading 20 bytes at 0xab60005c...

00000000 4b 6d 71 00 47 14 04 c8 15 08 04 28 c0 d4 89 3b |Kmq.G......(...;|

00000010 b0 01 00 20 |... |

00000014

app_36@android:/data/local #

so it is Old security one ? :) value = 0x00716d4b
[Xperia Arc General] scholbert:
Ah.. o.k. i've overseen this.

So this is the way for OTP PBL (the way HTC mostly does it)...

- Qualcomm PBL in OTP area of CPU

- Qualcomm signed QCSBL

Afterwards the manufacturer (OEM) jumps in, with OEMSBL.

On the other hand the OEM "open" model (might be used on the Xperia 2011):

- OEM (Sony) PBL in external NAND

(to make it most secure, PBL could be covered by signage and gets validated by OTP checksum blown to OEM fuse area by Sony)

- OEM (Sony) signed SBL (a.k.a. s1boot)

(security level depends on the used PBL here, PBL does not check SBL -> old security, PBL checks SBL -> new security)

In both cases there should be standard setup for the TCSR_CONF_FUSE area.

If we could interpret this better

Maybe we should compare to a HTC device using MSM8255?

Leave a comment, if this the wrong path...

Thanks!

BTW, some words on low level debugging...

I found a keyword in the bootcode: Dieseldumper2k10

Unfortunately there's not much to be found in the web.

My guess is, that this is a debuging suite for s1boot, similar to this open source project on kernel level:

http://code.google.com/p/lime-forensics/

Here's the official website:

www.digitalforensicssolutions.com

The guys at the MSM8690 development thread had their fingers on that as well.

Cheers,

scholbert
[Xperia Arc General] scholbert:
Hi Dilesh Perera!

We're not yet finished...

...but the values are the same as my device:

FUSE_0 = 0x00716d4b

FUSE_1 = 0xc8041447

FUSE_3 = 0x28040815

BTW, what's your date code?

Regards,

scholbert
[Xperia Arc General] Dilesh Perera:
hi scholbert

its 12W05

EDIT- and did u unlock BL using test point mathod??
[Xperia Arc General] gen_scheisskopf:
I understand that OEMSBL is and "addon" to QCSBL and is not bootable, main code still is held in QCSBL.

OEMSBL is something like a kernel module.

Remember that SBL security may depend on GPIO pin setting. Less likely than a cpu fuse but still possible

We definitely should do it, for both MSM8255 and MSM8255T devices

LiME could be more usefull than viewmem if it can capture all RAM contents
[Xperia Arc General] Dilesh Perera:
:good::good::good::good::good::good::good::good::good:

30-Jan-13 10:16:56 PM Welcome to S1 tool.

30-Jan-13 10:16:56 PM That is small and crippled subset of SETOOL2 service tool.

30-Jan-13 10:17:00 PM

30-Jan-13 10:17:00 PM DETACH USB CABLE FROM PHONE

30-Jan-13 10:17:00 PM REMOVE BATTERY FROM PHONE

30-Jan-13 10:17:00 PM ATTACH TESTPOINT

30-Jan-13 10:17:00 PM PRESS "READY", THEN ATTACH USB CABLE TO PHONE

30-Jan-13 10:17:00 PM

30-Jan-13 10:18:16 PM PROCESSING ...

30-Jan-13 10:18:17 PM REMOVE TESTPOINT NOW, THEN PRESS "READY"

30-Jan-13 10:18:17 PM

30-Jan-13 10:19:02 PM

30-Jan-13 10:19:02 PM TO CONNECT NEXT PHONES

30-Jan-13 10:19:02 PM X10 Xperia,E10 Mini,E15 Xperia X8,U20 Mini Pro

30-Jan-13 10:19:02 PM LT15 Xperia ARC,MT15 Xperia NEO,R800 Xperia PLAY

30-Jan-13 10:19:02 PM PRESS AND HOLD "BACK" BUTTON...

30-Jan-13 10:19:02 PM

30-Jan-13 10:19:02 PM ST18 Xperia RAY,ST15 Xperia Mini,SK17 Xperia Mini Pro

30-Jan-13 10:19:02 PM PRESS AND HOLD "Volume Down" BUTTON...

30-Jan-13 10:19:02 PM

30-Jan-13 10:19:03 PM PLEASE ATTACH TURNED OFF PHONE NOW

30-Jan-13 10:19:03 PM

30-Jan-13 10:19:04 PM

30-Jan-13 10:19:04 PM RUNNING S1_LOADER VER "R4A062"

30-Jan-13 10:19:04 PM LOADER AID: 0001

30-Jan-13 10:19:05 PM FLASH ID: "0098/00B3"

30-Jan-13 10:19:05 PM LOADER VERSION: "r4A069"

30-Jan-13 10:19:05 PM

30-Jan-13 10:19:05 PM

30-Jan-13 10:19:05 PM SEMC SIMLOCK CERTIFICATE, PROCEEDING

30-Jan-13 10:19:05 PM FINISHED

30-Jan-13 10:19:05 PM Elapsed:125 secs.
[Xperia Arc General] gen_scheisskopf:
Odp: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

So it seems that boot procedure is not so simple- what exactly is Loader for? I know that it's present in firmware updates and is somehow connected with partitions (it's a part of lt15 repartitioning solution).

Maybe Sony uses OEM bootloader after all?

Tapatalked from Xperia Arc S
[Xperia Arc General] Dilesh Perera:
bro i dont no much about tech stuff regarding this. but i have unlocked my bootloader using S1 tool.
[Xperia Arc General] gen_scheisskopf:
Easy, my question was a general one ;)

Since you've succeeded with s1tool- you have (had) old security.

@scholbert

I've checked several lt15/18 tft system updates

-loader.sin file is present in all of them

-s1boot.sin is not present in any of them

-Sin Editor (in flashtool) for all loader.sin gives

Partion Info: 00 Spare Info: 00 Content: unknown

-all other files have a "proper" Partition/Spare info fields

My conclusion:

-s1boot may be a SBL (more likley) or OEMSBL (less likely)- it is NOT updated with system updates

-"loader" mentioned in Dilesh Perera's s1tool log may be a simple loader launched by s1boot which starts kernel and passes partition info/cmdline/parameters to it- it is updated along with system and it's required to repartition lt15 (also it might be the cause why kernels made for a given FW don't work correctly with others, at least for Gingerbread)
[Xperia Arc General] scholbert:
Yeah cool stuff... congratulation!!

AFAIK loader.sin is kind of a RAM-based bootloader which is needed as a helper during the flashing process.

At some point the device hands over control to thisn part of code then.

Yupp agreed 100%.

No i don't think that there's any kernel starting up during the s1tool session.

From my point of view it's more like this:

- s1boot could be instructed to load certified code to RAM and start execution of that code

- loader.sin then is capable of accessing NAND on a low level base and could touch partitions as well

- loader.sin follows the same protocol as s1boot

Apart form the s1tool session...

- there could be another simple loader for the kernel afterwards

(which just feeds the kernel with the cmdline, see kexec splboot code at the X10 section or similar projects)

While disassembly of my RAM dump i thought about the following...

By shorting the testpoint to GND, s1boot enters a special mode and seems to accept additional commands.

During the session you'll realize that two different drivers are installed on the host PC (Gordon's Gate drivers).

This goes in line with this thesis.

While in fastboot mode, driver installation is handled by ggsemc.inf, second after shorting the testpoint to GND, an addon get's installed which is handled by Zeus.inf.

Running Zeus driver tells us s1boot is in a special mode now!!!

BTW, i don't know if anyone knows this:

https://github.com/Androxyde/Flashtool/blob/master/S1Protocol_notes.txt

EDIT:

Just an addon concerning s1boot in general:

Of course we know this is the "main" bootloader for the system.

So some parts are XIP while others are executed in RAM, in other words we got different stages here as well.

While GPL'ed bootloaders (e.g. u-boot) offer transparent ways to boot the kernel, offering a cmdline interface and support low level commands to access memory, s1boot needs validation to enter different stages.

Some parts are covered by security level and we need to grant rights to access special functions of the loader.

P.S.:

I know that most of you don't care about all this stuff...

Maybe this thread will give you no end result or something you could show your friends on the school yard or bus stop.

Anyway, i like to ask what's behind the scene and it seems gen_scheisskopf is with me at least :highfive:

BTW, congratulation to your 1000th post!

Thanks and have fun!

scholbert
[Xperia Arc General] gen_scheisskopf:
Here's something:

Successfull unlock- lt18i

Unsuccessfull unlock- lt18a

Both I and A models were sold as ArcS

-succesfull unlock- earlier version of s1boot/erom

-terms "erom" and "gdfs" may just be internal names used by the software (both are present in SE/Sony cellphone line)

Conclusion: "new" vs "old" security may just mean and updated s1boot

EDIT:

Gordon's Gate Driver is used "since always" for all SE/Sony USB devices I've ever had- Sony did the bootloader "their way"

EDIT EDIT:

@scholbert- Warranty Voided could be my middle name ;)

---------- Post added at 12:18 PM ---------- Previous post was at 11:51 AM ----------

Little summary from my side

I. Boot process

1) power on

2) rom-based PBL starts the hardware

3) Secure Boot is not set (both in fuses and GPIO) so PBL executes s1boot

4a) patched s1boot doesn't check anything, just starts the kernel

4b) s1boot check in Trim Area if it's locked or unlocked

5a) bootloader locked- s1boot checks kernel signature, if it's correct- starts kernel

5b) bootloader unlocked- s1boot starts kernel

-still not sure what is "loader" for

II. Bootloader security

-devices with "new security" apparently have a newer version of s1boot

-newer s1boot has a kind of self-protection which makes it inreplecable

a) checks the signatures of everything that can be flashed in it's special mode

or

b) has a smaller number of "extra features" available when testpoint is grounded- it's kinda ReadOnly

Of course I may be wrong, there is still too little data for any trustworthy conclusions

Edit:

removed wrong info from the post
[Xperia Arc General] scholbert:
Hi,

these logs seem to come from different versions of s1tool though.

PM RUNNING S1_LOADER VER "R4A062"

vs

RUNNING S1_EROM VER "R9B031"

Anyway, it seems that the version of R9B031 is not fully responsable for the new security...

First statements from forum.gsmhosting.com:

(http://forum.gsmhosting.com/vbb/archive/t-1508813.html)

Here are some essential statements from support.setool.net forum:

(http://support.setool.net/archive/index.php/t-32395.html)

Specific statements from the_laser:

... we got this comprehensive statement:

http://xdaforums.com/showpost.php?p=11374943&postcount=616

...this leds us to the very start of this thread.

How to identify new security?

Is it only software (version R9B031 and above) or hardware related (occured in 12W14 and later) or is it a mix of both??

BTW, i found some nice strings in my memory dump, seems like a description of the key section (or at least the names of the root-keys in use):

0x90684 R0TMAGIK

0x906bd S1_Loader_Root_773f0
0x906fd S1_Loader_Root_773f0

0x90874 S1_EROM_Root_d6010
0x908b2 S1_EROM_Root_d6010

0x90a27 S1_SW_Root_883f0
0x90a63 S1_SW_Root_883f0

0x90bd6 S1_Cust_Root_96030
0x90c14 S1_Cust_Root_96030

0x90d89 S1_SL_Root_c4220
0x90dc5 S1_SL_Root_c4220

0x90f38 S1_HWConf_Root_08af0
0x90f78 S1_HWConf_Root_08af0

0x910ef S1_Loader_test_Root_8e890
0x91134 S1_Loader_test_Root_8e890

0x912b0 S1_EROM_test_Root_4c370
0x912f3 S1_EROM_test_Root_4c370

0x9146d S1_SW_test_Root_3f3c0
0x914ae S1_SW_test_Root_3f3c0

0x91626 S1_Cust_test_Root_87ee0
0x91669 S1_Cust_test_Root_87ee0

0x917e3 S1_SL_test_Root_f6630
0x91824 S1_SL_test_Root_f6630

0x9199c S1_HWConf_test_Root_0d890
0x916E1 S1_HWConf_test_Root_0d890

The first hex value given is offset in RAM so to check your key section you might use viewmem as well.

Maybe we could identify old and new security level at the keys beeing used :cool:

EDIT:

So finally another thesis what happened to reach new security level:

- Over the period of manufacturing Xperia 2011 Sony updated s1boot (e.g from R4A062 -> R9B031)

could be, that some devices running R9B031 are still unlockable

- At around 12W14 they additionally changed some fuse bit setup (i'm on it right now)

This finally fixed all bugs, made it unbreakable and is known as new security

To be discussed...

P.S.: I guess i'll need to update my first post someday.

Regards,

scholbert
[Xperia Arc General] gen_scheisskopf:
Odp: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

Sorry but mine ArcS from the very beginning had the FUSE0 set to 0x00714b6d (reminder- MSM8255T). S1tool version may not matter, it reads current s1boot version (I'll check what's imside the .exe later).

So either Sony patched s1boot or s1tool wasn't updated for the new s1boot version (official unlock method became available so there was no interest)

Tapatalked from Xperia Arc S
[Xperia Arc General] scholbert:
Yeah i know this is little bit missleading and i'm just gonna modified this.... FUSE0 setup is identical on most devices i guess.

Anyway i'll try to concentrate on differences off the fuses from the devices we know already.

Leaving out the unique ID of course. So i stay concentrated and hopefully not mixing things up again.

BTW, what was your EROM version... ?

Things are moving fast... as i said maybe this will lead to nothing useful in the end... i just contacted danielgek and panda0 again.

Hopefully we got enough output then. I'll put it down together with the EROM versions in my next post i guess.

Maybe this leads to nothing but it's hot right now.

We really should make a version of LiME for our kernels.

Concerning the s1tool, forget about that... the_laser made it, and it's kind of a crypted binary, AFAIK no way to reverse it with IDA.

Maybe you're a lucky hacker though ;)

Agreed.

Stay tuned,

scholbert
[Xperia Arc General] gen_scheisskopf:
Odp: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

There is also another possibility- hardware bug in the SoC itself (like in early Pentium's FPU), devices labelled 12W14 and later may be equipped with newer revision of the chip.

I'll try to check my s1boot version later but I guess I have the older one

Tapatalked from Xperia Arc S
[Xperia Arc General] danielgek:
there you go :

shell@android:/data/local # ./viewmem 0xabc00270 0x4 | busybox hexdump -C
[INFO] Reading 4 bytes at 0xabc00270...
00000000 e1 a0 57 20 |..W |
00000004
shell@android:/data/local # ./viewmem 0xab60005c 0x14 | busybox hexdump -C
[INFO] Reading 20 bytes at 0xab60005c...
00000000 4b 6d 71 00 47 14 04 e8 15 08 04 28 60 f8 ed e7 |Kmq.G......(`...|
00000010 b0 01 00 20 |... |
00000014
[Xperia Arc General] gen_scheisskopf:
So it's 0x00716d4b- the "old" FUSE0 setting

But you have ArcS, date code is in the "unbreakable" range (which starts at 12W14) and you have newer s1boot (R9B031)

Assumption- MSM8255T has different fuse offsets than MSM8255?

My s1boot info:

2013-01-31 22:04:04 RUNNING S1_EROM VER "[B]r9A021[/B]"
2013-01-31 22:04:04 SOFTWARE AID: 0001
2013-01-31 22:04:04 LOADER AID: 0001
2013-01-31 22:04:06 FLASH ID: "0098/00B3"
2013-01-31 22:04:06 LOADER VERSION: "r4A069"

So it seems I have even older s1boot onboard or the r9A021 is the patched one flashed by Wotan software.

BTW is there a way to dump s1boot to hdd?
[Xperia Arc General] scholbert:
FIY, i asked danielgek by PM to dump again the whole set of registers.

I'm close... just awaiting some confirms via PM.

No i don't think so... but there could be a new OTP ROM or another security key setup on the T-models.

Thanks again!

I'll prepare a list with all device we could confirm so far and update my conclusions... this weekend i guess

We're very close it seems.

I've seen none so far... as i already stated, the best would be a working kexec environment and include the missing partitions.

As soon the kernel could bind those to /dev we simply could use dd to shift the raw data to a file.

We need kexec for Xperia 2011!

BTW, yesterday i build the kernel module for LiME to check out what the benefits are for this project.

I tried a RAM dump to my sdcard by inserting the module like this:

insmod /sdcard/lime-msm.ko “path=/sdcard/ram.lime format=lime”

Tried raw mode as well:

insmod /sdcard/lime-msm.ko “path=/sdcard/ram.raw format=raw”

Unfortunately this seems to give access to kernel RAM areas only...

I could not find any relevant parts of bootloader in that dump, which makes it quite useless for low-level hacking (e.g. s1boot RAM dumps).

EDIT:

Quote typo fixed ;)

Regards,

scholbert
[Xperia Arc General] gen_scheisskopf:
This makes sense- pre-12W14 devices shipped with newer bootloader are (rather) unlockable while 12W14+ are not. Looks like new batch of SoC-s arrived at manufacturing plant.

However I doubt that T-models (arcS) have a different security setup- I had no problem with testpoint unlock
[Xperia Arc General] Xperia U <3:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

Hi, I am pretty new to android. I have a Sony Xperia U with an unlocked bootloader. I was wondering if I used pc companion to officially update would I get a FOTA brick?

Thanks Lewie
[Xperia Arc General] gen_scheisskopf:
If you used official unlock method- there should be no problem.

However check in Sony U forums for the information.
[Xperia Arc General] Xperia U <3:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

Thank you;)
[Xperia Arc General] gen_scheisskopf:
I guess that means- testpoint not grounded?

Well..... Does this mean that SBL is not Qualcomm's (QCSBL+OEMSBL)?

What is this check for?

Full partition table :D So you can try to map s1boot using mtdparts and dd it :)

So this is how MACs are "hardcoded"

LOLOLOLOLOL :D (sorry, couldn't resist)

Did Sony pay licence fees for the quote used? ;)

So:

-full partition table is known (for mk16)

-there are still some security checks even though you unlocked the bootloader using s1tool- any idea what is checked?

-there are hardware design flaws in SoC ("Epic Qualcomm failure")

-programmers have red some good books ;)

EDIT:

I have to learn to read.... s1boot is the first block
[Xperia Arc General] mikeioannina:
Which serial adaptor are you using to connect the phone to your computer?
[Xperia Arc General] gen_scheisskopf:
I guess that adapter uses 3.3V signals.

Old school- MAX3232 (requires a COM port)

New- much more possibilities (likely choices- PL2303 or one of FTDI chips)
[Xperia Arc General] scholbert:
Hi!

You definitely would need a self powered adaptor if you want to avoid complete disassembly and extensive fiddling with the device.

By using a self powered adaptor you'll only need the RXD/TXD/GND connection as described in the pic.

I built my own adaptor based on a Digitus RS232 to USB adaptor using a FTDI FT232RL which is capable to be powered with 1.8V for the (LV)TTL IOs. It's little hard to explain the mods i had done to this adaptor and it requires TPS72118 or similar to get the 1.8V supply.

Soldering skills and good tools are needed as well.

Well see the statement above... you'll definitely need to work at 1.8V (LV)TTL level to connect to the device.

A much higher logic level, such as 3.3V, would destroy the input of the Qualcomm processor, so don't try that!!!

There are ready made adaptor cables if you want something out of the box, e.g. TTL-232RG-VREG1V8-WE build by FTDI.

You might purchase one from a professional distributor like:

http://www.rs-components.com/index.html

There might be others as well... but as stated i built my own :D

Anyway hopefully i'll find some time tonight, give some additional information here and also update my first post, because there are some news (i got some additional logs via PM that i'd like to give some comments on).

Thanks for your interest so far and stay tuned!

scholbert
[Xperia Arc General] gen_scheisskopf:
I didn't know that, thx for the tip
[Xperia Arc General] scholbert:
... possible debug UART3 on the Arc (LT15i) and Arc S (LT18i)

Hey,

i will post some more details how to identify the testpoints on other hardware.

Just to inform you about this...

As we know the MK16i (Xperia Pro) and LT15i (Xperia Arc) are very similar considering the hardware design.

So Sony engineers shared the same testpoints on these platforms, though the physical location is different.

As some of you might have realized, some testpoints could not be found in the level 3 schematics floating around.

That's why i had to search and verify the location of debug UART.

Anyway we got information about the mainboard component placement... and guess what... the same testpoints are present there as well.

So far i could only find some blurry FCC pics... see attachment.

If there's interest check these pads and confirm :fingers-crossed:

EDIT:

The UART3 testpoints had been confirmed on LT18i by hillbeast.

See the posts beginning at page 11 for details...

Maybe we could also find some better pics of an Arc (LT15i) opened up, much better would be the mainboard only.

If someone likes to share...

P.S.:

As a side note i would like to read your opinion, if we should present these information in public on xda-developers or if we better remove it.

We know that Sony frequently takes a look around here... and maybe this results in even more closed platforms in the future...

So what do you think?

P.P.S.:

@gen_scheisskopf:

Just looked at the Arc S (LT18), it seems the same here... so if you like soldering give it a try :p

Regards,

scholbert
[Xperia Arc General] gen_scheisskopf:
I guess Sony is aware of (maybe almost) all published info regarding their hardware so IMO there is no point in removing it from here. Unless they "ask" us of course ;)

I don't mind soldering ;)

But first I need to make some level converter (opamp should do the trick for both Rx and Tx- Rx as comparator, Tx as buffer ended with a voltage divider/zener diode) and find some free time.

Does UART3 use 115200 8n1?
[Xperia Arc General] scholbert:
Yes... maybe you're right.

It's also a fact that there are leaks in the service centers, see all these manuals floating around...

This is our profit here.

Yeah i saw those nice tweaks already...

BTW, i forgot to point that out clearly:

UART3 is used at 115200 8N1 (bootloader and kernel)

Concerning the comparator... it's better to use simple open collector buffers to translate between the voltages.

You may remember my hardware threads about the Archos tablets... there should be some information about it (at least i guess so).

Best would be to use one of these "new" FTDI chips, that work properly down to 1.8V.

This is the most elegant solution.

Anyway if you got questions don't mind to ask here.

P.S.:

I guess i'll try the other modes on my PRO (fastboot mode, QHSUSB_DLOAD, testpoint grounded...etc.) and see what the output will be at the serial line.

Maybe i could enter something like a command line interface of one of the bootloaders involved.

Just FYI, my device is still on locked bootloader!

Cheers,

scholbert
[Xperia Arc General] gen_scheisskopf:
FTDI solution is also quite pricey here.

However this works for Kindle
[Xperia Arc General] scholbert:
Mmmh... if it works, will be o.k.

I prefer the properly powered logic though :angel:

Regards,

scholbert
[Xperia Arc General] gen_scheisskopf:
One thing I'd change is the diode for SoC Tx- Shottky diode has 0.1V drop only

DIY FTW :D