I know that the Verizon bootloader is almost impenetrable as is, but would it be plausible to completely go over the head of the firmware and directly write an image with JTAG that would allow for custom software? If so, would it be possible to use the firmware from another carrier like USC or would it have to be a custom image?
EDIT: summary of the method and everything I have thusfar discovered
So, this method after a bit of evolution, got to the point it basically entailed the following: Using the SD Card debrick method (popularized by the galaxy s3 LTE variants) a modified firmware image would be written to an SD Card, and the phone would boot from that image. The main problem I ran into: it would not let me flash anything that could brick the phone, nor was I able to pull the usb cord at the right moment and try and manually brick it. I was able to flash firmware and stock tars from other variants of the phone (such as the one that runs on T-mobile), but what I found out through that is a couple things:
1. The stock tars seem mostly carrier independent, and I was without any modification able to flash a T-mobile bootloader, system image, and pit file, but within recovery and download mode it would show that because of integrated CSC, it would still change back to the original variant. This could have implications for a very simple method of removing bloat from the phone, but I'm not so sure
2. It must have a very low level method of injecting information and file verification that is not located anywhere on eMMC
The latter led me to research a TON, eventually finding that the most likely culprit is the use of Qualcomm Qfuses, non-volatile pre-set memory located directly on the SoC, to check how the bootloader is signed. They consist of a couple blocks of registers, and definitely aren't readily writable. The trusted base of the entire secure system, the same system that KNOX invokes on other systems, is within a series of Qfuses. From what I have deduced, however, they must be at some software level writable, as although the Knox counter is an e-fuse, the others (such as the warrantee bit) have been both changed upon their void and reverted when brought back to a service center. This must mean that the entire block is possible to modify in both directions, unlike a fuse or breaker; It seems to act more like flash memory than a "fuse." This is very good, mainly because if the service center can change it it means that jtag has not been disabled by those flags, and is enabled in at least some form. What this also means is that without another MAJOR exploit within unfortunately simple, clean code or a leak of several RSA keys from verizon, either current workarounds such as safestrap are the answer for the foreseeable future, or a method of manually changing a simgle Qfuse (the one that controls the "Qualcomm Secureboot" flag) could be used.
What I'm hopefully going to start at some point here is research into finding a way of accessing and changing that Qfuse via JTAG. I have no money for a JTAG box at the moment, so it'll have to wait, but if anyone who already has one wants to use it, hopefully this info helps
P.S. I figured out exactly what T-flash does in odin: it flashes the files that you input into odin to the currently inserted SD Card (or so it seems, I could be wrong but that's what it did for me)
P.P.S. Verizon, I respectfully request that...oh never mind, profanity is definitely frowned upon here
Also, I'm in ongoing discussion with the FCC as to block C violations by Verizon of aspects of the regulations that upon research have not really been argued to any substantial extent, so if that comes to fruition hopefully there'll be simple ODIN flashable patches for this stuff :fingers-crossed:
UPON REFLECTION: if the phone could be bricked, either by very subtly corrupted file or by interrupting a flash at the right moment, then could the debrick image from a tmobile galaxy s5 with an unlocked bootloader be used as not a method of flashing the on-board bootloader but as a kind of external boot, so a permenantly installed SD Card that would be permissive of modified kernels and such but still accepted as a boot device by the phone?
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
tr4nqui1i7y said:
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
Click to expand...
Click to collapse
what was done with the droix x? Did they use a direct JTAG patch?
I just realized something. From reading here: http://forum.gsmhosting.com/vbb/f200/how-fix-samsung-galaxy-s5-sm-g900f-dead-boot-1813266/
It seems to show that the S5 has a "alternative boot upon init fault" method similar to that that allows the galaxy s3 debrick to work (I have a guide I made with details) so would it be possible to somehow corrupt a very important part of the bootloader in an official update (would one or two bits still mess with the signature?), apply that, and have an insecure bootloader on a microsd card in the phone allowing it to boot into that, then use that with odin to flash an insecure bootloader to the s5 itself?
Now I have to ask an interesting question somewhere (since he: http://forum.xda-developers.com/verizon-galaxy-s5/help/g900v-hard-brick-t2914847 seems to have done it): "guys how do I brick my sm-g900v?"
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
tr4nqui1i7y said:
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
Click to expand...
Click to collapse
I think it might actually be easier
So long as a couple conditions are met for it:
1. The bootloader alone determines if an image is "signed" or not (like when flashed in odin)
2. The same UnBrick exploit from the S3 LTE variants works in some form (secondary storage, fault-triggered boot)
3. It is possible to get it to load a modified bootloader from that secondary boot (this is why number 1 is important)
4. KNOX is completely firmware based, and doesn't have any chip based verification
5. I or someone else actually knows how to modify the bootloader such that it will allow unsigned images (even if not removing it all together, then changing the key to one they publicize so people can sign their rom with it)
If all of these are met, then we might actually have free root! Basically all it would involve would be bricking the device badly enough it boots from secondary storage, have that secondary boot have a "back door" that allows a custom image to be flashed, that allows a bootloader image to be flashed that allows for a signed recovery (signed with that publicly available code) to be flashed without having to deal with safestrap or anything like that. Just full root like on any other phone. Anyone want to offer an opinion? Will this work? I would love to try this out, though I'm a bit unwilling to offer my s5 as a sacrifice just yet as I don't have a JTAG unit on site. I know the bounty is probs gone but I'm ok just getting my bootloader unlocked an' $#*+
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
tr4nqui1i7y said:
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Click to expand...
Click to collapse
Have you found anything yet?
dreamwave said:
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
Click to expand...
Click to collapse
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
dreamwave said:
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
Click to expand...
Click to collapse
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
that's why I'm hoping the debrick image method will work
tr4nqui1i7y said:
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
Click to expand...
Click to collapse
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom. Also, safestrap didn't do a thing with the bootloader, it was done during kernel init, right after firmware finishes. If a phone is hard bricked then adb won't work, and what I'm getting at is hard bricking it then using the debrick image thing
dreamwave said:
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom
Click to expand...
Click to collapse
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Click to expand...
Click to collapse
I don't know, I got it to go back to when root was still possible to get via an app. I don't see why there's a need to downgrade the bootloader if the debrick image thing works
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
Click to expand...
Click to collapse
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
dreamwave said:
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
Click to expand...
Click to collapse
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
tr4nqui1i7y said:
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
Click to expand...
Click to collapse
but that has already been done I think, root on a system with any bootloader so long as a root exploit exists for the OS
That's safestrap. It doesn't allow custom kernels or a full custom recovery though, that's why I'm trying to modify the bootloader
Can anybody help?I am S Off. Unlocked. Rooted. I am currently on Nu Sense Rom. Need to get back to stock for warranty purposes. I try flashing the Verizon zip and get mismatch issues. 7 RU CID FAIL. Thanks for your help.
artpena2323 said:
Can anybody help?I am S Off. Unlocked. Rooted. I am currently on Nu Sense Rom. Need to get back to stock for warranty purposes. I try flashing the Verizon zip and get mismatch issues. 7 RU CID FAIL. Thanks for your help.
Click to expand...
Click to collapse
Did you make a backup of the stock system image before flashing a custom rom? I haven't tried going back to stock any other way, but I'm fairly certain that the only way to RUU back to stock is if you have a completely stock copy of your system image to restore in TWRP.
Out of curiosity, what issue are you having that require warranty service?
I'm also having trouble finding a guide to this; I've bricked phones in the past, or had issues with reverting to sell that ended up costing me 3 hours of troubleshooting.
Basically I've now found that Android Pay is something that I wish to use again; and with the N update for VZW coming out very soon I might as well go back to full stock with my bootloader locked again now that the main reason I went to s-off/unlocked was for N.
Anyone know where the guide is? If there isn't one, I will outline the steps that I think I need to take, but could use some help to make sure I don't jank it up.
1. Get the RUU from the stock ruu thread.
2. Flash said RUU
3. Factory Reset
4. ???
5. Profit?
As you can see, I'm missing the parts where I re-lock the bootloader, change the tamper flag, fix potential LTE problems (I've read that might be an issue), and whatever else might need to be done to full revert it to legit VZW.
If it matters; I have a (rooted) stock backup from 1.85.605.8 I can flash to make this easier, as I recall having to do that for prior HTC phones (I think).
Hey all.
So I've installed LineageOS just fine - the unlocking guides around here are mostly clear enough. Certainly not as easy as I've been used to for Nexus and OnePlus devices though! I've been using the 'official' TWRP 3.0.4.1 and not any of the other (now often links removed) unofficial versions.
I've also got my hands dirty with EDL mode and have totally reflashed a couple of times while playing around.
So on to my question. Basically I have an email client for work (Good for Enterprise) that detects unlocked bootloaders as 'root' (even though I'm not rooted), so I would like to relock my bootloader.
However, as soon as I use 'fastboot oem lock' it instantly bricks my phone. It goes straight into EDL mode, from which it cannot return. No bootloader, no recovery mode, no booting of system. Completely dead. All button combos attempted etc.. The only way back that I've found is to flash a whole new system image in EDL, and start over.
So, have I missed something (a signed recovery?) that makes this happen? Are there some verifications that the bootloader does while locked that fails because there's a custom system and recovery in place?
Is there anything I can do about this? Am I doomed to use stock for as long as I need to use this darned app?
Thanks very much!
Yes you need to be completely stock to lock BL.
Also if you want to stay unlocked, you can use MAGISK to hide root for your mailing app.
Thanks for the replies. I actually don't have, and never have had, root. So the only thing it can possibly be detecting is either the custom ROM itself (or rather, not a factory one from some list they maintain) or the unlocked bootloader. So I doubt MAGISK will work, because there's no root there to hide in the first place
(In case it wasn't obvious, we're talking about Good for Enterprise here).
The blackberry mobile device management system (earlier called GFE) doesnt care if bootloader is unlocked, it just checks whether you have a custom recovery (twrp) and that is enough to flag your system as rooted.
Anyone one know if it is possible to get security off on ph-1?
I am thinking of maybe secure boot maybe.
I would like to relock bootloader with custom O/S.
Sorry it has been a long time since working on new device. Dual partitions, fastboot flashing unlock_critical, felt lost there for a bit. boot loops, no touch in twrp.
stupidis said:
Anyone one know if it is possible to get security off on ph-1?
I am thinking of maybe secure boot maybe.
I would like to relock bootloader with custom O/S.
Sorry it has been a long time since working on new device. Dual partitions, fastboot flashing unlock_critical, felt lost there for a bit. boot loops, no touch in twrp.
Click to expand...
Click to collapse
S-Off = unlock_critical...
DO NOT RELOCK YOUR BOOTLOADER UNLESS ON STOCK STOCK STOCK...
YOU
WILL
BRICK
YOUR
DEVICE
rignfool said:
S-Off = unlock_critical...
Click to expand...
Click to collapse
if unlock critical = s-off then I would be able to relock my bootloader with whatever software was on the device. at least that was the way it was years ago when I started with android on the HTC one-s (At least that is what I remember - getting old
The question I am getting at here -- I want to relock the bootloader with custom firmware on the device.
This is my device I should be able to replace security controls after I make changes relocking the bootloader would help with that - besides I have clients that do not understand physical security.
So what would it take to get a phone where I can make the software changes I want to make and then relock the bootloader?
What follows is possibly useless information:
I need to figure out how to do hide content button that way I can put useless info in, but hide it with a button
HTC One-s now that was a learing curve, root, s-off, super CID, custom radios, etc, all command line and hexeditors etc - I did mine before all the tools came out to do these things for devices. Fun fun
And thank you! let me reiterate.
DO NOT RELOCK YOUR BOOTLOADER UNLESS ON STOCK STOCK STOCK...
Hi,
Recently bought a Motorola Moto G5 Plus 2nd hand. It came rooted, TWRP, a custom ROM, etc. I'm pretty technical, but haven't done much in this arena.
Basically what would you got a phone from a stranger to "re mediate" it to the point you were comfortable (meaning felt it was probably not compromised in some way) using it? As an example, if this were a laptop I'd picked up 2nd hand, I'd format the drive and do a fresh OS install.
Some of my concerns:
1) How do I determine how it was rooted? I'm concerned the guy had some 3rd party "one click" style app use an exploit (and maybe install malware or a root kit). My understanding is some manufacturer's will provide keys on request and that's the right way to get root.
2) Can anyone point me to a good resource on understanding how the file system is setup? I'm not sure what a factory reset will do. Will it just reset the OS? Wipe the recovery partition? Reinstall the locked bootloader? Etc. It's all a little fuzzy to me.
Thanks
This phone is unlocked with manufacturer provided keys.
androidQuestions34 said:
Hi,
Recently bought a Motorola Moto G5 Plus 2nd hand. It came rooted, TWRP, a custom ROM, etc. I'm pretty technical, but haven't done much in this arena.
Basically what would you got a phone from a stranger to "re mediate" it to the point you were comfortable (meaning felt it was probably not compromised in some way) using it? As an example, if this were a laptop I'd picked up 2nd hand, I'd format the drive and do a fresh OS install.
Some of my concerns:
1) How do I determine how it was rooted? I'm concerned the guy had some 3rd party "one click" style app use an exploit (and maybe install malware or a root kit). My understanding is some manufacturer's will provide keys on request and that's the right way to get root.
2) Can anyone point me to a good resource on understanding how the file system is setup? I'm not sure what a factory reset will do. Will it just reset the OS? Wipe the recovery partition? Reinstall the locked bootloader? Etc. It's all a little fuzzy to me.
Thanks
Click to expand...
Click to collapse
As a custom ROM is installed a factory reset will only reset that ROM to it's state when it was installed. To be completely on the safe side you should flash the latest stock firmware for your region by fastboot or use a TWRP flashable stock ROM.
If you don't plan to root the device you will receive future OTA updates with the fastboot flashable version which isn't possible with a TWRP ROM.
Here's the thread for TWRP flashables incl how to do it:
https://forum.xda-developers.com/g5...ble-stock-builds-coming-t3830482/post77359934
Signed fastboot firmwares are here:
https://mirrors.lolinet.com/firmware/moto/potter/official/RETAIL/
There are several tutorial threads around how to flash them, some are outdated and the informations are a little bit disordered.
I'm about to write an actual guide soon.
Can you provide some informations like what custom ROM is installed (which android version) and as it is rooted if an app like magisk or SuperSU is installed.
Btw, the bootloader has to be unlocked when a custom ROM is installed. It is possible to lock it again if you are back on a stock firmware but not absolutely necessary.