G935V/G935U Analysis - Verizon Samsung Galaxy S7 Edge Questions & Answers

So I've had my S7 Edge for about a month now. Great stuff it is, but I honestly do find it a bit lacking compared to my S6 Edge. You can tell the difference between the Exynos7420 and MSM8996 right away with its responsiveness.
But I've updated my vzw S7 to the G935UUEU4BQD2 Nougat firmware. And I've used the ENG Kernel posted by @jrkruse to root my device no problems at all. Although I've figured out a few tweaks that should be added to your Rooting Batch Scripts. These tweaks include which packages to disable in order to prevent random reboots with the ENG Kernel, and CSC tweaks to fix the UI.
I have some questions & observations I'd really appreciate clarification on though, before I get to work on making some real mods.
****
1.) It is very interesting that my device is/was an SM-G935V, but I've flashed the full G935U firmware and the AT&T ENG Nougat Kernel using ODIN 3.12.5 without a hitch.
1A.) The "ENG-ROOT-USA.zip" for S7e Nougat, is an ENG build of Our Stock Kernel/RAMDisk with this in its "default.prop":
Code:
*#
# BOOTIMAGE_BUILD_PROPERTIES
#
ro.bootimage.build.date=Tue Jan 31 15:03:01 KST 2017
ro.bootimage.build.date.utc=1485842581
ro.bootimage.build.fingerprint=samsung/hero2qlteuc/hero2qlteatt:7.0/NRD90M/G935AUCE4BQA6:eng/test-keys
Do those boot.img properties really say our ENG Kernel is actually just signed with the Android 7.0 Test Keys? Aren't those supposed to be publicly available? Can't we then use them with the aosp signbootimg utility? Carliv's image kitchen says that the ENG Kernel uses an aosp format ramdisk.
I mean, That means our G935V and/or the G935U firmware will accept firmware from any of the carriers. So why couldn't we flash the Canadian W8 Bootloader overtop of the U firmware?* Or is there something I'm missing there?
3.) I've always thought that AT&T and Verizon firmware don't mix. But the G935U Modem carries all the U.S. bands already. Technically my AP is that of Sprint. But my kernel/boot.img is that of AT&T. And my device is originally that of Verizon.
So I ask good sirs & madams, what gives?
4.) I bring up point number 3 because I couldn't Willy Nilly just flash firmware cross carrier on my AT&T Note 5 or My Verizon S6 Edge. So apparently there IS an Obvious difference between the G925 and G935 device platforms in the United States. Then again, I've been without a carrier contract/plan since December. I've only used my devices as Wi-Fi Devices for months and haven't had to worry about GSM/CDMA network services since then. If my device boots, it boots. Go me!
I prefer to have the hardware rooted anyways. It saves me from going and buying a whole laptop for the same price as my mobile phone, when the two sets of hardware are comparable in most ways.
5.) My CSC code is XAS regardless if I flash the HOME CSC or the OYM CSC. I think because I don't have a SIM Card present in the device. When I try to update through Samsung SmartSwitch PC, is tries to download and install the firmware updates for the XAS CSC.

Delgoth said:
So I've had my S7 Edge for about a month now. Great stuff it is, but I honestly do find it a bit lacking compared to my S6 Edge. You can tell the difference between the Exynos7420 and MSM8996 right away with its responsiveness.
But I've updated my vzw S7 to the G935UUEU4BQD2 Nougat firmware. And I've used the ENG Kernel posted by @jrkruse to root my device no problems at all. Although I've figured out a few tweaks that should be added to your Rooting Batch Scripts. These tweaks include which packages to disable in order to prevent random reboots with the ENG Kernel, and CSC tweaks to fix the UI.
I have some questions & observations I'd really appreciate clarification on though, before I get to work on making some real mods.
****
1.) It is very interesting that my device is/was an SM-G935V, but I've flashed the full G935U firmware and the AT&T ENG Nougat Kernel using ODIN 3.12.5 without a hitch.
1A.) The "ENG-ROOT-USA.zip" for S7e Nougat, is an ENG build of Our Stock Kernel/RAMDisk with this in its "default.prop":
Code:
*#
# BOOTIMAGE_BUILD_PROPERTIES
#
ro.bootimage.build.date=Tue Jan 31 15:03:01 KST 2017
ro.bootimage.build.date.utc=1485842581
ro.bootimage.build.fingerprint=samsung/hero2qlteuc/hero2qlteatt:7.0/NRD90M/G935AUCE4BQA6:eng/test-keys
Do those boot.img properties really say our ENG Kernel is actually just signed with the Android 7.0 Test Keys? Aren't those supposed to be publicly available? Can't we then use them with the aosp signbootimg utility? Carliv's image kitchen says that the ENG Kernel uses an aosp format ramdisk.
I mean, That means our G935V and/or the G935U firmware will accept firmware from any of the carriers. So why couldn't we flash the Canadian W8 Bootloader overtop of the U firmware?* Or is there something I'm missing there?
3.) I've always thought that AT&T and Verizon firmware don't mix. But the G935U Modem carries all the U.S. bands already. Technically my AP is that of Sprint. But my kernel/boot.img is that of AT&T. And my device is originally that of Verizon.
So I ask good sirs & madams, what gives?
4.) I bring up point number 3 because I couldn't Willy Nilly just flash firmware cross carrier on my AT&T Note 5 or My Verizon S6 Edge. So apparently there IS an Obvious difference between the G925 and G935 device platforms in the United States. Then again, I've been without a carrier contract/plan since December. I've only used my devices as Wi-Fi Devices for months and haven't had to worry about GSM/CDMA network services since then. If my device boots, it boots. Go me!
I prefer to have the hardware rooted anyways. It saves me from going and buying a whole laptop for the same price as my mobile phone, when the two sets of hardware are comparable in most ways.
5.) My CSC code is XAS regardless if I flash the HOME CSC or the OYM CSC. I think because I don't have a SIM Card present in the device. When I try to update through Samsung SmartSwitch PC, is tries to download and install the firmware updates for the XAS CSC.
Click to expand...
Click to collapse
To answer your first question. You didnt look hard enough at the build properties of the engboot.img. If you notice adb secure=0 this means adb is insecure meaning we can mount the system and data partitions which allows us too push files.
Why do we use an ATT engboot.img? Because its all we have
To answer your other question, you can flash any carrier firmware on your S7 as all carrier phones are the same other than them being carrier locked which verizon is not.
Your csc on Ufirm will not change until a carrier sim is inserted. Thats the only way it knows what csc to install the default csc is XAS so with no sim thats what you get. If you want different on flash csc file only from the carriers firmware you want your csc to be

My real question about the ENG Kernel was if it is actually signed with the Google test keys for the Android 7.0 platform or not. Or are those private AT&T only test keys?
Because if it is signed with Google's keys and the device accepts it, doesn't that mean we can sign kernels with the same keys and get it to flash.
I understand why we are able to have ADB Root.

Delgoth said:
My real question about the ENG Kernel was if it is actually signed with the Google test keys for the Android 7.0 platform or not. Or are those private AT&T only test keys?
Because if it is signed with Google's keys and the device accepts it, doesn't that mean we can sign kernels with the same keys and get it to flash.
I understand why we are able to have ADB Root.
Click to expand...
Click to collapse
It's a Samsung signature not Google. If you can figure out how to sign a custom kernel with a Samsung signature then you would probably be a pretty popular guy

Well I was able to find what I believe to be the Verizon Test Keys for 6.0.1 (the .pem & .pk8) back around new years. But I honestly forget what all I can do with those files. I know MM doesn't help for the N firmware. But it's a start. I've been trying to read up on the related topics, but I won't have internet for a couple more weeks.
Do any of the S7 Edge variants have the Maintenance boot mode present in the G925V?
It may be possible to customize the AOSP 'signbootimg' utility in the same ways people like @osm0sis or Cyanogen modify the AOSP 'mkbootimg' & 'unpackbootimg' utilities to help. I mean Samsung must have already done the same thing.

Delgoth said:
Well I was able to find what I believe to be the Verizon Test Keys for 6.0.1 (the .pem & .pk8) back around new years. But I honestly forget what all I can do with those files. I know MM doesn't help for the N firmware. But it's a start. I've been trying to read up on the related topics, but I won't have internet for a couple more weeks.
Do any of the S7 Edge variants have the Maintenance boot mode present in the G925V?
It may be possible to customize the AOSP 'signbootimg' utility in the same ways people like @osm0sis or Cyanogen modify the AOSP 'mkbootimg' & 'unpackbootimg' utilities to help. I mean Samsung must have already done the same thing.
Click to expand...
Click to collapse
There is no "signbootimg" that I know of, only recently with BootSignature.jar for the May Pixel bootloader, and Xiaomi has been using it as well. There's also a newer avbtool from Brillo AOSP but we're not seeing that one in the wild yet.
Other than that there are a few reverse-engineered signing methods like Bump and SignBlob, but as far as I know all Samsung has really had going on is that SEANDROIDENFORCE string to avoid the bootloader message.

osm0sis said:
There is no "signbootimg" that I know of, only recently with BootSignature.jar for the May Pixel bootloader, and Xiaomi has been using it as well. There's also a newer avbtool from Brillo AOSP but we're not seeing that one in the wild yet.
Other than that there are a few reverse-engineered signing methods like Bump and SignBlob, but as far as I know all Samsung has really had going on is that SEANDROIDENFORCE string to avoid the bootloader message.
Click to expand...
Click to collapse
Well then I'm going to have to go back through some bookmarks, in order to find out where I read that. Because AT one point I read an article about how to use the utility to sign a boot.img using the .pem and .pk8 files.

Delgoth said:
Well then I'm going to have to go back through some bookmarks, in order to find out where I read that. Because AT one point I read an article about how to use the utility to sign a boot.img using the .pem and .pk8 files.
Click to expand...
Click to collapse
You must be thinking about kernel flashing zips? SignApk.jar uses .pk8 and .x509.pem to sign flashable zips and APKs. That's what vendors use for OTA zips.
Google's stock recoveries are always locked to their corporate keys, but often other OEMs' stock recoveries will accept the standard testkeys, which is why Chainfire signs SuperSU's zip with them.

osm0sis said:
You must be thinking about kernel flashing zips? SignApk.jar uses .pk8 and .x509.pem to sign flashable zips and APKs. That's what vendors use for OTA zips.
Google's stock recoveries are always locked to their corporate keys, but often other OEMs' stock recoveries will accept the standard testkeys, which is why Chainfire signs SuperSU's zip with them.
Click to expand...
Click to collapse
A boot.img is the Kernel right? Isn't that why when you unpack the boot.img you get the kernel ram disk and the initial kernel addresses.
So I would say you are correct, that I am talking about signing a kernel zip in a way.
In chainfire's thread about Android Verified Boot, he talks about what I'm talking about I believe.
Our S7 Edge has a keystore.mbn file which Is new to me as is the Snapdragon. But it's also said that the recovery.img houses the otacerts the device/dm-verity uses to authenticate.
In the case of locked bootloader devices, they don't use standard Google keys, but they use their own private carrier keys. As well as Samsung Factory Keys, which is why Combination Firmware files can be flashed on a locked BL no problem.
But unless they've come up with an entirely closed source addition to Android, I would venture to say Samsung spent some time customizing AVB/SecureBoot & bootimg.h the same way they did to The ART runtime to change the signature structure. More so than trying to reinvent the wheel that stock aosp provides.
I know I say that like it's simpler than it really is. But I still feel like there is a way. What seems impossible now, I don't forsee being as big of a problem in the nearish future.

Please supply a boot.img and I'll tell you if it's AVB or something else. A number of vendors have their own closed signing methods, unfortunately.
Edit: I found the engineering kernels you mentioned from @jrkruse's thread. Definitely not AVB. Definitely something proprietary. Kind of like the Samsung/Marvell pxa1088 board signatures described here (specifically the Xcover 3), except those weren't being enforced.
I'm at work right now. I'll give them a closer look when I'm home, but if just re-appending the signature doesn't work then you're likely out of luck.

osm0sis said:
Please supply a boot.img and I'll tell you if it's AVB or something else. A number of vendors have their own closed signing methods, unfortunately.
Edit: I found the engineering kernels you mentioned from @jrkruse's thread. Definitely not AVB. Definitely something proprietary. Kind of like the Samsung/Marvell pxa1088 board signatures described here (specifically the Xcover 3), except those weren't being enforced.
I'm at work right now. I'll give them a closer look when I'm home, but if just re-appending the signature doesn't work then you're likely out of luck.
Click to expand...
Click to collapse
Cool beans! I looked over that first post, and it may actually help me do what I was thinking. The header format they list for those devices looks pretty similar to how the PIT file repartitions the Emmc with ODIN. So with tools like gdisk and the like, I feel it shouldn't be too hard to put 2 and 2 together.
Gotta read that thread some more first. Seems like I was headed in the right direction though.
Maybe I can also find some more information in the Z3X support forums for the Connie Board and safety net stuff to help with the boot image headers.

Delgoth said:
Cool beans! I looked over that first post, and it may actually help me do what I was thinking. The header format they list for those devices looks pretty similar to how the PIT file repartitions the Emmc with ODIN. So with tools like gdisk and the like, I feel it shouldn't be too hard to put 2 and 2 together.
Gotta read that thread some more first. Seems like I was headed in the right direction though.
Maybe I can also find some more information in the Z3X support forums for the Connie Board and safety net stuff to help with the boot image headers.
Click to expand...
Click to collapse
That signature on those engineering images is SEANDROIDENFORCE + 256 bytes just like the Xcover 3. Difference is the header is normal AOSP instead of Marvell/Samsung's crazy version. I'm guessing that reappending the signature doesn't make it valid, but that should be your first test before going any further.
My Android Image Kitchen will do everything but add the signature back on. Do a repack with no changes and add the signature back on with a hex editor to see if it'll boot.

osm0sis said:
That signature on those engineering images is SEANDROIDENFORCE + 256 bytes just like the Xcover 3. Difference is the header is normal AOSP instead of Marvell/Samsung's crazy version. I'm guessing that reappending the signature doesn't make it valid, but that should be your first test before going any further.
My Android Image Kitchen will do everything but add the signature back on. Do a repack with no changes and add the signature back on with a hex editor to see if it'll boot.
Click to expand...
Click to collapse
Thank you for this. I've been moving my house this week, and I'm getting my internet back today. Woop woop. I've been wanting to dive into the topic of signatures for like a month now at least.
I'll see what I can dig up.

As some of you may know, jrkruse has a rom out for the phone, that allows the system to be modified to an extent without tripping knox and such. Can we possibly install the Crom Service apk as a system app, and unlock the bootloader that way? Won't it have all necessary permissions to unlock it?

CyanideHD said:
As some of you may know, jrkruse has a rom out for the phone, that allows the system to be modified to an extent without tripping knox and such. Can we possibly install the Crom Service apk as a system app, and unlock the bootloader that way? Won't it have all necessary permissions to unlock it?
Click to expand...
Click to collapse
I forget where I read on XDA, that the Crom Service APK talks to servers in China in order to send and receive the unlock instructions.
ConsIdering the APP is a first party Samsung Application, I wonder how exactly it goes about turning off the signature verification. Unless the Crom APK actually downloads an unlocked bootloader and flashes it directly to the device itself.
The signatures are stored in the footer of the images. At least in the System Image anyways. Because the fstab file specifically says to mount the system partition with an encryptable footer. That is how ODIN checks if what you are flashing matches the device binary revision.
Using a rooted device on newer builds, or the greyhat root console on older builds, we can pull the stock recovery and find the keystore. Which houses all the signatures the device will accept.
But yes, technically if you can get the APK to load without a Force Close, it should have the needed permissions. It was built using the Knox/Galaxy SDK's.

Related

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

Potential way to unlock bootloader?

Since we are using engboot, write protection seems to be off, so it appears you can use dd to write to normally write protected partitions such as the bootloaders (ex: "dd if=/sdcard/aboot of=/dev/block/sdd10"). In my testing I was successfully "dd" a backed up aboot (secondary bootloader) partition and also write to the modem partition and have it stick (which means write protection should be off akaik). If you were to "dd" the Chinese bootloaders, you might be able to flash and re-partition onto the Chinese firmware and then use the CROM service to unlock the bootloader from there. I personally don't know too much about this type of stuff and haven't tried to actually "dd" the Chinese bootloader, but for those more knowledgeable, could this potentially work?
Partitions likely needed are:
- rpm (Resource and Power Manager / Primary Bootloader) located at /dev/block/sdd1 (/dev/block/bootdevice/by-name/rpm)
- aboot (AP Bootloader / Secondary Bootloader) located at /dev/block/sdd10 (/dev/block/bootdevice/by-name/aboot)
- xbl (Extended Bootloader) located at /dev/block/sdb1 (/dev/block/bootdevice/by-name/xbl)
- ? located at /dev/block/sdc1
Modifying the bootloader is dangerous and could permanently brick your device. I take no responsibility if you try this and it breaks your device.
Edit 5: Additional Details
qwewqa said:
Since we are using engboot, write protection seems to be off, so it appears you can use dd to write to normally protected partitions (ex: "dd if=/sdcard/aboot of=/dev/block/sdd10"). In my testing I was successfully dd a backed up aboot (secondary bootloader) partition and also write zeros to the modem partition and have it stick (which means write protection should be off). If you were to dd a Chinese bl/ap, you might be able to flash/re-partition onto the Chinese firmware and then use the CROM service to unlock the bootloader from there. I personally don't know too much about and haven't tried to actually dd the Chinese bootloader, but for those more knowledgeable, would this work?
Edit: Modem partition sticks after reboot.
Click to expand...
Click to collapse
@Binary100100 you probably know somebody that knows little bit more about this, tell them to check it out
Magnifik81 said:
@Binary100100 you probably know somebody that knows little bit more about this, tell them to check it out
Click to expand...
Click to collapse
Nope. Don't know anyone specific.
Wish I had the $175 for my insurance deductible, I'd give it a try. All in all, it should work. The hardware is the same.
thescorpion420 said:
Wish I had the $175 for my insurance deductible, I'd give it a try. All in all, it should work. The hardware is the same.
Click to expand...
Click to collapse
Well, if it WORKS, I'm sure the bounty on unlocking the bootloader is a lot higher than $175! ?
DOMF said:
Well, if it WORKS, I'm sure the bounty on unlocking the bootloader is a lot higher than $175!
Click to expand...
Click to collapse
Lets start a thread . . . I am willing to contribute $25.00 :good: into a pool with others here at XDA to the developer who can produce an unlocked bootloader that is rooted with a decent rom that works great and better than stock, something that will fix all of the untold bugs and address the known issues.
Anyone else?
serendipityguy said:
Lets start a thread . . . I am willing to contribute $25.00 :good: into a pool with others here at XDA to the developer who can produce an unlocked bootloader that is rooted with a decent rom that works great and better than stock, something that will fix all of the untold bugs and address the known issues.
Anyone else?
Click to expand...
Click to collapse
$25? Hell think about how much we spend on the phone itself and bill every month.. I'd easily pledge $100 for an unlocked bootloader with twrp support.
That's the 1 thing I don't understand.. this is the most highly sought after phone right now with 0 developer support. I understand the limitations with the locked bootloader but other phones have overcome the same through the works of various motivated individuals. There is no one even interested in trying it seems on ANY carrier forum. Instead we have countless threads with people more interested in getting the nougat update early which will hardly provide anything useful compared to an unlocked bootloader with working root.
serendipityguy said:
Lets start a thread . . . I am willing to contribute $25.00 :good: into a pool with others here at XDA to the developer who can produce an unlocked bootloader that is rooted with a decent rom that works great and better than stock, something that will fix all of the untold bugs and address the known issues.
Anyone else?
Click to expand...
Click to collapse
"Start?" It was started ages ago and it thousands of dollars. https://forum.xda-developers.com/tmobile-s7-edge/how-to/bounty-unlocked-bootloader-s7edge-t3339857
bdvince said:
$25? Hell think about how much we spend on the phone itself and bill every month.. I'd easily pledge $100 for an unlocked bootloader with twrp support.
That's the 1 thing I don't understand.. this is the most highly sought after phone right now with 0 developer support. I understand the limitations with the locked bootloader but other phones have overcome the same through the works of various motivated individuals. There is no one even interested in trying it seems on ANY carrier forum. Instead we have countless threads with people more interested in getting the nougat update early which will hardly provide anything useful compared to an unlocked bootloader with working root.
Click to expand...
Click to collapse
Root right now is just too impractical for most people. I'm still rooted, but for most people it isn't worth the hassle and trade-offs, for many it's worse than stock. I think most people who are really into root probably switched devices. Switching to android N could actually prevent bootloader unlock in this way, unless root for N comes out. That is if this unlock method could actually work, hard to say without anyone experienced in bootloaders and write protection though.
I'd like to find someone with a sm-g9350 to DD a dump of sdd10.
thescorpion420 said:
I'd like to find someone with a sm-g9350 to DD a dump of sdd10.
Click to expand...
Click to collapse
Sdd1 is the primary bootloader, probably also necessary.
Came to the realization that the Chinese bootloader is v2 where all US models are v4. I'd imagine the Chinese nougat update will make it v4, so we wait to try.
Don't want to a be downer or anything but I'm pretty sure you can't just replace the bootloader, even if write protection is off on the Eng kernel. Even if you did replace it you'll have probably bricked your phone.
Sent from my SM-G935T using Tapatalk
dogredwing1 said:
Don't want to a be downer or anything but I'm pretty sure you can't just replace the bootloader, even if write protection is off on the Eng kernel. Even if you did replace it you'll have probably bricked your phone.
Click to expand...
Click to collapse
The thinking is that since the devices are virtually the same hardware wise, there is a chance the bootloader could be replaced. I do agree that there is a good chance of hard bricking though. I haven't done any testing other than apparently successfully dding a backed up version of the same bootloader.
If I wasn't on nougat I would try it if someone posted instructions and devs confirmed the directions are correct..
Sent from my SM-G935T using Tapatalk
I was actually playing with the bootloader, and found this thread when I went to post. I'm going to be pulling fastboot commands also to see if I can find anything interesting. I'm tired of not being able to use a custom kernel
My device is on nougat. Bit I can easily downgrade and test if someone has a rock solid idea. I don't mind bricking as the device has a cracked screen and I have my s6 edge plus to use until the s8 drops...
Sent from my SM-G935T using Tapatalk
Count me in as well!
I have a theory that we can open the BL file in WinRAR and extract the rpm.mbn file from G9350 odin file,
and flash to our device. But I cannot determine which one is for aboot. I have not tested this yet.
aaron007 said:
Count me in as well!
I have a theory that we can open the BL file in WinRAR and extract the rpm.mbn file from G9350 odin file,
and flash to our device. But I cannot determine which one is for aboot. I have not tested this yet.
Click to expand...
Click to collapse
What I know is:
RPM = Resource and Power Manager = Primary Bootloader
ABoot = AP Bootloader = Secondary Bootloader
I believe the boot process is "RPM > ABoot > boot.img (Main OS)", so both the rpm and aboot file would be needed. Also I think the partition layout in the Chinese version is slightly different, so a flash and repartition would be needed after replacing bootloader to actually root. I don't know what the chances success are though, the devices are virtually the same hardware wise, and the Chinese rom with the U.S. bootloader works according to the Verizon fourm, but there is a chance there are other differences what might prevent this from working.
Flippy125 said:
I was actually playing with the bootloader, and found this thread when I went to post. I'm going to be pulling fastboot commands also to see if I can find anything interesting. I'm tired of not being able to use a custom kernel
Click to expand...
Click to collapse
Isn't fastboot disabled on the s7. Also, were your results the same?
qwewqa said:
What I know is:
Isn't fastboot disabled on the s7. Also, were your results the same?
Click to expand...
Click to collapse
Yes, found that out when I started playing with it more. I'm currently reading sdd10 line by line. I did find an entry "Device is unlocked! Skipping verification...". I'm starting to think we need to look into recovery-side exploits. I'm too scared to try and mess with the bootloader too much.
EDIT: If we can find a way to get fastboot working, possibly piggybacking off of Odin, I found a command written in the aboot code 'fastboot oem unlock-go'
EDIT2: Using that command requires some sort of key. May be a dead end.
EDIT3: I'd be willing to test modifying the recovery image to see if it triggers the bootloader's hash checking. If anything, this could lead to writing a custom boot image that would open TWRP.

How do I root an SM-T377V?

As far as I'm aware, this device (Verizon variant of the T377) has a locked bootloader meaning that getting custom recovery is out of the question. Does anybody know of any way to root this tablet, or of any way to unlock the bootloader?
I need to be schooled.
I know this is the Verizon model and that complicates thi b a but I rooted my Verizon s7 with Odin (prince comsy), and with that I struggled with the same thing I struggled with here. Finding an image for my specific build number. With the s7 I eventually found an IMG that seemed to be one size fits all G930X boot.tar. I tried with other builds from cf auto root before I had found this image with no success. I found images specific to sprint T-Mobile at&t G930T, G930P, etc. No G930v for Verizon. But this G930X worked perfect, well, a few bugs, but worked really well. How could an IMG be modded to be a one size fits all type thing for this tablet? I realize the Tut's for this tablet involve flashing a recovery.img rather than a boot.img but the process can't be much different or more difficult could it be for modding the T377P (sprint) .img to fit the T377V (Verizon) model ? Or am I comparing apples and oranges here? Could a dev give me a quick 101 on this ? Any help would be really awesome.
wastedf4ther said:
I know this is the Verizon model and that complicates thi b a but I rooted my Verizon s7 with Odin (prince comsy), and with that I struggled with the same thing I struggled with here. Finding an image for my specific build number. With the s7 I eventually found an IMG that seemed to be one size fits all G930X boot.tar. I tried with other builds from cf auto root before I had found this image with no success. I found images specific to sprint T-Mobile at&t G930T, G930P, etc. No G930v for Verizon. But this G930X worked perfect, well, a few bugs, but worked really well. How could an IMG be modded to be a one size fits all type thing for this tablet? I realize the Tut's for this tablet involve flashing a recovery.img rather than a boot.img but the process can't be much different or more difficult could it be for modding the T377P (sprint) .img to fit the T377V (Verizon) model ? Or am I comparing apples and oranges here? Could a dev give me a quick 101 on this ? Any help would be really awesome.
Click to expand...
Click to collapse
I am as well very confused. I have no idea where to even start with rooting this tablet.
In the year 2020.
tomiga said:
I am as well very confused. I have no idea where to even start with rooting this tablet.
Click to expand...
Click to collapse
It amazes me how long some devices go without any development. Let's pick this back up.
COMING SOON. Information on any development for this device.
Casper Young said:
It amazes me how long some devices go without any development. Let's pick this back up.
COMING SOON. Information on any development for this device.
Click to expand...
Click to collapse
There's no development because nobody cares enough to try to crack open or otherwise work around the locked bootloader for this device. I got rid of mine years ago for a Tab S4.
Well ****! As I give Samsung the middle fingure and want to run over it with a steam-roller, smash it with a sledge-hammer and shoot it with a 12 guage, then send it to them in itty bitty pieces. My bad! I didn't even look to see if it had OEM Unlock..Drat!
So in response to Casper's post, my T-377V is showing OEM unlock and it activates. I am not sure what that means only is it just false hope? To be honest, this tablet was rescued from the recycling pile and duly erased.
I don't mind taking chances with it b/c I have nothing invested in it. I really haven't gone anywhere with this tablet b/c I have read so many conflicting opinions.
Anybody have any suggestions, I would be oh so grateful.
Its a fake unlocked with false hopes, I own 3 verzions and even tho its says unlocked it really is not. The only thing you can do is flash oem 5.1.1 and temporary root with king root that's about all you can do just enough to side load commands to uninstall blotware and clean it up a little bit.
what about flashing combination file would that make any difference with the bootloader unlocking
pokeperil420 said:
what about flashing combination file would that make any difference with the bootloader unlocking
Click to expand...
Click to collapse
As far as I know that answer would be a no. Combination files are for repairing firmware (in a sense) and not changing OEM status. I wish it were easy to change carriers because T-Mobile devices usually allows me to unlock the OEM. I have since moved on from this device and currently use my S10 Plus or the Samsung Note 10. Good luck.
Casper Young said:
As far as I know that answer would be a no. Combination files are for repairing firmware (in a sense) and not changing OEM status. I wish it were easy to change carriers because T-Mobile devices usually allows me to unlock the OEM. I have since moved on from this device and currently use my S10 Plus or the Samsung Note 10. Good luck.
Click to expand...
Click to collapse
Enable ADB and OEM Unlocking
To execute any tweaks on your device, you will first have to unlock the device’s bootloader. All Samsung devices shipped with a locked bootloader. So in order to perform the unlock process, you will have to enable the OEM Unlock Toggle. Along the same lines, near about every major modifications, calls for the execution of the ADB commands.
But for that, your device needs to be recognized by your PC in the first place in the ADB Mode. In which case, you will have to enable the USB Debugging toggle. The thing with both these options is that they are baked deep into the Developer Options which itself is hidden. So enabling both these toggles calls for a lot of effort. Well, not anymore. Using the Samsung Combination ROM, you could easily do so without any issues as such.
reference source
pokeperil420 said:
Enable ADB and OEM Unlocking
To execute any tweaks on your device, you will first have to unlock the device’s bootloader. All Samsung devices shipped with a locked bootloader. So in order to perform the unlock process, you will have to enable the OEM Unlock Toggle. Along the same lines, near about every major modifications, calls for the execution of the ADB commands.
But for that, your device needs to be recognized by your PC in the first place in the ADB Mode. In which case, you will have to enable the USB Debugging toggle. The thing with both these options is that they are baked deep into the Developer Options which itself is hidden. So enabling both these toggles calls for a lot of effort. Well, not anymore. Using the Samsung Combination ROM, you could easily do so without any issues as such.
reference source
Click to expand...
Click to collapse
It can be done but why would you. It's a glorified kindle lol.

BL1 - Rooted - Update system / Not loose root?

This may have been addressed, but I haven't been in this game in a few.
I have G950U1UEU1AQE3 on VZW. Currently I am rooted with SafeStrap and TWRP. I have been looking at updating to ANY latest firmware, but fear losing root. I figured that I could update to at least G950U1UEU1AQH3 since it is still BL1, but wanted to try Oreo (8.0). Assuming going to Oreo will cause me to lose every ability to return to an older release, will I still be able to keep root? I know this may be basic, but I need a refresher. Thanks!
nitro66215 said:
This may have been addressed, but I haven't been in this game in a few.
I have G950U1UEU1AQE3 on VZW. Currently I am rooted with SafeStrap and TWRP. I have been looking at updating to ANY latest firmware, but fear losing root. I figured that I could update to at least G950U1UEU1AQH3 since it is still BL1, but wanted to try Oreo (8.0). Assuming going to Oreo will cause me to lose every ability to return to an older release, will I still be able to keep root? I know this may be basic, but I need a refresher. Thanks!
Click to expand...
Click to collapse
I have a stock rom setup to flash in safe strap somewhere in dev section its the latest rootable firmware
https://forum.xda-developers.com/galaxy-s8/how-to/950u-stock-rom-blq1-optional-root-t3812012
HoosierDaddy said:
I have a stock rom setup to flash in safe strap somewhere in dev section its the latest rootable firmware
https://forum.xda-developers.com/galaxy-s8/how-to/950u-stock-rom-blq1-optional-root-t3812012
Click to expand...
Click to collapse
Thanks. After playing around with different things, what I found that worked for me was loading PartCyborgRom getting me to BL2 and then loading the UserData file from the G950USQS2BQL1 VZW rom. I will be monitoring the phone for LTE errors that I used to get and may re-load CP / CSC if that's the case. So far, I'm back with SafeStrap/TWRP and root. Once 8.0 has a good confirmed root, then I might work on going to that.
Does anyone know if there is a configuration setting to remove the diagnostic type information from the boot screen? All that text in the upper corner is more of a nuisance to me than what it's worth.
nitro66215 said:
Thanks. After playing around with different things, what I found that worked for me was loading PartCyborgRom getting me to BL2 and then loading the UserData file from the G950USQS2BQL1 VZW rom. I will be monitoring the phone for LTE errors that I used to get and may re-load CP / CSC if that's the case. So far, I'm back with SafeStrap/TWRP and root. Once 8.0 has a good confirmed root, then I might work on going to that.
Does anyone know if there is a configuration setting to remove the diagnostic type information from the boot screen? All that text in the upper corner is more of a nuisance to me than what it's worth.
Click to expand...
Click to collapse
Oreo probably will never be rooted I have a another s8 on revision 3 bootloader I have been picking the brains of the guys who did root for this device....
I tried several different methods all in fail
I have a small telegram group for advanced users,But telegram links are not allowed
most of the discussions are on there.... We tried a modified samfail on the FA70 Factory combo but no go
I got a working combo boot img I made
No combo system behind it
The only issue now is the previous roots all have native 7.0 systems to push su and junk to...On bootloader 3 We still need the combo boot img,Which unfort is a 7.0 combo,Which means all the rest of the Bit 3 systems out are oreo which wont obviously boot on 7.0 kernel
---------- Post added at 08:25 AM ---------- Previous post was at 08:12 AM ----------
nitro66215 said:
Thanks. After playing around with different things, what I found that worked for me was loading PartCyborgRom getting me to BL2 and then loading the UserData file from the G950USQS2BQL1 VZW rom. I will be monitoring the phone for LTE errors that I used to get and may re-load CP / CSC if that's the case. So far, I'm back with SafeStrap/TWRP and root. Once 8.0 has a good confirmed root, then I might work on going to that.
Does anyone know if there is a configuration setting to remove the diagnostic type information from the boot screen? All that text in the upper corner is more of a nuisance to me than what it's worth.
Click to expand...
Click to collapse
Also the info in the top of boot is part of the kernel thats used to gain root That cannot be gotten rid of,But there is a adb code you can run if you ever get the scrolling lines of debug code on boot animation similar to the app liveboot
HoosierDaddy said:
Also the info in the top of boot is part of the kernel thats used to gain root That cannot be gotten rid of,But there is a adb code you can run if you ever get the scrolling lines of debug code on boot animation similar to the app liveboot
Click to expand...
Click to collapse
Right on. Thanks!

Root SM-J337A Samsung Galaxy Express Prime 3 (2018) Via Magisk Method

EDIT 3: It appears this device has a locked bootloader, which means that twrp wont work, and that device tree was a waste of time... I guess I'll just wait until someone or Samsung releases the firmware for Magisk.
EDIT 2: I have successfully built a device tree for this device using TWRPBuilder's script on github. Although it might not be fully complete, it is still a start. Note: I built using an android 8 release. Does the boardconfig.mk file still work for android 9????
I plan on comparing it with a different device tree to make sure nothing is blatantly wrong with it, but I'm not a developer so I don't know if that will help.
(Anyone willing to help me? If I could efficiently navigate the linux CLI I would probably be much faster...)
My current plan is to build TWRP for this device to back up the ROM so that I can use Magisk.
https://github.com/TwrpBuilder/twrpbuilder_tree_generator/blob/master/README.md
Link to device tree builder for those interested. Dont even ask how long it took me to realize I had to add the commands to the end of the java executive instead of typing TWRPBuilder -r recovery.img. command.
-------
EDIT: To those that read, Samsung has restrictions against downgrading apparently. Currently, the only way for root is by waiting for someone to share the official stock ROM. The first half of this method about getting the firmware Does Not Work I don't know about the rest...
-----
Hello everyone,
I would first like to say that I think this is a working method, but I want to double check with someone who has rooted before.
I have the above mentioned phone, and after a ton of research, have determined a path to rooting it through Magisk. I'm currently running Android Pie 9, on the latest stock firmware from att.
This phone does not have A/B partitioning, but has system-as-root and it will require a copy (and Magisk patched) ROM to root.
One of the main problems I have is not having the latest firmware for my device. (Don't tell me to look it up. Its non-existent on the web) I have found that Samsung's Smart Switch will allow you to obtain the official ROM.
However, to download the ROM, I have to have an outdated phone. The most recent update for my phone was to upgrade from Android 8.0 to 9.0.
I assume such an upgrade requires the whole ROM to be downloaded.
Is it possible to use an outdated ROM for my phone (Yes, I have one for android 8) and downgrade my OS so that I can then update from Smart Switch and get a copy of the current firmware to use with Magisk?
Edit: apparently Samsung has protections against downgrading. I tried samfirm but to no avail.
Anyone know of any compatible custom ROMs?
Will keep trying to root though...
I know many people will immediately say yes, but this phone is different.
There is no OEM unlock in Developer options (read more about this further!), and there is no fastboot. There is no TWRP for this phone either (some older threads on Magisk mentioned TWRP, so I am confused if I need it for rooting via Magisk)
I have discovered, that if you were to hold HOME + POWER + UP, on powerup, you can get to a warning about installing custom OSes and an option to continue.
I pressed continue.
Someone on the web said pressing up will wipe the phone, since it unlocks the bootloader.
My phone did not get wiped.
Is my phone's bootloader/OEM unlocked?
I want to know because I Think Magisk requires an unlocked bootloader.
If Magisk doesn't, I'm all good, and I am glad I can install custom OSes (not my goal, but will do if desperate)
If it does require it, I believe my hone already has an unlocked bootloader/OEM
One last note, does downgrading trip anything? I have no warranty, but I know there are other protections (like KNOX) that could affect the outcome.
(I've heard downgrading won't change anything)
Is there anything I need to turn off?
To Recap:
Downgrade OS
Update via Smart Switch to get stock ROM
Use Magisk to root my phone.
I'm simply asking if everything will turn out OK.
(Sorry for the exceedingly long post)
Thanks.
I don't have this phone but I wanted to have one, but after I realized there is no method to unlock it, you are out of luck I also have a phone laying around (Zte Avid Plus with android lolipop), I built a ROM and recovery for it but I realized there is no method to unlock the bootloader. The only method is to get your hands on the bootloader from this device and try and modify it and pray that it works. That is just how a lot budget devices are built nowadays. And that's sad. The thing is that there was a successor to the Zte Avid with the same specs but it ran Android Oreo. Meanwhile the Avid ran Lolipop. A method from manufacturers to always force us to buy new phones.

Categories

Resources