yashsingh1/xdaforums huggingface dataset:
[Xperia Arc General] scholbert:
Hi,

just to make it clear again... right now i'm still trying to sort things out, that's why i need little help :fingers-crossed:

Thanks!

So i guess we could definitely mark this as old security fuse setting.

The other values should be similar to the ones i already listed (apart form your unique serial of course).

Thanks as well... looks O.K. for me. So this is the same value.

Did you try the testpoint method already?

If my assumption is correct, then you might be lucky and got old security as well. BTW, i don't want to be responsible for bricked devices ;)

At least this was my intention to get a real indicator for old security and give a clear statement:

Yes, it's safe to try the testpoint method.

So maybe you just be a little patient...

Some words on the production date:

I found out that the sticker on the back gives the production date of your phone.

There's another one on the processor under the shield on the mainboard.

This one is more related to the series of processors used for your mainboard.

My device is marked as 12W11 (sticker under the battery), while the sticker on the processor states 11W44.

See the pic attached.

In other words, they produced an amount of mainboards back in 2011, but the phone itself got assembled in 2012.

Thanks a lot for helping out, i really appreciate this!

Regards,

scholbert
[Xperia Arc General] danielgek:
hi i have a arc s 12w28 i i tryed to execute the viewmem but got nothing

shell@android:/data/local # ./viewmem 0xab60005c 0x4 | hexdump -C
sh: hexdump: not found
[INFO] Reading 4 bytes at 0xab60005c...

am i doing something wrong ??
[Xperia Arc General] panda0:
:fingers-crossed:

Not yet. But if everything works as we're expecting, indeed, I might be a lucky one. I'll see this question ASAP to give some feedback.
[Xperia Arc General] scholbert:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

Partly... the tool hexdump is used to get a formatted output for console.

You'll need at least a version of busybox with the hexdump feature installed.

Maybe your missing some symbolic links.

Try again with this command:

./viewmem 0xab60005c 0x4 | busybox hexdump -C

If the error persists, your version of busybox is missing that feature.

Would be very interesting to get your output though...

Good luck,

scholbert
[Xperia Arc General] danielgek:
shell@android:/data/local # ./viewmem 0xab60005c 0x4 | busybox hexdump -C
[INFO] Reading 4 bytes at 0xab60005c...
00000000 4b 6d 71 00 |Kmq.|
00000004

its an arc s 12w18 loked bootloader and sim loked
[Xperia Arc General] scholbert:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

Mmmh, still the same value... if we trust the statements about date code i would say that this should be new security...

but as i tried to point out already, this could not be taken for granted.

Anyway, locked or unlocked doesn't matter, because i'm looking for security bit in fuse registers.

Did you ever try testpoint method on your device?

Guess we need someone, who already tried the s1tool procedure and got the paket error with his device.

If this phone would give different value on FUSE0 register, it would prove that i'm on the right way.

Thanks for contributing!

Regards,

scholbert
[Xperia Arc General] surfzoid:
Hi scholbert, i will be very happy to have your tweaked version, also, i'm working on LT18I hard bricked, with only the QHSUSB pc connection, i'm running linux and trying to unbrick it :D

Thanks for your job
[Xperia Arc General] surfzoid:
Hi

With the DMSS documentation, i start to play under Monodevelop with C#, i see something very strange, in an windoze virtual machine, with S1tool, i got the following answers from the phone :

0806010100900000

0D1450424C5F446F776E6C6F6164657256455231

with my 2 cent code, i get the following one:

0D1450424C5F446F776E6C6F61646572564552312E30

VERSION:

~

PBL_DownloaderVER1.0~

Param

RECEIVED: 08060101009000001470

PARAM:

~

As we can see, i have extra in the frame response, this is useful?
[Xperia Arc General] danielgek:
yes i have tryed sim-unlock it whit the test point but no success :/
[Xperia Arc General] scholbert:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

AFAIK, SIM unlocking is not possible with s1tool, so i guess you tried it with a differnent tool.

Which error did you get?

Anyway this is a different track, but thanks for the info.

We need some more 12Wxx outputs i guess.

Come on folks...

Best regards,

scholbert
[Xperia Arc General] danielgek:
i will try the s1tool and report back ;)
[Xperia Arc General] scholbert:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

Cool, thanks a lot... but again i won't be responsible for bricks.

Be aware that all i am looking for, is a indicator for new security, s1tool won't help you to get rid of the SIM lock.

Thanks,

scholbert
[Xperia Arc General] danielgek:
yes im aware ;) and what i really want is bootloader unlock not sim unlock ;)

i want the sim unlock if i cant unlock bootloader with another methot ;)

btw can you point me the link for s1tool and what should i do with it ???
[Xperia Arc General] scholbert:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

Yeah, here's one of the threads which will guide you through the process...

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

Please report if you get the paket error...

P.S.: Just a hint... you should use the identify option of s1tool first and make sure that SEMC certficate message is printed.

Good luck,

scholbert
[Xperia Arc General] danielgek:
this is the Log:

25-01-2013 22:42:01 Welcome to S1 tool.
25-01-2013 22:42:01 That is small and crippled subset of SETOOL2 service tool.
25-01-2013 22:44:54
25-01-2013 22:44:54 TO CONNECT NEXT PHONES
25-01-2013 22:44:54 X10 Xperia,E10 Mini,E15 Xperia X8,U20 Mini Pro
25-01-2013 22:44:54 LT15 Xperia ARC,MT15 Xperia NEO,R800 Xperia PLAY
25-01-2013 22:44:54 PRESS AND HOLD "BACK" BUTTON...
25-01-2013 22:44:54
25-01-2013 22:44:54 ST18 Xperia RAY,ST15 Xperia Mini,SK17 Xperia Mini Pro
25-01-2013 22:44:54 PRESS AND HOLD "Volume Down" BUTTON...
25-01-2013 22:44:54
25-01-2013 22:44:54 PLEASE ATTACH TURNED OFF PHONE NOW
25-01-2013 22:44:54
25-01-2013 22:45:32
25-01-2013 22:45:32 RUNNING S1_EROM VER "R9B031"
25-01-2013 22:45:32 SOFTWARE AID: 0001
25-01-2013 22:45:32 LOADER AID: 0001
25-01-2013 22:45:35 FLASH ID: "002C/00B3"
25-01-2013 22:45:35 LOADER VERSION: "R4A069"
25-01-2013 22:45:35
25-01-2013 22:45:35 MODEL (from GDFS): LT18a
25-01-2013 22:45:35 SOFTWARE VERSION: 1253-8238_4.1.B.0.587
25-01-2013 22:45:35 CUSTOM VERSION: 1254-9461_R2I
25-01-2013 22:45:35 FILESYSTEM VERSION: WORLD-a_4.1.B.0.587
25-01-2013 22:45:35 SERIAL NO: BX9034AUL4
25-01-2013 22:45:35
25-01-2013 22:45:35 SEMC SIMLOCK CERTIFICATE
25-01-2013 22:45:35 Elapsed:41 secs.
25-01-2013 22:45:49
25-01-2013 22:45:50 DETACH USB CABLE FROM PHONE
25-01-2013 22:45:50 REMOVE BATTERY FROM PHONE
25-01-2013 22:45:50 ATTACH TESTPOINT
25-01-2013 22:45:50 PRESS "READY", THEN ATTACH USB CABLE TO PHONE
25-01-2013 22:45:50
25-01-2013 22:46:28 PROCESSING ...
25-01-2013 22:46:29 REMOVE TESTPOINT NOW, THEN PRESS "READY"
25-01-2013 22:46:29
25-01-2013 22:46:40 qcReceivePacket: can't get packet start.
25-01-2013 22:46:40 Elapsed:50 secs.

hope it helps ;)
[Xperia Arc General] scholbert:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

Uuuuh kind of...

Here's what i get from it:

- it's obvious that you got a device with new security, because of the paket error

- fuse bits (at least those i found) carry the same value like those with old security

- my method gives no indication for security type

- we're left with try and error (and o.k. there's the date code)

- give s1tool a try with new security device will do no harm ;)

What is left?

I guess nothing for today... it's late.

Anyway it was a nice journey.

Huge thanks to danielgek for helping on this issue!!!

Best regards,

scholbert
[Xperia Arc General] danielgek:
if you discovery something else tell me ,i will help you ;)
[Xperia Arc General] gen_scheisskopf:
Well, my values are quite similar:

root@android:/data/local # ./viewmem 0xab60005c 0x4 | hexdump -C
./viewmem 0xab60005c 0x4 | hexdump -C
[INFO] Reading 4 bytes at 0xab60005c...
00000000 4b 6d 71 00 |Kmq.|
00000004
root@android:/data/local # ./viewmem 0xab600060 0x4 | hexdump -C
./viewmem 0xab600060 0x4 | hexdump -C
[INFO] Reading 4 bytes at 0xab600060...
00000000 47 14 04 e8 |G...|
00000004
root@android:/data/local # ./viewmem 0xab600064 0x4 | hexdump -C
./viewmem 0xab600064 0x4 | hexdump -C
[INFO] Reading 4 bytes at 0xab600064...
00000000 15 08 04 28 |...(|
00000004
root@android:/data/local # ./viewmem 0xab600068 0x4 | hexdump -C
./viewmem 0xab600068 0x4 | hexdump -C
[INFO] Reading 4 bytes at 0xab600068...
00000000 c0 b2 1d b9 |....|
00000004
root@android:/data/local # ./viewmem 0xab60006c 0x4 | hexdump -C
./viewmem 0xab60006c 0x4 | hexdump -C
[INFO] Reading 4 bytes at 0xab60006c...
00000000 b0 01 00 20 |... |
00000004
root@android:/data/local #

But in my case: 0xab600060 = 0xe8041447

So I guess my Xperia has different debug features available than yours?
[Xperia Arc General] scholbert:
another one...

Hey,

thanks for contributing!!!

... to be honest... i don't know for sure :angel:

Some words on that...

I just made a comparisions/conclusions with known things from other Qualcomm chips.

So i assumed that TCSR_CONF_FUSE_1 is similar to MSM7200 because this follows a certain logic.

On the other hand one could say that the structure of the fuse bank should be similar to MSM8260.

This is dual Scorpion as we all know and should be the direct successor of MSM8255.

BTW, everything covered hardly by NDA and we got no MSM8255 documents at all.

Since the investigation on the fuse registers values gave no clearance about the type of security,

i'd like to check on last thing.

What else could identify new security chip?

Right, the chip identifier itself :cool:

This value gives information about the manufacturer, chip family and chip revision.

The chip's hardware id could be read from register at 0xabc00270.

EDIT:

Updated second post http://xdaforums.com/showpost.php?p=36264032&postcount=2

I'd really like to get my hands on a MSM8255 software manual...

Concerning debugging... this should be added here as well:

Devices with JTAG interface disabled got the MARM JTAG Fuse bit blown

(this bit is set to 1 in debug fuse registers of the MSM8255).

If MSM8255 FUSE_1 bit field is like MSM7200 our devices are JTAG disabled by default.

Anyway, please give me your HW_REVISION_NUMBER at 0xabc00270:

./viewmem 0xabc00270 0x4 | hexdump -C

What does the dump give???

Cheers,

scholbert
[Xperia Arc General] gen_scheisskopf:
root@android:/data/local # ./viewmem 0xabc00270 0x4 | hexdump -C
./viewmem 0xabc00270 0x4 | hexdump -C
[INFO] Reading 4 bytes at 0xabc00270...
00000000 e1 a0 57 20 |..W |
00000004

Mine is 0x2057A0E1 (MSM8255T).

Perhaps also TCSR_CONF_FUSE_1 (0xab600060) value depends on SoC used?

Still more reports are required to draw any conclusions- maybe it would be a good idea to make a script to automate dumping?

EDIT:

Maybe it's worth to check kernel sources? I remember that in one of board support files (semc_mogami) there was a check for some kind of hardware ID, not sure which one though
[Xperia Arc General] scholbert:
Hey gen_scheisskopf!

Whoops, this is interesting.

EDIT:

Just saw that the Arc S is listed as MSM8255T model...

Mmmmh yes sure getting more vlaues dumped would clear up things a little bit.

In fact this is stuff is more educational purpose right now. So i guess scripting is not really necessary.

The fact that your device is a MSM8255T should implement that this is "new" security...

At least we know too less about the different models to draw useful conclusions :silly:

Speaking more open...

As the Xperia 2011 is loosing interest already, most will just try to unlock using method A) or B) or leave it as is.

Yeah could be worth looking... though this would give us nothing new...

I assume there could be some exotic variants out there as well (e.g. Core ID: 0x105700E1 which should be a MSM8255 early bird :p).

... it's just the CPU ID nothing more nothing less.

Could be, they changed the OTP ROM code over the chip revisions. That's why i wrote this down again...

Have fun!

scholbert
[Xperia Arc General] gen_scheisskopf:
Yes, it is

Main and perhaps the only difference is SoC- lt15 uses MSM8225 (max clock 1 GHz), lt18- MSM8255T (max clock 1.5 GHz)

Well, to some extent devices can be crossflashed (e.g. ArcS ICS partitioning flashed on Arc) so there should be a way for bootloader/kernel to check on what hardware it is supposed to run
[Xperia Arc General] scholbert:
Re: [REF]Booting/Unlocking Xperia 2011 series: What's under the hood?

Yeah i know... had a short look at pdadb as well.

I guess hardware ID is used for PLL setup, PM core voltage regulation and other stuff in kernel code.

Just realized that danielgek has Arc S as well.

So we need someone with MSM8255 who failed to unlock with s1tool.

Could be that MSM8255T is always new security...

BTW, i found a nice document, covering MSM7xxx efuse details... maybe i put it down here, if there's interest.

Regards,

scholbert
[Xperia Arc General] gen_scheisskopf:
No. I've done testpoint bootloader unlock successfully.

It is possible that 0xab60005c fuse has nothing to do with "real" security, changes could be done to primary bootloader (not replaceable).

IMO s1boot is a second stage bootloader, primary bootloader can be responsible for device security and also flashmode- this feature is present in Sony/SE phones since at least CMD-J5 (and it always worked like now- hold a button, connect the cable and you can "unbrick")

Yes, please :)

EDIT:

There may be no such case, Arc (lt15) was replaced with ArcS (lt18) on the market so I assume all lt15 units have the old security onboard.

Besides if s1tool didn't work there was always official method.
[Xperia Arc General] scholbert:
confidential...

You might be right that we're looking not at the right register.

Though i'd like to know if the trusted boot flag is set (blown) on new security devices, while they left it untouched on the old ones (no sec check on SBL).

There are some statements on the GSM forums, where this could be read between the lines... at least nobody gives any details there.

Concerning OTP ROM, there could be some differences between MSM8255 and MSM8255T.

Though i know from ancient surgery on MSM72xx the OTP will mostly remain the same for a family of devices.

I'm sure there are some cracks (e.g. blagus, the_laser) who might give answers to these issues, but AFAIK they have left the scene.

For the document please jump over to my updated second post http://xdaforums.com/showpost.php?p=36264032&postcount=2

Keep in mind that this covers the former ARM11 CPU family, so bit positions could be different on the Scorpion chips.

Could be correct...

BTW, did anyone made a successful dump from s1boot in the hidden NAND partition on Xperia 2011 (Neo, Arc, Pro)?

I dumped first blocks of RAM but essential parts are missing here... maybe i need to find additonal offsets in RAM.

Anyway, will be just for scientific purposes.

Stay tuned,

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

GSM forums deal with unlocking and repairs using a commercial software/hardware so I don't expect any details given there.

Maybe 1st gen Snapdragon (Nexus One and similar) docs can be found?

How to do it? :)

Iconia A510 had spoken
[Xperia Arc General] scholbert:
Yeah i know, but most of the information the tools are based on had been gathered from XDAdevelopers forum.

I've never seen any so far...

There's a chinese forum with the first pages of MSM8255 manual... still found no way to get my hands on :eek:

No that easy to point it out in a few sentences... though i'll try to do in short:

- re-start stock kernel with kexec suitable for Xperia 2011 and modify kernel cmdline to include partition 4 & 5

(most elegant way, but no working kexec yet))

- write a special mtd-nand driver kernel module which hooks up mtdblock4 & 5

(apart from missing driver for Xperia 2011, the drivers for X10 were reported to give garbled data sometimes)

- locate valid offsets of bootcode while residing in RAM and dump the sections

(managed to do so already... though there are limits here, because we know less about valid offsets for MSM8255)

Anyway i started my disassembly of the RAM dump second time now.

First time disassembly, i got the initial start code and was able to get some offsets of subfunctions (this way i found the hint to TCSR_FUSE_CONF as well)

Second time disassembly just started... to early to say something useful.

Regards,

scholbert
[Xperia Arc General] Dilesh Perera:
hi scholbert

Im trying to get the output of viewmem. but having little issue.

My phone is ST18i , Rooted busy box installed . i have copied vievmem to /data/ local.

when i go to terminal and type chmod +x ./viewmem it says bad mode

Edit--

manage to get the output
[Xperia Arc General] gen_scheisskopf:
It's different from desktop Linux, you have to

chmod 0755 ./viewmem
[Xperia Arc General] Dilesh Perera:
ok thanks . i managed to do it as i posted a pic of it. what can u say by looking it. my one old or new ??
[Xperia Arc General] gen_scheisskopf:
We are not sure if values we are checking represent device security (old/new).

However you've checked wrong offsets, interesintg ones are:

0xab60005c
0xab600060
0xab600064
0xab600068 //optional, this is SoC serial number
0xab60006c

Check them using

./viewmem [offset] 0x4 | hexdump -C

@sholbert, could you make a note in 2nd post that 4th fuse is just a serial number? Otherwise we will drown in speculations ;)
[Xperia Arc General] scholbert:
Yeah my fault, wrote it in the first thread...

In fact this is toolbox related. If chmod is linked to busybox, it will work.

Anyway i changed the description accordingly.

Thanks, nothing to add here...

@Dilesh Perera:

You made a typo, see gen_scheisskopf's comments.

@gen_scheisskopf

BTW, i changed the commands to print the whole register set...

./viewmem 0xab60005c 0x14 | hexdump -C

Yeah maybe... i think it will be required to update and re-structure the thread from time to time.

Thanks for your comments!

Regards,

scholbert
[Xperia Arc General] gen_scheisskopf:
Right, I didn't notice that.

I've read msm72xx qfuses document.

Some comments, assuming of course that msm7x30 is based on msm72xx family:

-the most intersting fuse is FORCE_TRUSTED_BOOT- if set PBL will check itegrity of SBL (so patching s1boot will fail). This may be the "new security" since official bootloader unlocking doesn't change anything in the SBL/BPL

-both SBL and PBL can reside in NAND- see PRIMARY_BOOT_FROM_ROM fuse. Although Qualcomm says to boot from their rom-based PBL the fuse is not set by default. And since Sony likes it's own implementations.... ;)

Maybe it would be possible to dump raw NAND contents? Comparing output with binaries we have (s1boot and other files present in .tft updates) may give a clue about PBL, at least if it's the default one (rom based) or Sony's own (in NAND).

Maybe the flashtool could be used for dumping NAND- it communicates with the device on flashmode level (SBL or even PBL)

EDIT:

"New security" can be also done in hardware- FORCE_TRUSTD_BOOT fuse overrides BOOT_SCUR pin setting, Sony could just change one trace on the PCB without messing with fuses. Either way it seems that FORCE_TRUSTED_BOOT has been enabled
[Xperia Arc General] scholbert:
Yes, i agree with these conclusions.

Because of lacking documentation on the Scorpion single core CPUs, there's much guessing about the correct positions of the fuse bits.

That's the reason i started bootcode disassembly.

Unfortunately i have only RAM dump as a starting point.

The fuse register offsets we are talking about could be found in the first sections of code (starting in RAM at offset 0x0)

You could dump this first section by:

./viewmem 0x0 0x3000 > /sdcard/s1boot_ram1.bin

In fact useful code ends at ~0x2300 afterwards there's padded RAM... untill ~0x90300.

So next dump should start here.

We need to mod the viemem to dump larger amount of mem to go any further (limit is 0x18000 here).

Anyway disassembly is always a lot of guessing though, but i found a lot of interesting areas in the meantime.

There is a real command interface hidden in this bootcode and i found some hints about extensive debugging features.

Though it's hard to put some things together because code is missing again.

Assuming PBL resides in NAND as well is a interesting thesis.

Maybe it's useful again to get things defined properly:

PBL

- very first loader, normally resides in CPU OTP section

- could be possibly in NAND on Xperia 2011 -> external PBL (see comments of gen_scheisskopf)

SBL

- second stage loader

- seems to get executed by MARM (modem ARM processor, a.k.a the baseband processor)

- should be what we call s1boot on Xperia 2011

...TBC

Yeah i was looking for a way already... maybe flashtool could be used, never tried that.

Maybe it would be a nice idea contact some fella's who were involved in cracking X10 loader... (bin4ry, blagus, etc... )

Could be of course... but i don't think that Sony changed the hardware... i still assume that it all relies on the fuse setup, but maybe i'm wrong at this point.

Just to point it out again...

If Sony build there own PBL and placed it in NAND, this would be really strange, but possible.

At least HTC never did that and if PBL is placed in OTP with the trusted boot fuse blown, device is barely uncrackable.

Thanks again for sharing your thoughts ;)

Regards,

scholbert
[Xperia Arc General] Dilesh Perera:
dear scholbert

i tried the gen_scheisskopf mentioned but i dont get any output to them

0xab60005c

0xab600060

0xab600064

0xab600068

0xab60006c

i only get output for below ones

./viewmem 0xabc00270 0x4 | hexdump -C and

./viewmem 0xab60005c 0x14 | hexdump -C

sorry im not good as u guys.....

@ gen_scheisskopf thanks for u too
[Xperia Arc General] scholbert:
Hey Dilesh Perera,

thanks for contributing.

Nice, but i guess you slightly missunderstood.

You made a typo, please try again this:

./viewmem 0xab60005c 0x14 | hexdump -C

... and give the output again.

Thanks a lot!

scholbert
[Xperia Arc General] gen_scheisskopf:
This dumps all register values 0xab60005c-0xab6006f- these are all present on the list in one pass

EDIT:

So without knowledge what is the exact address of qfuse register or without raw NAND dump we are still guessing.

Anyway PBL in NAND would ease the developement of SBL- no need to send any code to Qualcomm (to get it compiled and signed- QCSBL) and no need to worry about proper hooks in the code to get OEMSBL working

EDIT EDIT:

scholbert, check this out, there may be a way to see what's inside reserved NAND area
[Xperia Arc General] scholbert:
These are the qfuse registers (at least the most relevant part), but we need the corresponding bit positions for MSM8255(T) to look behind the curtain :p

There should other fields somewhere as well, e.g. hash of PBL.

Sony could sign their code on their own, if they got private key set from Qualcomm matching OTP ROM signature...

No crypto expert though :eek:

Yeah thanks, for the link again... though i read this already a while ago.

I knew that msm_nand mtd driver uses ATAGs to map the partitions for kernel... it's all inside the mtd driver kernel code.

Anyway would require custom kernel to be flashed or at least got a working kexec environment for Xperia 2011.

Should be the way then.

P.S.:

This thread is getting geeky ;)

Regards,

scholbert
[Xperia Arc General] gen_scheisskopf:
Qualcomm would never ever give any of their private keys to anybody, this would be a possible security breach for their other products.

Document says clearly that QCSL is generated and signed by Qualcomm and not modifiable by customer.

Also not and expert but I have THIS ;)