Related
Guidelines for problem-free su usage
How-To SU is my guide on using "su" in your own programs (to execute commands as root). The guide covers the major common pitfalls and also provides example code, as I have been asked by several developers to provide.
I also did a presentation on this stuff at the Big Android BBQ 2012, so if you're looking for the article and code promised there, here it is!
The text is too long to copy here, but you can find it here:
http://su.chainfire.eu/
Example code is located on GitHub:
https://github.com/Chainfire/libsuperuser
If you are not an app developer, you have no business posting in this thread. This thread is for developer discussion on the article/example code only. In fact, I do not expect many posts in this thread at all - it's all rather straightforward, and this is not a helpdesk.
Moderators: Do not move this thread to a development subsection, 0-posters need to be able to reply to it.
Awesome job man, I definitely learned some new stuff. I've done a little bit differently than your implementation: instead of doing AsyncTask -> run su code inside I did this in my Root class:
Code:
class BackgroundThread extends AsyncTask<String, Void, Void> {
private String s;
public BackgroundThread(String command) {
s = command;
}
@Override
protected Void doInBackground(String... command) {
Process process = null;
DataOutputStream os = null;
try {
process = Runtime.getRuntime().exec("su");
os = new DataOutputStream(process.getOutputStream());
os.writeBytes(s+"\n");
os.writeBytes("exit\n");
os.flush();
process.waitFor();
} catch (Exception e) {
}
finally {
try {
if (os != null)
os.close();
else
process.destroy();
} catch (Exception e) {
}
}
return null;
}
}
And then receive the command in the parameter:
Code:
public void run(String command) {
new BackgroundThread(command).doInBackground();
}
Is this acceptable from your point of view?
No it isn't acceptable, but the reason is not what you might think.
Using a generic AsyncTask derived class to run su calls can be a solution. As long as your code ends up running in the background, all is good. However, in my experience what usually happens is that you have to do a lot of things in the background.
For example, imagine that during your app's startup, you need to check some files, perform some su calls, check some more files, do some computations, etc. Those should all go in a single AsyncTask's doInBackground method. That way you can use onPreExecute and onPostExecute to show and dismiss a dialog that tells the user you are busy.
Furthermore, if you had 10 su commands to run, would you just call new BackgroundThread ... 10 times? As the call should return before the su command is finished executing, the order of the executions of those commands becomes semi-random, you can't depend on them being run in any specific order, it even differs between Android versions (some versions run AsyncTasks serially, others run X of them in parallel). Not to mention that you shouldn't create 10 separate su processes to run 10 commands unless you have a good reason. Batching commands together == much higher performance.
The above does depend on which commands you need to execute, the needs of your application, and how you use it. If you only have to execute a single su command, it can be done that way, but I think in general this is not an ideal solution.
Now, the reason why your solution is truly unacceptable is because you are calling doInBackground. This does not make the code run in the background. You override doInBackground and insert your code, but you call the execute method. You should call your code like this:
Code:
new BackgroundThread(command).execute();
Else you're still calling on the main thread !
If you really want to keep using this method, keep in mind that you can actually pass parameters to the execute() function that in turn will be passed to doInBackground. Look in the AsyncTask documentation ...
that's a nice read
thanks for the guide
Chainfire said:
No it isn't acceptable, but the reason is not what you might think.
Using a generic AsyncTask derived class to run su calls can be a solution. As long as your code ends up running in the background, all is good. However, in my experience what usually happens is that you have to do a lot of things in the background.
For example, imagine that during your app's startup, you need to check some files, perform some su calls, check some more files, do some computations, etc. Those should all go in a single AsyncTask's doInBackground method. That way you can use onPreExecute and onPostExecute to show and dismiss a dialog that tells the user you are busy.
Furthermore, if you had 10 su commands to run, would you just call new BackgroundThread ... 10 times? As the call should return before the su command is finished executing, the order of the executions of those commands becomes semi-random, you can't depend on them being run in any specific order, it even differs between Android versions (some versions run AsyncTasks serially, others run X of them in parallel). Not to mention that you shouldn't create 10 separate su processes to run 10 commands unless you have a good reason. Batching commands together == much higher performance.
The above does depend on which commands you need to execute, the needs of your application, and how you use it. If you only have to execute a single su command, it can be done that way, but I think in general this is not an ideal solution.
Now, the reason why your solution is truly unacceptable is because you are calling doInBackground. This does not make the code run in the background. You override doInBackground and insert your code, but you call the execute method. You should call your code like this:
Code:
new BackgroundThread(command).execute();
Else you're still calling on the main thread !
If you really want to keep using this method, keep in mind that you can actually pass parameters to the execute() function that in turn will be passed to doInBackground. Look in the AsyncTask documentation ...
Click to expand...
Click to collapse
Hmm... I thought calling new BackgroundThread(command).doInBackground(); was doing it in the background thread... if I call new BackgroundThread(command).execute; the commands won't be called at all until I close the application/activity.
I don't do X new calls, for example in the BootService I just batch commands together and execute it once.
I'll use your code and see how it works.
Very nice reading. I always use AsyncTask for su commands, although I learned it the hard way
I remember few months back I couldn't figure out why supersu pops up when timeout is at 2-3 seconds
Sent from my HTC EVO 3D X515m using Tapatalk 2
I generally work with desktop apps. Is there a reason to not use Runnable?
Code:
public void liveBackgroundShellCommand() {
Runnable r = new Runnable() {
public void run() {
boolean LinkLaunched = false;
try {
String[] params = (String[]) Statics.LiveSendCommand.toArray(new String[0]);
Process process = new ProcessBuilder(params).start();
BufferedReader STDOUT = new BufferedReader(new InputStreamReader(process.getInputStream()));
BufferedReader STDERR = new BufferedReader(new InputStreamReader(process.getErrorStream()));
This is how I set up a background shell. Then I just pass in the su -c command. Is there a disadvantage to this?
AdamOutler said:
I generally work with desktop apps. Is there a reason to not use Runnable?
Code:
public void liveBackgroundShellCommand() {
Runnable r = new Runnable() {
public void run() {
boolean LinkLaunched = false;
try {
String[] params = (String[]) Statics.LiveSendCommand.toArray(new String[0]);
Process process = new ProcessBuilder(params).start();
BufferedReader STDOUT = new BufferedReader(new InputStreamReader(process.getInputStream()));
BufferedReader STDERR = new BufferedReader(new InputStreamReader(process.getErrorStream()));
This is how I set up a background shell. Then I just pass in the su -c command. Is there a disadvantage to this?
Click to expand...
Click to collapse
If this is about desktop Java, then I don't know. I don't use desktop Java, but in most languages and frameworks it is generally frowning upon to block the UI thread, and the UI thread is usually the main/default/first thread.
If we're talking about Android, then this may be bad, depending on what you are doing. A Runnable by itself says nothing about threading or being in the background, a Runnable is just a generic way to define some code you want to run somewhere, sometime.
The code you pasted here does start the process, but it does not wait for the process to exit or read/write to the streams. As such, this piece of code does not block, and is fine. 9 out of 10 times however, a piece of code like this is going to be followed by something like process.waitFor() or reading from STDOUT/STDERR in which cases it does block, and is thus holding up your UI thread and thus bad.
Furthermore, as detailed in the article, calling "su -c" can be errorprone.
Right. I generally launch in a Thread T=new Thread(..). I'be never used AsyncTask. I'm just wondering what its all about.
AdamOutler said:
Right. I generally launch in a Thread T=new Thread(..). I'be never used AsyncTask. I'm just wondering what its all about.
Click to expand...
Click to collapse
Ok, yeah that's fine. AsyncTask is pretty much a Thread wrapper with handy utility functions (onPreExecute, onPostExecute, onProgressUpdate) that is specifically aimed at running a short-lived task away from the UI thread, often with UI feedback (it's brilliant for use with progress dialogs, for example).
Chainfire said:
Ok, yeah that's fine. AsyncTask is pretty much a Thread wrapper with handy utility functions (onPreExecute, onPostExecute, onProgressUpdate) that is specifically aimed at running a short-lived task away from the UI thread, often with UI feedback (it's brilliant for use with progress dialogs, for example).
Click to expand...
Click to collapse
Ah ha! its like a SwingWorker() but with better functionality... Thanks Chainfire! I just looked and apparently it's not available on desktop or I would be switching immediately. That's a wonderful class.
Chainfire said:
Guidelines for problem-free su usage
How-To SU is my guide on using "su" in your own programs (to execute commands as root). The guide covers the major common pitfalls and also provides example code, as I have been asked by several developers to provide.
Click to expand...
Click to collapse
Great & sorely needed topic, thank you. I rarely check this forum, but stumbled in here. Hopefully busy devs of SU apps will be pointed here by someone.
I continue to have lots of problems with SuperUser/SuperSU apps that seem to be pre-configured or something to prevent SU access; and the user is never even prompted. But I don't think this is being discussed here.
At some point in the early development of ICS ROMs I noted that SU calls were taking much longer, perhaps about 0.1 seconds. So I optimized the 4-5 seconds and 40 or 50 calls (including blind chmod's for files that didn't exist on many devices) to about 2-4 calls for most devices.
I know I continue to be guilty of calling SU, and shell, and various other things from improper places, such as UI threads, onCreate etc. But I don't think these cause too much trouble in general, so putting these in threads or wherever is an exercise I save for an app re-design.
My app currently allows selection of "SU Type", but it doesn't seem to be needed anymore, now that I'm avoiding the quoting problems I've had previously.
I use the system() call from C/JNI in a lib. My best/default is like this, where CMD is the command, and noting that \" is " escaped in C:
system ("echo \"CMD\" | su -c sh");
This works, but writes to the filesystem every time:
system ("su -c \"sh /data/local/cmd\""); // Write CMD to cmd file first.
The simplest, but I was having more problems with this for whatever reason; perhaps quoting issues:
system ("su -c \"CMD\"");
thx
---------- Post added at 11:03 PM ---------- Previous post was at 10:58 PM ----------
it is great
pisy3 said:
thx
---------- Post added at 11:03 PM ---------- Previous post was at 10:58 PM ----------
it is great
Click to expand...
Click to collapse
I'm trying to convert my app to use your example classes for running root commands, as most of my app was implemented ok, but I needed to change a couple of bits based on your document. Once chaning I keep running into the following error:
11-20 22:16:39.770: I/System(31924): libcore.io.ErrnoException: kill failed: ESRCH (No such process)
11-20 22:16:39.770: I/System(31924): at libcore.io.Posix.kill(Native Method)
11-20 22:16:39.770: I/System(31924): at libcore.io.ForwardingOs.kill(ForwardingOs.java:77)
11-20 22:16:39.770: I/System(31924): at java.lang.ProcessManager$ProcessImpl.destroy(ProcessManager.java:257)
11-20 22:16:39.770: I/System(31924): at eu.chainfire.libsuperuser.Shell.run(Shell.java:100)
11-20 22:16:39.770: I/System(31924): at eu.chainfire.libsuperuser.Shell$SH.run(Shell.java:149)
11-20 22:16:39.770: I/System(31924): at com.rageconsulting.android.lightflow.util.RootUtil.runRootUnixCommand(RootUtil.java:49)
I'm calling my own helper method which is just a wrapper around your Shell class and it's getting called from an IntentService so I'm not quite sure why this happens.
You can ignore that.
By calling exit here, the process is usually gone.
When it tries to destroy the process in this line, the process is already gone, so it throws that error message as there is nothing to kill/destroy.
Before Android 4.0 this message was not even printed into the log.
Update the library code with some changes (like proper gobbling). See GitHub
Hello dear developers of the supersu. first thanks for good work. I don't know if anyone informed but after htc one s jb update there seem to be some compatibility problems.
The article has been updated to v1.20.
Changes are clearly marked in the "Table of Contents"
http://su.chainfire.eu/
Does the library support other superuser apps too?
mcnamaragio said:
Does the library support other superuser apps too?
Click to expand...
Click to collapse
Yes, it's all about best practises when calling the su binary - it should work with all superuser apps.
I want to develop a permission manage program.
but how can i hook the method startActivity?
it has
startActivity(Intent)
startActivity(Intent,Bundle)
startActivityForResult(Intent,int)
startActivityFromChild(Activity,Intent)
.....
and other overload method.
which one should i hook?
if I hook all the methods,when startAcitivyt(Intent) is called, and all the methods are called too.
but if I only hook startActivity(Intent), when the startAcivity(Intent,Bundle) is called,i will not catch it.
please help me.thanks.
Look at the source code, startActivity(Intent) will call startActivity(Intent, Bundle) so you only need to hook the latter. This may vary between different Android versions so you'll also want to check that.
In general you can also define a hook then use that for multiple methods. For example:
Code:
ZC_MethodHook hook = new XC_MethodHook(...);
findAndHookMethod (someClass, "someMethod", Argument.class, AnotherArgument.class, hook);
"someMethod", Argument.class, hook);
GermainZ said:
Look at the source code, startActivity(Intent) will call startActivity(Intent, Bundle) so you only need to hook the latter. This may vary between different Android versions so you'll also want to check that.
In general you can also define a hook then use that for multiple methods. For example:
Code:
ZC_MethodHook hook = new XC_MethodHook(...);
findAndHookMethod (someClass, "someMethod", Argument.class, AnotherArgument.class, hook);
"someMethod", Argument.class, hook);
Click to expand...
Click to collapse
but there is a problem.
if the two methods are:
void methodA(){
//some code ..
methodA(0);
}
void methodA(int a){
//...
}
if i hook methodA(int) and prevent it from running. when methodA() is called, the "some code" will execute,but then stop.
tonyzzp said:
but there is a problem.
if the two methods are:
void methodA(){
//some code ..
methodA(0);
}
void methodA(int a){
//...
}
if i hook methodA(int) and prevent it from running. when methodA() is called, the "some code" will execute,but then stop.
Click to expand...
Click to collapse
This isn't the case for startActivity - again, look at the source code.
I'm not sure what you're asking here, to be honest. Of course, you *can* hook both methods (or even all of them using hookAllMethods, but be careful about argument when you do that), but in startActivity's case that seems unnecessary.
have some problems with static values used as flags.
for example I need to hook 2 methods in different FRAMEWORK classes during initZygote. (no problem with system apps during handleLoadPackage)
I hook method in first class, set static value and waiting when another method of another class will be triggered.
once another method is invoked, flag always has it's initial state.
it looks like each hook method processed in different class instances.
i tried volatile type, tried to synchronize - nothing help.
unreliable remedy:
1. register broadcast receiver inside hook method.
2. send action to own service
3. send broadcast from own service.
4. catch broadcast with receiver.
BUT it is not battery cost efficient solution in my case. And mostly I receive broadcast message when hooking method already processed and returned value. Otherwise I need to wait when service will process request and send broadcast. But it is not usable.
is there any solution?
Code:
public class XMain implements IXposedHookInitPackageResources, IXposedHookZygoteInit, IXposedHookLoadPackage
{
private static boolean isNeedToRun = false;
public void initZygote(StartupParam startupParam) throws Throwable
{
findAndHookMethod("com.class1", null, "method1", int.class, new XC_MethodHook()
{
@Override
protected void beforeHookedMethod(final MethodHookParam param) throws Throwable
{
isNeedToRun = true;
}
});
findAndHookMethod("com.class2", null, "method2", int.class, new XC_MethodHook()
{
@Override
protected void beforeHookedMethod(final MethodHookParam param) throws Throwable
{
if (isNeedToRun) param.setResult(null); // always FALSE even if previous hook set as TRUE
}
});
}
}
Why do you think that using a broadcast receiver is not battery efficient?
GermainZ said:
Why do you think that using a broadcast receiver is not battery efficient?
Click to expand...
Click to collapse
I do not want to invoke service and send broadcast very often (several thousands times during normal battery one cycle charge)
I just want use easiest way by storing flag inside class and worried that users will find the module in the list of gluttonous applications.
Falseclock said:
Code:
if (isNeedToRun) param.setResult(null); // always FALSE even if previous hook set as TRUE
Click to expand...
Click to collapse
You're probably not considering the fact that different processes will each have its own "isNeededToRun" variable.
Whenever new processes (system_process, apps, etc.) are forked from zygote, each of them will have its own independent state which includes this static variable. From then on they will be completely separate things even if it's a variable with the same name, don't get confused by that.
Try adding a Log.i(...) call to write something in both methods, and then check the logcat for the pid in which the messages are logged. I bet you'll see that different pids are writing and reading, and you can't expect them to be doing it in the same global variable.
Tungstwenty said:
You're probably not considering the fact that different processes will each have its own "isNeededToRun" variable.
Whenever new processes (system_process, apps, etc.) are forked from zygote, each of them will have its own independent state which includes this static variable. From then on they will be completely separate things even if it's a variable with the same name, don't get confused by that.
Try adding a Log.i(...) call to write something in both methods, and then check the logcat for the pid in which the messages are logged. I bet you'll see that different pids are writing and reading, and you can't expect them to be doing it in the same global variable.
Click to expand...
Click to collapse
Yes, I realized this. But under handleLoadPackage everything work perfect.
Any suggestion to solve situation?
Falseclock said:
Yes, I realized this. But under handleLoadPackage everything work perfect.
Any suggestion to solve situation?
Click to expand...
Click to collapse
handleLoadPackage is executed after the fork, in the new process. Not sure what exactly you hooked when you tried that way, but probably both callbacks were executed in the same app/process.
You have the typical problem that requires some kind of inter-process communication (IPC). Most common examples for IPC in Android are broadcasts and services. Files might also be an option (especially with observers), but probably not when you need to change the value very frequently.
I'm trying to use Google Play Services APIs in a hooked method, but Google Play Services complains that I'm missing its version specification in the applications manifest, which makes sense since the application of which I hook the method doesn't integrate Google Play Services so its missing the meta-data tag from the manifest. Is there a way to inject the following meta-data into the hooked method's application process?
<meta-data
android:name="com.google.android.gms.version"
android:value="@integer/google_play_services_version" />
Or any alternative approach? Sorry if this has come up before, I'm a noob and I tried searching but didnt come up with anything.
As far as I know thats not possible.
You can try to hook the PackageManager and change the returned data to fool the check which is made. Not sure about other side effects, though.
theknut said:
You can try to hook the PackageManager and change the returned data to fool the check which is made. Not sure about other side effects, though.
Click to expand...
Click to collapse
Thanks for the suggestion! I tried hooking the method from PackageManager, but I must be missing something as I cant hook it and there is no error in the xposed log.
I wrote a quick test app com.example.overridetest which uses this code to get some meta-data from the manifest, which works fine:
Code:
localApplicationInfo = getPackageManager().getApplicationInfo("com.example.overridetest", 128);
Bundle localBundle = localApplicationInfo.metaData;
localBundle.getInt("com.google.android.gms.version");
Log.w("myApp", "metadata is "+i);
now im trying to hook getApplicationInfo in order to overwrite what it returns, however Im not able to hook it and theres no error in the xposed log either:
Code:
public void handleLoadPackage(final LoadPackageParam lpparam) throws Throwable {
if (!lpparam.packageName.equals("com.example.overridetest"))
return;
XposedHelpers.findAndHookMethod("android.content.pm.PackageManager", lpparam.classLoader, "getApplicationInfo", String.class, int.class, new XC_MethodHook() {
@Override
protected void beforeHookedMethod(XC_MethodHook.MethodHookParam param) throws Throwable {
XposedBridge.log("getApplicationInfo Hooked");
}
});
Subbed!
This sounds interesting
EDIT: Solution was posted to bypassing root-detection in the Amazon Flex App using a recently added feature to Security Bypasser 1.0.9.
****************
I have an Amazon app for doing contract deliveries for them, I need it to work on my rooted device. I'm pretty sure I've exhausted all other means of hiding root, as they are using native code (I think) to make one of their root checks.
They are implementing RootBeer to do their root-check. I have used APKTools to inspect the Amazon apk, coupled with reading through the source code for RootBeer I feel like I am just around the corner from getting this thing cracked.
UserAlertManager.smali has this line in it:
Code:
invoke-static {}, Lcom/scottyab/rootbeer/RootBeer;->checkForRootNative()Z
RootBeer.java has this:
Code:
/**
* Native checks are often harder to cloak/trick so here we call through to our native root checker
* @return true if we found su | false if not
*/
public boolean checkForRootNative() {
String binaryName = "su";
String[] paths = new String[Const.suPaths.length];
for (int i = 0; i < paths.length; i++) {
paths[i] = Const.suPaths[i]+binaryName;
}
RootBeerNative rootBeerNative = new RootBeerNative();
rootBeerNative.setLogDebugMessages(true);
return rootBeerNative.checkForRoot(paths) > 0;
}
And rootBeerNative is:
Code:
package com.scottyab.rootbeer;
/**
* Created by mat on 19/06/15.
*/
public class RootBeerNative {
/**
* Loads the C/C++ libraries statically
*/
static {
System.loadLibrary("tool-checker");
}
public native int checkForRoot(Object[] pathArray);
public native int setLogDebugMessages(boolean logDebugMessages);
}
And below is about where I am at:
Code:
package com.deleonemail.fixdet;
import android.util.Log;
import de.robv.android.xposed.XC_MethodReplacement;
import de.robv.android.xposed.XC_MethodHook;
import static de.robv.android.xposed.XposedHelpers.findAndHookMethod;
import de.robv.android.xposed.IXposedHookLoadPackage;
import de.robv.android.xposed.XposedBridge;
import de.robv.android.xposed.callbacks.XC_LoadPackage.LoadPackageParam;
public class stopdet implements IXposedHookLoadPackage {
public void handleLoadPackage(final LoadPackageParam lpparam) throws Throwable {
if (!lpparam.packageName.equals("com.amazon.rabbit"))
return;
findAndHookMethod("com.amazon.rabbit.android.presentation.alert.useralert.UserAlertManager", lpparam.classLoader, "checkForRootNative", new XC_MethodHook() {
@Override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
Log.v("rootbeer","grabbed UAM");
param.setResult(false);
}
});
//XposedBridge.log("we are in RootBeer!");
//param.setResult(false);
}
}
Any help getting this thing working right would be amazing!
nightauthor said:
Any help getting this thing working right would be amazing!
Click to expand...
Click to collapse
I was asked to add Amazon Flex support to my Xposed module and I just released it a few minutes ago. Check out Security Bypasser 1.0.9. You can check the source code. Your code is actually correct, but RootBeer has 5 more root checking functions active in Amazon Flex, that's why it still failed for you.
Amazon Flex' native library is "just" calling Java code, thus Xposed can easily override the functions. Other apps do stuff directly from native code, and that's much harder.
Setialpha said:
I was asked to add Amazon Flex support to my Xposed module and I just released it a few minutes ago. Check out Security Bypasser 1.0.9. You can check the source code. Your code is actually correct, but RootBeer has 5 more root checking functions active in Amazon Flex, that's why it still failed for you.
Amazon Flex' native library is "just" calling Java code, thus Xposed can easily override the functions. Other apps do stuff directly from native code, and that's much harder.
Click to expand...
Click to collapse
Thank you so much, this works perfectly. I'll definitely give the source a look. I didnt think to get into the other stuff because looking at the LogCat I only saw the xbin/su being detected, so I figured I needed to stop that and maybe move on from there.
I guess I was doing something wrong with the log command, because I never saw anything come up in my Logcat when trying to hook anything other than rabbit. I also wasnt sure about the "com.scottyab.rootbeer.RootBeer.isAnyPackageFromListInstalled())", didnt know if I needed rootbeer.RootBeer or just rootbeer.METHOD(). Thanks for your work and the great reference material.
I was concerned that this process might be harder than it was, because I thought surely someone would have done it already. And it seems you beet me to it, it was a learning experience, spent countless hours the past 1.5 days reading about Xposed, trying to make a module, figuring out that Instant Run in Android Studio sucks. And a bunch of other little things that took way too long to figure out. But here I am, pretty damn close to actually knowing how to hook and override a method.
how did it go?
Root-detection is no-longer bypassed
Amazon turned on some kind of new root-checking functionality in Amazon Flex today. No method of root-hiding seems to work at this moment. Not hiding the binary, not Security Bypasser, etc.
Can anything be done about this? It's kind of a big deal.
_kauffy_ said:
Amazon turned on some kind of new root-checking functionality in Amazon Flex today. No method of root-hiding seems to work at this moment. Not hiding the binary, not Security Bypasser, etc.
Can anything be done about this? It's kind of a big deal.
Click to expand...
Click to collapse
I updated just an hour ago, and while something had changed as far as the functionality of my script, the app did not seem to notice my phone being rooted at all.
Due to the changes on the offers page causing issues with my script, I reverted (I had created a backup on titanium backup). I will need to do some more testing later, but for now, I am going to keep using this version of the app for as long as I possibly can.
Still a problem with mine..
nightauthor said:
I updated just an hour ago, and while something had changed as far as the functionality of my script, the app did not seem to notice my phone being rooted at all.
Due to the changes on the offers page causing issues with my script, I reverted (I had created a backup on titanium backup). I will need to do some more testing later, but for now, I am going to keep using this version of the app for as long as I possibly can.
Click to expand...
Click to collapse
What market are you in? It may be they haven't pushed this to all the markets yet.
Also, what are you using root for in this case? I think it may be the same as I am. Curious how you did it, though we might want to take this conversation out of public view.
nightauthor said:
I updated just an hour ago, and while something had changed as far as the functionality of my script, the app did not seem to notice my phone being rooted at all.
Due to the changes on the offers page causing issues with my script, I reverted (I had created a backup on titanium backup). I will need to do some more testing later, but for now, I am going to keep using this version of the app for as long as I possibly can.
Click to expand...
Click to collapse
Im using the module on the amazon version 3.0.5947.2 and is working fine. Thanks for the module. :good:
Anonymus1725 said:
Im using the module on the amazon version 3.0.5947.2 and is working fine. Thanks for the module. :good:
Click to expand...
Click to collapse
Do you have the apk for your version, and can you get it to me? Thanks!
CommanderZurek said:
Do you have the apk for your version, and can you get it to me? Thanks!
Click to expand...
Click to collapse
I dont have the phone now its in a repair shop, and I have a SD but I dont have a SD card reader. when I have Back I can check if I have the APK.
Bypass root detection
Hopefully this will help someone... I had a Verizon S6 that i rolled back to OK7, then rooted by using the tar file in this folder and kingroot G920V Root By RubenTomala files. Then installed Amazon flex and it detected root. I used Xposed Installer by dvdandroid to install Xposed and then installed Wanam.
I installed the bypass module and tried it no go. Then i tried it with Bypasser module and rootcloak and it worked fine.
how do you bypass this root-check on Android 7.x / Lineage OS 14.1 without Xposed ?
Bypass for maadhaar app
I also find the rootbeer native detection in the maadhaar app. Can you please bypass the rootdetection for this https://play.google.com/store/apps/details?id=in.gov.uidai.mAadhaarPlus also.
I will be very thankful.
It is not working no more.
May you help me to bypass root-checker library, please?
Thank you very much