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.
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.
Hi folks,
even though there are many nice 3rd party twitter clients available they are all missing an important feature: push notifications using GCM. The original Twitter app offers GCM based notifications but the app itself is more or less crap.
Therefore I thought about utilizing the original Twitter app for receiving GCM messages which create the Android notifications and then modify these notifications so that another (3rd party) app is started when clicking on them. I already managed to hook into the NotificationManager:
Code:
XposedHelpers.findAndHookMethod(android.app.NotificationManager.class, "notify", String.class, int.class, Notification.class, new XC_MethodHook() {
@Override
protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
XposedBridge.log("NotificationManager.beforeHookedMethod(): param=" + param);
for (Object o : param.args) {
if (o instanceof Notification) {
Notification n = (Notification) o;
XposedBridge.log("NotificationManager.beforeHookedMethod(): notification=" + n);
}
}
}
}
);
At this stage, where simple things as changing Notification.tickeText work, I tried the following:
1) Creating a new PendingIntent and assigning it to Notification.contentIntent:
Code:
Intent LaunchIntent = context.getPackageManager().getLaunchIntentForPackage("it.mvilla.android.fenix");
PendingIntent contentIntent = PendingIntent.getActivity(context, 0, LaunchIntent, 0);
n.contentIntent = contentIntent;
This fails due to the fact that I did not succeed in getting my hand on a Context instance. Does anyone have got an idea on how to get a Context instance or can provide another possibility for creating the PendingIntend without a Context?
2) As the previous did not work due to a missing Context I tried to change the LauchIntent of the existing Notification. But I was not able to find the correct place - I did not even find the original LaunchIntent when studying the sources or even by dumping the notification by reflection.
I also started investigating on how to hook into the Twitter app itself. But as the source code is (of course) not public and additionally is obfuscated this seems to be even more complicated. In addition hooking into the NotificationManager is more generic and would allow - when adding configuration - the redirection also for other sources and targets.
As you see, I am somehow stucked. But I'm not hopeless respectively cannot imaging that it should not be possible. So now it's up to you to feed me with the correct ideas
So far and thanks in advance,
yaan04
yaan04 said:
1) Creating a new PendingIntent and assigning it to Notification.contentIntent:
This fails due to the fact that I did not succeed in getting my hand on a Context instance. Does anyone have got an idea on how to get a Context instance or can provide another possibility for creating the PendingIntend without a Context?
Click to expand...
Click to collapse
AndroidAppHelper.currentApplication() should do the trick. Otherwise see this, though if AndroidAppHelper fails most of these probably will, too.
yaan04 said:
2) As the previous did not work due to a missing Context I tried to change the LauchIntent of the existing Notification. But I was not able to find the correct place - I did not even find the original LaunchIntent when studying the sources or even by dumping the notification by reflection.
Click to expand...
Click to collapse
LaunchIntent?
yaan04 said:
I also started investigating on how to hook into the Twitter app itself. But as the source code is (of course) not public and additionally is obfuscated this seems to be even more complicated. In addition hooking into the NotificationManager is more generic and would allow - when adding configuration - the redirection also for other sources and targets.
Click to expand...
Click to collapse
Android API calls won't be obfuscated. Try searching for "NotificationManager" for example and see where it's used.
Yeah, AndroidAppHelper.currentApplication() provides a usable Context instance \o/
Thanks, GermainZ. Now I can go on...
Letts assume there is a method
public static native boolean doSomething(params...);
which gets called by regular Java code.
Can Xposed hook it?
EDIT: I'm wrong, see rovo's answer.
Yes, native methods can be hooked. However, in case this is for an app's code, it has to be done after System.loadLibrary(), otherwise the latter overwrites the hook. Ideally, the framework should take care of this itself, but it's not straight-forward and the has been vey little need for this.
rovo89 said:
Yes, native methods can be hooked. However, in case this is for an app's code, it has to be done after System.loadLibrary(), otherwise the latter overwrites the hook. Ideally, the framework should take care of this itself, but it's not straight-forward and the has been vey little need for this.
Click to expand...
Click to collapse
I've always assumed this wasn't the case. Just to clarify, Xposed is able to hook native functions, but not (native) C/C++ code/libraries? I've read more than once it can't so I'm a bit confused. Thanks for the correction.
GermainZ said:
Just to clarify, Xposed is able to hook native functions, but not (native) C/C++ code/libraries?
Click to expand...
Click to collapse
Correct. Only JNI functions can be hooked, i.e. those which are declared in and called by Java code.
How to do it "after System.loadLibrary()"?
How you go about hooking such methods? I am trying to hook some API methods, mainly the ones declared in the "Connectivity" class one such example is "isTetheringSupported" however I am struggling to do so as when I hook the method directly, the hook is never executed as I believe it is being called via the java.lang.reflect.Method invoke method, and when I try and hook that method I get the following error "java.lang.NoSuchMethodError: java.lang.reflect.Method#invoke()#exact"
hwhh_1 said:
How you go about hooking such methods? I am trying to hook some API methods, mainly the ones declared in the "Connectivity" class one such example is "isTetheringSupported" however I am struggling to do so as when I hook the method directly, the hook is never executed as I believe it is being called via the java.lang.reflect.Method invoke method, and when I try and hook that method I get the following error "java.lang.NoSuchMethodError: java.lang.reflect.Method#invoke()#exact"
Click to expand...
Click to collapse
Are you talking about EdXposed? If so it should be noted that hook not working for a particular method can also be a result of art compiler optimizations. E.g. if the method is simple and not called from many places, compiler will include body of such method directly into methods that call that method. It's called inlining. So while you can see method at source code level, during runtime it's empty and never called as original body became part of another method. To overcome this you have to find a different strategy, e.g. hook such methods that are less likely to become inlined.
C3C076 said:
Are you talking about EdXposed? If so it should be noted that hook not working for a particular method can also be a result of art compiler optimizations. E.g. if the method is simple and not called from many places, compiler will include body of such method directly into methods that call that method. It's called inlining. So while you can see method at source code level, during runtime it's empty and never called as original body became part of another method. To overcome this you have to find a different strategy, e.g. hook such methods that are less likely to become inlined.
Click to expand...
Click to collapse
In order to see if it inlined, there is a setting in EDXPOSED to deoptimize boot image.
log(String.format("Class: %s method: %s with parameters of length %s : %s", param.thisObject.getClass().getName(),
param.method.getName(), String.valueOf(param.args.length), paramTypes));
Seems to always to result in java.lang.NullPointerExceptionor or at least most of the time.
I can check to see if param.thisObject is null but why would this be null?
Tungstwenty this is based off your xposed mod.
I'm guessing you're hooking a static method, in which case you can only access/call static fields/methods using the appropriate helpers.
If this is not the case, the full code would be helpful.
GermainZ said:
I'm guessing you're hooking a static method, in which case you can only access/call static fields/methods using the appropriate helpers.
If this is not the case, the full code would be helpful.
Click to expand...
Click to collapse
In the case I want to hook a static method, how can I obtain a thisObject of the class?
MPeti1 said:
In the case I want to hook a static method, how can I obtain a thisObject of the class?
Click to expand...
Click to collapse
If a method is static, it's not associated with a specific instance.
GermainZ said:
If a method is static, it's not associated with a specific instance.
Click to expand...
Click to collapse
Is it possible to check if a static method is called in a specific instance of the class?
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