yashsingh1/xdaforums huggingface dataset:
[Xperia Z Q&A, Help & Troubleshooting] helion_rules:
So, anyone uploads the backups from the different stages for comparing?

Before upload, hexedit your file, search your IMEI, and change it for XXXXX..

Thanks
[Xperia Z Q&A, Help & Troubleshooting] kingvortex:
Guys, read the thread linked to before. A lot of the things that you are talking about have been looked at already ;)

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

Very interesting read, even though a lot of it flies over my head lol.

It seems the security regarding bootloader/drm is very strict and unlikely to be broken easily if at all. See posts by the_laser, lilstevie, Egan and others that know their stuff (sorry can't recall everyone's username :)) for some good info. Basically read through from page 21 as stated before.

Lastly, be very careful messing with the TA partition as it's very easy to end up with a hard brick if you make a mistake.
[Xperia Z Q&A, Help & Troubleshooting] shoey63:
[MENTION=4322181]Tungstwenty[/MENTION] is another one to look for in that thread:thumbup:
[Xperia Z Q&A, Help & Troubleshooting] kingvortex:
Yes, just couldn't remember everyone off the top of my head as it's a while since I read through the thread :D

Some good info posted by some very knowledgeable people in there though. Interesting stuff. :thumbup:
[Xperia Z Q&A, Help & Troubleshooting] shoey63:
Easy for me to remember [MENTION=4322181]Tungstwenty[/MENTION].(I Previously owned Note1)

He's the guy who pioneered the hex patch method for blocking bricking command on Samsung devices on stock kernel without recompiling from source. [MENTION=4666971]Phil3759[/MENTION] adopted it, added his touch recovery and countless bricks have been prevented:D
[Xperia Z Q&A, Help & Troubleshooting] Tungstwenty:
You rang? :)

This 'mentions' feature is really helpful, I wouldn't have found this thread otherwise.

I'll be acquiring my XZ soon and from what I've gathered, I'll be unfortunately in the same boat as those with "Allows unlock: No".

From all that has been discussed so far, unless a serious flaw is found, I don't think it will be possible to do anything more than obtaining root. Perhaps loading kernel modules as well on top of the stock kernel, but not breaking the chain of trust that enforces that only a signed kernel is accepted :(

For parsing the TA contents, check this piece of code I posted.

There's not much science in knowing where the tokens are stored - IMEI, other HW signatures, hash of the unlock key for each device (if it allows unlock), current state, drm master key, etc. etc.

Writing to the TA (or even to the several bootloader partitions AFAIK) is also not a problem, as long as you obtained root.

The fundamental problem is that the several loading phases are all validating the next one with signatures - from the primary bootloader to the sbl1, sbl2, sbl3, the TrustZone, etc.

Even if we manipulate TA entries in any way we want will not solve the problem. The ones containing IMEI or HW ids, the ALLOWS_ROOT flag, the hash of the bootloader unlock key, are all protected behind a signature and tampering with any of those will certainly result in a hard-brick as the bootloader (sbl3, I think) will detect that those entries no longer have valid signatures and will refuse to boot, even to fastboot or any recovery mode -> HARD BRICK.

Just run the code I linked above and check the entries for yourself. You can easily see the "simple values" (inserted unlock key, drm master key, etc.) but you won't be able to edit those compound and more sensitive ones without invalidating the value as a whole.

Patching the sbl code to ignore certain values in the TA and assume the device is unlocked (and even still keep the DRM key) would be trivial. The problem is having the previous sbl stage accept that patched code as valid and not hard-brick :P

Unless someone finds a vulnerability in the signature validations, I don't think it will be possible to tamper with the normal loading process. It's not even a matter of obtaining access to manipulate the TA or whatever, which as I mentioned I think is possible as soon as you have root. The problem is making the device still boot after we apply any changes we like.

In other words, I don't think the vector of attack done in other exploits (or at least a few I've read) will solve it for this case. In those other situations, the found exploits are used to write things that would be otherwise tamper-proof, and the normal boot process is not hijacked.

Oh, one other thing I suggested on the other thread was having the stock (signed) kernel load, and then with root access make it load a replacement kernel and execute it (this would happen on every boot), thus allowing a custom kernel to be used.

But from the received feedback, the stock kernel might be lacking some compile-time features to make it viable...
[Xperia Z Q&A, Help & Troubleshooting] Okluzhion:
Any news on this?

Sent from my SXZ
[Xperia Z Q&A, Help & Troubleshooting] jonnycarter:
Looks like a dead end, not enough interest from devs so unless we get a leak from inside Sony ie: the signing process this is dead water
[Xperia Z Q&A, Help & Troubleshooting] Okluzhion:
Sigh... oh well. Finding out that my bootloader is unlockable was a heavy hit for me since I've come from unbranded/completely unlocked Xperia Arc. When I saw this thread, my hopes went up a bit. Really hope something will come up like on X10.
[Xperia Z Q&A, Help & Troubleshooting] jonnycarter:
Just found this

Not sure it can be any help but an interesting read.

http://blog.gtvhacker.com/2012/root-for-sony-google-tv-with-unsigned-kernels/
[Xperia Z Q&A, Help & Troubleshooting] kingvortex:
As far as I can tell, Sony's Google TV set top boxes use a Marvell SoC, not anything by Qualcomm.

Therefore the security arrangements will not be the same and exploits to break them will be of no use for our device.

Someone correct me if I'm wrong :)
[Xperia Z Q&A, Help & Troubleshooting] Tungstwenty:
The exploit to obtain root should indeed be machine-specific, and not applicable to the Xperia Z. On the other hand, there are already root exploits for XZ.

As for the part about loading an unsigned kernel, this seems to use the kexec technique to replace the stock kernel with a custom one

after

the bootloader has validated and start loading it.

I had suggested this approach before on this post and there were some comments about it not being feasible. I don't have enough kernel dev knowledge to further investigate it.
[Xperia Z Q&A, Help & Troubleshooting] jonnycarter:
Have you looked at how the s4 bootloader has been bypassed?
[Xperia Z Q&A, Help & Troubleshooting] Tungstwenty:
Yes, I've read the juicy details from [MENTION=4229979]djrbliss[/MENTION] on this page but unfortunately the aboot code on the XZ doesn't have that weakness. It doesn't load the kernel + ramfs at a hijackable address prior to validating the signature :(
[Xperia Z Q&A, Help & Troubleshooting] jonnycarter:
Bummer

What about the Motorola's?
[Xperia Z Q&A, Help & Troubleshooting] SXUsr:
Just out of interest, what are Peoples S1 Boot Version under Software Info in the Service Menu? My Phone came from O2 (Locked) and this is mine...

...will be interesting to see the difference between carrier locked and SIM Free Phones.
[Xperia Z Q&A, Help & Troubleshooting] Tungstwenty:
The bootloader I've been analyzing (got a dump from [MENTION=5261329]DevShaft[/MENTION] back in April) is also version "1264-2309 S1_Boot_Lagan_1.0_4".

The bootloader code doesn't need to change between ROM versions (unless holes need to be fixed and Sony does it), and much less between operators.

The lock information is stored in the TA partition and the bootloader code is flexible enough to suit all cases. It validates the several TA entries in order to behave accordingly: currently locked, unlocked, support unlocking or not, etc.
[Xperia Z Q&A, Help & Troubleshooting] Okluzhion:
Mine is 1.0.1_8

SlimBean'd from my Arc
[Xperia Z Q&A, Help & Troubleshooting] Tungstwenty:
If you're referring to this then it is another dead end (I think).

The checks for bootloader status are different; TA will contain an "RCK" token with the official unlock code, and its hash compared with a value (RCK_H) unique for each device, thus preventing brute force. There's also another token ROOTING_ALLOWED="1" which for non-unlockable devices probably contains "0", although I haven't looked at any dump with it.

Also, the vulnerability found on the TrustZone doesn't seem to exist on the XZ. I have looked at the implemented entry points and they are very limited; I haven't found any identical exploits (buffer overflow, or any others for that matter).

Perhaps [MENTION=4229979]djrbliss[/MENTION] would find something else, though, although I'm not sure if there is enough motivation for that since the carrier-free devices can be unlocked officially.
[Xperia Z Q&A, Help & Troubleshooting] :
I disagree with your statement of motivation. For 1 major reason, if you request your code from Sony you Lost warranty... Either, you used your code or not. Your imei is gets logged into another database ,which used by service centers to determinate the rooting status, and suspected modified phones. I repairing them in work, and if any of them got unlocked BL or s-off in htc or their imei is in the manufacturer supplied list they goes "beyond repair" out of warranty or "send to quotation". In this case we contact the owner and ask, if he our she wanted the repair.

If someone make it happen....:rolleyes: can you imagine having all the fun and your warranty in the same time??? Would be nice.

Sent from my C6603
[Xperia Z Q&A, Help & Troubleshooting] Okluzhion:
I wish I had knowledge on Android deving, I feel so useless. :mad: And I just can't seem to understand why so many people are j**king off at Samsung anyway. I really have a feeling like it's only because of the nuts level of advertisement. You can't turn on a tv or exit your house without a Sammy ad jumping out of bloody nowhere.

Sent from my SXZ
[Xperia Z Q&A, Help & Troubleshooting] :
On my droid2 global i seen a similar solution... Loading a 2nd kernel.

Sent from my C6603
[Xperia Z Q&A, Help & Troubleshooting] nikc0069:
I requested my unlock code and have not used it (locked BL, but you never know when it may become useful to have ;) ). I spoke with Xperia chat and as long as the software is not modified, then simply requesting the code does not affect warranty. It is only when you use it your warranty would be void. They can log the IMEI as a suspected modified device all they want but they would need to prove you modified the phone software to void your warranty - you could always request the code and never do anything to the phone!
[Xperia Z Q&A, Help & Troubleshooting] shoey63:
Yep. And if your device is hardbricked, they can't prove anything;)
[Xperia Z Q&A, Help & Troubleshooting] :
They don't. I know by experience. And you know why??? Because there is a way to re lock it and Sony is fully aware of the situation. Once you request, your warranty is over. Full stop.

Sent from my C6603
[Xperia Z Q&A, Help & Troubleshooting] nikc0069:
Then my warranty is over even though I haven't unlocked the bootloader, nay at present can't do so, and therefore run a stock Sony kernel which can't damage the cpu etc unless it is their fault for having a faulty kernel? And if I restore a stock ftf etc to my handset and have an untouched bootloader they would still refuse warranty? I don't doubt your personal experience but if that is the case, and the unlock key request itself voids your warranty despite never being used (I could legitimately request a key and never even take the phone out of its box) then that doesn't seem right, or possibly even legal.
[Xperia Z Q&A, Help & Troubleshooting] jonnycarter:
Can we stay on topic please people.

It's obvious we don't care about warranty if we want this so end of.

Thanks.
[Xperia Z Q&A, Help & Troubleshooting] nikc0069:
Apologies for any offence caused. I felt that warranty implications were implicit with bootloader unlock discussion as those doing their due diligence in researching possible pitfalls in the process would likely come across this.

However, I see how this could be OT so I'm keeping schtumm on this one now :)
[Xperia Z Q&A, Help & Troubleshooting] wyterabitt:
Warranty is not too important, it doesn't change the consumer protection you still have and Sony would still need to fix any problems unless related to the unlocked bootloader (and proven to be so).

Does anyone know how the code is generated? If the code they generate and give you is based on set key on the Sony server that doesn't change (that seems likely) then surely it can be cracked. Although you would need to figure out what information from your phone is being used to generate the number, but you should be able to crack it with enough example codes if people are willing to give them along with info from their phone.
[Xperia Z Q&A, Help & Troubleshooting] nikc0069:
Pretty sure it is generated from your imei via an algorithm. They'll give you an unlock code no matter the status of your "bootloader unlock allowed" though. It just won't work. What needs to be done is find out how to alter the correct property to allow the phone to actually take this without messing up hash checks in the bootloader process - which is 3 stage I think and each stage checks against the previous one. Either that or there is work on kexec so that the stock kernel can then load other stuff, but seems like it may be a hopeless endeavour. It doesn't actually bother me too much as I'm quite fond of the Sony software, but knowing I paid for a device which is not mine to tinker with as I please is the annoyance here for me.
[Xperia Z Q&A, Help & Troubleshooting] Tungstwenty:
The unlocking mechanism is controlled by tokens that exist on the TA partition, so if you dump the contents of the /dev/block/mmcblk0p1 partition to a file and explore the strings within (or parse all the tokens in a more structured way, if you want), you can check the values for your case:

ROOTING_ALLOWED="1" or "0"

This is the first thing checked when receiving the fastboot oem unlock 0x.... command.

If the value is 0, nothing else is done and unlocking the bootloader can't be done (at least not through the standard method)

Then the value you supply is hashed with SHA2 (IIRC), and the resulting value is compared against the RCK_H="......." value that is also stored on the TA.

This makes it impossible to brute force the unlock code until its hash matches the pre-shipped value on each device's unique TA.

One can speculate on whether:

a) Sony merely generates random RCK values for each device, stores them on a private database, and ships the devices with the hash of those values so that afterwards the devices can validate that the code is the expected one

or

b) The calculate the RCK from an algorithm that takes as input the IMEI or whatever, and thus not requiring that they maintain an internal database of all the unique RCK values.

Option b) is more convenient for them, but once the algorithm would be leaked, anyone would be able to generate unlock codes for devices with ROOTING_ALLOWED="1".

Option a) would be the safest way for them to make sure nobody gets the RCK value without requesting it to them.

Both the ROOTING_ALLOWED and RCK_H values are stored in the 0x0E54 entry on the TA.

I'm not sure whether the validation mechanism on those is completely tamper proof (pk signatures, for instance), or there are merely some hidden checks that once understood could be manipulated.

Anyway, any such experiment that writes data to the TA that the bootloader later rejects, leads to a hard brick.
[Xperia Z Q&A, Help & Troubleshooting] nikc0069:
Thanks, that makes much more sense now :)

So what would be needed for unlocking the bootloader on these devices would be clarifying whether there are hidden checks or not? So as I understand it, there is no way to do this without hard bricking lots of phones. Thus making the likelihood of an unofficial unlock very unlikely. Sad news :(
[Xperia Z Q&A, Help & Troubleshooting] nikc0069:
Just to add to this, I have directly (and very politely with much deference to their skills and work may I add) emailed directly both Dan Rosenberg and Adam Outler to see if they have any interest in looking at the Xperia's, given their experience with Qualcomm bootloaders. It may do no good, but never hurts to ask as long as you are polite eh?

PS some good stuff from Dan Rosenberg on the Motorola bootloader does this help in any way? http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html )
[Xperia Z Q&A, Help & Troubleshooting] Tungstwenty:
While extremely interesting, the article doesn't seem to help in our case, as:

- the mechanism used in the Motorola devices is different

- the weakness in the TrustZone that was exploited to fool the mechanism is also not present on the Xperia Z

:(

See my previous post here.
[Xperia Z Q&A, Help & Troubleshooting] nikc0069:
OK looks like you've explored every avenue! :)

I'm getting close to just selling this one and getting one with a unlocked bootloader. Anybody fancy a trade? ;)
[Xperia Z Q&A, Help & Troubleshooting] jonnycarter:
is there any way we can get fastboot working?

can we force it in anyway?
[Xperia Z Q&A, Help & Troubleshooting] kingvortex:
Isn't fastboot already working? I believe it is as there have been a few people that have flashed custom kernels on a locked bootloader and bricked their phone.

I believe that the issue is that the security checks the kernels signature when booting, not that it cannot be flashed in the first place.

(I could be wrong, but I gather this from previous posts in this thread from people that know their stuff).
[Xperia Z Q&A, Help & Troubleshooting] gm007:
No you cannot flash a kernel via fastboot if the bootlader is locked,it will gives you an error while flashing.
[Xperia Z Q&A, Help & Troubleshooting] kingvortex:
Ah OK. I did say I could be wrong :D

Well in that case, even if somehow the flash could be forced, the signature checks would still stop the phone booting, no?

Edit: This person must have flashed via recovery. Their phone did not boot after flashing DoomKernel on their locked bootloader - http://xdaforums.com/showthread.php?p=43529774

That seems to suggest that there is definitely a signature check even if you manage to flash a kernel.
[Xperia Z Q&A, Help & Troubleshooting] gm007:
No it wont flash in any way,that is the job of bootloader's security.
[Xperia Z Q&A, Help & Troubleshooting] kingvortex:
Yes, but I was replying to a question asking if fastboot could be forced to flash.

In that imagined situation, then the signature checks during boot would still not allow a custom kernel to be used if I understand correctly.
[Xperia Z Q&A, Help & Troubleshooting] gm007:
Could be when flashing doom kernel with recovery some system files changed that's why the phone wont boot,but for sure the kernel didn't been flashed.
[Xperia Z Q&A, Help & Troubleshooting] Tungstwenty:
You are correct.

If you manage to flash a non-signed kernel - and you can do it, just not through fastboot (custom recovery, for instance) - if will SOFT-brick because on the next regular boot the bootloader will not accept the kernel. You just need to enter fastboot and flash a stock kernel (or an FTF for that matter) that the bootloader will accept.

Or am I missing something?
[Xperia Z Q&A, Help & Troubleshooting] kingvortex:
But flashing back a stock kernel fixed the problem in that case, suggesting that the kernel was flashed and the security just didn't allow the phone to boot with an unsigned kernel.

Read this post by Tungstwenty - http://xdaforums.com/showthread.php?p=41892742

He goes into a bit of detail on how everything is verified during boot, even mentioning that only a signed kernel is allowed. Why enforce a check for a signed kernel if there is no way to flash an unsigned one?

Edit: I see Tungstwenty beat me to it :D
[Xperia Z Q&A, Help & Troubleshooting] gm007:
I could be wrong but maybe the phone didn't boot has something to do with the recovery?not sure though.
[Xperia Z Q&A, Help & Troubleshooting] shoey63:
Correct. It would be the same as relocking boatloader on custom kernel. Phone won't boot but can be recovered by flashing stock kernel with flashtool. No hardbrick though.
[Xperia Z Q&A, Help & Troubleshooting] jonnycarter:
what im trying to get at with forcing fastboot is could it be used to then execute commands to the bootloader? rewrite the bootloader?
[Xperia Z Q&A, Help & Troubleshooting] shoey63:
Not sure. Interesting approach though.
[Xperia Z Q&A, Help & Troubleshooting] Tungstwenty:
You can still use fastboot, but the list of commands is limited.

For instance, you can issue the one to unlock the bootloader, if you have the unlock key and your device can be unlocked.

You can flash or erase some partitions, but not the kernel one.

As for "rewriting the bootloader", it's code that is stored on a partition just like the kernel, system, etc. but you can't replace it unless you have a new one that has been properly signed. If you replaced it, you'd get stuck on the next boot since it wouldn't meet the signature checks.
[Xperia Z Q&A, Help & Troubleshooting] shoey63:
Ok, so what is needed is for someone to post images of their unlockable TA partion AND bootloader partition(s)?

Edit : that won't work either, due to TA being locked to hardware ID's :(
[Xperia Arc Q&A, Help & Troubleshooting] a12bd1:
I just bought an usb otg cable and it works properly with keyboard, mouse and usb stick.

But I realize there are no way for it to work with joystick, since there are no joydev.ko module for for joypad.

My rom is uHD 3.0.2 with Lupus Kernel v14 ICS, xperia arc S.

Do anyone have the working solution? :confused: :confused:

I have tried joydev.ko from another device and it failed to work.:(
[Xperia Arc Q&A, Help & Troubleshooting] caroku:
Same here

Hi, I have the same problem on Xperia ARC S, CM 9.1 cannot find any solution, please help.
[Nexus 4 Q&A, Help & Troubleshooting] calc:
I was playing some games.. phone crashed. Now when i plug in the power the LED just flashes RED. Can't boot. I can still get into the bootloader but thats it.

I am rooted, unlocked, etc... am ****ting my pants right now. Any tips guys. Searched around the threads not sure what to do ? Maybe restore and RMA...:crying::crying:
[Nexus 4 Q&A, Help & Troubleshooting] calc:
actually now i cant even access fastboot... it shows for a split second and crashes out to blinking red LED
[Nexus 4 Q&A, Help & Troubleshooting] exb0:
plug it in the wall, keep it ther for 10 minutes or so, then try to turn it on again.

This happens when your battery is literally out of charge.
[Nexus 4 Q&A, Help & Troubleshooting] Eagle1337:
Let it charge, the phone's entered the trickle charge mode because the battery is low. It may not recover and if it doesn't it means the battery is having an issue. From my reading of red light issues the solutions have been: let it charge because the battery is to low, it shorted so unplug and replug the battery, or to rma it cause the battery died.
[Nexus 4 Q&A, Help & Troubleshooting] calc:
Sorry guys skipped a boatload of details.... yeah the phone is charged...

I was playing games off the wall charger, believe me it has plenty of power. The light is blinking red can't do anything, no power up.
[Nexus 4 Q&A, Help & Troubleshooting] kishke:
Either RMA or take the phone apart, disconnect the battery wires and reconnect them. There should be a guide somewhere, just look blinking red light of death.