Question on permissions

[IzzySoft]

Nice to see the update, Konrad! While it rolled in, it triggered a report at our scanners at IzzyOnDroid, maybe you can help us with clarification here so we can put the points on the app's "green list" with the proper explanation:

! repo/net.kollnig.missioncontrol_2024121502.apk declares intent-filter(s): android.net.VpnService
! repo/net.kollnig.missioncontrol_2024121502.apk declares sensitive permission(s):
  android.permission.READ_PHONE_STATE android.permission.QUERY_ALL_PACKAGES
! repo/net.kollnig.missioncontrol_2024121502.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

I've just added

android.net.VpnService: needed to filter tracker access

as that's how the app works. I have no idea what it needs READ_PHONE_STATE for, though. QUERY_ALL_PACKAGES seems clear again: to choose apps to be filtered. So I've put:

android.permission.QUERY_ALL_PACKAGES: needed to list apps to filter trackers for

Last but not least, there's DEPENDENCY_INFO_BLOCK, which can easily be avoided by a minor addition to your build.gradle:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

So far:

Would be great if you could help us fill the gaps (especially for "chocolate warnings"), and get that blob removed.

PS: I've just checked my notes why TrackerControl is not enrolled for our RBs at IzzyOnDroid. It seems we were able to build the app, but there were differences in the *.so files keeping it from being RB. If you're interested to have the app enrolled (no signing change here as we already ship your builds), we gladly give it another try – for which it would help to know how your setup looks like, which tools and versions you are using and, if it's no secret, which path you build from (i.e. "the build directory location"). If you prefer, I'd open a separate issue for that then.

[kasnder]

Nice to hear from you! I'll add the code to the build.gradle.

As for the READ_PHONE_STATE, that's easy. The app has a functionality to disable the VPN whenever a call is ongoing. This obviously is only possible once this opt-in permission is granted at run-time. This aims to mitigate problems with the VPN and Voice-over-IP services.

[kasnder]

Should be fixed in 1df32c8

[kasnder]

As for RBs, not sure what the problem is there. Does it have to do with fixing the NDK to a specific version?

[kasnder]

It's very odd that Google adds this BLOB. I really don't like how Android is ever more moving away from open-source to a Google empire.. I'm also finishing up writing a book on the topic – to be released in October.

[IzzySoft]

Thanks Konrad! Explanation is added (live already). The warning for DEPENDENCY_INFO_BLOCK should be gone with the next release then.

As for RBs, not sure what the problem is there. Does it have to do with fixing the NDK to a specific version?

I don't remember. When the new release came in I just wondered why it was not set up, and found it in my notes – most likely from several months ago. I'm a bit more experienced now, so I gladly give it another try if you're interested.

It's very odd that Google adds this BLOB.

It's principally understandable that they want that information, and that they want it tamper-proof. But as nobody except them can tell what's really in that blob (and our POCs showed you could easily hide nearly anything in signature blobs without breaking the signing (apksigner verify will see no issue) or even trigger alerts from scanners (the engines at VT didn't mind our EICAR virus in there, and even a full ELF binary went unnoticed except for Pithus flagging it as "notice")), this also bears security risks.

I really don't like how Android is ever more moving away from open-source to a Google empire.

That's something that disturbs me for years already. More and more of the AOSP apps get replaced by proprietary Google pendants, and then mostly abandoned in AOSP.

I'm also finishing up writing a book on the topic – to be released in October.

2025 I guess? Sounds interesting, let me know where to grab a copy then. If I'd not be drowning already, I'd offer some proof-reading if you want – but I cannot promise to have sufficient time (though I'm intrigued).

That said: As you seem interested, let me try for RB again. Build is running while I write this. Will update you in the next comment.

[IzzySoft]

OK, here we go. I've basically just been running ./gradlew assembleGithubRelease, and this is the diff between your APK and mine:

  -rw-r--r--  0.0 unx      120 b-      118 defN 1981-01-01 01:01:02 1c3c83a7 META-INF/version-control-info.textproto
- -rw-r--r--  0.0 unx     4222 b-     4222 stor 1981-01-01 01:01:02 8b6a837d assets/dexopt/baseline.prof
- -rw-r--r--  0.0 unx      285 b-      285 stor 1981-01-01 01:01:02 8e470a73 assets/dexopt/baseline.profm
+ -rw-r--r--  0.0 unx     4218 b-     4218 stor 1981-01-01 01:01:02 62ee53a2 assets/dexopt/baseline.prof
+ -rw-r--r--  0.0 unx      285 b-      285 stor 1981-01-01 01:01:02 36b37854 assets/dexopt/baseline.profm
  -rw-r--r--  0.0 unx  7293544 b-  3032037 defN 1981-01-01 01:01:02 0837bec3 classes.dex
  -rw-r--r--  0.0 unx     3640 b-     1306 defN 1981-01-01 01:01:02 8608dd9b classes2.dex
- -rw-r--r--  0.0 unx  8161344 b-  2918338 defN 1981-01-01 01:01:02 7de08156 classes3.dex
+ -rw-r--r--  0.0 unx  8158972 b-  2917290 defN 1981-01-01 01:01:02 6522cbed classes3.dex
  -rw-r--r--  0.0 unx  2514800 b-   953200 defN 1981-01-01 01:01:02 4f03c297 classes4.dex
- -rw-r--r--  0.0 unx    87928 b-    38790 defN 1981-01-01 01:01:02 493672d8 lib/arm64-v8a/libnetguard.so
- -rw-r--r--  0.0 unx    64456 b-    35281 defN 1981-01-01 01:01:02 f0f2ee9f lib/armeabi-v7a/libnetguard.so
- -rw-r--r--  0.0 unx    82760 b-    38699 defN 1981-01-01 01:01:02 793fc1f0 lib/x86/libnetguard.so
- -rw-r--r--  0.0 unx    90208 b-    39717 defN 1981-01-01 01:01:02 cf14443e lib/x86_64/libnetguard.so
+ -rw-r--r--  0.0 unx    87640 b-    38743 defN 1981-01-01 01:01:02 16c93820 lib/arm64-v8a/libnetguard.so
+ -rw-r--r--  0.0 unx    63984 b-    35257 defN 1981-01-01 01:01:02 502f8786 lib/armeabi-v7a/libnetguard.so
+ -rw-r--r--  0.0 unx    82472 b-    38659 defN 1981-01-01 01:01:02 b001ec77 lib/x86/libnetguard.so
+ -rw-r--r--  0.0 unx    89920 b-    39697 defN 1981-01-01 01:01:02 f96ec40c lib/x86_64/libnetguard.so
  -rw-r--r--  0.0 unx  7057429 b-  3399991 defN 1981-01-01 01:01:02 93a6739d assets/GeoLite2-Country.mmdb

Which means it's all the libnetguard.so plus something in classes3.dex. The DEX diff is about 120 kB. Could be something with the used JDK. May I ask on which OS you build (here: by default, Debian bookworm – but we can easily switch to bullseye, or to Ubuntu jammy/noble aka 22.04/24.04) and with what JDK (here: OpenJDK-17 by default, but we can also do 11 with bullseye or 21 with Ubuntu).

I'll attach you the DEX diff here, and also the diffoscope output, in the hope you can spot something e.g. for the native libs. Haha, found something already, which also answers the OS question – that looks like an apple:

/Users/konrad/StudioProjects/tracker-control-android/app/src/main/jni/netguard/udp.c

OK, that is one point: embedded build paths (my APK had /build/repo/app/src/main/jni/netguard/udp.c instead). Luckily, that's easy to match (unless you build on Windows). So let me drop that diffoscope output again and first give the path a try… hm, must be more. But diffoscope.html now is down to 2 MB, it was 5 MB on the first run, so we're getting closer.

Yuck, an embedded build-id. OK, that's nothing I can fix, that requires your help:

Please take a look at our wiki here, keywords: "linker args" and --build-id=none. Not sure what of the other diffs are just resulting from that, e.g. what to make out of this:

(note the -bolt in your build on the left, and the +bolt in mine). More strange:

But well, maybe we address things one by one – unless your knowledge is deeper there (the things I point out now I had not even known to look for half a year ago. I had a very good teacher). So here come the files, in a ZIP: trackercontrol.zip

Thanks in advance for your help with this!

[IzzySoft]

Does it have to do with fixing the NDK to a specific version?

I've watched the build, mine picked up the NDK version from your build.gradle.kts fine, so that should not be an issue here.

[kasnder]

Hmm.. Really interesting. For RBs, I'm currently running the worst set-up: arm64, macOS, and the JetBrains version of OpenJDK 21 that's integrated into Android Studio. That's quite a few things to change (CPU architecture, OS, and JDK). I don't think I'll have the capacity right now to change all three. Sorry!

[kasnder]

I've added the suggested part to the C build instructions but I'd imagine that that's not enough..

[kasnder]

Because of the issues with the dex files.

[IzzySoft]

and the JetBrains version of OpenJDK 21 that's integrated into Android Studio

and known to have trouble with RBs. Could you switch to the non-Jetbrain OpenJDK there? AFAIK that could be downloaded even from within Studio – and thus the easiest part to switch (and start with for checking). Should that fail, too, other options would include Github workflows, or using rbtlog for building (if either podman or docker would be available to you).

I've added the suggested part to the C build instructions

Not sure where they were – I only find the build instructions in the Readme which state:

Android NDK (all recent versions should be compatible)

The version you use would be best for RB 😜

So if you want, what we could try for starters is:

• you build with the "real" OpenJDK-21 (hopefully solves the DEX issue)
• let me know the NDK used and the C build instructions you mentioned (should fix the .so issue)
• I try to reproduce that

[IzzySoft]

@kasnder any chance (or ETA)?

[IzzySoft]

You still there, Konrad?

[kasnder]

You still there, Konrad?

Sure, sorry! Just finished my book about the app economy... As I said: I sadly don't currently have the capacity to implement this.