Good for Enterprise (GFE) [03-7-2014] root workaround

Are you using SUPERSU or SUPERUSER?


  • Total voters
    253
Search This thread

auslander1138

Member
Dec 12, 2009
37
8
Calgary
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

Cheers man! I haven't yet updated on my phablet but I'll report back if I have any issues post update.

Sent from my SAMSUNG-SGH-I717 using xda app-developers app
 
  • Like
Reactions: calisro

calisro

Senior Member
Sep 9, 2008
1,871
754
noneya
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

Hm seems serious..... I will try the reboot but I am not sure if during reboot CM10 will mount again /system as RW. How can I check this?
Anyone else that has experience with other Native SD installations (non Nexus-Cm10) and does not have the same error (or fixed it somehow..)?

MANY THANKS
GV

Since you have a setup that I can't test with, you should ask in your device forum how you would remount your particular system partition setup. What may be causing the issue is the way nativesd is setup. I am wondering if we need either the --bind and/or the -type options on the mount command.

If you can figure that out, you can customize the script for your device easily.
 

gveloce

Member
Jan 5, 2007
42
6

gveloce

Member
Jan 5, 2007
42
6
You r right it is mounted RW again...
I found this btw
http://oletange.blogspot.de/2012/04/umount-device-is-busy-why.html
but dont know how it helps. I keep trying.....

thanks a lot
GV
I am progressing with small steps
On my NativeSD installation /system is mounted on the same dev/block/mmcblk0p2 device as /NativeSD and /data.
Not a unix expert but seems that something is keeping the fs busy from the other two mounted .....??

Any help appreciated. Hope this will help others that happen to be in my case (hope more than one=me!)

GV
 
Last edited:

calisro

Senior Member
Sep 9, 2008
1,871
754
noneya
I am progressing with small steps
On my NativeSD installation /system is mounted on the same dev/block/mmcblk0p2 device as /NativeSD and /data.
Not a unix expert but seems that something is keeping the fs busy from the other two mounted .....??

Any help appreciated. Hope this will help others that happen to be in my case (hope more than one=me!)

GV

Paste the output of

Code:
su
mount
df
 

gveloce

Member
Jan 5, 2007
42
6
Paste the output of

Code:
su
mount
df

Su: no output. Works
mount output (notice the common device for system data and NativeSD)
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,nosuid,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
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p2 /NativeSD ext4 rw,noatime,nodiratime,barrier=0,stripe=64,data=ordered 0 0
/dev/block/mmcblk0p2 /system ext4 rw,noatime,nodiratime,barrier=0,stripe=64,data=ordered 0 0
/dev/block/mmcblk0p2 /data ext4 rw,noatime,nodiratime,barrier=0,stripe=64,data=ordered 0 0
/dev/block/vold/179:1 /storage/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:1 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /storage/sdcard0/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0

df (seems enough...)
Filesystem Size Used Free Blksize
/dev 205.2M 48K 205.2M 4096
/mnt/asec 205.2M 0K 205.2M 4096
/mnt/obb 205.2M 0K 205.2M 4096
/NativeSD 849.3M 620.3M 229M 4096
/system 849.3M 620.3M 229M 4096
/data 849.3M 620.3M 229M 4096
/storage/sdcard0 1009.9M 343.9M 666M 4096
/mnt/secure/asec 1009.9M 343.9M 666M 4096

thanks for your support efforts!
GV
 

Fallon

Senior Member
Jan 23, 2007
300
47
Parker
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

Still working fine after the GFE app update a couple days ago. Even after updating to the 3/6 CM 10.1 nightly.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
 

calisro

Senior Member
Sep 9, 2008
1,871
754
noneya
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

Su: no output. Works
mount output (notice the common device for system data and NativeSD)
...
thanks for your support efforts!
GV

After a reboot is /system rw or ro? If system is always rw, then you won't get GOOD to run in this environment. GOOD detects the system mount as rw.

If when using nativesd the system mount is always rw that will be a problem hence why I ask if it changes to ro after reboot.
 

gveloce

Member
Jan 5, 2007
42
6
After a reboot is /system rw or ro? If system is always rw, then you won't get GOOD to run in this environment. GOOD detects the system mount as rw.

If when using nativesd the system mount is always rw that will be a problem hence why I ask if it changes to ro after reboot.
Hm. What if I change the FSTAB to have /system mounted as RO? Would this work??

GV
 

calisro

Senior Member
Sep 9, 2008
1,871
754
noneya
Hm. What if I change the FSTAB to have /system mounted as RO? Would this work??

GV

I'm not sure if that will break your nativesd implementation. If it does not, it may work. This likely won't stop the error you are seeing when trying to make the /system RO again but this is the procedure you can likely follow:

Whenever you want to Enable good:
1. Run the enable* script.
2. The script will error at the end when making /system RO.
3. Reboot to correct the mount point.
4. Launch Good.

Whenever you want to Enable root:
1. Run the disable* script.
2. The script will error at the end when making /system RO but that is irrelevant at the moment.
3. You are rooted.
 

calisro

Senior Member
Sep 9, 2008
1,871
754
noneya
Hm. What if I change the FSTAB to have /system mounted as RO? Would this work??

GV

You can get creative IF you can set /system to RO in /etc/fstab 1st and if you continue to get the 'resource or device busy' when changing it from RO->RW->RO...

1. Change fstab.
2. Make a new mount point for accessing system
Code:
su
mkdir /data/gfesystem
mount --bind -o rw,noatime,barrier=1,data=ordered -t ext4 /system /data/gfesystem
3. Change my scripts to access /data/gfesystem instead of /system and simply remove the mount commands from the script. You can then make your modifications using /data/gfesystem instead of /system.

There is always a way. Depends on how much energy you want to spend on it. :cool:

The best approach would be to figure out what is blocking the remounts and terminate it but this is under the assumption that you can even set that filesystem to RO in fstab and have it not break your nativesd.
 
Last edited:

gveloce

Member
Jan 5, 2007
42
6
I'm not sure if that will break your nativesd implementation. If it does not, it may work. This likely won't stop the error you are seeing when trying to make the /system RO again but this is the procedure you can likely follow:

Whenever you want to Enable good:
1. Run the enable* script.
2. The script will error at the end when making /system RO.
3. Reboot to correct the mount point.
4. Launch Good.

Whenever you want to Enable root:
1. Run the disable* script.
2. The script will error at the end when making /system RO but that is irrelevant at the moment.
3. You are rooted.
Thanks a lot mate!
I ll try and report back!
BTW I hate GFE methods but is the only way not to carry 2 phones (mine and a Blackberry!)

GV
 

Fallon

Senior Member
Jan 23, 2007
300
47
Parker
Still working fine after the GFE app update a couple days ago. Even after updating to the 3/6 CM 10.1 nightly.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2

[*]Just encountered some weirdness:
  1. Went to scan a QC code & could only get a black screen with no video
  2. Ended opening up the camera app & got an error message saying camera was disabled by security policy, even after a couple reboots
  3. Ended up disabling GFE
  4. When I re-enabled GFE I complained the security policy required a PIN (I already had one set)
  5. I was then bounced me over to the PIN lockscreen configuration, which prompted me for my PIN (only once as I already had one set
  6. Camera now works

No real long term problems, but it was weird. Not sure if it was related to our enable/disable hacks, an artifact of GFE being upgraded, or what.
 
  • Like
Reactions: calisro

calisro

Senior Member
Sep 9, 2008
1,871
754
noneya
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

yea, I had that pin thing happen after the upgrade. I'm guessing is GOOD weirdness is all.
 

Fallon

Senior Member
Jan 23, 2007
300
47
Parker
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

Just had it happen again & GFE wouldn't let me in complaining about the lock screen even when I changed to password from pin. GFE was happy again going back to my pin after a reboot. Odd.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
 

calisro

Senior Member
Sep 9, 2008
1,871
754
noneya
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

Just had it happen again & GFE wouldn't let me in complaining about the lock screen even when I changed to password from pin. GFE was happy again going back to my pin after a reboot. Odd.

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2

Do you have GFE set as a device administrator? settings - security - device administrator...

Mines been working fine on both my devices after that initial upgrade quirkyness.
 

Fallon

Senior Member
Jan 23, 2007
300
47
Parker
Do you have GFE set as a device administrator? settings - security - device administrator...

Mines been working fine on both my devices after that initial upgrade quirkyness.

Yes GFE is an administrator. Complains GFE might lock if I disable it's admin access, might try that tonight & see if it borks GFE.

And it looks like it ate my camera again. Going to do a TiBu backup then wipe stuff & update to the latest nightly this weekend & re-install things. See if that helps, it's been a little while since I've done that anyways.
 

calisro

Senior Member
Sep 9, 2008
1,871
754
noneya
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

Yes GFE is an administrator. Complains GFE might lock if I disable it's admin access, might try that tonight & see if it borks GFE.

And it looks like it ate my camera again. Going to do a TiBu backup then wipe stuff & update to the latest nightly this weekend & re-install things. See if that helps, it's been a little while since I've done that anyways.

Interesting. mine isn't. I removed it a while back. ymmv.
 

IT Rider

Senior Member
Nov 3, 2006
166
45
Chicago Area
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

With the new su in the latest nightlies, I now found that when I disable root, the su app does not return to the application list. Thoughts?

Sent from my SAMSUNG-SGH-I727 using Tapatalk 2
 

calisro

Senior Member
Sep 9, 2008
1,871
754
noneya
Re: Good for Enterprise (GFE) [02-24-2014] root workaround

With the new su in the latest nightlies, I now found that when I disable root, the su app does not return to the application list. Thoughts?

Sent from my SAMSUNG-SGH-I727 using Tapatalk 2

latest nightlies of what? and what superuser app are you using?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 41
    This IS working for 4.3+ using xposed module.

    http://xdaforums.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!! ;)
    **************************************************************************************************************

    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:
    1. 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
    2. Install Good Application
    3. 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.
    4. 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..
    5. 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:
    1. Run dger to return root to your device and disable GOOD
    2. Reboot into cwm
    3. Flash rom and do any other rom specific instructions including any reboots or whatever the rom maintainer wants you to do.
    4. Reflash the gfe_workaround zip from the op since flashing the rom overwrites it.
    5. Boot into the rom and set it up as you like with root...
    6. Run disable good enable root.sh to make sure things are well after rom flash.
    7. reboot one last time
    8. 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
    1. Run dger to return root to your device and disable GOOD
    2. Use Titanium Backup (or similar like carbon) to backup the GOOD app and data.
    3. Reboot into cwm
    4. Flash rom and do any other rom specific instructions including any reboots, wiping data/system or whatever\ the rom maintener wants you to do.
    5. Reflash the gfe_workaround zip from the op since flashing the rom overwrites it.
    6. Boot into the rom and set it up as you like with root...
    7. 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.
    8. Immediately run dger BEFORE REBOOTING to make sure things are well after rom flash.
    9. Ensure you redisable any permissions denied things and autostarts.
    10. reboot one last time
    11. 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:


    1. flash newest scripts in OP and boot up and let it settle.
    2. run the disable good script.
    3. run enable good script.
    4. 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
    31
    my company has just started using this and it blocks me due to having rooted my phone,

    I've been taking a look at the decompiled java smali code and the compliance checking routines look pretty straightforward. Almost too straightforward to be honest, All of the code is obfuscated but some parts of the compliance code stand out pretty clearly and it looks pretty simple to disable. Either the code is a dummy or there are further checks.

    I've made an xposed module that attempts to disable the compliance checking.

    If anyone wants to give it a try and report back that would be great.

    I will try it myself in time but i cant keep contacting my IT department to get my account reinstated as it will raise suspicion

    Update: I contacted my IT department this morning to get a new pin for GFE ive activated my account and so far its not detected that i have root on my phone.
    14
    the updated module shouldn't be too much longer now. I've got something that seems to work - just doing some final testing now before release.

    thanks to all who offered to help and especially those who I actually did contact for help with the testing.
    9
    here is a patched copy of gfe client 2.7 that should work fully in conjunction with the Xposed module.

    Ideally i would have liked to be able to implement this as either

    a) a fully cracked apk

    or

    b) an Xposed module that fully bypasses all of the security.

    So far i have not managed to achieve either of these so we are stuck with this less than ideal solution.

    The Xposed module posted a few pages back will bypass the root checking but the app will still detect the presence of the xposed framework as a completely separate check. The attached apk has the checks for the Xposed framework disabled. I had to modify some of the native libraries and resign the apk so you wont be able to install it over the top of the existing application but you can backup the existing installation using titanium and then uninstall. Once you have installed the attached apk you can restore the data only from the backup and you should be good to go.

    Let me know how you get on.

    Admin Note: We removed the Good for Enterprise APK due to DMCA complaint: https://github.com/xda/Notices/blob/master/2014/Good-2014-10-13.md Do not re-upload this APK as it is protected by copyright. Thank you.
    7
    prior apk version