Related
Current Status 7/14
Without the NAND being unlocked, we are unable to re-write to the recovery partition. Other than that everything is working good. Unlocked NAND=One Click Root!
This method is directly based on the new root process for the Eris released on xda.
Original thread can be found here
The following information is taken directly from the thread mentioned above with some small modifications by me for the Incredible.
Big thanks to tereg for the toolkit and the guys who rooted the EVO with a file write/chmod race condition exploit that gave me the idea for this.
jcase noticed that a race isn't actually nessisary to exploit the chmod 777 on the file I've been working with, simplifying the script alot.
I used the files from the adb development pack that Tereg put together. Download them here. You don't need them for this root process as long as you have a working adb install.
You will need adb access. Install the android sdk for your platform (macos, windows, linux) get it for your OS here.
If you don't know how to install the sdk, search xda, there are a ton of howtos for that.
Files to download:
hack-v5-DINC.zip
A ROM file
Android SKD (skip if you have a working adb)
Instructions for linux/OSX.
Have adb in your path, or move the files contained in hack-v5-DINC.zip into your sdk/tools directory so your pushes will work properly.
FOR ALL OS's Make sure your phone has Applications->Development->USB Debugging turned on.
Do NOT have your phone in Disk Drive Mode, have it in Charge Only.
Open a terminal window in your /tools/ directory. Type this at the prompt.
Code:
sh runinlinux.sh
This will take a few minutes, follow the instructions on your screen.
If you get adb: command not found, edit runinlinux.sh and change every
Code:
#/bin/bash
adb push flash_image /data/local/
adb push recovery.img /data/local/
adb push testfile /data/local/
etc...
to
Code:
./adb push flash_image /data/local/
./adb push recovery.img /data/local/
./adb push testfile /data/local/
etc...
Instructions for windows (thanks tereg!)
Download the hack.zip file and extract it to the desktop. So, you have a folder on the desktop called hack. I would recommend moving or copying those files (EDIT: that are contained in the hack folder) to the C:\android-sdk-windows\tools folder. Why? Because the script runs "adb ____" commands, and unless you've set up adb to be able to run anywhere within the command prompt, the script won't run. So, it will universally work if the files in the hack folder are placed in C:\android-sdk-windows\tools
So, open a command prompt by pressing WindowsKey+R, or going to Start-Run (in WinXP) and typing
Code:
cmd
in the text box there and press OK
If you are in Windows Vista/Windows 7, go to the Start Menu, then type in
Code:
cmd
in the search bar in the lower right-hand corner of the start menu and press enter, and locate Command Prompt in the search results, or go to Start -> All Programs -> Accessories -> Command Prompt
Type
Code:
cd C:\android-sdk-windows\tools
and press enter
Now, I recommend pushing the ROM you want to flash to the SD card now.
Code:
adb push ROM.zip /sdcard
Then, type
Code:
runindos.bat
to execute the script.
You might have to run it 2 or 3 times for it to work. If it fails, just reboot the phone normally, then run
Code:
runindos.bat
again once the phone is booted back up and you're ready.
----------(Thanks again tereg!)
It will scan for a long time, give it at least 5 minutes. If it doesn't come back after 5 minutes cntrl +c to stop it, start the process again. MOST PEOPLE HAVE TO RUN THIS AT LEAST TWICE!
If your device reboots into a new screen with options on it, you now have root in recovery mode. At this point you will be flashing your Incredible's brains, so YOUR PHONE WILL BE BLANK AFTER LOADING A NEW ROM! All of your apps/numbers will be gone from the phone.
I suggest a nand backup first.
Download and copy one of these ROM's to your sdcard as update.zip and flash it with flash zip from sdcard by selecting "Install zip from sdcard".
The first boot after loading a new ROM takes quite a while to show any activity to the screen. Give it a good 5 minutes before you start wondering if it's ever going to come back.
---
runinlinux.sh
---
Code:
#/bin/bash
adb push recovery.img /data/local/
adb push flash_image /data/local/
adb shell chmod 777 /data/local/recovery.img
adb shell chmod 777 /data/local/flash_image
adb shell rm /data/local/rights/mid.txt
adb shell ln -s /dev/mtd/mtd1 /data/local/rights/mid.txt
echo "Files copied and permissions set, rebooting HTC Andriod 2.1"
adb reboot
echo "Your phone will now reboot into normal mode, then reboot into recovery mode. If it does not reboot the second time, wait 10 minutes and manually reboot and begin again."
echo "Your phone is now rebooting in Rooted Recovery mode, do a backup and load your ROMs"
adb wait-for-device
adb shell /data/local/flash_image recovery /data/local/recovery.img
adb reboot recovery
---
runindos.bat
---
Code:
@echo off
adb push recovery.img /data/local/
adb push flash_image /data/local/
adb shell chmod 777 /data/local/recovery.img
adb shell chmod 777 /data/local/flash_image
adb shell rm /data/local/rights/mid.txt
adb shell ln -s /dev/mtd/mtd1 /data/local/rights/mid.txt
echo "Files copied and permissions set, rebooting HTC Andriod 2.1"
echo "Your phone will now reboot into normal mode, then reboot into recovery mode. If it does not reboot the second time, wait 10 minutes and manually reboot and begin again."
adb reboot
adb wait-for-device
echo "Your phone is now rebooting in Rooted Recovery mode, do a backup and load your ROMs"
adb shell /data/local/flash_image recovery /data/local/recovery.img
adb reboot recovery
This thread is intended to be an think-tank, similar to the one on the eris forums where I got the idea from. Let the ideas flow!
has this been tested to work on the INC? if not why has this been posted.
outsid0r said:
has this been tested to work on the INC? if not why has this been posted.
Click to expand...
Click to collapse
uhm....do you read?
"This thread is intended to be an think-tank, similar to the one on the eris forums where I got the idea from. Let the ideas flow!"
no. this is not working yet. thats why the title even has {development} in it. the process is almost working, and this is a develpoment thread to work out the issue-which is also in big letters at the top...see where it says
"Without the NAND being unlocked, we are unable to re-write to the recovery partition. Other than that everything is working good. Unlocked NAND=One Click Root!"
So once we solve a much more difficult problem, the less difficult will be easier.
Makes sense.
We already know how to unlock the nand vs the exploit posted last night...also unrevoked will have it done In a few days anyway
Sent from my HTC Incredible using the XDA App
adrynalyne said:
So once we solve a much more difficult problem, the less difficult will be easier.
Makes sense.
Click to expand...
Click to collapse
the difficult problem has already been solved. the unrEVOked team already has the NAND unlocked. now its whether they want to share and make it a true one-click root method, or if they are going to keep it a secret and keep koush's clockworkmod recovery as the only possibility. this tool still uses the clockworkmod recovery, but after a NAND unlock your given the option to change. since koush is working for them too, im starting to think more and more that they are going to keep the monopoly.
im hoping that they will just incorporate their NAND unlock method into this root process. they can even re-lock it after the process is done as they do in their re-flash tool to preserve the monopoly, but a true one-click root is now possible with their co-operation. ive messaged them asking if they want to help out. we will see soon enough, so cross your fingers!
they can even re-lock it after the process is done as they do in their re-flash tool to preserve the monopoly
Click to expand...
Click to collapse
You just lost a ton of respect from me, and I suspect more than a few others. Talk about biting the hand that feeds you.
adrynalyne said:
You just lost a ton of respect from me, and I suspect more than a few others. Talk about biting the hand that feeds you.
Click to expand...
Click to collapse
So I see we have this starting up again....shakes head at OP..
@adrynalyne best to just ignore these people...its not like the winmo days is it man? Le sighe
Good advice, you are right. I will ignore this stuff in the future.
No, not like the winmo days at all. I've never seen so much anomisity and jealousy in a community before like there is for Android.
All I can say is we already intended to release this method, we were making a pretty robust obfuscation for it. But again the community has jumped before thinking and posted the bug for HTC to fix. There might not be any root's left after this one is burnt. Which it now is. Our tool will be released as is soon enough.
We don't care to create a monopoly, we happily work with others that ASK. Those that just jump and tell the world all the secrets we don't want plugged are just stupid, plain and simple.
adrynalyne said:
You just lost a ton of respect from me, and I suspect more than a few others. Talk about biting the hand that feeds you.
Click to expand...
Click to collapse
LOL Whatever, it isnt like respect from you is something anyone cares about. I like someone with the nerve to speak the truth no matter how unpopular it might be.
outsid0r said:
has this been tested to work on the INC? if not why has this been posted.
Click to expand...
Click to collapse
Please read. Think tank! I applaud this dude for trying. More than many others do here!
fader01 said:
LOL Whatever, it isnt like respect from you is something anyone cares about. I like someone with the nerve to speak the truth no matter how untrue it might be.
Click to expand...
Click to collapse
Fixed that for ya.
adrynalyne said:
You just lost a ton of respect from me, and I suspect more than a few others. Talk about biting the hand that feeds you.
Click to expand...
Click to collapse
Shadowmite said:
All I can say is we already intended to release this method, we were making a pretty robust obfuscation for it. But again the community has jumped before thinking and posted the bug for HTC to fix. There might not be any root's left after this one is burnt. Which it now is. Our tool will be released as is soon enough.
We don't care to create a monopoly, we happily work with others that ASK. Those that just jump and tell the world all the secrets we don't want plugged are just stupid, plain and simple.
Click to expand...
Click to collapse
it seems like my comment was taken the wrong way.
for one, clockworkmod recovery is the only one that works on the DINC AFAIK, amon_ras isnt working on here either.
the monopoly is basically a monopoly because of the lack of other available options, not necessarily because its enforced.
i apologize if it came off the wrong way or insulted anyone with the preceding comments.
i meant this thread as a co-operative think-tank, it wasnt my intention to start a big ordeal.
adrynalyne said:
Good advice, you are right. I will ignore this stuff in the future.
No, not like the winmo days at all. I've never seen so much anomisity and jealousy in a community before like there is for Android.
Click to expand...
Click to collapse
@adrynalyne yeah its a real rough community at times, but what ya gonna do right...its hard for me to ignore them at times too
@shadowmite. thanks for your guys hard work....the ignorant ones are everywhere nowadays, hope they don't get you guys down.
Cheers!
Shadowmite said:
All I can say is we already intended to release this method, we were making a pretty robust obfuscation for it. But again the community has jumped before thinking and posted the bug for HTC to fix. There might not be any root's left after this one is burnt. Which it now is. Our tool will be released as is soon enough.
We don't care to create a monopoly, we happily work with others that ASK. Those that just jump and tell the world all the secrets we don't want plugged are just stupid, plain and simple.
Click to expand...
Click to collapse
hmm. well i guess thats what happens when people try to help out the community...maybe next time i just wont do anything... :/
and FYI...i did contact you. i sent you a PM earlier today.
this method has been used on the EVO and hasnt been plugged, and its been in the works on the Eris-also an HTC phone- for quite a long time, and in the same way this is...a co-operative community effort to make the phone the best that it can be.And its still not been plugged.
id worry less about HTC plugging the exploits and more about getting the exploits available to the public.
Correct, you are not the original one leaking the method. But my point is devs capable of finding things like this should be capable of thinking about it being plugged. HTC fixed our recovery hold in the next OTA. Now it's quite possible nand and this root will be patched also. we have NO OTHER WAYS IN... Thats it. besides some VERY complicated exploits we are OUT after the next ota.
I got your pm's, but only after you posted this.
It's a moot point, our one click root is due out in a few minutes. we were going to further lengths to protect the method, but it's out anyway at this point.
Shadowmite said:
Correct, you are not the original one leaking the method. But my point is devs capable of finding things like this should be capable of thinking about it being plugged. HTC fixed our recovery hold in the next OTA. Now it's quite possible nand and this root will be patched also. we have NO OTHER WAYS IN... Thats it. besides some VERY complicated exploits we are OUT after the next ota.
I got your pm's, but only after you posted this.
It's a moot point, our one click root is due out in a few minutes. we were going to further lengths to protect the method, but it's out anyway at this point.
Click to expand...
Click to collapse
well i apologize for the fact that i may/may not have ruined your chances to make a big announcement for your release, but IMO its kinda bs that you keep the info on lockdown. the whole point of android is that its open. a select amount of people shouldnt consider themselves the gatekeepers of important information.
ban_dover said:
well i apologize for the fact that i may/may not have ruined your chances to make a big announcement for your release, but IMO its kinda bs that you keep the info on lockdown. the whole point of android is that its open. a select amount of people shouldnt consider themselves the gatekeepers of important information.
Click to expand...
Click to collapse
From our wiki, which you appearently haven't read:
http://unrevoked.com/rootwiki/doku.php/public/unrevoked2
That doesn't seem fair! Android is about open source.
In some senses, we agree; but at times, a tradeoff needs to be made. Releasing the source code for this, we believe, would compromise the greater ability to unlock devices like these in the future. Given the choice between sacrificing the liberty of running code on our handsets and the liberty of reading the code by which we unlock it, we feel that the millions of handsets are more important. It is unfortunate that we must make such a choice, and we look forward to the day in the future that no such decision need be made.
Click to expand...
Click to collapse
Shadowmite said:
From our wiki, which you appearently haven't read:
Click to expand...
Click to collapse
already read it.
i dont take my opinions from things i read. i take the information and draw my own conclusions. and in this case my conclusion is that, while i can see your point i still disagree.
A soft brick, in this case, is when you make a bad edit to your framework files and the phone won't fully boot and starts flashing a red LED at you.
There is one catch, you only get about 1-2min to do all of this before the phone reboots on its own. If that happens, do SuperOneClick steps again and continue where you left off. Better yet, build a script to do it all for you
Power off your device
Enter Fastboot:
Hold Volume down + power until you see Fastboot at the top left
Use volume down to scroll down to "Early USB Enumeration" (only shows one item at a time, if you pass it, keep going down, up selects)
Press Volume up to select
Wait for ADB to enable, run "Shell Root" from SuperOneClick, wait until it says you have root.
Enter adb shell from command line, You should have root(#) access:
adb shell
Mount the system directory as read/write:
mount -o rw,remount /dev/block/mmcblk0p12 /system
Make a new directory on /data for your recovery files: (sdcard wont be mounted yet)
mkdir /data/recover
Exit adb shell:
exit
Push your known working files to the new directory:
adb push /path/to/local/file.ext /data/recovery
Enter adb shell from command line:
adb shell
Copy your newly pushed recovery files to their proper location:
cp /data/recover/services.jar /system/framework
cp /data/recover/framework.jar /system/framework
cp /data/recover/famework-res.apk /system/framework
Reboot:
reboot now
Thanks! Extremely happy you are deving for this phone
What's the best way to backup my stock partitions before I keep playing with those files?
Titan Backup works for that?
Or just a tar cf /mnt/sdcard/systembackup.tar /system , works?
Thanks in advance.
uskr said:
What's the best way to backup my stock partitions before I keep playing with those files?
Titan Backup works for that?
Or just a tar cf /mnt/sdcard/systembackup.tar /system , works?
Thanks in advance.
Click to expand...
Click to collapse
I would just use the tar solution, much easier to deal with.
You can also use ADB, adb pull /system system
Also, the retail dump I did matched my phone dump bit for bit, as long as you have that you should be fine.
Thanks! I am messing around with the APKs and scripts to get the webtop to work without the dock. So I wanted to make sure I was covered.
designgears said:
I would just use the tar solution, much easier to deal with.
You can also use ADB, adb pull /system system
Also, the retail dump I did matched my phone dump bit for bit, as long as you have that you should be fine.
Click to expand...
Click to collapse
I already did both adb pull of system and tar, but how did you do the retail dump?
lpsi2000 said:
I already did both adb pull of system and tar, but how did you do the retail dump?
Click to expand...
Click to collapse
tar dump as root of system
One last question.
Once I deodex my /system/app, should I just do a adb push app /system/app and then rm /system/app/*.odex ?
I am used to use the update.zip trick on the captivate. But I am not sure how to proceed on this phone.
uskr said:
One last question.
Once I deodex my /system/app, should I just do a adb push app /system/app and then rm /system/app/*.odex ?
I am used to use the update.zip trick on the captivate. But I am not sure how to proceed on this phone.
Click to expand...
Click to collapse
push apps, then push framework, reboot, then delete all the odex files, reboot
from system do something like; find . -name "*.odex" -exec rm {} \;
designgears said:
push apps, then push framework, reboot, then delete all the odex files, reboot
from system do something like; find . -name "*.odex" -exec rm {} \;
Click to expand...
Click to collapse
Unrelated to this, I could sware yesterday I got to the recovery screen where I was able to wipe stuff and also be able to use update.zip. Although I did not use and update files but saw the option there. Today I am looking everywhere but the recovery screen does not come up with the options. I only see exclamation point and the droid. May be I am going nuts but can anyone confirm this.
lpsi2000 said:
Unrelated to this, I could sware yesterday I got to the recovery screen where I was able to wipe stuff and also be able to use update.zip. Although I did not use and update files but saw the option there. Today I am looking everywhere but the recovery screen does not come up with the options. I only see exclamation point and the droid. May be I am going nuts but can anyone confirm this.
Click to expand...
Click to collapse
tap at the bottom right of the screen right above the search button
designgears said:
tap at the bottom right of the screen right above the search button
Click to expand...
Click to collapse
ahha, thank you. Now I know I am going crazy. I used it yesterday to wipe when the system was unstable on me after playing around with the framework. I am must have stumble on that by accident. I am wondering if this documented yet somewhere around here.
Also too bad we cannot get root from there yet.
Well thank you for this. So when it boots to run, does it do a sys check to verify files are the same size or what? Anyway went to my local AT&T store and they swapped it out for me.
realawill said:
Well thank you for this. So when it boots to run, does it do a sys check to verify files are the same size or what? Anyway went to my local AT&T store and they swapped it out for me.
Click to expand...
Click to collapse
No, I just made a bad edit and it was FC hell
IT DOES NOT WORK WITH ME
I have been trying this trick for many times. The device restart and SuperOneClick hanging without any result.
designgears said:
No, I just made a bad edit and it was FC hell
Click to expand...
Click to collapse
Crazy....mine just would not reboot. But good to know that there is a way to recover. Love the phone but hate Motorola. Wish that it was easy as the Cappy.
Cool stuff. I may snatch the framework off the phone in stock form and make a batch package for this so folks can easily just double click to restore their framework and system app folder.
Good work DG...
I never get past that initial... Starting RSD protocol support screen. Is that fast boot? If so I'm a retard...
EDIT: I need the face palm sticky. It's not Volume UP...it's Volume Down. Reading comprehension for the loss...
azy8000 said:
IT DOES NOT WORK WITH ME
I have been trying this trick for many times. The device restart and SuperOneClick hanging without any result.
Click to expand...
Click to collapse
I have done this several times now, it works
I soft bricked my Atrix earlier this morning, and used this to recover. The time limit is a serious pain!
I ended up needing to separate /system into 5 separate pushes of 30MB each in order to get them done in time.
Oddly, after restoring everything, the phone is no longer associated with my motoblur account, and I can't add it.
Also, I think there my be some files in /system that are unaccounted for by the filesystem, as there is 70MB more than what is present.
Edit:
Restoring the system fixed both above problems.
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!
I am posting this here in hopes that some of you heed my warning.
The permanent root method was released so that when, and its coming, when motorola pushed out an update you would maintain root through the update. I never intended for everyone to use it to update their devices to 5.5.891/892/893. Updating to those updates still bears some risk as you are officially off the update path until we find out what the next update is, and if it is not one of those listed above, you could have your phone stuck not being able to fully update.
Truthfully, I think people should have fun and that is what android is about in my eyes but just flashing newer builds to say "hey I'm now on .893" is not, in my opinion, prudent.
How the root method works:
When init runs at the start of the booting process is runs files in the init.rc, one of those files is mount_ext3.sh. When you add that code to the end of the file you have told the kernel to give the 4755 permission to su, which means you will always have root.
How to check if it works:
This part opens your phone up and is dangerous, I only use it to check to make sure my script is running correctly.
add the following line (this will perma mount system as r/w DANGEROUS) mount -o rw,remount /dev/null /system.
reboot your device.
using rootexplorer (or something similar) go to /system you should see MOUNT R/O in top right corner.
if you see that then I suggest going back to mount_ext3.sh and removing the mount command.
---------------------------
There you have it, be careful.
****Always ensure that your mount_ext3.sh is given correct permissions 4755 ****
jimmydafish said:
****Always ensure that your mount_ext3.sh is given correct permissions 4755 ****
Click to expand...
Click to collapse
The instructions say to push mount to /data/local then mount system as rw then cat mount to /system/bin then to chmod 777 mount.
Are you saying to chmod 4755 mount instead of chmod 777?
I am not understanding what you are saying.
P3-
I'm on 893. Would I be able to nandroid back to one of my 875 backups if I wanted?
Just curious.
Sent from my DROID BIONIC using xda premium
twinkyz1979 said:
The instructions say to push mount to /data/local then mount system as rw then cat mount to /system/bin then to chmod 777 mount.
Are you saying to chmod 4755 mount instead of chmod 777?
I am not understanding what you are saying.
Click to expand...
Click to collapse
They do same thing.
mistawolfe said:
P3-
I'm on 893. Would I be able to nandroid back to one of my 875 backups if I wanted?
Just curious.
Sent from my DROID BIONIC using xda premium
Click to expand...
Click to collapse
875? You should be able to though.
jimmydafish said:
875? You should be able to though.
Click to expand...
Click to collapse
Would that not keep the radio and kernel from 893 since the bootloader is locked?
I have no idea just asking.
jimmydafish said:
875? You should be able to though.
Click to expand...
Click to collapse
Durp. Do I mean 886? Whatever the stock build was.
Sent from my DROID BIONIC using xda premium
mistawolfe said:
P3-
I'm on 893. Would I be able to nandroid back to one of my 875 backups if I wanted?
Just curious.
Sent from my DROID BIONIC using xda premium
Click to expand...
Click to collapse
I say try it and let us know
Sent from my DROID BIONIC using XDA App
Thanks, P3, for posting this, both for the technical information about the Forever root and for the warning. I had felt a bit uneasy about the process (specifically flashing an unreleased update) and kept me from jumping on that wagon, but I assumed that was simply me being noobish and cowardly. Hearing your warning makes me feel a bit less crazy.
That said, I had one other technical question about the Permaroot itself. As you say, this rooting method involves editing the filesystem loader to change the permission on the su binary, among others, at boot.
isn't this actually a relatively easy thing for a future update to break? If they modify/replace the mount_ext3.sh file in a future update, while closing other exploit holes, then next time the phone boots (failing to change the permissions back), won't we be back where we started? In other words, resumably the updater has root permission, so what's to stop it from changing this file back and rebooting?
What am I missing here? Sorry for the silly question!
wanderfowl said:
Thanks, P3, for posting this, both for the technical information about the Forever root and for the warning. I had felt a bit uneasy about the process (specifically flashing an unreleased update) and kept me from jumping on that wagon, but I assumed that was simply me being noobish and cowardly. Hearing your warning makes me feel a bit less crazy.
That said, I had one other technical question about the Permaroot itself. As you say, this rooting method involves editing the filesystem loader to change the permission on the su binary, among others, at boot.
isn't this actually a relatively easy thing for a future update to break? If they modify/replace the mount_ext3.sh file in a future update, while closing other exploit holes, then next time the phone boots (failing to change the permissions back), won't we be back where we started? In other words, resumably the updater has root permission, so what's to stop it from changing this file back and rebooting?
What am I missing here? Sorry for the silly question!
Click to expand...
Click to collapse
yes it is, but i checked every update that I have from Motorola, that is at least 75+ if not more...they have never updated that unless they pushed an entire new system. But there are other things available as well.
wish i would of read this before i screwed my phone up. hopefully not for good.
I'm a huge fan of you're work and this post is proof that professionalism is every day life for you...thanks for the clarification, and I'm still a fan.
hmmm
neckbonest said:
wish i would of read this before i screwed my phone up. hopefully not for good.
Click to expand...
Click to collapse
well i guess i better start getting happy with rooted 893 and be damn sure I dont soft brick until you smarties figure it out.
well 893 works well enough. I can (as long as I am extremely careful and lucky ) install future roms at least. Right, as long as I dont softbrick. If I do is there a more preferable method than fastboot to restore with root?
stoffelck said:
well i guess i better start getting happy with rooted 893 and be damn sure I dont soft brick until you smarties figure it out.
well 893 works well enough. I can (as long as I am extremely careful and lucky ) install future roms at least. Right, as long as I dont softbrick. If I do is there a more preferable method than fastboot to restore with root?
Click to expand...
Click to collapse
As a side note, you will be able to nandroid back and forth as you are only changing system.
But the issue is that future updates need a virgin system and when you frankenstein your system most likely it will fail the webtop install..
I have created system only update zips from .886 -> 893, and 891 ->893, and 892 -> 893. If you want to test out .893 without needing to install it fully let me know.
ups2525 said:
I'm a huge fan of you're work and this post is proof that professionalism is every day life for you...thanks for the clarification, and I'm still a fan.
Click to expand...
Click to collapse
I attempt to be, every so often I like to give back what I receive.
So I nandroided back (to 893 from unleashed 2) and I seem to be having the same radio issues as before, yet my baseband is different (than original stock) and my phone idle has gone down.
Anybody else seen this?
Sent from my DROID BIONIC using xda premium
fxz back to "pure" stock from this?
jntdroid said:
fxz back to "pure" stock from this?
Click to expand...
Click to collapse
Look here: http://rootzwiki.com/showthread.php...-ROOT-after-893-OTA-OOPS)&p=189877#post189877
Sent from my DROID BIONIC using xda premium
So let me get this straight....if we are on rooted 893 can we or can we not get back to 886 with the stock kernal, webtop, and radio?
Sent from my DROID BIONIC using Tapatalk
You CANNOT get back the stock kernel or radio once you have updated to. 893.
You can flash the system back while still on the new kernel, radio and boot files, the so called "bastard hybrid".
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.