Related
I went from a stock 1.5 to 2.1 using the Sprint 2.1 RUU and all is well. I understand it's a dev build and as such is already root but when I trying installing android-wifi-tether (both 2.0 and 1.6) it all looks well except when I touch the icon to start and it fails. The 1.6 version did report I didn't have root.
What do I need to do in ADB/shell to ensure the proper permissions are there for AWT? This is the last thing I want to get working and I'm happy.
Do I need to remount the filesystem as rw? Add superuser? Not sure what's needed.
Please help.
mobilehavoc said:
I went from a stock 1.5 to 2.1 using the Sprint 2.1 RUU and all is well. I understand it's a dev build and as such is already root but when I trying installing android-wifi-tether (both 2.0 and 1.6) it all looks well except when I touch the icon to start and it fails. The 1.6 version did report I didn't have root.
What do I need to do in ADB/shell to ensure the proper permissions are there for AWT? This is the last thing I want to get working and I'm happy.
Do I need to remount the filesystem as rw? Add superuser? Not sure what's needed.
Please help.
Click to expand...
Click to collapse
is busy box installed?
is SU working?
feefeeboomboom said:
is busy box installed?
is SU working?
Click to expand...
Click to collapse
I haven't done anything since flashing the 2.1 RUU. What steps do I need to do to get busybox and su working?
if you installed the RUU that was just 'leaked' (from what i understood our 2.1 builds are based off this ruu already). The build does not include busy box or anything for that matter that is required for wireless tether-
damageless said:
Here is a link to the latest RUU from Sprint.
You cannot simply extract it. This still has root since it is a test release. I recommend just doing an adb pull of your system directory after you flash it. Don't do this when the final one comes out or else you might be stuck without root.
You will need to add busybox, patch sh and su, and make sure that you do another recovery image and such. I also recommend adding Superuser.apk and stuff. If you use the Desire build.prop, you can get most of the protected apps working.
Enjoy.
http://dl.damagedroms.com/2.0/RUU_Hero_C_Sprint_2.20.651.1_signed_test.exe
Leak, I know who you are.
Click to expand...
Click to collapse
http://benno.id.au/blog/2007/11/14/android-busybox
Busy Box link for you, I'm not really sure how to get it working but it's a start, alot of results come up if you google "busybox for android", so I hope that helps ya out bud
mobilehavoc said:
I went from a stock 1.5 to 2.1 using the Sprint 2.1 RUU and all is well. I understand it's a dev build and as such is already root but when I trying installing android-wifi-tether (both 2.0 and 1.6) it all looks well except when I touch the icon to start and it fails. The 1.6 version did report I didn't have root.
What do I need to do in ADB/shell to ensure the proper permissions are there for AWT? This is the last thing I want to get working and I'm happy.
Do I need to remount the filesystem as rw? Add superuser? Not sure what's needed.
Please help.
Click to expand...
Click to collapse
Add SU and make sure you have USB debugging on (Menu/Settings/Applications/Development/USB Debugging). This is needed so when you try to start the WIfi Tether app that is says do you allow root permissions.
dwertz said:
Add SU and make sure you have USB debugging on (Menu/Settings/Applications/Development/USB Debugging). This is needed so when you try to start the WIfi Tether app that is says do you allow root permissions.
Click to expand...
Click to collapse
How do I add su? Any guides on here. Don't understand why busy box is required for wifi tether.
mobilehavoc said:
I went from a stock 1.5 to 2.1 using the Sprint 2.1 RUU and all is well. I understand it's a dev build and as such is already root
Click to expand...
Click to collapse
Who told you that the RUU was rooted already? It's not. Why would it be? Sprint has no interest in you being root.
As for why do you have to install busybox? Because the application requires it.
It's rooted because it's a dev release. It just doesn't appear to have busybox or superuser installed
mobilehavoc said:
How do I add su? Any guides on here. Don't understand why busy box is required for wifi tether.
Click to expand...
Click to collapse
Here is the superuser.apk You have to have root.
Put superuser.apk in your C:\AndroidSDK\Tools\
adb remount
adb push superuser.apk /system/app/
mobilehavoc said:
It's rooted because it's a dev release. It just doesn't appear to have busybox or superuser installed
Click to expand...
Click to collapse
It has no reason to have either one. As for whether or not it's rooted... when you connect to it with adb, what do you get?
posguy99 said:
It has no reason to have either one. As for whether or not it's rooted... when you connect to it with adb, what do you get?
Click to expand...
Click to collapse
Not sure what you mean but I was able to push a new build prop onto the phone using adb with no issues.
posguy99 said:
It has no reason to have either one. As for whether or not it's rooted... when you connect to it with adb, what do you get?
Click to expand...
Click to collapse
The leak actually is rooted. It's an engineering leak, so root can work his magic- but only from the adb shell.
why do you need superuser?
superuser requires root, if you had root, you wouldnt need it.
you can just dl the wifi tether for root from the market
program and it would work right?
10 chars and a poke
THIS WILL NOT WORK WITH JELLY BEAN.
---
Here's a easy-to-use tool based on the method in this thread.
If you like this tool, please click the Thanks button!
Even better, see my signature.
DISCLAIMER: As with any rooting tool, there is some chance that something will go wrong. Use of this tool is at your own risk, and I will not be responsible if you brick your phone in the process. Although there have been zero reports of this tool breaking anyone's phone, don't run it if you aren't comfortable with the possibility of having something go wrong and having to re-Odin back to stock or worse.
Instructions:
Install the USB drivers if you don't have them already: Verizon_Wireless_I535_GSIII_Samsung_USB_Driver_v1_4_6_0.exe
Download the package and extract it somewhere (you'll need 7-Zip or some other modern compression tool) Make sure you extract all the files to a folder somewhere! Running it straight from your compression program probably won't work.
On your phone, enable installation of third-party apps (Settings --> Security --> Unknown sources, near the bottom in the "Device administration" section)
On your phone, enable USB debugging (Settings --> Developer options --> USB debugging)
On your PC, make sure you don't have any other Android devices connected, any Android emulators running, or any Android tools like PdaNet running.
Plug your phone into a USB port on your computer. For best results, use a port directly on the machine, and not a USB hub.
Double-click RootDebugfs.bat and follow the directions on the screen. Your phone will reboot 3 or 4 times during the process; just leave it plugged in. To be safe, don't switch to any other applications while the root process is running.
DOWNLOAD GS3DebugFSRoot R2 FOR US GALAXY S III VARIANTS ONLY!!!
(Released July 24, 2012)
If anything goes wrong, post here and I'll see what I can do.
Credits:
* miloj, for the debugfs root method for the Asus TF300T
* sparkym3, for his script for rooting the Asus Transformer Prime - this is a modified version of that script
* ChainsDD, for Superuser
Version History:
The most recent version is always at the top.
r2 2012-07-24
+ Changed font color to white for readability
+ Cleaned up output
+ Fixed typo in title (GSII instead of GSIII)
+ Fixed Unknown Sources/USB Debugging directions
+ Included latest version of adb from platform-tools 13, might make things more reliable
* Includes ChainsDD Superuser 3.1.3 and su binary 3.1.1
* Known to work with LF2 and LG1.
r1 2012-07-23
* Initial beta
* Includes ChainsDD Superuser 3.1.3 and su binary 3.1.1
* Works with LF2. Probably works with LG1.
Possible future features:
* APK version of the tool! I'm still not sure if this is possible - currently researching.
Sadly, I don't think this is going to happen.
* Unroot tool.
* Choice of Superuser or SuperSU.
FAQs:
Q: What versions of the stock ROM does this work with?
A: It's known to work with anything from LF2 up to LHE. It seems likely that DebugFSRoot will be able to work with any ICS ROMs. We'll have to wait and see if it works on JB or not.
Q: I'm getting an error like "adb is not recognized as an internal or external command", or "cannot stat 'su': No such file or directory". What do I do?
A: Don't run the tool straight from your compression program. Make sure to extract all the files somewhere first.
Q: Will this wipe my data?
A: Nope.
Q: How can I unroot? Will flashing a stock ROM unroot?
A: Flashing a stock ROM will unroot and also remove any modifications you made to /system.
Q: Everything seems to have worked fine, and the Superuser app shows the binary as present and working. However, none of my root apps work. What do I do?
A: This seems to happen to a very small number of people, and the cause is unknown. If this happens to you, try installing Chainfire SuperSU.
Q: Is this any better than flashing the root66 ROM?
A: The end result should be pretty much the same, but this tool is much smaller to download than the root66 ROM.
A: If you are on a phone with the stock LG1 ROM update, root66 will downgrade you to LF2, while this tool will leave your ROM alone.
Q: Is this any better than using the VRALEC boot chain method?
A: The boot chain is a little more complicated. It requires flashing two bootloaders, flashing recovery, and using Triangle Away to reset the Custom Binary Download counter. If you intend to install a custom recovery/custom ROMs anyway, it's fine and probably quicker. However, if all you want is root to run Titanium Backup or other root apps, GS3DebugFSRoot is easier.
Q: Will this increment the flash counter?
A: Not on its own. If you flash anything else after rooting, however, you might, so read up on what you're doing.
Q: Will this cause the "custom unlock" boot screen to appear?
A: In general, no. However, the spyware Samsung/Verizon included (SysScope/libcordon) is paranoid, and a lot of tweaks you can do after rooting will trigger it. If you don't want to risk getting the custom unlock screen, don't freeze any apps using Titanium Backup and generally limit your tweaking to things you could do without root.
Q: Can Samsung/Verizon block this method in the future?
Yes. It's very possible that a future OTA will patch the exploit that this tool uses. If you want to root, it's always best to do it now!
I just tried this and it appears to work. Installed Titanium Backup and SuperUser permissions were given. Thanks!
P.S.
Some of the instructions in the console app are incorrect for the location of enabling Debug Mode and Installing Unknown App Sources.
DFieldFL said:
I just tried this and it appears to work. Installed Titanium Backup and SuperUser permissions were given. Thanks!
P.S.
Some of the instructions in the console app are incorrect for the location of enabling Debug Mode and Installing Unknown App Sources.
Click to expand...
Click to collapse
Ah, I forgot to update that part in the Transformer Prime script I based this on. I'll fix it tomorrow.
Did you get the custom unlock boot screen?
Noxious Ninja said:
Ah, I forgot to update that part in the Transformer Prime script I based this on. I'll fix it tomorrow.
Did you get the custom unlock boot screen?
Click to expand...
Click to collapse
Also title says Galaxy S II not III.
Noxious Ninja said:
Ah, I forgot to update that part in the Transformer Prime script I based this on. I'll fix it tomorrow.
Did you get the custom unlock boot screen?
Click to expand...
Click to collapse
The boot screen looks the same to me.
Worked for me, thanks
Cant recognize the phone using this tool. Yet device is recognized by adb in a standalone cmd prompt..
saying "adb is not an executable file"
phantomevo77 said:
Cant recognize the phone using this tool. Yet device is recognized by adb in a standalone cmd prompt..
saying "adb is not an executable file"
Click to expand...
Click to collapse
Same thing happening to me.
EDIT: Just switched usb ports and unplugged and replugged my phone in and it worked!
If my gs3 came updated with the newest version, will this still work?
Next release will be out tonight after I test it.
DFieldFL said:
Some of the instructions in the console app are incorrect for the location of enabling Debug Mode and Installing Unknown App Sources.
Click to expand...
Click to collapse
Fixed in the next version. Also, I added those steps to the main post.
open1your1eyes0 said:
Also title says Galaxy S II not III.
Click to expand...
Click to collapse
Typo on my part. Will be fixed in the next release.
phantomevo77 said:
Cant recognize the phone using this tool. Yet device is recognized by adb in a standalone cmd prompt..
saying "adb is not an executable file"
Click to expand...
Click to collapse
I'm not sure about this one. However, I had packaged a slightly older version of adb, which could cause a difference. The next release will have the latest adb.
eakrish said:
If my gs3 came updated with the newest version, will this still work?
Click to expand...
Click to collapse
I think so, but I don't know if it's been tested. Worst case should be that it would fail when trying to copy su into /system/xbin/, and you might have to manually clean up a few things:
Code:
adb shell
[COLOR="Red"]$[/COLOR] rm /data/local/tmp
[COLOR="Red"]$[/COLOR] mv /data/local/tmp.bak /data/local/tmp
[COLOR="Red"]$[/COLOR] rm /data/local/su
[COLOR="Red"]$[/COLOR] rm /data/local/debugfs
[COLOR="Red"]$[/COLOR] rm /data/local/debugfsinput
[COLOR="Red"]$[/COLOR] exit
Really worst case is that your /system is screwed up and you have to re-flash a stock ROM with Odin, but that is highly, highly unlikely with this method.
Thanks for this awesome tool!!! Will there be a reversal to what this script does, aka, non-root to reverse changes if necessary or will that require odin flash?
It's probably possible to unroot via script. I think it might even be possible to move this into an APK and do away with adb altogether. I'll play around with it.
Is there an unroot method that's just as easy? I'd prefer not to reflash the phone to get rid of root. I guess I'm one of the oddballs here as I can care less about custom roms, I only root to be able to backup and remove bloatware.
edit: sorry I typed and posted this as others were doing the same... I couldn't delete or edit the post for a few minutes because of my newby status.
edthesped said:
Is there an unroot method that's just as easy? I'd prefer not to reflash the phone to get rid of root. I guess I'm one of the oddballs here as I can care less about custom roms, I only root to be able to backup and remove bloatware.
Click to expand...
Click to collapse
You should be able to do it via adb shell.
Code:
adb remount rw
adb shell
$ su
# rm /system/xbin/su
# exit
And then uninstall the Superuser app.
I'll try and add it to the script.
Thank You ! so much ... The tool works perfectly on my stock VZ ... Finally can get rid of all the crap that VZ puts in.
Noxious Ninja said:
It's probably possible to unroot via script. I think it might even be possible to move this into an APK and do away with adb altogether. I'll play around with it.
Click to expand...
Click to collapse
That would be awesome. It would be cool if you could make it unroot as well. Keep up the good work!
Tap'd via SGSIII(!)
CooL Very Very CooL
Thanks Noxious Ninja
eakrish said:
If my gs3 came updated with the newest version, will this still work?
Click to expand...
Click to collapse
Mine came with the update and I was able to root successfully with this tool. Very nice.
Good morning everyone!
I need some help in removing the file /system/xbin/.tmpsu I found on my nexus 5 after removing SuperSU.
I have to send my phone back for warranty because of broken usb port (so no fastboot, adb...).
Analyzing the file, I found that it'is a normal su executable (correct me if I'm wrong), probably used by SuperSU itself to clean its stuff during removal: so I tried in terminal emulator to gain su privileges with .tmpsu, remount /system as rw and remove .tmpsu, but it's a no-win... Any other idea?
Additional info: the phone now is completely stock (ready for warranty), so no cwm or twrp... everything ok apart of that executable, and I'm worried they will complain about it
Thank you!!!
PS: everyone of us rooted and on stock should have that file on his phone; you can use "strings .tmpsu" and see it really is the normal su executable by chainfire...!
vaccaaa said:
Good morning everyone!
I need some help in removing the file /system/xbin/.tmpsu I found on my nexus 5 after removing SuperSU.
I have to send my phone back for warranty because of broken usb port (so no fastboot, adb...).
Analyzing the file, I found that it'is a normal su executable (correct me if I'm wrong), probably used by SuperSU itself to clean its stuff during removal: so I tried in terminal emulator to gain su privileges with .tmpsu, remount /system as rw and remove .tmpsu, but it's a no-win... Any other idea?
Additional info: the phone now is completely stock (ready for warranty), so no cwm or twrp... everything ok apart of that executable, and I'm worried they will complain about it
Thank you!!!
PS: everyone of us rooted and on stock should have that file on his phone; you can use "strings .tmpsu" and see it really is the normal su executable by chainfire...!
Click to expand...
Click to collapse
If you have removed both SuperSU AND the su binary, there is nothing you can do now.
Although they're not...
1) going to look for these files.
2) reject warranty for a hardware issue not related to root anyway
all the above, except:
- you should be able to install supersu from playstore, then enable root
- you could use adb via wifi
kendong2 said:
all the above, except:
you should be able to install supersu from playstore
Click to expand...
Click to collapse
Yes
kendong2 said:
all the above, except:
then enable root
Click to expand...
Click to collapse
No, not if the SU binary was removed. Otherwise we'd all be rooting our Nexus 5 this way
kendong2 said:
all the above, except:
- you could use adb via wifi
Click to expand...
Click to collapse
But without root, this is useless. What will it achieve?
rootSU said:
No, not if the SU binary was removed. Otherwise we'd all be rooting our Nexus 5 this way
Click to expand...
Click to collapse
if we all had a hidden file /system/xbin/.tmpsu then we would all be rooting our nex's this way, yes
rootSU said:
But without root, this is useless. What will it achieve?
Click to expand...
Click to collapse
after installing supersu from playstore there will be root again.
kendong2 said:
if we all had a hidden file /system/xbin/.tmpsu then we would all be rooting our nex's this way, yes
Click to expand...
Click to collapse
Oh I see what you're saying. Sorry
Hey guys,
I couldn't find it anywhere and I don't really know if this is the right place to ask, but I'll give it a try...
I wonder how does the CF-Auto-Root for the nexus 5 works?
I can see in the windows batch file that it unlocks the bootloader (that's the easy part) and than boot with some image file.
It seems that this tool is not installing any custom recovery which I always saw is a necessary tool for rooting.
What exactly is this image file? what does it do? Where does it come from? What it contains?
Why it's device related (different image files for different nexus devices running the same stock version).
Thanks,
Casteel.
Casteel said:
Hey guys,
I couldn't find it anywhere and I don't really know if this is the right place to ask, but I'll give it a try...
I wonder how does the CF-Auto-Root for the nexus 5 works?
I can see in the windows batch file that it unlocks the bootloader (that's the easy part) and than boot with some image file.
It seems that this tool is not installing any custom recovery which I always saw is a necessary tool for rooting.
What exactly is this image file? what does it do? Where does it come from? What it contains?
Why it's device related (different image files for different nexus devices running the same stock version).
Thanks,
Casteel.
Click to expand...
Click to collapse
Unlocking and rooting is a piece of cake with CF Auto Root for the N5, i never xperienced issues with it. Download CF Root for the Nexus 5, unzip it with 7-zip. Enable usb debugging in developer options, then go into bootloader/fastboot mode, open the uznipped CF Root folder and press Root_windows.bat and follow instructions. Takes 30 seconds - 1 minute all in all.
Thanks, but...
gee2012 said:
Unlocking and rooting is a piece of cake with CF Auto Root for the N5, i never xperienced issues with it. Download CF Root for the Nexus 5, unzip it with 7-zip. Enable usb debugging in developer options, then go into bootloader/fastboot mode, open the uznipped CF Root folder and press Root_windows,bat and follow instructions. Takes 30 seconds - 1 munute all in all.
Click to expand...
Click to collapse
First, thanks for your response.
I don't have a problem with making it work.
As you said, it is super simple and no question it's a great tool.
My question is about how it works? What exactly does it do behind the scene?
Casteel said:
First, thanks for your response.
I don't have a problem with making it work.
As you said, it is super simple and no question it's a great tool.
My question is about how it works? What exactly does it do behind the scene?
Click to expand...
Click to collapse
It unlocks the BL and injects superSU in one go without having to flash a seperate superSU.zip with a custom recovery. Thats all.
gee2012 said:
It unlocks the BL and injects superSU in one go without having to flash a seperate superSU.zip with a custom recovery. Thats all.
Click to expand...
Click to collapse
What do you mean by "injects SuperSU" ?
It sounds very simple from the way you say it. Why can't I do this myself?
I believe it doesn't just mean copy it to the right place.
Does it also include putting the su binary in the right system path with the right permissions?
How does the root privilage is gained?
Does only unlocking the BL let me write to the system partition?
I would really appreciate some technical details to understand this rooting process and what this image file contains.
Thanks again!
Read this http://forum.xda-developers.com/showthread.php?t=2507211 and this http://forum.xda-developers.com/showthread.php?t=1980683. You can also do the root yourself manualy if that more comfortable for you.
gee2012 said:
Read this http://forum.xda-developers.com/showthread.php?t=2507211 and this http://forum.xda-developers.com/showthread.php?t=1980683. You can also do the root yourself manualy if that more comfortable for you.
Click to expand...
Click to collapse
gee2012, I really appreciate your help.
I've already read (most of) these two threads before posted here, and couldn't find an answer to my questions,
only general explanations about how to make it work and how to solve problems,
nothing about HOW it works and what it actually does.
I have already rooted my device with this tool, I don't have any discomfort with is,
just pure technological curiosity about how it works.
Sure, I can also root myself manually, but all the guides I read about it mentioned installing custom recovery, and that tool does it with out it.
Casteel said:
gee2012, I really appreciate your help.
I've already read (most of) these two threads before posted here, and couldn't find an answer to my questions,
only general explanations about how to make it work and how to solve problems,
nothing about HOW it works and what it actually does.
I have already rooted my device with this tool, I don't have any discomfort with is,
just pure technological curiosity about how it works.
Sure, I can also root myself manually, but all the guides I read about it mentioned installing custom recovery, and that tool does it with out it.
Click to expand...
Click to collapse
Look here https://www.google.com/search?q=how+root+works&ie=utf-8&oe=utf-8&aq=t and other sites how root works http://stackoverflow.com/questions/...hat-are-the-pre-requisites-for-it-to-work-wha.
With Google you can find anything
Actually, I read this also...
It only talks about gaining root privilage using some system exploit.
So, you're telling that CF-Auto-Root is running some script in its bootable image file that is using some kind of exploit to gain root access?
Shouldn't it be less "hacky" thing in nexus devices?
And how can it be that the image file is related to specific devices and not to specific stock versions?
What prevents from other apps to use this so called "exploit"?
This is probably what you are looking for...
Embedded in the boot image a folder cfroot with the SuperSU apk file, the su binary and the necessary init scripts and there is a binary under sbin does the remaining steps of copying the files to the respective places. It is not an exploit, it merely uses the boot image and the boot process to "install" SuperSU. You do not need a custom recovery to root your phone, merely the capability to copy the superuser files to the /system partition.
In more detail:
1. Embedded in the ramdisk is a folder "cfroot" with "99SuperSUDaemon, install-recovery.sh, su and Superuser.apk".
2. In the sbin folder in the ramdisk is a binary "cfautoroot" which does stuff like copy the above files to the correct locations and set the appropriate permissions, etc.
3. This file is called through the "recovery" script/binary in the sbin folder
4. The "recovery" script/binary is executed as a startup server via the init system in "init.rc" within the ramdisk
The result:
When you boot up, the superuser files are copied to the respective locations with the right permission, thereby rooting the system
OK! Now we're getting closer
Thank you very much.
But I still have some confusions...
You said:
craigacgomez said:
there is a binary under sbin does the remaining steps of copying the files to the respective places.
You do not need a custom recovery to root your phone, merely the capability to copy the superuser files to the /system partition.
Click to expand...
Click to collapse
How did the "cfautoroot" got to my phone sbin folder?
How do I get the capability to copy the superuser files to the system partition?
Putting things in these folders and set their appropriate permissions doesn't require root from the first place?
How is the init.rc calling the recovery script to run the cfautoroot? shouldn't I need root access to modify init.rc?
[Is the CF-Auto-Root source code available somewhere to see all these files you're talking about?]
It sounds like only unlocking the bootloader is giving me some sort of "root" capabilities to do all these stuff. is it true?
Will this method work in non Nexus devices either?
And what are all those "exploits" that so many rooting guides are talking about?
I'm guessing it desn't have anything with rooting Nexus devices since rooting them is kind of part of their existence, isn't it?
Thanks again! :good:
Casteel said:
OK! Now we're getting closer
Thank you very much.
But I still have some confusions...
You said:
How did the "cfautoroot" got to my phone sbin folder?
How do I get the capability to copy the superuser files to the system partition?
Putting things in these folders and set their appropriate permissions doesn't require root from the first place?
How is the init.rc calling the recovery script to run the cfautoroot? shouldn't I need root access to modify init.rc?
[Is the CF-Auto-Root source code available somewhere to see all these files you're talking about?]
It sounds like only unlocking the bootloader is giving me some sort of "root" capabilities to do all these stuff. is it true?
Will this method work in non Nexus devices either?
And what are all those "exploits" that so many rooting guides are talking about?
I'm guessing it desn't have anything with rooting Nexus devices since rooting them is kind of part of their existence, isn't it?
Thanks again! :good:
Click to expand...
Click to collapse
"cfautoroot" is a binary created by Chainfire which is embedded in the sbin folder in the kernel ramdisk. It's in the CF Auto Root boot image. Android kernels are essentially Linux kernels and have an init process which is basically a bootstrap/startup process. init.rc is part of this process. It is run when the kernel boots up. Anything within the init process is low-level and essentially run as "root". It kick-starts various other processes like zygote which is the Android process management system. This will help you understand the init process a bit better (http://www.mekya.com/blog/2012/03/android-initialization-from-init-rc-to-third-party-code/). In the init.rc file is a line which "executes" the file /sbin/recovery (which is embedded in the ramdisk along with cfautoroot). This in turn "executes" cfautoroot which takes care of copying the superuser files to the correct locations and setting the correct permission. All this is done within the init process and has elevated (root) permission.
Unlocking the bootloader does not root your phone. It simply allows you to flash "unsigned" (custom) boot images.
Any phone with the ability to flash a custom boot image can make use of this process.
Exploits make use of holes or workarounds to either flash a custom boot image or inject files into the system partition without unlocking the bootloader and are only needed if you cannot unlock the phone bootloader.
Hope this helps!
Casteel said:
Hey guys,
I couldn't find it anywhere and I don't really know if this is the right place to ask, but I'll give it a try...
I wonder how does the CF-Auto-Root for the nexus 5 works?
I can see in the windows batch file that it unlocks the bootloader (that's the easy part) and than boot with some image file.
It seems that this tool is not installing any custom recovery which I always saw is a necessary tool for rooting.
What exactly is this image file? what does it do? Where does it come from? What it contains?
Why it's device related (different image files for different nexus devices running the same stock version).
Thanks,
Casteel.
Click to expand...
Click to collapse
Thank you for asking the question and being polite yet persistent about getting your answer. I have been trying to get to this answer myself for some time now.
Sent from my Nexus 5 using Tapatalk
Great! now we're even closer :victory:
So in the boot process I have elevated privilages, that basically what I was missing.
But this bootable image file is not an image of the OS, isn't it?
It is an image of the kernel?
It is some sort of pre-handled file system that the device is booted into and than startup the OS?
Or something like that...?
Thanks for your patient and the very quiqc responses!
We're almost there...
Casteel said:
Great! now we're even closer :victory:
So in the boot process I have elevated privilages, that basically what I was missing.
But this bootable image file is not an image of the OS, isn't it?
It is an image of the kernel?
It is some sort of pre-handled file system that the device is booted into and than startup the OS?
Or something like that...?
Thanks for your patient and the very quiqc responses!
We're almost there...
Click to expand...
Click to collapse
The boot image is not the OS image. It contains the kernel and the ramdisk. The ramdisk is the basically the root filesystem (/) which the kernel mounts, after which the init process begins and init.rc is called. Nothing is ever persisted or modified in the root filesystem unless it is done during the init process or it is embedded in the ramdisk
craigacgomez said:
The boot image is not the OS image. It contains the kernel and the ramdisk. The ramdisk is the basically the root filesystem (/) which the kernel mounts, after which the init process begins and init.rc is called. Nothing is ever persisted or modified in the root filesystem unless it is done during the init process or it is embedded in the ramdisk
Click to expand...
Click to collapse
Nice.
I thought the root file system is part of the OS image.
So basically, I can have the same OS installed on my devices with different file systems according to what is defined in boot?
One last question and I will stop bother you
Why is the image file device related?
Meaning, why nexus 4, 5 and 7 have different CF-Auto-Root?
(Nexus 7 even got several).
Thanks again!
Casteel said:
Nice.
I thought the root file system is part of the OS image.
So basically, I can have the same OS installed on my devices with different file systems according to what is defined in boot?
One last question and I will stop bother you
Why is the image file device related?
Meaning, why nexus 4, 5 and 7 have different CF-Auto-Root?
(Nexus 7 even got several).
Thanks again!
Click to expand...
Click to collapse
Yes, you could theoretically change the way your filesystem is defined via the boot image, but Android as an OS expects some things.
And each device has different autoroot files because they have different kernels and some differences in some init scripts specific to the hardware. Some devices like the Nexus 7 have multiple version (LTE & non-LTE for example) and there are hardware differences and different kernels.
craigacgomez said:
Yes, you could theoretically change the way your filesystem is defined via the boot image, but Android as an OS expects some things.
And each device has different autoroot files because they have different kernels and some differences in some init scripts specific to the hardware. Some devices like the Nexus 7 have multiple version (LTE & non-LTE for example) and there are hardware differences and different kernels.
Click to expand...
Click to collapse
A thousand thanks, Craig Gomez!
You really helped.
I truely appreciate the patient and the kindful responses.
It was a nice first experience in this forum.
Thank you very much!
Casteel said:
A thousand thanks, Craig Gomez!
You really helped.
I truely appreciate the patient and the kindful responses.
It was a nice first experience in this forum.
Thank you very much!
Click to expand...
Click to collapse
Glad I could help you... It's what communities are all about... Sharing knowledge and experiences.
Sent from my Nexus 5
Excellent thread. Thanks to OP and members who responded.
Hi,
A while back I rooted my phone because I had had enough of missing out on xposed modules and had had enough with all the Ads!! When did Android become so riddled with adverts. (i know its not android itself before you say anything)
Anyway I managed to root my phone using the methods highlighted in the forum. I've got xposed working perfectly but I am still seeing averts in apps and on web pages. Correct me if I'm wrong but I should be able to hide these now. I've come from Galaxy S4 which I had rooted from day 1 so I never saw a single advert (in app or webpage) but now on my rooted Z5 I am still seeing a lot. Many apps (baconreader for example) have had the ads in there hidden but many still persist.
I've tried all the options I can see to be available to me
In no particular order and never installed at the same time incase they conflict.
- Adaway (this errors when applying the host file saying the copy failed)
- Adblock plus (app not browser)
- Adfree (this is what I used on my S4)
- MinMinGuard (tried different modes on this one and still no luck and no errors to speak of)
None of them error apart from AdAway.
Have any of you guys got a totally adfree experience on the Z5? If so how have you managed this?
I am using Adguard, it costs 8$ a year. That's almost free I think.
I just installed AdAway, the host file applied fine as far as I can tell (haven't rebooted).
Did you make sure you have a kernel that disables RIC, or disable it your self in a terminal emulator?
Sent from my E6683 using Tapatalk
Funkmasterchilla said:
I am using Adguard, it costs 8$ a year. That's almost free I think.
Click to expand...
Click to collapse
Thanks. I am aware of that option as it's what I was using before I rooted. (free version)
Not that $8 is a lot I don't see the point in paying for something when I can get a permanent solution for $0 so I'd like to know why the host method isn't working on my current setup.
Is there anybody with a rooted Z5 that has blocked all adverts using the host modification method?
TimDawg said:
Thanks. I am aware of that option as it's what I was using before I rooted. (free version)
Not that $8 is a lot I don't see the point in paying for something when I can get a permanent solution for $0 so I'd like to know why the host method isn't working on my current setup.
Is there anybody with a rooted Z5 that has blocked all adverts using the host modification method?
Click to expand...
Click to collapse
AdAway is working for me.
Like I said ensure you can remount /system as r/w.
Sent from my E6683 using Tapatalk
_Dennis_ said:
I just installed AdAway, the host file applied fine as far as I can tell (haven't rebooted).
Did you make sure you have a kernel that disables RIC, or disable it your self in a terminal emulator?
Sent from my E6683 using Tapatalk
Click to expand...
Click to collapse
I used the kernel that is on the dirty root guide. I was meaning to use the AndroPlus on but didn't in the end. Flashing a new kernel doesn't affect any of the data on it does it?
If I can disable RIC via terminal could you advise me how please. I've had a quick google and can't find anything.
Cheers
TimDawg said:
I used the kernel that is on the dirty root guide. I was meaning to use the AndroPlus on but didn't in the end. Flashing a new kernel doesn't affect any of the data on it does it?
If I can disable RIC via terminal could you advise me how please. I've had a quick google and can't find anything.
Cheers
Click to expand...
Click to collapse
Thanks to @tobias.waldvogel for this. Use the following in a terminal emulator to disable RIC, will need to be done on reboot (you can make it a boot script if you know how.)
Code:
su
echo 0 >/sys/kernel/security/sony_ric/enable
mount - o remount, rw /system
Sent from my E6683 using Tapatalk
See MOAAB (mother of all ad block) in Android Development and Hacking. Costs 0 bucks and blocks hosts. That's the best if you are rooted bro
_Dennis_ said:
Thanks to @tobias.waldvogel for this. Use the following in a terminal emulator to disable RIC, will need to be done on reboot (you can make it a boot script if you know how.)
Code:
su
echo 0 >/sys/kernel/security/sony_ric/enable
mount - o remount, rw /system
Sent from my E6683 using Tapatalk
Click to expand...
Click to collapse
I get an error saying no such directory. if i try to create it manually it fails...
TimDawg said:
I get an error saying no such directory. if i try to create it manually it fails...
Click to expand...
Click to collapse
It worked for mine....
You did it one line at a time? And approved super user for the terminal emulator?
Sent from my SM-T710 using Tapatalk
_Dennis_ said:
It worked for mine....
You did it one line at a time? And approved super user for the terminal emulator?
Sent from my SM-T710 using Tapatalk
Click to expand...
Click to collapse
yep one line at a time.
It's almost like my phone isn't totally rooted. I can do a lot of things that require root. If it try to create any folder inside /sys it fails.
TimDawg said:
yep one line at a time.
It's almost like my phone isn't totally rooted. I can do a lot of things that require root. If it try to create any folder inside /sys it fails.
Click to expand...
Click to collapse
What super user app do you use? How was it installed?
_Dennis_ said:
What super user app do you use? How was it installed?
Click to expand...
Click to collapse
SuperSU and it was installed via ADB
I think I must have messed up the kernel install somehow.
I'm busy tomorrow and not risking anything tonight so I'll give a fresh kernel a go on Monday. Already looking at AndroPlus kernels and there are a lot of options now. Enforcing and Permissive. I'm sure a Google will let me know what the difference is though.
TimDawg said:
SuperSU and it was installed via ADB
I think I must have messed up the kernel install somehow.
I'm busy tomorrow and not risking anything tonight so I'll give a fresh kernel a go on Monday. Already looking at AndroPlus kernels and there are a lot of options now. Enforcing and Permissive. I'm sure a Google will let me know what the difference is though.
Click to expand...
Click to collapse
Probably your best bet. Sorry I couldn't be of any help.
Sent from my E6683 using Tapatalk
How did you rooted your z5?
luisfillipe said:
How did you rooted your z5?
Click to expand...
Click to collapse
I used the method for Z5 dual SIM posted in the dirty root thread in development section. There are other simpler methods for the regular Z5, again in development section. It requires bootloader unlocks for all of them and that causes you to lose some Sony DRM keys.
Sent from my SM-T710 using Tapatalk
I tried Adblock since i'm not rooted, but it occasionally drain battery in sleep mode so I removed it..
I've always used Lucky Patcher for that. It has hosts blocking as well as disabling google ad modules inside apps, making everything clean and bull$hit free.
Gotta say I was starting it get a be pissed off with how much more complicated it is to do root this phone than any other android phone I've tried to do in the past...
so I came to the assumption that I'm supposed to be booting into recovery and installing the zip through there like I used to do to install ROMs on my older android phones.
I've flashed a few AndroPlus kernels and no luck. One of them left me stuck in bootloop which I let go around roughly 10 times until I decided it was getting nowhere. I did eventually manage to get one installed without a bootloop.
I wanted to know what Kernel I was running so I installed 'Kernel Adiutor' which required BusyBox to be installed alongside it. I found I was unable to install BusyBox which I guess was caused by the same thing causing all my other issues.
I've tried going through this whole over complicated process again and I hit a problem was trying to execute these two lines:
Code:
adb shell mount /dev/block/platform/soc.0/by-name/system /system
adb shell mount /dev/block/platform/soc.0/by-name/userdata /data
I read through everything I could find again to see if I could work out what was going on. While looking for this I can across this line of code:
Code:
fastboot flash boot boot.img
which is to be run if you want to flash the kernel via adb. (you need to extract the zip provided by AndroPlus)
Once this line had been executed I booted up again and was able to install BusyBox which let me see which kernel I had which showed AndroPlus (v3 incase you're interested) so I then tried AdAway again.
BINGO
Only thing is on some websites, particularly xda there is still a gap showing where the Advert would be displayed if not blocked. This I can live with.
I can't beleive how much more complicated this phone is to root compared to my HTC Desire, Galaxy S2 & S4. All of them were plug phone in. Click a few times and the jobs done. Is there a reason this hasn't been done for the Z5?
Just want to say thanks to all that have tried to help.
Thanks to AndroPlus for his kernel which has sorted me out.
Not so much thanks to Sony as this whole process has put me off ever getting another Sony phone. Mainly the fact I've lost some functionality what with having to unlock the bootloader. Overall I'm happy though.
Cheers