Database Info

Help with editing my build.prop

Hi every one
just need to confirm from professional people here , i need to edit build.prop on my A9 device without rooting so that i could make some connection with my car screen (stupid screen accept only Samsung and LG) , Is that possible?

amro ibrahim said:
Hi every one
just need to confirm from professional people here , i need to edit build.prop on my A9 device without rooting so that i could make some connection with my car screen (stupid screen accept only Samsung and LG) , Is that possible?
Click to expand...
Click to collapse
First, this question gets asked A LOT so a simple search here or google will show numerous others asking this and their findings. It doesn't matter if its not specifically referring to HTC A9 or in this specific forum either.
That being said....to answer your question.....NO! ^_^ You will most likely need root to even access the system root folder where your build prop. You may find it using some app possibly that doesn't require root, open it and change values, HOWEVER, you will never be able to save these changes without root, sorry.
If you are knowledgeable on unpacking system images or have firmware.zip/tar etc that you can dig through and find the build prop, edit it on windows/linux/mac repack or rezip and flash it successfully....thats one way.
Another way would be to use ADB to pull what you want and push it back to system afterwards.....but not to sure as my phone(s) usually are rooted and never tried to use ADB unrooted. Somethings tells me that this too won't work but go for it.

mcbright80 said:
First, this question gets asked A LOT so a simple search here or google will show numerous others asking this and their findings. It doesn't matter if its not specifically referring to HTC A9 or in this specific forum either.
That being said....to answer your question.....NO! ^_^ You will most likely need root to even access the system root folder where your build prop. You may find it using some app possibly that doesn't require root, open it and change values, HOWEVER, you will never be able to save these changes without root, sorry.
If you are knowledgeable on unpacking system images or have firmware.zip/tar etc that you can dig through and find the build prop, edit it on windows/linux/mac repack or rezip and flash it successfully....thats one way.
Another way would be to use ADB to pull what you want and push it back to system afterwards.....but not to sure as my phone(s) usually are rooted and never tried to use ADB unrooted. Somethings tells me that this too won't work but go for it.
Click to expand...
Click to collapse
Actually i searched a LOT but i have found the TWO answers "Yes you can" AND "No you can not" , also people says yes you can giving steps i have no idea about it like this one
1. Make a process which executes "getprop" from the "/system/bin/getprop" directory and initialize the String which we want to get (ro.board.platform in example).
2. Make a BufferedReader which gets the value (String) by retrieving the data from a inputStreamReader().
3.Convert the BufferedReader to String.
. That is why i asked here again to get clear answer which i get it and many thanks for you

amro ibrahim said:
Actually i searched a LOT but i have found the TWO answers "Yes you can" AND "No you can not" , also people says yes you can giving steps i have no idea about it like this one
1. Make a process which executes "getprop" from the "/system/bin/getprop" directory and initialize the String which we want to get (ro.board.platform in example).
2. Make a BufferedReader which gets the value (String) by retrieving the data from a inputStreamReader().
3.Convert the BufferedReader to String.
. That is why i asked here again to get clear answer which i get it and many thanks for you
Click to expand...
Click to collapse
LOL i understand the frustration. I also spend a ridiculous amount of time scouring forums and any other place online for the many questions i need help with only to get fractured/incomplete answers or conflicting ones like you stated where it seems like the answer is both yes and no or whatever....its a real pain. Truthfully, I said you wouldn't be able to do this without root due to the level of difficulty of the other options trying without root. Creating bufferedreader etc is all Java Programming. You will need a decent working knowledge of java programming to be able to do what that guide was talking about.....i figured you might not have that so I said that NO to your question here. I know some of what that guide was explaining enough to create some of that they described but still not enough to feel comfy attempting. Your best option, i think, will be to extract the build prop from a stock.img and repack the system.img after editing the build.prop. Use 7zip to unzip/rezip the system.img and notepad++ to open/edit the build.prop and flash image in your recovery. You could also use Android Kitchen if you can. Plenty of tutorials on this. I linked two below for ya though. '
What were you looking to edit in the Build.prop anyhow? I assume you are disinclined to root/unlock bootloader for warranty issues correct?
BTW, sorry for such a late response...I am not always here for days at a time usually so.....
dsixda's Android Kitchen - http://forum.xda-developers.com/showthread.php?t=633246
Super-Rs - http://forum.xda-developers.com/chef-central/android/kitchen-superrs-kitchen-t3202296

mcbright80 said:
LOL i understand the frustration. I also spend a ridiculous amount of time scouring forums and any other place online for the many questions i need help with only to get fractured/incomplete answers or conflicting ones like you stated where it seems like the answer is both yes and no or whatever....its a real pain. Truthfully, I said you wouldn't be able to do this without root due to the level of difficulty of the other options trying without root. Creating bufferedreader etc is all Java Programming. You will need a decent working knowledge of java programming to be able to do what that guide was talking about.....i figured you might not have that so I said that NO to your question here. I know some of what that guide was explaining enough to create some of that they described but still not enough to feel comfy attempting. Your best option, i think, will be to extract the build prop from a stock.img and repack the system.img after editing the build.prop. Use 7zip to unzip/rezip the system.img and notepad++ to open/edit the build.prop and flash image in your recovery. You could also use Android Kitchen if you can. Plenty of tutorials on this. I linked two below for ya though. '
What were you looking to edit in the Build.prop anyhow? I assume you are disinclined to root/unlock bootloader for warranty issues correct?
BTW, sorry for such a late response...I am not always here for days at a time usually so.....
dsixda's Android Kitchen - http://forum.xda-developers.com/showthread.php?t=633246
Super-Rs - http://forum.xda-developers.com/chef-central/android/kitchen-superrs-kitchen-t3202296
Click to expand...
Click to collapse
Thanks again for your replay , actually i still trying to proceed your way .. i think i am too close to do it , but you know after one or two hour of Trying&searching i say to my self let us unlock this phone and finish this matter .. any way i am using the Android Kitchen and i hope i could do it

[GUIDE] How to gain root shell on 2016 Honda Pilot (and now install apps!!!)

Disclaimer - this is your vehicle you are messing with. If you are not comfortable with potentially permanently damaging the head unit, stop here.
Now for the good stuff.
Credit where credit is due: this method relies on the recent "dirtycow" exploit. I used the POC Android exploit code located here:
https://github.com/timwr/CVE-2016-5195
This exploit in simple terms takes advantage of a Linux kernel bug that allows a (small) file to be "overwritten", when a user only has read access to that file. It doesn't actually modify filesystem contents, but any application that reads the file after the exploit is used will read the "new", post-exploit contents instead of the original.
The scripts attached use the dirtycow binary to overwrite the "/system/etc/factory_reset.sh" shell script with a nefarious version. This script is executed when you perform a factory reset operation through the settings menu, and gets executed as the root user .
The nefarious script is quite simple - it just calls another script that is uploaded and performs a reboot. The second script mounts the /system partition as R/W, then copies over an su binary and sets appropriate permissions, then syncs and mounts read only again.
Please note that the attached "rootme.sh" script is intended to be run from a Linux machine - if I get the time (or enough donations), or if someone else cares to, it can be ported over to a Windows batch file easily enough.
Updated the attached zip to include a Windows batch file.
Steps:
Download the attached zip file
Extract to a machine capable of connecting to your Pilot over ADB
Modify "rootme.sh" (*nix) or "rootme.bat" (Windows) to use the correct IP
- Change the "172.16.1.217" lines to reflect the correct IP for your Pilot
Execute "rootme.sh" (*nix) or "rootme.bat"
- ./rootme.sh should do it for *nix
- for Windows, open a command prompt, navigate to "rootme.bat" location and type "rootme.bat"
- Watch output for completion
Perform factory reset operation
- Note - should the exploit function correctly, this step should NOT perform any factory reset operations. However, you should fully expect everything to be reset if the exploit failed or some other problem occurred when attempting to use a nefarious factory_reset.sh script.
After the Pilot reboots, you should be able to get a shell over ADB as normal, except now issuing an "su" command will drop you to root!
Update - thanks to purespin figuring out the signature mechanisms, we can now install apps! I've attached OneClick.zip, which contains a series of scripts to automate the rooting & app installation process.
That said, be careful, use these at your own risk, etc.
Extract zip file to some folder then open up a command prompt in that folder. Also drop the APKs you wish to install to that folder.
Type OnceClickInstall.bat [YourHeadUnitIP] [APKToInstall.apk]
The script will root your device if it's not already, then go ahead and perform steps necessary to install the APK (one reboot required if already rooted).
This basically performs the steps described in purespin's post to get a signature of the APK, download and modify the whitelist XML file, upload it back, reboot, then install the APK.
There's one prompt in the script that asks you too look things over - pay attention here, if any issues crop up at this point damage can be avoided, continuing in a bad state will have undefined results.
Updated the scripts to back up the white list on each run to /data/local/tmp/whitelist-(timestamp).xml.
Updated to handle APKs with more than one signature.
Edit: As suggested by wpg_moe, a Git Hub project has been set up here:
https://github.com/jersacct/2016PilotOneClick.git
Changes & suggestions are encouraged and welcomed, but this is a part time hobby project for me, so expect movement to be "lumpy", as I'm mostly only able to work on this during the weekends.

would this work on a 2016 civic android headunit? should be the same concept for it?

This is GREAT news!!! We will start to test it on a 2016/Civic/Touring. It reminds of of the hacking a linksys firmware via tftp.

sheryip said:
would this work on a 2016 civic android headunit? should be the same concept for it?
Click to expand...
Click to collapse
I don't have a Civic to test with, but I would imagine Honda uses the same factory reset mechanism on both models.
The included scripts are pretty straightforward - if you care to crack them open you'll see the operations they perform pretty plainly. I think the absolute worst you could suffer if you attempt this is that you factory reset your head unit. Remember your favorite radio stations if you decide to give it a shot.

Yes, I am able to root the 2016 Pilot using the method provided by jersacct. It is super easy and strait-forward!
Now the question is what is next I have been working as programmer for the last 20 years but I don't have much knowledge of Android hacking. What's the starting point?

I'd say step 2 is to get the system info from a Ridgeline or a '17 pilot when they come out so we can try to put Android Auto or Car Play on the 16 models. Navigation would be nice but with AA/CP, you wouldn't need it.

Yep, this is just a first step. We still have to work around the white list service Honda put in place that's preventing installation of other APKs. I have not been successful in replacing the ApplistUpdate.apk with a modified version or replacing /data/system/whitelist.xml with a modified version. In either case the service is still preventing installation of new APKs.
I have a couple of workaround theories I'm working on - tracking down and modifying the service's source to always allow APK installation (effectively disabling the white list check), using the service's own interface to add APKs to the white list (much like S_Mike has done for the EU versions), stripping out or disabling the service entirely.

I think it would be much easier to get APKs installed than porting Android Auto or Car Play over. I would be much happy if we can achieve what they have done on EU versions.
jersacct said:
Yep, this is just a first step. We still have to work around the white list service Honda put in place that's preventing installation of other APKs. I have not been successful in replacing the ApplistUpdate.apk with a modified version or replacing /data/system/whitelist.xml with a modified version. In either case the service is still preventing installation of new APKs.
Click to expand...
Click to collapse
Any summary on how S_Mike did that (using the service's own interface to add APKs to the white list)? If not, I might spend some time to loop through the 139-page thread after work
jersacct said:
I have a couple of workaround theories I'm working on - tracking down and modifying the service's source to always allow APK installation (effectively disabling the white list check), using the service's own interface to add APKs to the white list (much like S_Mike has done for the EU versions), stripping out or disabling the service entirely.
Click to expand...
Click to collapse

I have a pilot 2016. But i dont have a Linux machine. So how can i use this. Even if i use this, if i will not have access to install apks then what is the use. I am a bit confused. I am also a developer and have been rooting my phones to install custom roms, but that was all with the guides that i found on the internet. Didn't try any thing fancy.

ammarbukhari said:
I have a pilot 2016. But i dont have a Linux machine. So how can i use this.
Click to expand...
Click to collapse
I've updated the attachment to include a Windows batch file, and updated the instructions.
Rooting the device with this method doesn't mean you can unlock all the Android goodies we're hoping for. It will, however, help a person so inclined to defeat the Honda installation restrictions.

There is no zip file

jersacct said:
I've updated the attachment to include a Windows batch file, and updated the instructions.
Rooting the device with this method doesn't mean you can unlock all the Android goodies we're hoping for. It will, however, help a person so inclined to defeat the Honda installation restrictions.
Click to expand...
Click to collapse
Thanks, have you had any luck installing an apk? That's what I'm looking to do on my Ridgeline.
Sent from my Nexus 6P using Tapatalk

ammarbukhari said:
There is no zip file
Click to expand...
Click to collapse
Sorry, corrected.

enyce9 said:
Thanks, have you had any luck installing an apk? That's what I'm looking to do on my Ridgeline.
Click to expand...
Click to collapse
Not yet, still working on this.

The system doesn't just check the white list. It checks the certs as well. If it's isn't sign by the developer for Honda the package installer won't install the apk.

Guys, you probably have to change the signature of the APK in the list from that code to "PREINSTALL", without the "". I have a 2015 Honda HR-V and that's the way we can install apps on our head unit. Some people had problem to install apps after updating Honda applications, because it changed "PREINSTALL" to the app signature. After a factory reset, they got the PREINSTALL again for "HondaAppCenter_A1.apk". So, try removing the signature code to PREINSTALL for some APK and use that APK name to install the app.

maecar said:
Guys, you probably have to change the signature of the APK in the list from that code to "PREINSTALL", without the "". I have a 2015 Honda HR-V and that's the way we can install apps on our head unit. Some people had problem to install apps after updating Honda applications, because it changed "PREINSTALL" to the app signature. After a factory reset, they got the PREINSTALL again for "HondaAppCenter_A1.apk". So, try removing the signature code to PREINSTALL for some APK and use that APK name to install the app.
Click to expand...
Click to collapse
I think the protection mechanisms in this version are entirely different. There are no "process_controls.list" or "allowed_installations.list" files present in the entire filesystem, nor does a grep across the entire filesystem return any results for "HondaAppCenter". These tell me that the protection mechanisms are not the same as previous or EU versions.
I've attached what I believe to be a component of the replacement mechanisms, an XML file describing full app names, sometimes signatures, and fields describing permissions. Any edits to this file don't seem to be regarded, so I'm still digging in to the core services that make up the white list mechanism.

Did you update whitelist.xml file directly or update the whitelist.xml file in ApplistUpdate.apk?

What a coincidence this is, as I heard about the Dirty Cow exploit just the other day and spent time trying to root my 64 bit Samsung smartphone to no avail. I did hear that it works on 32 bit android platforms and how about this for a case in point.
Jersacct, thanks for making this available to the community! I can understand that the first hurdle is getting the system to stop blocking / removing non-whitelisted apps and it sounds like you are just getting to this point now. Keep up the good work and please let us know if there are any minor details that you need worked out that can be delegated to the community, i.e. testing, troubleshooting or research.
Looking forward to having more capabilities with my 2016 Honda Pilot!

purespin said:
Did you update whitelist.xml file directly or update the whitelist.xml file in ApplistUpdate.apk?
Click to expand...
Click to collapse
I've attempted both approaches, with no luck. It may be that my ApplistUpdate.apk replacement was flawed somehow, so I'm not sure there. Because you modify the zipped whitelist.xml in the APK, you also have to resign the APK before installation, Android won't reinstall an app with different signatures without uninstalling original, and because it's a system app it won't let you uninstall.....blah blah I deleted the original (after backing up) and replaced it with modified version, still no positive result. I attempted to add eu.chainfire.supersu (picked at random, could be anything) to the list of allowed apps in these cases but still couldn't get it installed.
I think my next approach will be to edit the system services (in /system/framework/services.(.jar,.odex)) and see if I can disable all whitelist checks.
Now that root is available, it's only a matter of time before someone gets around Honda's restrictions.

Temporary root shell for developers on locked bootloaders.

Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
 @jcadduono - For recowvery, and pointing me in the right direction on IRC.
 @brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.

Very cool work! Glad to see people putting my shell (such as it is) to good use. Wish I had a V20 to try it out

I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).

jcadduono said:
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
Click to expand...
Click to collapse
if system_server can read init then thats a serious flaw.... Question for you. you said it would be very device specific. does that mean its unique for each individual phone or each model?
EDIT:Unfortunately we only have access to the init.rc not the binary it self.

@jcadduono I appreciate your input and direction in this matter another idea we have been toying with is
We have the aboot boot recovery and system dump. From the tmob variant would it be possible to make a tot from that for our devices changing the props to match our device, build, and carrier info? We can also pull apks from /system/apps and /privapps to our ext sdcard

@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA

roosta said:
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
Click to expand...
Click to collapse
It should work on all models. I personally use a sprint model(LS997). I think it MAY have been tested on VZW as well.

I can confirm that work on H990DS
Sent from my MI PAD using XDA-Developers mobile app

We know from earlier LG phone releases that the laf partition when bypassed in some way (corrupted, etc) aboot will boot to fastboot when going into download mode. It was my thought that the bootloader could be unlocked from there. However corrupting laf eliminates device recovery. Catch-22.
I think the best way to proceed is to get a working .TOT first which is just a waiting game. That would ensure device recovery and replacing the bootloader in the .TOT and signing it with something unlockable.
This is a great way to explore the locked phones in the meantime, thanks.

ATT Pretty Please

me2151 said:
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Click to expand...
Click to collapse
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!

NRadonich said:
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
Click to expand...
Click to collapse
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario

elliwigy said:
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
Click to expand...
Click to collapse
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid

markbencze said:
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
Click to expand...
Click to collapse
Unfortunately its a tcp shell. not a pure adb shell. so we cannot push or pull to those directories

Wow great progress keep up the good work. You guys are helping those assholes from LG sell more phones. Obviously some people have not made the switch because the lack of root. Root users are very influential leaders to get others to try out a new device.
Sent from my LG-LS997 using XDA-Developers mobile app

Works on the LG G5 also...

Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA

roosta said:
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
Click to expand...
Click to collapse
it shouldnt be an expectation as weve made it clear we do not have root and are hitting hurdles.. we have been advised we need to atack selinux and or the bl but at this point were wanting to try to use debug firmware which hoprfully would allow a bl unlock..
unfortunately nobody can creat a .tot with the debug firmware at al and theres no way at all to flash the images..
we need to somehow leverage an exploit to gain a temp adb root shell before we could even attempt anything and this has not been done in a way thats useful to us..
unfortunately we need more experienced devs at this point.

LG Australia (and as such, Taiwan) have effectively confirmed their H990DS v20 mobile phone's bootloader is confirmed as being unlockable. However (and for no apparent reason) they will not confirm why one region have released a variant of the phone with the bootloader unlock and why they are refusing this to others phones/regions. Because of course, they have zero training and information about anything related to their company expect for goods released in a specific region. That comes from a 'product expert'

Titanium Backup
Howdy,
Just reading through the thread, I understand that it's not quite a "full" root, but would it be enough to run Titanium Backup? I'm hoping to move away from root access with my V20 but it would be really helpful if I could do it temporarily, restore some application and data backups, reboot and uninstall Titanium.
Tim

[5.12.17][g935u][root] stable method for g935u - bqd2 t-mobile

As we have all seen with this latest STOCK G935U [BQD2] Firmware for T-Mobile indeed it runs smooth and personally I have experienced better performance without all those carrier-bloat applications by default. Dating a week ago, I tried to root this build version and for some reason I experienced infinite bootloops after my device boots up. So I did some research as to what system apps could be causing this I still I can't believe that a network-related system application was causing this issue.
I am talking about com.samsung.sprint.chameleon as mentioned by @qwewqa here -> https://forum.xda-developers.com/tmobile-s7-edge/how-to/4-28-t-mobile-935-firmware-t3597866/page10
I will not go in-depth about what this is but this relates to a network configuration. I will post a reference on this if you guys feel like checking out...
https://community.sprint.com/t5/Archives/Chameleon/td-p/654097
FAST & STABLE ROOT METHOD FOR THE G935U under T-Mobile // S7 EDGE
1 - Download & Flash Via Odin the latest Firmware provided on this post. Thanks to @justda
https://forum.xda-developers.com/tmobile-s7-edge/how-to/4-28-t-mobile-935-firmware-t3597866
------------ HERE COMES THE MOST IMPORTANT STEP ON THIS GUIDE ----------​
2 - Install Package Disabler Pro from OSPolice. Play Store link ...
https://play.google.com/store/apps/details?id=com.ospolice.packagedisablerpro&hl=es
3 - Open the application, activate Device Administrator, just hit next or ok or just follow through the setup and once the apps list loads up look for the system app with the name of: com.samsung.sprint.chameleon. Go ahead clear data and DISABLE it. After you are done disabling this system app, you are now safe and good to follow through the root method below.
4 - I suggest that you use the root.bat file provided by @Quickvic30 on this thread to root your device
https://forum.xda-developers.com/tmobile-s7-edge/how-to/heres-how-rooted-nougat-s7-edge-g935t-t3567502
IF YOU HAVE SUCCESSFULLY BOOTED UP YOUR DEVICE PAST THE SAMSUNG SCREEN WITHOUT ENDING UP IN BOOTLOOPS (Bootloops may occur within 30 seconds after booting up from the Samsung Screen) THATS IT, YOU ARE DONE!
### Post-Root Suggestions ###
Applications to Install:
Titanium Backup
Kernel Adiutor
L-Speed
SD Maid
THE FOLLOWING XML DEBLOAT PACKAGE IS FOR THOSE WHO ARE LOOKING INTO DISABLING THE MOST PACKAGES INCLUDING SOME STOCK APKS. PLEASE CAREFULLY GO OVER THE LIST ATTACHED AND JUST CONTINUE ON TO MAKE ANY MODIFICATIONS TO FIT YOUR NEEDS
### DEBLOATER FOR PACKAGE DISABLER PRO - SAFE TO DISABLE APPS & SYSTEM APPS [~1950 MB RAM FREE - SOMETIMES 2000 MB's] ###
Attached is the xml file for Package Disabler Pro that will free ~ 2 GB RAM on your device.

Since I don't see any mention of using the engineering kernel should I assume this method does not work for US models?

So basically you take qwewqa's discovery, make no mention of him, then pass it off as your own. Then copy and paste some steps from other people, and submit it as your work?

markmain2. 0 said:
Since I don't see any mention of using the engineering kernel should I assume this method does not work for US models?
Click to expand...
Click to collapse
As referred in the procedure section. The main and original root method goes to the forum thread linked above. As I briefly specified in the background info section, this is just a quick fix in performance and stability when applying root to this build.

tofu- said:
So basically you take qwewqa's discovery, make no mention of him, then pass it off as your own. Then copy and paste some steps from other people, and submit it as your work?
Click to expand...
Click to collapse
I didn't copy nor plagiarize any information from their respective owners. Credits are given, very briefly detailed information on the steps as to the main reason of this thread is just giving the list and proceed with the order of steps to successfully achieve root. The link that I attached in regards to the conflicting system app that where I noticed the issue with other models.
I didn't look into @qwewqa thread comment regarding this, and I apologize and edited to credit him on this finding.

The debloat list provided is extremely aggresive. It removes the stock gallery, stock calender, lock screen wallpaper, stock contacts, Bluetooth, and all google back up services.
Your list is great for the hardcore folks BUT you have to go back through the lost and re-enable the apps and clear the data then re disable them.
Sent from my SM-G935U using XDA Premium HD app

Brian,
Thanks for bringing it all together. I am currently rooted on T-Mobile QC1. I wanted to go to the U firmware wanted a tested way to root first.
Pat

Thank you kindly. Going to try this out right now

gonna give this a try, Any kernel tweak recommendations? how smooth/fast is it or does it lag like a bunch

any fix for the finger print sensor?

Im think the eng is conflicting with a app killing the fingerprint sensor

patcal said:
Brian,
Thanks for bringing it all together. I am currently rooted on T-Mobile QC1. I wanted to go to the U firmware wanted a tested way to root first.
Pat
Click to expand...
Click to collapse
Hey Pat,
In fact there is a way to root the U Firmware and achieve functionality and administration. All thanks to their devs for their work

black96ss said:
gonna give this a try, Any kernel tweak recommendations? how smooth/fast is it or does it lag like a bunch
Click to expand...
Click to collapse
As a matter of fact, the root.bat from @Quickvic30 does all the jobs needed. I strongly suggest running his method. No L Speed, no Kernel Adiutor. Just Titanium Backup to freeze/uninstall bloatware.

black96ss said:
gonna give this a try, Any kernel tweak recommendations? how smooth/fast is it or does it lag like a bunch
Click to expand...
Click to collapse
black96ss said:
any fix for the finger print sensor?
Click to expand...
Click to collapse
Hmmm...to be honest I didn't have any issues regarding the fingerprint sensor. Have you solved your issue by now?

Broken Fingerprint Sensor
purotijuana said:
Hmmm...to be honest I didn't have any issues regarding the fingerprint sensor. Have you solved your issue by now?
Click to expand...
Click to collapse
Yes, I also have the same problem. The fingerprint sensor has stopped working after flashing the Eng Bootloader.
Found the fix: Credits to qwewqa
Link

Dexolit said:
Yes, I also have the same problem. The fingerprint sensor has stopped working after flashing the Eng Bootloader.
Found the fix: Credits to qwewqa
Link
Click to expand...
Click to collapse
I tried to use this method but my phone won't let me change permissions. It pops up with a message that says "changing permissions was not successful. Please note that some file systems do not allow permission changes." Is there something special I need to do to enable permission changes?
Also I am using root browser to do this.

nickp22127 said:
I tried to use this method but my phone won't let me change permissions. It pops up with a message that says "changing permissions was not successful. Please note that some file systems do not allow permission changes." Is there something special I need to do to enable permission changes?
Also I am using root browser to do this.
Click to expand...
Click to collapse
Try another file browser. Root Explorer is what I have always used.

patcal said:
Try another file browser. Root Explorer is what I have always used.
Click to expand...
Click to collapse
Awesome man it worked! Thanks a lot. Root explorer seems pretty legit by the way. I've only ever used root browser.

nickp22127 said:
Awesome man it worked! Thanks a lot. Root explorer seems pretty legit by the way. I've only ever used root browser.
Click to expand...
Click to collapse
Glad it worked. I have been using Root Explorer for as long as I have been using & rooting android phones.

nickp22127 said:
I tried to use this method but my phone won't let me change permissions. It pops up with a message that says "changing permissions was not successful. Please note that some file systems do not allow permission changes." Is there something special I need to do to enable permission changes?
Also I am using root browser to do this.
Click to expand...
Click to collapse
I also had that problem too. Just extract the libs and overwrite them in /system/lib and /lib64, then change the permissions to rw-r--r--. Apparently, it only worked after overwriting the files.

Question Unable to edit build.prop (net.tethering.noprovisioning)

I've looked into the forums and haven't seen anyone ask about this, but ever since a update in January (I think) I've been unable to use my hotspot. I'm on an unlocked rooted phone with verizon as my serivce provider.
Normally I would just edit the build.prop, but lately I've been having issues since MagiskHide Props is a dead module. Does it still work for anyone else?
Am I missing a new feature?
I'm not that verse with how MagiskHide works, so I'll ask is there a way of changing / editing build.prop like the days of old?

rknee said:
I've looked into the forums and haven't seen anyone ask about this, but ever since a update in January (I think) I've been unable to use my hotspot. I'm on an unlocked rooted phone with verizon as my serivce provider.
Normally I would just edit the build.prop, but lately I've been having issues since MagiskHide Props is a dead module. Does it still work for anyone else?
Am I missing a new feature?
I'm not that verse with how MagiskHide works, so I'll ask is there a way of changing / editing build.prop like the days of old?
Click to expand...
Click to collapse
I had a similar issue on the Pixel 5. You should be able to turn the hotspot on while connected to WiFi. Turn Wifi off while leaving the hotspot on and see if it stays on. You shouldn't need to edit anything in the build.prop to get hotspot to work, but there does seem to be an elusive authentication issue.

V0latyle said:
I had a similar issue on the Pixel 5. You should be able to turn the hotspot on while connected to WiFi. Turn Wifi off while leaving the hotspot on and see if it stays on. You shouldn't need to edit anything in the build.prop to get hotspot to work, but there does seem to be an elusive authentication issue.
Click to expand...
Click to collapse
Gave it a try, but my hotspot immediately turns off as soon as I turn off wifi.
If I can figure out why the props command doesn't take. I've read some posts about people talking about "Settings version mismatch" when using props. I'll have to take a look at that thread and see if there are any new answers.
Thanks for the reply

rknee said:
is there a way of changing / editing build.prop like the days of old?
Click to expand...
Click to collapse
I haven't used this so can't comment on how well it works, but maybe it's something that will help your situation.
GitHub - HuskyDG/magic_overlayfs: Make system partition become read-write (it is also possible without Magisk)
Make system partition become read-write (it is also possible without Magisk) - GitHub - HuskyDG/magic_overlayfs: Make system partition become read-write (it is also possible without Magisk)
github.com

Lughnasadh said:
I haven't used this so can't comment on how well it works, but maybe it's something that will help your situation.
GitHub - HuskyDG/magic_overlayfs: Make system partition become read-write (it is also possible without Magisk)
Make system partition become read-write (it is also possible without Magisk) - GitHub - HuskyDG/magic_overlayfs: Make system partition become read-write (it is also possible without Magisk)
github.com
Click to expand...
Click to collapse
thanks for the resource, I'll take a look, as I'd like to learn more in depth of the inner workings.
I've found the issue, MagiskHide still works but for whatever reason the directory that I get started on when opening a terminal app is incorrect, so all that was needed was changing the directory ( /system/bin/ )
Thanks to anyone who took the time to look at this post, but my problem is now resolved

Great a file (no extension) in /data/adb/post-fs-data and put
resetprop prop value
So, "resetprop net.tethering.noprovisioning insert-value"
And reboot. Be sure to give 744 permission