DexTrace shows inconsistent Quark rule matching results compared with Androguard

[sidra-asa]

Summary

When Quark Engine analyzes 13667fe3b0ad496a0cd157f34b7e0c991d72a4db.apk with DexTrace core, it produces inconsistent results compared with Androguard for several rules.

The affected rules are:

• 00083 – Query the IMEI number
• 00092 – Send broadcast
• 00223 – Access ContentResolver

Result difference

Using the same APK and the same Quark rules, the following differences were observed:

$ diff out_androguard.txt out_dextrace.txt
98c98
< | 00083.json | Query the IMEI number                                                           | 60%        | -2.4  | -0.6      |
---
> | 00083.json | Query the IMEI number                                                           | 40%        | -2.4  | -0.3      |
107c107
< | 00092.json | Send broadcast                                                                  | 40%        | -1.95 | -0.24375  |
---
> | 00092.json | Send broadcast                                                                  | 20%        | -1.95 | -0.121875 |
238c238
< | 00223.json | Access ContentResolver                                                          | 60%        | -0.51 | -0.1275   |
---
> | 00223.json | Access ContentResolver                                                          | 40%        | -0.51 | -0.06375  |

For all three rules, DexTrace reports 20% lower confidence than Androguard.

Affected API pairs

These rules define the following Android framework API pairs:

• 00083

  • Landroid/app/Activity;->getSystemService(Ljava/lang/String;)Ljava/lang/Object;
  • Landroid/telephony/TelephonyManager;->getDeviceId()Ljava/lang/String;

• 00092

  • Landroid/app/Activity;->getApplicationContext()Landroid/content/Context;
  • Landroid/content/Context;->sendBroadcast(Landroid/content/Intent;)V

• 00223

  • Landroid/app/Activity;->getApplicationContext()Landroid/content/Context;
  • Landroid/content/Context;->getContentResolver()Landroid/content/ContentResolver;

Observation

This does not appear to be a general failure for all Landroid/app/Activity;-related rules, because some other Activity-related rules can still be matched correctly.

The issue is more likely related to inconsistent matching or resolution of specific Android framework API pairs in DexTrace, rather than a problem in the rule definitions themselves.

Possible causes

Possible causes may include:

• incomplete Android framework method matching
• inconsistent API resolution / normalization for specific framework calls
• gaps in invoke target extraction for certain class/method/descriptor combinations

Suggested next steps

• compare the matched APIs between Androguard and DexTrace for these three rules
• inspect how DexTrace resolves the affected framework methods