There was another incident during a hunt... Or why Appdome is sometimes such a Dome

This article is original, not copy-paste or machine translation. When copying, please cite. Illustrations are original and are intellectual property @themegaera. Thanks to her for finding time in her busy study schedule.

Preface.

Analyzing applications for purely educational purposes is a very creative thing. 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, then you understand what real pleasure is.
Now, already in my third year of work in this area, a certain overall picture is emerging. And I will say this – the defense-attack competition in the world of Android applications is always a duel. Moreover, opponents here can use all their imagination practically without restrictions. Yes, the set of means may be limited, but their combinations are endless.
Sometimes it happens like during an exam – you prepare for something difficult, write cheat sheets, but everything turns out easy and simple. Here is one such case.

Initial data. Extraction.

An application of a very large company, in terms of the money flows passing through it. The essence of the application is to ensure user verification when performing important actions with their account. The main application runs 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 am not describing all the details, but this is the main point.
The application is protected and does not work on the emulator, on devices with root, and in general, if there is any deviation, it displays a message about the presence of a threat and closes.
The purpose of the study is to find out the possibility of automatic application launch and verification with pre-set parameters.

Initial data. Protection.

As usual, what we have at the beginning of the path is an apk file obtained either from resources like apkmirroror directly pulled from the phone via adb and assembled from parts into one. Now unsplit apk are a big rarity.
The first thing I usually use for analysis is the utility apkid. A very useful tool. It is practically a magic ball-predictor. Allows to get a general idea of what awaits the researcher in the future without opening it.
In this case, I was told that Appdome was ahead of me.

If anyone doesn't know, then AppDome – is another type of “unparalleled” mobile application protection system. Including applications for Android OS, which was initially created by Google Corporation in such a way as to make this protection as difficult as possible.
In essence, Appdome makes a lot of money by offering software developers an amulet that, if applied to a product, can protect that product from various forms of evil spirits. At the same time, a separate text states that no changes are made to the source product code. In short, a Miracle of Miracles. But for some reason, the developer must transfer his Keystore 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 for any person, believe.
Marketing aside, Appdome is another attempt to create a comprehensive application protection based on all available global experience. The same as Dexprotector, which I wrote about earlier, only – a side view.
It is obvious that the consumer has the right to expect the fulfillment of his expectations from a product in which a lot of money has been invested. But is this always the case?
On the Appdome website, the Customer can choose which types of threats he wants to protect his application from. 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 boxes in accordance with his budget.

Here is a rough list of threats that Appdome promises to catch:

integrity of application files. Checksums of dex files and libraries are compared with values from the database.
checking for root on phone
check for emulator
check for connection using adb
check if the “developer” option is enabled in the phone settings
check for Exposed
check on Frida

Application protection methods:

library encryption
string encoding
Encrypting 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 core of Appdome's defense mechanism is a library libloader.so. Below is the basic algorithm of the operation of the studied application, which has Appdome protection:

In words, it works like this: When the application (Application class) is initialized, the library is loaded libloader.so (that is, the source code is already changing)) ). This library hooks up the database that 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 immediate Segmentation Fault occurs (exit() in the diagram) and the application closes.
If everything is fine with the CRC, then libloader.so starts checking the threats that the Customer purchased (their list 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, in general, the getAndSendInfo() method). Appdome no longer interferes with the operation of the application until a threat appears. For this purpose, the Service and Broadcat Receiver are initialized in the application, which respectively send and receive notifications if, for example, you 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 is launched) libloader kills the application process.

So 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 it this way:

We'll just run the business logic ourselves. Without waiting for a verdict from Appdome. We'll run it right from the onCreate method of our MainActivity. At the end of the onCreate method, we'll call the getAndSendInfo() method. What's stopping us from doing this? Nothing is stopping us.
And, oops! – verification is complete.

Debriefing.

How is that possible?
And the point, as you already understood, is time. Time, damn it!
The time after which Appdome will kill the process is approximately 10 seconds from the launch of the application. And the time during which the application collects and sends data with a normally operating network is 5 seconds.
And the fact that the application will close on the 10th second is even good – we don't need to close it. Let Appdome work for us.
In general, when I did this, I had a strange feeling of bifurcation of algorithms – it turns out that in this case the application works separately from the protection, and the protection – separately from the application. As 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 adb sees it, but does not have time to do anything.
You need to substitute your parameters in the verification request. Well, now we have root rights on the phone. We save the json file with the necessary parameters on the phone, and in the application when launched we read these parameters and substitute them in the request. Appdome sees root, but again can't do anything.

Conclusion.

It is clear that the process of analyzing the protection of the target application, described in the article, is greatly simplified by me. In fact, it took about three days from receiving the technical task.
But the point of this article is not to break down this process step by step, but to show how labor-intensive the task can look, and how comparatively easy it is sometimes to solve in reality.

The essence of the article is to tell novice analysts, and indeed everyone who faces a seemingly unsolvable task: Do not trust your eyes – “the eyes are afraid, but the hands are doing” – Folk wisdom. And the People, especially in Rus', have always been and are savvy. Boldly take on the most difficult tasks, without looking back at the loud names of companies.

The larger the company, the more chaos there is. Developers, testers, and information security specialists in large companies sit on salaries and gradually relax and start to be lazy and slack off. And sometimes an illiterate “effective” manager just goes and buys protection, not knowing at all how to use it correctly. Even I have come across quite a few such products in such a short period of time.
As for Appdome – I'm tired of justifying these companies to myself. Like, they make a good product, it's just that users don't use it well. No. It's not like that.
It's just that some manager at Appdome decided that in order for the Customer to see that Appdome is working, it is absolutely necessary to display a message on the screen describing the threat found. And the developer who was given the task to implement this simply set a time delay for this message.
Well, tell me – why does the user need to know what kind of threat caused the application to stop? As an analyst, this might really be interesting to me. But for the Customer, it is generally more important that the application simply does not start.

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