Bug: Application Crash When Enabling Packet Captures Using Downloads Folder

[X8ETr1x]

Description

When enabling packet captures in Settings > Packet capture > Output to the Downloads folder, Rethink crashes. When restarting the application, the Rethink folder within the Download folder may have pcap files, but they will all have zero bytes.

Steps to Reproduce

1. Disable packet capturing or set to logcat.
2. Set packet capturing back to "Output to the Downloads folder" and the app will crash.

Expected behavior

The application will output packet captures of application traffic to the Rethink folder in the Download folder.

Actual behavior

The application crashes and creates empty pcap files.

Application

• Version: v0.5.5n
• Storage Scope: Device > Download > Rethink
• Permissions: Network
• Battery Usage: Unrestricted
• Hardened Memory Allocator: Enabled
• Memory Tagging: Enabled
• Extended Virtual Address Space: Enabled
• Native Code Debugging: Blocked
• WebView JIT: Disabled
• Dynamic Code Loading via Memory: Restricted
• Dynamic Code Loading via Storage: Allowed

Device Information

• Device: Google Pixel 9 Pro XL
• Operating System: GrapheneOS (Android 15) build 2025011500

Log

type: crash
flags: dev options enabled
package: com.celzero.bravedns:45, targetSdk 34
process: com.celzero.bravedns
installer: com.android.packageinstaller

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/komodo/komodo:15/AP4A.250105.002/2025011500:user/release-keys'
Revision: 'MP1.0'
ABI: 'arm64'
Timestamp: 2025-01-19 14:10:26.995445694-0600
Process uptime: 11s
Cmdline: com.celzero.bravedns
pid: 16179, tid: 16234, name: DefaultDispatch  >>> com.celzero.bravedns <<<
uid: 10166
tagged_addr_ctrl: 000000000007fff7 (PR_TAGGED_ADDR_ENABLE, PR_MTE_TCF_SYNC, PR_MTE_TCF_ASYNC, mask 0xfffe)
pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
    x0  0000000000000000  x1  0000000000003f6a  x2  0000000000000006  x3  0000000000000008
    x4  0000000000000001  x5  0000d04ff1b20f28  x6  0000000000000000  x7  0000000000000000
    x8  0000000000000083  x9  000000000000c888  x10 000000000000000e  x11 0000d0505153e408
    x12 0000000000000005  x13 000000007fffffff  x14 00000000039666e2  x15 00000513e2b30216
    x16 0000d04ff132a450  x17 0000d04ff1b20bb0  x18 0000d04feea28000  x19 0000000000003f33
    x20 0000d04ff1b20a50  x21 0000004000099808  x22 0000000000000001  x23 0000000000000000
    x24 0000000000000000  x25 0000d050c02f6190  x26 0000000000000000  x27 0000000000000010
    x28 0000004008180700  x29 00000040003b3ac8
    lr  0000d05050e8dd14  sp  00000040003b3ad0  pc  0000d05050eacba8  pst 0000000080001000

1 total frames
backtrace:
      #00 pc 0000000000306ba8  /data/app/~~6n2d27URO0rsAlgu7ndRCQ==/com.celzero.bravedns-9WkWN8HBXWCGq0YB0KcYSQ==/base.apk (offset 0x344000)

Full dump output attached.

c30d06186c9e.txt

Additional Context

I do see Rethink opening the file in the full output each time:

 fd 121: /storage/emulated/0/Download/Rethink/rethink_pcap_250119141026.pcap (unowned)

I'm unsure if this is related to the app sandboxing in GrapheneOS, but it is somewhat odd.

[ignoramous]

Related PR_TAGGED_ADDR_ENABLE: #962

Memory Tagging: Enabled

Disabling this might get you over the line.

[X8ETr1x]

Related PR_TAGGED_ADDR_ENABLE: #962

Memory Tagging: Enabled

Disabling this might get you over the line.

Perhaps as a temporary workaround for those willing to accept the risk, but IMO decreasing device security and exploit protection is not a permanent solution even on a per-app basis.

[ignoramous]

IMO decreasing device security and exploit protection

True, but from what I read, MTEs (as implemented) are a good mitigation not prevention (source).

Either way, we'll see what's up but I should warn you that we're literally shooting in the dark here with backtraces like this (which is thanks to the way golang's stack unwinder works on Android):

1 total frames
backtrace:
      #00 pc 0000000000306ba8  /data/app/~~6n2d27URO0rsAlgu7ndRCQ==/com.celzero.bravedns-9WkWN8HBXWCGq0YB0KcYSQ==/base.apk (offset 0x344000)

[X8ETr1x]

IMO decreasing device security and exploit protection

True, but from what I read, MTEs (as implemented) are a good mitigation not prevention (source).

Either way, we'll see what's up but I should warn you that we're literally shooting in the dark here with backtraces like this (which is thanks to the way golang's stack unwinder works on Android):

1 total frames
backtrace:
      #00 pc 0000000000306ba8  /data/app/~~6n2d27URO0rsAlgu7ndRCQ==/com.celzero.bravedns-9WkWN8HBXWCGq0YB0KcYSQ==/base.apk (offset 0x344000)

I'm happy to test and prod at the device to get additional information if there's anything else I can provide. Please let me know.