Database Develop

Whats/Hows/Wheres

As most of you are finding out by umpteen amount of random post theres a new way to unlock your handset.
Great, wicked......for some of us!
OK, Findings are as follows,
if your handset is original and are desperate to get this unlocked......DO NOT unlock via the XTC Clip.
Unlock this handset via HTCDev only!
WHY your probably saying right now., simple answer is...your screwed if you do!
Currently XTC handsets can only have version 4 CWM installed, and it wont renew to version 5.
HTCDev you can flash CWM 5 easily.
Both setups can install custom Roms, please note there are NO CM7 Roms Available.
The current script available for data2sd kindly made by puppet13th/Kanded, is only working for handsets with HTC Unlock only.
Why this reasoning is i dont know. sakisuren and myself have XTC unlocked handsets and both have the same problems.
Which incule, failure to install data2sd script, my handset bootloops once installed, some commands not pushing via adb, i also have some other various issues!
You'll find various posts around explaining this and that....all saying the same thing. Unlock by HTCDev blah blah, usual dribble!
Find your own way, your own choice! warnings have been given.
I am here to help others conquer there salsa as best as they can, and will continue for quite a while yet!
I have 2 Custom Roms available to use. Both Chinese with English Installed.
Older One has transparent status bar, with blue icons, nice to view, comes pre rooted! couple of extras included in package, quicker than normal Rom.
Newest Rom has basic setup, little more internal memory, but otherwise normal.
& Few games.
x2 gapps packages, various different build versions inside the zip, but all have same Google apps, flash-able after installing these 2 Roms.
To use either i'd suggest using the data2sd scripting to get the best package.
All come unsupported and usage at your own Risk. So Backup everything beofre you try it!
Again your choice, everything in these Salsa forums i have Hosted on media-fire, so if your missing anything or need something which isn't working via the link please ask.

WHy does downgrading not work?

I see it mentioned a few times but what on the phone prevents say 4.4.2 from being installed after the upgrade to 4.4.3?

Because the partion table and bootloader are different and can't be downgraded at all.

Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?

I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?

knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.

knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
No, the Dev edition is no different. All the same "rules" apply.
The Dev edition is the same as any other.... It just keeps is warranty if you unlock it.

aviwdoowks said:
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
Click to expand...
Click to collapse
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
KJ said:
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
Click to expand...
Click to collapse
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
AGISCI said:
Because the partion table and bootloader are different and can't be downgraded at all.
Click to expand...
Click to collapse
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...

scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
It is security. Specifically the SECURED BOOTLOADER. Don't confuse secured with locked. Yes, you can unlock your bootloader, but it is still secured.
Read up on "TrustZone" and see why it is important, and why the OEMs would not want you to be able to downgrade. You can "buy" or "not buy" whatever you want....
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
The early (4.2.2 & 4.4) bootloader (motoboot.img) was vulnerable to an exploit that allowed us to disable write protection. The updated bootloader (4.4.2+) is patched. You *CAN NOT* downgrade back to the vulnerable version.
^Does that not have *everything* to do with security??

scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.

AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
Can't just fake the version number?

No, it's not possible.

samwathegreat said:
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
Click to expand...
Click to collapse
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
samwathegreat said:
You can "buy" or "not buy" whatever you want....
Click to expand...
Click to collapse
I know, and that is why I want to understand what it is I would be buying.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...

scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.

AGISCI said:
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
Click to expand...
Click to collapse
Well said :good:

Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
scryan said:
Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
Click to expand...
Click to collapse
Our recovery devs never restore such partitions or boot loader elements.

scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
Smh I normally don't chime into these threads but I had to, you can't downgrade the bootloader because of security/compatibility plan and simple. It's the same concept as why you can't downgrade most PC's bios, if there is a flaw found in the system as a whole, then they don't want you to downgrade to that version. A lot of the times when people brick their device trying to downgrade is because it will flash, but because an efuse was blown when it was upgraded the downgraded version will not boot. Yes the recovery can technically rewrite those partitions but again because the efuse was blown it will not boot. Also yes being able to downgrade on any system Windows, Linux, Unix, IOS, Xbox, PS, etc are causes to security issues. If you can downgrade a system to a vulnerable version, it is then by definition less secure, no matter how you try to spin it. Take the futex vulnerability which affected most linux kernels from the past 5 years, so why would any desktop linux user ever want to downgrade to a vulnerable kernel? They wouldn't but if the end user isn't knowledgeable of the vulnerability they wouldn't know that downgrading makes them vulnerable. So since phones are used by so many people who are not knowledgeable of vulnerabilities, why would you want to give them the opportunity to downgrade themselves to a vulnerable OS?

Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
aviwdoowks said:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
Our recovery devs never restore such partitions or boot loader elements.
Click to expand...
Click to collapse
By "Our recovery devs" do you mean the ones doing the moto specific stuff? Do you know if this Is typical of the custom recoveries for other devices?

@scryan
I know far less then other posters, but yes android recoveries are all very similar in that regard.

scryan said:
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
Click to expand...
Click to collapse
The thing is you keep looking at it from a PC point of view, where you basically have full control over the software and hardware. Phones have much tighter restrictions on them from carriers, fcc, etc they're not personal computers. So the reason they make it where you can't downgrade the bootloader is because that's what controls the restriction on downgrading any other partition on the device.
So with the Moto X's 4.4.4 update they probably blew an efuse, so users with a locked device can't downgrade. This is done because with locked devices they can only flash signed kernels, so by blowing the efuse they can't downgrade to the vulnerable 4.4.2 and below kernel even though it is signed correctly. This is because lets say a malicious app was able to get on a device that had the ability to downgrade say back to 4.2.2. That app could flash the older vulnerable signed kernel to the recovery partition, to disable write protection gain more control over the phone etc, without the users knowledge. Now that is a stretch and probably will never happen but that doesn't mean the threat isn't there, and hackers are very creative at deploying malicious attacks. So by updating the bootloader and blowing an efuse the older vulnerable kernels can't be flashed. Now this is all negated if you're unlocked of course, but if you don't want to ever worry about this issue don't update your bootloader. This is not recommended but I've mentioned it several times on this forum I haven't updated my X's bootloader since I bought it, it's still running the factory 4.2.2 bootloader, running 4.4.4 with no problem.
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.

iKrYpToNiTe said:
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
Click to expand...
Click to collapse
A bit selfish, and perhaps lazy of me but I am only really here talking about the developer version, I just haven't bothered to write the full "verizon developer edition " every time (most of this is research for next phone, which will be developer handset)... To me, obviously a locked phone is going to have weird restrictions and hacked together paths to getting things done, your not supposed to have admin rights...(yeah, maybe I do look at it too much as a computer. Mostly because I am annoyed the differences seem intentionally imposed). But when I pay outright for a device so that I can own it and have full administrative control... anyways, thats a different more philosophical discussion. The point is I have been talking about an unlocked device using third party software where possible.
Either way, appreciate the reply. I have a better understanding of the issue... Though coming from an S4 it still seems weird that MDK*/developer phones don't seem to have the same issues/warnings. It would seem however that the difference may be that MDK/dev owners only use kernels/roms prepared for their devices and do not update the bootloader. I suppose if more people in the Moto X community were worried about maintaining the ability to downgrade an unlocked device it would be technically possible to upgrade in a way that could be easily reversed, similar to the S4.
(*MDK was the first VZ S4 firmware, and the only one that has a released exploit to allow for a full custom recover. Later locked firmwares must rely on safestrap)

[Q] Options for Stock Unrooted S5 requiring airwatch and encryption

I have an ATT S5 (SM-G900A), completely stock, unrooted, updated to the latest 5.0 OTA update. My requirements for my phone are that it be able to pass Airwatch checks and that it be able to be encrypted (Personal device used at work). Some background first:
Last time I tried to play around with rooting, other mods, and whatnot was on my ATT S3 (I think I747?) and I discovered that an unspecified combination of rooting, installing a custom loader (CWM in my case) and installing a custom mod (Cyanogenmod at the time) made my phone unable to encrypt. At the time I was not required to use Airwatch, but encryption was required for my phone to connect to work, so I gave up on the whole lot.
I have now discovered that ATT, in their infinite wisdom, has replaced the S Voice drive mode with their own "ATT Drive Mode", and it's been verified they went so far as to remove the related APKs from the phone entirely. For those unaware, S Voice Drive mode is an feature of S Voice that (when turned on) reads out all callers and text messages, and then verbally prompts you for actions; reply, answer, ignore, etc. It allows fully hands free functionality. ATT Drive Mode, on the other hand, automatically kicks in whenever speeds of 20 MPH are detected (even if you're a passenger), rejects all calls and texts excluding a user-defined 5 person list, and essentially makes your phone useless anytime you're in a car. The goal is to "reduce texting and distracted driving", but as I'm on-call as part of my job and need to at least be aware of texts that come in within 10 minutes of receipt, it actually makes my drive much more dangerous. ATT Drive mode is a good idea for teens, perhaps, but i'm not a teen.
This brings me to my question: What are my options?
--Does rooting break my ability to encrypt? I know airwatch will flag, but I'm thinking there's a possibility of being able to root, put a custom loader on my phone, and then restore stock with that custom loader, whereupon I can try to install the drive mode APK...which leads me to my next question:
--Does having a custom loader (like safestrap or CWM or whatever is in use nowadays) break my ability to encrypt?
--Does anyone know of a way to install the S Voice drive mode in the G900A? I tried searching, but the only references involved being rooted, or ended with something vague like "download a stock rom and find the apk using root explorer" as the solution (which is vague to me because I don't know which stock rom to use, what apk to look for, and last time I used root explorer on my s3, it needed root...)
Honestly, the ideal solution would be something like the stock rom from the international version that would run on my ATT version...but I don't know if such a thing exists or is possible. I don't mind Samsung's cruft, but I do dislike ATT's lobotomizing of my phone to push their own little product that treats me like a kid. I know that I am less safe as a driver without the S Voice drive mode than I was with it.

I take it I have no options? And that no one knows how rooting affects encryption?
Sent from my SAMSUNG-SM-G900A using XDA Free mobile app

sheaiden said:
I take it I have no options? And that no one knows how rooting affects encryption?
Sent from my SAMSUNG-SM-G900A using XDA Free mobile app
Click to expand...
Click to collapse
I will make it easy for you. Since you took the 5.0 OTA update rooting is not possible anymore. Also there is no way to downgrade to KitKat which was rootable. Sorry. Not much you can do until someone finds a way to root 5.0. If you find the S Voice Drive app, you can side load it and see if it works.

Waiting4MyAndroid said:
I will make it easy for you. Since you took the 5.0 OTA update rooting is not possible anymore. Also there is no way to downgrade to KitKat which was rootable. Sorry. Not much you can do until someone finds a way to root 5.0. If you find the S Voice Drive app, you can side load it and see if it works.
Click to expand...
Click to collapse
Actually, while I greatly appreciate the fact that you took the time to reply (seriously! at least you took the time!), this is neither easy nor related to the questions I asked. If you look at my post, I'm not asking "how can I root", I'm asking three rather different questions:
--Does rooting break my ability to encrypt? I know airwatch will flag, but I'm thinking there's a possibility of being able to root, put a custom loader on my phone, and then restore stock with that custom loader, whereupon I can try to install the drive mode APK...which leads me to my next question:
--Does having a custom loader (like safestrap or CWM or whatever is in use nowadays) break my ability to encrypt?
--Does anyone know of a way to install the S Voice drive mode in the G900A? I tried searching, but the only references involved being rooted, or ended with something vague like "download a stock rom and find the apk using root explorer" as the solution (which is vague to me because I don't know which stock rom to use, what apk to look for, and last time I used root explorer on my s3, it needed root...)
In fact, I am unable to remain rooted (Airwatch; it's part of the post title), and the whole point and thrust of my question lies in the fact that I am looking to find out what affects encryption and what options I have as far as getting S Voice Drive mode on my phone while staying Airwatch compliant (not rooted). In addition, "if you can find the s voice drive app" is part of the problem too, as evidenced by the third question I asked above; I don't know where to find said app.
Does anyone know anything regarding what I was actually asking?

Everything that you want to do requires ROOT! Safstrap needs root, CWM will brick you phone since the bootloader is locked. Again, there is no way as of now to root the S5 with 5.0 att OTA.
Here is the link to download the GS4 S Voice app. You can try and side load it,
https://www.dropbox.com/s/oe7i2g81iuhjv38/S-Voice_Android_phone_J.apk?dl=0

Waiting4MyAndroid said:
Everything that you want to do requires ROOT! Safstrap needs root, CWM will brick you phone since the bootloader is locked. Again, there is no way as of now to root the S5 with 5.0 att OTA.
Here is the link to download the GS4 S Voice app. You can try and side load it,
Click to expand...
Click to collapse
Awesome, I'll start with that sideloading, and test it out. Thanks! As far as the rest, I suppose that does clarify some things (that I admittedly already knew), so I do appreciate it, but it still does leave the answers to the other questions. I can infer, of course, that the answer to whether having a custom bootloader on the Galaxy S5 breaks encryption will be dependent on whether root breaks the encryption, since as you pointed out custom bootloaders need root to install, but the fantasy I entertained for a little while was rooting when there's a method (hope springs eternal, so I'm hoping it will eventually be possible), installing a custom bootloader so I can do things like backups and sideload, getting the proper apk's installed for the drive app, and then unrooting it so I can connect it via airwatch to my work's network. Perhaps I should have marked this as a solidly theoretical question, since as you said, there currently exists no root. I just want to know, with the unique way that Samsung implemented Knox and the encryption on the S5, what will break encryption and what won't?
Of course, there is a side question brought up by all this...how possible is it to load another firmware on my phone? as in, use Odin to put the tmobile image on my phone. That is likely a bad example, since I'm fairly certain there are actual hardware differences between the ATT and the tmobile models, but the concept still stands. At what level are the hardware configurations different between phone companies?

sheaiden said:
Awesome, I'll start with that sideloading, and test it out. Thanks! As far as the rest, I suppose that does clarify some things (that I admittedly already knew), so I do appreciate it, but it still does leave the answers to the other questions. I can infer, of course, that the answer to whether having a custom bootloader on the Galaxy S5 breaks encryption will be dependent on whether root breaks the encryption, since as you pointed out custom bootloaders need root to install, but the fantasy I entertained for a little while was rooting when there's a method (hope springs eternal, so I'm hoping it will eventually be possible), installing a custom bootloader so I can do things like backups and sideload, getting the proper apk's installed for the drive app, and then unrooting it so I can connect it via airwatch to my work's network. Perhaps I should have marked this as a solidly theoretical question, since as you said, there currently exists no root. I just want to know, with the unique way that Samsung implemented Knox and the encryption on the S5, what will break encryption and what won't?
Of course, there is a side question brought up by all this...how possible is it to load another firmware on my phone? as in, use Odin to put the tmobile image on my phone. That is likely a bad example, since I'm fairly certain there are actual hardware differences between the ATT and the tmobile models, but the concept still stands. At what level are the hardware configurations different between phone companies?
Click to expand...
Click to collapse
You will not be able to change your bootloader period... At this point the locked bootloader is unbreakable. That leads to your next question about tmobile and that's a no as well due to the locked down bootloader.
Even with root you won't be able to do anything you've suggested due to the locked bootloader.

OPOfreak said:
You will not be able to change your bootloader period... At this point the locked bootloader is unbreakable. That leads to your next question about tmobile and that's a no as well due to the locked down bootloader.
Even with root you won't be able to do anything you've suggested due to the locked bootloader.
Click to expand...
Click to collapse
Interesting. I had been under the impression that I had seen people referring to installing clockworkmod or some similar thing on an S5, but I think I may be getting caught up in terminology; those are recoveries, aren't they? not bootloaders? Or perhaps people were posting about the other S5s with unlocked bootloaders. 15 different versions of S5, and I get stuck with the most apple-like of all the carriers....(in the sense of "you take what we give you and don't play with it!")
So, assuming I don't manage to get it installed via the link Waiting4MyAndroid was kind enough to post, I think that rules out anything other than the method of:
--wait for a root method to be established for the new OTA
--root, install the drive apk
--unroot, so I can encrypt and pass airwatch
Does anyone know if the old method of rooting broke encryption? and whether encryption was able to be performed after unrooting again?
Edit: Attempted to Sideload. Sadly, it is telling me "App not installed" (other sideloads do work; it's not the unknown sources setting). I'm thinking either the apk is marked for s4, and it's not compatible, or it's trying to overwrite files from the established svoice system, and that's not allowed. I suppose if someone has the drive apks from a tmobile S5 image or some such thing (same model, different carrier), then I could try again, but unfortunately this apk doesn't work. Thanks for the attempt, Waiting4MyAndroid!

Possible ways to achieve root?

So I actually don't have the S5, or any Samsung device for that matter, but a friend of mine does, and really wants to root their phone. I had no idea the AT&T S5 was so secure, but it's pretty interesting too. I've been researching for over 15 hours. I may not have been able to root his phone, but I think I have learned a couple things and maybe some possible root methods.
1.) Since using ODIN to downgrade would soft brick the phone, would it be possible to download the stock Lollipop update onto a computer, give the update super user access, replace the recovery with a custom one, or unlock the bootloader from the computer, then flash it through ODIN?
2.) Intercept any sort of OTA update, then alter it to flash a custom recovery or unlock bootloader? I don't know how you would go around this though.
3.) If someone hasn't taken the OTA update that patched the Stagefright exploit, could someone purposely use the exploit to allow installation of a custom recovery or even to unlock the bootloader since the Stagefright bug has super user access (or so I've heard).
Also, I'm sorry if these are stupid ideas. I know close to nothing about Samsung so everything I'm basing this off of is what I've read in the past 15 hours.

jsmithfms said:
So I actually don't have the S5, or any Samsung device for that matter, but a friend of mine does, and really wants to root their phone. I had no idea the AT&T S5 was so secure, but it's pretty interesting too. I've been researching for over 15 hours. I may not have been able to root his phone, but I think I have learned a couple things and maybe some possible root methods.
1.) Since using ODIN to downgrade would soft brick the phone, would it be possible to download the stock Lollipop update onto a computer, give the update super user access, replace the recovery with a custom one, or unlock the bootloader from the computer, then flash it through ODIN?
2.) Intercept any sort of OTA update, then alter it to flash a custom recovery or unlock bootloader? I don't know how you would go around this though.
3.) If someone hasn't taken the OTA update that patched the Stagefright exploit, could someone purposely use the exploit to allow installation of a custom recovery or even to unlock the bootloader since the Stagefright bug has super user access (or so I've heard).
Also, I'm sorry if these are stupid ideas. I know close to nothing about Samsung so everything I'm basing this off of is what I've read in the past 15 hours.
Click to expand...
Click to collapse
The issue is that AT&T (and Verizon) use an encrypted signature key to verify they are the correct unaltered files as well as the means to unlock the bootloader to allow the OTA. Without that key, the tasks you mention are near impossible. They are not stupid ideas at all..just very difficult with all the security checks included.

KennyG123 said:
The issue is that AT&T (and Verizon) use an encrypted signature key to verify they are the correct unaltered files as well as the means to unlock the bootloader to allow the OTA. Without that key, the tasks you mention are near impossible. They are not stupid ideas at all..just very difficult with all the security checks included.
Click to expand...
Click to collapse
Crap... well does anyone know how that encyption key is generated? Like, could I theoretically get an algorithm from a ROM?

Honestly for the time being I wouldn't bother with ROMS for that Device and carrier at the moment. Especially being that its someone elses device. Towelroot should be a good start. If Im not mistaken I don't think its supposed to trip knox.
Sent from my HTCEVODesign4G using XDA Free mobile app

jsmithfms said:
Crap... well does anyone know how that encyption key is generated? Like, could I theoretically get an algorithm from a ROM?
Click to expand...
Click to collapse
This is the riddle of the Sphinx my friend. I am sure the super devs have tried their best so far to crack it. It has been an ongoing effort to make phones more and more secure, not against the amateur developers and rooters, but against the hackers. These smartphones are now our personal computers, diaries, personal assistants, financial operator, and more. They basically are a person's (and business's) life. AT&T and Verizon have taken the big steps to appeal to the Exchange clients, corporate, government and military contracts. Even the general public want to know their phone is secure. This is what keeps me stuck on the Sprint network.

Have you tried Kingroot?
I successfully rooted my wife's AT&T S4 on OC3 lollipop (supposedly unrootable) with the desktop version. Mobile version didn't work but desktop did without a hiccup. Maybe it'll work on the S5.
http://forum.xda-developers.com/android/apps-games/one-click-root-tool-android-2-x-5-0-t3107461
Rockin' a l337 with Goldeneye v49.1 + Wanam Xposed and loving life on AT&T's 4G LTE network

S5 on lollipop has a new nasty boot loader.... it was a miracle on its own that they ever came up with safestrap to duck the boot loader on earlier versions of android

The great adventure of rooting the XZ1C

Hello everyone,
I have to say I am completely lost regarding the whole rooting process for the XZ1C. I usually manage to get where I want just by carefully reading the forums, but with this device, I feel overwhelmed by information. And I sometimes feel like what I am reading contradicts what I though I understood from previous reads...
I will try to sum up what I know so far.
First of all, I have a just-out-of-the-box Sony model G8441 with firmware 47.1.A.12.179 / Oreo 8.0.0 (never been connected to the outside world yet), and I want to properly root the device and install TWRP with no loss of feature.
What I think I understand:
To root, I first need to unlock the bootloader, which seems to be a trivial operation. However, this will break some functionalities due to DRM keys being erased. Once it is done, there is no way, ever, to get them back. There are however ways to "trick" DRM-related functionalities into believing DRM keys are still there.
Alternatively, there seems to be a way to backup the DRM keys prior to unlocking the BL, and this backup can somehow be reused and injected back into the unlocked device. If true, then this would certainly be a preferable method than the previous one, which would then be obsolete. However, it obviously doesn't look obsolete when I read the related topics, so I must be missing something...
Another thing I noted (but do not quite understand): There are ROMs for this device that "include" a DRM fix.
Last important thing I read: there is a paid "do-it-all" tool which takes my locked device and, with one click, makes it unlocked - rooted - DRM-fixed - TWRP-enabled. Now that sounds really good! Maybe too good?
As far as i know (but I learn new stuff every day on this topic) this DRM stuff is the main difficulty here. I understand that the rest of the process (root + TWRP) will be much simpler (although I'm old-school and completly missed all this magisk trend...!)
What I don't understand:
I read that some people downgrade to Oreo to be able to root properly, and at the same time, I read that Pie removed the restrictions on unlocked bootloader. So I still have no idea if I should connect and receive Sony updates, or avoid them.
Another thing I don't get, is how many ways do we have to root this thing? In the past, I was used to see, for a specific device, always one major and widly used rooting method. Here I fail to identify it...
What I think I will do:
1. Backup TA partition with j4nn's tool. This will probably imply flashing an older firmware right? Is there any link that could help me with this flashing process? (I only know Odin - did I mention old-school?) I saw this page for generic sony Z devices, but the thread is from 2013 and now closed. Is it still up-to-date or is there a newer thread?
2. Unlock bootloader and restore TA partition.
3. Wait for Sony updates? Or should I first hide unlock status?
3bis. Alternaltively to waiting for updates, maybe I can just flash the latest build? (47.2.A.8.24 if I am not mistaken)
4. Flash modpunk's TWRP.
5. Flash janjan's Boot.img to get root functionalities?
Alternaltively to all the above (except maybe step 1 that I will probably do in any case), buy the paid all-in-one tool (Xperifix), plug, click and wait... But will I really end up the same as with the manual way?
I saw a few other methods in the forums but it seems my brain is currently refusing to bring them back...
That's all I have right now. I would really appreciate if you guys could share some insight and tell me what you think about this, whether there are missing steps, useless steps, incorrectly ordered steps, silly steps, or if I'm just completely wrong about the whole thing.
Feel free also to correct me on the assumptions I made at the beginning.
Thank you very much for reading this repulsive piece of text.

SunJu22 said:
I would really appreciate if you guys could share some insight and tell me what you think about this
Click to expand...
Click to collapse
By the looks of it you have done a great deal of research on the project.
Yes, go down the route of backing up your TA partition first, but that is not a small step in itself, it's pretty complicated and if you get that working then the rest of the project will be a breeze.
You don't say what version of firmware you want to end up on. If you want to end up on Pie then forget the DRMfix . But if you're staying on Oreo and can't be bothered with lots of files & flashing, then this is the easy way out, I bought the paid version and can verify it works.
More recently I ended up janjan's kernel (Oreo build). Hidden root (Google Pay works), lots of performance tweaks, DRM completely working.
It's unlikely that anyone will bother making a DRM fix for Pie as the camera works and there are only a couple of other features that get disabled.
It sounds like you're not the sort of person who's only going to read the first couple of pages of a thread (or the last) flash the xxxxxx and then complain when it's broken.
The people on the forum here are very helpful and if you go into any of the threads you mentioned in your post with a question, you'll get a reply.
Good luck.

I agree, there is a lot of information out there and different methods of achieving what you want - very confusing if you have not been following the threads since the beginning.
In my opinion, the preferred method is j4nn's method outlined here: https://forum.xda-developers.com/xp...devonly-exploits-temp-root-to-backup-t3795510
Use that post as your main guide (the final step in that guide, #13, is how you will achieve root). You will use Newflasher to flash the various firmwares along the way (this is linked from j4nn's procedure in step #2). User munted made a very detailed pdf file that fills in some of the details on j4nn's procedure - see the following post and download the pdf attached: https://forum.xda-developers.com/showpost.php?p=78255334&postcount=382
Most of the other methods out there came before j4nn's work - they didn't include DRM backup/restore.
If you follow j4nn's procedure, you won't need to use the janjan kernel as you assumed - janjan method is different and does not overlap with j4nn.

SunJu22 said:
Feel free also to correct me on the assumptions I made at the beginning.
Click to expand...
Click to collapse
Sorry, I didn't point out that I was one of the early 'jumpers' who unlocked their bootloader without any backups, so I have been forced into always using fixes and all the information I have is based on having to fix your phone for it to work, but that's all changed now. I'm so out of date :-/
 @camaro322hp is right, if you follow j4nn's method correctly you'll be rooted with no DRM loss. All of the other stuff is not required.

Thank you Digesteve and camaro322hp for your help.
From what I understand the XZ1C didn't get as much love as other devices, thus there was a long period of tinkering before a "do-it-all guide" could be considered "the" solution. That could explain all these different approaches that are proposed. Like you said camaro322hp it's rather difficult to jump on this train, and I can only guess how interesting this ride has been.
Anyway, I didn't see that the TA backup thread from j4nn also encompassed all the information I needed; I am glad to finally know that there is indeed a centralized "do-it-all guide" . To make it easier for XZ1C newcomers, I think j4nn should update his opening post to make this clearer.
Since I managed to grab the attention of 2 XZ1C power users, I would like to ask you: Did you keep stock? Did you try alternative ROMs? Do you like some of them? Do you prefer Oreo or Pie?
For information, the most up-to-date experience I have on a Android phone is my LG90 with CyanogenMod 11 (KitKat 4.4.4! Yes sir!). I heard that it's becoming less and less useful to flash a custom ROM due to major OS improvements, but I would still enjoy the simplest and lightest Android possible.

SunJu22 said:
Did you keep stock? Did you try alternative ROMs?
Click to expand...
Click to collapse
I've always been on stock, the camera is an important part of what I want from my phone and although there's lots of alternative camera apps, there's no competition to the stock camera app. Then I theme it black with swift installer and just uninstall or freeze any apps I don't want with Titanium Backup. I have stuck with Oreo, everything works perfect and I remember seeing so many people jumping to 9 then wanting to go back to 8 because they didn't like it. Something about changing the way the drop down menu works, among other things, but having never installed it, I'm not the person to comment on if it's any good or not.
I have been watching the XZ1c thread and Lineage is gaining ground, it even has a stock camera now. I would have thought something like that with miniGapps is going to be pretty lightweight and very similar to your carbon rom of before. At the moment this is based on 8, but is working well. Depends how keen you are to move to Pie.

Thank you Digesteve.
One thing I still don't understand. Part of the process is to hide unlock status. If I do this, FOTA will be applied and I will automatically end up on Pie, right? Should I skip this step if I want Oreo?
EDIT: when you say "a stock camera", you mean the Sony camera?

@SunJu22 I've stuck with the Sony ROM. A rooted stock ROM meets all my needs, so I've never felt the need to experiment with custom ROMs. There are some custom options out there that people seem fairly happy with, so if that's your thing, I'd encourage it.
Without going into too much detail, I'm still on Oreo for the moment, for a variety of reasons, but I don't know of anything that would keep me from recommending Pie.

One thing you should note is that once you unlock, there is no going back. AFAIK there is no known or working method to relock the bootloader.

SunJu22 said:
FOTA will be applied and I will automatically end up on Pie, right? Should I skip this step if I want Oreo?
EDIT: when you say "a stock camera", you mean the Sony camera?
Click to expand...
Click to collapse
Yes, I'm not entirely sure why having your rooted phone try and update itself is an advantage, but something I'd recomend avoiding.
Stock camera is the Sony camera, yes.

Thank you everyone, I believe I now have enough information to jump into this with confidence. The adventure begins, and will be reported in this thread for future reference, in the hope that it will help others like me!

Well, I am a bit sad... I wanted to report my "adventure" here in detail, but I'm afraid I have nothing to say.
Indeed, following the procedure from j4nn with a printed copy of munted's awesome guide, I managed to do all I wanted on the first attempt.
I don't have anything to add to this guide, everyone wanting to root their XZ1C can do it just by reading the opening post from j4nn and the mentioned guide. It takes a bit of time but nothing complicated thanks to the clear and detailed explanations.
I now have a fully functional rooted XZ1C (including camera) on Pie with Magisk root and TWRP.
Thank you all again from pointing me to the right direction.
I however have a slight disappointment. I wanted to start with Oreo and make an Nandroid backup before moving to Pie, but I didn't find Oreo builds on Xperifirm. So I jumped straight to Pie.
In case I want to test Oreo, I read that a downgrade is more complicated than an upgrade, but apart from the fact that a factory reset is needed for downgrade, I couldn't find an explanation for this. Any idea?
Last but not least: I looked for the latest Oreo build version number but couldn't find it. Do you guys know what it is and where I can download it?
I guess this will be all for this thread after this. Although it is very convenient to have my own thread to ask questions rather than finding the relevant page for each one, I don't want to annoy you too much...
EDIT: Please ignore the last question. I found out last Oreo build is 47.1.A.16.20, and I found the files via the download link in the opening post of the Lineage thread.

SunJu22 said:
In case I want to test Oreo, I read that a downgrade is more complicated than an upgrade, but apart from the fact that a factory reset is needed for downgrade, I couldn't find an explanation for this. Any idea? Lineage thread.
Click to expand...
Click to collapse
There is an easy solution to downgrade:
Newflasher

Hi, I've been thinking about rooting my XZ1c for a long time now. So, do I understand correctly that the ONLY disadvantage compared to non-rooted device is not possible to receive the OTA updates from Sony anymore?

mEREHAIGE said:
Hi, I've been thinking about rooting my XZ1c for a long time now. So, do I understand correctly that the ONLY disadvantage compared to non-rooted device is not possible to receive the OTA updates from Sony anymore?
Click to expand...
Click to collapse
No, you can flash a kernel to hide the bootloader unlock flag, this will mean that you will receive OTA updates, although depending on how you're rooted an update will most likely break your phone, so not that useful.

*made a thread*

Thanks--rooted withOUT adventure too
Very happily rooted now. Just wanted to say a quick thanks and add a few notes:
1. j4nn's renoroot to enable TA key backup and restore is fantastic. My advice: use and donate
2. munted's guide is excellent. clear and thorough...a rare combination.
3. do expect that renoroot may need to be restarted a couple of times. it took me 3 or 4 attempts to get temp root to pull the TA keys, although it took only 1 effort to get root back to restore.
4. topjohnwu's magisk is, of course, a key component to all this. Thx and $s there too.
I did a few things slightly differently/additionally than SunJu22.
5. I am on T-Mobile US, so I opted to create a hybrid Pie FW to get wifi calling and VoLTE. There are a number of discussions on this. I did it by combining the vendor**.sin and system**.sin files from custom-CH FW with the other files from custom-US FW. Of course (a) use IDENTICAL release numbers only, e.g. 47.A.2.10.28 w/ 47.A.2.10.28 and (b) you still need to delete .TA and persist files from the hybrid before you flash it.
Note: I don't really care about these features, but I have *heard* that T-mobile won't allow BYOD on their band-12 sites if they don't have VoLTE. Don't know if it is true (or where it is true) but figured why not?
6. I decided (for now, at least) to leave boot and recovery stock. So, I am using fastboot to run TWRP or a rooted kernel. Thanks again to j4nn for the method.
Note: I don't plan on allowing FOTA upgrades---I just like passing all the security checks and being able to *see* if updates are available.
That's all. Fine work in development and guides has made life simple and happy for me

kirkzp said:
Very happily rooted now. Just wanted to say a quick thanks and add a few notes:
1. j4nn's renoroot to enable TA key backup and restore is fantastic. My advice: use and donate
2. munted's guide is excellent. clear and thorough...a rare combination.
3. do expect that renoroot may need to be restarted a couple of times. it took me 3 or 4 attempts to get temp root to pull the TA keys, although it took only 1 effort to get root back to restore.
4. topjohnwu's magisk is, of course, a key component to all this. Thx and $s there too.
I did a few things slightly differently/additionally than SunJu22.
5. I am on T-Mobile US, so I opted to create a hybrid Pie FW to get wifi calling and VoLTE. There are a number of discussions on this. I did it by combining the vendor**.sin and system**.sin files from custom-CH FW with the other files from custom-US FW. Of course (a) use IDENTICAL release numbers only, e.g. 47.A.2.10.28 w/ 47.A.2.10.28 and (b) you still need to delete .TA and persist files from the hybrid before you flash it.
Note: I don't really care about these features, but I have *heard* that T-mobile won't allow BYOD on their band-12 sites if they don't have VoLTE. Don't know if it is true (or where it is true) but figured why not?
6. I decided (for now, at least) to leave boot and recovery stock. So, I am using fastboot to run TWRP or a rooted kernel. Thanks again to j4nn for the method.
Note: I don't plan on allowing FOTA upgrades---I just like passing all the security checks and being able to *see* if updates are available.
That's all. Fine work in development and guides has made life simple and happy for me
Click to expand...
Click to collapse
Now riddle me this cause I'm on Tmo USA as well and I did the hybrid work fine as well but heres the question, does googlepay and banking apps still work with a unlocked bootloader or did you flash a modified kernel to hide the unlocked status.
Sitting on the fence about unlocking mine so I can do a full nandroid before trying out some gsi pie roms infact this is the first phone I haven't unlocked or least put twrp on since my samsung sidekick 4g o.o

kernel with hide-unlock
T_Tank said:
Now riddle me this cause I'm on Tmo USA as well and I did the hybrid work fine as well but heres the question, does googlepay and banking apps still work with a unlocked bootloader or did you flash a modified kernel to hide the unlocked status.
Sitting on the fence about unlocking mine so I can do a full nandroid before trying out some gsi pie roms infact this is the first phone I haven't unlocked or least put twrp on since my samsung sidekick 4g o.o
Click to expand...
Click to collapse
Full disclosure: I don't use Google pay or too many banking apps, so YMMV. But, I am using j4nn's kernel with unlock hidden. (See link in my note 6.) You can flash this, or you can leave in your stock kernel and merely fastboot to this. From what I have seen, it hides most - if not all -- indicators that the phone is rooted and the BL in unlocked.

Does somebody has :
G8441_1310-7123_47.1.A.16.20-R7B_Customized_CE1.ftf ?
Only backup i did not make, and its gone from XperiFirm.
Still have the feeling battery life was better in Oreo, and would be nice for experimenting.
Would be nice.
Thanks in advance.