Another S-Off script that was sent to me by coremark. Successfully s-off my device and supercid.
http://firewater-soff.com/
Thanks to @coremark.
After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?
edorner said:
After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?
Click to expand...
Click to collapse
I'm afraid you'll need a custom recovery for this. The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this. To work around it, you'd need a custom kernel (which is not feasible at the moment since HTC haven't released the full source tree yet, unfortunately) or the wp-mod hack (which I would be afraid of using, to be honest).
Also, why avoid custom recovery when you're already S-OFF and you can flash the stock recovey anytime?
koniiiik said:
The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this.
Click to expand...
Click to collapse
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?
edorner said:
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Click to expand...
Click to collapse
To be honest, no idea. All I do know is that on my phone the write protection works the way it does and I don't really see a feasible way around it. Also, I haven't tried these exact steps. It's possible that adb remount does some extra work or something. Moreover, I'm not sure about the adb shell chmod ... command – that would require root, wouldn't it? But since I haven't tried it, I can only guess.
If you don't mind trying it, I'd be interested in the results.
edorner said:
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?
Click to expand...
Click to collapse
The way I understand wp_mod works is that it monkey-patches the running kernel's filesystem driver to skip the check for the /system partition. In other words, it rewrites the code of the running kernel in-memory. This by itself is reason enough to be extremely careful around such code as it has potential for a major disaster. Missing the right memory location by any nonzero number of bytes can result in the kernel doing practically anything (most likely a crash).
Now, to make matters worse, these seem to be only a few binary versions of the kernel module and people seem to just take a binary compiled for one kernel, modify the version information within the file to make it match other kernels and load it on a completely different kernel. This, to me, is borderline insane, considering that the kernel binaries depend on the version of the kernel, used compiler and even compiler flags used when building.
Again, though, I haven't actually looked at the module's source code; can't say I'm suffering from a surplus of free time and I'm also not *that* interested in it. Most likely it's written in a robust enough way to have a high chance of success. (This seems to be backed up by anecdotal evidence – the thing appears to work for people, which is a small wonder for me.) All of the above is actually just my interpretation of stuff I read in some threads here on XDA-developers and I haven't even tried to confirm it myself.
Still, for me, using the recovery for any such changes is a sufficient and acceptable workaround, since I don't need to modify /system that often.
Wow! Thanks for the exhaustive expanation about WP-mod!
If you don't mind trying it, I'd be interested in the results.
Click to expand...
Click to collapse
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.
edorner said:
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.
Click to expand...
Click to collapse
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
Ah, I see. In that case I will definitely try it!
Truth is I am still an Android noob, I used ADB maybe on two occasions so far, and did not have the time yet to properly check out the documentation for these particular commands.
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?
edorner said:
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?
Click to expand...
Click to collapse
No idea, I haven't used firewater, but my guess would be that it won't wipe anything…
As for backing up /data/preload, you can for example use temproot to get access to the directory, copy it somewhere on your sdcard and adb pull it. In case it gets wiped, you can just push it back again and voilà. It's going to require some shell-fu, however.
Alternately, you can just download my ZIP of the latest stock ROM and extract it, it contains the latest /data/preload.
And yes, just copying the APK files into /data/preload should suffice *– Dalvik and its package manager is intelligent enough to detect something has changed in there and perform any installation steps necessary. If it doesn't work right away, a reboot should fix things.
Edorner. It won't wipe. I tried it already.
Sent from my GT-I9305 using XDA Premium 4 mobile app
koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.
edorner said:
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.
Click to expand...
Click to collapse
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.
koniiiik said:
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.
Click to expand...
Click to collapse
Thanks
Hm... Strange...
Instead of manually remounting /system as "ro", I simply rebooted the device. (What can I say, I am hopelessly lazy ) After the reboot I checked the permissions of /system by issuing the "mount" command without any parameters. It showed that it was remounted using the original settings:
Code:
/dev/block/mmcblk0p38 /system ext4 ro,noatime,data=ordered 0 0
So in theory, rebooting instead of manually remounting as "ro" should not make any difference. But who knows
After the reboot, I checked the changes I made to /system previously, and fortunately they did not disappear. (su was still there, I could successfully copy it, and execute it.)
Since then, I've performed a couple more reboots and at least one full shutdown-startup cycle as well. And I still have not lost any changes.
Please let me know if you find something out! I am very interested.
Related
So, anyone come up with a way to block the NC from receiving its firmware updates from B&N? I can see Barnes releasing a update and it just installs itself and wipes out the root we have. I'm sure they cant be happy about all the stuff we are now doing on the nook, but I'm sure they are especially not happy about us being able to install the Kindle app! In my mind, its the best of both worlds, but I'm sure B&N wouldnt see it that way. They could (for all practical purposes), put out a 1.0.1 update that blocked that app and kills our root.
The "default way" of disabling OTA updates on Android might work (make sure your device is not currently updating or something):
Code:
mount -o remount,rw /dev/block/mmcblk0p5 /system
cd /etc/security
mv otacerts.zip otacerts.zip_DISABLED_OTA_UPDATES
Although the key contained in that ZIP file does not look like it's really used (its name is testkey.x509.pem).
Edit: Please disregard my mindless ramblings below (I feel like the noob I am, now). I took a closer look at the code once my mind had emerged from whatever haze had been blocking my deeper thought processes and realized what needed to be done to get it to work (I learned a little more about ADB, which helps). And what's more, I think I did it the right way. *grin* Now, if we knew for sure this would block updates, we'd be set. I suppose we'll find out soon enough.
Thanks for posting the code, Weichel.
weichel said:
The "default way" of disabling OTA updates on Android might work (make sure your device is not currently updating or something):
Code:
mount -o remount,rw /dev/block/mmcblk0p5 /system
cd /etc/security
mv otacerts.zip otacerts.zip_DISABLED_OTA_UPDATES
Although the key contained in that ZIP file does not look like it's really used (its name is testkey.x509.pem).
Click to expand...
Click to collapse
Just to make sure I'm on the right track (noob here), I'd want to do an "adb shell" then run the script above? Also, read-write access for the NC system partition is probably necessary, yes? I haven't enabled rw access yet, didn't want to take any chances of accidentally bricking my NC.
I tried the code above (without going through to proceedure to enable read-write access to the system partition), but it didn't return any messages confirming success or failure.
just looked in that /etc folder and I see install-recovery.sh I wonder what that does.
xboxexpert said:
just looked in that /etc folder and I see install-recovery.sh I wonder what that does.
Click to expand...
Click to collapse
Overwrites corrupted/custom recovery with stock one on boot. At least, that's what it did on the OG Droid.
disregard. wrong post
big.t_03 said:
Edit: Please disregard my mindless ramblings below (I feel like the noob I am, now). I took a closer look at the code once my mind had emerged from whatever haze had been blocking my deeper thought processes and realized what needed to be done to get it to work (I learned a little more about ADB, which helps). And what's more, I think I did it the right way. *grin* Now, if we knew for sure this would block updates, we'd be set. I suppose we'll find out soon enough.
Thanks for posting the code, Weichel.
Just to make sure I'm on the right track (noob here), I'd want to do an "adb shell" then run the script above? Also, read-write access for the NC system partition is probably necessary, yes? I haven't enabled rw access yet, didn't want to take any chances of accidentally bricking my NC.
I tried the code above (without going through to proceedure to enable read-write access to the system partition), but it didn't return any messages confirming success or failure.
Click to expand...
Click to collapse
I don't understand the confusion here. You have a rooted Color Nook. Install Root Explorer and go to /system/etc and click the Mount R/W button and then long press the ocacerts.zip file and rename it. It's that easy.
Psneuter exploit is working on IS, but because /system is locked on s-on phones, we can't copy su and superuser.apk into /system, apps required root access can't work.
The following procedure uses psenuter exploit to gain adb shell root, and then copy su (without privilege control ) and busybox into /sbin (which is on rootfs and in the global PATH list) to gain root access for apps.
The procedure:
1. Unzip the attached .zip into a directory (like c:\adb)
2. Open a command prompt and cd to the directory where you extracted the .zip (like cd \adb)
3. run pushroot.bat (simply type pushroot)
4. adb shell /data/local/tmp/getroot
5. adb shell
6. you are now in # prompt. Type /data/local/tmp/pushroot
You have to redo steps 4,5,6 once you reboot your phone.
The procedure will have all apps gaining root access.
!!USE ON YOUR OWN RISK!!
Known working programs: Root explorer, Titanium backup, gscript lite, trasproxy 2.04, ...
Some apps check existence of su in /system/xbin , and reject to proceed if the su binary is not exist (like transproxy 3.08). For this kind of apps, this procedure won't help.
Nice but old news mate...
Sent from my HTC Incredible S using XDA Premium App
Good job...thanks
Thanks for writing this up, might quell the thirst for S-OFF a little longer
/system/ is writeable btw, if you remount it, but after reboot everything u done will be changed to the way it were before.
so a temp root in xbin is possible also, only it will be gone afterwards (atleast i never tried this, but should work also...)
Yes. /system could be remount in rw with root. However, the files you wrote will be gone after you remount ro, and then you won't be able to copy the same filename into the same location again before next reboot ( I don't know why, actually!!). This is why I put su in sbin instead of /system/xbin.
thanks to your files 非常感谢你的工作。
Does anyone know whether steps 4, 5 and 6 can be run from the device itself?
Can I put these commands into some sort of script and run it everytime I need temp root or would I need to do this from a computer every time?
faf said:
Does anyone know whether steps 4, 5 and 6 can be run from the device itself?
Can I put these commands into some sort of script and run it everytime I need temp root or would I need to do this from a computer every time?
Click to expand...
Click to collapse
I believe you can do it from a terminal emulator but haven't got the chance to try it myself though.
Sent from my HTC Incredible S using Tapatalk
pushroot error
c:/adb>adb shell ln /data/local/tem/busybox /data/local/tmp/cp
Link failed File exists
and
c:/adb>adb shell /data/local/tmp/getroot
mmap<> failed. operation not permitted
Why??THX....
itandy said:
I believe you can do it from a terminal emulator but haven't got the chance to try it myself though.
Sent from my HTC Incredible S using Tapatalk
Click to expand...
Click to collapse
Definitely, this is the way to go.
Unfortunately, the root exploit I know could run on device itself, including
rageagainstthecage (ratc) and local root exploit (hotplug) both failed on IS.
The solution will be nearly perfect if we can get temp root on IS without a computer link.
Any input will be welcome.
sky1212 said:
pushroot error
c:/adb>adb shell ln /data/local/tem/busybox /data/local/tmp/cp
Link failed File exists
and
c:/adb>adb shell /data/local/tmp/getroot
mmap<> failed. operation not permitted
Why??THX....
Click to expand...
Click to collapse
Please then type adb shell.
If you see # but not $, do
cd /data/local/tmp
rm ./cp
ln busybox cp
./pushroot
Then you finished the install.
If you see $, please do all over again.
You can also add ShootMe (screen capture app) and SetCPU to the list of working apps. SetCPU will only allow you underclock for now due to the kernel, but it is a nice touch if you are worried about battery life. Adfree doesn't appear to work
l0st.prophet said:
You can also add ShootMe (screen capture app) and SetCPU to the list of working apps. SetCPU will only allow you underclock for now due to the kernel, but it is a nice touch if you are worried about battery life. Adfree doesn't appear to work
Click to expand...
Click to collapse
Adfree is working for me. Are you getting some type of error message?
MetaMorph, screenshot and MyBackup Root are also working.
I had to mount system, then push su to /system/xbin. Then install BusyBox Installer from Market.
No erro, still got the ads. I've tried rebooting & rerooting, still no luck
l0st.prophet said:
No erro, still got the ads. I've tried rebooting & rerooting, still no luck
Click to expand...
Click to collapse
What site/app are you going to so I can see if I get the ads.
the anti-ads actually tries to modify the current host file... which is not allowed in your state as far as i know
what you can do is replace it by pushin it to the right spot
but after reboot gone,but sure u know
Adfee is working for me, you can also add Droidwall.
@eddycyf, did you test adfree with apps? Since it aint working for prophet...
Sent from my HTC Incredible S using XDA Premium App
Mhm AdFree isnt working for me. The App states that everything is okay, and that my hosts file is up to date, but I see ads everywhere.
But I am kinda happy now, because i can use Titanium Backup
This is my attempt at a Bell FAQ, it is a work in progress.
Q. Why don't the instructions I found on how to do X not work?A. This is a development forum, sometimes things are written in shorthand assuming you know things you don't. At lot of things are specific to one carrier's phone or another. Sometimes things change and are now obsolete, something new was found, a better way of doing things, if you were not following it all along you are likely to be lost. Read between the lines, you are a human being with reasoning abilities, figure it out. Q. What should I do first?
A. Backup your phone. That means everything, especially your pds partition. Nandroid won't cut it and you have already modified your phone beyond the ability to get back if you can run it.
Ex. dd if=/dev/block/mmcblk0p3 of=/sdcard/backup/mmcblk0p3
Save your backup on your computer, create a zip of all the files, burn it off on cd/dvd, put it in a safety deposit box at your bank. Be prepared for bricking your phone. A lot of things mentioned in threads here are developed and tested for ATT phones, they may not work 100% on your phone.Q. What is ADB?A. It stands for Android Debug Bridge or something like that. It is a program that runs on your computer that lets you talk to your phone using special commands. Your phone has to have adb enabled, it's a setting under application/development.
Ex. adb shell
This opens a linux shell connected to your phone. Linux is an operating system for computers, it is also used as the base for android phones.
Ex. adb install file.apk
Ex. adb push file /tmp
Ex. adb pull /tmp/file .
Q. What is CWM recovery?A. Android phones come with a special boot configuration that allows for changes to the android system from a place outside the system. It is very corporate and does the job for official signed updates, but only Motorola and it's oems can sign the updates. Not much fun for us. CWM recovery is a replacement for the official recovery system that doesn't require signed updates.
You install CWM recovery using fastboot or moto-fastboot.Q. What is unlocking the bootloader all about?A. It is the means of putting CWM recovery on your phone so you can install roms and other packages. It allows you to flash a partition with mods and have the phone not soft brick when you reboot. When the unlocked versions of the atrix bootloader were found it started a new round of mods. A lot of the threads prior to that are now obsolete.Q. How do I unlock the bootloader?A. There is a huge thread already about this, see here.
WARNING: this is a permanent change to your phone.
Summary:
1. Download the archive
2. Extract the sbf inside, whatever it's called, that is the one to use.
3. Use linux sbf_flash or rsdlite from windows to install it.
3. fastboot oem unlock
4. Copy code fastboot spits out.
5. fastboot oem unlock code
6. fastboot reboot
You will see unlocked while booting and when you get into android you will have ~300MB of ram. This will need to be fixed. Also, you will lose all your data during the process, do a backup first.Q. What is fastboot/moto-fastboot?A. It's a program to access the phone and do stuff, write phone partition images mostly. The stock one can only handle tiny system images, pretty useless for the Atrix, xda member eval- compiled the motorola version for us that can handle larger system images, do a search for moto-fastboot.
Ex. moto-fastboot flash recovery recovery.img.Q. How do I fix the ram problem?A. I did up a CWM recovery zip to update the boot and recovery partitions to contain a kernel command line with the missing bit "[email protected]" added. See here.
There are other means of doing this, some boot images come prepackaged with the command line already embedded. There are ATT compiled kernels with a patch inside the kernel itself to do the same thing. You can search for those when you are ready to try things like custom ATT kernels on your phone.Q. How do I root the phone?A. If you are unlocked and you have fastboot flashed a version of CWM recovery, it is trivial. By that I mean almost impossible for newbies to figure out.
It would go something like this:
1. Boot into CWM recovery.
2. use adb shell
3. adb push a su binary to the phone.
4. mount system as read write as /system
5. copy su binary to /system/bin
6. make sure it has the right permissions, 06755 mode , user root, group root.
7. unmount -l /system
8. when in android look on the market for Superuser.apk, install.
Every rooting method out there is all about putting su into /system/bin with 06755 permissions, most don't work anymore since Gingerbread. If you are looking for a simple, no brain involved solution, you are likely to get something working and also something else you didn't want like a replaced preinstall partition or an installed busybox with different functionality for some important system commands. (Busybox may be more up to date even, but if it doesn't do what is expected of the older version, it's still not good.)
Another way would be to create a CWM zip that simply puts the linux su binary in system with the correct permissions. Some info about creating your own can be found here. Doing this is more involved that just doing it manually, but it would be a good practice for getting into creating CWM updates.
Here is a link to a exploit someone did up to root the phone when running GB. Haven't tested it, and with an unlocked phone it is totally redundant, but it's nice that some found yet another security hole in the OS, seems similar in result to psneuter, so be sure to reboot the phone to fix the exploited system.
Seriously, if you are going to be reading or posting in the development section of xda for an android phone, take the 5 minutes to become familiar with adb and a few linux shell commands, it will save you hours of confusion and aggravation. If you fly blind trying things on your phone without understanding what you are doing you are eventually going to get into a place you can't get out of and need a new phone or REALLY have to struggle to understand things. You were warned. Q. How do I get back to stock?
A. You can't unless you have a backup of all your phone partitions and can update your radio and bootloader to be stock. Once you unlock your phone, it is recorded that you did so by blowing a physical fuse on the phone. This cannot be restored, you will need a new phone.
What does stock mean to you? When I bought my phone it had a certain radio, the bootloader couldn't be unlocked, the android system files had certain versions, etc. Beyond the android system there are 18 partitions that I know of on the phone, most phones do with 5-6. Every ota update or sbf files take the normal files and change them to something else, non android partitions get modified or replaced.
I have some solutions for getting close to stock, do a search for Gobstopper. There is one for Bell 2.2.2 and Bell 2.3.4, use one or the other. These attempt a full back to stock operation, that means the radio and bootloader will be stock, recovery will be stock as well. (All the partitions that are on the phone are written over with the ones that were on my phone when I bought it, with the exception of partitions 3 (pds), 15 (cache), 16 (data), and 18 (userdata or internal memory), factory reset clears cache and data, you don't want pds touched or internal memory.) Unlocked will no longer be displayed when you boot and you will no longer have CWM recovery installed. You will need to install the unlocked bootloader again and fastboot flash recovery again if stock is not what you wanted. (Your pds partition is not involved in this operation, so if you made changes to it, either directly or indirectly via a sbf this will not restore it, your pds partition contains individual phone information.)
More about sbf format here.Q. What does the pds partition taste like?A. It's not really fit to eat. Now you know.
It is mmcblk0p3, a partition on your phone, it is mounted as /pds when android boots and contains a bunch of folders and files that nobody really understands fully but Motorola. Having a look at some of the files you will see things like your network physical address, bluetooth physical address. You will find threads where the display is all arsed up, cpu running at half speed, touch screen not working right, etc, all due to something going wrong with /pds. It is best to back it up and not mess with it. Restore it in an emergency. Maybe one day everything in there will be figured out, take a stab at it yourself.
See this thread by edgan for how to back up your pds partition.
See this thread by KeRmiT80 about attempting to fix your pds partition. Good motivation to see previous link.
Q. I lost network data access after flashing X.
A. Check your APN list, if it's not a Bell firmware you are using, it probably doesn't have Bell's APN list. Scratch that, you don't know what that is or how to check it.
It stands for Access Point Name and a big list of them is stored on your phone in one big file (/system/etc/apns-conf.xml), each firmware has it's own version of it. Your phone will get two numbers from your carrier's phone network to do a look up in this list to figure out what configuration to use. So say it gets mcc 302, mcn 610, it will check the phone and look up 302, 610 in the file and read what it says there and use that config to try to connect. Now, another thing is that the phone knows what the home network is by these two numbers, embedded somewhere in the system. A foreign, non Bell carrier won't have Bell's numbers in there so your phone will think it's roaming. If you have roaming disabled, guess what, no data connection. Your carrier should be smart enough not to charge you for roaming, never had a problem with that, but you never know.
Here are the apn settings you can enter manually for your phone, see Bell's support link.
Q. How do I get webtop over HDMI to work?
A. There are several threads on getting this to work on ATT phones and others, they are specific to the firmware being run on the phone. They involve copying two deodexed files to your system/app folder and replacing the ones already there. You will also need to clear your dalvik cache to get the new code recognized. They are DockService.apk and PortalApp.apk. If you are not deodexed then you also have to remove the .odex files for both.
Here is one thread for Gingerbread, in the zip there is one for ORFR that will get you to viewing the webtop on Bell GB, but applications don't load.
Here is another thread for Froyo that works, see the Bell specific bit in the OP. This does not work from Bell Gingerbread. To be continued...
Hoping the Mods sticky this
A link should be attached to the wiki as well. I will try to when I get home if it isn't done already.
shouldn't this be in general? or q&a?
Magnetox said:
shouldn't this be in general? or q&a?
Click to expand...
Click to collapse
Probably both. Most things referenced are in development.
Cheers!
Sent from my MB860 using xda premium
y2whisper said:
Hoping the Mods sticky this
A link should be attached to the wiki as well. I will try to when I get home if it isn't done already.
Click to expand...
Click to collapse
+1 this should be a sticky on either or both general or development...
cheers for this...this thread is going to help me with my youtube viewers BIG TIME!!
Very nice!
Keep it up NFHimself!
NFHimself said:
This is my attempt at a Bell FAQ, it is a work in progress.
Q. How do I root the phone?A. If you are unlocked and you have fastboot flashed a version of CWM recovery, it is trivial. By that I mean almost impossible for newbies to figure out.
It would go something like this:
1. Boot into CWM recovery.
2. use adb shell
3. adb push a su binary to the phone.
4. mount system as read write as /system
5. copy su binary to /system/bin
6. make sure it has the right permissions, 06755 mode , user root, group root.
7. unmount -l /system
8. when in android look on the market for Superuser.apk, install.
Every rooting method out there is all about putting su into /system/bin with 06755 permissions, most don't work anymore since Gingerbread. If you are looking for a simple, no brain involved solution, you are likely to get something working and also something else you didn't want like a replaced preinstall partition or an installed busybox with different functionality for some important system commands. (Busybox may be more up to date even, but if it doesn't do what is expected of the older version, it's still not good.) To be continued...
Click to expand...
Click to collapse
I used this method to root the stock Bell Gingerbread ROM. Works on an Atrix too. It's a quick download and easy for those people who may not be comfortable with the adb command line.
http://www.psouza4.com/Bionic/
thx
useful for newbies
but can you put some more details about returning to stock and explain the pds partition in details plz?
papakilo10 said:
I used this method to root the stock Bell Gingerbread ROM. Works on an Atrix too. It's a quick download and easy for those people who may not be comfortable with the adb command line.
http://www.psouza4.com/Bionic/
Click to expand...
Click to collapse
Had a look at the script in that one, should be fine, doesn't install a busybox or anything like that. I don't care for Superuser.apk in /system/app myself, but it won't harm anything having it there.
Cheers!
ytwytw said:
thx
useful for newbies
but can you put some more details about returning to stock and explain the pds partition in details plz?
Click to expand...
Click to collapse
I added a few things, anything in particular you wanted?
I am trying to avoid step by step tutorials or spoon feeding everything, so people who are lazy/careless will have to attempt to think for themselves. It just leads to more questions, more laziness, and bricked phones, and I don't have the time these days.
Cheers!
Hi everybody!
I noticed there is another update...it should not be so strong, just minor fixes...
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/97885/p/30,6720,8302/action/auth
I haven't done it yet, but after 12 hours I have always the notice about it.
I'm using Droid 4 in Europe, so I'm not so interested.
Anyway, do you know if I will lose the root permission?
Thanks!
I currently have 98.72.18.XT894.Verizon.en.US and 4.1.2, so I'm curious as to what the new updates are for the xxxxxx.188 and xxxxx.189. I would suggest something like VooDoo OTA to attempt to save your root but there is no guarantee that it will protect it if Motorola has figured out how to patch the exploit.
From Motorola, new software is .....
98.72.188.XT894.Verizon.en.US or 98.72.189.XT894.Verizon.en.US
Voodooo worked for me on latest O.T.A
karlsdroids said:
I currently have 98.72.18.XT894.Verizon.en.US and 4.1.2, so I'm curious as to what the new updates are for the xxxxxx.188 and xxxxx.189. I would suggest something like VooDoo OTA to attempt to save your root but there is no guarantee that it will protect it if Motorola has figured out how to patch the exploit.
From Motorola, new software is .....
98.72.188.XT894.Verizon.en.US or 98.72.189.XT894.Verizon.en.US
Click to expand...
Click to collapse
I used Voodoo root keeper for the latest ota update. Worked for me. Just needed to reinstall SU
mercermtn said:
I used Voodoo root keeper for the latest ota update. Worked for me. Just needed to reinstall SU
Click to expand...
Click to collapse
ok! thank you for your answer...
except for what mentioned by Motorola, the update changes something else? I mean speed or other aspects?
Same with voodoo here, didn't uninstall the SU app though
Sent from my XT894 using Tapatalk
Using voodoo to temp unroot and install the update did not work for me. I've decided to pass on the update and instead I'll just do a different rom. I found what the update consisted of and basically it's "bug fixes and security updates"- no real benefit there for me.
woodoo didn't work for me...can I use the same procedure to root again?
Sent from my DROID4 using xda app-developers app
For those who failed with voodoo, you could try Saferoot, it harmless to try...
Just root my RAZR HD although it designed for VZW Galaxy S4...
http://forum.xda-developers.com/showthread.php?t=2565758
I used voodoo on my wife's phone. Saved the su binary, installed the ota, clicked restore root. Voodoo said root restored but the check box for root stayed empty and root apps didn't work (like titanium backup). Found a post that gave terminal commands to manually restore the su backup. Worked perfectly and I now have root back. I forgot the link but luckily I copied and pasted the steps. So If voodoo said it worked but didn't, give this a try...
(I'd give credit where credit is due but lost the link)
"My wife's Transformer Infinity exhibited basically the same behaviour after its last 2 updates (both 4.2.something, IIRC). Fortunately the backup copy of su was intact, as it likely is in your case, and I was able to restore it manually using a terminal emulater app... adb would presumably have worked as well, but my notebook wasn't available at the time. Here's what I did.
.
1. Launch the terminal emulater of your choice (I used Better Terminal Emulater Pro, but the specific app probably doesn't matter)
.
2. Go to the location of the backup copy.
===========================
cd /system/usr/we-need-root
===========================
.
3. Use the su backup to obtain a root shell. This should trigger the usual superuser popup/notification, assuming that it's configured to do so.
=================
./su-backup -
=================
.
4. Remount the /system partition in read/write mode.
============================
mount -o remount,rw /system
============================
.
5. Copy the su backup to the proper location, taking care to keep the permissions intact.
=============================
cp -p su-backup /system/xbin/su
=============================
.
6. Remount the /system partition in the normal, read-only mode.
=============================
mount -o remount,ro /system
=============================
.
7. Reboot the device (might not be strictly required), to ensure that any root-enabled background apps are able to startup cleanly.
.
The usual disclaimers apply, of course. Your device might not have the same configuration as mine, etc., so these commands may need some tweaking. Also, if it was a 4.3 upgrade which caused you to lose root then this procedure likely won't work... I believe that su needs to be running in daemon mode in order to grant privileges, which certainly won't be the case for the backup copy (even if it is a 4.3-compatible version).
squall90x said:
Hi everybody!
I'm using Droid 4 in Europe, so I'm not so interested.
Thanks!
Click to expand...
Click to collapse
I too use this in Europe, and made the mistake of accepting this OTA update, which bricked my data connectivity. More info in this post:
http://forum.xda-developers.com/showpost.php?p=49627296&postcount=23
mike-phone said:
I too use this in Europe, and made the mistake of accepting this OTA update, which bricked my data connectivity. More info in this post:
http://forum.xda-developers.com/showpost.php?p=49627296&postcount=23
Click to expand...
Click to collapse
My data connectivity works without problems...
squall90x said:
My data connectivity works without problems...
Click to expand...
Click to collapse
Your reply inspired me to dig a bit deeper. It looks like the OTA update just cleared the list of APNs. I re-added the APN, and it works fine. Thanks.
mike-phone said:
Your reply inspired me to dig a bit deeper. It looks like the OTA update just cleared the list of APNs. I re-added the APN, and it works fine. Thanks.
Click to expand...
Click to collapse
You're welcome!
Sorry I didn't tell you...it was the same also for me!!
androitri said:
For those who failed with voodoo, you could try Saferoot, it harmless to try...
Just root my RAZR HD although it designed for VZW Galaxy S4...
http://forum.xda-developers.com/showthread.php?t=2565758
Click to expand...
Click to collapse
Thank you so much for this link. I accepted this OTA update about a week ago and lost my root access, despite having run Voodoo OTA Rootkeeper (maybe I did something wrong?) I tried to re-root it using the Razr Blade tool (which is what I had used originally to get root access), but that didn't work. Apparently motorola/verizon plugged the smart action security hole. But this one (saferoot) got the job done. Back to wifi tethering; thanks!
Richard
edit: I have the Droid 4 XT894, and the OTA update which broke my root was 98.72.189.XT894.Verizon.en.US
squabeggz said:
I used voodoo on my wife's phone. Saved the su binary, installed the ota, clicked restore root. Voodoo said root restored but the check box for root stayed empty and root apps didn't work (like titanium backup). Found a post that gave terminal commands to manually restore the su backup. Worked perfectly and I now have root back. I forgot the link but luckily I copied and pasted the steps. So If voodoo said it worked but didn't, give this a try...
(I'd give credit where credit is due but lost the link)
"My wife's Transformer Infinity exhibited basically the same behaviour after its last 2 updates (both 4.2.something, IIRC). Fortunately the backup copy of su was intact, as it likely is in your case, and I was able to restore it manually using a terminal emulater app... adb would presumably have worked as well, but my notebook wasn't available at the time. Here's what I did.
.
1. Launch the terminal emulater of your choice (I used Better Terminal Emulater Pro, but the specific app probably doesn't matter)
.
2. Go to the location of the backup copy.
===========================
cd /system/usr/we-need-root
===========================
.
3. Use the su backup to obtain a root shell. This should trigger the usual superuser popup/notification, assuming that it's configured to do so.
=================
./su-backup -
=================
.
4. Remount the /system partition in read/write mode.
============================
mount -o remount,rw /system
============================
.
5. Copy the su backup to the proper location, taking care to keep the permissions intact.
=============================
cp -p su-backup /system/xbin/su
=============================
.
6. Remount the /system partition in the normal, read-only mode.
=============================
mount -o remount,ro /system
=============================
.
7. Reboot the device (might not be strictly required), to ensure that any root-enabled background apps are able to startup cleanly.
.
The usual disclaimers apply, of course. Your device might not have the same configuration as mine, etc., so these commands may need some tweaking. Also, if it was a 4.3 upgrade which caused you to lose root then this procedure likely won't work... I believe that su needs to be running in daemon mode in order to grant privileges, which certainly won't be the case for the backup copy (even if it is a 4.3-compatible version).
Click to expand...
Click to collapse
After some days I found time to try...
I put the same command and reboot and it worked!!
Thank you so much!!
I've done a fair amount of research and am still having trouble getting this installed on an emulated device. I have tried the base adt-sdk images for 4.1.2, 4.3 and 4.4.2 none of which I was able to attain the same "rooted" functionality as a phyical device. Most of the threads I read were a lot like this: http://forum.xda-developers.com/showthread.php?t=1731095
Xposed always gives me the following error: "Failed to get root access. Make sure your device is root properly and you have not blocked shell commands."
When I
Code:
adb shell
into the device I have [email protected], so I have access to root. The su binary is in both /system/bin and /system/xbin. I have also tried remounting the /system partition as rw, but nothing seems to help.
I'm not sold on any particualr version of android as long as it is >=4.1.2. I know some SELinux stuff came in at 4.3.
Any help you could offer would be great,
Thanks!
It worked flawlessly for me using Genymotion. I'm guessing you're using the normal Android emulator - apps won't get root on that directly and I'm not familiar with it.
You could, however, manually replace the necessary files. I'd recommend changing the installation mode to "Recovery" then checking the flashable ZIP's updater-script and basically replicate it from the shell (the updater-script is a shell script).
GermainZ said:
It worked flawlessly for me using Genymotion. I'm guessing you're using the normal Android emulator - apps won't get root on that directly and I'm not familiar with it.
You could, however, manually replace the necessary files. I'd recommend changing the installation mode to "Recovery" then checking the flashable ZIP's updater-script and basically replicate it from the shell (the updater-script is a shell script).
Click to expand...
Click to collapse
Where does it drop the script?
Blackdragon1400 said:
Where does it drop the script?
Click to expand...
Click to collapse
The script is inside the ZIP, which I think I saved to /sdcard/Android/data/de.robv.android.xposed.installer/ - check the output on your screen after pressing install, it should be noted there.
GermainZ said:
The script is inside the ZIP, which I think I saved to /sdcard/Android/data/de.robv.android.xposed.installer/ - check the output on your screen after pressing install, it should be noted there.
Click to expand...
Click to collapse
Alright, I will give it a try tomorrow, and post an update on the results. Thanks for the help!
Note that there are still a few minor things that are done via root, even when using the manual recovery installation mode. So the app needs to get root access.