Another case on the hunt... Or why Appdome is sometimes such a Dome

Preface.

Analyzing applications solely for educational purposes is a very creative endeavor. And, although 90% of the time is spent on routine work, the remaining 10% is probably what makes people place bets or play roulette - excitement and endless faith in luck. It doesn't always work - yes. But if it does, you understand what real pleasure is.
Now, in the third year of my work in this field, a certain overall picture is emerging. And I will say this - the defense-offense competition in the world of Android applications is always a duel. Moreover, opponents here can use all their imagination almost without restrictions. Yes, the set of tools may be limited, but their combinations are endless.
Sometimes it happens like in an exam - you prepare for something difficult, write cheat sheets, and everything turns out to be easy and simple. Here's one such case.

Initial data. Extraction.

The application of a very large company in terms of the flow of money passing through it. The essence of the application is to ensure user verification when performing important actions with their account. The main application works on the desktop in the browser. But when it is necessary to perform an important operation, a verification request appears in the browser. The user must open the application on the phone, after which the application will collect a certain set of data and send it to the server. The server will decide whether this is a real user or not. If not, the transaction will not go through. I do not describe all the details, but the main idea is this.
The application is protected and does not work on an emulator, on devices with root, and in general, in any deviation, it gives a threat message and closes.
The purpose of the study is to find out the possibility of automatically launching the application and verification with predefined parameters.

Initial data. Protection.

As usual, what we have at the beginning of the journey is an apk file obtained either from resources like apkmirror, or directly extracted from the phone via adb and assembled from parts into one. Now undivided apks are a rarity.
The first thing I usually use for analysis is the apkid utility. A very useful tool. Practically a magic crystal ball. Allows you to get a general idea of what awaits the researcher in the future without opening it.
In this case, I was predicted that Appdome awaits me ahead.

If anyone is not aware, Appdome is another type of "unparalleled" mobile application protection system. Including applications for the Android OS, which was originally created by Google Corporation to make this very protection as complicated as possible.
In essence, Appdome makes huge money by offering software developers such an amulet, which, if applied to the product, can protect this product from various forms of evil. At the same time, it is stated separately that no changes are made to the source code of the original product. In general - a Miracle of Miracles. But at the same time, the developer, for some reason, must transfer their Keystore storage with passwords to the keys to Appdome.
In general - shamanism of the 80th level. But, judging by the financial results of Appdome's activities, many, as is typical of any person, believe.
If you move away from marketing, Appdome is another attempt to create comprehensive application protection based on all the available world experience. The same as Dexprotector, which I wrote about earlier, only - a side view.
It is obvious that from a product in which a lot of money has been invested, the consumer has the right to expect their expectations to be met. But is it always the case?
On the Appdome website, the customer can choose from which types of threats they want to protect their application. In accordance with the rules of modern marketing, all threats are divided into components, protection from each of which is sold separately. Thus, the customer can tick the boxes according to their budget.

Here is an approximate list of threats that Appdome promises to catch:

• application file integrity. Checksums of dex files and libraries are compared with values from the database.

• check for root on the phone

• check for emulator

• check for connection using adb

• check for enabling the "developer options" in the phone settings

• check for Exposed

• check for Frida

Application protection methods:

• library encryption

• string encoding

• encryption of Shared Preferences content

All information about the threats selected by the Customer is placed in the SQLite database and, of course, is also encrypted.
The basis of the Appdome protection mechanism is the libloader.so library. Below is the basic algorithm of the protected application:

If in words, it works like this: When the application (Application class) is initialized, the libloader.so library is loaded (that is, the source code is already being changed)). This library connects to the database, which stores all the information related to Appdome. After that, libloader.so checks itself for integrity by comparing the checksum from the database with the checksum of the file itself. If they do not match, an instant Segmentation Fault occurs (in the diagram - exit()) and the application closes.
If the CRC is fine, then libloader.so starts checking the threats that the Customer bought (the list of them is in the database). At the end of the checks, a certain verdict is formed. If no threats are detected, the standard algorithm of the main business logic of the application is launched (in our case, generally - the getAndSendInfo() method). Appdome no longer interferes with the operation of the application until a threat appears. For this purpose, Service and Broadcat Receiver are initialized in the application, which respectively send and receive notifications if you, for example, enable debugging while the application is running. If threats are detected, libloader sends a description of the threat to the integrated Event Tracker Mixpanel and shows a Toast with a threat message. After that (about 10 seconds after the application starts), libloader kills the application process.

And what to do with all this?

There are many options, and each of them leads to the goal. The only difference is in time and tools.
TIME!!!
Here it is - The solution in this particular case.
Let's do this:

We will just run the business logic ourselves. Without waiting for a verdict from Appdome. Directly from the onCreate method of our MainActivity and run it. At the end of the onCreate method, we will call the getAndSendInfo() method. And what prevents us from doing this? Nothing prevents.
And, voila! - verification passed.

Analysis.

How come?
And the essence, as you already understood, is in time. Time, damn it!
The time after which Appdome will kill the process is about 10 seconds from the start of the application. And the time it takes for the application to collect and send data with a normally functioning network is 5 seconds.
And the fact that the application will close on the 10th second is even good - we do not need to close it. Let Appdome work for us.
In general, when I did this, I had a strange feeling of algorithm splitting - it turns out that in this case the application works separately from the protection, and the protection works separately from the application. Like in parallel worlds - one does not affect the other.

Tasks completed:

• It was necessary to automate the launch of the application. We launch it from the desktop via adb. Appdome sees adb, but does not have time to do anything.

• It is necessary to substitute your parameters in the verification request. So now we have root rights on the phone. We save the json file with the necessary parameters on the phone, and in the application at startup we read these parameters and substitute them in the request. Appdome sees root, but again cannot do anything.

Conclusion.

It is clear that the process of analyzing the protection of the target application, as described in the article, has been greatly simplified by me. In fact, it took about three days from receiving the technical assignment.
But the essence of the article is not to break down this process step by step, but to show how laborious the task may seem, and how relatively easy it is sometimes actually solved.

The essence of the article is to tell novice analysts, and indeed everyone who faces an unsolvable, at first glance, task: Do not believe your eyes - "the eyes are afraid, but the hands are doing" - Folk wisdom. And the People, especially in Russia, have always been and are always resourceful. Boldly take on the most difficult tasks, without looking back at the loud names of companies.

The larger the company, the more mess there is. Both developers, testers, and information security specialists in large companies sit on salaries and gradually relax and start to get lazy and slack off. And sometimes an illiterate "efficient" manager just takes and buys protection, without knowing how to apply it correctly. Even I have come across quite a few such products in such a short period of time.
As for Appdome - I am tired of justifying these companies to myself. They say they make a good product, it's just that users apply it poorly. No. It's not like that.
Just some manager at Appdome decided that in order for the Customer to see that Appdome is working, it is necessary to display a message on the screen with a description of the detected threat. And the developer, who was given the task to implement this, simply laid a time delay for this message.
Well, tell me - why does the user need to know what exactly the threat was that led to the application stopping? As an analyst, this might really be interesting to me. But for the Customer, it is more important that the application simply does not start.

By the way, take the same Dexprotector - there the application just closes without any messages. Apparently, their decision was made by a techie, not a marketer.
Techie for President! )))

Illustrations are original and are the intellectual property of @themegaera.