Introducing Wasmcov: Code Coverage Tool for Wasm Projects
We’re proud to introduce Wasmcov, a specialized code coverage tool tailored for Wasm environments.
In the last article, we reviewed OWASP Mobile TOP 10 Methodology for Testing Mobile Apps; that time we could not provide a proper case for demonstrating the need for protecting the source code. Only recently an interesting case appeared and now we are ready to share our experience of the diversion of the status checks of the implementation environment.
Case Description
While assessing the work of one of the projects, our team immediately realized that the case won’t be easy. The developers approached the issue of information protection in the program in a better way and implemented the runtime status checks. The application was not started under any of the following conditions:
- the device was rooted;
- an emulator was used;
- a presence of connection through USB;
- use the developer mode.
The developers didn’t fool the source code and the code modification check was not built in, which allowed us to analyze the ways in which the checks were performed and carry out the necessary manipulations with them.
Tools and Methodologies
According to OWASP Mobile TOP 10, which we use as the basic test methodology at Hacken, the analysis of the source code (Reverse Engineering) — the procedure involves the analysis of binary files to determine the source code, libraries, algorithms, etc. Software such as IDA Pro, Hopper, otool, and other reverse engineering tools can give an idea of the internal operation of the application. This can be used to find the vulnerabilities in the application, extract critical information, such as the backend server, encryption keys, or intellectual property.
Process of Testing
To conduct a basic static analysis, we used an interesting tool, such as MobSF, which performed decompilation and a basic static analysis. After a decompilation we were interested in java- and smali-codes of the program. Java-code is needed for analysis and will make changes in the smali-code.
After looking through the list of classes, we found a file that is responsible for checking the phone’s handling (see Picture 1) – rootingcheck / RootBeerNative.java.
After analyzing the class, it becomes clear that you need to look for calls to the functions checkForRoot () and setLogDebugMessage () (see Picture 2).
Using the grep command, we get the following results, which show us in which files there is a call for CheckForRoot () and setLogDebugMessage () methods.
The checks didn’t stop here. After analyzing the MainActivity.java class, function calls were found, where the lines “su”, “test-keys” and “which” are transmitted with a help of which the check is conducted (see Picture 3).
Again, with the grep command, we look for the root checks in the small files:
Search Results:
In the article, we will show only one of the found modifications of the checks of rootility. After a little manipulation, namely the change of 1 to 0, checks for rootility are removed.
After it, the program can be collected, signed with your own release key and run on your mobile phone. However, there are two ‘BUTs’!
- checking the connection to USB.
- Verification of inclusion of Developer mode — connection to USB and enabled Developer mode allow a dynamic analysis.
Verification Developer mode is turned off in the same way as checking the rootility — a change in the checks unit to zero.In the MainActivity.java class, we should find the line that is responsible for checking Developer mode (see Figure 6). After that, we look for grep files in which the “development_settings_enabled” line is present and modify the check-change from 1 to 0 (see Pictures 7 and 8).
After all the manipulations, you can run the program in Developer mode.
The next step is to deactivate the USB connection test. This check is in the class MainActivity.java (see Picture 9). Without using grep, we find the line in MainActivity.smali, discover the line that contains the string with the USB test — android.hardware.usb.action.USB_STATE. After that, in the smali-code, modify the line for any other permissions, which returns “false” (see Picture 10).
Now it’s time to generate your own release key and sign the application. This is done as follows:
Basically, all the manipulations are over. Now install the application on the phone using adb install or from the smartphone directory, and you can conduct a dynamic testing on the vulnerability.
After installing the application, start it (see Picture 11 and Picture 12).
Summing Up
In this article, we showed how you can turn off some checks on the state of the runtime on a practical example. Further on, with the help of other tools, we conducted a vulnerability analysis, but this is another story …
A careless attitude to code protection can lead to the implementation of third-party code, after which the program can be published and used as malicious one.
P.S.You can use a more advanced method of analysis — it’s smali debugging.
A bit for reference, I’ve formulated a list of lines that are used to check for rootility:
How to defend oneself?
At Hacken, we decided not to reinvent the wheel and invited the client to obfuscate the source code and use the functions that check the modification of the source code. We take security extremely seriously: contact us and you’ll see!
