an example of mobile phone "rogue software" cleaning

Posted by barello at 2020-03-22

Since I called the phone and asked the firewings to give me the human flesh root, I felt very happy and tested. One day bored, decided to install a tcpdump grab bag.

Use the ADB toolkit provided by Google to connect to the mobile phone, transfer the tcpdump under Android to the SD card, and then you can execute the packet grabbing (if you can't, of course, Baidu can solve it):

After capturing the package, pull the pcap file back to view the content, which can't help but be shocked. See the figure:

The mobile phone will send a request to a domain name regularly, especially with an encrypted TK string, which is suspicious, and the target domain name is also very suspicious (xxsvr. Com). Whois is a mobile software company that hasn't heard of domain names. In addition, its domain root directory and root domain name have nothing. I took a breath of air-conditioner and thought of a "species": grey pigeon!

Basically, it's a mobile phone problem, so we need to check the spy location. First, we need to see whether it's rootkit or application level Trojan horse. End the applications one by one and grab the packages one by one. It is found that there is no "heartbeat package" after the end of an app. It seems to be application level (that's a small thing, a little accident is still under my control), and it's bound in an app.

Throw the app's installation file into the Android sandbox (address:, and you can see that it actually visited the domain name of and some inexplicable domain names.

At the same time, app also has some permissions that have nothing to do with its application functions, such as read SMS, receive SMS, write SMS, send SMS, read contacts, write contacts, read browser history / bookmarks, access fine location and so on, which are very suspicious.

Well, now that it's reached this point, I have to look at its code.

Applications on Android are written in Java, and decompilation is easy. The APK file is actually a zip package. First, change the suffix and use winrar and other tools to decompress it. The key files are Android manifest.xml and classes.dex.

Android manifest.xml is a file for Android applications to declare permissions and components. It is binary and needs to be decompiled with a tool called axmlprinter2. I wrote a simple script and only put forward the permission:

Classes.dex is the binary of Java code after compilation. It can be directly converted into jar format with dex2jar, and then viewed with Java decompiler such as JD GUI.

Carefully search the code of the suspicious domain name, and find that the suspicious string is the encrypted mobile Mac, IMSI and other information. Look at the source code:

There's a lot of other code. It's a headache, so I won't continue to analyze it. Since this app is so suspicious, whether it's rogue software or not, uninstall it directly.

Finally, I'd like to say a few more words. Now mobile app is more popular, and the industry is very worried about privacy disclosure. But some app developers don't have this awareness. They apply for some unnecessary permissions in the app and read and transfer some data that is easy to cause controversy. This brings fear to users. Of course, users are afraid of privacy disclosure, but they can't trust you, "no doubt about people", and the final result is to uninstall your app.

Therefore, enterprises with mobile app products, especially large-scale Internet enterprises, should pay attention to this problem. They should establish their own mobile app security specifications, standards, processes and systems, and solve this kind of problem before the app is released, so as to avoid the problems of privacy to users and to themselves.