Database Users

Custom recovery- padlock unlocked

I bought an AT&T 32 GB Galaxy S4 (SGH-I337) yesterday and rooted it using the "MotoChopper" method . I then tried to find a custom recovery and didn't come up with any . This morning i got a pop saying i have an update from AT&T, I downloaded "RootKeep" click on save root then took the update. While the phone was rebooting i noticed it was saying "Custom recovery" with an Open Padlock. What does this mean ?. I know on other devices an open padlock means the Bootloader is unlocked .

jawonder said:
I bought an AT&T 32 GB Galaxy S4 (SGH-I337) yesterday and rooted it using the "MotoRooter" method . I then tried to find a custom recovery and didn't come up with any . This morning i got a pop saying i have an update from AT&T, I downloaded "RootKeep" click on save root then took the update. While the phone was rebooting i noticed it was saying "Custom recovery" with an Open Padlock. What does this mean ?. I know on other devices an open padlock means the Bootloader is unlocked .
Click to expand...
Click to collapse
It doesn't say "Custom Recovery", it just says "Custom" - and all it indicates is that you're rooted. I encourage you to go read a couple of the threads in this forum...in which you'd find out that we still have a locked bootloader (until djrbliss releases his exploit later this month hopefully) and, thus, no way to install a custom recovery yet.
Edit: This is from the Motochopper root thread's OP:
djrbliss said:
Warning:
At this point, since there are no custom recoveries or stock images available, it may not be possible to repair your device should you accidentally break it. Please be aware of this before performing any modifications to your phone.
Click to expand...
Click to collapse

CPA Poke said:
It doesn't say "Custom Recovery", it just says "Custom" - and all it indicates is that you're rooted. I encourage you to go read a couple of the threads in this forum...in which you'd find out that we still have a locked bootloader (until djrbliss releases his exploit later this month hopefully) and, thus, no way to install a custom recovery yet.
Edit: This is from the Motochopper root thread's OP:
Click to expand...
Click to collapse
Yeah sorry don't know why i put Custom Recovery instead on custom . Will do some reading in the thread . Thanks

jawonder said:
Yeah sorry don't know why i put Custom Recovery instead on custom . Will do some reading in the thread . Thanks
Click to expand...
Click to collapse
No prob. I'm right there with you in desperately awaiting that bootloader unlock!

[Q] [SOLVED] Disabling "Device Status - Custom" Scanning

This question is mostly aimed at the Devs, but if there's already a thread out there, please simply point me in the correct direction - thanks.
The question: How do we disable the scan that checks /system for modifications and marks the phone as "custom" ?
Disclaimer: I'm not interested in warranty fraud - that's just silly. I just want to be able to run custom kernels or delete bloatware (instead of freezing) and still retain the nice Galaxy S4 logo on startup... not the ugly "Custom" padlock/logo.
As mentioned by @scott14719 in this post, disabling the scan altogether may cause other problems (won't know until we try?). However, it seems clear to us that this scan, upon determining that the /system is indeed customized, throws a red flag that is read by the bootloader upon next startup. My goal here would be to either disable the scan altogether, or somehow permanently disable this red flag.
Not knowing much about the scan itself, here's some more observations that might help:
Most critically, the padlock/"custom" boot screen is NOT triggered until this scan is run and the system is flagged.
The scan runs immediately upon startup and finishes within about 38 seconds of uptime. Might take longer if more files have been added to /system or if more apps are running on startup (and slowing it down).
If you quickly go look at the Device Status in About Phone within the first 38 seconds of startup, you can see that it is "scanning" at this time.
It seems that the scan does not run again until the next system startup.
A custom recovery does not trigger "custom".
A custom kernel triggers the "custom".
Freezing bloatware does not trigger the "custom".
I once uninstalled a lot of bloatware, and this triggered "custom". I haven't checked to see if it's any system apps that trigger it, or if only certain apps are monitored.
Having busybox and/or Superuser properly in-place will trigger "custom".
All this being said, can anyone offer some more insight into this scan, and more ideally: has anyone found a way to disable it?
EDIT:
Thank you everyone for your replies. I've finished a working solution here: http://forum.xda-developers.com/showthread.php?t=2333700

I think that splash screen is compiled into the kernel or aboot on these phones but im not 100% sure, there are a few threads in the s3 area about changing the splash but it requires an unlocked boot loader.
Sent from my GT-I9505 using xda app-developers app
---------- Post added at 10:52 PM ---------- Previous post was at 10:48 PM ----------
http://forum.xda-developers.com/showthread.php?t=2257058
Sent from my GT-I9505 using xda app-developers app
Try this also.

If code can be located and then changed to report "official" no matter what the scan returns, it would be a huge hurdle.

C13v3r0n3 said:
I think that splash screen is compiled into the kernel or aboot on these phones but im not 100% sure, there are a few threads in the s3 area about changing the splash but it requires an unlocked boot loader.
Sent from my GT-I9505 using xda app-developers app
---------- Post added at 10:52 PM ---------- Previous post was at 10:48 PM ----------
http://forum.xda-developers.com/showthread.php?t=2257058
Sent from my GT-I9505 using xda app-developers app
Try this also.
Click to expand...
Click to collapse
I believe you are correct in that the only way to remove or modify the boot screen itself would be to have an unlocked bootloader. However, I believe that we should be able to keep it from ever showing the "custom" screen, simply because it's clear that the system doesn't check for "custom" during the time that this screen is shown. Rather, it's fed by a variable or tidbit of code somewhere.
Also, regarding the thread you linked: this of course works fine... until you make any modifications to /system. I've used this method a few times myself, even. But once I uninstall masses of bloatware or install a custom kernel, this method won't work anymore until the changes are restored.
scott14719 said:
If code can be located and then changed to report "official" no matter what the scan returns, it would be a huge hurdle.
Click to expand...
Click to collapse
Without an unlocked bootloader, I believe this is the only way we can accomplish this... apart from preventing the scan to begin with, of course.

Aou, here is an interesting read that I think may, at least partly, apply to our device...
http://forum.xda-developers.com/showthread.php?p=38934760
I haven't had a chance to check the entire thread or the links within that thread but it seems like some people have already put some thought into this. Maybe something can be built on top of this.
**Edit**
It seems that we are definitely thinking about this the correct way. This is a post about the Verizon S3 bootloader unlock but the custom screen is discussed heavily between pages 7 and 12.
http://forum.xda-developers.com/showthread.php?t=1769411&page=7
post 68 seems to show exactly the point where the code for custom or official exists on that phone. I am willing to bet it is very similar on the AT&T S4. However, reading these threads shows me that some very smart guys (including Adam Outler) are way deeper into understanding this than I could ever be. Though, maybe it shows that there is hope for this after all.

Im am sure the local android badasses will figure it out, we have some beast devs around here.
Sent from my GT-I9505 using xda app-developers app

That is interesting - I jumped straight from the S2 to the S4, so I had no idea about SysScope. Out of curiosity, I froze the following two apps and restarted:
EdmSysScopeService.apk
SysScope.apk
Upon restart, I had the "Custom" status. Also, it took a lot longer for the "Device status" to finish Scanning. but now shows custom.
I'll play with this a bit more...

Aou said:
That is interesting - I jumped straight from the S2 to the S4, so I had no idea about SysScope. Out of curiosity, I froze the following two apps and restarted:
EdmSysScopeService.apk
SysScope.apk
Upon restart, I had the "Custom" status. Also, it took a lot longer for the "Device status" to finish Scanning. but now shows custom.
I'll play with this a bit more...
Click to expand...
Click to collapse
Another interesting post...
http://forum.xda-developers.com/showpost.php?p=29227801&postcount=107
and
http://forum.xda-developers.com/showpost.php?p=29244923&postcount=109
Again, this is not from our phone but it seems pretty damn close. This post is from the second link I posted above.

scott14719 said:
Another interesting post...
http://forum.xda-developers.com/showpost.php?p=29227801&postcount=107
and
http://forum.xda-developers.com/showpost.php?p=29244923&postcount=109
Again, this is not from our phone but it seems pretty damn close. This post is from the second link I posted above.
Click to expand...
Click to collapse
It might still be applicable. Going to bed for now, but it sounds like the devs in this thread you linked to have managed to accomplish exactly what I'm after here. I wonder if any of them have posted more details elsewhere...

Again from the Verizon S3 thread...
http://forum.xda-developers.com/showthread.php?t=1781471
This has more to do with the counter, but the areas of code are the same.
Of course, that is if the Verizon S3 has a similar code as the AT&T S4.
**EDIT**
Some more information about Sysscope from the Note II forum. This just helps to show what it scans and why it returns "custom". The code will still need to be located and modified for the S4 (similar as described in one of the links I posted in one of my above posts about the S3) in order to keep the phone as "official".
http://forum.xda-developers.com/showthread.php?t=2285894
This post also helps to show why just freezing, deleting, or modifying syscope will still return a "custom" status. Other processes are at work to make sure syscope is authentic. That is why the code which decides what is returned (after the scan) needs to be modified.

TRY THIS: http://forum.xda-developers.com/showthread.php?p=42062451#post42062451

Aou said:
This question is mostly aimed at the Devs, but if there's already a thread out there, please simply point me in the correct direction - thanks.
The question: How do we disable the scan that checks /system for modifications and marks the phone as "custom" ?
Disclaimer: I'm not interested in warranty fraud - that's just silly. I just want to be able to run custom kernels or delete bloatware (instead of freezing) and still retain the nice Galaxy S4 logo on startup... not the ugly "Custom" padlock/logo.
As mentioned by @scott14719 in this post, disabling the scan altogether may cause other problems (won't know until we try?). However, it seems clear to us that this scan, upon determining that the /system is indeed customized, throws a red flag that is read by the bootloader upon next startup. My goal here would be to either disable the scan altogether, or somehow permanently disable this red flag.
Not knowing much about the scan itself, here's some more observations that might help:
Most critically, the padlock/"custom" boot screen is NOT triggered until this scan is run and the system is flagged.
The scan runs immediately upon startup and finishes within about 38 seconds of uptime. Might take longer if more files have been added to /system or if more apps are running on startup (and slowing it down).
If you quickly go look at the Device Status in About Phone within the first 38 seconds of startup, you can see that it is "scanning" at this time.
It seems that the scan does not run again until the next system startup.
A custom recovery does not trigger "custom".
A custom kernel triggers the "custom".
Freezing bloatware does not trigger the "custom".
I once uninstalled a lot of bloatware, and this triggered "custom". I haven't checked to see if it's any system apps that trigger it, or if only certain apps are monitored.
Having busybox and/or Superuser properly in-place will trigger "custom".
All this being said, can anyone offer some more insight into this scan, and more ideally: has anyone found a way to disable it?
Click to expand...
Click to collapse
As others pointed out throughout the thread, the file responsible for checking the system status at boot is SysScope. There are various ways of trying to "full" the system into believing that it was NOT modified when in fact it was but one that has been working fine on my Note 2 as well as the S4, uses an XPosed Framework module called...yeah, you guessed it, SysScope.
Furthermore, if you're not familiar with XPosed Framework you'll be in for a NICE surprise as, once the framework installed it gives you the possibility of installing many other modules - real goodies, and I mean real goodies!!!
A word of caution: DO NOT INSTALL any version of XPosed Framework prior to 2.1.4- it'll soft brick your S4.
Take a look at the attached screenshot. Needless to say that my phone is heavily customized/modified.

Awesome! I would still like to know how to modify the code manually ( incase people don't want to use XPosed for whatever reason), but this is getting pretty close to the objective and I think will work for most. Thank you.

Here something very interesting. All credit goes to Mr. Impossible. I have not tried this so it should be interesting to see how well it works.
http://forum.xda-developers.com/showpost.php?p=42098246&postcount=729

scott14719 said:
Awesome! I would still like to know how to modify the code manually ( incase people don't want to use XPosed for whatever reason), but this is getting pretty close to the objective and I think will work for most. Thank you.
Click to expand...
Click to collapse
This SysScope Xposed module says its re-enables logcat'ing for SysScope. Maybe with this enabled, you can tell what functions need modifications. But if something else is monitoring SysScope's integrity, the rabbit hole may get pretty deep. The advantage of something like Xposed is that the apps are not modified so something checksum'ing them won't notice anything different.
For what its worth, I restored my device using Odin and rooted it. Followed the common steps to replace SuperSU with Superuser and rebooted a couple of times until the "custom" message was gone. I booted into recovery, installed CM10.1 and never looked back. My phone boots with the standard logo now each time because CM doesn't have SysScope.

romracer said:
This SysScope Xposed module says its re-enables logcat'ing for SysScope. Maybe with this enabled, you can tell what functions need modifications. But if something else is monitoring SysScope's integrity, the rabbit hole may get pretty deep. The advantage of something like Xposed is that the apps are not modified so something checksum'ing them won't notice anything different.
For what its worth, I restored my device using Odin and rooted it. Followed the common steps to replace SuperSU with Superuser and rebooted a couple of times until the "custom" message was gone. I booted into recovery, installed CM10.1 and never looked back. My phone boots with the standard logo now each time because CM doesn't have SysScope.
Click to expand...
Click to collapse
The Xposed module for SysScope does appear to work well. I agree that it would be nice to know how to modify a stock (or TW-based) ROM such that SysScope is removed without the other apps noticing.
I'm thinking that in your case, romracer, the bootloader last knew your status to be "official" - and because SysScope (and other related checks for it) are completely gone, the bootloader has no way of knowing otherwise. Interesting. I wonder if there's something we can do to these handful of apps to "neuter" them, keeping them from reporting to the bootloader that the status is Custom.

Sweet! It worked! No longer showing custom icon!!

Update: I've got a working solution here: http://forum.xda-developers.com/showthread.php?t=2333700

Aou said:
Update: I've got a working solution here: http://forum.xda-developers.com/showthread.php?t=2333700
Click to expand...
Click to collapse
Awesome, I knew you would get it going.

Has anyone been able to automate this procedure to make it more simple? Seems like quite a bit involved to get it done. Would like to see the Custom status gone for good but wouldn't mind a simpler solution
Sent from my GT-I9505 using XDA Premium 4 mobile app

Un-rooting and Bootloader Question

My Galaxy S4 stopped working and I'm planning to send it back to get a replacement. However, I rooted my phone before this happened and I'm planning to un-root it before sending it back. I was planning on using the Triangle Away app as well to reset the flash counter but apparently I need to unlock the bootloader first. I read in this thread that you can flash a recovery and root the phone at the same time.
Would using that tool help me in unlocking the bootloader so that I can use the Triangle Away app to reset the counter and un-root my phone using Odin afterwards? The topic creator mentioned that TWRP will auto-lok anything you flash and works as a bootloader unlock but can anyone confirm this? I bricked my Galaxy S3 two weeks ago and don't want to face the same problems with this newly aquired Galaxy S4.
Is it worth it to go through all the trouble to just reset the flash counter or would un-rooting the phone be enough to send the phone back for a replacement?

http://forum.xda-developers.com/showpost.php?p=42320414&postcount=2

Thanks, that guide looks really helpful. I do have one question though, it seems the Triangle Away app needs the boot loader unlocked in order to run successfully on the AT&T Galaxy S4 so what would be a good and simple way to unlock the bootloader and is there a way to check whether or not mine is unlocked? Would running the CASUAL tool take care of this (even if my device is already rooted)?

What guide/method did you use to root? Did you not use the bootloader exploit at that time?

I used the Motochopper tool located on this thread. I hadn't researched enough to know about the CASUAL tool at the time

Un-Rooting
Zernell said:
I used the Motochopper tool located on this thread. I hadn't researched enough to know about the CASUAL tool at the time
Click to expand...
Click to collapse
Go Here to unroot without flashing
http://androidtechy.com/index.php/2013-04-28-19-55-53/how-to-diy/48

pharrisworth said:
Go Here to unroot without flashing
http://androidtechy.com/index.php/2013-04-28-19-55-53/how-to-diy/48
Click to expand...
Click to collapse
Hmm...yeah I can see that method would probably work, but that wouldn't reset the flash counter to 0 would it? If the seller happens to notice that, then they won't send me a replacement and will probably tell me my warranty is void; hence why I'm trying to get the Triangle Away app to work but need the boot loader unlocked first in order to do that.

Un-Rooting
Zernell said:
Hmm...yeah I can see that method would probably work, but that wouldn't reset the flash counter to 0 would it? If the seller happens to notice that, then they won't send me a replacement and will probably tell me my warranty is void; hence why I'm trying to get the Triangle Away app to work but need the boot loader unlocked first in order to do that.
Click to expand...
Click to collapse
Well if all you did was ROOT the flash counter shouldn't be affected. Iused the same tool. I took the additional step of replacing Superuser with SU user. to rid myself of the "custom" unlocked symbolon boot up. However, the phone was NEVER really unlocked.

Thanks for the replies! I managed to un-root the phone by just flashing the AT&T stock firmware using Odin. Hopefully the binary counter won't be an issue.

Remove "Device has been modified"

I am so new, and so sorry, but this might be simple for others.... I am trying to undue what I did like 6 months ago. I know I downloaded something from the web from here (drawing a blank on the name, but it looked like the "anarchy A", it was just a quick easy way to ROOT. I don't think I did anything else, I know I never added a custom ROM. Can someone just tell me where to check to see what is modified. Then maybe I will be able to undue the rest.

hisandherturbo said:
I am so new, and so sorry, but this might be simple for others.... I am trying to undue what I did like 6 months ago. I know I downloaded something from the web from here (drawing a blank on the name, but it looked like the "anarchy A", it was just a quick easy way to ROOT. I don't think I did anything else, I know I never added a custom ROM. Can someone just tell me where to check to see what is modified. Then maybe I will be able to undue the rest.
Click to expand...
Click to collapse
Did you root your phone? Or did you install custom recovery? Or custom kernel? All of these may lead to the "Device has been modified" message.
You may also want to check for the Knox Warranty Status with Phone INFO ★Samsung★ app.

I did "root" it... it was a software root, I can not remember what it was called..... like I tried to explain, it looked like an "A".
thank you for the APP... KNOX is 0x0.... what else can I look at?

If you keep your phone, it really does not matter, but If you are going to sell it, then flash full image with Odin, it will bring everything back to stock, removing the root, all the red letter messages, etc. If you need help with using Odin, let us know.

TowelRoot was the software I used....

vndnguyen said:
Did you root your phone? Or did you install custom recovery? Or custom kernel? All of these may lead to the "Device has been modified" message.
You may also want to check for the Knox Warranty Status with Phone INFO ★Samsung★ app.
Click to expand...
Click to collapse
TowelRoot is the software I used... also, I am pretty sure I didn't install any recovery.... isn't there somewhere I can look to see what is/was done?

hisandherturbo said:
TowelRoot is the software I used... also, I am pretty sure I didn't install any recovery.... isn't there somewhere I can look to see what is/was done?
Click to expand...
Click to collapse
Hummh, you may need to post all screenshots from Phone INFO ★Samsung★ app for further investigation. Without the detailed info, no one can say anything for sure.

Here are some, is this enough?

hisandherturbo said:
Here are some, is this enough?
Click to expand...
Click to collapse
Not really enough, but I didn't see anything abnormal in your device info.
May be the reason is because your device has been rooted .
Try the following:
- Reflash the stock firmware. You will lost root.
- Or use Wanam Xposed > Security hacks > Fake system status.

Actually the very first screen you posted clearly says charger info requires root and it's blank so it doesn't seem like you have a root ATM and none of the 4 screens posted has Knox info, again its first page on the phone info (general info header) on the bottom, should say Knox warranty void 0 (good) or 1 for flag being tripped.
---------- Post added at 02:39 AM ---------- Previous post was at 02:24 AM ----------
Actually the very first screen you posted clearly says charger info requires root and it's blank so it doesn't seem like you have a root ATM and none of the 4 screens posted has Knox info, again its first page on the phone info (general info header) on the bottom, should say Knox warranty void 0 (good) or 1 for flag being tripped.

I really appreciate the help!
I "un-did" the towelroot, and KNOX does say 0X0.....
Here are the other screen shots....
If I remember correctly.... before when the towelroot was there, root info says I was rooted, and my device status was NOT custom.... so, I think it was something other then the root that did it.

My KNOX is still 0
I've tried to "factory data reset" from both the Android software and also the boot up screen (after I wiped the cache).
No matter what I do Device Status is still "custom"
There has to be something/somewhere I am missing.....

Here is a picture of my download page.... showing the custom status

For future searches.... FIXED..... I Downloaded Samsung KIES 3... and let it update the firmware... then I was official.

Would it be plausible to use JTAG to rewrite an unlocked firmware?

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