How to test the root detection?
First of all, we need to be clear what would be the goal of the root detection. When it comes to anti-reversing, the goal would definitely be to make it more difficult to run such an app which is on the rooted device. It also turns on some tools and the techniques which reverse engineers like to use most of the times. Also, I would like to tell you that like with most other defenses, the root detection is also not highly effective on its own. What does that mean? It means that you also need to have some root checks which are basically sprinkled through the application and they will be able to improve the effectiveness of the whole anti-tampering scheme.
I would like to see few more words here for your better understanding. When it comes to Android, the root detection term is actually defined more broadly. It also includes the detection of some custom ROMs and also verifies if the device is a stock Android build version or a custom one.
What are the common root detection methods?
I will now introduce you to some common methods which are used for this purpose. First of all, we will talk about the SafetyNet. It is actually the Android’s API which creates a profile of the device. For such a purpose, it uses a software and the hardware information. After that is completed, a profile is compared against a list of the white-listed device models. Those models have passed the Android’s compatibility test.
Let’s say that you have called the API, and what can you expect to happen then? After you have done it, the service will download a binary package. Such a package will contain the device validation code which comes from the Google. It is basically dynamically executed by using the reflection. Besides that, it is shown that those checks which are performed by SafetyNet can also be able to attempt the detecting whether the device itself is rooted. It doesn’t matter how unclear exactly this process is determined.
Also, I would like to inform you that the file existence checks are the category of the method which is widely used with a purpose to check the files that are typically found on the rooted device. For example, it may be such a package file of some rooting apps which are common and also the associated files and the directories.
Besides that, the detection code itself looks for the binaries which are usually installed. It happens once the device is rooted. Also, when you want to have the file checks, they can be easily achieved in Java and the native code.
How to check the writable partitions and also the system directories?
There are some unusual permissions which exist in the system directories. Those can indicate a customized or a rooted device. If the circumstances are normal, it is expected that the system and also the data categories are mounted at all times as read-only. You may also find them as a read-write. In that case, the device is rooted. How can you test this? Easily, by checking whether those filesystems actually are mounted with the ‘rw’ flag. Also, there is another option, which is to create some files in those categories.
Also, I would like to recommend that it is useful to check for some signs (if there are any) of the test builds and also the custom ROMs.
We will now talk about the bypassing the root detection. When you are running the execution traces by using JDB, DDMS or some Kernel modules with a purpose to find out what the application is actually doing, most of the times you will see all of the kinds of the suspected interactions that happen with the operating system. For example, it can be an opened su which is foreseen for the reading or even obtaining some list of the processes.
Those are actually the interactions which are the surefire for some rooting detection. All you need to do here is to identify and also to deactivate all of the root detections mechanisms and all that one-by-one. Also, you need to remember that if you are trying to perform the black-box resilience assessment, this should be your first step.
How to test the anti-debugging?
I am sure that you have already know how the debugging is really a high-effective way when you want to analyze some runtime behaviors of the application. What it actually does is that it allows the reverse engineering and all that to the step through the code. Also, it stops the execution of the app at some arbitrary point if they arrive. The third thing it does and that will be of benefit to you is that it actually inspects the state of the variables. That also means that it reads the modifying memory and a lot more.
We will now show you how can the presence of the anti-debugging mechanisms be applied. You need to follow the criteria we will show you:
-you need to attach the JDB and also the ptrace which are based debuggers. If you don’t do that, your action will fail.
-there are the multiple detection methods which are scattered throughout the application.
-there are the anti-debugging defenses which can operate on the multiple API layers, such as Java, Assembler, some native library functions and more.
-understand that the mechanisms themselves show more levels of functionality.
The availability of the source code
We will talk about the static analysis here. Let’s say the source code is available, but how will you know it? It would be for the best of you to show it in the example.
If there is a presence of the unique identifier that no longer works in the future, it will be shown this way:
-Build.SERIAL without the Build.getSerial();
-htc.camera.sensor.front_SN (this is for the HTC devices);
-persist.service.bdroid.dbadd;
-Settings.Secure.bluetooth_address.
So, all in all, the goal of the device binding would definitely be to impede the attacker once he/she tries to copy some app and also its state from the device A to the device B. If the attacker does that successfully, then it is able to continue the execution of the app which is placed on the device B.
I hope that you have learned a lot of new things today with us!