I have been coming here for years really, enough o spot major changes, like the bootloader variant's available lately, so I thought it a good idea to create a one charity thread full of bootloaders, because I figured out that the variant's of bootloaders have increased. Just look at all those custom roms... each modded rom seems to come in 4 flavour now.
a, a/b
32mb or 64..?
user, user-debug, or eng.
then there's the type of whatever chips etc, but most importantly...
People are forgetting a simple fact. A 'user' built bootloader, ie, stock, after-sale is blocked to root.
Magisk says patch the bootloader, yup, but they also want internet, so flashing latest magisk to a bootloader wont work if your not online, cause it wants to update BEFORE you get to play.. su CANNOT be used until you update the app, even if there are no updates, and while flashing magisk apk solves this, it is an un-neccessary step and a pain, because magisk is not the cure. It now takes over su... or busybox... Provable thus:
Flash Magisk'd boot, reboot, dulled out magisk shows in gui, wanting an update. Root checker says you are rooted (system-as-root, root shows even without magisk ) does not mean magisk rooted your bootloader, because if it had, you would be able to install su or busybox at shell... to get su. without recovery. I know. I've tested this fone for a year now... then I noticed I was using a user build... says it all....
With a latest magisk'd bootloader, booted up, we still cannot install su or busybox. So magisk does NOT root the bootloader, OR the fone. Until you login to them.
Even then, Magisk can patch, but not FLASH the fone=USER build.
Say I cant update offline to test why it wont flash the boot it just created. to make matters worse, now we gotta worry about the name of the patched boot getting longer and longer, magisk themselves making it harder to keep track... only to find flash failed. Respect Magisk
All because of the variant build.
We test recoveries... but magisk roots the bootloader.
Why patch a recovery for temp root wiped upon reboot when we can do the bootloader?
If we posted our magisk'd bootloaders instead of recoveries, you'd spot something factual.
A WORKING magisk'd bootloader, when opened in hex, will show variant=eng - if its PIE. Mine shows user.
A WORKING magisk'd recovery, when opened in hex, wait for it.. shows eng! wtf?
This is cause someone upped their test using their eng build, so it worked. For others.
Stock recovery does NOT show this. It shows user. PIE rooters see ENG in their RECOVERY. NOT USER!!!!!
Hence the note9 recovery, with ENG at the start, allowed me to patch my bootloader while in gui, and reflash it to bootloader OFFLINE, using what I just wrote wont work.
Because the PIE rooted bootloades are all ENG builds.
So if your magisk'd bootloader OR recovery shows 'USER' - forget it.
So, why not magisk patch your bootloader and post it here? Take it from your stock, magisk it, and post it.
Then we can all just grab a boot, and KNOW why the latest problems can disappear in a FLASH!
I'll post a link to my post's regarding how I found this simply stupid fact... Since my bootloaders there...
people assume root works on user builds...
It no longer does, and is now in fact, a barrier. One we never worried about before.. until now...
Ps: Last OS's only please, nothing from Pie please, just Android 10 onwards due to new partition schemes...
Thank you. I'll get you rooted. After I plant myself lol....
Armor x5 Android 10_Q Mt6765 aka Mt6762 ROOT AT LAST!
This 'tutorial' is a quicky for those yet to figure this fone out. Well it took a bit time for sure, but this is how it went... No matter what recovery or magisk I tried, nothing worked, all ulefone images with twrp were 64mb in size, where-as...
forum.xda-developers.com
The main mistake in your post is that you confuse bootloader ( read: uboot.bin ) with boot.img.
Next big mistake is to claim that a device's bootloader can get rooted: only the Android OS can get rooted.
Another mistake is to claim a bootloader is build-type dependent: the build-type only relates to Android OS, it controls whether ADB is featured or not.
And so on ...
No, I'm not confused. I do not want uboot.bin, although I understand your geek speak, there is NO uboot anywhere in my rom.
I want, like everyone else, a bootloader that clearly states its an eng variant of either a 32mb or 64 mb, preferable from stock, but since google twigged to what I'm saying, eng bootloaders are hard to find. Pie shows eng... but nothing since, have you twigged to that uboot?
When I want linux, I'll attempt lineage, but since twrp wont see the lineage zip we're all supposed to install, which in turn has an img inside, I'll say bang goes that idea, says it all when the devs think twrp will see their roms as a zip when it's an xz, not viewable in twrp, and well, I guess I just need to hang on until the boots arive when y'all twig to what google is doing...
Killing root period.
Uboot? Das uboot 57 is on the ocean floor....
Even google admit they're not releasing engineer or debug builds anymore... yes you can make them in the dev studio, and then post them online, but we've yet to accept what I'm saying.... in order to find the eng builds.
I want rid of google period, not install all their crap...
And how many people so far have realised what I'm saying, looked at their user bootloaders, and gave up knowing how pointless magisk actually is on a user bootloader?
Oh, and su actually needs to be in a bootloader to have true root, since directory traversal is geting worse.... aint no goin back....
Why do you think flashing a BOOTABLE recovery made from a BOOTLOADER works in recovery?
$ is turned into # when typing su.
Now if system is yet to load, explain how $ turns to # -Don't lol
Because it WAS a bootloader until it was rooted and loaded in RECOVERY, in order to boot or root!
I know what I'm saying and pursuing, and all others will fall into line soon....
jwoegerbauer said:
The main mistake in your post is that you confuse bootloader ( read: uboot.bin ) with boot.img.
Next big mistake is to claim that a device's bootloader can get rooted: only the Android OS can get rooted.
Another mistake is to claim a bootloader is build-type dependent: the build-type only relates to Android OS, it controls whether ADB is featured or not.
And so on ...
Click to expand...
Click to collapse
Uboot is in pie I believe. and every other linux I've seen, but android is NOT linux, but a remix... I even see uboot in the firesticks... but not my fone. Nor my stock firmware. your statement here could mean a/b partitioning is 2 uboots? pointless... uboot. Docsis 1. Docsis 2. Dual Chips. ab partitioning. Docsis 3. Same. Hello Fone. Is that a seperate linux os with another uboot controlling the lte side of your fone? or one uboot with 2 identical partitions.. My fone calls that a preloader. boot 1 would be boot.img, boot 2 would be boot-debug.img, if I was a/b partitioned. But I got a preloader with 2 identical boot.img, checking byte for byte unless I root. the boot.
It's not a mistake to know I know the origional command used in windows, to create a true unix root and password (at that time, supposedly impossible), windows commanding unix? windows control over an iphone with nothing more than the origional unix root user hack, which incidently, still works on every version of unix/linux/android...?
Android is NOT linux, but a remix, as much as linux is unix is eye... same commands, some on google, some in my head
And as for your last statement, I never made any mistake claiming any bootloader is dependant on build-type, but the bootloader's build-type decides wether we can flash, a magisk'd bootloader in gui, or rw system...
User is simply windows oem home edition. debug is android. engineer is unix.
I'm old school. Past it... Never frown on those that write like I do, we have so much to share...
But if my memory serves me well, uboot actually came from eCos, origionating in Docsis modems at the beginning of broadband., hence it is a DOS boot file, origionaly for modems. Just for the record, check tcniso, where they mention the vxShell as being 'very beauty'...
This explains the 64mb non-vol from the ambit 250, best security at that time, the non-vol was doubled to store a copy of the first half, in the second half where the first half was matched byte for byte before the modem came online, and why an ambit 250 non-vol could not work on an ambit 256, for the non-vol was exactly half the size, 32mb..
Same structure, day in day out... meanwhile, back in the jungle...
Pachacouti said:
Uboot is in pie I believe. and every other linux I've seen, but android is NOT linux, but a remix... I even see uboot in the firesticks... but not my fone. Nor my stock firmware. your statement here could mean a/b partitioning is 2 uboots? pointless... uboot. Docsis 1. Docsis 2. Dual Chips. ab partitioning. Docsis 3. Same. Hello Fone. Is that a seperate linux os with another uboot controlling the lte side of your fone? or one uboot with 2 identical partitions.. My fone calls that a preloader. boot 1 would be boot.img, boot 2 would be boot-debug.img, if I was a/b partitioned. But I got a preloader with 2 identical boot.img, checking byte for byte unless I root. the boot.
It's not a mistake to know I know the origional command used in windows, to create a true unix root and password (at that time, supposedly impossible), windows commanding unix? windows control over an iphone with nothing more than the origional unix root user hack, which incidently, still works on every version of unix/linux/android...?
Android is NOT linux, but a remix, as much as linux is unix is eye... same commands, some on google, some in my head
And as for your last statement, I never made any mistake claiming any bootloader is dependant on build-type, but the bootloader's build-type decides wether we can flash, a magisk'd bootloader in gui, or rw system...
User is simply windows oem home edition. debug is android. engineer is unix.
I'm old school. Past it... Never frown on those that write like I do, we have so much to share...
But if my memory serves me well, uboot actually came from eCos, origionating in Docsis modems at the beginning of broadband., hence it is a DOS boot file, origionaly for modems. Just for the record, check tcniso, where they mention the vxShell as being 'very beauty'...
This explains the 64mb non-vol from the ambit 250, best security at that time, the non-vol was doubled to store a copy of the first half, in the second half where the first half was matched byte for byte before the modem came online, and why an ambit 250 non-vol could not work on an ambit 256, for the non-vol was exactly half the size, 32mb..
Same structure, day in day out... meanwhile, back in the jungle...
Click to expand...
Click to collapse
Ok, so no-one see's the need for bootloaders yet lol... so in the meantime, I had another idea.
Why not just remove magisk from an eng build bootloader, and then flash it, then re-apply magisk, if only to find out that this is how google prevent us writing to system...
And to whom-ever it was that stated magisk can convert an unpatched bootloader of the user variant into an eng (engineer) variant bootloader, your simply wrong, no offence, I been through enough of them to know...
I wouldn't be looking for one since android 10 if it was ahem, the old way...
Related
Don't forget to hit the thanks button.
http://superstarmobility.weebly.com/
New thread: http://forum.xda-developers.com/android/development/twrp-m1-lg-k7-t3462130.
(Above TWRP can be flashed with Flashify from Playstore)
Instructions from video:
With phone powered off, hold POWER and VOLUME DOWN buttons until LG logo shows. Release POWER then quickly press and hold again until factory reset menu comes up. Select YES and you will be booted into recovery instead of a factory reset ; )
Thanks @czarsuperstar!
V2 with the proper cmd line from m1 aka LG K7
Reserved.
This the real deal?
goitalone said:
This the real deal?
Click to expand...
Click to collapse
Of course. You looked at the video?
goitalone said:
This the real deal?
Click to expand...
Click to collapse
I've used it and can confirm, first tested it with fastboot without flashing of course(use adb to get to the bootloader: adb reboot bootloader , then fastboot:fastboot boot "twrp.img file, tested then rebooted into bootloader, then flashed via fastboot:fastboot flash "twrp.img file") instructions are for any random person that come by i know you know how to do all this
concerned xda citizen
what are the boardconfig.mk file contents that you used to compile this recovery?
the fact youre using a ghetto hacked twrp that works is fine, but id prefer an actual device specific twrp version that will reliably work - theres no telling what this twrp can do to your device, and the fact youre using another devices ramdisk scares the hell out of me.
ramdisks arent something you play around with - you can seriously ruin someones device like that.
also requesting the twrp fstab file youve used.
youre literally just throwing files at users that have perviously bricked their devices and not explaining in detail what they consist of.
if you seriously damage any of these user's device partitions by overwriting the wrong partition, are you going to pay for the devices when theyre hardbricked and no longer responsive to the oem flashing?
not once have a even seen a warning on these files yet youre just posting forum to forum; not to mention youre inexperienced at rom/kernel/recovery compiling for the fact you think its okay to just throw a different devices ramdisk in there " because it just works." when we have readily available source for our device.
legally- youre held responsible for these files youre distributing.
and to those just flashing this twrp file to their device, yes its reversible - but would you want to find out it doesnt work when its too late? IE backing up partitions in the wrong order, and restoring them into the wrong partitions? the video shows it backs up and restores, but is it doing so in the right order? in the right places. i may be ranting but id rather be careful/safe then sorry.
not one detail of this compile/build has been released, just a link that is claimed to work.
"left sock fits on right, doesnt feel right - but my feet aren't cold!" is how this feels to me.
i was sketched to even test this twrp version considering you need to tell the factory reset "yes, i want to wipe" twice, in order to boot to twrp.
idk about you but ive never seen any recovery warrant those options. normally twrp would just boot upon button combo - which is why im sharing this post. recoveries arent supposed to be functioning that way.
NASSTYROME said:
what are the boardconfig.mk file contents that you used to compile this recovery?
the fact youre using a ghetto hacked twrp that works is fine, but id prefer an actual device specific twrp version that will reliably work - theres no telling what this twrp can do to your device, and the fact youre using another devices ramdisk scares the hell out of me.
ramdisks arent something you play around with - you can seriously ruin someones device like that.
also requesting the twrp fstab file youve used.
youre literally just throwing files at users that have perviously bricked their devices and not explaining in detail what they consist of.
if you seriously damage any of these user's device partitions by overwriting the wrong partition, are you going to pay for the devices when theyre hardbricked and no longer responsive to the oem flashing?
not once have a even seen a warning on these files yet youre just posting forum to forum; not to mention youre inexperienced at rom/kernel/recovery compiling for the fact you think its okay to just throw a different devices ramdisk in there " because it just works." when we have readily available source for our device.
legally- youre held responsible for these files youre distributing.
and to those just flashing this twrp file to their device, yes its reversible - but would you want to find out it doesnt work when its too late? IE backing up partitions in the wrong order, and restoring them into the wrong partitions? the video shows it backs up and restores, but is it doing so in the right order? in the right places. i may be ranting but id rather be careful/safe then sorry.
not one detail of this compile/build has been released, just a link that is claimed to work.
"left sock fits on right, doesnt feel right - but my feet aren't cold!" is how this feels to me.
i was sketched to even test this twrp version considering you need to tell the factory reset "yes, i want to wipe" twice, in order to boot to twrp.
idk about you but ive never seen any recovery warrant those options. normally twrp would just boot upon button combo - which is why im sharing this post. recoveries arent supposed to be functioning that way.
Click to expand...
Click to collapse
The first twrp was from a htc phone. This is from lg leon lte. Same manufacturer. I used my boot.img dumped on my sdcard and used the ramdisk from Twrp Leon aka c50 the leon twrp is missing the options seen on this one. Don't use it. But I'm working on cm_m1 so continue to use the old one and when your phone can't come on have fun getting in recovery. Make it better.
Recovery log
Make a log.
NASSTYROME said:
what are the boardconfig.mk file contents that you used to compile this recovery?
the fact youre using a ghetto hacked twrp that works is fine, but id prefer an actual device specific twrp version that will reliably work - theres no telling what this twrp can do to your device, and the fact youre using another devices ramdisk scares the hell out of me.
ramdisks arent something you play around with - you can seriously ruin someones device like that.
also requesting the twrp fstab file youve used.
youre literally just throwing files at users that have perviously bricked their devices and not explaining in detail what they consist of.
if you seriously damage any of these user's device partitions by overwriting the wrong partition, are you going to pay for the devices when theyre hardbricked and no longer responsive to the oem flashing?
not once have a even seen a warning on these files yet youre just posting forum to forum; not to mention youre inexperienced at rom/kernel/recovery compiling for the fact you think its okay to just throw a different devices ramdisk in there " because it just works." when we have readily available source for our device.
legally- youre held responsible for these files youre distributing.
and to those just flashing this twrp file to their device, yes its reversible - but would you want to find out it doesnt work when its too late? IE backing up partitions in the wrong order, and restoring them into the wrong partitions? the video shows it backs up and restores, but is it doing so in the right order? in the right places. i may be ranting but id rather be careful/safe then sorry.
not one detail of this compile/build has been released, just a link that is claimed to work.
"left sock fits on right, doesnt feel right - but my feet aren't cold!" is how this feels to me.
i was sketched to even test this twrp version considering you need to tell the factory reset "yes, i want to wipe" twice, in order to boot to twrp.
idk about you but ive never seen any recovery warrant those options. normally twrp would just boot upon button combo - which is why im sharing this post. recoveries arent supposed to be functioning that way.
Click to expand...
Click to collapse
Check out the LG L70 it's the same way to get in recovery. This must be your first LG phone.
i dont care whether its the same way to enter recovery, my care is youre using another phone's ramdisk in this device.
"I used my boot.img dumped on my sdcard and used the ramdisk from Twrp Leon aka c50 the leon"
post twrp.fstab and boardconfig.mk youve used for this "twrp" build.
this must be your first posting for development on an unsupported device.
as for anyone using another device's files when we have access to source of our own device - i wouldnt trust them to build anything, let alone CM. thats just pure shortcutting and laziness .. and at what expense?
as for twrp making this official, they wont - as you cannot provide SOURCE.
So, now, hopefully you've compiled TWRP for your device and gotten it working. Now, you'd like to know how to get TWRP officially supported for your device so that it can be installed automatically with GooManager. In order for us to add "official support" for your device we'll need the following:
1) Device configuration files to compile TWRP from source for your device. This means that you cannot have repacked a recovery.img by hand to get it working. We need to be able to compile it from source so that we can easily release future updates.
2) A copy of a build prop for your device (it's in /system/build.prop) so that we can add the correct device information to GooManager
3) We'll build a copy of TWRP and send it to you for validation. Once you've validated that we can build a working image for your device, we'll add it to GooManager.
Go spam the other thread. Over 200 downloads and no problems but there was problems right away with the first version. For your info download Twrp c50 from the Twrp site examine it and ask why it's incomplete. That's why I linked the video of the Twrp from the site and same problems. Bye and leave me be. Hd2 check it out. Czarsuperstar's HTC HD2 android custom roms. Check it out and leave me alone. Thanks for your concern. Oh and for your info we have the same keyboard configuration as the LG Leon. There's a device tree. Google it. Google is your friend bro.
NASSTYROME said:
i dont care whether its the same way to enter recovery, my care is youre using another phone's ramdisk in this device.
"I used my boot.img dumped on my sdcard and used the ramdisk from Twrp Leon aka c50 the leon"
post twrp.fstab and boardconfig.mk youve used for this "twrp" build.
this must be your first posting for development on an unsupported device.
as for anyone using another device's files when we have access to source of our own device - i wouldnt trust them to build anything, let alone CM. thats just pure shortcutting and laziness .. and at what expense?
as for twrp making this official, they wont - as you cannot provide SOURCE.
So, now, hopefully you've compiled TWRP for your device and gotten it working. Now, you'd like to know how to get TWRP officially supported for your device so that it can be installed automatically with GooManager. In order for us to add "official support" for your device we'll need the following:
1) Device configuration files to compile TWRP from source for your device. This means that you cannot have repacked a recovery.img by hand to get it working. We need to be able to compile it from source so that we can easily release future updates.
2) A copy of a build prop for your device (it's in /system/build.prop) so that we can add the correct device information to GooManager
3) We'll build a copy of TWRP and send it to you for validation. Once you've validated that we can build a working image for your device, we'll add it to GooManager.
Click to expand...
Click to collapse
not saying a official twrp isn't preferable, but man you got to learn how to talk to people, you were just short of cursing the dude out, and as far as the recovery the thing is solid(tested backup, flash and restore/ anyhow we got LGUP if you **** up so its not a huge deal), but anyone on this site shouldn't take someones word for things like recovery's and you should always test boot before you flash, also you don't seem to understand the first rule of xda-whatever happens to your device is on you, been that way since the og day's- talking politely to others is the way to go about things, people wont listen if you combative.
Kernel
Im building the kernel from source right now check out the video on Twitter. Anyone that wants to join the development I am down with it.
Didn't work, after selecting yes twice, my phone just starts like normal, doesn't go to TWRP or factory restore, it is there though because I can boot to it from the flashify app, ah well.
wait...my bad, I was highlighting the wrong one, lol, works great, thanks
Assuming it ever worked right it should work better now because you can always get to it.
As for concerns about the ramdisk I don't see any issues with that, it's just being used to boot and run recovery on if I'm not mistaken and apparently where the buttons get enabled so a necessity.
Considering many phones have such hacked together recoverys and many more have no custom recovery I'm thankful to have it particularly since most of my work is done away from my pc.
callihn said:
Assuming it ever worked right it should work better now because you can always get to it.
As for concerns about the ramdisk I don't see any issues with that, it's just being used to boot and run recovery on if I'm not mistaken and apparently where the buttons get enabled so a necessity.
Considering many phones have such hacked together recoverys and many more have no custom recovery I'm thankful to have it particularly since most of my work is done away from my pc.
Click to expand...
Click to collapse
Thanks for report. The other Twrp w/o the button combo was from a HTC phone lol and I am getting blasted. HTC or LG? LG K7. ... LG.
[email protected] said:
Thanks for report. The other Twrp w/o the button combo was from a HTC phone lol and I am getting blasted. HTC or LG? LG K7. ... LG.
Click to expand...
Click to collapse
Right and that's why the buttons didn't work. Great job! Best discovery yet for this phone, so happy that we can restore now withoit adb and withoit having to worry about debugging getting turn off, very essential find. Don't let those that don't understand get you down.
callihn said:
Right and that's why the buttons didn't work. Great job! Best discovery yet for this phone, so happy that we can restore now withoit adb and withoit having to worry about debugging getting turn off, very essential find. Don't let those that don't understand get you down.
Click to expand...
Click to collapse
I'm working on building it from source but keep getting errors and I'm trying it with another device that has Twrp (Moto E 2015) and followed the directions to the T and no luck. So I am trying......... Will let everyone know how it's going.
[email protected] said:
Im building the kernel from source right now check out the video on Twitter. Anyone that wants to join the development I am down with it.
Click to expand...
Click to collapse
kernel??????????????????????????
im down!
I have an Alcatel Tetra running Android 8.1, June 2018 update, and I would like to root it. It was only released in September 2018, though, so there seems to be no common solution.
Some specs are:
480x854 resolution on 5" screen @ 70hz
1.1ghz MediaTek MT6739WM CPU
2gb ram
4G LTE GSM on AT&T
WIFI A/B/G/N 2.4ghz
Bluetooth 4.2 LE
Android 8.1, June 2018 update
16gb internal storage with support for 128gb sd card
GE8100 GPU
5MP front camera & 2MP back
USB 2.0 port, 3.5mm jack
Root
clcombs262 said:
I have an Alcatel Tetra running Android 8.1, June 2018 update, and I would like to root it. It was only released in September 2018, though, so there seems to be no common solution.
Some specs are:
480x854 resolution on 5" screen @ 70hz
1.1ghz MediaTek MT6739WM CPU
2gb ram
4G LTE GSM
WIFI A/B/G/N 2.4ghz
Android 8.1, June 2018 update
16gb internal storage with support for 128gb sd card
GE8100 GPU
5MP front camera & 2MP back
Click to expand...
Click to collapse
I have one also id like to root
I also have this phone. Almost cobbled together a twrp but just need the correct recovery-kernel & offset file to repack it. As it stands right now the twrp build will boot loop, but I know all the other pieces are solid ( correct resolution set, correct prop.default, fstab files, .rc files and so on) unfortunately so flash tools is useless until we can get a custom DA file that works with the Tetra. This whole process has been quite a pain lol but I'm close. If I can get it figured out I'll make a thread here upload all relevant files
Update: I'm currently using a few different RATs to pull any and all files possible while also trying to see what exploits (if any) I may be able to leverage with them. currently still lacking the recovery.fstab, but all other files needed for the ramdisk folder section of the recovery.img is set (put together the prop.default from scratch as I can't pull it from the phone). Still need all files outside of the ramdisk folder though (mostly just a proper recovery-kernel and offset, think I may be able to substitute the other files from a similar Alcatel MT6739 phone, the 3x/5058, which I have a stock firmware for). I also have the source code for the 4.4.95+ kernel that's on the Tetra, digging through it to see if I can use anything from it. If anyone has any thoughts about what could be done with all this stuff I have please feel free to share, as I could use some fresh eyes on this.
MICHAEL(SMHOS.ORG) said:
Just use magisk to root ,or ONE click root for PC is easy bro??
Click to expand...
Click to collapse
#1. There is no publicly available fw for this device as of this moment to patch with Magisk.
#2. Sp flash tool cannot currently readback or download to this phone, as the necessary DA file is unavailable. That means no way to get the boot.img or recovery.img to make magisk root/port TWRP
#3. NO ROOTING APPS WHETHER THEY BE APK OR PC BASED, WORK WHATSOEVER ON THIS PHONE, AND 80% OF THEM ARE BORDERLINE MALICIOUS (HERE'S LOOKING AT YOU KINGROOT)
#4 please kindly ****post elsewhere.
Root Alcatel Tetra
MICHAEL(SMHOS.ORG) said:
Just use magisk to root ,or ONE click root for PC is easy bro
Click to expand...
Click to collapse
I know for a fact One Click Root has no support, and Magisk is unreliable in my experience. I think I may have a way to apply a root patch, but obviously I need the patch first. I believe I can exploit the "apply update from sd card" function but haven't really tested it.
MICHAEL(SMHOS.ORG) said:
OK try it and check if any patch or so,because I use Flashing tools like Gsm alladin cracked or android adb multi tool since it support adb function for root
Click to expand...
Click to collapse
There is currently no adb exploit to gain root that works on this device. Trust me, I've tried. There is not an easy fix for this phone. The only options I see, is for someone who has access to the most recent NCK box, or Miracle thunder MT2 ( which added support for the mt6739 chip set) to dump the firmware and share It with the public, or for the Download Assistant file for this phone to be released, at which point SP flashtools can be used to dump the firmware, at which point a custom TWRP can be ported, root can be gained, and bob's your uncle. I've spent the last month going over every possible way to crack this phone open, and aside from finding/developing an as of yet unknown exploit, the only options available require a firmware dump (which currently can only be made with the 2 aforementioned box tools). I've been using every method I can think of to get a functioning TWRP without the stock recovery, with no luck yet. Ive taken every possible amount of info and files accessable from the phone using adb shells, mtk based tools, and RATs. I've got ahold of pretty much all publicly available firmwares and TWRPs for other Mt6739 phones that are already cracked, to see if I could take the files/Info and modify them to fill in the gaps and get a functional TWRP. Hasn't worked yet and while I've narrowed the reasons why down, those reasons seem to be hard blocks that could only be overcome through root access/access to the Tetras specific firmware. Which as you see is a catch 22 where you would need root to get root. I've even tried to get ahold of an ota update directly from AT&Ts cdn to try and exploit. I have the dl address but am not sure how to use it, as trying to connect to it from phone browser or PC just returns as forbidden. I'm honestly a little burnt out with it at the moment and am gonna go mess with some other phones I have and come back to this later when/if hopefully some new resources become available.
Tlr ; the easy and common solutions aren't gonna cut it, so save your breath
cthulu_rises said:
There is currently no adb exploit to gain root that works on this device. Trust me, I've tried. There is not an easy fix for this phone. The only options I see, is for someone who has access to the most recent NCK box, or Miracle thunder MT2 ( which added support for the mt6739 chip set) to dump the firmware and share It with the public, or for the Download Assistant file for this phone to be released, at which point SP flashtools can be used to dump the firmware, at which point a custom TWRP can be ported, root can be gained, and bob's your uncle. I've spent the last month going over every possible way to crack this phone open, and aside from finding/developing an as of yet unknown exploit, the only options available require a firmware dump (which currently can only be made with the 2 aforementioned box tools). I've been using every method I can think of to get a functioning TWRP without the stock recovery, with no luck yet. Ive taken every possible amount of info and files accessable from the phone using adb shells, mtk based tools, and RATs. I've got ahold of pretty much all publicly available firmwares and TWRPs for other Mt6739 phones that are already cracked, to see if I could take the files/Info and modify them to fill in the gaps and get a functional TWRP. Hasn't worked yet and while I've narrowed the reasons why down, those reasons seem to be hard blocks that could only be overcome through root access/access to the Tetras specific firmware. Which as you see is a catch 22 where you would need root to get root. I've even tried to get ahold of an ota update directly from AT&Ts cdn to try and exploit. I have the dl address but am not sure how to use it, as trying to connect to it from phone browser or PC just returns as forbidden. I'm honestly a little burnt out with it at the moment and am gonna go mess with some other phones I have and come back to this later when/if hopefully some new resources become available.
Tlr ; the easy and common solutions aren't gonna cut it, so save your breath
Click to expand...
Click to collapse
/
+1 on the no easy solutions. In theory, there is a utility built in to flash an update from an sd card from fastboot menu, or if you have an activity launcher.... exploitable, maybe?
Also, you must remember that those people are just people like you and me, with more experience. Since this phone was released September of this year, it may be awhile. So we may be on our own since the Tetra is a lower end device. I got a system dump, which I know can be used ro make firmware, but am not sure how to do so
clcombs262 said:
/
+1 on the no easy solutions. In theory, there is a utility built in to flash an update from an sd card from fastboot menu.
I got a system dump
Click to expand...
Click to collapse
Only way to use stock sideload would require you to sign the zip with the manufacturer private keys. I did pull some keys & certs from the phone but never got a chance to see if they were the proper ones.
And pls upload your system dump
Dont use this, see next post
Last post was the wrong file.
Here you'll find:
*DA file
*Auth file
*Preloader
*.mbn
*.sca
All specific for the 5041c, direct from Alcatel
https://drive.google.com/file/d/1FS0MFuoFSRlSncuUUtsZM808fqypUmue/view?usp=drivesdk
Yo OP what's up with that system dump?
cthulu_rises said:
Yo OP what's up with that system dump?
Click to expand...
Click to collapse
It ll be awhile. My ssd took a dump and died last night and I don't get paid for 2 weeks, so can't afford a new one.
That zip wasn't backed up unfortunately. So right now I have no pc
clcombs262 said:
It ll be awhile. My ssd took a dump and died last night and I don't get paid for 2 weeks, so can't afford a new one.
That zip wasn't backed up unfortunately. So right now I have no pc
Click to expand...
Click to collapse
Dang sorry to hear that brotha. Do you remember what method you used to get the system dump? I can try my hand at it
cthulu_rises said:
Dang sorry to hear that brotha. Do you remember what method you used to get the system dump? I can try my hand at it
Click to expand...
Click to collapse
See next post
cthulu_rises said:
Dang sorry to hear that brotha. Do you remember what method you used to get the system dump? I can try my hand at it
Click to expand...
Click to collapse
The primary code I used was
Code:
adb pull /system
adb pull /data
I may have used other code; I don't remember. It's been awhile.
Also, so my friends will stop asking, will you post how to root/flash recovery with what you provided? It'll be easier to link to the post then explain it 500 times, since I end up their IT guy a lot. Thanks in advance
Take the Da file, auth file, and scatter file provided and load them in the latest version of SP Flash Tool, use the readback function to dump the recovery img. If memory serves me correctly, mmcblk0p18 is the location for it. (use the scatter file to locate the begining address and the length for it). Once you have the stock recovery img, manually port twrp to it using carliv image kitchen. Then fastboot to flash twrp. If you did it right then you can boot into twrp and flash supersu or magisk for root. Make sure to boot directly into recovery after flashing, because the recovery gets replaced by stock after a normal boot
---------- Post added at 09:12 PM ---------- Previous post was at 09:11 PM ----------
I would have posted more already but have no access to PC for a while. I haven't even had a chance to do this for myself yet
cthulu_rises said:
Take the Da file, auth file, and scatter file provided and load them in the latest version of SP Flash Tool, use the readback function to dump the recovery img. If memory serves me correctly, mmcblk0p18 is the location for it. (use the scatter file to locate the begining address and the length for it). Once you have the stock recovery img, manually port twrp to it using carliv image kitchen. Then fastboot to flash twrp. If you did it right then you can boot into twrp and flash supersu or magisk for root. Make sure to boot directly into recovery after flashing, because the recovery gets replaced by stock after a normal boot
---------- Post added at 09:12 PM ---------- Previous post was at 09:11 PM ----------
I would have posted more already but have no access to PC for a while. I haven't even had a chance to do this for myself yet
Click to expand...
Click to collapse
I have access to a library pc, but youre not allowed to install anything. No adb or sp flash tool. Though i do have a theory about using stock recovery...
Probably wont work, but hey. YOLO. Still waiting for my ssd to be in stock
Well here's the stock ROM. Cut SP flash Tool and all its hassles out and use this. Just extract the recovery.img and port twrp, or extract boot.img and patch with magisk. Am gonna do this when I get home, I have a beater laptop I can use but no internet there, so I'll post my work the next time I can come to town and get cell service.
https://mega.nz/#!dpFmBIgI!4FXN0VYjTYSyMp608BCCDOtEVABHqOwoJPBx_OkaKrE
This zip contains the magisk patched boot.img, happy rooting!
Important notice! : iLLNiSS made me aware of a serious risk!
If you play with the firmwares manually and not with the flash all bat then DO NOT flash the blobs!
These are the actual bootloader files and stuffing up here will cause a hard brick!
I have to stress this out as it is serious thanks to not having working APX drivers a flshing programs for the Shield!
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
I have done some extensive tests since the first block based update wrecked my rooted Shield.
Some of it will end up in this post as info for everyone.
But lets start with what seems to be the problem for a lot of users right now who run a rooted Shield : Fixing the problem
A downgrade is officially not supported by Nvidia but my tests showed it works just fine if you only go back to the 7.1.
So far my tests showed differen sources for a Shield no longer working after the OTA.
1. The device had an unlocked bootloader and you got the 422mb block update.
This would have stuffed your bootloader and the Shield won't go past 1/4 on the progress bar for the update.
You are in luck as just flashing the 7.1 bootloader will fix it.
After that just dismiss the update and change the settings to manual updates.https://forum.xda-developers.com/editpost.php?do=editpost&p=78466377
2. Your device was already fully rooted and you got the full update that resulted in your Shield doing all sorts of thing but nothing properly anymore.
As long as your apps are still there and the Shield is still somhow usable you are lucky again.
A downgrade to 7.1 will fix it, I will explain the steps required further down.
3. You made bid mods, used Magisk or other rooting tools and now your Shield complains that your system is corrupt.
Bad luck if your bootloader is locked as you loose it all.
Lucky if the bootloader is unlocked as you might be able to keep most if not all during the downgrade.
General words of warning:
Even if your bootloader was unlocked from day one I can not garantee that the downgrade will keep all settings, apps, databases and so on.
For me it works fine as I kept all vital databases on external storage.
The procedures are all based on the developer firmware, on the stock firmware some things can still be done but then again you should not have more than software problems.
On the stock firmware the bootloader is locked by default and you can use some things required to owngrade due to the restrictions of a stock system.
General downgrade procedure for the developer firmware to get back to 7.1 :
If the update did get stuck on the progess bar early on and a reboot won't fix it so you can dismiss the update you just follow the steps.
If you can reboot into the 7.1 then just dismiss the update.
Trust issues or curruption warnings at boot but an otherwise working shield on 7.1 require to flash the 7.1 bootloader again.
In some cases it is possible to skip the corruption warning with a connected controller.
A reboot once you got to the homescreen will determine how bad it is.
Reboot goes fine: You are good.
Reboot keeps nagging with warnings other than the unlocked bootloader: Downgrade.
The downgrade is only required if you have problems or the Shield already runs on the 7.2!
In almost all other cases just flashing the 7.1 bootloader is sufficient.
Fixing a stuffed Shield by sideloading the 7.1 firmware while keping all apps and things:
Enable USB debugging and allow the connections for the computer if you still have access to the settings.
Otherwise you need to flash the 7.1 fresh and might loose vital things that need to install again.
Reboot into the stock recovery, if you use TWRP flashed on the Shield already then please flash the recovery from the 7.1 firmware first.
Hook up the controller and pressing A or B should get you into the normal recover screen past the dead droid.
ADB sideload XXX - where the xxx stands for the filename you have for the developer ZIP.
After the rebbot you should be back on your 7.1 homescreen and can dismiss the 7.2 update.
Also change the update settings while at it
Fixing a fully stuffed Shield and then downgrading to the 7.1 firmware:
If all went down south then you tried a few things and realised there is no way to get your data back and even less to prevent the 7.2 update.
Installing the 7.1 from scratch forces the setup wizard and before you can get anywhere you need to update to 7.2
So much easier to use the linked 7.2 update from above until Nvidia provides it on their download servers.
A vital thing to do is to keep the bootloader locked!!
Same for NOT having TWRP installed on the Shield!
If in doubt flash the 7.1 boot and recovery partitions first then go back into the stock recovery and wipe the cache.
Coming from a stock developer firmware with just an unlocked bootloader you are good to go.
Sideload the 7.2 update.
Unplug when the reboot starts and go into fastboot to lock the bootloader: Fastboot oem lock.
This is a vital step as the new kernel otherwise could ruin the completion of the install.
Ignore the double hassles and go through the wizard so you can enter the settings again to enable the developer mode and USB debugging.
Unlock the bootloader so you can do it all again Last time I promise!
Once you have both the bootloader unlocked AND the Shield in a usable condition past the setup wizard:
Reboot into the recovery to sideload the 7.1 firmware.
After the next reboot you are back on the 7.1 homescreen drirectly and can dismiss the update.
Possible tricks that can help you to prevent the installation of the 7.2 update if you come from a fresh 7.1 install instead:
Don't allow the reboot and instead use ADB to reboot into the recovery.
Wipe the cache - this will remove the scripts required to start the update after the reboot.
The next reboot should bring you back to the homescreen where you can stop the new download of the update and change the update settings.
TWRP, full root and new security measures in 7.2:
The 4.9 kernel used also makes use of a Fstab configuration that no longer includes the system partition.
This and other restrictions currently make the normal use of Magisk impossible.
With no system partition available to Magisk the changes in the boot process come to a stop and the Shield gets stuck during boot.
The added restrictions also make it very, very hard to manually add SU and busybox.
At least without getting the currupt system popup on every boot and finding out that a lot of things still don't work properly.
A final 7.2 firmware is said to be available on the download servers today.
If this final is no different from the current OTA then it will not be of any use for users requiring a fully rooted devices.
With the stock recovery still using the old kernel all attempts to use recovery functions to alter the system for rooting fail as well.
Can't blame the company as all this is part of Google revamp og security and closing backdoors and loopholes for possible attackers.
Personally I think it is Googles way of keeping control over devices they don't actually own.
Anyways I did make some little progress:
Plans for the near future:
Security is good but I like to know what my Android devices are doing and especially what Google likes to collect if I can not find ways to stop it.
So I will not try to use any backdoors or secrurity vulnerablilites in the new kernel to allow a full root on my Shield.
I will go the route I know best: Manual labour
The bootloader is already fixed to allow what we are used to from previous developer firmwares.
As SU and busybox can not be manually entered at this stage I will try to include them directly in the stock 7.1 firmware while renaming the OTA updater to have it a bit easier.
Assuming that works as expected I will do the same on the 7.2 firmware and compare the corresponding scripts and so on.
If the standard SU still works on an "unlocked" 7.2 I should be able to adjust the Magisk ZIP accordingly to implement it into the bootloader.
Only need to figure out if Magisk then has enough rights to work and the system is still happy to accept the changes.
I noly have the 16Gb 2017 model to work with but since the bootloader seems to be same for all Shield models I think if it works then it should do so for all models.
In the meantime I hope the infos here will help some pople to get their shield back without the need to sent it in.
Update 25/12/18: I got TWRP working on 7.2
This is only true for the 2017 model though as I have only this for testing.
Currently creating a backup to the internal storage.
If the restore works then I will upload the new TWRP - for the said model only!
Give me a day or two to fix it for the other models too.
There is progress on the rooting front as well.
Created new scripts for my kitchen to be able to handle the new file_context thing.
A fully pre-rooted and totally unsecure (in terms of ABD, DM-verity and such) is already cooked, just did not dare yet to try it out as I have a real life job too.
As for the pre-rooted firmware:
Things have changed quite a bit with the new kernel in terms of "just adding SU or Magisk".
Magisk might see an update for this problem soon, SU however seems to tally fail on two levels.
So far I was unable to do a full install of the modded firmware.
Flashed all at once and the boot just hangs.
Bootloader, reboot, then the rest seems to work.
At least for the basic install of the system.
If I add SU and busybox the system still ends up with a corrup notice during boot and then it fails.
Tune in over the next few days for progress updates at the end of the thread.
Major developments will be added right here.
Just a matter of finding the last restrictions.
Once that is done Magisk should be possible as well.
Ok, TWRP boot fine, does a backup but fails to restore the system to a bootable state.
Will now check if at least installing a zip works.
Well, it did not, so TWRP has to wait a few more days
I edited post 3 with instructions on how to "unbrick" and go back to 7.1.
Update 27/12/18: A friend of mine found some intersting stuff.
A 7.2 firmware offering a pure Android without any TV stuff but also a full root possible.
I hope he will share his finding here soon or allow me post it all in his name.
For now lets just say: It really works if done the rght way!
Full write rights, installing Magisk modules and all.
All thanks to an undocumented flaw in the device security structures, so even without any hidden backdoors or such LOL
Update: Whiteak was so kind to provide a working root solution in post 36, please check it.
I can confirm it is working as promised.
So the credits for this one go to Whiteak and the credits for the idea and use of the DTB file to Zulu99 - great idea!
To prevent any problems I advise to perform a factory wipe after the install and before the first boot.
Switch to the stock recovery to do this then boot as normal an enjoy.
A complete firmware with the required mods is sitting on my PC just waiting for idiot behing the keyboard to figure out how to pack it properly for flashing.
Once that problem is sorted and also TWRP working again things will get a lot easier.
Annoying update:
I was not able to confirm my web findings on the 7.2 firmwares bootloader but it seems other devices running the same type of kernel and bootloader and a bit lost now.
AVB is fully implemented on the latest level.
(Again I am working on confirming or denying these findings!)
This means any alteration to vital parts of the system will fail with a corruption warning or worse.
Custom recovery access is limited if not fully restricted.
But even if it works you still need a firmware to flash that either is able to disable all this crap, hoping the bootloader alone will allow it, or
to hope Nvidia will provide a future bootloader update with these restrictions removed.
We can not downgrade the bootloader and even if there is some old one out there that would actually be flashable the risk is high to end with a brick anyway.
The DTB, at least in my tests gives us the required system wide write access but I have no information about the AVM verfified boot other than that Zulu99's firmware works.
But if it was compiled with the NVidia developer suite then it will be signed accordingly so the bootloader accepts it.
Could not find any info on how his firmware was actually created.
It gives me the hope though that once I have a fully working TWRP again that my modded 7.2 will work as expected and with no restrictions anymore.
Thanks for the info.
Edit: Will use this post to list options to recover the Shield is all seems lost.
As a result of far too much rom cooking and mods I needed a 100% working way to recover the Shield in case things turn very ugly.
So lets sum up what I define as very ugly when playing with firmwares:
1. Firmware installed but the Shield just hangs on the logo.
2. Firmware installed and now the system is corrupt and even it is boots it takes forever to get around the nag screens.
3. Firmware downgrade attempted but now the Shield won't even boot anymore.
4. Anything that would qualify for a soft brick.
My worst case when I only got a flashing white screen after trying to restore a TWRP backup under 7.2.
There any many way that work for a variety of boot problems but it takes too long to list all cases I encountered with a list of fixes that work or a comment that only the below way works.
So just to be clear here: This is not for any recovery purpose other than fixing what can't be fixed through a factory reset or fresh flashing of the firmware!
1. Get the Shield into Fastboot mode: Connect wired controller and male to male USB cable.
2. Power the Shield up while holding A and B on the controller.
Keep holding until you see the fastboot menu on the screen.
3. Install the 7.1 recovery firmware for your Shield type after unpacking it.
With Fastboot connection working type: flash-all.bat and hit enter.
4. Keep an eye on the progess!
5. Once the Shield is finnished and reboots, hold the A and B buttons on the controller again to enter fastboot mode!
Do not let the Shield boot up other than into the fastboot mode!
6. Lock the bootloader! Fastboot oem lock
Confirm with the controller, then go down and select the recovery kernel.
7. Once the dead droid is on the screen press B on the controller to enter the real recovery.
If B does not work try A
8. Select the factory reset option to wipe all!
9. Once the wipe is done you can boot into 7.1 as normal again.
10. With a bit of chance you might even get directly to the homescreen if the previous setup was completed.
If you need the full seup wizard again and are forced to update to 7.2 then at least the update will work fine this time around.
In case you desire to go back to the 7.1:
If you just finnished the above only to end with the 7.2 then set it up and flash the 7.1 - you won't get the setup wizard again and can skip the update.
If you are on a working 7.2 that was update the OTA way but want to go back:
1. Install the 7.1 firmware.
2. Lock the bootloader.
3. Boot and then skip the update to 7.2.
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
psycho_asylum said:
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
Click to expand...
Click to collapse
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Downunder35m said:
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Click to expand...
Click to collapse
I have not been able to get to the dead droid screen.
Downunder35m said:
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
(snip)
Click to expand...
Click to collapse
Thanks for posting this, but please note that this firmware is only for the 2017 16GB model and cannot be used with a 2015 or Pro model.
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Weird, I am not getting the 7.2.1 at all here.
And since yesterday the OTA only tries the block based but not the full image.
AthieN said:
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Click to expand...
Click to collapse
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Thanks downunder this kind of in-depth info is always appriciated man........i like to learn these kind of things, having bits here and bits there gives a better picture of the whole, while also giving us upto date current info.
Thanks for taking the time to write this :good:
---------- Post added at 07:35 AM ---------- Previous post was at 07:27 AM ----------
Edit
Hi downunder, could you confirm i have this correctly
With no access to fastboot thus no twrp or root, are you implying, assuming your able to inject root into stock firmware, that, i'd be able to flash this stock+root rom in STOCK recovery, which i do have access to?
Edit: im under the impression that stock firmware zips are checked by stock recoveries, so modifying a stock firmware zip tends to fail this check and thus wont install/flash.......which makes me think im misunderstanding here......or just hoping im not
If so, im interested
Edit
i just read your second post which near enought answers my curiousity, so that'll teach me to read beyond the first post before asking answered questions ........even if the post excites me............ahhh, who am i kidding, ill probabably do it again........the equivelancy of a mental post boner........not controllable
Sorry for the disgusting analogy
SyberHexen said:
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Click to expand...
Click to collapse
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
ErAzOr2k said:
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
Click to expand...
Click to collapse
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
As long as we don't jump to Android 9 we should always be able to downgrade through a full factory firmware.
Once Android 9 comes this might not work anymore due to the massive changes involved for the boot and system checks.
@banderos101: Unless you really did something bad you should always be able to enter the fastboot mode to flash a full firmware.
If I have some time after xmas I will have another look on the options of signing the zip properly or simply to fake it.
Biggest problem will be to generate the corret SHA checksums ince all is installed so I can use the same checksums in the check files.
The bootloader needs them to identify the system and vendor as genuine.
The system needs them to confirm all is actually unmodified as otherwise all fails to boot at some stage.
Modding a proper userdebug firmware is not really that hard, but converting a release version that also is a true and secure user release...
Lets just say that it won't be an easy task.
As it looks like the kernel is a keeper I might have to figure something out unless TopJohnWu won't enjoy a break after his exams and works on a way to get Magisk working with out kernel.
At least I figured out why the recovery trick isn't working for me.
The system partition is not mounted for the sideload mode.
To apply an update the stuff is written directly onto the partition, so no file level access left to play with and break things
In comparison you could say the shield is now like a modern car with keyless operation only.
You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door
SyberHexen said:
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
Click to expand...
Click to collapse
Just wondering what is achieved by going back to 7.2?
What do you mean "going back"?
Right now the 7.2 is the official and latest firmware.
I was unable to get my hands in the 7.2.1 but guess it might have been a testversion for certain models only.
I wasted a few hours trying to fix the system image.
First stage was only to get the basic "features" back, like full ADB support, enabling the support to use SU and busybox....
Just what is required to actually allow these nice apps we like to gain root to work.
This backfired badly as right after the start the bootloader complained about the system being corrup and no override to get past this worked.
So of course I then removed the known restrictions from the bootloader...
As you guessed it the damn thing then did not even boot at all, just jumped right into the (locked) recovery mode.
A half decent comparision with my last manual root on a tv box that was a success showed I still did the right things...
If anyone wondered why we needed a new bootloader for the support of smart helpers an some codes stuff:
We didn't as all this could have been done with the 7.1 bootloader as well.
Since my root attempts so far all ended either in disaster or in a root access that failed shortly after/corrupted the system, I took a look of the general kernel changes that were published for other devices.
Before I could find anything meaningful I realised the 4.9 kernel is actually a requirement for Android Pie!
With that info sorted I started digging inti the new "security" features Pie can offer.
I will try to keep it simple and to the stuff that actually concerns us for rooting purposes:
The new boot process with Pie is aimed at being secure from the hardware level up and all the way into the system partion once the boot is completed.
So the hardware checks if the bootloader is actually usable - we had that for a long time, nothing new.
Once the bootloader starts and reaches the point of actually getting somewhere, all partitions required will be checks by either a hash check or a trusted certificate gererated at boot time that is compared to the previous certificate.
Only if that is fine the bootloader will call upon the system and vendor partitions.
The handover of control from bootloader to the system is made far more secure as well.
SELinux is called early on to ensure that only trusted apps and tasks can work but also to all a new control level.
System related apps no longer run as root or with special permissions.
Instead every single app and service runs as its own user!
And under SELinux conditions this means nothing can access anything that it is not entitled to unless included as a user for the other app.
And with that sorted the vendor stuff is called to ensure all hardware and vendor related stuff is still genuine - this include the required certs but also the recovery and bootloader hash codes and certs.
So if something is fishy either SELinux will stop us or the vendor stuff will just overwrite it all.
Once we finally reach the system stage the recovery is checked if called from within the system, if fully implemented it could mean that using an official update on a modded firmware will delete all data as the encryption from the old system is declared invalid.
Sadly it does not stop there because even with full rigths (faked or otherwise) to access the system partition with write access we still can not just change things.
If something belongs to a user (a secure app) than a change will corrupt the system.
To overcome all this without using vulnerabilities that so far no one has found, a compatible userdebug release has to be created from the official user firmware.
DM-Verity needs to be disabled as well as all partition encryption stuff.
The bootloader needs to be adjusted to reflect these changes and the required turst certificates generated and included in both system and boot images.
The only problem here is that the kernel won't allow these changes unless it itself is a userdebug kernel.
After that it is only the little efford to go through about 60 different scripts to remove or redirect the calls for all boot and system security related things.
If then by some chance all this actually boots up and goes all the way into a usable homescreen the entire stuff needs to be secured again.
This time so that the final system has a correct cert and checksum that matches those we need to include in the bootloader.
Anyone knows how to gain full access to the trusted keystore on the 4.9 kernel? LOL
For the moment I don't really care about all the stuff above.
I would be happy to figue out what to make out of these new fstab configurations without the vital partitions listed.
The real aprtitions used have not changed but it is impossible include them in the fastab, doing so causes the bootloader to fail.
Presumably because the kernel realised we try to get around the verification process.
This and some other minor things are also the reason TWRP fails so badly, same for the stock recovery by the way.
Since TWRP is toy a lot us like:
TWRP and 7.2....
Without a system partion in the bootloader fastab TWRP can not mount it.
Same for all other things TWRP needs to mount as it simply does not have the right to access these areas.
To make things worse, we need system access to even start TWRP through fastboot.
So, now matter if we flash or start it through fastboot: The bootloader and system will realise our recovery does not match the checksum.
What does al this now mean in terms a lot more people are able to understand?
Let me try...
Imagine the 7.2 in a running version would be just some encrypted file with a lot of folders in it.
And like PGP or other encryptions software we know there is a private and a public key.
With the public key you can see a lot and use most the encrypted file - but only to a level that is required, nothing above your low level clearance.
For every attempt to write into this file or to make changes we need the private key.
If you follow so far then lets just say the recovery (stock) and Fastboot can be, to some extent, used for this access.
But since every folder in the encrypted file also uses private and public keys it is like tracing a tree.
Although it is getting too long, let me give you the example of just adding SU to the sytem partition:
Adding SU into the system image is no big deal.
Singing this image to get a usable key and including this key into the keystore is.
Assume we would just be able to do it....
SU needs to be called quite early in the boot process.
It then elevates the access level for certain things and also intercepts all root related requests from apps and services.
Except of course those that already had these rights by default.
Problem here is that adding the scripts we need plus changing some others means violating the tree of trust on the device and we get locked out.
Finding a spot to add the required rights for SU might be still possible.
On the other hand it will be impossible to give SU any rights or access to "trusted user" owned parts, files, folders, partitions....
The entire concept of SU just fails.
I will have to check how much of the new features are active in the 7.2 kernel that hinder us.
If I find enough it might be possible it enough to call for a Magisk update.
But I guess it is of little use for just one set of devices, so maybe once more devices on the 4.9 kernel fail to work with Magisk it will be easier to spot a usable pattern.
In case someone else if already working ona mdified system: Please let me know how you made it boot after the changes
Shield Tv 16 2017 - OTA update 7.2.1 Ready for updating
Im on 7.1. I have been waiting for 7.2 developer image, which is now out and just noticed 7.2.1 is available OTA. I'm really confused what to do. I want to keep root without bricking my Shield. Should I Stay with what I have as it is running well.
I am not even sure if it is safe trying to update to dev 7.2 image (or if I would want to) by hooking to computer and using ADB Fastboot tools.
Is there any good reason to update to 7.2 or 7.21? and if so how would I go about doing it? Which program is good for flashing developer images or OTA updates. I used to use flash-fire, which seems to be obsolete now and have heard TWRP is incompatible rooting with SU with OREO updates????
Should I play it safe and stay with what I have rather than experiment and end up with a brick? (wouldn't be the first time)
Anyone know if 7.21 is some-kind of bug fix?
Alot of questions but hope someone has some answers.
Thanks for any info.
"You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door "
My fastboot issue
Yeah, i think i busted the microusb somehow with a faulty usb hub, whenever i plug the usb to my raspberrypi/windows box(for adb/fastboot) now, it turns off all usb ports on the pi aswell as the windows box, even when the shield is unplugged, some sort of earth problem maybe
......all i have is adb over network, adb reboot bootloader simply reboots back to system, adb reboot recovery works though.
ive read that fastboot over tcp(ethernet) had been introduced a couple of android versions ago, but i dont think its been implemented in our shields
infact heres a link
https://www.androidpolice.com/2016/...-capabilities-wireless-flashing-isnt-far-off/
Looks like it needs to be specifically added onto a build
As far as you making a stock root build, if you can, that would awesome, more then awesome, but if it becomes more work then you thought dont worry about it, its not like their making it easy
Also, sounds like 4.9/future android is gonna be a nightmare for root......... having the ability to root so that the option is there to see whats going on in the background of these devices, these devices posessing cameras/microphones/old+latest sensors/personal files/personal info, which reside on our personal beings or in our homes........is just one reason why i dont want to see root go away
So what is the purpose of the developer image of 7.2?
Rather, I know the stated purpose of the developer image, but if it is locked in the way described it sounds like the benefit is negated for typical developers.
(e.g. sometimes I debug an application without permissions in order to benchmark or debug a problem).
For casual users of the shield, using ad blockers and whatnot, is there any benefit to derive from installing the developer rom over stock? Does "adb root" still work?
What is left as the difference. It doesn't sound like they produced a userdebug build of the OS.
Thanks
The 2 new updates are horrible. I have gone back to 7.1. They have crippled my shield. I'll wait for a new update.
After many searches for the best help on my new Asus ZenFone V V520KL, I have no way to unlock the bootloader. Asus doesn't provide any support for this 2017 model, nor does Verizon, the company the phone was made for.
It comes stock with Nougat 7.0 OS, 32 GB ROM & 4 GB RAM. It's got a decent size screen and runs not too too bad.
I'm wondering if one of the tech people here would be so kind as to help me with not only unlocking the bootloader so I can then install a custom recovery image, preferrably TWRP, since I have used this type of program before on my other ZenFone 3 Zoom.
I already have ADB tools on my Windows 7 notebook (32-bit). I used it to install the last root on my other aforementioned phone so it will work.
What I'm wondering about is the bootloader unlock tool, custom recovery image (TWRP), and a way to root the bastard. Hopefully we can relock the bootloader after the job's done because it's annoying on my other phone to always have to bypass the "Can't check for corruption." screen before the phone actually boots. Again this is for the Asus ZenFone V V520KL model. There is really no information anywhere right now I know of that gets this job done.
Having a custom Pie 9.0 ROM upgrade would be the best if possible once we root the device.
My name is Andrew, S.D. from Canada.
Thanks and blessings.
Root
Did you find a way to root it?
No, I still need help with the original post. I can root the ZenFone 3 Zoom ZE553KL but they already tell us how to do that in another forum.
the Bootloader for v520kl is already unlock by ENG Firmware
Just serch it in forums
You're talking to a noob. Give me the location of ENG firmware.
Hi friend, in the other post de link for downloading de ENG Firmware is broken
[email protected] said:
Hi friend, in the other post de link for downloading de ENG Firmware is broken
Click to expand...
Click to collapse
This is the link
http://www.mediafire.com/file/lc17b75qbvy018z/Asus_Zenfone_V_V520KL_All_WW_ENG_T3.3.15.zip
I tried to flash it did not work for me..
---------- Post added at 10:55 PM ---------- Previous post was at 10:43 PM ----------
Doctor Andrew said:
You're talking to a noob. Give me the location of ENG firmware.
Click to expand...
Click to collapse
Here is the link:
https://forum.xda-developers.com/showpost.php?p=78833735&postcount=52
Hi friend,
It's de the same rom for this page
https:
www
hardreset.info/devices/asus/asus-v520kl/faq/firmware/ because, the size of this rom is 813MB
and the size of the rom of the link that you provide is 775.53 MB and the files is the same name.
or this rom has been updated.
someone know what version of android have this rom
Okay so we now have a link to just the ROM it looks like. Do we have a way to unlock the bootloader yet and install TWRP first? What about the TWRP image file, do we have one of those as well?
Doctor Andrew said:
Okay so we now have a link to just the ROM it looks like. Do we have a way to unlock the bootloader yet and install TWRP first? What about the TWRP image file, do we have one of those as well?
Click to expand...
Click to collapse
To flash the ENG rom, you do not need to unlock the bootloader. Just the Asus flash tool.
Once you flash it, you can reboot to fastboot mode(adb reboot bootloader) and use fastboot oem unlock to unlock bootloader. Be warned though the ENG firmware is very basic. No web browser, no google play, you can't pull down the notification bar etc. (Great battery life though with about 7-10 days since I am not using it at all).
As of right now, there is no TWRP for it that i know of. In fact, I can't even boot into recovery atm. I also am unable to get boot.img file form the .raw file so the various methods to root it seem to be out of reach for the moment.
I've absolutely no interest in the ENG firmware. Still looking for a solution to the original post that people can understand and use easily.
Doctor Andrew said:
I've absolutely no interest in the ENG firmware. Still looking for a solution to the original post that people can understand and use easily.
Click to expand...
Click to collapse
Well, ENG is the only way i could figure it out but I finally manged to get root on the phone with magisk. Still have some work to do to get play store and everything else running properly, but for now, hardest part is done.
oh my god - rooooot
faericia said:
Well, ENG is the only way i could figure it out but I finally manged to get root on the phone with magisk. Still have some work to do to get play store and everything else running properly, but for now, hardest part is done.
Click to expand...
Click to collapse
Good time of day, Faericia, this is just great news. You can share the experience of getting root with magisk?
Regarding Google Play and all that, where you need Google, using a bunch of microG and Aurora store.
MicroG is the core of Google services, which allows you to pass authorization through Google, synchronize and do it all without any garbage code, according to my observations, the expense is not much spent.
Aurora shop, as an analogue of Google Play, the application, the ability to save apk.
Due to the lack of binding to your Google account.
I think this connection may be relevant and rooted.
The initial partition should appear as root, it intends to resolve all the problems that I have in my phone. for asus applications, after I have done my best, several attempts have already been made.
It was possible to look in read mode using root explorer.
Perhaps you can somehow remove the protection of verizon on the bootloader.
PS the most hardcore variation of raw firmware, a hex editor, search in that between code, boot, recovery, system, etc. Very large empty spaces. previously there were 100 miles earlier.
I think this is part of verizon jokes.
This article should be cut and placed in img.
Thanks so much in advance.
hello when you finish you could share through a tutorial what you did I have my asus v with verizon rom and only data but if I can make it functional with the rom eng then better
Okay, Here are the steps. Before anything else though, I should warn you that I have not been able to get safetynet to pass. So if you have apps that require safetynet to pass, this may not be the way to go.
First you will need the ENG firmware:
https://mega.nz/#!l7wBlQ4B!uB63yH5Rir24GaSfDMWKowqdz-N_sc6SJ-q1WuuGiqM/
Also Asus Flash tools v 1.0.0.72:
https://drive.google.com/file/d/11rcjOgdpJhpK97GzbhYK6cYEIWOtzKE9/view
I am assuming you know adb and such. If not, search the forums and get the adb tools.
Using adb, Reboot to bootloader. ( adb reboot bootloader )
Load the .raw file in the asus flash tool, select v520KL and flash.
Once flash is done, unlock bootloader by going into bootloader (adb reboot bootloader) then type (fastboot oem unlock.)
Here is the patched_boot.img I used if you want to just try to flash that and see if it will work. This is for the eng firmware.
https://drive.google.com/file/d/1fUxGc27lrodR3ro9MIspde73G8Xg9VlW/view?usp=sharing
Go into bootloader and flash. (fastboot flash boot patched_boot.img)
Install magisk manager and test it out.
If you wish to patch the img yourself, the steps are below (still working on it):
So now we have the phone unlocked, and the software is very basic. We also need the boot.img file to patch since we do not have TWRP. Since I couldn't get it from the raw file (the extracted file is invalid with a size of 0 bytes) I decided to extract it from the phone. But to extract from the phone we need root. So for this next step, temporary root will have to do.
You can get temp root by using KingoRoot. Use the PC version and you will get root. This is just so we can extract the files from the phone itself.
I need to find the steps for the next steps again, but the basics is, extract boot.img from the phone. Patch it using magisk manager and then flash the patched_boot.img in bootloader mode. I had google play working(chinese version) but once i removed kingoroot it kept crashing. I currently have magisk and it gives me the root permissions but safetynet fails. I will retry this tomorrow and see if I can fix the safetynet issue and update this post with the steps.
Also I seem to have borken recovery mode on my phone. That may be because I tried flashing bunch of other stuff before I managed to root it so I do not know if it will be the same situation to you or not. I believe after I flashed ENG firmware, i had access to recovery mode at one point, but I may have just messed it up. Either way, Expect updates in the near future.
asus recovery
A huge over many thanks.
I also tried to get a temporary root, via the kingoroot pc version, it did not work, I suspect it because I installed eng, but did not oem unloock, when I did unlock, I somehow managed to get the boot out of the firmware, the user from 4pda was patched, but said that this boot is from 8 android, I thought that I had schizophrenia because later on trying to get boot I also got 0mb, this was due to the unexpected end of the archive.
In general, by flashing this boot, I also found a recovery mode and even a recovery mode, but going into recovery a message from Verizon was displayed, standard, when you roll the eng firmware for 5 seconds, hold something, etc. Well, you understand. And the whole laugh is that it was in a circle.
I suspect that asus had any plans for this device or for this amount of components. In other words, it was some kind of blank that was abandoned, maybe asus thought that this exclusive for verizon will make a trap, and then they say on the basis of v520kl we will make a non-exclusive open device, but alas, a huge member between two rolls.
Therefore, fortunately or unfortunately, recovery was not broken by you, most likely it was not working initially, but this is only a guess.
Daniel.Sim said:
A huge over many thanks.
I also tried to get a temporary root, via the kingoroot pc version, it did not work, I suspect it because I installed eng, but did not oem unloock, when I did unlock, I somehow managed to get the boot out of the firmware, the user from 4pda was patched, but said that this boot is from 8 android, I thought that I had schizophrenia because later on trying to get boot I also got 0mb, this was due to the unexpected end of the archive.
In general, by flashing this boot, I also found a recovery mode and even a recovery mode, but going into recovery a message from Verizon was displayed, standard, when you roll the eng firmware for 5 seconds, hold something, etc. Well, you understand. And the whole laugh is that it was in a circle.
I suspect that asus had any plans for this device or for this amount of components. In other words, it was some kind of blank that was abandoned, maybe asus thought that this exclusive for verizon will make a trap, and then they say on the basis of v520kl we will make a non-exclusive open device, but alas, a huge member between two rolls.
Therefore, fortunately or unfortunately, recovery was not broken by you, most likely it was not working initially, but this is only a guess.
Click to expand...
Click to collapse
I know recovery mode was working with VZW firmware. I know this because I tried installing using adb sideload several times. I might be mistaken on getting there once i flashed eng firmware but again, it has been a month or two since I tried it and all I know is, it won't go into the recovery screen now. Oh well, not my main phone so irrelevant.
I have installed patched boot img with fastboot. Now have root. But there a lot of apps not working. No Google apps at all. And no way to install them.
---------- Post added at 06:23 PM ---------- Previous post was at 06:15 PM ----------
Have installed patched boot img by faericia. Now I got root. But eng version doesn't have Google apps, so no play store, no Google pay, no accounts, no Gmail. And I don't know how to install it.
game #1 said:
I have installed patched boot img with fastboot. Now have root. But there a lot of apps not working. No Google apps at all. And no way to install them.
---------- Post added at 06:23 PM ---------- Previous post was at 06:15 PM ----------
Have installed patched boot img by faericia. Now I got root. But eng version doesn't have Google apps, so no play store, no Google pay, no accounts, no Gmail. And I don't know how to install it.
Click to expand...
Click to collapse
The only time I had Google apps was when I had kingoroot root still int he system. I then downloaded the Chinese google apps installer and used that to get it. Once i removed kingoroot google framwork kept crashing making it unusable.. If you don't need to pass safetynet, that might be the way. Othewise, I am still trying to work on it.
faericia said:
The only time I had Google apps was when I had kingoroot root still int he system. I then downloaded the Chinese google apps installer and used that to get it. Once i removed kingoroot google framwork kept crashing making it unusable.. If you don't need to pass safetynet, that might be the way. Othewise, I am still trying to work on it.
Click to expand...
Click to collapse
I found out how to stop frameworks from crashing. Just make it a system app. I use link2sd for this.
Now all gapps work nice.
Hello, and thanks for reading my post...HOPING someone can help...so, Here's the specs. If you need more just ask...
Mediatek MT6739 salable: ZTE Z3351S (Qlink Wireless govt. phone)
Android 9 running SP 2019-07-05 (API 28)
Build: Z3351SV1.0.0B4
BL: Locked, no root (even through Magisk...so far.)
As this is my primary phone I'd really rather avoid the off chance of bootloop, soft/hard bricking....but I am very interested in the security features on this device...I've not done a LOAD of rooting and playing, this system has managed to make my poor old brain swim like I had a green beer!!!
I've so far managed to get a temp root solution, and got backups of the entire device excepting the /user partition...not an easy task, and I PROBABLY coulda got it but that's one big-a^& file!
Since I don't wanna have to actually pay full price for a replacement in the case of me screwing up, I've hesitated on trying the Magisk solution for a /system-less root. I unpacked the boot.img and ramdisk (which wound up empty,) and the recovery.img and ramdisk (which did have files,) and I dont really have the experience in repacking the image (with oem signature,)
or (and this is a big one,)
how to enable the full fastboot on it...and I'm not sure where that is, I think it's moved to the user area...and I want the BL unlocked before I even try to Magisk this puppy...
Fastboot works okay, maybe. Command adb reboot bootloader gets me a fastboot mode on the device, but no fastboot devices. When I lsusb (Linux Mint 18) the Mediatek device shows up, but not as bootloader.
I would like to take these unpacked files, mod the existing kernel to allow full fastboot, repack it (with oem sig so the stock recovery doesn't reject it,) the flash it as an update....
....HEEELLLPPP...
What do I do from here?!?
Thanks a LOT guys...and you gals too!:laugh: