feat: Phase 5 dynamic string resolution via DexTrace

[haeter525]

Add DexTrace-based dynamic string resolution to resolve encrypted strings for Phase 5 keyword matching. The false negative on bianlian APK (80% → 100% confidence) is the motivating case.

⚠️ Merge dependency:
This PR cannot be merged until the following tasks are completed:

• Merge ev-flow/DexTrace#8
• Publish the updated DexTrace to PyPI

How to Test

1. Install DexTrace (development install)

git clone https://github.com/haeter525/DexTrace.git
cd DexTrace
git checkout feat/droidkungfu-stubs
pip install -e .

2. Install quark-engine with this branch

git clone git@github.com:haeter525/quark-engine.git
cd quark-engine
git checkout feat/phase5-dynamic-resolution
pip install -e .

3. Download the sample APK

Download bianlian.zip (Password: infected) and extract bianlian.apk.

4. Save the detection rule

Save the following as auto_click_comfirm_button_on_dialog.json:

{
    "crime": "Auto click button on system dialog",
    "permission": [],
    "api": [
        {
            "class": "Landroid/view/accessibility/AccessibilityNodeInfo;",
            "method": "findAccessibilityNodeInfosByText",
            "descriptor": "(Ljava/lang/String;)Ljava/util/List;",
            "match_keywords": [
                "android:id/button1"
            ]
        },
        {
            "class": "Landroid/view/accessibility/AccessibilityNodeInfo;",
            "method": "performAction",
            "descriptor": "(I)Z"
        }
    ],
    "score": 10,
    "label": ["sms", "calllog", "collection"]
}

5. Run — compare static vs dynamic

The sample first calls the method dilemmaexact() to compute a string, then takes it as the 2nd argument to call the findButtonAndClick method:

The method then calls the first API findAccessibilityNodeInfosByText with this string to locate a button on the system dialog:

Quark Analysis Without --dynamic-resolve (static only)

quark -a bianlian.apk -s auto_click_comfirm_button_on_dialog.json

Since the string is dynamically computed, the Quark rule above cannot fully detect this behavior, resulting in an 80% confidence score.

Quark Analysis With --dynamic-resolve

quark -a bianlian.apk -s auto_click_comfirm_button_on_dialog.json --dynamic-resolve

With the dynamic string resolution feature, Quark successfully resolves the string from the dilemmaexact() method and identifies the target behavior with 100% confidence.

[codecov]

Codecov Report

❌ Patch coverage is 80.82192% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.40%. Comparing base (9fb4362) to head (5f8b8d8).
⚠️ Report is 19 commits behind head on master.

Files with missing lines	Patch %	Lines
quark/core/quark.py	83.09%	12 Missing ⚠️
quark/cli.py	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #919      +/-   ##
==========================================
+ Coverage   81.31%   81.40%   +0.09%     
==========================================
  Files          80       80              
  Lines        6946     6969      +23     
==========================================
+ Hits         5648     5673      +25     
+ Misses       1298     1296       -2     

Flag	Coverage Δ
unittests	81.40% <80.82%> (+0.09%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pulorsok]

--dynamic-resolve is silently ignored in parallel mode (--num-of-process > 1)

In quark/cli.py, only the serial Quark(...) branches forward the flag (lines 252, 309). The two ParallelQuark(...) call sites (lines 250, 307) don't pass it.

And it wouldn't help if they did: ParallelQuark.__init__ (parallelquark.py:115) neither accepts nor forwards dynamic_resolve — its super().__init__(apk, core_library) (line 122) leaves it at the default False. More importantly, Phase 5 actually runs in the worker processes, whose Quark is built in _worker_initializer (lines 16–18) as Quark(apk, core_library, auto_fix_checksum) — again without dynamic_resolve.

Net effect: quark -a app.apk -s rule.json --dynamic-resolve --num-of-process 2 performs no dynamic resolution and emits no warning — it behaves exactly like omitting the flag. The serial path (--num-of-process <= 1) is wired correctly.

Suggestion: thread dynamic_resolve through ParallelQuark.__init__, the Pool initargs, and _worker_initializer so workers are built with it enabled — or, at minimum, emit a warning when the flag is dropped in parallel mode.