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.
Related
This is /sort/ of a development question; if the mods feel it's more properly in Q&A, please move it.
First off, a little disclosure; "IANAP".
Okay, here goes:
Currently I am trying to create what ought to be a /very/ simple script using "am" (as in; am start -a blahblah -n blahblah/.blah ) in order to invoke an activity for a specific application. Unfortunately, apparently the activity can only be called viably from //within// the application.
The app in question is "redditisfun" ( http://github.com/talklittle/reddit-is-fun ). The activity in question is ".InboxActivity". So far, I can get the first bit of code to pull up the app, but the second bit fails out due to lack of permission.
1)
Code:
am start -a android.intent.activity.MAIN -n com.andrewshu.android.redditdonation/.RedditIsFun
2)
Code:
am start -a android.intent.activity.MAIN -n com.andrewshu.android.redditdonation/.InboxActivity
I've tried it with "broadcast" rather than "start" -- that throws no errors, but simply does nothing. (logcat shows no activity that I can see.)
So here's my question; how does one send a system call to an app that is already running, using am? I am afraid that none of the documentation I've yet found says anything at all about this.
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...
Hook is in PhoneWindowManager class, I need to put a value to Settings.System. ContentResolver from the available mContext variable is used.
I get the following:
Code:
InvocationTargetError: java.lang.SecurityException: Package android does not belong to 10036
10036 is UID of my module.
- Which context did you use to get content resolver?
- Depends on where your hook is.
Although your hook is in phone window manager, it still depends from where method you are hooking was called from. If it was called from different package that has different permissions (such as your module app), you will have to clear an identity of calling package while using system settings.
Something like:
Code:
long ident = Binder.clearCallingIdentity();
try {
// store to system settings or whatever
} finally {
Binder.restoreCallingIdentity(ident);
}
- Another option is to add necessary permission to your module's manifest
My module already has WRITE_SETTINGS permission. I use mContext variable that is available in PhoneWindowManager, never had a problem with it. Calling from a separate thread that is created in screenTurnedOff() method.
PhoneWindowManager has a lot of similar code involving Settings.System:
Code:
android.provider.Settings.System.putIntForUser(mContext.getContentResolver(), "screen_brightness_mode", 0, -3);
I tried ...ForUser methods with -2, -3 and 1000 UIDs - still the same error. Regular methods should use current process UID, so it's 1000 anyway.
No idea how it still knows that Xposed module is involved, code is supposed to be executed as if it's a part of a hooked app.
But I guess it knows) so clearing calling identity works perfectly, thanks.
I assume thread in screenTurnedOff you mentioned is your own you created? If yes, then for some reason thread in which runs phone window manager is thinking it's some kind of a foreign thread although created within phone window manager. Question is where screenTurnedOff was called from. If it's an IPC call then it's clear it has different identity. If it's not that case then it's definitely strange.
C3C076 said:
Question is where screenTurnedOff was called from. If it's an IPC call then it's clear it has different identity. If it's not that case then it's definitely strange.
Click to expand...
Click to collapse
screenTurnedOff is a stock method, it's called whenever it's called Definitely not from my module. I bet there is an explanation, something complicated)
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
Have decided to rejoin XDA after a while off to see what sort of response I get to this.
A browse of the forum tells me that there is no known way to unlock fastboot, I was wondering what methods had been explored in an attempt to do this?
More specifically there are 2 potential methods I'd like to ask about.
1: I have seen mentioned in a comment here a tool I stumbled across a few months ago while messing around with another device,
edl/README.md at master · bkerler/edl
Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :) - edl/README.md at master · bkerler/edl
github.com
There is one option in particular that I think is of interest,
edl modules oemunlock enable -> Unlocks OEM if partition "config" exists, fastboot oem unlock is still needed afterwards
2: After a quick browse of the disassembled Oppo deeptesting app I can see a number of references to a class that is only accessible via reflection 'android.engineer.OplusEngineerManager'
and it contains a method 'fastbootUnlock'. Has anyone tried to access this class and its methods at all?
Maybe none of these things will be of any use, but before I spend too much time exploring them, I was interested to hear if anyone else had explored these at all? If so what progress was or wasn't made?
A little update for anyone who is interested:
So I have spent a little bit of time this morning seeing what I can do with the 'OplusEngineerManager' class. I made very simple app to see what access I could get to this class. After adding a library to allow the use of reflection to access non sdk classes I was able to get a list methods from the class, but so far have not been successfully invoke any of them, despite there being no exceptions caught.
User154 said:
A little update for anyone who is interested:
So I have spent a little bit of time this morning seeing what I can do with the 'OplusEngineerManager' class. I made very simple app to see what access I could get to this class. After adding a library to allow the use of reflection to access non sdk classes I was able to get a list methods from the class, but so far have not been successfully invoke any of them, despite there being no exceptions caught.
Click to expand...
Click to collapse
I took a look at the fastbootUnlock method itself (at /system/framework/oplus-framework.jar) and I believe that even if we could invoke it, it wouldn't work because it uses some sort of token (generated be Oppo?). I might be wrong though, I don't have much experience working with decompiled code, and the code I looked at was Realme one (I guess its same as Oppo).
daniml3 said:
I took a look at the fastbootUnlock method itself (at /system/framework/oplus-framework.jar) and I believe that even if we could invoke it, it wouldn't work because it uses some sort of token (generated be Oppo?). I might be wrong though, I don't have much experience working with decompiled code, and the code I looked at was Realme one (I guess its same as Oppo).
Click to expand...
Click to collapse
Its great that someone else is looking at this! I hadn't posted another update as I haven't made a huge amount of progress, and I wasn't sure anybody would be interested.
The fastbootUnlock method returns a boolean and takes 2 parameters, a byte array and an int. From what I can see it is the only method of the OplusEngineerManager class that the deeptesting app calls. It contains 2 calls to the fastbootUnlock method. Once where it calls it with an empty byte array and the int is 1. I was actually able to invoke the method from my test app in this way and got a false return value (rather than just getting null like the other methods I tried to invoke). The second is contained within a method of the deeptesting app that takes a string as its parameter. It then converts this string to a byte array which it passes as the paramter for the fastbootUnlock method along with the int of 1.
Edit:
The second call to fastbootUnlock uses the length of the byte array as the int and not 1. Please forgive me it was late when I wrote this and I was not looking at the source.
Thats about as far as I am with it at the moment, the next task is to find out what that string it passes is exactly, and is it something that needs to be generated by Oppo.
I would imagine the realme framework woukd be similar, if you would like to compare I can provide the full list of methods from the OplusEngineerManager class?
Hey guys, I would be interested in helping you somehow.
I have no prior experience with unlocking a device. (besides actually doing it with the tools provided by anyone else).
But I own an oppo find x3 pro, if you need me to do some testing for you, let me know
Thank you for your reaserch and trying to unlock the fastboot!
xarf903 said:
Hey guys, I would be interested in helping you somehow.
I have no prior experience with unlocking a device. (besides actually doing it with the tools provided by anyone else).
But I own an oppo find x3 pro, if you need me to do some testing for you, let me know
Thank you for your reaserch and trying to unlock the fastboot!
Click to expand...
Click to collapse
Hi, thanks for your reply. At the moment there isn't too nuch to test, but if I do manage to find a way I will need plenty of testers, so thank you
A small update:
I have found that the method in the deep testing app which takes a string and then ends up invoking the reflected fastbootUnlock method is called by a handler associated with one of the app's activities.
The handler gets the string extra from the intent which starts the activity, and then passes that as the parameter when calling the method.
The next problem is that I cannot find anywhere in the deep testing app that starts this activity. I can see as part of, what I believe to be, the normal flow of the deep testing app that an activity in the startup wizard is called, so I wonder if the startup wizard then starts the activity of interest in the deep testing app. This will be the next thing I look into
Edit:
I have looked into this more and it turns out most of this is wrong. The activity is started from within the deeptesting app and not the startup wizard
User154 said:
A small update:
I have found that the method in the deep testing app which takes a string and then ends up invoking the reflected fastbootUnlock method is called by a handler associated with one of the app's activities.
The handler gets the string extra from the intent which starts the activity, and then passes that as the parameter when calling the method.
The next problem is that I cannot find anywhere in the deep testing app that starts this activity. I can see as part of, what I believe to be, the normal flow of the deep testing app that an activity in the startup wizard is called, so I wonder if the startup wizard then starts the activity of interest in the deep testing app. This will be the next thing I look into
Click to expand...
Click to collapse
Great, from my side I tried running the fastbootUnlock method as you did, and got the same result (false). I looked at the logs and there was a selinux denial for finding the engineering service as my app is an untrusted app, so our only way to run the fastbootUnlock method is through the deep testing app I guess.
daniml3 said:
Great, from my side I tried running the fastbootUnlock method as you did, and got the same result (false). I looked at the logs and there was a selinux denial for finding the engineering service as my app is an untrusted app, so our only way to run the fastbootUnlock method is through the deep testing app I guess.
Click to expand...
Click to collapse
Do you mind if I see the logs? I have had no such denial that I can see.
How have you enabled access to hidden apis?
Have you used any of the permissions from the deeptesting app?
User154 said:
Do you mind if I see the logs? I have had no such denial that I can see.
How have you enabled access to hidden apis?
Have you used any of the permissions from the deeptesting app?
Click to expand...
Click to collapse
2022-08-30 14:30:02.115 669-669/? E/SELinux: avc: denied { find } for pid=22831 uid=10866 name=engineer scontext=u:r:untrusted_app_29:s0:c98,c259,c512,c768 tcontext=u:object_r:engineer_service:s0 tclass=service_manager permissive=0
2022-08-30 14:30:02.115 22831-22831/com.danieml.unlockme E/Unlockme: False
There are the logs. I enabled hidden apis, yes, didn't add any extra permissions though. By the way, did you use some specific keys for signing the app (platform keys for example)?
daniml3 said:
2022-08-30 14:30:02.115 669-669/? E/SELinux: avc: denied { find } for pid=22831 uid=10866 name=engineer scontext=u:r:untrusted_app_29:s0:c98,c259,c512,c768 tcontext=u:object_r:engineer_service:s0 tclass=service_manager permissive=0
2022-08-30 14:30:02.115 22831-22831/com.danieml.unlockme E/Unlockme: False
There are the logs. I enabled hidden apis, yes, didn't add any extra permissions though. By the way, did you use some specific keys for signing the app (platform keys for example)?
Click to expand...
Click to collapse
I had a closer look at the logs and I can see that sadly I am getting the same SELinux error.
I can't see much of a way around it at the moment.
I have made a thread in general should anyone wish to discuss this further. Most of this is applicable to all Oppo devices and there are people that have looked at this in different ways and found different things out when trying to unlock fastboot on other devices. I think it would be useful to have somewhere to discuss unlocking fastboot on Oppo devices in general.
[DISCUSSION] A thread to collate and share what is known about unlocking fastboot on Oppo devices
Admin: Please move/delete this thread if it is in the wrong place or against the rules. I wanted to create a thread to discuss unlocking fastboot mode on Oppo devices in general, rather than discussing it in terms of any one device in...
forum.xda-developers.com