Related
I'll try to keep this as short and simple as possible:
I am a total newb to the touchscreen, smart-phone, I just got a USCC Samsung Mesmerize SCH-i500, came installed w/ 2.3.4 Gingerbread & I just had to reflash it w/ USCC EH09 root using Odin 3 v1.85, now, everything I have "hacked" in the past (PSP (both fat & slim), iPod Touch, etc) I've always had to use step-by-step instructions (I am not a dev & know absolutely nothing about programming) & the same applies here.
So, it has root access & BusyBox (I don't even know what that is) installed, so my question is what was the point?
What exactly can/should I do from here? Any suggestions?
well, with a rooted android device you can
*remove bloatware (you're wasting your root if you don't do this)
*system-wide adblock (my personal fav)
*change boot animations
*flash custom ROM
*free wifi tethering
*overclock the CPU
and more!
Thank you for the answer, I'll look into these things but on a side note: my su app keeps saying that theres an update available for my su binary & every time I tap update it goes through the process & less than half-way through it pops up a message saying: "This updater cannot update the su binary on phones that have some kind of write protection on the system partition like S-ON. You can continue to use Superuser with your outdated binary, or update su with ROM Manager."
I have tried to use ROM Manager, I even bought the Premium version, either way it gives me the same message, even after doing the Fix Permissions option, is there a way to manually allow su access to the files it needs to overwrite/update?
Oh, and, yes, I have allowed it when su asked, so now I'm at a loss....
Xeno Templar said:
Thank you for the answer, I'll look into these things but on a side note: my su app keeps saying that theres an update available for my su binary & every time I tap update it goes through the process & less than half-way through it pops up a message saying: "This updater cannot update the su binary on phones that have some kind of write protection on the system partition like S-ON. You can continue to use Superuser with your outdated binary, or update su with ROM Manager."
I have tried to use ROM Manager, I even bought the Premium version, either way it gives me the same message, even after doing the Fix Permissions option, is there a way to manually allow su access to the files it needs to overwrite/update?
Oh, and, yes, I have allowed it when su asked, so now I'm at a loss....
Click to expand...
Click to collapse
I had the same issue today, couldn't update SU.
but after I had updated the terminal emulator, I was able to update SU.
Fixed the Problem with updating SU Binary
Recently updated my device with a new rom and was unpleasantly surprised to not be able to update my SU binary with either the application itself or CWM. I am not sure that this is the best way to handle the problem, but I found a solution that worked for me.
1. Open "System/XBin" in RootExplorer (or a similar app)
2. Mount the drive as R/W using the button up at the top left
3. Open the superuser app and update the binary from within the app
4. There may be an error in the log about the device not being able to remount the drive properly, but the update WILL occur.
5. Use RootExplorer to open the directory again and mount as R/O.
I hope this helps!
Disclaimer: This is for testing purposes only. I do not condone breaking company policy, or breaking any laws. I am not responsible for you getting fired as a result of you making these modifications. You should always read and abide by company policies and any laws pertaining to such modifications. Use of this tutorial is at your own risk.
Preface: I have tested the new method on multiple devices and it has been flawless so far.
UPDATE: I have found a new method that so far has been flawless across multiple devices so far for me. With this new method you won't even have MobileIron installed when you're done! I have tested this on my Galaxy Nexus, My Nexus 7 and my Galaxy Note II and believe it should work regardless of device. Your company may have different security policies than mine so it's possible this may not work for you.
The easiest way to do this is with one of mskip's toolkits, but it can also be done manually with adb (must have the latest sdk).
Toolkit Method
0. Make sure you have MobileIron and Touchdown installed, configured and syncing. Your phone does NOT have to be rooted to do this.
1. Download mskip's Toolkit Here and install.
2. Make sure you have the adb drivers for your phone installed on your computer and android debugging is turned on in the developer settings on your phone.
3. Open the toolkit and connect your phone to your computer
4. It shouldn't matter what model phone you choose for the purpose of what we're doing, and the options may be slightly different based on which toolkit you download
5. Choose the option backup and restore your device
6. Choose backup all installed apps
7. Choose do NOT include system apps in the backup
8. Choose backup apk's AND respective app data
9. Choose do NOT back up internal storage data in backup
10. Wake your phone and it will ask you to start the backup, choose to do so
Once it is finished you will need to wipe your phone. It may work without wiping and just uninstalling touchdown and Mobileiron before proceeding to the next section, but I haven't tested this.
11. Connect your phone to your computer and enable android debugging
12. Browse to C:\Galaxy Nexus Toolkit (or whatever the name of your toolkit is under c:\)
13. Open the folder backups and rename the backup file to backup.bak. (if you don't see the file extension just name it backup)
14. Open the toolkit and choose a model
15. Choose Backup and Restore
16. Choose Restore apps from a backup file
17. type backup.bak and press enter
18. Wake your phone and choose to begin the restore
19. When it's finished, uninstall mobileiron, open touchdown and see if it's syncs!
ADB Method
adb backup -all -system -shared -apk
recovery> backup, wipe, flash rom, flash gapps, reboot
adb restore backup.ab
Requirements For ICS:
1. Rooted Android Phone running ICS based ROM
2. Titanium Backup (app installed)
3. Hide my Root (app installed)
4. Mobileiron (app installed but never run)
5. Touchdown (app installed but never run)
Instructions for ICS:
0. Make a Nandroid backup
1. Open Hide my Root
2. Choose hide SU binary
3. Press home
4. Menu, settings, apps, all apps
5. Choose Superuser.apk
6. Choose disable
7. Now open mobileiron and configure the settings per your company's instruction.
8. Set up your email in the Touchdown application and let it sync everything.
9. Open Hide my Root and choose restore SU Binary
10. Go back to menu, settings, apps, superser.apk and choose enable. (Its at the bottom when disabled)
11. Open Titanium Backup
12. Choose backup/restore from the top
13. Scroll to Mobileiron and tap it and choose freeze.
14. Profit
Now restore your nandroid backup before you get in trouble.
**Update** for Jelly Bean
It seems the builds out there for Jelly Bean use a new version of SuperUser that as of yet isn't compatible with Hide My Root. I wrote the developer of Hide My Root and he is looking into this but currently doesn't have a device running Jelly Bean to test on, so I took it upon myself to figure this out once again. I tested this and it does work. Again this was tested on a VZW Galaxy Nexus only.
Instructions for Jelly Bean:
0. Make a Nandroid backup!
1. Download MobileIron (App installed but never run)
2. Download Touchdown (or any apps that depend on MobileIron and do not launch them)
3. Download Titanium Backup (You may need the premium version to freeze apps)
4. Download SuperSU flashable zip from HERE and place on your SDcard.
5. From the app drawer launch SuperSU (that app already installed, not the zip you just downloaded)
7. Swipe 2 screens to the right to Settings
8. Choose Full unroot.
9. Install and configure MobileIron and dependent apps and let them fully sync.
10. Enable Airplane Mode
11. Reboot to recovery and flash the SuperSU zip you downloaded
12. Boot into Android, open Titanium Backup and freeze MobileIron
13. Turn off Airplane Mode
14. Profit
Now restore your nandroid backup before you get in trouble.
After a reboot all of the lockscreen options will reappear allowing you to have an insecure lockscreen.
This is great
You just saved me hours of frustration.
Thanks!
Thanks - this is a huge help!!
Question: does this work only with Touchdown, or any Android email client? (I prefer the app Enhanced Email).
SoCalNewb said:
Thanks - this is a huge help!!
Question: does this work only with Touchdown, or any Android email client? (I prefer the app Enhanced Email).
Click to expand...
Click to collapse
I have only tested this as posted. Make a nandroid backup and play around with it
How to re-enable superuser?
Made a nandroid backup. Followed instructions below. Works great, now I can synch email with MobileIron fortified corp server AND change the PIN lock requirement that MobileIron required! Thank you
Only one issue: I couldn't complete step 10 ("Go back to menu, settings, apps, superser.apk and choose enable"). Superuser was no longer in the "All" list under menu, settings, apps. As a result, I seem to have lost the ability to grant root access to new applications.
QUESTION: How do I re-enable superuser?
Notes:
- ADB: I can connect to device via ADB, but if I type "adb shell", and then type "su" at the "sh-3.2#" promot, no $ access is granted).
- Terminal Emulator: TE cannot get root (I type "su" at the "sh-3.2$" command, and TE says "Permission denied")
- Root Access - Old Apps: Any apps that previously had root privileges still do (Root Explorer can navigate to "/" and enable "Mount R/W", Wifi Tether still works, etc).
- Root Access - New Apps: New apps requiring root are not able to get root (no superuser prompt comes up)
- Re-Installing Superuser.apk: I tried using root installer to re-install superuser.apk (in the "/system/app" directory). It said it installed successfully, but still no superuser in the "All" list under menu, settings, apps.
- Re-Rooting: I tried re-rooting (using mskip's exceelend GNEX toolkit HERE), to no avail (process completes, but no superuser access).
If anyone can help me troubleshoot I would be extremely appreciative. I've tried to not be a helpless newb and to try a few fixes (above), but I would be ecstatic if one of XDA's Android ninjas could tell me how to re-enable superuser. Hoping to avoid comments of "restore nandroid backup and give up"
bhilgeman said:
1. Open Hide my Root
2. Choose hide SU binary
3. Press home
4. Menu, settings, apps, all apps
5. Choose Superuser.apk
6. Choose disable
7. Now open mobileiron and configure the settings per your company's instruction.
8. Set up your email in the Touchdown application and let it sync everything.
9. Open Hide my Root and choose restore SU Binary
10. Go back to menu, settings, apps, superser.apk and choose enable.
11. Open Titanium Backup
12. Choose backup/restore from the top
13. Scroll to Mobileiron and tap it and choose freeze.
Click to expand...
Click to collapse
SoCalNewb said:
Made a nandroid backup. Followed instructions below. Works great, now I can synch email with MobileIron fortified corp server AND change the PIN lock requirement that MobileIron required! Thank you
Only one issue: I couldn't complete step 10 ("Go back to menu, settings, apps, superser.apk and choose enable"). Superuser was no longer in the "All" list under menu, settings, apps. As a result, I seem to have lost the ability to grant root access to new applications.
QUESTION: How do I re-enable superuser?
Notes:
- ADB: I can connect to device via ADB, but if I type "adb shell", and then type "su" at the "sh-3.2#" promot, no $ access is granted).
- Terminal Emulator: TE cannot get root (I type "su" at the "sh-3.2$" command, and TE says "Permission denied")
- Root Access - Old Apps: Any apps that previously had root privileges still do (Root Explorer can navigate to "/" and enable "Mount R/W", Wifi Tether still works, etc).
- Root Access - New Apps: New apps requiring root are not able to get root (no superuser prompt comes up)
- Re-Installing Superuser.apk: I tried using root installer to re-install superuser.apk (in the "/system/app" directory). It said it installed successfully, but still no superuser in the "All" list under menu, settings, apps.
- Re-Rooting: I tried re-rooting (using mskip's exceelend GNEX toolkit HERE), to no avail (process completes, but no superuser access).
If anyone can help me troubleshoot I would be extremely appreciative. I've tried to not be a helpless newb and to try a few fixes (above), but I would be ecstatic if one of XDA's Android ninjas could tell me how to re-enable superuser. Hoping to avoid comments of "restore nandroid backup and give up"
Click to expand...
Click to collapse
When you disable superuser.apk in the apps list it moves it from the alphabetical order to the bottom of the apps list. Look there and see if its at the bottom of your apps list.
bhilgeman said:
When you disable superuser.apk in the apps list it moves it from the alphabetical order to the bottom of the apps list. Look there and see if its at the bottom of your apps list.
Click to expand...
Click to collapse
YOU ARE THE MAN.
That was so simple, but I spent an hour trying stuff and still missed it
My Android experience is back to awesome despite Mobile Iron - THANK YOU!!!!
Thanks for that. Great idea.
I followed your instructions but I had to switch 9 and 10 because Hide my root cannot restore a deactivated app.
But my TouchDown says "Synchronization Error" --> access denied (update your password). Maybe too strong policies?
And by the way: you have to use tintanium backup PRO to enable or disable apps
---------------------
Edit: I made a system application of "Hide my root" with TI Backup - works. I had to uninstall TI Backup now - currently TouchDown is syncing again. We will see if it works, next: I try to use LBE Privacy Guard... will report. Disabling "MobileIron" seems not working for me...
Hey, is not possible solve it on 2.X version of Andriod? Thanks...
OP Updated to reflect Changes for those running JellyBean. Long live the Android experience!
bhilgeman said:
The SU change needed for JellyBean makes this previous method unusable. I did however figure out how to still get to the same result if you're running JellyBean.
I will so an update to the OP soon to reflect this.
Click to expand...
Click to collapse
Looking forward to the instructions for making this work on JB
SoCalNewb said:
Looking forward to the instructions for making this work on JB
Click to expand...
Click to collapse
OP updated for JB instructions.
Sorry, I haven't tested this on a 2.x build so I'm not sure. If I get time I'll try to test this for you, I'm just super slammed with projects right now...
Will we appear "normal" on the Server that the app links us to our Corp acct??
Yes, you will appear as a non rooted phone. I just updated the JB instructions again. Realized I left out a step.
Anyone test this for Airwatch yet?
FWIW.....my experience has shown this to be merely a temporary solution, by itself. Yes...following the JB instructions will allow you to sync up just fine. But.....when mobileiron does not report back as device administrator, the red flags go up. My solution, thus far, has been to suspend root access on the phone, after reactivating mobileiron. In my case, after re-activating mobileiron, the app, itself, now FC's, which may be helping me out....not sure. At this point I seem to be able to continue remaining synced, without root access. As long as I use airplane mode before enabling root access to do root-type stuff, I seem to be fine. Word of caution, though....disabling root, seems screw up TB when I re-enable root. Specificaly...even though I have TB pro, it does not register after re-enabling root, so freezing and unfreezing mobileiron at will has not been possible. Could just be my system though.I recommend using airplane mode liberally if there is any doubt regarding your recognized root/non-root status. This definitely changes how I use the device, though, for sure.
makelegs said:
FWIW.....my experience has shown this to be merely a temporary solution, by itself. Yes...following the JB instructions will allow you to sync up just fine. But.....when mobileiron does not report back as device administrator, the red flags go up. My solution, thus far, has been to suspend root access on the phone, after reactivating mobileiron. In my case, after re-activating mobileiron, the app, itself, now FC's, which may be helping me out....not sure. At this point I seem to be able to continue remaining synced, without root access. As long as I use airplane mode before enabling root access to do root-type stuff, I seem to be fine. Word of caution, though....disabling root, seems screw up TB when I re-enable root. Specificaly...even though I have TB pro, it does not register after re-enabling root, so freezing and unfreezing mobileiron at will has not been possible. Could just be my system though.I recommend using airplane mode liberally if there is any doubt regarding your recognized root/non-root status. This definitely changes how I use the device, though, for sure.
Click to expand...
Click to collapse
I run your CM10 build on my nex7 and love it. Great to have navbar mods.
On my nex7 it took me a few tries to get it to stick but I finally got it. I hadn't updated a nightly for a couple weeks and when I did Mobileiron got me. I decided I don't care about getting work email on my tablet as much as I do my phone so no big deal. I freaking hate Mobileiron and touchdown nearly as bad.
On my galaxy nexus (running fitsnugly cm10) I don't have any issues. I flash the nightlies every day and I've gone a couple months without Mobileiron flagging me.
Sent from my Nexus 7 using xda app-developers app
bhilgeman said:
I run your CM10 build on my nex7 and love it. Great to have navbar mods.
On my nex7 it took me a few tries to get it to stick but I finally got it. I hadn't updated a nightly for a couple weeks and when I did Mobileiron got me. I decided I don't care about getting work email on my tablet as much as I do my phone so no big deal. I freaking hate Mobileiron and touchdown nearly as bad.
On my galaxy nexus (running fitsnugly cm10) I don't have any issues. I flash the nightlies every day and I've gone a couple months without Mobileiron flagging me.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Skanklove!
I was completely under the radar, due to some corporate user configs, until I screwed up and raised the red flag. Then I had to encrypt, and install mobileiron. I was perfectly happy with touchdown until mobileiron got involved. I don't want work email on any device other than my work phone (toro). I can still run email without mobileiron, but no activesync and no email attachments......meh
Steps on ICS
Hello,
I am new to using mobileiron, as my corporation just started to use this program. Can I use your steps on ICS and keep my root undetected or will I eventually have issues. Last question, why is it necessary to restore your nandroid backup at the end?
This IS working for 4.3+ using xposed module.
http://forum.xda-developers.com/showpost.php?p=49878296&postcount=679
All credit goes to Phantasm4489. I am only adding the the OP so people can find it.
Below can be used for anything below 4.2 but I still think the xposed module above is better.
Standard Disclaimer:
**************************************************************************************************************
I AM NOT RESPONSIBLE FOR YOU BEING FIRED BY CIRCUMVENTING THE POLICY YOUR IT STAFF HAS PUT IN PLACE. I AM NOT RESPONSIBLE FOR BRICKING YOUR PHONE (ALTHOUGH SERIOUSLY DOUBT IT COULD POSSIBLY DO THAT). I AM NOT RESPONSIBLE FOR ANY DAMAGE WHAT SO EVER. THIS IS FOR EDUCATIONAL PURPOSES ONLY!!
**************************************************************************************************************
Click to expand...
Click to collapse
First off:
THANKS to sparky for the 'su' binary I use in my newer scripts.
THANKS to chainfire for the 'su' binary I use in my older scripts.
THANKS to Fallon for helping fine tuning the directions.
This thread is dedicated to using GFE on rooted devices. My intent is to understand root detection schemes for my own personal education. If the information here is beneficial to others, then that is a plus.
I came up with a process that satisfies both GFE and its use on rooted (technically temp unrooted) devices. Basically unrooting and rerooting the phone so that the GFE app functions and I comply with not running GFE on a rooted phone. .
Tested on CM9 and CM10 for the Epic 4 Touch and the Galaxy S3. I've seen success on other ROMS as well. If you run into issues, i'd be happy to help and improve the process.
What GOOD(GFE) detects and what it doesn't care about
Some key notes about what GFE seems to detect:
Detects 'su' anyplace on the phone /system partition (usually located in /system/bin/su or /system/xbin/su).
Detects the superuser apk and supersu apk
Detects if you have su'd in adb or shell while it is running. Close adb and log out of and shells before launch!
If you use a root tool like titanium, reboot before launching good! Titanium will sometimes leave open rooted processes running.
In pre-JB, it could use the READ_LOGS android permission to comb the system logs and find 'root like 'activity'. In JB, that 'security hole' is closed and that permission is locked down by android.
It detects if /system is RW.
The software is setup to never be shutdown. Once its started, it runs no matter what. Preventing it from starting is a good thing IMHO.
Seems that for some unknown reason, if es explorer was run in root mode at any point before running good, it detects root. Even if I manually kill all the back ground processes before unfreezing/launching Good.
Sometimes I get a compliance failed when I was working in ADB prior to running good. Typically if I was in ADB doing root work, i'll reboot the ROM before enabling good.
Turn off 'automatic update' for super user app from market
What GFE does not seem to care about:
busybox
CWM
locked/unlocked bootloaders
Here is how to make root and GFE play as nice as possible. This isn't perfect but it works pretty good. I still get the 'compliance failed' once in a while when i do something dumb. I am lucky in that I can clear data on the GFE app and reuse the prior key or request a new key from our IT system on demand. If you cannot do this easily, then this may be cumbersome. As we further progress this, we should get less and less lockouts.
SCRIPTED PROCESS
Downloads:
Something to run the scripts One of these will do:
- Connectbot or any shell execution program from play store. connectbot has widgets. I use connectbot.... - Script Manager found here: http://db.tt/Vonx78NI . Or playstore.
(required for PRE-JB roms only). Install Permissions Denied from the Market
The latest cwm/twrp flashable zip attached to this OP.
An installation of busybox. Typically comes with CM and lots of other ROMs but just making the point here that it is required.
Setup app and dependencies:
Flash the gfe_workaround_setup zip attached to this OP in CWM. This will create four scripts and a "backdoor" su binary. They are as follows:
/system/xbin/dger
/system/xbin/egdr
/system/xbin/fu. (The sparkysu binary is insecure so be careful out there! Just a disclaimer)
/system/xbin/r_dger
/system/xbin/r_egdr
Install Good Application
If pre-JB (NOT REQUIRED ON JB+), open Permissions Denied and disable the READ_LOGS permission for the Good Application. Immediately after disabling that permission reboot the device from within the Permissions Denied app (in the menu). It must be done from within the application immediately after toggling the permissions to denied.
Optional but recommended: use "autostarts app" (or similar) from market to turn off all autostarting flags for Good app. This is incase you forget to disable root before you reboot and dont want it to start after again after flashing a rom which would restore root..
Use Connectbot or old script manager to execute the enable/disable scripts.
HOW TO Use the scripts and run the Good.
These scripts will basically temp unroot your phone and disable the superuser user whenever you want to run good. It will reverse the operation whenever you want to return root and lockup good.
I typically leave good disabled unless I am using it but that is up to you.
Whenever you want to 'run good'. You will run the script egdr.
Whenever you want to disable good and return root to your phone run dger (prior to reboot for example or flashing roms or whatever)
DO NOT FORGET TO run the DGER script before flashing a rom since that rom will repush superuser and su and if good was enabled when you shutdown to reflash the rom, good will detect root and deactivate the handheld. Also since I disable the superuser user entirely when you flash the new rom, you will lose root and will need to enable the superuser user and reflash the rom to fix things... You can always just fix it with adb but renabling superuser... But that is a pain.
(pre-JB only) Permissions Denied takes FOREVER to startup, several minutes at least & you repeatidly see it getting root permissions, at first I thought it was having issues but that is how it works.
No need to "Lock Permissions" within the Permissions Denied app from what I've seen but ymmv
Under the ROM Developer Options "Root access" is irrelevant, GFE is working just fine with it set to "Apps and ADB right now"
GFE will work fine by wiping app data & initilizing it with a new PIN if you get things cleaned up after a policy violation
No need to get an unlock code from your sysadmins after a policy violation, just wipe app data for GFE & get a new PIN (assuming you have access to a website to request a new PIN
A mini-how to for connectbot:
I prefer this because connectbot is a simple tool and I like to keep it simple. But you may prefer the script manager interface instead.
With connectbot, you can create 2 'local' connections. One for each of the enable/disable scripts appropriately named. You can edit each of the local connections and setup 'post-login automation'. In the post-login automation you add the following (Note that <enter> means to put a line feed... i.e. hit enter ):
Code:
/system/xbin/dger;exit
<enter>
Code:
/system/xbin/egdr;exit
<enter>
You can either open connectbot each time and run the enable or disable scripts or you can add connectbot shortcuts to each local connection on your launcher's desktop. Its under 'add shortcut' you will see connectbot.
If you, like me, get annoyed by the notification icon from connectbot, you can optionally do these steps to execute it.
In the connectbot options, disable persistence. Also you can replace the ';exit' in the post automation commands with ';kill $PPID' and that will get you very close a self closing command. That will terminate the shell session you are in. When disabling GFE you'll still have to hit the back button but when enabling GFE it wont stay in your notification bar.
Example:
Code:
/system/xbin/dger;kill $PPID
<enter>
The negative is that if there was an issue, you wont see the log. I may add logging support in the scripts so that we can go back and look easier anyway at what failed if we get a lock out. If you ever needed to debug though just remove that temporarily and you'll see the log again.
If you wanted a few seconds to review the log, you could do something like this also:
Code:
/system/xbin/dger;[COLOR="Red"]sleep 5[/COLOR];kill $PPID
<enter>
A mini-how to for script manager:
In script manager you will add the scripts into script manager and execute them via the app or it's widgets. The scripts should NOT be setup to run as superuser but they still will prompt for super user when the disable one is actually executed and you should respond GRANT to that request. You will use the app to find the scripts in /system/xbin chosing the following:
Code:
/system/xbin/dger
Code:
/system/xbin/egdr
FAQ
Q: If I am going to dirty flash a new rom (no data wipe), What do I need to do to keep GOOD in compliance?
A: IT'S LIKE DANCING AROUND A LAND MINE! You will want to follow this process before and after flashing dirty:
Run dger to return root to your device and disable GOOD
Reboot into cwm
Flash rom and do any other rom specific instructions including any reboots or whatever the rom maintainer wants you to do.
Reflash the gfe_workaround zip from the op since flashing the rom overwrites it.
Boot into the rom and set it up as you like with root...
Run disable good enable root.sh to make sure things are well after rom flash.
reboot one last time
use scripts as normal
Q: If I am going to clean flash a new rom (wipe data), What do I need to do to keep GOOD in compliance?
A: Clean Flashing will require you to restore the good app or jsut reactivate it. You can likely avoid reactivation by following this. YMMV
Run dger to return root to your device and disable GOOD
Use Titanium Backup (or similar like carbon) to backup the GOOD app and data.
Reboot into cwm
Flash rom and do any other rom specific instructions including any reboots, wiping data/system or whatever\ the rom maintener wants you to do.
Reflash the gfe_workaround zip from the op since flashing the rom overwrites it.
Boot into the rom and set it up as you like with root...
Restore GOOD with Titanium. You may need to also restore your android ID with titanium as I am not sure if it hashes that ID with activation credentials.
Immediately run dger BEFORE REBOOTING to make sure things are well after rom flash.
Ensure you redisable any permissions denied things and autostarts.
reboot one last time
use scripts as normal
DEBUGGING PROCESS
So you've experienced a policy break/lockout? Now what?? This is how you can debug and give me what I need to help you if required:
flash newest scripts in OP and boot up and let it settle.
run the disable good script.
run enable good script.
run disable good script again.
That will create log files in /sdcard/ with the same names as the scripts. You can review those or submit them to me in this thread and I can look. I will also need the following. I review these files to see if there are any 'other' superuser or supersu apks that my scripts have missed. I will need the /sdcard/gfe.txt after you run the below to assist posted in the thread.
Run the following commands in a connectbot shell after above:
Code:
Code:
su
find /system/app /data/app /system/bin /system/xbin|sort > /sdcard/gfe.txt
pm list packages >> /sdcard/gfe.txt
Then give me these following logs:
/sdcard/gfe.txt
/sdcard/egdr.......log
/sdcard/dger.......log
Some of the most common reasons for lockouts are because of the running of certain root apps prior to enabling good. Certain root apps still retain root access after you close them. Notably es explorer and titanium. I'm sure there are others but this is two that I know of. If you use those tools either disable root access in them if applicable or reboot before running good after using them.
Change log
04-20-2013 (v16):
Renamed scripts and binary
04-03-2013 (v16):
Added "script complete" messages to output.
04-02-2013 (v15):
Added command line option to turn off auto-launch of GFE. The default will remain to auto-launch it.
04-01-2013 (v14):
Went back to sparky su as other su is causing too many anomolies.
FAQ added to OP.
02-26-2013 (v13):
Removed execution speed enhancement introduced in v11 as it caused some issues.
02-22-2013 (v12):
Further improved Logging to sdcards
Added some enhancements and termination of some root apps(titanium)
02-14-2013 (v11):
Improved script execution speed by parallelizing some operations
Added logging to /sdcard if available
02-04-2013 (v10):
Changed the way I handled superuser apps (or multiples) stored in data and system.
Added ability to handle chainfire's nonag apk in addition to regular supersu.
Started using supersu's su for a more secure setup.
Revamped directions and cleared up some errors in the OP.
01-29-2013 (v9):
added new mask for apk
added error handling for mounts incase.
01-25-2013 (v8):
reversed order of hiding apks between system/data to resolve
issue of supersu/superuser "forgetting" settings when rerooting.
12-18-2012 (v6):
added supersu support
fixed left over apks from super app upgrades
12-14-2012 (v3):
Added clean exit commands.
12-13-2012 (v2):
- Discovery that new script manager may cause compliance issues and doesn't work after temp unrooting!
12-12-2012 (v1):
- Fixed bugs
- Automated variables
- Created flashable setup script
- Simplified the install process
12-10-2012 ():
- Initial design
The 'manual' process may not work anymore. I believe supersu apks are getting picked up for compliance. There are a few more manual ways listed in this thread that may or may not work for you but you are welcome to try them.
MANUAL PROCESS
If the script process is too complicated for you and you want to do things manually, you can do this as well. It is a pain though and more prone to getting the handheld disabled by good because of user error (forgetting to do something).
The key to this way is that gfe doesnt appear to detect supersu apk and does detect superuser apk. Not sure how long this will last! ymmv
You can install supersu, open it and let it authorize. Then rename /system/app/Superuser.apk to super_user.rob since its not needed anymore and let supersu do the authorizations.
Then install "app quarantine" from the market or titanium backup. These apps let you freeze and unfreeze the gfe app so you can bounce between a rooted and unrooted phone. (hint: there are widgets for this in titanium and app quarantine that are much more convenient)
If pre_JB, Install "permissions denied" (in app store) to remove the some of the permissions from the app. specifically you must remove
READ_LOGS
The process is as follows once the above is complete and gfe is installed and you want to use gfe:
FROST GFE(reroot)
open gfe and go into preferences and select "disconnect" and then select shutdown good. VERY IMPORTANT TO DISCONNECT AND SHUTDOWN from within the GOOD app. Do NOT just hit the 'HOME' button and reroot. It WILL detect that it has been frosted and unfrosted if you do not follow this advice
immediately open supersu app and go to settings and select "enable supersu" to reenable root.
open app quarantine (or titanium) and freeze good so it won't autostart.
You can now use the rooted phone like normal.
when you want to use gfe, temp unroot as follows:
UNFROST GFE(temp unroot)
using titanium or app quarantine defrost gfe.
immediately open supersu and go to settings and uncheck "enable supersu". the will hide the su binary and temp unroot.
open gfe and use it like normal.
once done using gfe, refrost it like above
this works very well but ymmv. The scripted method works much better.
Finally had success getting GFE running a recent CM10 nightly on my AT&T SGS3 thanks to calisro. Thanks for figuring out a good work around to enable GFE! It looks like my issues this go around were with Permissions Denied & me doing some uninstall-re-install of GFE.
My process (tweaks to calisro's stuff mostly):
Uninstalled ES explorer (just to make sure it is not causing issues for now)
Installed GFE
Installed Script Manager (I've since upgraded to Script Manager-SManager(NoAds), always a good idea to support the devs)
Installed Permissions Denied
Installed su as /sdcard/rob_su
Opened Permissions Denied and disabled the following permission for the Good Application: READ_LOGS and RECEIVE_BOOT_COMPLETED
Rebooted from within Permissions Denied, checked & verified Good had the 2 permissions in question denied
Created the 3 scripts using the updated versions recently posted
setup_rootdoor.sh
enable_good_disable_root.sh (complete with the missing final line noted above)
disable_good_enable_root.sh
With Script Manager, ran setup_rootdoor.sh
Deleted all data for GFE through app manager
With Script Manager, ran enable_good_disable_root.sh
Activated GFE
Working GFE
Notes:
Permissions Denied takes FOREVER to startup, several minutes at least & you repeatedly see it getting root permissions, at first I thought it was having issues, but I guess that's normal behavior
No need to "Lock Permissions" within the Permissions Denied app from what I've seen
Under Developer Options "Root access" is irrelevant, GFE is working just fine with it set to "Apps and ADB right now"
GFE seems to be sucessfully cleaned up by deleting app data from within app manager
GFE will work fine by wiping app data & initializing it with a new PIN if you get things cleaned up after a policy violation
No need to get an unlock code from your sysadmins after a policy violation, just wipe app data for GFE & get a new PIN (assuming you have access to a website to request a new PIN
Logs & thoughts from of my previous failures & troubleshooting steps http://forum.xda-developers.com/showpost.php?p=33025295&postcount=5
Fallon said:
Finally had success getting GFE running a recent CM10 nightly on my AT&T SGS3 thanks to calisro. Thanks for figuring out a good work around to enable GFE! It looks like my issues this go around were with Permissions Denied & me doing some uninstall-re-install of GFE.
My process (tweaks to calisro's stuff mostly):
Uninstalled ES explorer (just to make sure it is not causing issues for now)
Installed GFE
Installed Script Manager (I've since upgraded to Script Manager-SManager(NoAds), always a good idea to support the devs)
Installed Permissions Denied
Installed su as /sdcard/rob_su
Opened Permissions Denied and disabled the following permission for the Good Application: READ_LOGS and RECEIVE_BOOT_COMPLETED
Rebooted from within Permissions Denied, checked & verified Good had the 2 permissions in question denied
Created the 3 scripts using the updated versions recently posted
setup_rootdoor.sh
enable_good_disable_root.sh (complete with the missing final line noted above)
disable_good_enable_root.sh
With Script Manager, ran setup_rootdoor.sh
Deleted all data for GFE through app manager
With Script Manager, ran enable_good_disable_root.sh
Activated GFE
Working GFE
Notes:
Permissions Denied takes FOREVER to startup, several minutes at least & you repeatedly see it getting root permissions, at first I thought it was having issues, but I guess that's normal behavior
No need to "Lock Permissions" within the Permissions Denied app from what I've seen
Under Developer Options "Root access" is irrelevant, GFE is working just fine with it set to "Apps and ADB right now"
GFE seems to be sucessfully cleaned up by deleting app data from within app manager
GFE will work fine by wiping app data & initializing it with a new PIN if you get things cleaned up after a policy violation
No need to get an unlock code from your sysadmins after a policy violation, just wipe app data for GFE & get a new PIN (assuming you have access to a website to request a new PIN
Logs & thoughts from of my previous failures & troubleshooting steps http://forum.xda-developers.com/showpost.php?p=33025295&postcount=5
Click to expand...
Click to collapse
FYI, I simplified the install with a flashable zip and some modifications to the scripts so that the work they do is dynamic rather than hard coded.
Discovered that the new Script Manager is potentially causing policy compliance issues. See the op for alternative or older version of script manager.
calisro said:
Discovered that the new Script Manager is causing policy compliance issues. See the op for alternative or older version of script manager.
Click to expand...
Click to collapse
Does it only trip when you use it? I think I saw Script Manager update a couple days ago, but haven't had any problems yet. Then again I haven't needed to mess with SM at all since then or even engage root for anything since I got GFE working on CM10 a week or so ago.
I'm having it fail compliance by simply having it installed. I've gone through and upgraded, tested, downgraded, tested, etc for a number of times to be sure and it keeps tripping as soon as it is used once. I've even installed it,denied superuser for the app, then used connectbot to actually run the script and it still failed. As soon as I go back to older version it works flawlessly again.
I'll be interested if yours' trips when toggle root and good once again.
De easiest way to perform tasks that require root is to use chainfire's exynos exploit apk to acquire root and when you're done use supersu to unroot.
Make sure you stop de GFE service before rooting! I just did this and GFE really stops working as I rooted, cleaned up my new polish Note 2 4.1.2. rom, unrooted, booted and used GFE like before, no policy violations.
Whatever you do, do not boot before you unrooted.
blackspp said:
De easiest way to perform tasks that require root is to use chainfire's exynos exploit apk to acquire root and when you're done use supersu to unroot.
Make sure you stop de GFE service before rooting! I just did this and GFE really stops working as I rooted, cleaned up my new polish Note 2 4.1.2. rom, unrooted, booted and used GFE like before, no policy violations.
Whatever you do, do not boot before you unrooted.
Click to expand...
Click to collapse
I wouldn't call that the easiest but to each their own.
While that may work for some people for a short time, it doesn't address a lot of things:
1) Doesn't work with superuser since Good detects the superuser apk and doesn't detect supersu yet. Detection of supersu will be added to Good at some point since its use is being coming more prevalent.
2) That exploit will be addressed soon since it affects millions of hand sets. Samsung will close the exploit and AOSP/AOKP will also address the exploit. So it will be useful for a short time only.
3) It only works for Samsung exynos based handsets only. My method is generic.
4) Requires reboots to bounce back and forth between root and unroot. Would be tiresome to do this many times a day.
5) if you reboot while your rooted, you'll get policy breaks.
v6 works great. the new method of CWM installation of scripts makes it very easy. i used the free autorun app "autorun manager" to disable the receiver flags of GFE.
the only annoyance that really is not bad is that when GFE is disabled, the shortcuts/widgets i have are removed since the app is hidden. a very acceptable price to pay considering my company has the "root" compliance turned on. this at least gives me access to email w/o rebooting when needed.
Thanks for all the work!
Do you have to use CWM recovery to flash the zip or can I use the team win recovery. I'm on Verizon note 2 with jelly beans v4 rom.
Thanks, Will
Sent from my SCH-I605 using xda app-developers app
wc4482 said:
Do you have to use CWM recovery to flash the zip or can I use the team win recovery. I'm on Verizon note 2 with jelly beans v4 rom.
Thanks, Will
Sent from my SCH-I605 using xda app-developers app
Click to expand...
Click to collapse
I have not tried twrp but it should work fine.
calisro said:
I have not tried twrp but it should work fine.
Click to expand...
Click to collapse
Just wanted to say thank you for your scripts. Installation worked perfectly on TWRP and to be safe I froze ES file Explorer in titanium since it came with my ROM.
I think my favorite part of the re root script is killing Good and not being bothered by work emails unless I want to be.
Sent from my SCH-I605 using xda app-developers app
glad they are working for you. what rom and phone are you on?
calisro said:
glad they are working for you. what rom and phone are you on?
Click to expand...
Click to collapse
Jelly Beans v4 ROM for Verizon Galaxy Note 2
Sent from my SCH-I605 using xda app-developers app
Good unrooted
Hi,
I've tried lots of different options, being a complete noob at this unrooting malarkey.
Having had a nightmare rooting, I finally managed it, only for Good to then not work because it was rooted.
I finally managed it thus: Downloaded the paid for version of SuperSU. Selected the 'clean up for complete unroot option', downloaded GFE, and self served a new pin, installed Good, went through the setup steps, et voila!
Have rebooted a couple of times and it's still working. Fingers crossed.
Galaxy S3 i9300 with a nightly build of CyanogenMod 10.1 Jelly Bean 4.2.
Not sure if it'll keep working, but I really hope so!
Bestbaldmanever said:
Hi,
I've tried lots of different options, being a complete noob at this unrooting malarkey.
Having had a nightmare rooting, I finally managed it, only for Good to then not work because it was rooted.
I finally managed it thus: Downloaded the paid for version of SuperSU. Selected the 'clean up for complete unroot option', downloaded GFE, and self served a new pin, installed Good, went through the setup steps, et voila!
Have rebooted a couple of times and it's still working. Fingers crossed.
Galaxy S3 i9300 with a nightly build of CyanogenMod 10.1 Jelly Bean 4.2.
Not sure if it'll keep working, but I really hope so!
Click to expand...
Click to collapse
If you completely unrooted it should be fine but now you don't have root unless you reflash. The point here was to offer a way to temp unroot.
calisro said:
If you completely unrooted it should be fine but now you don't have root unless you reflash. The point here was to offer a way to temp unroot.
Click to expand...
Click to collapse
*hangs head in shame for being a dumbass*
That said, it's no biggie to reflash with CF Root whenever I need Root. Which won't be very often I can't imagine... I've had the phone six months and only flashed it cos I got so frustrated with TouchWiz and the horrendous lag I was getting.
The SGS3 is my work phone; I'm an iOS boy for all my personal stuff (sorry!), so I'm quite used to operating without Root access!
Bestbaldmanever said:
*hangs head in shame for being a dumbass*
That said, it's no biggie to reflash with CF Root whenever I need Root. Which won't be very often I can't imagine... I've had the phone six months and only flashed it cos I got so frustrated with TouchWiz and the horrendous lag I was getting.
The SGS3 is my work phone; I'm an iOS boy for all my personal stuff (sorry!), so I'm quite used to operating without Root access!
Click to expand...
Click to collapse
But the scripts in the OP didn't work for you? What problems did you have?
I understand if it ain't broken don't fix it, but I'm also a noob and was able to get this working- the best of both worlds now!
Sent from my SCH-I605 using xda app-developers app
wc4482 said:
But the scripts in the OP didn't work for you? What problems did you get have?
I understand if it ain't broken don't fix it, but I'm also a noob and got the best of both worlds now!
Sent from my SCH-I605 using xda app-developers app
Click to expand...
Click to collapse
Truth be told, i'm not sure what happened. Flashed the ROM, installed connectbot, ran the scripts; nothing happened. Searched for the scripts in system/xbin but couldn't find them.
This was at the end of two days of battling with connection problems with Odin, phone getting stuck in Download mode, SD card not being recognised with the nightly build of CM 10.1 I was using, and a few other things.
I could probably have made it work, but being as my primary goal was to get rid of TouchWiz and all the Vodafone clag on the phone, that has been achieved.
At some point in the future, i might have another go. But as I'm someone who loves technology but isn't a techie, the instructions on most of these blogs are a bit difficult for my small brain to follow.
That's obviously my problem, not anyone else's, but it takes me a while to penetrate the language and understand what people mean. So, unless I really, really need to be switching back and forth between root and no root, I'll probably leave well alone for a while now.
Thanks, though, to everyone who is clearly a lot, lot cleverer and more persisten than I am for making all this wonderful stuff available.
The title explains it all. I'm trying to get rid of all the bloatware and other system apps I don't need on my Droid Mini (4.4 19.5.3, rooted, w/p off, BL locked) and some apps (specifically the Amazon appstore) I can't get rid of no matter what I do (it seems to be the apps in the /system/priv-app directory). I use Titanium Backup (I have the pro version), and it acts like it uninstalled it but it's still there. I use Clean Master and try to uninstall it but it fails. I use ES File Explorer (I have /system r/w mounted) and try to delete it and it says device or resource busy. Also get the device or resource busy error if I try to remove it via ADB. So I'm at a loss here.
Try to use system cleanup app from the playstore.
That app can see whats installes in priv-app.
w/p on/off isn't something i quite understand as i have only used bl unlocked maxx/mini, but what I personally do is install Root Browser, navigate to system/priv-app and rename the offending applications to app.apk.bak (example: Amazon.apk becomes Amazon.apk.bak) This way, if an update comes along I can erase the .bak and have the stock crap back. If you can't do this with your setup, i apologize, i just thought it might help, as I hate having to install an app just to do one function, and Root Browser is a great app for many things like this, not just one function.
The Xposed threads for older HDs haven't been updated in months, so I thought I would start a new one for the 2017 HD 10.
Before I begin, the standard disclaimer: This is a risky undertaking. If you encounter issues or, worse, end up with a brick, I (or the others here) will try to help you, but the risk is all yours. Before you start with Xposed, do a dd backup of your SuperSU-rooted /system (with SuperSU in /system) to use as a fallback. Details are below.
Xposed: Follow this guide to install Xposed. As of this writing, v89 works well.
Modules: See the screenshots for the modules I have installed and confirmed working and for the look of the status bar and the navigation bar using GB, FSBI, and Xstana.
Some other apps of choice:
Launcher: Apex (free)
Keyboard: Gboard
Browser: Lightning
File explorer: Root Explorer (only because I got it for free from an old Amz promotion)
Office: OfficeSuite (ditto reason above)
YouTube: OGYouTube
Media: VLC for Fire
Adblocker: AdAway
Backup: Titanium Backup and Backup+
Boot manager: ROM Toolbox Lite and All-In-One Toolbox
VPN: OpenVPN Connect
Update: I have finally been able to get FlashFire working, albeit an older version. I have tested backup/restore extensively (backup and restore of /system and /data) and flashed a few zips with success.
Requirements:
-- Root with SuperSU
-- FlashFire v0.24 or modified v0.51
-- Xposed with Per App Hacking module (to use Time Machine to load time-bombed FF)
-- Low risk aversion
-- Patience
Downloads:
-- Download the Xposed Installer from here. You should be downloading this framework: xposed-v89-sdk22-arm64 (the installer will likely pick it up from here).
-- Search for and download all the Xposed modules (the screenshot below contains the version numbers of the modules I have installed) from the Xposed Installer's Download tab. For modules that aren't in the Xposed repo, do a Google or XDA search. The Per App Hacking module is here.
-- Download FlashFire v0.24 or modified v0.51 from the attachments in this post.
I have now created a custom image (using dd) with SuperSU, Xposed, and FlashFire in /system. After a factory reset or adb sideload, I root with Kingo, dd this custom system.img, and reboot to have a SuperSU-rooted /system with working Xposed. You may have to run each of these apps once and reboot for things to work properly. Finally, install the Per App Hacking module to allow FlashFire to function. I would have loved to put the PAH module in /system as well, but FF doesn't like that.
FlashFire: How to get FF working and use it to backup and restore /system and /data:
-- Install FlashFire but do not open it. You can make it (and anything else) a system app at this point. I used Link2SD (long-press on the app and convert it to a system app), but manually moving it to /system/app or /system/priv-app works just as well. For SuperSU, just choose the option in Settings to make it a system app (this moves SuperSU to /system/app; you can confirm this using a root explorer). Reboot after you convert user apps into system apps.
-- Assuming you have Xposed working, install and activate the Per App Hacking module.
-- Go to the aforementioned module and scroll down to FF. Under Time Machine, choose a date around the time the version was active. For v0.24, I went with late Sept. 2015. The format is (date time): 2015-09-25 12:55.
-- Now start FF. It should open w/o complaints. Under Settings, use the best compression and all the cores.
-- This is not needed if you use FF to backup /system as a raw image, but here's how you use dd (to use as a failsafe in the event of a careless wipe, make sure you copy the backup off the tablet after it's done):
Code:
adb shell
su
dd if=/dev/block/mmcblk0p13 of=/sdcard/system.img
-- If you are happy with your system partition, you can now backup using FF. Choose "raw" backup.
-- Here's where you wait ... and wait ... and wait. I have timed this wait: First, the Fire will reboot to a near-black screen. It will spend about 4 minutes on that screen before a huge Loading sign in the center and a bunch of /system modules being loaded. Next, you will be on a black, but slightly brighter, screen for another 4 minutes, after which you will see the red FF at the top and the backup progress at the bottom. The actual backup should take a minute or so and the Fire will reboot. Your backup should be in /sdcard/FlashFire/Backups/. Open system.gz in 7-Zip and extract system. Save it as system.img (file extension optional).
-- To backup /data, choose Normal backup in FF, check the data partition, and repeat the rest of the steps in FF (above).
-- You can chain actions in FF. For example, you can backup /system as Raw and /data as Normal in one shot, saving you an eight-minute wait.
-- After a factory reset (or if root is lost), use (offline) Kingo to root as usual (do not reboot), but don't jump through hoops to install SuperSU. Use dd to write back the saved system img (assuming it's in /sdcard):
Code:
adb shell
su
mount -w -o remount /system
dd if=/sdcard/system.img of=/dev/block/mmcblk0p13; sync
Note: Doing a live dump onto a mounted partition is risky. The above process is meant to save a few minutes. If you have time to burn, use FlashFire to restore /system. Using the steps in "FlashFire w/o Xposed," this will be even quicker.
Wait a few minutes and reboot. (If your Fire reboots before this is done, you will be stuck at the Fire logo, but adb shell and su will still be available. Repeat the dd and it should work this time. I have noticed that the likelihood of reboot during dd is (much) greater when moving from one version of FireOS to another.)
-- After confirming SuperSU is working as expected (change the default access to Grant), uninstall the Kingo junk.
-- Finally, restore the data partition using FF, but before you do so, install Per App Hacking and tweak it to get FF working.
FlashFire w/o Xposed: If you only care about FlashFire and don't want Xposed, here's a quick-and-dirty non-Xposed way to get FlashFire working (say, after an adb sideload and SuperSU): Change the date using busybox:
Code:
busybox date -s "201509221745"
Changing the system date has implications beyond FF, so this is just a quick fix to get FF working to do a restore, after which you should look to PAH as the permanent solution.
Given the risk of data corruption when dding back a system.img into a mounted /system, here's my recommended approach:
-- adb sideload update.bin
-- Root with (offline) Kingo
-- Install SuperSU v2.79
-- Get FF working with backdating using busybox
-- Use FF to restore /system and /data from backup
I like to use swype for keyboard. I use a version 1.8 from oppo which has a bult in voice key that activates google voice input, instead of dragon. it just seems to read my mind much better than gboard, or swiftkey.
For launcher, i use nova.
for browser i use chrome, just because it has all my passwords and history from my desktops and laptops.
for youtube, i use iYTPB Vanced version. I used to mess around with OG Youtube but it wasn't nearly as functional for me; maybe it's gotten much better over the years. I install regular youtube, login, then rename the modded youtube to iYTPB and replace the base.apk for youtube. It stays logged in. The main thing it does is get rid of ads and unlimited resolution on mobile
edit: what does a boot manager do?
mistermojorizin said:
what does a boot manager do?
Click to expand...
Click to collapse
Prevents apps from running automatically at boot. You can also prevent apps from autorunning even after boot. This is a safer alternative (relative to wholesale uninstall).
ETA: See the updated OP for FlashFire-related information.
retyre said:
Prevents apps from running automatically at boot. You can also prevent apps from autorunning even after boot. This is a safer alternative (relative to wholesale uninstall).
To answer my question in the OP, I have finally been able to get FlashFire working, albeit an older version. Can't do much more than backup/restore at this point, but that's all I need (backup and restore of /system and /data). It has trouble restoring /system (presumably because FF starts by loading a minimal /system), but I just use good old dd to live-restore system.img.
Requirements:
-- Root with SuperSU
-- FlashFire v0.24
-- Xposed with Per App Hacking module (to use Time Machine to load time-bombed FF)
-- Low risk aversion
-- Patience
I have now created a custom image (using dd) with SuperSU, Xposed, FlashFire, and AdAway in /system. After a factory reset or adb sideload, I root with Kingo, dd this custom system.img, and reboot to have a SuperSU-rooted /system with working Xposed. Each of these apps has to be run once and rebooted for everything to work properly. Finally, install the Per App Hacking module to allow FF v0.24 to function. I would have loved to put the PAH module in /system as well, but FF doesn't like that.
Click to expand...
Click to collapse
this is very interesting! Nice work! Let me know if i got this right:
get flashfire working with Per App Hacking, make a backup of /data
make SuperSu, Xposed App, AdAway, and FlashFire system apps
created a custom image (using dd) with SuperSU, Xposed, FlashFire, and AdAway in /system
root with Kingo
dd this custom system.img and reboot
run SuperSu and reboot
run Xposed (app) and reboot
run FlashFire and reboot
run AdAway and reboot
install Per App Hacking module to make FF function
restore /data with flashfire
Now come the stupid questions. I've tried researching this but couldn't figure these parts out.
In step 1, how do you use PAH to get FF working? How do you backup /data from inside FF? (I see the guide for installing xposed, so that's a given, but then what?) Do you also backup system.img with FF? Do you backup /data as an .img? Also, which version xposed do you use? in the guide it says use v87 but v89 is the current version.
In step 2, how do you check if SuperSu is properly installed as a system app? (I had run "make supersu a system app" when I rooted, but I don't know if it actually worked. I was just happy to get permanent root.) If SuperSu is not a system app, what's the best way to do it? Use the option from within SuperSu or move the apk to /syste/app and set proper permissions?
In step 3, I don't know how to do that. I researched "dd" and I know it's an adb command. But how do you use it specifically make a live-restore system.img?
In step 4, do you mean run the kingo from the PC and get the "temp root" without rebooting (the state right after we root with kingo but if we reboot without doing anything else, the root is lost)?
In step 5, same question as step 3 - how do you specifically do it?
In step 11, how do you restore /data with flashfire
sorry for all these questions, just want to make sure I am doing it exactly how you did it.
mistermojorizin said:
Let me know if i got this right:
Click to expand...
Click to collapse
Snipped a lot of your post, but here are the answers:
-- Do 2. and 3. first. If you make a backup of /data with the four apps and then make them system apps, you will have duplicates (one in the data backup and one in your system img).
ETA: Most of the FlashFire-related information that used to be here is now in the updated OP.
retyre said:
Snipped a lot of your post, but here are the answers:
-- Do 2. and 3. first. If you make a backup of /data with the four apps and then make them system apps, you will have duplicates (one in the data backup and one in your system img). But before you do that, you need to get FF working:
Click to expand...
Click to collapse
I tried installing xposed using the steps from your post here: https://forum.xda-developers.com/showpost.php?p=74913548&postcount=160
now I am in a bootloop. it goes fire, optimizing apps, then loads walpaper and sometimes lockscreen, then reboots back to the fire logo. I use adb shell, su, mount system writeable, rm app_process64_xposed, says file not found (which makes sense because i made sure to delete it from system/bin before rebooting). What should I try?
mistermojorizin said:
I tried installing xposed using the steps from your post here: https://forum.xda-developers.com/showpost.php?p=74913548&postcount=160
now I am in a bootloop. it goes fire, optimizing apps, then loads walpaper and sometimes lockscreen, then reboots back to the fire logo. I use adb shell, su, mount system writeable, rm app_process64_xposed, says file not found (which makes sense because i made sure to delete it from system/bin before rebooting). What should I try?
Click to expand...
Click to collapse
Try this first. If that doesn't work, then this (not in TWRP obviously, but in a root shell from adb).
If SuperSU was working before you installed Xposed, you should be able to get to a root shell from adb, delete the xposed installer from /data/app and /data/data, and reboot.
Did you follow the steps to the letter?
retyre said:
Try this first. If that doesn't work, then this (not in TWRP obviously, but in a root shell from adb).
If SuperSU was working before you installed Xposed, you should be able to get to a root shell from adb, delete the xposed installer from /data/app and /data/data, and reboot.
Did you follow the steps to the letter?
Click to expand...
Click to collapse
yes pretty sure i followed the directions closely. here's what I did: installed xposed installer, selected install arm64-v89, deleted process_64, reboot. it optimized files for a while then went into this bootloop
i created a blank file from adb shell root system rw /data/data/de.robv.android.xposed.installer/conf/disabled and then used the ls command to make sure it is indeed in there. I changed the xposed installer in data/app and data/data to .bak rather than deleting altogether. still not working
mistermojorizin said:
yes pretty sure i followed the directions closely. here's what I did: installed xposed installer, selected install arm64-v89, deleted process_64, reboot. it optimized files for a while then went into this bootloop
i created a blank file from adb shell root system rw /data/data/de.robv.android.xposed.installer/conf/disabled and then used the ls command to make sure it is indeed in there. I changed the xposed installer in data/app and data/data to .bak rather than deleting altogether. still not working
Click to expand...
Click to collapse
See whether wiping the cache partition in recovery and rebooting helps. And /data/dalvik-cache/ from a root shell.
retyre said:
See whether wiping the cache partition in recovery and rebooting helps.
Click to expand...
Click to collapse
i tried that and it didn't help, so i wiped dalvik cache from adb
rm -r /data/dalvik-cache
rm -r /cache/dalvik-cache
took 10 minutes to boot, but didn't work, same behavior
mistermojorizin said:
i tried that and it didn't help, so i wiped dalvik cache from adb
rm -r /data/dalvik-cache
rm -r /cache/dalvik-cache
took 10 minutes to boot, but didn't work, same behavior
Click to expand...
Click to collapse
I think we have tried the usual Xposed-bootloop troubleshooting tips. Before you do adb sideload (w/o a factory reset), can you think of anything else you may have done to /system after your last working reboot? In particular, anything SuperSU-related?
no i didn't touch supersu, and i don't think i did anything with system either. is there any way to boot into safemode? also will sideloading 5.6 without factory reset get rid of root?
edit: it's so frustrating, it'll sometimes load the lockscreen and systemui, and even started nova launcher and i saw my homescreen. but it soft-reboots so quickly it seems like.
mistermojorizin said:
no i didn't touch supersu, and i don't think i did anything with system either. is there any way to boot into safemode? also will sideloading 5.6 without factory reset get rid of root?
edit: it's so frustrating, it'll sometimes load the lockscreen and systemui, and even started nova launcher and i saw my homescreen. but it soft-reboots so quickly it seems like.
Click to expand...
Click to collapse
Earlier Kindles had a safe mode (power + vol down), but I don't think ours does. Yes, sideloading update .bin will clean /system, thus removing root.
Putting the "disabled" file in /data/data/de.robv.android.xposed.installer/conf/ disables Xposed, so I doubt your current issue is Xposed-related (it may have been caused by the Xposed install, though).
Did you uninstall any system apps (or convert user apps like your launcher to system apps) after your last successful boot?
retyre said:
Earlier Kindles had a safe mode (power + vol down), but I don't think ours does. Yes, sideloading update .bin will clean /system, thus removing root.
Putting the "disabled" file in /data/data/de.robv.android.xposed.installer/conf/ disables Xposed, so I doubt your current issue is Xposed-related (it may have been caused by the Xposed install, though).
Did you uninstall any system apps (or convert user apps like your launcher to system apps) after your last successful boot?
Click to expand...
Click to collapse
no not since the last successful boot. i tried disabling a few root apps through adb, and then gave up and am doing the sideload. i've done this a ton of times the other day when i was trying to root. but now...it's stuck at 64% and in the screen says "patching system unconditionally'. It's been stuck for 5 minutes. I don't think this is normal, though i've never watched the whole process before.
Edit:it got through it and the %age is increasing at a reasonable pace now.
mistermojorizin said:
Edit:it got through it and the %age is increasing at a reasonable pace now.
Click to expand...
Click to collapse
After you root with SuperSU and set everything up, but before you try Xposed again (if you're not ready to give up yet!), do a dd dump of your system partition to use in the event of a boot loop.
retyre said:
Snipped a lot of your post, but here are the answers:
-- Do 2. and 3. first. If you make a backup of /data with the four apps and then make them system apps, you will have duplicates (one in the data backup and one in your system img). But before you do that, you need to get FF working:
-- Install FF v0.24 but do not open it. You can make it a system app at this point. I used Link2SD (right-click on the app and convert it to a system app), but moving it to /system/app or /system/priv-app works just as well. For SuperSU, just choose the option in Settings to make it a system app (this moves SuperSU to /system/app; you can check it using a root explorer). Reboot after you convert user apps into system apps.
-- Assuming you have Xposed working (v89 works fine), install and activate the Per App Hacking module.
-- Go to the aforementioned module and scroll down to FF. Under Time Machine, choose a date right after v0.24 was released (but before v0.26 just to be safe). I went with late Sept. 2015. The format is (date time): 2015-09-25 12:55.
-- Now start FF. It should open w/o complaints. Under Settings, use the best compression and all the cores.
-- This is not needed if you use FF to backup /system as a raw image, but here's how you use dd (make sure you copy the backup off the tablet after it's done):
Code:
adb shell
su
dd if=/dev/block/mmcblk0p13 of=/sdcard/system.img
-- If you are happy with your system partition, you can now backup using FF. Choose "raw" backup.
-- Here's where you wait ... and wait ... and wait. I have timed this (I know what you're thinking!): First, the Fire will reboot to a near-black screen. It will spend about 4 minutes on that screen before a huge Loading sign in the center and a bunch of /system modules being loaded. Next, you will be on a black, but slightly brighter, screen for another 4 minutes, after which you will see the red FF logo at the top and backup progress at the bottom. The actual backup should take a minute or so and the Fire will reboot. Your backup should be in /sdcard/FlashFire/Backups/. Open system.gz in 7-Zip and extract system. Save it as system.img (file extension optional).
-- To backup /data, choose Normal backup in FF, check the data partition, and repeat the rest of the steps in FF (above). FF does not give you the option to backup /data as a raw image (thankfully, so you're not left with a 20G backup because /sdcard is in /data).
-- After a factory reset (or if root is lost), use the Kingo PC app and root as usual (do not reboot), but don't jump through hoops to install SuperSU. Use dd to write back the saved system img (assuming it's in /sdcard):
Code:
adb shell
su
mount -w -o remount /system
dd if=/sdcard/system.img of=/dev/block/mmcblk0p13; sync
Wait a few minutes and reboot. (If your Fire reboots before this is done, you will be stuck at the Fire logo, but adb shell and su will still be available. Repeat the dd and it should work this time.)
-- After confirming SuperSU is working as expected (change the default access to Grant), uninstall the Kingo junk.
-- Finally, restore the data partition using FF, but before you do so, install Per App Hacking and tweak it to get FF working.
Click to expand...
Click to collapse
So I'm back up and running. I made a dd backup .
I got xposed going and I used time-machine for FF. Opened FF and hit the plus sign under actions, and selected only the data partition. It's been stuck on the fire splash screen for about 17 minutes now. Is that normal? I know you mentioned the raw system backup takes forever, but I thought data would go quicker, and I didn't expect it to spend all its time on the splashscreen.
edit: i force reboot after like 35mins of the boot screen. was glad to see that it reboot normally just fine. so i decided to try the raw system backup (by the way, in there it had system and boot prechecked, I unchecked boot - is that OK?). So I was expecting it to reboot to a blank screen as you mentioned, but nope, its just sitting at the "fire" boot screen again. I can get into ADB shell.
edit 2: i installed the wrong version of flashfire. gonna try again.
edit 3: 0.24 did the same thing
edit 4: changed FF to a user app, and now it seems to be working on backing up data partition (at least it's giving me a black screen instead of that boot logo). But to do system, i will need to move it to system. I've been using link2sd and it puts it in priv-app. maybe it should just be in system/app? It's working for you to backup system as a system app? Is it in priv-app?
mistermojorizin said:
So I'm back up and running. I made a dd backup .
I got xposed going and I used time-machine for FF. Opened FF and hit the plus sign under actions, and selected only the data partition. It's been stuck on the fire splash screen for about 17 minutes now. Is that normal? I know you mentioned the raw system backup takes forever, but I thought data would go quicker, and I didn't expect it to spend all its time on the splashscreen.
edit: i force reboot after like 35mins of the boot screen. was glad to see that it reboot normally just fine. so i decided to try the raw system backup (by the way, in there it had system and boot prechecked, I unchecked boot - is that OK?). So I was expecting it to reboot to a blank screen as you mentioned, but nope, its just sitting at the "fire" boot screen again. I can get into ADB shell.
edit 2: i installed the wrong version of flashfire. gonna try again.
edit 3: 0.24 did the same thing
edit 4: changed FF to a user app, and now it seems to be working on backing up data partition (at least it's giving me a black screen instead of that boot logo). But to do system, i will need to move it to system. I've been using link2sd and it puts it in priv-app. maybe it should just be in system/app? It's working for you to backup system as a system app? Is it in priv-app?
Click to expand...
Click to collapse
Changing FF to user vs. system app should have no bearing on being able to backup /system as a raw image. I use it as a system app (in /system/priv-app) and it works fine. Did the /data backup complete? What's the size of the .gz file in /sdcard/FlashFire/Backups/**/? Which backup option are you choosing and which partitions are you checking in there?
Read my section about FF starting up (and how many minutes each step should take). Look carefully at the screen and tell me whether you see the "two stages of black." The first black should be darker than the second, and there should be a bunch of scrolling text (this will only last a second or two, so you will have to stare at your screen like your life depends on it) between the two stages. If you don't see the red FlashFire at the top in 8-10 minutes, something's gone wrong. In general, it would be a good idea to keep an eye on the Fire's screen for the entire 10 minutes after you click Flash in FF and press OK.
retyre said:
Changing FF to user vs. system app should have no bearing on being able to backup /system as a raw image. I use it as a system app (in /system/priv-app) and it works fine. Did the /data backup complete? What's the size of the .gz file in /sdcard/FlashFire/Backups/**/? Which backup option are you choosing and which partitions are you checking in there?
Read my section about FF starting up (and how many minutes each step should take). Look carefully at the screen and tell me whether you see the "two stages of black." The first black should be darker than the second, and there should be a bunch of scrolling text (this will only last a second or two, so you will have to stare at your screen like your life depends on it) between the two stages. If you don't see the red FlashFire at the top in 8-10 minutes, something's gone wrong. In general, it would be a good idea to keep an eye on the Fire's screen for the entire 10 minutes after you click Flash in FF and press OK.
Click to expand...
Click to collapse
I ended up getting it to work. Had to uninstall, reinstall, change to user app again and everything worked. Don't know why it didn't work before. I appreciate all of your help. when doing the raw system backup, i only checked "system" and unchecked "boot". That sound right?
One thing I've been wondering about is why the arm64 version of xposed works on this devices. It does have a arm64 cpu, but it's instruction set is armv7 only, and from what i can tell, all of the apps it runs are not arm64 versions.
mistermojorizin said:
... when doing the raw system backup, i only checked "system" and unchecked "boot". That sound right?
One thing I've been wondering about is why the arm64 version of xposed works on this devices. It does have a arm64 cpu, but it's instruction set is armv7 only, and from what i can tell, all of the apps it runs are not arm64 versions.
Click to expand...
Click to collapse
Yes. You can check all the partitions just for completeness (esp. boot and recovery), but there's not much we can do with them at this time (other than for debricking; better to use dd with those images).
Yes, I noticed that as well. After trying the arm version, I realized the Xposed Installer cares more about the CPU architecture than the instruction set.
So, you never got FF to work as a system app? If it does, the only app to install after a dd restore will be PAH.
Were all the partitions backed up properly?
retyre said:
...
To answer my question in the OP, I have finally been able to get FlashFire working, albeit an older version. Can't do much more than backup/restore at this point, but that's all I need (backup and restore of /system and /data). It has trouble restoring /system (presumably because FF starts by loading a minimal /system), but I just use good old dd to live-restore system.img.
Requirements:
-- Root with SuperSU
-- FlashFire v0.24
-- Xposed with Per App Hacking module (to use Time Machine to load time-bombed FF)
-- Low risk aversion
-- Patience
Click to expand...
Click to collapse
May I inquire why you were using FF v0.24 ? What's wrong with the newer FF versions? Do they not work?
retyre said:
I have now created a custom image (using dd) with SuperSU, Xposed, FlashFire, and AdAway in /system. After a factory reset or adb sideload, I root with Kingo, dd this custom system.img, and reboot to have a SuperSU-rooted /system with working Xposed. Each of these apps has to be run once and rebooted for everything to work properly. Finally, install the Per App Hacking module to allow FF v0.24 to function. I would have loved to put the PAH module in /system as well, but FF doesn't like that.
Click to expand...
Click to collapse
What's the reason to save an img for /system, instead of just reloading everything upon getting root?
P.S. Wanted to add on the subject of Xposed. My must have Xposed modules are App Settings v1.13 (to make Chrome tabs behave like on a cell phone, instead of taking an extra line - link), GravityBox (to make status bar display notifications in colors, and up/down network traffic), and the module with a yellow smiley face (kind of like Walmart's)