Preamble
What I write here is what I did. BUT I am not responsible of damages you could do your phones. Be careful and safe. If you do not know what you are doing, do not do this.
This is not a method to unbrick your phone. Unfortunately, I did not succeed to do that. It is a method to unroot: to cleanse any trace of rooting. In my case, it was to give it back to my store.
The rooting method I used is the "Universal Gingerbread Root (by StoneBoyTony)" I found here: http://forum.xda-developers.com/showthread.php?t=1192122 (scroll down a bit). This method is to root your Gingerbread phone through the recovery mode by unpacking a zip file (keep this file in mind). Thus, this tutorial is concerning this rooting method. I did not try with other rooting methods. So take care.
Code:
something to write
is what you have to type.
something to expect/read
Click to expand...
Click to collapse
is what you should read at your side.
Read before writing. Like students (should) do in classes.
My computer runs Windows XP SP3. Just saying.
This is my first thread. Please, be cool with me
Finally, do not confuse rooting and unlocking.
To root a phone is to allow the user to be a super-user on the phone, which means: to have greeeaaaat powers.
To unlock means to use any carrier with the phone by getting the unlock code.
Hence, to get the unlock code, you often have to root your phone to access to sensible data (cf. stl5 story).
I - Introduction
(= useless blabla but informative)
I bought some Samsung Gio cellphones (Bell prepaid, Canada) at a pretty good price ($80, thanks redflagdeals for the deal!), in order to go with another carrier (Chatr).
Characteristics of the Bell's Samsung Gio prepaid cell:
GT-S5660M
Gingerbread 2.3.4
S5660MUGKG3
GT-S5660DSMBMC
Click to expand...
Click to collapse
For the first one, I retrieved the unlock code through what I call the "stl5 way". It worked without any issue. Cool. Next!
For the second one... Oh snap.
Issues began after getting the unlock code and a rebooting. Kinda weird since I exactly did like the first one. Problems were:
No sound at the Samsung animation
Too many minutes to initialize
When I could reach the pad to call a number, the pad was so laaaaggggyyyy
Fly mode is stuck
No more IMEI (nooooooooooooo)
Doing *#7465625# does not display any information about the network lock, sp/cp lock (it displays labels but no values at all)
Turning off the cellphone was very long too...
...but it was not a shutdown: the cellphone was rebooting, weird
Random warnings (even got a warning from "com.android.phone"!)
Putting another SIM card from another carrier did not even notice me to unlock the phone
And so on. Like some folks, I did not really brick it, but like some others, the phone became... unusable.
What I call the "stl5 way" is the unlocking method which can succeed... or not, it depends. Weird isn't it? Unfortunately, I didn't know.
xda and rfd links which explain the stl5 unlocking method:
http://forum.xda-developers.com/showthread.php?t=1204705
http://forum.xda-developers.com/showthread.php?t=1192122
I absolutely advise against this method. BEWARE.
It seems that the /dev/stl5 partition is madly protected. When we use/read/smurf it, it corrupts some data of the phone which could lead to (partially) brick your phone.
Thus, the safest way (nobody failed) so far to unlock your phone is the "bml5 way":
http://forum.xda-developers.com/showpost.php?p=17148825&postcount=334
http://forum.xda-developers.com/showthread.php?p=17247878
II - Plat de résistance
Ok, you used the stl5 way and your phone just took 80yo: it is slow, forgot a lot of information, and some other symptoms I wrote earlier.
Or you just want to unroot your phone, because it's cool.
If there is still no method to unbrick (or it did not succeed), you can give it back to your store or to use the Samsung warranty. You may have to unroot it (get all chances on your side).
- Tools/weapons you will need:
Android Platform Tools, last version (don't need older ones)
Your Samsung Gio in debugging mode
Samsung Kies
Click to expand...
Click to collapse
Explanations:
Android Platform Tools
Click to expand...
Click to collapse
We will use the "adb" program, in order to use the phone terminal. You can also use an embedded terminal (free ones in the android market) or through ssh. It's your call.
Your Samsung Gio in debugging mode
Click to expand...
Click to collapse
Go to : Menu -> Applications -> Development -> USB debugging (green cross it). It will allow "adb" to be connected to the phone.
Samsung Kies
Click to expand...
Click to collapse
Download it here: www.samsung.com/ca/support/mobilesoftwaremanual/mobilesoftwaremanual.do?page=MOBILE.SOFTWARE.MANUAL
Kies is the iTunes-like by Samsung. This may be needed for your computer to detect your phone. But we do not need to launch it. Just install it but do not launch it while doing your stuff.
Step #1
In a Windows shell, go to your .\android-sdk\platform-tools directory (for the example: C:\Android\android-sdk\platform-tools>). Type:
Code:
> adb shell
This will link the computer to your phone and display a remote Android shell. At this point, you should see something like this:
C:\>Documents and Settings\superpizon>cd C:\Android\android-sdk\platform-tools
C:\Android\android-sdk\platform-tools>adb shell
$
Click to expand...
Click to collapse
($ is the prefix of the Android shell, do not type it)
(> is the one for the Windows shell, do not type it too)
Note : if your phone is not in debugging mode, the Windows shell will write:
error: device not found
Click to expand...
Click to collapse
Step #2
After madly browsing the xda method to unroot my phone, I found this post: http://forum.xda-developers.com/showpost.php?p=17078367&postcount=34. Interesting.
If you open the Universal_GB_ROOT.zip file, you have:
META-INF/
-com/
--google/
---android/
----update-binary
----updater-script
-CERT.RSA
-CERT.SF
-MANIFEST.MF
system/
-app/
--Superuser.apk
-xbin/
--busybox
--sh
--sqlite3
--su
--su-v1
--su-v2
--su-v3
Click to expand...
Click to collapse
If you did not notice, after rooting your phone, an unremovable application appeared in the menu application (the icon is a dead skull): this is the visible part of the iceberg that we want to remove.
Ok, your Android shell is waiting. Let's type:
Code:
$ ls /system/xbin
It should display:
dexdump
busybox
sh
sqlite3
su
su-v1
su-v2
su-v3
Click to expand...
Click to collapse
Happenstance? I don't think so. Now type:
Code:
$ ls /system/app/S*.apk
/system/app/SamsungApps.apk
/system/app/SamsungAppsUNAService.apk
/system/app/SamsungWidget_ProgramMonitor.apk
/system/app/SamsungWidget_StockClock.apk
/system/app/ScreenCaptureService.apk
/system/app/SecDownloadProvider.apk
/system/app/SecurityProvider.apk
/system/app/SelfTest.apk
/system/app/SerialNumberLabelIndicator.apk
/system/app/Settings.apk
/system/app/SettingsProvider.apk
/system/app/SetupWizard.apk
/system/app/Setup_Wizard.apk
/system/app/SisoDrmProvider.apk
/system/app/SnsAccount.apk
/system/app/SnsProvider.apk
/system/app/Stk.apk
/system/app/Street.apk
/system/app/Superuser.apk
/system/app/Swype.apk
/system/app/SystemUI.apk
Click to expand...
Click to collapse
(I wrote S*.apk to shorter this logfile).
Oh god, what did we see? The content of the Universal_GB_ROOT.zip file.
Step #3
What do we do now? Well, let's delete these files. Simply.
Good idea. But not so quick to do.
If you "rm" (*nix remove command) files we pointed at, the shell will answer:
rm failed for /system/app/Superuser.apk, Read-only file system
Click to expand...
Click to collapse
Why? Type:
Code:
$ cat /proc/mounts
You should have (it depends of apps you installed):
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
/dev/stl14 /cache rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/stl13 /data rfs rw,nosuid,nodev,relatime,vfat,llw,check=no,gid/uid/rwx,iocharset=utf8 0 0
/dev/stl12 /system rfs ro,relatime,vfat,log_off,check=no,gid/uid/rwx,iocharset=utf8 0 0
Click to expand...
Click to collapse
As you can see (or guess ^^), /system (where apps are installed) is mounted as ro (read-only).
As you can wonder, there is a "trick" to bypass that. Go being super-user:
Code:
$ su
Then:
Code:
$ mount -o rw,remount /dev/stl12 /system
This command will remount /dev/stl12 to /system in rw (read-write).
Step #4
NOW, you can remove files. But please, do ONLY remove files of the Universal_GB_ROOT.zip file like this way:
Code:
$ rm /system/xbin/busybox
$ rm /system/xbin/sqlite3
$ rm /system/xbin/sh
$ rm /system/xbin/su-v1
$ rm /system/xbin/su-v2
$ rm /system/xbin/su-v3
$ rm /system/xbin/su
$ rm /system/app/Superuser.apk
(obviously, *nix folks would prefer to go into the xbin folder and remove each file to write less).
Remember: 7 files in the xbin/ folder and only one in the app/ folder.
And this is it! Now quit the su role:
Code:
$ exit
And the Android shell:
Code:
$ exit
You are now back to the Windows shell.
Note : we did not umount anything because it is not needed. We did a remount. Thus, the usual mount of /system/stl12 to /system will happen again at startup. No worries.
Reboot your phone and go back to the application menu. The unremovable root application disappeared! *clap clap*
III - Going further
Since this unrooting method works with the "Universal Gingerbread Root (by StoneBoyTony)" (as a recall, you will find here: http://forum.xda-developers.com/showthread.php?t=1192122), this unrooting method may work on other devices (Mini, Ace, Pop, Fit) which have been rooted the same way.
Note we got access to the /system/app folder, where some unremovable applications of your carrier could be located. Take a look here. You will probably be able to remove them!
But you must root your phone
Since Sh is in the root package as well, don't you remove it too?
and after I unroot, I can safely OTA update correct? Or is unrooting necessary for safe OTA update.
Can this rooting method work for the Samsung Admire (SCH-R70)?????
I have tried flashing the Universal_BG_ROOT via recovery but I get stock at signature verification.
Can this other method work?
TriXin said:
Since Sh is in the root package as well, don't you remove it too?
Click to expand...
Click to collapse
True. I forgot to write it down. Thank you.
TriXin said:
and after I unroot, I can safely OTA update correct? Or is unrooting necessary for safe OTA update.
Click to expand...
Click to collapse
Rooting a phone (at least, for Android phones) means to allow user to be super-user => to use great powers on the phone.
I don't understand what do you mean by OTA update. But if the OTA update worked before rooting your phone, then unrooting your phone won't stop the OTA update to work.
marcos.lennis said:
Can this rooting method work for the Samsung Admire (SCH-R70)?????
Click to expand...
Click to collapse
If you used the Universal GB Root method, yes.
marcos.lennis said:
I have tried flashing the Universal_BG_ROOT via recovery but I get stock at signature verification.
Can this other method work?
Click to expand...
Click to collapse
stl5 (blaaaaah) or bml5, you have to root your phone. Check the first post, i say a word about rooting and unlocking. I think you have not made the difference yet.
If I use Root Explorer and remove those files then uninstall Root Explorer, would that work?
lypang said:
If I use Root Explorer and remove those files then uninstall Root Explorer, would that work?
Click to expand...
Click to collapse
I never used Root Explorer.
The goal here is to remove files contained in the zip file. If you can do that, so yes it should work.
I've downloaded the Andriod SDK but I have no idea how to do the adb shell. Where do I type this in? Sorry I'm new to this stuff.
I almost got it but it say's permission denied when I type "su" so I can't delete those files. Any reason why I'm getting this?
nevermind got it working. I had to allow the superuser on the phone.
Although the unroot was successful the phone still seems to be unlock. My sim card still works on it even though it should be locked to a different carrier.
Niitsu said:
I've downloaded the Andriod SDK but I have no idea how to do the adb shell. Where do I type this in? Sorry I'm new to this stuff.
Click to expand...
Click to collapse
Use CMD of windows! and search here for tutorials there are enaugh of it
unroot?
I've rooted my gio (gingerbread 2.3.5) with the update.zip method: http://forum.xda-developers.com/showthread.php?t=1111414. Can I unroot it with this method, or can I unroot it by just uninstalling superuser with titanium backup and then reboot? Maybe someone have another idea?
Related
I’ve compiled a quick guide to instruct how to make a copy of the /efs folder. I’ve found in many threads suggestions about backing up this folder but the methods itself are very general. Most of the times they suggest to “root and copy the folder” with Root Explorer or similar, but usually it’s not that easy or it just doesn't work for everyone (my case).
This guide ASUMES you have read this Excellent Guide by Darkstrikerfirst:
H E R E <-- Make sure to read the ADB Guide.
I recommend doing this with a Mobile just taken out of the box or with any Official ROM of its Service Provider. If you have already Flashed your phone with another ROM but its working fine, then you can use that /efs also.
Why the /efs folder?
This is a very sensitive system folder that contains Phone-specific information such as the IMEI (encrypted in the nv_data.bin), wireless devices MAC addresses, product code (also in the nv_data.bin), and much more. Often users trying to change product codes or trying to unlock the mobile will end up corrupting data in this location.
Why back it up?
Well, let’s resume it saying that backing-up this little folder will keep you away from Samsung service centers.
***WARNING: I take no responsibility to any damage caused by the methods cited and/or written here. Their sole purpose is to back-up data and not to alter in any way the integrity of the original files of the mobile***
Please don’t ask how to recover your IMEI if you have previously messed your SGS without backing up this folder. I’m not familiar with such methods plus it is UNRELATED to this thread.
What you will need:
Rooted SGS to get permissions as a SU (Super User) and perform the backup
I would suggest learning a little about the terminal commands used (in case you are not familiar with them), as it’s better to know what you are doing rather than typing strings like a little chimp without knowing what they are; if you are a little lazy, then you have a good chance bricking your mobile.<- Busybox Commands(or Google them)
Terminal Emulator by Jack Palevich (available from the market) <-Terminal Emulator or use ADB which is included in the SDK Development Tools
IMPORTANT: If getting "error: device not found" under ADB (happened to me under CM7 2.3.4), you need to update your ADB drivers. Go HERE and follow the instructions to download the USB Driver for Windows, Revision 4 (Nexus S Support). Then update the drivers under your Windows Device Manager.
--------------------------------------
Backup commands
--------------------------------------
Depending on the type of root, you might have to use “busybox” at the beginning of the sting or just the string:
The standard prompt of terminal (adb) is a $ sign. Once you enter “SU” it will become a # Sign.
***NOTE: Make sure to keep an eye on the screen of your SGS during this process, because it will request SU permissions; else, you will get an error (just if it’s the first time). In Terminal Emulator you will need to reset the app after granting permissions cause it usually freezes***
*Remember: to use ADB you need to enable USB DEBUGGING under Applications/Development in your SGS. Once you are finished with the files, you need to turn it off so you can get the files.
Code:
su
tar zcvf /sdcard/efs-backup.tar.gz /efs or
busybox tar zcvf /sdcard/efs-backup.tar.gz /efs
After this, you will end up with the file efs-backup.tar.gz in your INTERNAL SDCARD, which is a “tarball” or a ZIP of the /efs folder. That file is your backup. You can expand it with Winrar.
In another forum I also saw a recommendation to back up the st13 under /dev/block which can support greatly to recoveryour IMEI in case of a screw-up:
Code:
su
cat /dev/block/stl3 > /sdcard/efs_dev-block-stl3.img or
busybox cat /dev/block/stl3 > /sdcard/efs_dev-block-stl3.img
Same thing, the target is the INTERNAL SDCARD, so go ahead and copy the file.
----------------------------
nv_data.bin - Restore
----------------------------
In case you screwed your IMEI by playing with the nv_data.bin and you are experiencing issues like:
Fake IMEI (usually 004999010640000)
Unable to download apps from the market
Unable to unlock your SIM card using your PIN
Weird apps are downloading automatically from the market
Blinking SIM card icon on the top tray… ETC
You may want to upload your fresh copy of this file back to the phone. Use this commands:
(thanks to Methyldioxide method to recover the product code http://forum.xda-developers.com/showthread.php?t=780509 )
Copy the file from your backup (efs-backup.tar.gz) and paste it in the INTERNAL SDCARD:
Code:
cp /sdcard/nv_data.bin /efs/nv_data.bin
rm -rf /efs/nv_data.bin.md5 OR
busybox rm -rf /efs/nv_data.bin.md5
Reboot your SGS
The md5 hash/signature is removed (rm) as the system will generate a new one.
**Most likely your SIM code won’t work after this and you won’t be able to log into the phone**
Pop off your SIM card, boot your SGS and execute the following commands to change ownership of the file under ADB or Terminal as well:
Code:
su
busybox chown 1001:1001 /efs/nv_data.bin or
chown 1001:1001 /efs/nv_data.bin
Hope this can help anyone with doubts. Cheers!
An alternative to the backup part is to use Root Explorer and zip the whole /efs folder onto your external sd card. (or wherever you want)
How about a method to restore the IMEI if you never had a good back up to begin with ?
Candanga said:
Please don’t ask how to recover your IMEI if you have previously messed your SGS without backing up this folder. I’m not familiar with such methods plus it is UNRELATED to this thread.
Click to expand...
Click to collapse
EarlZ said:
How about a method to restore the IMEI if you never had a good back up to begin with ?
Click to expand...
Click to collapse
How did you manage to miss that?
EarlZ said:
How about a method to restore the IMEI if you never had a good back up to begin with ?
Click to expand...
Click to collapse
had the feeling you would be here LMAO..
funny thing
the other day i messed up nv_data.bak trying to get my old product code back
the phone would not recognise the sim card
i deleted the whole /efs folder and the phone made a new one
i got my imei but no product code
sim card started working everything looked ok appart from sgs tools reporting nothing as phone !?!
i did restore /efs from a backup i had and then my product code came back
weird though
I was on jpo when all this happened
pele78 said:
had the feeling you would be here LMAO..
Click to expand...
Click to collapse
I guess you find it entertaining if people messed up their IMEI, well we all have our kinkiness.
EarlZ said:
I guess you find it entertaining if people messed up their IMEI, well we all have our kinkiness.
Click to expand...
Click to collapse
@EarlZ - I myself was a victim of this, but I managed to make a duplicate of my nv_data.bin as per instructions of the guide that I was following to unlock my SGS.
The only "tip" that I can give you (geez.. Im going against my own disclaimer lol ) is to try to flash it back to JM1 or the earliest release of your mobile. I think I remember to get my IMEI back doing this, but then lost it flashing to a newer ROM. AGAIN, my "research" didn't go past this as I managed to get my IMEI back, reason why I got inspired to throw this little guide.
Hope this can get you started on your IMEI recovery journey.
Cheers mate.
The restore should also be done with tar - in this way you won't lose the permissions on the files.
ingineru said:
The restore should also be done with tar - in this way you won't lose the permissions on the files.
Click to expand...
Click to collapse
Just for future reference (in case I need it ) can you give us the full command line?
Thanks
Thanks for the HowTo.
I ended up deleting my nv_data files in order to restore the backup files to get back the orig product code. As far as I can tell, it worked perfectly.
Code:
busybox rm -rf /efs/nv_data.bin
busybox rm -rf /efs/nv_data.bin.md5
In case you really boink your EFS
I wanted to add a small piece to this thread that not really consolidated anywhere I can fine. I toasted my /EFS yesterday - to the point of no cellular unless I was at JF6. I couldn't use tar because I'd get "out of room" errors and "numerical value out of range". I mean I SERIOUSLY borked the /EFS. But then I've been flashing this phone from the day it was available from AT&T.
I used ODIN to restore my /EFS. I have a permanent generic IMEI.
There are several good threads on backup of the /EFS, but not on restoring. If you follow the OP post to backup, here's a good discussion on how to restore.
http://forum.xda-developers.com/showthread.php?t=882039
What wasn't clear in Da_G's thread is the you don't have to use DD to use ODIN to restore. There's no discussion on using the .img file to restore. That's scattered across a couple of threads and lots of reading. I'm not a linux guy, so I had to figure this out. . . .
Deep in rotohammer's following thread, there is a discussion about using a cat .img file to do create an ODIN .rfs file that allows you to restore from ODIN.
http://forum.xda-developers.com/showthread.php?t=850359
So here's what I did to restore my /EFS to functional. You MUST have a backup of your functional /EFS using either dd or cat and ADB installed.
On your PC do the following:
c:\Android\tools> adb shell
$ su (you're now on your phones Android command line; watch your home screen on the phone in case Superuser comes up asking for permission)
#
Now we're going to take the efs_folder_backup_stl3.img that you did with the cat file and make it usable by ODIN. Change directory locations to your cat .img location. Mine is on /sdcard/external_sd/.
#cd /sdcard/external_sd/
#busybox cat efs_folder_backup_stl3.img > /sdcard/efs.rfs (this is the key step!!)
# cd /sdcard
# tar -cf efs.tar efs.rfs
# exit
$ exit
Now your back at your PC. Do the following step to get the .tar file off your phone.
c:\Android\tools> adb pull /sdcard/efs.tar
Almost done. Move the efs.tar file to the same direction as ODIN and the follow the last directions in Da_G's thread. I'll post them below for just for clarity.
"Now, get into download mode, open odin, stick efs.tar in PDA slot, and press start. Bam! EFS fixed"
This worked for me, several times. Once you have the /EFS directory in ODIN flashable tar format - you really have to work hard to brick your phone.
Hope this helps!
If I flash back to stock using ODIN, would that also put things back to right ?
@bsc7080xsc
It should. You might have to do a factory reset if the device shows as locked, but otherwise it's worked for me many times.
Hi
backedup my efs folder through this thread in combination with roto.
cellgeek in your post you say : " busybox cat efs_folder_backup_stl3.img > /sdcard/efs.rfs (this is the key step!!)"
But i never made an .img file/folder.
both the dd and cat created an rfs file which i turned to tar.
am i missing a step?
thank you for your little extra guide.
that's a very useful Candanga
several times saved my ass
thanks !
Thank you VERY much OP, that worked for me
Sorry to revive if this is old;
Why won't rm -rf /efs/nv_data.bin.md5 work in terminal? It gives me an error along the lines of this is a read-only file etc?
geesamsungs said:
Sorry to revive if this is old;
Why won't rm -rf /efs/nv_data.bin.md5 work in terminal? It gives me an error along the lines of this is a read-only file etc?
Click to expand...
Click to collapse
Try "busybox rm -rf /efs/nv_data.bin.md5"
Thanks that was very useful but I have a problem here.
When I copy my nv_data.bin file to efs directory I can only change the ownership but not the group!
I tried both of this:
su
busybox chown 1001:1001 /efs/nv_data.bin or
chown 1001:1001 /efs/nv_data.bin
Click to expand...
Click to collapse
and
su
busybox chown radio:radio /efs/nv_data.bin or
chown radio:radio /efs/nv_data.bin
Click to expand...
Click to collapse
Ok, after using my phone for a while i decided to root it. Since I have the stock Gingerbread rom i followed the guide to downgrade to the stock froyo rom. http://forum.xda-developers.com/showthread.php?t=1178912
I reached the part Temp-Rooting to Backup However, when i run titanium backup it says Error: Sorry, I could not acquire root privileges. This application will *not* work.
What am I supposed to do? I followed the guide to the letter and everything up till that point was exactly as the guide said.
My phone's details are
Android version 2.3.3
Baseband version 12.56.60.25U_26.10.04.03_M
Kernel version 2.6.35.10-g7b95729
Software number 2.42.415.17
Here is what i did in adb
http://pastebin.com/jkxE55Yh
For some reason, new users are not allowed to post links in their replies. Nipqer, i redid all my steps and did what you told me.
here is the link of all what i did:
http://pastebin.com/Fze9uB33
First, thank you so much for linking a pastebin of what you've done, makes it so much easier to try help.
However I'd really like to see if there was any output after running 'adb shell /data/local/
tmp/fixsu.sh' so if you can get that ouput and post it, would be much appreciated.
You might have to run it from inside shell:
adb shell
cd /data/local/tmp
./fixsu.sh
-Nipqer
Thanks Nipqer and sorry for the late reply.
I did what you told me and this is what i got
C:\Program Files (x86)\Android\android-sdk\platform-tools>adb shell
adb server is out of date. killing...
* daemon started successfully *
# cd /data/local/tmp
cd /data/local/tmp
# ./fixsu.sh
./fixsu.sh
#
though i don't know if it helps with anything.
I just got confused because in the guide it says to install Titanium backup and backup my data. I have already done a manual backup myself but i figured doing a backup using Titanium backup will not hurt. I have used other programs like Root Checker Basic and it tells me that i don't have proper root access.
Can I just ignore this issue and go ahead with the downgrade? Or will there be some problems?
Thanks again in advance!
Hmm, it should give you root permissions after running fixsu.sh.
The lack of output shows it should've worked.
That part of the guide is entirely optional anyway, so If you already have what you want backed up, go ahead and downgrade.
-Nipqer
Nipqer said:
Hmm, it should give you root permissions after running fixsu.sh.
The lack of output shows it should've worked.
Click to expand...
Click to collapse
Well. fixsu.sh returned no error for me, too. But Titanium backup did not get root and trying to call "su", I got I/O error. And looking to dmesg, I seen corrupted file system.
After a bit of research I got the reason: rw remount succeeds, Linux thinks, that data are written to flash, but no data are written for real. Once data leave cache, they are lost and system "returns" to intact state.
I wrote a different fixsu.sh, which does not have this problem, but I am still failing to get root privileges, even with the latest Superuser+su. I got only a pop-up about refused root access. (But "su number_of_any_existing_uid" and then "su" in adb shell says says about permitted access.)
Here is my preliminary fixsu.sh:
Code:
#!/system/bin/sh
chmod 755 /data/local/tmp/busybox
chmod 4755 /data/local/tmp/su
/data/local/tmp/busybox cp -a /system/xbin /data/local/tmp/
mount -o bind /data/local/tmp/xbin /system/xbin
/data/local/tmp/busybox --install -s /system/xbin/
/system/bin/rm /system/xbin/su 2>/dev/null
/data/local/tmp/busybox cp -a /data/local/tmp/su /system/xbin/
/data/local/tmp/busybox cp -a /system/bin /data/local/tmp/
mount -o bind /data/local/tmp/bin /system/bin
/data/local/tmp/busybox cp -a /data/local/tmp/su /system/bin/
# /etc/* changes are needed only for some busybox utils, not for Superuser's su
/data/local/tmp/busybox cp -a /system/etc /data/local/tmp/
mount -o bind /data/local/tmp/etc /system/etc
/data/local/tmp/busybox echo "root::0:0:root:/data/local:/system/bin/sh" > /system/etc/passwd
chmod 0666 /system/etc/passwd
/data/local/tmp/busybox echo "root::0:0:root:/data/local:/system/bin/sh" > /system/etc/passwd
/data/local/tmp/busybox echo "root::0:" > /system/etc/group
chmod 0666 /system/etc/group
# Optional:
ln /data/local/tmp/busybox /data/local/tmp/xbin/busybox
And here is the code to recover "writable" state after reboot:
Code:
#!/system/bin/sh
mount -o bind /data/local/tmp/xbin /system/xbin
mount -o bind /data/local/tmp/bin /system/bin
mount -o bind /data/local/tmp/etc /system/etc
Unfortunately I can't tell you why it won't work. Might just be your partitions are too corrupted or something.
Have you tried a full power cycle (turn phone off, pull battery), it's helped other phones work in the past.
Otherwise I'd say just use adb to pull your entire /data dir, so you have everything saved and can mess round with trying to put it back in later.
-Nipqer
Nipqer said:
Unfortunately I can't tell you why it won't work. Might just be your partitions are too corrupted or something.
Have you tried a full power cycle (turn phone off, pull battery), it's helped other phones work in the past.
Click to expand...
Click to collapse
I tried to reboot without battery removal. Partition was "corrupted" before reboot and intact after reboot. I tried to write again. I again got corruption. And ffter reboot it was again byte-equal to the original system.img. It means, that not write actually happens. Linux kernel just assumes that data are written, but they are lost after leaving kernel cache.
Hopefully, Android mount command supports -o bind, so one can bind mount directories from /data and /system is seemingly writable then.
Nipqer said:
Otherwise I'd say just use adb to pull your entire /data dir, so you have everything saved and can mess round with trying to put it back in later.
Click to expand...
Click to collapse
I saved all mmcblk0p* before starting my experiments. It should be the most complete way to backup, but it does not easily allow partial restore.
utx said:
I saved all mmcblk0p* before starting my experiments. It should be the most complete way to backup, but it does not easily allow partial restore.
Click to expand...
Click to collapse
If you saved the data from the partitions, restoring would just be placing the apk in /data/app/ and then placing the data files back into /data/data/ - if you do it this way, you must run fix_permissions whether you saved it with or without preserving the permissions (owner, read/write/execute, et cetera). The app, when you put it on the different rom, will have a different UID (more than likely) than it did before and the data files permissions would be incorrectly set. Running fix_permissions should resolve that issue.
*EDIT*
I may of misunderstood what you meant by saving mmcblk0p*. How did you do this? At first I was thinking you just meant you did a tar backup of each partition, but after re-reading sounds more like you something like
Code:
# dd if=/dev/block/mmcblk0p# of=/sdcard/mmcblk0p#.img
Is that what you did? If so, are you trying to restore it by the same method?
Code:
# dd if=/sdcard/mmcblk0p#.img of=/dev/block/mmcblk0p#
If so, I'm not sure that would work properly… You might have to extract the data from it then copy it over to the partition...
I've had that problem after geting temp root. Titanium would say no root premissions. So I redid the steps after reboot...but I found the problem was that if you open titanium back up be for u root it will throw yu that msg so if yu have did that that's why so go back after you root in to applications and force close titanium and then reopen app then it shuld give you root premssions at least it worked for me but I still wasn't able to down grade and another thing are u using the gfree method kus that didn't work for me to get root... I had to use the freevo method to get temp root as gfree kept giving me errors after doing the adb coommands
sent from my Tmobile G2 Rush Vision
And if that dosnt work yu can use sdcard maid to back up your system apps n such or delete them ....
sent from my Tmobile G2 Rush Vision
Setherio said:
If you saved the data from the partitions, restoring would just be placing the apk in /data/app/ and then placing the data files back into /data/data/ - if you do it this way, you must run fix_permissions whether you saved it with or without preserving the permissions (owner, read/write/execute, et cetera). The app, when you put it on the different rom, will have a different UID (more than likely) than it did before and the data files permissions would be incorrectly set. Running fix_permissions should resolve that issue.
Click to expand...
Click to collapse
I am aware of this problem. But if one returns exactly equal /system as it was there before, the /data will need no change.
Setherio said:
I may of misunderstood what you meant by saving mmcblk0p*. How did you do this? At first I was thinking you just meant you did a tar backup of each partition, but after re-reading sounds more like you something like
Code:
# dd if=/dev/block/mmcblk0p# of=/sdcard/mmcblk0p#.img
Is that what you did? If so, are you trying to restore it by the same method?
Code:
# dd if=/sdcard/mmcblk0p#.img of=/dev/block/mmcblk0p#
If so, I'm not sure that would work properly… You might have to extract the data from it then copy it over to the partition...
Click to expand...
Click to collapse
It was just an abbreviation:
Code:
cd /dev/block
for PARTITION in mmcblk0p* ; do
dd if=/dev/block/$PARTITION of=/sdcard/$PARTITION.img
done
I guess, that the most straightforward way to restore that /data would be: First run
Code:
fsck mmcblk0p26.img
(on Linux machine) on that /data image (when you don't have root and custom recovery yet, you cannot backup /data in read-only mode, so the image is corrupted a bit for sure; if the fsck puts something to /lost+found, you can delete it after finishing of the rooting process). Then rename mmcblk0p26.img to userdata.img and add it to the PC10IMG.zip that restores stock system. Otherwise you will again fight with "partition in use" problem when trying to restore.
I did not test this method, as I did not understand the partition layout that deeply before I root. But there is no reason why it would not work.
Hello everybody,
for quite a while i am reading several guide for rooting my desire z (android 2.3.3, not branded, USB debugging activated, Fast boot deactivated). In Germany most of the guides refer to Setherio's guide. So working with the source is as usual the best.
Unfortunately - even after 3 tries, with factory resets, rebooting, removing the battery, etc. - I cannot gain a temporary root. neither titanium backup nor MyBackUp Root gain access for making a backup. So I ended up here. I am not sure, if Sayedamir had the same problem. Nevertheless, I appreciate every help.
This is what I have done so far:
http://pastebin.com/NKD6D7Av
Furthermore, referring to Nipquer's 1st post, I executed fixsu as described with following results:
http://pastebin.com/0EQS0UnF
I am not sure, if I should proceed with the downgrading without having a backup and I guess, when the backup isn't working (lack of temporary root), the downgrading would not work anyway?!
Hi Vince683,
Yes I had exactly the same problem. I too followed Setherio's guide and after 2 attempts I still couldnt get temp root. I ended up not being able to back up any of my apps.
However i suggest you back up your messages and contact as that was the only stuff I could back up. there are alot of apps in the market that do that and i guess they dont need root.
If backing up your app data is that not important you can proceed with the downgrade. It worked in my case. I guess the only nuisance would be that you have to manually install and configure all yours apps again.
Tell us how it goes.
Perfect, it worked. Thank you for encouraging me
And Cyanogenmod 7.2 works fine.
Vince683 said:
Perfect, it worked. Thank you for encouraging me
And Cyanogenmod 7.2 works fine.
Click to expand...
Click to collapse
You're welcome
Since my phone's usb is effed, I can't root it via usb. Now, I can install dropbox and put stuff in my phone like the the SU file and ROMS. Can I root using my phone only?
Edit: unrelated. Sorry
convolution said:
Since my phone's usb is effed, I can't root it via usb. Now, I can install dropbox and put stuff in my phone like the the SU file and ROMS. Can I root using my phone only?
Click to expand...
Click to collapse
Nope. How do you know your USB is broken? Sounds more like user error?
Sent from my Galaxy Nexus using xda premium
To my knowledge you need fastboot to unlock and root. That requires USB.
There might be some local privilege escalation vulnerabilities in ICS itself, but those tends to get patched and nobody really bothers to look for them on open devices like the Galaxy Nexus.
you can use mempodroid on 4.0.2 to get a root shell. not sure what you can or can't do from there with a locked bootloader tho.
kendong2 said:
you can use mempodroid on 4.0.2 to get a root shell. not sure what you can or can't do from there with a locked bootloader tho.
Click to expand...
Click to collapse
If you can get a rootshell, you can manually root the phone, just like many people do with the hacked/modified boot.img booted by fastboot. Basically take your temproot and make it a permroot.
1. push modified su-binary and Superuser.apk to phone's /sdcard/.
2. From the (temp) root-shell do approximately the following:
Code:
# mount -o remount,rw /system
# cat /sdcard/su >/system/xbin/su
# cat /sdcard/Superuser.apk /system/app/Superuser.apk
# chmod 06755 /system/xbin/su
# mount -o remount,ro /system
3. Done.
kendong2 said:
you can use mempodroid on 4.0.2 to get a root shell. not sure what you can or can't do from there with a locked bootloader tho.
Click to expand...
Click to collapse
Thanks for this. I was unaware that someone found local privilege escalation exploit for ICS.
I haven't tried it myself, but it would certainly helps those with locked bootloaders (and/or broken hardware buttons or USB ports).
I started a new thread here.
EDIT: It seems that you need to be connected over ADB to get this to work. However, it may work with ADB over Wi-Fi, but I haven't gotten there yet.
Oh thx!
Now, can I flash roms and have CWM without an unlocked bootloader as well?
[HOW-TO] [GSM & CDMA] Root without Unlocking Bootloader via exploit (for 4.0.1/4.0.2)
Edit: This does not works on anything newer than ICL53F (i.e., 4.0.2). It works fine on ITL41D (4.0.1), ITL41F (4.0.1) and ICL53F (4.0.2)
Once you have got root, you can now use segv11's BootUnlocker app to unlock your bootloader without wiping anything. Easy as pie!
Disclaimer: I take no credit for this exploit or the implementation of it (but I will take credit for the step-by step ). Thanks to kendong2 for pointing it out to me here.
So, it looks like zx2c4 has found a local privilege escalation exploit. See source here, and saurik has managed to package it together for Android. See here. Although this may be old news to some, I hadn't seen it before.
So what does this all mean:
If you are running a 2.6.39 kernel (or above), which all Galaxy Nexus' are, you can now root your device without having to unlock your bootloader (and without losing your data).
Moreover, you should now be able to root your device even if your hardware buttons are not working.
Additionally, this allows those who have not received an OTA update and want to apply it without having an unlocked bootloader or root to do so by copying the OTA update to /cache from /sdcard.
Notes:
1) This assumes that you have USB Debugging enable on your device (Settings > Developer Options > Enable USB Debugging) and the drivers for your device installed on your computer. For the drivers, I would recommend you remove all old drivers and install these. If you don't know how to install them, or are having issues, look here.
2) This needs to be done over ADB, as a terminal emulator on-device does not have the appropriate access. If you do not have ADB, I've attached it in the zip. Unzip all files.
3) Some users indicate that, once finished the procedure, they needed to open the Superuser app.
Step-by-step:
1) Download the attached files to your computer and unzip them in the same directory as your adb.exe file;
2) Open a command prompt in the same directory;
3) Copy the files to your device:
adb push mempodroid /data/local/tmp/mempodroid
adb push su /data/local/tmp/su
adb push Superuser.apk /data/local/tmp/Superuser.apk
4) Open a shell: adb shell
5) Change permission on mempodroid to allow it to run: chmod 777 /data/local/tmp/mempodroid
6) Run the exploit: ./data/local/tmp/mempodroid 0xd7f4 0xad4b sh
Note: Once you do step 6, your prompt should change from $ to #. If not, it did not work.
7) Mount the system partition as rw: mount -o remount,rw -t ext4 /dev/block/mmcblk0p1 /system
8) Copy su to /system: cat /data/local/tmp/su > /system/bin/su
9) Change permissions on su: chmod 06755 /system/bin/su
10) Copy Superuser.apk: cat /data/local/tmp/Superuser.apk > /system/app/Superuser.apk
11) Change permissions on Superuser.apk: chmod 0644 /system/app/Superuser.apk
12) Mount the system partition as r/o: mount -o remount,ro -t ext4 /dev/block/mmcblk0p1 /system
13) Rescind root: exit
14) Exit the ADB shell: exit
15) Done. You now should have root without having to unlock your bootloader.
Reserved
Reserved
This is the same as https://github.com/saurik/mempodroid
saurik ftw.
times_infinity said:
This is the same as https://github.com/saurik/mempodroid
saurik ftw.
Click to expand...
Click to collapse
Not sure what you are getting at? I mentioned saurik in the first post, and the link you posted is in the first post. And I mentioned that this may be old news, but I haven't seen it anywhere before today in the GN forums.
Yikes! This exploit works on any kernel from 2.6.39 and >. This could become a common root method for many devices. Linus Torvalds himself posted the fix commit! Nice work by zx2c4!
Sleuth255 said:
Yikes! This exploit works on any kernel from 2.6.39 and >. This could become a common root method for many devices. Linus Torvalds himself posted the fix commit! Nice work by zx2c4!
Click to expand...
Click to collapse
You need ics to have a vulnerable kernel version, so given the number of devices which currently have ics officially, I doubt it will be common. I'd also expect Google and vendors to correct this in next release.
Also many custom kernels don't have this flaw as they are at or over 3.0.18 or have patched it. This prevents gaining unnoticed root.
Sent from my Galaxy Nexus
Hmmm I thought 2.6.39 was found in GB builds. This exploit is almost a root fix for the Moto DX 4.5.621 fiasco. Unfortunately the kernel for that build is 2.6.32.9.
Sent from my Galaxy Nexus using xda premium
This was huge in the headlines a few weeks back. It's nice to see someone putting it to a good use!
Sent from my Galaxy Nexus using xda premium
Hi, been lurking awhile, registered to clear up somethings.
I did some research while attempting to access the /data/local/ -folder with terminal emulator and I found that it would be impossible to write or to find it while being unrooted. Rooting a phone through using an unrooted access root seems impossible.
Did I miss something or is there any other way to copy mempodroid to the data- folder? I sure would like to keep all my files.
Huxleysäl said:
Hi, been lurking awhile, registered to clear up somethings.
I did some research while attempting to access the /data/local/ -folder with terminal emulator and I found that it would be impossible to write or to find it while being unrooted. Rooting a phone through using an unrooted access root seems impossible.
Did I miss something or is there any other way to copy mempodroid to the data- folder? I sure would like to keep all my files.
Click to expand...
Click to collapse
I think you are mistaken. In a terminal emulator type: cd /data/local/tmp
Edit: Fixed a mistake made by auto correct...
Sent from my Galaxy Nexus using Tapatalk
efrant said:
I think you are mistaken. In a terminal emulator type: cd /data/local/temp
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Just did. It says "No such file or directory."
Not the best source, but if you google it, people state what I state. Sorry, can't post links
try /data/local/tmp
Huxleysäl said:
Just did. It says "No such file or directory."
Not the best source, but if you google it, people state what I state. Sorry, can't post links
Click to expand...
Click to collapse
Sorry, damn auto correct. It should be: cd /data/local/tmp
Not "temp".
It works fine.
Edit: Sleuth255 beat me to it!
Sent from my Galaxy Nexus using Tapatalk
efrant said:
Sorry, damn auto correct. It should be: cd /data/local/tmp
Not "temp".
It works fine.
Edit: Sleuth255 beat me to it!
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Sure, OK, it worked. But as I'm trying to replicate his instructions, copying mempodroid to data/local/tmp doesn't compute. I tried extracting the files, puting mempodroid in a new folder in ./sdcard/ (which I named Nex), and it still couldn't find it.
Wait, just had an idea. Brb
Huxleysäl said:
Sure, OK, it worked. But as I'm trying to replicate his instructions, copying mempodroid to data/local/tmp doesn't compute. I tried extracting the files, puting mempodroid in a new folder in ./sdcard/ (which I named Nex), and it still couldn't find it.
Wait, just had an idea. Brb
Click to expand...
Click to collapse
Hmm. Looks like you may be correct. In GB, we had write access to that directory, but it looks like we don't in ICS. I'll have another look tomorrow and try to figure something out.
Sent from my Galaxy Nexus using Tapatalk
OK, this is exactly what I did:
I downloaded the files, extracted them into the ./sdcard folder of my android. I opened the console, wrote exactly as stated. Reaction? Cannot create /data/local/tmp/mempodroid: Permission denied
So, what I'm thinking is this: I tried the cd ./sdcard/mempodroid, found it. So, logically, that should mean that since the permission is dennied, the problem lies not in where I put the mempodroid, but with my authority over my phone. So, here we are again. Could anybody smarter then me clarify?
efrant said:
Hmm. Looks like you may be correct. In GB, we had write access to that directory, but it looks like we don't in ICS. I'll have another look tomorrow and try to figure something out.
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
****, I was hoping I was wrong. I originally thought that the exploit was this. But alas.
Try finding an alternative write route to the /data/local/- folder. That should solve all problems, I guess. Big words, ey? This is for the simpletons like me, who stupidly forgot to bootload.
Might want to expand on the steps.
Like what program to use to copy the file.
How do you change permission.
How do you run the exploit.
How to mount rw.
How to copy su.
convolution said:
Might want to expand on the steps.
Like what program to use to copy the file.
How do you change permission.
How do you run the exploit.
How to mount rw.
How to copy su.
Click to expand...
Click to collapse
I hade my initial problems with that too. But as if this moment it doesn't really matter. Read above posts. Anyhow, to answer your question: you need to download a console emulator
Just search for it in the market. Also the commands go in this console
For example: cat /directory/filename > /newdirectory/samefilename means to copy or move from one place. To change permission you just write that line of code ending with 777 instead of cat and then the filename etc and etc.
I didn't know any of this 'till yesterday, so it is quite understandable.
cheers
Huxleysäl said:
F***, I was hoping I was wrong. I originally thought that the exploit was this. But alas.
Try finding an alternative write route to the /data/local/- folder. That should solve all problems, I guess. Big words, ey? This is for the simpletons like me, who stupidly forgot to bootload.
Click to expand...
Click to collapse
I've updated the first post. Give that a go and let me know how it turns out. (The guide may need some minor tweaking, but I am here to help you through it.)
It seems that ADB has rw access to /data/local/tmp but a terminal emulator on-device does not. So for now, you need to be plugged into your computer.
It may be possible to do this with ADB-over-Wi-Fi, but I haven't gotten there yet.
Hi,
A few days ago, I did unlock and root my N7 (2013) using "Nexus Root Toolkit (v.1.6.8)" by WugFresh. I followed the instructions to the letter and everything went OK, it seemed. My N7 (JSS15J) is unlocked and I have root access, as confirmed by "Titanium Backup" and "Root Checker Pro" app.
However, my N7 cannot mount "System" - which is why I cannot delete any system app bloatware (also confirmed by "System App Remover" & Root Checker Pro app). When rooting my N7 (2012) and my SGS3, everything worked just perfectly and I never had these kind of issues...
I did factory-reset a number of times, went through the unlock/root process again, rooted again via UPDATE-SuperSU-v1.51.zip etc etc. - no dice. TWRP v2.6.0.0 is installed and working. I also installed & updated BusyBox, and I wiped of Dalvik - but still no root access to "System", or "mount".
As I just found out, "Root Checker Pro" actually explains why I can't mount "System" and/or don't have root access... I just don't know what to do about it:
Congratulations! You have root access!
Super User Application Status:
SuperSU application - version 1.51 - is installed!
System File Properties for Root Access:
Standard Location
Check Command: ls -l /system/bin/su:
Result: /system/bin/su: No such file or directory
Analysis: File /system/bin/su does not exist.
Standard Location
Check Command: ls -l /system/xbin/su:
Result: -rwsr-sr-x root root 112164 2008-08-01 07:00 su
Analysis: Setuid attribute is present and root user ownership is present. Root access is correctly configured for this file! Executing this file can grant root access!
Alternative Location
Check Command: ls -l /sbin/su:
Result: /sbin/su: Permission denied
Analysis: File system permissions restricted and denied access.
Alternative Location
Check Command: ls -l /system/xbin/sudo:
Result: /system/xbin/sudo: No such file or directory
Analysis: File /system/xbin/sudo does not exist.
Root User ID and Group ID Status:
Root user id:
uid=0(root)
Root group id:
gid=0(root)
System Environment PATH: /sbin /vendor/bin /system/sbin /system/bin /system/xbin
ADB Shell Default User:
ADB shell setting for standard access, stored in default.prop, is configured as: shell (non root) user - ro.secure=1
Results provided on your Nexus 7 device by Root Checker Pro version 1.3.4 from joeykrim in the Android Market - http://goo.gl/NcnHn
What did I miss?
Can someone please help me to install whatever is needed to gain root access to "System"? "System App Remover" app shows that "System" is not mounted but downloading a separate "mount app" did not do the trick either...
Thanks for your help & suggestions, guys!
System is already mounted or you wouldn't be running android.
What you probably want to do is "remount"
mount -o remount,rw /system /system
But if all you want is to remove apps, perhaps it is easier if you just use Titanium to freeze them first and once you are sure you don't need them you can delete them, but I would just leave them frozen.
sfhub said:
System is already mounted or you wouldn't be running android.
What you probably want to do is "remount"
mount -o remount,rw /system /system
But if all you want is to remove apps, perhaps it is easier if you just use Titanium to freeze them first and once you are sure you don't need them you can delete them, but I would just leave them frozen.
Click to expand...
Click to collapse
Thanks, sfhub... I'll give that a try!
Doesn't look good, I'm afraid:
C:\platform-tools>mount -o remount,rw /system /system
'mount' is not recognized as an internal or external command,
operable program or batch file.
Click to expand...
Click to collapse
Any further suggestions, please?
androidarmin said:
Doesn't look good, I'm afraid:
Click to expand...
Click to collapse
Seems like I tried in the wrong place... I'll give it another try; sorry
Well... downloaded a Terminal Emulator from Google Play..
But now I'm getting a "mount: Operation not permitted" error...
Googled a ton and found a lot of good advice... and even figured things out using ADB (hint: adb shell) - but nothing worked in the end.
Seems like my "SU" may be the culprit, but I'll figure things out when I have more time... meaning, on the weekend. Probably go back to stock and then start over. Seems to be the simplest way right now.
Thanks so far, guys!
androidarmin said:
Well... downloaded a Terminal Emulator from Google Play..
But now I'm getting a "mount: Operation not permitted" error...
Click to expand...
Click to collapse
In adb, you need to type su first to give yourself root privileges before you can mount /system
You need to mount system as read/write in order to remove apps from it.
Sent from my Nexus 7 (2013)
Thanks, sfhub & Muikkuman... I know/I did. Still doesn't work.
Sent from my GT-I9300 using Tapatalk 4
androidarmin said:
Thanks, sfhub & Muikkuman... I know/I did. Still doesn't work.
Click to expand...
Click to collapse
what happens if you do in a command prompt in your adb directory
adb shell
su
Yes this seem strange.
Sent from my Nexus 7 (2013)
My suggestion would be to update TWRP, back-up important data, format data in recovery, look for decent rom, flash rom/gapps/latest supersu.
Then go to 'advanced' in recovery and fix permissions. Reboot recovery and tick 'mount' 'system', respectively install root file explorer of your liking.
No quick solution but should do the trick..
My suggestion is DO NOT delete anything, period. Nurse disable from settings or use pm disable.
Deleting stuff is completely pointless and WILL cause you problems in the future.
androidarmin said:
Thanks, sfhub & Muikkuman... I know/I did. Still doesn't work.
Sent from my GT-I9300 using Tapatalk 4
Click to expand...
Click to collapse
Dont know if you got this sorted. i was having the same problem with my son's Nexus 7 and came across this tutorial for Total Commander
http://www.androidpolice.com/2011/0...ns-remount-rw-in-total-commander-for-android/
Great little short cut to get the job done and can now get Total Commander free on Google Play.