Android system scanning method with advertisement Application

There are many apps that use ad detection, AD detection, AD scanning, AD killer, and Ad plug-in killer on android, But what principles have they used? Today, we will conduct an in-depth analysis. After decompiling an apk package with an advertisement, the following features will be generated: 1. manifest. the xml file contains the declaration of each activity, which contains the window of the advertisement plug-in; 2. the ad plug-in is a separate jar package. In obfuscation, proguard. in the cfg file, the public classes and methods must be processed with keep. Therefore, the package name corresponding to the ad plug-in can still be found in the decompiled package. In response to the above signs, the current application with the ad detection function is tested: 1. Package the APK to be scanned into the ad plug-in to scan the "ad scanning tool. 2. Declare the activities used by some advertising platforms in manifest. xml. The scanning results of LBE and 360 on ad plug-ins are not the same, and the number of LBE scans is relatively large. The test results are as follows: method 1 can be scanned. Method 2 cannot be scanned. Therefore, we also intend to use the package name and class name matching method for AD plug-in scanning. The specific ad plug-in scan solution is: (1) list all apk installed by the system; (2) list all the classes used by each apk; (3) A single class matches the feature library of the AD plug-in. On the android system (1) obtain the code of all installed packages: PackageManager packagemgr = getPackageManager (); List <PackageInfo> packageList = packagemgr. getInstalledPackages (0); count = packageList. size (); for (int I = 0; I <count; I ++) {PackageInfo pi = packageList. get (I); if (pi. versionName = null) continue; // determine whether the software package is in the/data/app directory File file = new File ("/Data/app/" + pi. packageName + ". apk"); if (! File. exists () systemInstalledApk ++; userInstalledApk ++;/*** Application name */applicationName = pi. applicationInfo. loadLabel (packagemgr ). toString (); packageName = pi. packageName;} (2) obtain all classes in a single package: try {path = context. getPackageManager (). getApplicationInfo (packageName, 0 ). sourceDir; // obtain the APK path of a program} catch (NameNotFoundException e) {e. printStackTrace ();} try {DexFile dexFile = new DexFile (path); // ge T dex file of APKEnumeration <String> entries = dexFile. entries (); while (entries. hasMoreElements () {// travel all classesString className = (String) entries. nextElement () ;}} catch (IOException e) {e. printStackTrace ();} on the PC side: It is easy or not easy to implement the above two points. If you have your own program, you can consider parsing the class. dex file. This involves understanding the dex file format and then reading the class content of the response. If the parser is an automation tool, you can use the dexdump.exe program to parse the class. dex file. The rest of the work can be done by C applications, MFC, Java, shell scripts, and so on. The remaining problem is the collection of AD plug-in feature libraries. The more comprehensive the collection, the more accurate the scanned ad plug-ins can be. For more information about the principles and handling methods of android ad scanning, see the relevant blog. Thank you!