Hi, I understand that the G-2PW2100s all share identical hardwares, but are the bootloader partitions interchangeable between the Verizon ones & non-Verizon ones? (<- This is question #1) i.e. Can I for example use NJH47F factory image instead of NHG47Q (Verizon) from https://developers.google.com/android/images#marlin on a Verizon marlin assuming the bootloader is unlocked? Or if the stock rom is already rooted and I can overwrite the bootloader partitions via dd? Or perhaps fastboot boot twrp and then dd the bootloader partitions?
If so, can one say there are then no differences between these G-2PW2100 variants? (<- This is question #2)
Update 1: Since everyone focuses on the unlockability and ignores what's asked above, let me state that I know there's currently no way to unlock the bootloader or root the Verizon Pixel, and the purpose of this thread is to collect information in order to help those stuck with a locked bootloader on Verizon Pixels. If you have such information, feel free to share; repeating "you can't unlock/root" is not helpful. I do not own a Verizon Pixel, and I have absolutely nothing to gain from this; I merely want to give back to the community.
Rooting gives one access to read/write the partitions on the eMMC, therefore gives the ability to overwrite the bootloader partitions, which allows unlocking the bootloader.
Unlocking the bootloader also grants read/write access to the partitions on the eMMC, therefore allowing one to overwrite the partitions on the eMMC.
Sneaking an OTA pre-rooted image may or may not be possible, so is finding another way to gain access such as disabling signature check.
The point is, it comes down to the ability to write the partitions on eMMC; once it's writable, you own everything that's on the eMMC. Most people tend to think it's only about the ability to root/unlock, which isn't exactly false, but it's not exactly true either.
Update 2: According to aboot.c, the last byte of the eMMC controls whether a device can be unlocked or not (assuming the compiled aboot in your device uses this logic) For future reference, code is attached.
I don't think you can fastboot boot twrp img with lock bootloader.
Sent from my SM-G950U using Tapatalk
Nochis said:
I don't think you can fastboot boot twrp img with lock bootloader.
Sent from my SM-G950U using Tapatalk
Click to expand...
Click to collapse
Right, but if there's a way to flash or write to the partitions, it should be able to convert a Verizon Pixel to a non-Verizon Pixel. That's what I'm trying to confirm.
AncientDeveloper said:
Right, but if there's a way to flash or write to the partitions, it should be able to convert a Verizon Pixel to a non-Verizon Pixel. That's what I'm trying to confirm.
Click to expand...
Click to collapse
You can't overwrite a locked bootloader...that is the very definition of a locked bootloader. Yes, you need root. Root either temporary or permanent is what is needed to unlock the VZ phones. This has been covered a million times here.
TonikJDK said:
You can't overwrite a locked bootloader...that is the very definition of a locked bootloader. Yes, you need root. Root either temporary or permanent is what is needed to unlock the VZ phones. This has been covered a million times here.
Click to expand...
Click to collapse
The question asked in the post was that if this was doable, then there should be no differences between the 2 variants? I have not asked if unlocking the bootloader is possible at the moment.
Go ahead, brick it. You can't. Same hardware doesn't mean same software, there's still a difference.
martinez5241 said:
Go ahead, brick it. You can't. Same hardware doesn't mean same software, there's still a difference.
Click to expand...
Click to collapse
The Verizon image is obviously different than the non-Verizon one. That's a proven as the checksums are different. The question asked was that by loading the non-Verizon image into a Verizon Pixel, does it effectively make the phone non-Verizon since the hardware is the same?
Lets clear up some misconceptions here.
The phones ship with exactly the same image. It is not until you put in a VZ SIM do you get the different image. And it is only changes to radio and some network settings. Don't matter where you bought it, and it has nothing to do with locking.
Verizon does not lock the phone. They all ship locked including Googles. When you start it up it phones home to Google and Google decides if the phone qualifies to be unlocked. If so it unlocks. Verified with packet captures.
You will not unlock this phone without root. You will not flash anything other than OTA's without root.
If Rooted
yes on the first
NO on the second
TonikJDK said:
Lets clear up some misconceptions here.
The phones ship with exactly the same image. It is not until you put in a VZ SIM do you get the different image. And it is only changes to radio and some network settings. Don't matter where you bought it, and it has nothing to do with locking.
Verizon does not lock the phone. They all ship locked including Googles. When you start it up it phones home to Google and Google decides if the phone qualifies to be unlocked. If so it unlocks. Verified with packet captures.
You will not unlock this phone without root. You will not flash anything other than OTA's without root.
Click to expand...
Click to collapse
chazall1 said:
If Rooted
yes on the first
NO on the second
Click to expand...
Click to collapse
Since we're on the "unlockability" subject, we know that once it normal boots with a Verizon SIM, it becomes not unlockable; but does anyone know if it's because the phone contacts Verizon/Google & received "you can't unlock" command, or the baked-in factory image is pre-programmed to do this once the phone boots with a Verizon SIM?
Technically, one would just need to gain access to write to the eMMC; rooting is one way to gain such access.
AncientDeveloper said:
Since we're on the "unlockability" subject, we know that once it normal boots with a Verizon SIM, it becomes not unlockable; but does anyone know if it's because the phone contacts Verizon/Google & received "you can't unlock" command, or the baked-in factory image is pre-programmed to do this once the phone boots with a Verizon SIM?
Technically, one would just need to gain access to write to the eMMC; rooting is one way to gain such access.
Click to expand...
Click to collapse
It has nothing to do with the sim. This has been covered a million times. Some think it's the cid. Others think it's the IMEI. Either way it's nothing you can get around without temp root.
toknitup420 said:
It has nothing to do with the sim. This has been covered a million times. Some think it's the cid. Others think it's the IMEI. Either way it's nothing you can get around without temp root.
Click to expand...
Click to collapse
I don't have a Verizon Pixel to verify what you're saying, but according to this post, what you said is not true. Either way, I'm just trying to study the specifics and help the community, and I have nothing to gain or lose by either helping or not helping the community.
As mentioned, "rooting" is one way to gain access to write the system onto eMMC, unlocking bootloader is another; there may or may not be other methods. Saying one cannot get around without temp root is quite an absolute statement. And yes, I have also read most of the "million" threads.
AncientDeveloper said:
I don't have a Verizon Pixel to verify what you're saying, but according to this post, what you said is not true. Either way, I'm just trying to study the specifics and help the community, and I have nothing to gain or lose by either helping or not helping the community.
As mentioned, "rooting" is one way to gain access to write the system onto eMMC, unlocking bootloader is another; there may or may not be other methods. Saying one cannot get around without temp root is quite an absolute statement. And yes, I have also read most of the "million" threads.
Click to expand...
Click to collapse
Okay let me definitively explain this.
VZW Pixel's run the EXACT same software Google Store Pixel's that insert a VZW SIM get. The factory image you run doesn't affect your unlock ability at all.
A Google Store Pixel will update to the VZW build if a VZW SIM is inserted.
DISCLAIMER: From here down is conjecture based on my findings, reverse engineering, and things said/found around the forums.
/** begin my thoughts **/
A few things affect unlock ability (this isn't a catch all list, just from my findings):
1. Is the device SIM locked? - if yes, return grey out "Allow OEM Unlock" switch, if no, continue.
2. Is the device IMEI/MEID on approved by Google to be unlocked? - if this is met, allow "Allow OEM Unlock" to be checked, if not, continue checks.
3. Is the CID a non-unlockable CID (CID = Carried ID ex. VZW___001 on VZW sold Pixels) - if this is met (meaning that the CID is on a specific list of CID's like VZW's for example), grey out "Allow OEM Unlock", if not, allow "Allow OEM Unlock" to be checked.
If when the device connects to Google's servers it passes the above checks, the switch can be toggled.
If the switch can be toggled, you can unlock your device.
Hence why random VZW Pixels are unlockable for no apparent reason, their IMEI isn't VZW's or it doesn't have the VZW MEID (which comically is "vzwmeid"), then the CID being one of a locked device doesn't matter, because that check is never reached.
/** end my thoughts, back to cold hard facts **/
Though I may not be certain of the exact order/magnitude of the checks, the same basic principle applies, its a list of if/then statements. "Flashing an unlocked bootloader" doesn't even make sense in the context of 99% of devices. If you were on a VZW Pixel, and magically were able to flash a non-VZW generic factory image, bootloader set and all, you'd still be unable to unlock all the same.
Now, what else do we know? The device's switch can be toggled if /data/system/users/ 0.xml reports <restrictions> as "false".
This file cannot be edited without root, which many will say "...requires an unlocked bootloader...", but that isn't right.
Currently there are 3 main methods to root access:
- /system/ root - in which the SU binary is put in /system/, as /system/ already has the set-suid capability (which allows SU to actually work), this used to be the go to way, but as of DM-Verity's unveiling in Android 6.0 Marshmallow, we can't remount the system partition read/write, as the verity contexts would be changed, and the device would refuse to boot (and I haven't seen any public DM-Verity bypasses/vulnerabilities). An example of this is SuperSU installed in "System Mode". This can't be used on Locked Bootloader devices (running higher than Android 6.0 Marshmallow), because DM-Verity is enforced in the kernel (which is signature checked).
- Boot Image Root - in which the SU binary is put in the ramdisk, which has the set-suid capability (which allows SU to actually work), this was ChainFire (and later everyone else's) method to root Android 6.0 Marshmallow and beyond while respecting DM-Verity, with this method, we still can't remount the system partition read/write, as the verity contexts would be changed, and the device would refuse to boot (and I haven't seen any public DM-Verity bypasses/vulnerabilities). An example of this is SuperSU installed in "System-less Mode", or any Magisk installation. This can't be used on Locked Bootloader devices because the ramdisk is signature checked.
- Temporary Root - in which the SU binary is either put in /system/ in memory (like we saw with the DirtyCow vulnerability/exploits), or in the /data/ partition (this won't work unless we use some method to give /data/ the set-suid capability). To explain a little more, you've likely seen devices with Locked Bootloaders and /system/ write protection making use of these temp-root setups, like carrier editions of the Samsung Galaxy Note 4/5 with locked bootloaders, and of HTC phones that are S-ON/Bootloader locked. On these devices the exploit needs to be re-run after each boot (hence the "temp" part of temp-root).
The Pixel's can't be rooted with the top two methods due to the combination of DM-Verity and the bootloader being Locked. Though, temp-root can work.
All dePixel8 did was temp-root the Pixel's, remove the restrictions in that file (no proof of this one, though I believe it did), and manually set the "unlockable" bit that the "Allow OEM Unlock" sets when flipped on.
Hence why JCase (one of its creators) said "If anyone hands us a temp-root, we will release another unlock for the Pixel's.". It is literally as simple as plugging in the new temp-root exploit.
Now, the problem with finding a temp-root solution for the Pixel's is that they are one of the most secure and updated devices on the market, often getting Android's monthly security patches before any other device. What I would do it I were serious about it (and let me tell you, I am not), is surf the Android security bulletins and CVE boards for "Privilege Escalation" vulnerabilities that have public PoC's or exploits, and then either further reverse dePixel8 to figure out what bit they set, or just ask JCase, because if you can prove you have temp-root working, I'd bet he'd be friendly enough to talk it through with you. Now granted, that train of thought will only result in an unlock for a previous month's security patch level, but it is better than nothing.
As I noted above, I am not putting this here to express interest in me working on this (for those that might recognize me from my S4 research, or other security ventures), but have seen so much misinformation on these forums, and so much general misunderstanding that I felt it would be helpful to throw this out publically.
Tl;DR: Please link the confused to this post.
npjohnson said:
Tl;DR: Please link the confused to this post.
Click to expand...
Click to collapse
Thank you for your time and effort. I did not want to explain all that. I was attempting to collect information, but instead ended up explaining myself and replying replies that weren't related to the questions I asked.
Anyway, here's a minor update: According to the aboot.c code (and assuming the logic is not modified), the last byte of the eMMC controls whether the device is unlockable. Having root would be nice as it allows the user to write anything onto the eMMC, which makes this rather easy if it's a matter of overwriting one byte.
AncientDeveloper said:
Thank you for your time and effort. I did not want to explain all that. I was attempting to collect information, but instead ended up explaining myself and replying replies that weren't related to the questions I asked.
Anyway, here's a minor update: According to the aboot.c code (and assuming the logic is not modified), the last byte of the eMMC controls whether the device is unlockable. Having root would be nice as it allows the user to write anything onto the eMMC, which makes this rather easy if it's a matter of overwriting one byte.
Click to expand...
Click to collapse
Which aboot.c are you analyzing?
1. Google uses its own lock/unlock mechanism, much alike many other OEM's.
2. msm8996 uses non-standard LK, so it the public LK logic isn't necessarily what we use.
npjohnson said:
Which aboot.c are you analyzing?
1. Google uses its own lock/unlock mechanism, much alike many other OEM's.
2. msm8996 uses non-standard LK, so it the public LK logic isn't necessarily what we use.
Click to expand...
Click to collapse
Yes, in fact, the public aboot.c requires OEM implementation in order for it to work as some functions are merely defined as interfaces where OEM has to implement the actual code.
Perhaps I should've been more clear on "assuming the logic is not modified". What I meant was, if the OEM did not change the specific position of the unlock byte, this is where it'd be. Of course, there's no way to verify this without (1) obtaining the OEM aboot.c or (2) experimenting it on a device. One of the OnePlus for example, stores it at position 0x000FFE10.
This particular aboot.c is listed under quic/la from codeaurora under a late enough branch, where marlin is under.
Hope this clears things up a bit.
AncientDeveloper said:
Yes, in fact, the public aboot.c requires OEM implementation in order for it to work as some functions are merely defined as interfaces where OEM has to implement the actual code.
Perhaps I should've been more clear on "assuming the logic is not modified". What I meant was, if the OEM did not change the specific position of the unlock byte, this is where it'd be. Of course, there's no way to verify this without (1) obtaining the OEM aboot.c or (2) experimenting it on a device. One of the OnePlus for example, stores it at position 0x000FFE10.
This particular aboot.c is listed under quic/la from codeaurora under a late enough branch, where marlin is under.
Hope this clears things up a bit.
Click to expand...
Click to collapse
If you need some one to test this theory out for ya, I've got a VZW Pixel xl. I've also got a Nexus 6p I can fall back on if we "F UP" my Pixel. Plus I've brought back a lot of phones from brick. Even the Bootloader locked LG Flex. And those Flex owners thought it couldn't be done.
mattwheat said:
If you need some one to test this theory out for ya, I've got a VZW Pixel xl. I've also got a Nexus 6p I can fall back on if we "F UP" my Pixel. Plus I've brought back a lot of phones from brick. Even the Bootloader locked LG Flex. And those Flex owners thought it couldn't be done.
Click to expand...
Click to collapse
That's very brave of you. I've been exploring the possibility of using EDL (QDLoader 9008) mode to overwrite the whole eMMC with an already-unlocked image. Pixel is in an unique position to try this as all US versions share the same hardware (except marlin vs sailfish), so there shouldn't be a reason why they can't run the same image.
Shameless bump.
Related
***This is not a bootloader unlock. This is only a discussion about a possible bootloader unlock***
So I've been following this blog for the past couple of weeks. The owner of the blog describes an exploit to run arbitrary code in trustzone kernel in msm8974 chipsets (post1, post2, post3).
Trustzone is responsible for stuff like android keystore, decoding audio and video with DRM and has absolute control over every bit of hardware inside the chipset.
Most importantly the Qfuses checked by the bootloader to determine if it's unlocked or not.
Now, I've been looking at the deassemblies of trustzone images extracted from firmware versions 4.3.6, 3.5 AT&T, 3.6.2T-MobileDE.
The bug caused this exploit is in fact fixed in firmware 4.6.3. I didn't test 4.6.1 because probably it is fixed.
Anyway, In firmware versions 3.5 and 3.6.2 the bug is still present. Meaning that we would probably be able to run arbitrary code on the devices with old firmware, or if we can downgrade our phones to 3.6.2 firmware.
The first problem we have is, the exploit needs a slight kernel driver modification to run. (that is if we are not going to use his "zero write primitive" to blow a Qfuse).
But in our devices we can't even boot a custom kernel! (fastboot kernel hotbooting complain even if you pass a signed boot image, saying "boot not allowed in locked HW").
So we might need to find a way to use "kexec" to hotswap a kernel at runtime. Which in turn might need a modified kernel module to be loaded.
We still don't know if we can load unsigned kernel modules to the stock kernel.
The next problem is to find the correct Qfuse to blow, If we blow a wrong one, We can say our device goodbye.
This would need an analysis of aboot partition image (emmc_appsboot.mbn) to find which Qfuse aboot check for bootloader unlocked. (take a look here to know more about this)
So a very simple outline of what we have to do is,
1)Find a way to downgrade to firmware/trustzone 3.6.2
2)Get kexec to run a custom kernel
3)Run the trustzone exploit to blow the correct Qfuse
Now, I'm not very good at reverse engineering stuff since I'm still a newbie, I need help from everyone.
Reply if you have any ideas and contributions. any kind of feedback is appreciated.
Hello @madushan1000,
Here seemed an appropriate place to reply to your PM
Some points to consider:
- Safestrap doesn't use kexec, it uses 2nd init which hijacks the boot process to load a different ramdisk
- Therefore you won't be able to use anything from Safestrap including 2nd init to enable loading a new kernel
- Also note kexec is not enabled on stock kernel builds so at least the exec part is out the window.
- I checked the aboot of 3.5.x and 4.6.1 and noted that the exploit used on the Kindle HDX tabs to bypass/unlock the bootloader have been patched up.
- Other than that: It seems the bootloader is going to remain locked on our devices - Though I hope I am wrong.
More info on the trustzoon exploit can be found in the posts I linked above.
Anyway, I don't think we can use HDX bugs even if the aboot bug was present because there is no unlock partition found on the device and flashing to any kind of partition is absolutely prohibited.
We are going to do what described in this post (http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html) using the trustzoon exploit.
As per kexec, there is a kexec kernel module developed at Xperia forums, I can try to port it to fire phone. Probably wouldn't be too hard because it was built for msms8974 kernel too.
Anyway, Does anyone had gone back to 3.6.2 from 4.6.1 without bricking the device?
Wow, I just found out you can't load unsigned kernel modules too.
madushan1000 said:
***This is not a bootloader unlock. This is only a discussion about a possible bootloader unlock***
So I've been following this blog for the past couple of weeks. The owner of the blog describes an exploit to run arbitrary code in trustzone kernel in msm8974 chipsets (post1, post2, post3).
Trustzone is responsible for stuff like android keystore, decoding audio and video with DRM and has absolute control over every bit of hardware inside the chipset.
Most importantly the Qfuses checked by the bootloader to determine if it's unlocked or not.
Now, I've been looking at the deassemblies of trustzone images extracted from firmware versions 4.3.6, 3.5 AT&T, 3.6.2T-MobileDE.
The bug caused this exploit is in fact fixed in firmware 4.6.3. I didn't test 4.6.1 because probably it is fixed.
Anyway, In firmware versions 3.5 and 3.6.2 the bug is still present. Meaning that we would probably be able to run arbitrary code on the devices with old firmware, or if we can downgrade our phones to 3.6.2 firmware.
The first problem we have is, the exploit needs a slight kernel driver modification to run. (that is if we are not going to use his "zero write primitive" to blow a Qfuse).
But in our devices we can't even boot a custom kernel! (fastboot kernel hotbooting complain even if you pass a signed boot image, saying "boot not allowed in locked HW").
So we might need to find a way to use "kexec" to hotswap a kernel at runtime. Which in turn might need a modified kernel module to be loaded.
We still don't know if we can load unsigned kernel modules to the stock kernel.
The next problem is to find the correct Qfuse to blow, If we blow a wrong one, We can say our device goodbye.
This would need an analysis of aboot partition image (emmc_appsboot.mbn) to find which Qfuse aboot check for bootloader unlocked. (take a look here to know more about this)
So a very simple outline of what we have to do is,
1)Find a way to downgrade to firmware/trustzone 3.6.2
2)Get kexec to run a custom kernel
3)Run the trustzone exploit to blow the correct Qfuse
Now, I'm not very good at reverse engineering stuff since I'm still a newbie, I need help from everyone.
Reply if you have any ideas and contributions. any kind of feedback is appreciated.
Click to expand...
Click to collapse
How do you know there's a bit in the QFPROM dedicated to unlocking the bootloader? Doesn't that seem kind of like an oversight since there's one you blow to lock it in the first place? Blowing a random fuse will just brick your phone and I'll tell you right now there's no bit to unlock it. The bug has been patched for quite a while and even if it did work, I'm doubtful you'd find what you're looking for.
Well, I don't know. That's why this is still work in progress. But still, As pointed out in the original post, the is one qfuse which is blown after first factory flash to mark the device as bootloader locked. Then there is another one (which is not blown in almost all the msm chipsets in case vendor change their mind and offer a unlock in the future) which mark the device as permanently unlockable. Even if this fuse is blown, by gaining arbitrary code execution in trustzoon we might be able to trick the bootloader in to thinking device is unlocked.
Don't worry, I'm not going to start blowing qfuses up blindly. First I'm going to identify if there is such a qfuse at all by looking at the aboot drassembly. Then try reading their values first to verify it is in fact not blown. Then I'm going to blow stuff up when I can afford a new phone
Even before that, I have to find a way to downgrade trustzoon and find a way to load unsigned kernel modules. I have no illusions, I'm very very far away from unlocking this thing.
And which bug you are referring to? The new trustzoon bug I mentioned or the previous trustzoon bug?
kaboom away
madushan1000 said:
Don't worry, I'm not going to start blowing qfuses up blindly. First I'm going to identify if there is such a qfuse at all by looking at the aboot drassembly. Then try reading their values first to verify it is in fact not blown. Then I'm going to blow stuff up when I can afford a new phone
Click to expand...
Click to collapse
With the current fire sale on these phones, you can probably afford to blow up as many as you want. I cannot believe the prices on these babies right now, that is, if you are into Prime, or don't mind reselling the Prime. I am almost ready to buy a third one.
LNRrgB said:
With the current fire sale on these phones, you can probably afford to blow up as many as you want. I cannot believe the prices on these babies right now, that is, if you are into Prime, or don't mind reselling the Prime. I am almost ready to buy a third one.
Click to expand...
Click to collapse
The sad thing is, Amazon prime is not available, let alone fire sales I would definitely love to get my hands on few more.
madushan1000 said:
The sad thing is, Amazon prime is not available, let alone fire sales I would definitely love to get my hands on few more.
Click to expand...
Click to collapse
it's $124.99 in ebay, brand new, prime and warranty.
Yup, ebay has the 32GB and the 64GB for sale right now, with Prime ! Seller is qualitycellz .
litan1106 said:
it's $124.99 in ebay, brand new, prime and warranty.
Click to expand...
Click to collapse
Now $119
Perhaps, after all stock containing Prime is depleted, we will get a bootloader unlock...
Wow, If I only had the money. Wish the stock will hold untill I graduate next month and get a job.
Do google know that we've unlocked the bootloader? (as Sony do as they ask for email adresses etc and confirm the ulock)
Wondering about warranty.
there is a notice about unlocking of bootloader may violate warranty . thing is it is stated in a somewhat vague manner, it is not like CAUTION YOU ARE ABOUT TO VIOLATE WARRANTY but rather worded like you may be in violation of warranty. anyway, i think it does violate and yes there is most likely a software switch that sets a value in hardware register which can be recovered to determine that the bootloader was unlocked. if you have the least bit of concern do not unlock.
dkryder said:
there is a notice about unlocking of bootloader may violate warranty . thing is it is stated in a somewhat vague manner, it is not like CAUTION YOU ARE ABOUT TO VIOLATE WARRANTY but rather worded like you may be in violation of warranty. anyway, i think it does violate and yes there is most likely a software switch that sets a value in hardware register which can be recovered to determine that the bootloader was unlocked. if you have the least bit of concern do not unlock.
Click to expand...
Click to collapse
Ok thanks.
One last google noob question; does rooting usually need an unlocked bootloader?
On xperia root is more difficult to achieve with a locked bootloader, but can be done, thanks to the devs.
I guess I will read the 6P thread to get a feel for the situation.
Cheers again.
i do not know if it is possible, in practice as far as i know it is necessary to unlock if any modification is wanted. recently it is popular to gain root without mod of /system partition. hopefully that is what is achieved with the pixel c.
edit: never done this but, fastboot boot recovery recovery.img then flash a superuser from temp recovery. however it seems you would still be restricted from mod of /system
in future.
dkryder said:
i do not know if it is possible, in practice as far as i know it is necessary to unlock if any modification is wanted. recently it is popular to gain root without mod of /system partition. hopefully that is what is achieved with the pixel c.
edit: never done this but, fastboot boot recovery recovery.img then flash a superuser from temp recovery. however it seems you would still be restricted from mod of /system
in future.
Click to expand...
Click to collapse
If you use fastboot boot then you do not need to specify a partition (only if using fasboot flash *partition* image.img).
The device is still very new but im sure a custom recovery will be released soon so an easy root can be achieved.
MArk.
mskip said:
If you use fastboot boot then you do not need to specify a partition (only if using fasboot flash *partition* image.img).
The device is still very new but im sure a custom recovery will be released soon so an easy root can be achieved.
MArk.
Click to expand...
Click to collapse
I sure hope so. That's one of the only things keeping me from buying it already. It's kind of worrisome that the development forums are almost completely dead (save for the one thread trying to get root without a custom recovery, of course). I guess I'm just spoiled by using only Nexus devices, so having very active development is usually the norm.
well, the thing was only a rumor about sales start up until a report in a german site on 12/5 or so that sales would start 12/8 and then on 12/8 a confirm that at 1pm eastern u.s.a. sales would begin. talk about giving people a decent notice about a device this pixel c was a new low for google. it's almost they decided to sell them as android tablet at last moment instead of tossing in trash as a complete failure as chrome os tablet so, yeah, it will take a while for anyone that has skill to develop this device to ante up the funds and take delivery. if bootloader remains locked and boot temp recovery to flash supersu does that restrict the root in any way? i am just curious about this as my bootloader is unlocked.
This thread is intended for the Droid Turbo 2. For the lucky Moto X Force owners, this thread shouldn't apply to you.
I think there are some brilliant minds lurking on this forum and I'm hoping there could be some research done to "encourage" the possibility of attaining root and boot loader access on our Droid Turbo 2 Devices.
My approach here is to establish a collection of "Zero Day Bugs". Security flaws found in our devices that would put our OS as risk. As far as I can tell, Google keeps a record database and the media likes to talk about zero-day discoveries. Of course these bugs need to be timely so zero-day flaws found in 2014 or early 2015 likely were patched with the launch of the DT2.
For example, below is a link to a Zero-Day exploit that elevates the privileges of an app. Can something like this be used? Who has the technical expertise to replicate such an exploit? This thread is to talk about these things.
http://perception-point.io/2016/01/...f-a-linux-kernel-vulnerability-cve-2016-0728/
Hopefully this will spur up some traction and help get us root and bootloader.
Exploit found for Turbo 2 that can grant root access
Given the widespread impact of this exploit, it is likely other device owners are going to try to implement this exploit as well. Please post here if you find any implementations for other devices as it may be usable for the Turbo 2.
It has been confirmed that Quadrooter can exploit the Turbo 2: http://www.zdnet.com/article/quadrooter-security-flaws-affect-over-900-million-android-phones/
Four vulnerabilities (CVE-2016-2059, CVE-2016-2504, CVE-2016-2503, CVE-2016-5340)
And just an FYI:
"ALLOW OEM UNLOCKING" DOES NOTHING ON THE DROID TURBO 2
Click to expand...
Click to collapse
windraver said:
This thread is intended for the Droid Turbo 2. For the lucky Moto X Force owners, this thread shouldn't apply to you.
I think there are some brilliant minds lurking on this forum and I'm hoping there could be some research done to "encourage" the possibility of attaining root and boot loader access on our Droid Turbo 2 Devices.
My approach here is to establish a collection of "Zero Day Bugs". Security flaws found in our devices that would put our OS as risk. As far as I can tell, Google keeps a record database and the media likes to talk about zero-day discoveries. Of course these bugs need to be timely so zero-day flaws found in 2014 or early 2015 likely were patched with the launch of the DT2.
For example, below is a link to a Zero-Day exploit that elevates the privileges of an app. Can something like this be used? Who has the technical expertise to replicate such an exploit? This thread is to talk about these things.
http://perception-point.io/2016/01/...f-a-linux-kernel-vulnerability-cve-2016-0728/
Hopefully this will spur up some traction and help get us root and bootloader.
Click to expand...
Click to collapse
Could be used on a Terminal Simulator and get the bootloader lock transistor to break safety.
But honestly, my first thought would be to force into QHSUSB_DLOAD and somehow inject all XT1580 stuff to get it recognized as such.
I have installed one-click root (I got it through another site, not from them) and it sometimes says failed to root, but other times, it goes through the process, says it's done and to reboot, but when rebooting it does not have root. I have tried running other apps, like King Root, or Root Genius, or half a dozen others to get it to root, after getting one-click to say it has rooted it. Not sure if this will help or not, and honestly, I'm to the point, I'm ready to give up and do something different. I WILL NEVER buy another Verizon phone, ever! I may not drop them as a carrier, but I wont be keeping their crappy locked junk.
brannonwj said:
rant
Click to expand...
Click to collapse
From what I understand, this thread is for brainstorming. Not ranting about how you didn't do your research.
not a rant
Techn0Luigi said:
From what I understand, this thread is for brainstorming. Not ranting about how you didn't do your research.
Click to expand...
Click to collapse
That wasn't a rant about how I didn't do any research. IT was a what I did that might lead to someone having an idea of how it might help.
Don't be a jerk.
mr_verystock said:
Could be used on a Terminal Simulator and get the bootloader lock transistor to break safety.
But honestly, my first thought would be to force into QHSUSB_DLOAD and somehow inject all XT1580 stuff to get it recognized as such.
Click to expand...
Click to collapse
Can you explain the QHSUSB_DLOAD more?
QHSUSB_DLOAD (Qualcomm High-Speed USB Download Mode)
Man... It's been a while. Haven't had fun with any of this.
The bootloader starts and checks everything. There are 3 stages of the bootloader. 1 starts TZ, 2 something else, by 3 everything is booted and then it loads fastboot. QHSUSB_DLOAD is baked into the hardware. If the bootloader file is missing (.sbn) or doesn't match magic key (.hex) then booting fails. Most of the stuff turn off except for the CPU (in this case, ARM Cortex A53 and A78) and communications (USB interface), and it is stuck at QHSUSB_DLOAD. From there, you can load anything raw into the phone. So you can bring over the partitions that is used to boot (so in this case, you may be able to bring over something that damages TZ transistor, thereby unlocking bootloader). What you bring over exactly for the bootloader unlock, it hasn't been discovered even with the original Moto X (2013). However, that's how root is done. Bring over the blocks of the OS that contains the root blocks, and the bootloader doesn't know a thing.
Bring over a valid .sbn and .hex file and forcing the phone CPU to reset would bring the phone back from the missing bootloader, and then fastboot loads, followed by the OS (if the Linux core is present, the boot sector there, but that's another topic).
They rooted the phone in China , they sell it rooted!! Here is the link
m.intl.taobao.com/detail/detail.html?id=521809261322&spm=0.0.0.0
mr_verystock said:
QHSUSB_DLOAD (Qualcomm High-Speed USB Download Mode)
Man... It's been a while. Haven't had fun with any of this.
The bootloader starts and checks everything. There are 3 stages of the bootloader. 1 starts TZ, 2 something else, by 3 everything is booted and then it loads fastboot. QHSUSB_DLOAD is baked into the hardware. If the bootloader file is missing (.sbn) or doesn't match magic key (.hex) then booting fails. Most of the stuff turn off except for the CPU (in this case, ARM Cortex A53 and A78) and communications (USB interface), and it is stuck at QHSUSB_DLOAD. From there, you can load anything raw into the phone. So you can bring over the partitions that is used to boot (so in this case, you may be able to bring over something that damages TZ transistor, thereby unlocking bootloader). What you bring over exactly for the bootloader unlock, it hasn't been discovered even with the original Moto X (2013). However, that's how root is done. Bring over the blocks of the OS that contains the root blocks, and the bootloader doesn't know a thing.
Bring over a valid .sbn and .hex file and forcing the phone CPU to reset would bring the phone back from the missing bootloader, and then fastboot loads, followed by the OS (if the Linux core is present, the boot sector there, but that's another topic).
Click to expand...
Click to collapse
I'd like to see a Verizon phone rooted. That is the version I have and most in the U.S. have as well.
Sent from my XT1585 using Tapatalk
I finally updated my Turbo 2, losing hope on a root exploit.
Then I read this.
http arstechnica dot com/security/2016/06/godless-apps-some-found-in-google-play-root-90-of-android-phones (sorry, longtime lurker, just registered, can't post links)
It might lead to nothing, but maybe for those who haven't updated an exploit can be found with the godless apps?
The godless app is a hack that steals your data. If it did work, (which from what I understand it only works on 5.1 and below) you'd risk your personal and financial data being stolen and sold.
Alaadragonfire said:
They rooted the phone in China , they sell it rooted!! Here is the link
m.intl.taobao.com/detail/detail.html?id=521809261322&spm=0.0.0.0
Click to expand...
Click to collapse
Any luck in contacting the seller on how it is rooted?
I'm sure they use stolen Lenovo/Motorola factory development "engineering" software which unlocks the bootloader. It's the same phone as the Moto X Force but with locked down bootloader.
There were similar Droid Turbo phones being sold with unlocked bootloader a year ago in China, months before the Sunshine exploit was found.
gizzardgulpe said:
I finally updated my Turbo 2, losing hope on a root exploit.
Then I read this.
http arstechnica dot com/security/2016/06/godless-apps-some-found-in-google-play-root-90-of-android-phones (sorry, longtime lurker, just registered, can't post links)
It might lead to nothing, but maybe for those who haven't updated an exploit can be found with the godless apps?
Click to expand...
Click to collapse
I dont have my dt2 but link to one of the apps in case someone wants to try
https://apkpure.com/summer-flashlight/com.foresight.free.flashlight?hl=en
I'm usually just lurking here and grab Roms and exploits when they pop up, but I have something to add. Has anyone unlocked the developer settings? There's a toggle named 'oem unlocking' with a subtext of 'allow the bootloader to be unlocked'. Does this mean the bootloader can be unlocked? Last Verizon phone I had was a g3 and only way to gain a faux unlock was to use 'bump' to install twrp. Could this be possible with the turbo 2? I'm not a coder or anything, but just trying to add to the think tank here
This setting does nothing.
damkol said:
This setting does nothing.
Click to expand...
Click to collapse
There really should be a sticky saying "ALLOW OEM UNLOCKING DOES NOTHING ON THE DT2"
Droid turbo 2
After spending countless hours trying to unlock my bootloader to root my phone I'm at an impasse I've been told the Verizon and at&t models arnt able to be unlocked I will keep trying to get around this to root and install custom roms if anyone has any tips
Rhydenallnight said:
After spending countless hours trying to unlock my bootloader to root my phone I'm at an impasse I've been told the Verizon and at&t models arnt able to be unlocked I will keep trying to get around this to root and install custom roms if anyone has any tips
Click to expand...
Click to collapse
Crack the case, hook up some leads (microscope) and dump the memory for the boot loader is the only thing I can think of. Don't know if the that is even possible with that memory. It's probably integrated with other stuff.
Sent from my XT1585 using Tapatalk
Update: Oh yeah, it's encrypted. Guess that won't work.
Found something. Does anyone know if this vulnerability exists on the Droid Turbo 2?
CVE-2015-1805
http://www.computerworld.com/articl...itical-android-root-vulnerability-itbwcw.html
There is a proof of concept out there. Has anyone tried it?
https://github.com/dosomder/iovyroot
Hi,
My wife HTC m9(UK, Vodaphone, latest stock ROM, No root) was turned off last night to charge.
When booted up it does the below. It does not load into the OS. Every boot loops into the below.
https://drive.google.com/file/d/0B8n21CQX7535cjF4MnZqV2E1dGM/view?usp=sharing
It says the software has been modified?
My wife was very insistent that I never root or change ROMS on her phone.
Does anyone have a fix or is this send off for replacement?
Any advice would be greatly appreciated.
Thanks
Ca1v
ca1v said:
Hi,
My wife HTC m9(UK, Vodaphone, latest stock ROM, No root) was turned off last night to charge.
When booted up it does the below. It does not load into the OS. Every boot loops into the below.
https://drive.google.com/file/d/0B8n21CQX7535cjF4MnZqV2E1dGM/view?usp=sharing
It says the software has been modified?
My wife was very insistent that I never root or change ROMS on her phone.
Does anyone have a fix or is this send off for replacement?
Any advice would be greatly appreciated.
Thanks
Ca1v
Click to expand...
Click to collapse
What happens if you try to boot to Download Mode? I guess you see the black screen that is mentioned in Q7, right? If that's the case there isn't much you can do...
Download mode seems to be working (https://drive.google.com/file/d/0B8n21CQX7535cEFhTlpnajF5anM/view?usp=sharing)
If this is the case, can you point me in the right direction to get resolved?
Many thanks for the help
Flippy498 said:
What happens if you try to boot to Download Mode? I guess you see the black screen that is mentioned in Q7, right? If that's the case there isn't much you can do...
Click to expand...
Click to collapse
Download mode seems to be working (https://drive.google.com/file/d/0B8n...ew?usp=sharing)
If this is the case, can you point me in the right direction to get resolved?
Many thanks for the help
Interesting. Your video in post 1 shows a security warning. That means that the OS got deleted. This is only possible if you unlock the bootloader and delete it manually via TWRP or if the EMMC gets broken. Since the phone's S-ON and its bootloader is locked and not unlocked or relocked I assumed that the latter happened*.
As long as the download mode is working you can restore the system with the help of a RUU. Instructions can be found in the thread I linked in my last post. Be aware that all data on the phone is going to get erased.
* Well, it is possible to get the phone's status back to S-ON and locked with S-OFF but you said you never tinkered with that phone...
Flippy498 said:
Interesting. Your video in post 1 shows a security warning. That means that the OS got deleted. This is only possible if you unlock the bootloader and delete it manually via TWRP or if the EMMC gets broken. Since the phone's S-ON and its bootloader is locked and not unlocked or relocked I assumed that the latter happened*.
As long as the download mode is working you can restore the system with the help of a RUU. Instructions can be found in the thread I linked in my last post. Be aware that all data on the phone is going to get erased.
* Well, it is possible to get the phone's status back to S-ON and locked with S-OFF but you said you never tinkered with that phone...
Click to expand...
Click to collapse
Just thought I'd bring to your attention that apps are now being written that will try to obtain root without you knowing. The reason is that they can steal any information they want and sell it to corporations for as little as 4 pence/6c a record.
It is possible that it is a failed root by an app.
"I'm safe, I only download my apps from google playstore" - nope, you're not.
"I only use signed apps and the checksum is always correct" - nope, checksum can be matched with padding.
"I only use external sources to update genuine apps" - nope, see the Google playstore comment above.
"I have all my security and privacy set to super strict, I have my apps verified by google" - nope, still not secure because alerts are only written when the malicious/bad code is found.
Be warned, my fellow xda'ers. There is a whole new breed of security breach and it is terminal to root as a whole. Apps like kingoroot etc are issuing the wrong type of people with the wrong type of information and they are using it for the wrong purposes.
Google will stuggle to put a lid on these types of apps because they attack the hardware for access to software (a simple memory buffer overflow attack), inject a few lines of code and you're in, permanently. It will eventually result in a total lockdown at the manufacturer and bye bye root access, roms, mods etc, you'll get what you're given.
How do we prevent this?. We don't and we can't. We just have to sit back and watch as the world takes our privacy while bricking our devices one by one just to "try" to earn a poxy 4p.
Beamed in by telepathy.
@shivadow: I'm actually not sure what you're trying to achieve with your post. Malicious apps that can root your device without letting the user know about that exist since several years now. (Click here for a random example from 2011) Smartphones aren't completely safe and they never were. Everyone who's claiming the opposite either doesn't know what he/she is talking about or is simply lying.
To name just a few more android security flaws/exploits that emerged in the past: rageagainstthecage, gingerbreak, heartbleed, stagefright, the master key vulnerability, the futex bug, rootnik...
All of these have more or less been used for manipulating android phones. There is no absolute security. Android is still as secure/insecure as it's always been.
In addition, several OEMs are already trying to prevent their customers from rooting their phones since several years. Samsung's KNOX is a perfect example. (I don't want to discuss whether they're successful. That's a whole different topic.)
But let's get back to the deleted OS of the OP's phone: I've never heard about failed root attempts that erase a complete system partition. Therefore, I highly doubt that a malicious app caused all the trouble. Failed root attempts may cause a bootloop but they don't wipe your phone. Just think about the following: How should the dev of such app gain money if the app deletes OSes? Without OS there is no information you can steel and if you have no information you could sell/abuse/whatsoever you don't gain any money. Oh and not to forget that most apps on the play store already collect more than enough data from your phone they can sell afterwards without having to root it.
I meant failed root could be the cause, if the op didn't then who did?. If no-one modded it then dead nand is the only player..
I agree with every thing else but I don't trust those apps that try to gain root in the background to steal data and I think it's too easy for them to bugger your phone just for the sake of making a few coins. Face it, if I was doing it, once I had what I wanted I wouldn't care about the device. Sod the gracious exit and all that jazz.. No evidence, no conviction.
Maybe I'm being ott but my questions and points are still valid.
This is a proper "who dunnit" because I doubt it died of its own accord.
Knox is for businesses btw. If knox is triggered, which is very easy to do, the business is advised not to buy the device as it "may" have been compromised. But if no company secrets are being held on the device then it's still good to use. Knox protection was counteracted by supersu. In a nutshell, unless you run a company knox is of no concern to the everyday user.
Just thought I'd chuck that in there, I'm versed in the arts of the s3 i9300. I moved from that phone to this m9.
Beamed in by telepathy.
Hi
I'm new to the forum but have been doing a fair amount of research. I am stuck now though and would like a bit of help.
My situation is that I have a Xperia XA1 ultra (I know I should post in that device specific forum but not much seems to be happening there) I have a very specific problem that I have treated like a forensics problem.
The phone is locked by a pattern which has been guessed by another person so many times that the gatekeeper only allows one entry per day provided the phone is charged otherwise the timer resets.
It has not been rooted and ADB is disabled.
I have connected to it through fastboot and what I can gather is that it is running Android Oreo.
The system details are as follows:
Product: XA1 Ultra G3221
Build Number: 48.1.A.0.129
Chipset: Mediatek MT6757 Helio P20
Bootloader: Locked
My research has led me to the possibility of loading a recovery image into the RAM of the phone and accessing ADB that way. I tried this with a TWRP image but obviously it didn't work. There is a company called Cellebrite that claims to be able to load it's own boot/recovery image into the bootloader and gain entry that way, however the license is something like £10,000. I'm definitely not a commercial customer.
The final option for me would be to dump the memory via JTAG or chipoff, the contents would be encrypted but I found a blog where somebody had managed to find the location of the gesture.key file while the system was encrypted. I can't remember what the site was called though, it took me ages to find last time.
My main questions are does Sony sign the boot image with it's own keys or does it use the standard Android Verified Boot?
Does Sony reuse the same keys for signing across devices? Likely not but maybe
Is there a way to send specific instructions to the RAM via fastboot?
Does anybody know of an exploit that could be used?
Is there a way to extract the boot.img and recover the Sony keys?
If there any other docs, resources or ways to get the data that could help, I will gladly read and/or try them. I think this forum is probably the biggest resource one though but after a while the specific information needed gets harder to find.
The main thing is that I don't unlock the bootloader and flash anything. It's all got to be live and non data damaging.
I tried MTPwn on the off chance that it would work but nope, it was a no go.
If there was a way to utilise the mediatek exploit to gain entry from fastboot that would be excellent, or to use fastboot to dump the memory.
Thanks for reading, I hope someone can help.
Your thread was quite confusing at first as I wasn't sure what to look for exactly :/
That being said, you have your phone locked and you want to unlock it. However you don't want to flash or reset your device, you don't have root permission, you don't have debugger mode on and you don't want to unlock the bootloader, correct?
Basically you're asking for the impossible...
All I can think of is FROST attack. See article for details and source code.
You can also send your device to your nearest Sony service center and they can probably fix it with no memory loss.
Other than that, you MUST hard reset your phone if you want it back.
However should you come to your mind and realize the reality of the situation where you shouldn't be picky about it then you can start with flashing custom recovery. Or using third-party programs like dr.fone.
XDHx86 said:
Your thread was quite confusing at first as I wasn't sure what to look for exactly :/
That being said, you have your phone locked and you want to unlock it. However you don't want to flash or reset your device, you don't have root permission, you don't have debugger mode on and you don't want to unlock the bootloader, correct?
Basically you're asking for the impossible...
All I can think of is FROST attack. See article for details and source code.
You can also send your device to your nearest Sony service center and they can probably fix it with no memory loss.
Other than that, you MUST hard reset your phone if you want it back.
However should you come to your mind and realize the reality of the situation where you shouldn't be picky about it then you can start with flashing custom recovery. Or using third-party programs like dr.fone.
Click to expand...
Click to collapse
Thanks for getting back to me, yes I realise it is asking for the impossible. I'll have a research around that article and see if I can find some information on how to write the program to dump the contents over USB. I tried Dr Fone but that only gave me the option of a hard reset.
My current line of attack is an exploit over USB called OATmeal, whereby a Raspberry Pi is used over OTG with a filesystem label of "../../data", it allows the filesystem of the phone to be mounted and data written off. It is a little complex and so I am struggling a bit with getting it to work. The team over at Project Zero have a good write-up of it so I'm following that and the POC at exploit-db to guide me through it.
I think I will be able to get the USB part to work but I'm not sure if I have to write a Java file to automatically run when /data is mounted, or if that's even possible.
Forenzo said:
My current line of attack is an exploit over USB called OATmeal
Click to expand...
Click to collapse
Not to make you frustrated, but this is an old exploit and I highly doubt it'd work on your device, unless your device security patch is older than 9-2018.
And you can't rollback on your security patch.
You should really consider flashing TWRP or other custom recovery. You have no other option.
XDHx86 said:
Not to make you frustrated, but this is an old exploit and I highly doubt it'd work on your device, unless your device security patch is older than 9-2018.
And you can't rollback on your security patch.
You should really consider flashing TWRP or other custom recovery. You have no other option.
Click to expand...
Click to collapse
Fortunately the device hasn't been updated since around 2-2018 or 3-2018 so any exploit I can find from then onwards that I can use will be great. I really do get that the only realistic option is to unlock the bootloader and flash the recovery but the data needs to be recovered and I absolutely don't want to wipe it.
If I can't do it then it will gather dust until the end of time...
It seems that no matter what I say you won't realize the situation you are in.
I can only suggest to NEVER mess with the phone circuits or the motherboard. No matter which stupid yoututbe tutorial you saw. Those guys are douchebags who only know how to get views and don't care for whatever you/they do to your device.
Needless to say messing with the circuits or the motherboard require dexterity and experience which I'm positive you don't have.
As I said before if you send it to an authorized service center, then they can help you with it without memory loss.
Sending you device to a service center isn't an insult or an act of low self esteem. Service centers exist for a reason, and they're basically geeks who are too passionate about electronics and decided to make a living out of it.
Or maybe you can somehow use the EDL mode on the phone.
In Qualcomm devices the EDL mode is locked and can only be accessed by an authorized person who have the security code of your device. I don't know if it even exist in MTK devices.
Should you actually manage to boot into EDL mode - Assuming it exists and is unlocked - then BEWARE: EDL mode is very low level and any command can directly affect the kernel or compromise the system. Don't use commands you're not sure what do they do.
You can use EDL mode to recover the data from the phone then wipe it clean, then restore the data.
You cannot access memory with EDL mode, but you can access the current image on your device. And from which you can get the key file.
EDL mode is a very very powerful tool (Much more powerful than debugging, fastboot, or anything you may know of) as it doesn't need unlocked bootloader to use it and through which you can do anything to your device including flashing other ROMs.
Good luck on your impossible quest. Make sure to post updates should you find yourself stuck.