[Mod][Systemless Root][Pixel/Pixel XL] TetherMod - Bypass provisioning checks. - Google Pixel XL Themes, Apps, and Mods

This guide presupposes that you have Supersu installed as systemless, and that you have access to adb.
This will bypass provisioning checks for builtin tether app. The modded apk should work with future updates without touching /system at all.
Installation
Method 1 - Manual install
Download the attached CarrierEntitlement apk.
If you have su.img su:
Code:
adb push CarrierEntitlement.apk /sdcard/CarrierEntitlement.apk
adb shell
su
mkdir /su/CarrierEntitlement
cp /sdcard/CarrierEntitlement.apk /su/CarrierEntitlement/CarrierEntitlement.apk
chmod 644 /su/CarrierEntitlement/CarrierEntitlement.apk
echo "mount -o bind /su/CarrierEntitlement/CarrierEntitlement.apk /system/priv-app/CarrierEntitlement/CarrierEntitlement.apk" > /su/su.d/05TetherMod
chmod +x /su/su.d/05TetherMod
reboot
If you have sbin su (Android 8.0+)
Code:
adb push CarrierEntitlement.apk /sdcard/CarrierEntitlement.apk
adb shell
su
mkdir /sbin/supersu/CarrierEntitlement
cp /sdcard/CarrierEntitlement.apk /sbin/supersu/CarrierEntitlement/CarrierEntitlement.apk
chmod 644 /sbin/supersu/CarrierEntitlement/CarrierEntitlement.apk
echo "mount -o bind /sbin/supersu/CarrierEntitlement/CarrierEntitlement.apk /system/priv-app/CarrierEntitlement/CarrierEntitlement.apk" > /sbin/supersu/su.d/05TetherMod
chmod +x /sbin/supersu/su.d/05TetherMod
reboot
Method 2 - Flashable Zip (su.img only)
Code:
1. Download attached zip.
2. Flash in TWRP (Last tested in alpha 2)
Information
This mod is accomplished by replacing the following function:
Code:
.method public static getCarrierEntitlement(Landroid/content/Context;)Lcom/google/android/carrierentitlement/CarrierEntitlement;
.registers 2
.param p0, "context" # Landroid/content/Context;
.prologue
.line 56
const/4 v0, 0x0
return-object v0
.end method
NOTE: Post install
You may need to edit your APNs to get tethering working for your carrier.
On sprint, where editing APNs is disabled, the fix is here: Sprint Fix
Be sure to thank @Builtfordtough1 for all his help in diagnosing the issue at this post: The Solution!
Be sure to thank sb1893 for sbin su instructions.

Worked Perfectly
This worked perfectly. Fantastic job!

So I am on stock with unlocked bootloader, twrp installed, and rooted with SuperSU. Because this is an apk file, do i just download onto the phone and install as I would with any other .apk file?

coolhandz said:
So I am on stock with unlocked bootloader, twrp installed, and rooted with SuperSU. Because this is an apk file, do i just download onto the phone and install as I would with any other .apk file?
Click to expand...
Click to collapse
The directions clearly state in adb speak that you need to create a directory for the file. Move to said directory, change permissions, etc etc. Nothing about installing via the apk.

pcriz said:
The directions clearly state in adb speak that you need to create a directory for the file. Move to said directory, change permissions, etc etc. Nothing about installing via the apk.
Click to expand...
Click to collapse
well, i can follow basic commands in minimal adb & fastboot. I think this may be above me unless there is an idiots' guide.

coolhandz said:
well, i can follow basic commands in minimal adb & fastboot. I think this may be above me unless there is an idiots' guide.
Click to expand...
Click to collapse
Do you have access to adb? They are pretty straight forward. May need to view them on the website but if you are using an app it may throw the word wrap off and make the commands seem confusing. The directions are pretty word for word.

pcriz said:
Do you have access to adb? They are pretty straight forward. May need to view them actually on the website but if you are using an app it may throw the word wrap off and make the commands seem confusing. The directs are pretty word for word.
Click to expand...
Click to collapse
If by adb you mean minimal adb & fastboot, then yes I have access and I could probably brave it.

coolhandz said:
If by adb you mean minimal adb & fastboot, then yes I have access and I could probably brave it.
Click to expand...
Click to collapse
I wouldn't suggest doing it how I did it but I downloaded the file to my phone. I created the directory using a root enabled file browser (see mkdir command {make directory}). I even used the file properties option in solid explorer to change the permissions (see chmod 644). Every other command I did on the phone from a terminal emulator. Just had to ignore the adb shell command because I am actually doing them on the device and not through a shell on my computer.

pcriz said:
I wouldn't suggest doing it how I did it but I downloaded the file to my phone. I created the directory using a root enabled file browser (see mkdir command {make directory}). I even used the file properties option in solid explorer to change the permissions (see chmod 644). Every other command I did on the phone from a terminal emulator. Just had to ignore the adb shell command because I am actually doing them on the device and not through a shell on my computer.
Click to expand...
Click to collapse
yeah, all that is definitely outside of my comfort zone, but thank you for the info.

Can you normally update your device with OTA-updates like a un-rooted device, without flashfire or connect to your computer?

Is there an advantage to doing this over adding "net.tethering.noprovisioning=true" to the build.prop file?

airmaxx23 said:
Is there an advantage to doing this over adding "net.tethering.noprovisioning=true" to the build.prop file?
Click to expand...
Click to collapse
This mod is systemless, and should survive OTAs. That mod changes the build.prop on the system partition, which could prevent taking OTAs.
njeri123 said:
Can you normally update your device with OTA-updates like a un-rooted device, without flashfire or connect to your computer?
Click to expand...
Click to collapse
Any modification to the boot image *should* prevent OTAs from working at all. However, you can flash back to stock boot images, and take OTAs as long as you have not modified /system, which this mod does not do.
Furthermore, as long as you don't wipe /data/ this mod will live in su.img and survive when you flash newer system software.

Fenny said:
This mod is systemless, and should survive OTAs. That mod changes the build.prop on the system partition, which could prevent taking OTAs.
Any modification to the boot image *should* prevent OTAs from working at all. However, you can flash back to stock boot images, and take OTAs as long as you have not modified /system, which this mod does not do.
Furthermore, as long as you don't wipe /data/ this mod will live in su.img and survive when you flash newer system software.
Click to expand...
Click to collapse
Thanks for the explanation, I removed the build.prop line and used this method and it's working fine. Thank you.

@Fenny
Thank you so much for putting this into a .zip file. It is greatly appreciated!

is there a non root method to bypass the checks? i dont plan on unlocking or rooting since i use android pay...

ddarvish said:
is there a non root method to bypass the checks? i dont plan on unlocking or rooting since i use android pay...
Click to expand...
Click to collapse
I also use Android pay, so I have two boot images ready to fastboot or flash. I have a boot image with root, and a boot image without root running a kernel that hides the bootloader unlocked flag.
So, the way I handle this, I flash the unrooted (bootloader flag hidden) image as my daily driver kernel, this passes safetynet, and allows me to use Android pay.
I make a backup of that boot image. Then, I install TWRP, my custom kernel, and SuperSU. I make a backup of that image as well.
So I have two backed up boot images:
rooted.img
HideBLUnlock.img
I flash HideBLUnlock.img to boot a, and boot b, safetynet passes.
Whenever I need to tether I have my computer with me, so I "fastboot boot rooted.img" which leaves me rooted until my next reboot.
Depending on your usage you might want to reverse that.
All my mods get stored in su.img, so switching out the boot images is all I need to have the best of both worlds.

Is it possible to fastboot boot twrp and flash the zip without being rooted or having twrp actually installed? O unlocked my bootloader but that's been it

Ocelot13 said:
Is it possible to fastboot boot twrp and flash the zip without being rooted or having twrp actually installed? O unlocked my bootloader but that's been it
Click to expand...
Click to collapse
You can use the fastboot twrp image to install this mod but you MUST have SuperSu. I have basic validation to check that in my update.zip. If you don't have a su.img in /cache or /data, this mod cannot be installed.

Flashed via TWRP and now i finally have a fully functioning hotspot!!

Fenny said:
I also use Android pay, so I have two boot images ready to fastboot or flash. I have a boot image with root, and a boot image without root running a kernel that hides the bootloader unlocked flag.
So, the way I handle this, I flash the unrooted (bootloader flag hidden) image as my daily driver kernel, this passes safetynet, and allows me to use Android pay.
I make a backup of that boot image. Then, I install TWRP, my custom kernel, and SuperSU. I make a backup of that image as well.
So I have two backed up boot images:
rooted.img
HideBLUnlock.img
I flash HideBLUnlock.img to boot a, and boot b, safetynet passes.
Whenever I need to tether I have my computer with me, so I "fastboot boot rooted.img" which leaves me rooted until my next reboot.
Depending on your usage you might want to reverse that.
All my mods get stored in su.img, so switching out the boot images is all I need to have the best of both worlds.
Click to expand...
Click to collapse
This is facinating, do you ever think where we can use boot a and boot b in a multiboot like fashion so that when you turn on the device you can choose what to boot?

Related

[HOW-TO] [GSM & CDMA] How to root without unlocking bootloader (for ITL41D to JRO03O)

[HOW-TO] [GSM & CDMA] How to root without unlocking bootloader (for ITL41D to JRO03O)
As of Oct 10, 2012: Google has patched this vulnerability starting with JRO03U. That is to say, this works on versions of ICS and JB from ITL41D to JRO03O inclusive. It will not work for JRO03U or newer. (My previous guide found here only worked on Android versions 4.0.1 and 4.0.2, i.e., ITL41D/F and ICL53F.
Once you have root, you can use segv11's BootUnlocker app to unlock your bootloader without wiping anything. Easy as pie!
Disclaimer: I take no credit for this exploit or the implementation of it. All credit goes to Bin4ry and his team. I just isolated the parts required for the GNex, modified it slightly and eliminated the script.
So, it looks like Bin4ry (with the help of a couple of others) has managed to find a way to exploit a timing difference in the "adb restore" command. See source here. (Although this may be old news to some, I hadn't seen it before a few days ago.) This is more for informational purposes, as having a Nexus device, we are able to backup our data, unlock the bootloader and restore the backup, so this is guide is not really that useful for most, but you still have those users who are scared to unlock their bootloader. It is useful however, for those with a broken power button, as it allows them to unlock their bootloader without the power button.
How this works
The way this works is as follows: the "adb restore" command needs to be able to write to /data to restore a backup. Because of this, we can find a way to write something to /data while this is being done. Now, Android parses a file called /data/local.prop on boot. If the following line exists in local.prop, it will boot your device in emulator mode with root shell access: ro.kernel.qemu=1. So, if we can place a file called local.prop with the aforementioned line in /data, once your device boots, it will boot in emulator mode and the shell user has root access, so we now can mount the system partition as r/w.
So what does this all mean:
You can now root any version of ICS and JB released to-date without having to unlock your bootloader (and without losing your data).
Moreover, you should now be able to root your device even if your hardware buttons are not working.
Additionally, this allows those who have not received an OTA update and want to apply it without having an unlocked bootloader or root to do so by copying the OTA update to /cache from /sdcard.
Notes:
1) Please read the entire post before attempting this.
2) This does not wipe any of your data, but I take no responsibility if something happens and you lose your data. Maybe consider doing a backup as per this thread before attempting this.
3) This assumes that you have USB Debugging enable on your device (Settings > Developer Options > Enable USB Debugging) and the drivers for your device installed on your computer. For the drivers, I would recommend you remove all old drivers and install these. If you don't know how to install them, or are having issues, look here.
4) This obviously needs to be done over ADB, as you cannot run adb in a terminal emulator on-device. If you do not have ADB, I've attached it in the zip (Windows and Linux versions). Unzip all files.
Step-by-step:
1) Download the attached files to your computer and unzip them;
2) Open a command prompt in that same directory;
3) Copy the root files to your device:
adb push su /data/local/tmp/su
adb push Superuser.apk /data/local/tmp/Superuser.apk
4) Restore the fake "backup": adb restore fakebackup.ab Note: do not click restore on your device. Just enter the command into the command prompt on your PC and press the enter key.
5) Run the "exploit": adb shell "while ! ln -s /data/local.prop /data/data/com.android.settings/a/file99; do :; done" Note: when you enter this command, you should see your adb window flooded with errors -- this is what is supposed to happen.
6) Now that the "exploit" is running, click restore on your device.
7) Once it finishes, reboot your device: adb reboot Note: Do not try and use your device when it reboots. Running this exploit will reboot your device into emulator mode, so it will be laggy and the screen will flicker -- this is normal.
8) Once it is rebooted, open a shell: adb shell
Note: Once you do step 8, your should have a root shell, i.e., your prompt should be #, not $. If not, it did not work. Start again from step 4. (It may take a few tries for it to work. Thanks segv11.)
Now we can copy su and Superuser.apk to the correct spots to give us root.
9) Mount the system partition as r/w: mount -o remount,rw -t ext4 /dev/block/mmcblk0p1 /system
10) Copy su to /system: cat /data/local/tmp/su > /system/bin/su
11) Change permissions on su: chmod 06755 /system/bin/su
12) Symlink su to /xbin/su: ln -s /system/bin/su /system/xbin/su
13) Copy Superuser.apk to /system: cat /data/local/tmp/Superuser.apk > /system/app/Superuser.apk
14) Change permissions on Superuser.apk: chmod 0644 /system/app/Superuser.apk
15) Delete the file that the exploit created: rm /data/local.prop
16) Exit the ADB shell: exit (May have to type exit twice to get back to your command prompt.)
17) Type the following (not sure if this is needed for the GNex, but it shouldn't matter): adb shell "sync; sync; sync;"
18) Reboot: adb reboot
19) Done. You now should have root without having to unlock your bootloader. If you want to unlock now, you can without wiping anything. See segv11's app linked at the beginning of this post.
Note: If you still do not have root access after doing these steps, redo them and add this step between 10 and 11:
10b) Change the owner of su: chown 0.0 /system/bin/su (Thanks maxrfon.)
I've done all. It installs supersuser app but the phone is not really rooted and apps that requires it doesn't work
Lorenzo_9 said:
I've done all. It installs supersuser app but the phone is not really rooted and apps that requires it doesn't work
Click to expand...
Click to collapse
Did you try opening the Superuser app?
What happens when you open an app that requires root? Do you get the request for su access?
You can open the app but whith apps that requires root there are no requestes and they don't... Even using root checker you see that you're not rooted
Lorenzo_9 said:
You can open the app but whith apps that requires root there are no requestes and they don't... Even using root checker you see that you're not rooted
Click to expand...
Click to collapse
Re-run the entire procedure again (including pushing the su and Superuser.apk files). When I had done it, I used the latest version of su and Superuser.apk, but when I uploaded the files in the attachment in post #1, I used the files that Bin4ry had in his package, which I assume are older. Regardless, re-download the attachment in the first post and try it again.
efrant said:
Re-run the entire procedure again (including pushing the su and Superuser.apk files). When I had done it, I used the latest version of su and Superuser.apk, but when I uploaded the files in the attachment in post #1, I used the files that Bin4ry had in his package, which I assume are older. Regardless, re-download the attachment in the first post and try it again.
Click to expand...
Click to collapse
Ok I'll do it and then I'll report you what happens. So now have you updated su and superuser.apk?
Lorenzo_9 said:
Ok I'll do it and then I'll report you what happens. So now have you updated su and superuser.apk?
Click to expand...
Click to collapse
Yes, I put the latest versions in the zip in the first post.
I can confirm that this works, and also that step 10b was not needed for me. This is the first time I have not used a toolkit so if I can do it, anyone can.
Running a Verizon Galaxy Nexus, this allowed me to update to the leaked Jelly Bean OTA with a locked bootloader. I first flashed stock 4.0.4 and locked the bootloader. I then used the exploit to gain root access, allowing me to apply IMM76Q and JRO03O OTA updates via stock recovery. (Rebooting between updates.) Thank you for creating a guide that this newb could easily understand and follow.
serty4011 said:
I can confirm that this works, and also that step 10b was not needed for me. This is the first time I have not used a toolkit so if I can do it, anyone can.
Running a Verizon Galaxy Nexus, this allowed me to update to the leaked Jelly Bean OTA with a locked bootloader. I first flashed stock 4.0.4 and locked the bootloader. I then used the exploit to gain root access, allowing me to apply IMM76Q and JRO03O OTA updates via stock recovery. (Rebooting between updates.) Thank you for creating a guide that this newb could easily understand and follow.
Click to expand...
Click to collapse
Thanks for confirming that step was not needed.
Thanks!
Bookmarked for future reference :good:
does it work on nexus 7 ?
dacc said:
does it work on nexus 7 ?
Click to expand...
Click to collapse
Yes, it should.
thans for quick response
Works fine for my GNex, big thanks! How about putting it into a script for non-advanced users here?
wictor1992 said:
Works fine for my GNex, big thanks! How about putting it into a script for non-advanced users here?
Click to expand...
Click to collapse
Glad you got it working!
As for putting it into a script, I could but I'd rather not. As with most of the guides that I have written up, I purposely do not put things into a script so that people would actually go through all the steps and, by doing so, maybe get an understanding of what they are actually doing, and hopefully learn something in the process. If I would have packaged it up into a script, a lot of the less experienced users would not even try to go through the steps -- they would just use the script, and no one learns anything yet again. See here for some discussion on one-click scripts. Granted, blindly following a step-by-step is not much better, but I have tried to put comments and explanations throughout to facilitate learning. It's about the journey...
P.S.: I would appreciate it if no one else posts a script in this thread.
efrant said:
P.S.: I would appreciate it if no one else posts a script in this thread.
Click to expand...
Click to collapse
can i make a script that just puts in big text "STOP USING TOOLKITS AND 1 CLICKS"
Zepius said:
can i make a script that just puts in big text "STOP USING TOOLKITS AND 1 CLICKS"
Click to expand...
Click to collapse
LOL! Yes, sure, that's one script I don't mind being posted. LOL!
Heh, fair enough. I think I'm learning a bit about adb
One question: I can't replace system APKs by installing them, it tells me that there is a signature conflict. How can I fix that? I thought it shouldn't happen after rooting. (I'm trying to install the "international" velvet.apk).
wictor1992 said:
Heh, fair enough. I think I'm learning a bit about adb
One question: I can't replace system APKs by installing them, it tells me that there is a signature conflict. How can I fix that? I thought it shouldn't happen after rooting. (I'm trying to install the "international" velvet.apk).
Click to expand...
Click to collapse
Let's try to keep this thread on-topic please.
But to answer your question, don't install the apk. Using a file explorer that has root access, copy it to /system/app (after making sure that system is r/w) and make sure the permissions are set to match the other apks in that directory.
when running adb after running the command where i tell it to restore fake restore and then while the "exploit" is running ikeep getting , in cmd, link failed, no such file or directory, and it just keep doing that. is this normal or did i do something wrong.
efrant said:
Let's try to keep this thread on-topic please.
But to answer your question, don't install the apk. Using a file explorer that has root access, copy it to /system/app (after making sure that system is r/w) and make sure the permissions are set to match the other apks in that directory.
Click to expand...
Click to collapse

Rooting Hell Since 4.2.1

So I usually use the toolkit to root, in fact I have been for many versions now.
However with the installation of 4.2.1 I haven't been able to root at all. I use the toolkit in the same way but it simply doesn't root the phone.
So today I tried the manual way. I downloaded and installed SDK tools from google navigated to the adb folder and went through the commands. Everything seemed to go okay apart from when I typed adb shell chmod 06755 /system/bin/su. The command window did nothing.
I carried on and typed adb shell chmod 06755 /system/app/Superuser.apk, when it said "bad command" or something similar.
Rebooted the phone, no root... still.
However the Superuser app is there. So:
1) How do I delete the superuser app, bearing in mind it has system permissions. I'd like to simply start again.
2) I don't have CW recovery installed and would prefer not to bother with it if I can.
3) Just to confirm, when I root the phone, does that allow me to delete files in the /system/app folder?
4) Following this guide on rooting manually. Is that all alright?
5) In a couple of sentences, can someone explain rooting to me? From what I understood, rooting simply opens up the phone to allow access to everywhere, where you can copy and delete files, or apks.
6) If 5 is true, when following the rooting guide (4), which command am I actually telling the system to run as root? Is it simply the "root" command?
7) If 6 is true, how come when I re-boot, the phone won't let me delete things from the system/app folder?
Thanks for any help.
1) stop using a toolkit, and no you didnt root the manual way.
2) download this: http://forum.xda-developers.com/showthread.php?t=1538053 - its supersu, superuser is unreliable on 4.2+
3) fastboot flash a recovery
4) flash the supersu.zip
5) done.
Sorry, I should have explained the Su app is SuperSU.
Just gave it another go using a manual toolkit but still no root access. I also now have an su.apk, superuser.apk (SuperSU) and a su file. Need to delete them all.
What do you mean by "fastboot flash a recovery"? You mean flash a new recovery centre like CW?
Don't these superuser apps just manage app permissions? They don't actually enable the root access do they?
Thanks
anotherxdauser said:
Sorry, I should have explained the Su app is SuperSU.
Just gave it another go using a manual toolkit but still no root access. I also now have an su.apk, superuser.apk (SuperSU) and a su file. Need to delete them all.
What do you mean by "fastboot flash a recovery"? You mean flash a new recovery centre like CW?
Thanks
Click to expand...
Click to collapse
follow this: http://forum.xda-developers.com/showthread.php?t=1529058
Quick Q...
If I flash a 4.2.1 system.img to the phone, it will replace what exactly?
I'm thinking this might be a way to get rid of the root apps which are protected and allow me to update to 4.2.2, THEN look at manually rooting.
anotherxdauser said:
Quick Q...
If I flash a 4.2.1 system.img to the phone, it will replace what exactly?
I'm thinking this might be a way to get rid of the root apps which are protected and allow me to update to 4.2.2, THEN look at manually rooting.
Click to expand...
Click to collapse
it replaces anything in /system... basically the OS.

[MOD][HOW TO]Make your favorite kernel adbd insecure to run ADB as root on /system

Note: Found out there is one small problem with this mode - "adb logcat" is not working. As a workaround run "adb shell su -c logcat"
The Problem:
I am a heavy ADB user (QtADB) and was having problems getting it to mount /system rw and pushing/editing files in real time. Had no problems doing all this by mounting /system in recovery but rebooting the phone just to make some system files changes is kind of inconvenient. So I did some research and found this:
HEXcube said:
The real reason behind adb root or insecure adb is the adb daemon in the device running at root permissions. In pre-Android 4.1 versions, this is usually decided by some initialisation script(like init.rc) at boot time. The script checks for value in default.prop,local.propand other environment variables.
If it finds build.prop,default.prop or local.prop property file with ro.secure=0 adbd is allowed to run as root. You'll get adb root and hence will be able to do commands like adb remount,adb root and adb shell's prompt'll be # by default. The user may be displayed as [email protected] or [email protected] adb GUIs like Android Commander and QtADB will get to work in Root mode.
But,if it's ro.secure=1, adb daemon is made to work in secure mode, and adb won't change to root mode on issuing adb root command. However, if su binary is present in $PATH, u can still call su command from adb shell. But, it's not enough for Android Commander to get Root Access. It is possible to attain adb root through any one of the following methods:
1.For CyanoGenMod based ROMs there is an option in Settings->Developer Settings->Root access to control root access. Choose ADB only or Apps and ADB in options to get adb root.
2.Else use adbd Insecure app by chainfire if you have a rooted device. This is useful, especially for Android 4.1+ devices.
3.Or, you may manually edit default.prop to set it's value to 0, but original default.prop will be restored from boot partition everytime you reboot(this is the reason why adb Insecure cannot permanently do adb root, though there is an option to repeat the rooting procedure everytime the device boots). This method is called temporary adb root. On pre-Android 4.0 ROMs default.prop file was located in / directory. I read that from Android 4.x this file is in ramdisk and so more difficult to edit. But Android 4.0 has local.prop which is easier to modify than default.prop( See method 5)
4.For permanent adb root, you'll have to extract boot.img, change default.prop, repack and then flash it back to device.
5. In Android 4.0 there's local.prop file in /data partition. Setting ro.secure=0 in this file will do adb root permanently. Else you can set another property ro.kernel.qemu=1 in the same file. But, this value makes the system think that it is running in an android emulator. Many exploits and root methods set this property temporarily to gain root. But, it may cause side effects if used permanently. Setting ro.secure=0 is recommended. Do this command in terminal app or adb shell:
echo ro.secure=0 >/data/local.prop
or you can manually copy a local.prop file with ro.secure=0 as it's content to /data.
6.Note that method 3,4 and 5 won't work in Android 4.0 Jelly Bean onwards. According to Dan Rosenburg(drjbliss in XDA),the researcher who discovered adb root emulator exploit and many other exploits, Jelly Bean doesn't parse any property files to set the ownership of adb daemon. The stock adbd will have to be replaced with an insecure one to gain adb root. But still,as adbd is located in /sbin whose contents are reloaded everytime on reboot from boot.img, it won't be permanent.
7. For permanent adb root, you may flash an insecure boot.img(one that contains and insecure adbd)
8. If you're really desperate and can't get adb root to work with any of the above methods use an exploit. Most of the adb based rooting methods utilise some exploit to make the adb daemon run as root. By studying the exploit and implementing it you could gain adb root atleast temporarily.I'm not recommending this method but as a last resort you could try them.
Acknowledgements: Thanks to Dan Rosenberg for explaining the reasons behind adb root, especially the one in Jelly Bean.
Click to expand...
Click to collapse
Original thread: Can't get ADB Root Access in certain ROMs?
So I desided to modify my favorite kernel img and give it a try. I used Imoseyon's leanKernel but it should work with any kernel.
How To:
1. Get Android Image Kitchen and extract it to your PC;
2. Open your_favorite_kernel.zip with 7zip and extract boot.img file to Android Image Kitchen folder;
3. Drag and Drop boot.img over unpackimg.bat. Kernel is unpacked and you will see 2 new folders - ramdisk and split_img;
4. Go to ramdisk folder and open default.prop file with text editor. This probably is not necessary but just in case change ro.secure and ro.adb.secure to 0 (zero):
Code:
ro.secure=0
ro.adb.secure=0
5. Get Chainfire's adbd Insecure v1.30, open it with 7zip, in assets folder you will see 3 .png files. Extract adbd.17.png to ramdisk\sbin folder;
6. Delete original kernel adbd file and rename adbd.17.png to adbd;
7. Go back to Android Image Kitchen folder and run repackimg.bat by just click on it. This will repack the modified kernel to image-new.img file ready for flashing;
8. Rename image-new.img to boot.img and replace the original one in your_favorite_kernel.zip by Drag and Drop in 7zip window;
9. Close 7zip, copy modified your_favorite_kernel.zip to /sdcard and flash it in recovery.
10. Enjoy ADB full root access for /system;
Warnings:
I can't guarantee 100% success with this mod. I did this only with leanKernel and it works great, Haven't tried any other kernels so I am note sure how all this will end up. IT CAN SOFT BRICK YOUR PHONE!!! Keep a copy of the original kernel on your /sdcard!!!
Doing this while trying to find the correct tools for proper repack of the modified kernel sometime I was ending up with the phone not booting to Android, goes straight to download mode. Don't panic... Just remove battery, place it back, hold Volume Up + Home + Power buttons booting to recovery. Flash the original kernel and you are back all good.
The usual stuff:
I AM NOT RESPONSIBLE FOR ANYTHING ... bla-bla-bla...
All the credits goes for the developers created the great tools used for this mod.
If you think it's useful fill free to say THEM and me thanks.
@nijel8
Thanks for sharing this. I will test this out on my device. If successful I would like to share this over in the One SV forums.
I never even considered this idea smh lol.
Edit: confirmed working
Thanks so much for sharing this. I too use adb a lot and need an insecure kernel.
Success. Nexus 5 and I changed Franco kernel to insecure.
Franco kernels used to be insecure but none thus far have been on the N5. Any reason behind this?
Fuzzy13 said:
Thanks so much for sharing this. I too use adb a lot and need an insecure kernel.
Success. Nexus 5 and I changed Franco kernel to insecure.
Franco kernels used to be insecure but none thus far have been on the N5. Any reason behind this?
Click to expand...
Click to collapse
My guess is devs play it safe so average Joe don't mess with /system... ha-ha
btw is "adb logcat" working for you?
Only problem with the adbd from chainfires ADB Insecure is that it breaks adb wireless,any solution ?
nijel8 said:
Note: Found out there is one small problem with this mode - "adb logcat" is not working. As a workaround run "adb shell su -c logcat"
The Problem:
I am a heavy ADB user (QtADB) and was having problems getting it to mount /system rw and pushing/editing files in real time. Had no problems doing all this by mounting /system in recovery but rebooting the phone just to make some system files changes is kind of inconvenient. So I did some research and found this:
Original thread: Can't get ADB Root Access in certain ROMs?
So I desided to modify my favorite kernel img and give it a try. I used Imoseyon's leanKernel but it should work with any kernel.
How To:
1. Get Android Image Kitchen and extract it to your PC;
2. Open your_favorite_kernel.zip with 7zip and extract boot.img file to Android Image Kitchen folder;
3. Drag and Drop boot.img over unpackimg.bat. Kernel is unpacked and you will see 2 new folders - ramdisk and split_img;
4. Go to ramdisk folder and open default.prop file with text editor. This probably is not necessary but just in case change ro.secure and ro.adb.secure to 0 (zero):
Code:
ro.secure=0
ro.adb.secure=0
5. Get Chainfire's adbd Insecure v1.30, open it with 7zip, in assets folder you will see 3 .png files. Extract adbd.17.png to ramdisk\sbin folder;
6. Delete original kernel adbd file and rename adbd.17.png to adbd;
7. Go back to Android Image Kitchen folder and run repackimg.bat by just click on it. This will repack the modified kernel to image-new.img file ready for flashing;
8. Rename image-new.img to boot.img and replace the original one in your_favorite_kernel.zip by Drag and Drop in 7zip window;
9. Close 7zip, copy modified your_favorite_kernel.zip to /sdcard and flash it in recovery.
10. Enjoy ADB full root access for /system;
Warnings:
I can't guarantee 100% success with this mod. I did this only with leanKernel and it works great, Haven't tried any other kernels so I am note sure how all this will end up. IT CAN SOFT BRICK YOUR PHONE!!! Keep a copy of the original kernel on your /sdcard!!!
Doing this while trying to find the correct tools for proper repack of the modified kernel sometime I was ending up with the phone not booting to Android, goes straight to download mode. Don't panic... Just remove battery, place it back, hold Volume Up + Home + Power buttons booting to recovery. Flash the original kernel and you are back all good.
The usual stuff:
I AM NOT RESPONSIBLE FOR ANYTHING ... bla-bla-bla...
All the credits goes for the developers created the great tools used for this mod.
If you think it's useful fill free to say THEM and me thanks.
Click to expand...
Click to collapse
Some time ago I 've tried to do this for a Nexus6, running Marshmallow.
Android has tighten up security, so I got bootloops.
Anyone has managed to do this?
Thank you!
nijel8 said:
Note: Found out there is one small problem with this mode - "adb logcat" is not working. As a workaround run "adb shell su -c logcat"
The Problem:
I am a heavy ADB user (QtADB) and was having problems getting it to mount /system rw and pushing/editing files in real time. Had no problems doing all this by mounting /system in recovery but rebooting the phone just to make some system files changes is kind of inconvenient. So I did some research and found this:
Original thread: Can't get ADB Root Access in certain ROMs?
So I desided to modify my favorite kernel img and give it a try. I used Imoseyon's leanKernel but it should work with any kernel.
How To:
1. Get Android Image Kitchen and extract it to your PC;
2. Open your_favorite_kernel.zip with 7zip and extract boot.img file to Android Image Kitchen folder;
3. Drag and Drop boot.img over unpackimg.bat. Kernel is unpacked and you will see 2 new folders - ramdisk and split_img;
4. Go to ramdisk folder and open default.prop file with text editor. This probably is not necessary but just in case change ro.secure and ro.adb.secure to 0 (zero):
Code:
ro.secure=0
ro.adb.secure=0
5. Get Chainfire's adbd Insecure v1.30, open it with 7zip, in assets folder you will see 3 .png files. Extract adbd.17.png to ramdisk\sbin folder;
6. Delete original kernel adbd file and rename adbd.17.png to adbd;
7. Go back to Android Image Kitchen folder and run repackimg.bat by just click on it. This will repack the modified kernel to image-new.img file ready for flashing;
8. Rename image-new.img to boot.img and replace the original one in your_favorite_kernel.zip by Drag and Drop in 7zip window;
9. Close 7zip, copy modified your_favorite_kernel.zip to /sdcard and flash it in recovery.
10. Enjoy ADB full root access for /system;
Warnings:
I can't guarantee 100% success with this mod. I did this only with leanKernel and it works great, Haven't tried any other kernels so I am note sure how all this will end up. IT CAN SOFT BRICK YOUR PHONE!!! Keep a copy of the original kernel on your /sdcard!!!
Doing this while trying to find the correct tools for proper repack of the modified kernel sometime I was ending up with the phone not booting to Android, goes straight to download mode. Don't panic... Just remove battery, place it back, hold Volume Up + Home + Power buttons booting to recovery. Flash the original kernel and you are back all good.
The usual stuff:
I AM NOT RESPONSIBLE FOR ANYTHING ... bla-bla-bla...
All the credits goes for the developers created the great tools used for this mod.
If you think it's useful fill free to say THEM and me thanks.
Click to expand...
Click to collapse
Can this work with Note 3 N900 (exynos kernel) sir? Or just only for snapdragon chipsrt kernel? Thanks sir!
does this work on locked bootloader devices?
a custom kernel exists for my devices (G928A) with AdB Insecure , but its got a few qwirks that need worked out ( that require fully rooting the device )
all im looking for is insecure Adb, ( which I have tried to change ro.secure=0 and adb.secure=0 both with Echo commands in shell) for temporary adb root on the device
how did ManIT make his custom kernel undetectable/passable by the bootloader but with modifications?
if this will work ... then I will just edit an image pulled from the devices current boot.img and do the same adb insecure edit to the ramdisk.. to update the root flash kernel... shes a bit dated.... and there isn't one for marshmallow specific one yet.
I was also reading about a filler file due to block sizing when repacking the image ... so I created a copy file and edited the contents till it zipped back to within 1kb of data... will this be detected and flagged at boot?
help please
Great tutorial.
I did it by following the steps in your post.
Thank you for clear and precise explanation.
Anybody have a pre-patched / adb root enabled adbd at hand (10.0.36 or higher - current is 10.0.41 I think)?

help! pushing adaway hosts file

Has anyone been able to do this yet? I don't feel like rooting anymore since all I use root for is to use AdAway and getting OTA updates is just a PITA with having to RUU, restore all my stuff, just takes forever.
Apparently you can adb push a modded hosts file in TWRP and I've done so successfully, but everytime I reboot phone it reverts back to the stock hosts file (1 KB) and none of my changes are made.
I'm not pushing to the wrong place. I can do a adb pull immediately after and it retrieves the modified hosts file I want, it just doesn't stay that way after I reboot.
The process I'm doing:
Boot into TWRP
ADB pull stock hosts file
ADB push modded hosts file
CHMOD 0644 using TWRP file manager
Reboot
Test in browser/apps
Doesn't work
Boot back into TWRP
ADB pull hosts file
It's reverted back to stock 1KB unmodified
Anyone with more experience pls chime in, would be greatly appreciated.
cauqazn said:
Has anyone been able to do this yet? I don't feel like rooting anymore since all I use root for is to use AdAway and getting OTA updates is just a PITA with having to RUU, restore all my stuff, just takes forever.
Apparently you can adb push a modded hosts file in TWRP and I've done so successfully, but everytime I reboot phone it reverts back to the stock hosts file (1 KB) and none of my changes are made.
I'm not pushing to the wrong place. I can do a adb pull immediately after and it retrieves the modified hosts file I want, it just doesn't stay that way after I reboot.
The process I'm doing:
Boot into TWRP
ADB pull stock hosts file
ADB push modded hosts file
CHMOD 0644 using TWRP file manager
Reboot
Test in browser/apps
Doesn't work
Boot back into TWRP
ADB pull hosts file
It's reverted back to stock 1KB unmodified
Anyone with more experience pls chime in, would be greatly appreciated.
Click to expand...
Click to collapse
Are you just unlocked?
Sent from my HTC6545LVW using Tapatalk
I am sure its possible via TWRP but you will have to mount system first otherwise you are just flashing into the TWRP system itself.
But the moment you modify /system/ (Even mounting it) your device will no longer accept OTA.
dottat said:
Are you just unlocked?
Sent from my HTC6545LVW using Tapatalk
Click to expand...
Click to collapse
Yes, unlocked only.
Electronic Punk said:
I am sure its possible via TWRP but you will have to mount system first otherwise you are just flashing into the TWRP system itself.
But the moment you modify /system/ (Even mounting it) your device will no longer accept OTA.
Click to expand...
Click to collapse
I see. I mounted system before doing all of that. Meh, I guess I'm just going to have to root.
I went down this same path but ended up rooting so I could run AdAway. Easy enough to restore stock system image and recovery once the OTA comes out. With luck that process won't disturb the encrypted /data partition.

[Guide] AdAway for systemless hosts file

About the only reason I root my phone is to install AdAway. I'd prefer to not modify the system partition to help make OTA's easier to get and to allow Android Pay to work. AdAway has a flashable .zip file that preps the hosts file to use the systemless root structure that comes along with SuperSU. Unfortunately, that script depends on being able to access the /data partition inside of TWRP which isn't going to happen any time soon on the HTC 10. Fortunately, it is easy for us to manually replicate what the flashable .zip is trying to do.
This isn't a detailed how-to, but more of a set of guidelines. Don't blame me if your phone explodes.
Root the phone with the latest SuperSU.
Download the AdAway_systemless_hosts_v2.zip file from the Unofficial AdAway thread.
Extract the files from inside the zip. We are only interested in two files in the support folder.
Connect the phone to your PC and turn on file transfer mode.
Copy "hosts" and "0000adaway.script" that you just extracted to the internal storage of your phone.
Use a program file Root Explorer to move "hosts" into /su/etc and move "0000adaway.script" into /su/su.d (this probably could have been done with ADB push, but I got permission errors when I tried it that way and I'm impatient and lazy).
Chmod 0755 /su/su.d/0000adaway.script (I used a root shell on the phone via ADB)
Install AdAway (I used the link in the Unofficial AdAway thread.)
Reboot the phone.
Run AdAway like normal. By default it should use /system/etc/hosts which is what you want.
If something doesn't work, figure out why and fix it. I'm happy to answer questions to the best of my ability.
AdAway works without problems here, with simple press activate button.
starbase64 said:
AdAway works without problems here, with simple press activate button.
Click to expand...
Click to collapse
Yup
Sent from my HTC 10 using Tapatalk
starbase64 said:
AdAway works without problems here, with simple press activate button.
Click to expand...
Click to collapse
Yes, but it modifies the /system partition unless you do the trick in OP. If I'm correct, you will have problems with OTA updates and Google Pay if you let AdAway directly modify the hosts file on /system.
Now that TWRP can access /data, can we just flash the zip?
goodtimes50 said:
Now that TWRP can access /data, can we just flash the zip?
Click to expand...
Click to collapse
Yes, you can. I downloaded that zip and apk from the Unofficial AdAway thread linked above. Booted into TWRP, flashed the newest betaSuperSU2.74-2-forceencrypt (not related to this, just so I'd be on the latest version), then the AdAway_systemless_hosts_v2.zip, rebooted and installed the apk and let it run. Rebooted. Showing hosts location as /system32/etc/hosts as the OP says is a good thing, and both files mentioned are in their correct places per Root Browser. [emoji106]
Sent from my HTC 10 using XDA-Developers mobile app
Sorry that it doesn't completely match the thread here but I think my question could fit in here anyway.
Do I suggest correctly that with systemless root, systemless AdAway and the stock recovery OTAs should be fully usable? Since there's no other modification to /system then.
bmwbasti said:
Sorry that it doesn't completely match the thread here but I think my question could fit in here anyway.
Do I suggest correctly that with systemless root, systemless AdAway and the stock recovery OTAs should be fully usable? Since there's no other modification to /system then.
Click to expand...
Click to collapse
I believe that is correct. There hasn't been a new OTA for my phone yet so I can't verify. However, when I do the check for new software it tells me no new updates (as opposed to the message about the files system being corrupt). I believe Android Pay should also work. I have it installed and added a new card, but I haven't tested making a purchase yet.
Thanks for the guide.
My device is rooted, but I didn't found su folder in anywhere when I use Root Explorer with root access, does anyone tell me how to get su folder and make AdAway work?
Fix for AdAway.
matif525 said:
Thanks for the guide.
My device is rooted, but I didn't found su folder in anywhere when I use Root Explorer with root access, does anyone tell me how to get su folder and make AdAway work?
Click to expand...
Click to collapse
Your device may use su, & still not have an su folder (at all) that is used for hosts file (ie systemless root). Just do this..
Download... Terminal emulator.
https://play.google.com/store/apps/details?id=jackpal.androidterm
Open terminal
Then enter these commands.. "Quote"
su
mount -orw,remount /system
rm /system/etc/hosts
ln -s /data/data/hosts /system/etc/hosts
mount -orw,remount /system
Now open AdAway go to preferences and select option to " Target hosts file"
Select /data/data/hosts
Enjoy..
If you still have ads in apps do this!!!
githyanki said:
Open the 3 dot menu in adaway, chose log DNS request. Enable TCP dump.
Open the app with ads, when ad loads, go back to adaway, and open log.
Long press any entries and chose black list.
Profit
Click to expand...
Click to collapse
All credit where credit is due. I just shared what I read else where.
Read here for more details..
https://github.com/AdAway/AdAway/issues/770
&
http://forum.xda-developers.com/showthread.php?t=2190753&page=143#post68988079
There is a known issue in HTC devices involves S-off. If the above doesn't solve this for you message here I'll follow. Or pm me. I work wierd hours be patient.
Rom Maximus 3.0.0 ( Android 7 ).Any instruction don't works,adaway no blocked ads.
regarding su folder to move files to
FreydNot said:
About the only reason I root my phone is to install AdAway. I'd prefer to not modify the system partition to help make OTA's easier to get and to allow Android Pay to work. AdAway has a flashable .zip file that preps the hosts file to use the systemless root structure that comes along with SuperSU. Unfortunately, that script depends on being able to access the /data partition inside of TWRP which isn't going to happen any time soon on the HTC 10. Fortunately, it is easy for us to manually replicate what the flashable .zip is trying to do.
This isn't a detailed how-to, but more of a set of guidelines. Don't blame me if your phone explodes.
Root the phone with the latest SuperSU.
Download the AdAway_systemless_hosts_v2.zip file from the Unofficial AdAway thread.
Extract the files from inside the zip. We are only interested in two files in the support folder.
Connect the phone to your PC and turn on file transfer mode.
Copy "hosts" and "0000adaway.script" that you just extracted to the internal storage of your phone.
Use a program file Root Explorer to move "hosts" into /su/etc and move "0000adaway.script" into /su/su.d (this probably could have been done with ADB push, but I got permission errors when I tried it that way and I'm impatient and lazy).
Chmod 0755 /su/su.d/0000adaway.script (I used a root shell on the phone via ADB)
Install AdAway (I used the link in the Unofficial AdAway thread.)
Reboot the phone.
Run AdAway like normal. By default it should use /system/etc/hosts which is what you want.
If something doesn't work, figure out why and fix it. I'm happy to answer questions to the best of my ability.
Click to expand...
Click to collapse
Hi there, ive got a mate 8, not sure if this adblocker will work on it but i want to try it out anyway. Ive unzipped the file but which folder in su do i move the files to? screenshot of the folders i have in su

Categories

Resources