ev-flow / ev-flow/DexTrace

DexTrace shows inconsistent Quark rule matching results compared with Androguard

Open
#1 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
4
Forks
3
Avg merge
3d 4h
Merged PRs (30d)
2

Description

## 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:

```text
$ 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

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.