Stellt NetGuard Verbindung zu "firebaselogging.googleapis.com" her?

Software
1

Während der Fehlersuche bei einer ganz anderen Geschichte bin ich zufällig in meinem IPfire-Log darauf gestoßen, dass mein GOS-Phone Verbindungen an der VPN-Schnittstelle (da läuft NetGuard Pro) vorbei in Richtung firebaselogging.googleapis.com via port 443 herstellt.

Per logcat kam ich dann zu folgendem Ergebnis:

02-29 11:38:55.762  3463  5387 I TRuntime.CctTransportBackend: Making request to: https://firebaselogging.googleapis.com/v0cc/log/batch?format=json_proto3

Ich interpretiere das hier Folgende doch insofern richtig, als dass der auslösende Prozess 3463 tatsächlich NetGuard ist, oder ?

02-29 11:31:18.881   861   861 D Zygote  : Forked child process 3463
[...]
02-29 11:31:18.883  1441  1646 I ActivityManager: Start proc 3463:eu.faircode.netguard/u0a126 for service {eu.faircode.netguard/eu.faircode.netguard.ServiceSinkhole}

Der dazugehörige Thread 5387 taucht insgesamt nur ein paar mal und ausschließlich über Prozess 3463 auf:

02-29 11:32:13.871  3463  5387 D CompatibilityChangeReporter: Compat change id reported: 194532703; UID 10126; state: ENABLED
02-29 11:32:13.871  3463  5387 D CompatibilityChangeReporter: Compat change id reported: 253665015; UID 10126; state: ENABLED
[...]
02-29 11:38:55.762  3463  5387 I TRuntime.CctTransportBackend: Making request to: https://firebaselogging.googleapis.com/v0cc/log/batch?format=json_proto3
[...]
02-29 11:38:55.985  3463  5387 D TrafficStats: tagSocket(106) with statsTag=0xffffffff, statsUid=-1
[...]
02-29 11:38:56.171  3463  5387 I TRuntime.CctTransportBackend: Status Code: 200

Da kann jetzt leider nicht unmittelbar nachvollziehen, ob tatsächlich auch Daten gesendet werden, oder einfach nur die Adresse „angepingt“ wird - der Status „200“ weist aber eigentlich darauf hin, dass irgendwas erfolgreich war.

Ich schaue mir jetzt noch mal den PCAP-Mitschnitt aus meinem WLAN-AP genauer an. Aber habe ich da einen grundsätzlichen Denkfehler drin, wenn ich annehme, dass die Kommunikation tatsächlich aus NetGuard kommt ?

2 „Gefällt mir“
2

Sieht oberflächlich zumindest so aus, als ob hier aufgrund eines spezifischen Ereignisses eine Info zum Status der Applikation gesendet bzw. geloggt wird.

Vor den Aufrufen wird im Code offenbar gecheckt, ob Notifikation gesendet werden kann. Kann mich aber zeitlich nicht da einlesen.
Vielleicht gibt es einen Schalter zu Fehlerberichten senden der aktiviert ist.
Ansonsten müßte man beim Entwickler anfragen.

3

benutzt Du die „heise“-App?

lt. Protokoll von NetGuard selbst versuchen hier™ nur die „heise“-App und die „Google Play Dienste“ Verbindungen zu „firebaselogging.googleapis.com“ aufzubauen, allerdings sind etliche Google-Domains unter gleicher IP zu finden, NetGuard listet immer nur eine und ich weiß nicht nach welchem Prinzip.

Wobei Du unter GOS die „Google Play Dienste“ wohl eher nicht nutzt.

In Vergangenheit war es so, daß Android den Datenverkehr der Apps, die durch das „VPN“ von NetGuard gehen, NetGuard zuordnete, das kann ich hier aber so nicht mehr vollumfänglich beobachten, aber für NetGuard werden dennoch „noch“ 1,55 GB von 61,32GB im letzten Monat gelistet.

NetGuard kann die Purchasing-Dienste von Google nutzen, aber imho läuft das NetGuard-seitig lokal auf dem Gerät eben durch die Befragung der Dienste von Google.

aus der FAQ (https://github.com/M66B/NetGuard/blob/master/FAQ.md#user-content-faq57)

(57) Why does NetGuard use so much data?

Basically, NetGuard doesn’t use data itself. However, many Android versions incorrectly account data of other applications flowing through NetGuard to NetGuard instead of to the applications. The data usage of other applications will be zero with NetGuard enabled in this case.

The total data usage of your device will be the same with and without NetGuard.

klar nutzt NetGuard ein paar Daten selbst, findet man wiederum in anderen Punkten der FAQ, warum das so ist

aber die zu „firebaselogging.googleapis.com“ dürften nicht dazugehören

4

Kurzer Zwischenstand: Ich konnte die selbe Kontaktaufnahme nun mit einem komplett „nackten“ iodéOS-Gerät ebenfalls exakt reproduzieren. Netguard stellt da eindeutig Verbindungen zu firebaselogging.googleapis.com her!

Der Mitschnitt aus dem WLAN-AP zeigt auch, dass ein größeres Datenpaket in Richtung Google-Server abgeht. Natürlich TLS-verschlüsselt. Im nächsten Schritt werde ich jetzt ein Gerät rooten und versuchen, mir über mitmpropxy den Inhalt anzusehen.

Das iodéOS hat jetzt übrigens NG 2.328 (GitHub, ohne Pro), das GOS ist noch auf NG 2.327 (GitHub, Pro freigeschaltet). Beobachtungen in beiden Fällen identisch.

Falls jemand so ein Setup gerade fertig zur Hand hat, würde mich gerne auch mal ein Vergleich interessieren.

@strauch_2
Nein, ich benutze weder die heise-App noch play-Dienste. Alle Apps stammen aus F-Droid. Deren Kommunikation läuft auch wie es sein soll durch NetGuard und nicht daran vorbei. Das ganze hat auch nichts mit der Datenmenge oder sonstigen Domains zu tun. Wie Du ja oben siehst (logcat-Dump), wird explizit firebaselogging.googleapis.com angefordert. Dazu geht dann im externen Netzwerkverkehr auch eine DNS-Anfrage raus und eine der darin zurückgemeldeten IPs wird kontaktiert.

3 „Gefällt mir“
5

Kann das nicht auch daran liegen, dass einige SDKs daran „schuld“ sind und dass denjenigen, die solche SDKs nutzen, das oft gar nicht bewusst (oder auch egal) ist? :thinking:

6

Dann frag doch mal Marcel, den Autor, meine letzten Anfragen per PlayStore-Kommentar als „Betatester“(einer der sich kaum da mal zu Wort meldet), hat er prompt beantwortet, jedoch auf die Kontaktmöglichkeit, welche auf der GitHub-Seite angegeben ist, hingewiesen, war eher ein Thema, was wohl nicht so in den PlayStore paßte, die dortige Version will man nicht wirklich, aber bezahlt habe ich darüber.

Support
For questions, feature requests and bug reports, please use this form.¹

There is support on the latest version of NetGuard only.

There is no support on things that are not directly related to NetGuard.

There is no support on building and developing things by yourself.

¹ https://contact.faircode.eu/?product=netguard%2B

Wenn man den PlayStore in Vergangenheit benutzte, konnte es durchaus auch passieren, daß deren Version auf dem Gerät landete(gleiche Signierung). K.A., ob einem das auch mit „Aurora“ passieren kann (sehr wahrscheinlich).

OT:
Ich habe hier mittlerweile wieder eine durch mich modifizierte Version 2.3.28 in Gebrauch, nach Jahren wieder mal dazugekommen, meine Anpassungen einzupflegen. Das Purchasing-Zeugs aber nur grob rausgenommen. Die Patches dürfen nicht mehr zu groß werden, um den Überblick zu wahren.

Ich habe auch vor, wieder mal tiefer durch den Quelltext zu gehen, aber was das „Android Studio“ und die weiteren Build-Abhängigkeiten damit tun, kann ich so auch nicht sagen.

Meine Version grad mal von „Dev Tools Pro“ decompilieren lassen, „firebase“ oder „googleapis“ ist mit „TotalCommander“ nicht als Text zu finden in den resultierenden Dateien, auch „fire“ nicht. (hier auf dem Gerät, „APK Studio“ auf dem Rechner wäre besser, damit kann man auch Änderungen an fertigen apk’s durchführen und wieder zusammensetzen mit eigener Signierung), paar binäre Dateien gibt es aber dann noch, so u.a. „libnetguard.so“ und „classes.dex“.

PS: zum Logging auf dem Gerät, die Zuordnung von Verbindungen zu NetGuard selbst paßt auch hier nicht, um zu sehen, ob was übrigbleibt, was nicht durch NetGuards „VPN“ geht, müßte ich aber wohl in NetGuard mal alle Apps sperren, ob NetGuard selbst dann immer noch auftaucht. Wenn die MDM-Lösung nicht alles listet, dann wäre sowas quasi unbrauchbar. Logging extern ist leider kaum einer App zuzuordnen.

Auf zwei 10er Androiden mit AFWall+ seh ich in dessen Log derzeit nichts zu firebaselogging.googleapis.com, aber NetGuard ist dort auch erlaubt, ansonsten soll alles durchs „VPN“, bis auf notwendige Ausnahmen.

7

Das NetGuard da nur auftaucht, weil es als VPN eben die Verbindung managed erscheint mir schlüssig.
Die im Log angegebene Klasse ist denn auch ein VPN-Service.

Nebenbei fällt mir auf, was für eine hochwertige FAQ das mittlerweile bei NetGuard ist. Muss mal wieder was spenden…

8

So, Fall abgeschlossen mit folgendem Ergebnis:

KURZVERSION
Ja, NetGuard sendet in der aktuellen GitHub-Version in der Tat komplette Logging-Informations in Richtung Google! Um dem zu entgehen, sollte man stattdessen auf die F-Droid-Version wechseln!

LANGVERSION
Nach Analyse des tatsächlichen Datenverkehrs mittels gerootetem Gerät und PCAPdroid konnte als Quelle für die Kommunikation die PLAY_BILLING_LIBRARY identifiziert werden. Es wird hier eine vollständige Logging-Kommunikation mit firebaselogging.googleapis.com hergestellt, d.h. Daten fließen ab und es gibt eine Rückmeldung.

Durch Ausprobieren mit einigen noch verfügbaren alten APKs konnte ich feststellen, dass das Datensendeverhalten bis herunter auf Version 2.322 vorhanden war, in Version 2.305 aber nicht mehr. Für den Zwischenraum hatte ich leider keine APKs mehr.

In der GitHub-Version ist nach Auskunft des Entwicklers (Marcel Bokhorst) aus nachvollziehbarem Grund Google’s „billing library“ enthalten:

Since many people expect Play Store purchases to work in the GitHub version, the Play Billing library is part of the GitHub version.

Da war in der Vergangenheit auch noch kein Thema, allerdings hat Google Mitte 2023 seit Version 6 nun zusätzliches Logging eingebaut! Dies war Marcel bisher aber auch noch nicht bekannt!

Die F-Droid Version enthält die „billing library“ erst gar nicht, somit auch an dieser Stelle keine Kommunikation mit Google.

7 „Gefällt mir“
9

Besten Dank für die Recherche!

Es wird bei NetGuard darauf hingewiesen, dass zur Nutzung der Pro-Features die GitHub-Version gentzt werden muss.
Damit ist NetGuard bei mir bislang die einzige SW auf dem Gerät, die eine andere Quelle als F-Droid verwendet.
Kann ich die Aussagen so interpretieren, dass Pro-Features auch mit der F-Droid-Version aktivierbar sind?

10

Ja, das geht auch in der F-Droid Version! Neuen Freischaltcode anfordern nach Installation und fertig!

Auf der NetGuard-Seite steht es auch tatsächlich so:

You can get all current and future NetGuard pro features (including updates) without Google Play services for the GitHub or F-Droid version by a one time donation of € 0.10 or more.

Die F-Droid Version hatte ich auch gar nicht wirklich auf dem Schirm, da kein direkter Link vorhanden ist.

11

Danke. Da kann ich in meiner Version wohl auch nichts finden.

Es wäre natürlich schön, wenn F-Droid beim Link auf die Quelle bei Modifikationen auch die „eigenen“ Sourcen zusätzlich verlinken bzw. ein „diff“ bereitstellen würde, evtl. auch solche Besonderheiten erwähnen. Hab die mir jetzt gerade mal von der F-Droid-Seite geholt.

Die F-droid-App hat die leider die Eigenschaft, bei „gleichen“ Paketen aus mehreren Quellen diese gemeinsam darzustellen, die Beschreibung der F-Droid-Version wird mir nur angezeigt, wenn ich IzzyOnDroid unter Paketquellen deaktiviere.

12

Super, vielen Dank für die Recherche!

Ein sehr guter Beitrag :+1:

13

Sehr gut. Habe gleich mal die Github gegen die Fdroidversion getauscht.

14

Das liebe ich so an Android, da wissen nicht einmal die Entwickler was Google so in ihre Software einbaut.

Langfristig gibt es nur einen Weg - weg von Android!

15

Kurz und mittelfristig reicht es scheinbar, stets nur direkt aus öffentlichen Quellen gebaute Software zu installieren.

16

Nerv … F-Droid-Version einfach über die Github-Version installieren geht nicht. D.h., erst löschen (github), neu installlieren (F-Droid) und dann erneut die Pro-Funktionen wieder aktivieren. Hat jemand noch den Link, den man dafür braucht?

17

https://activate.faircode.eu/?product=netguard

1 „Gefällt mir“
18

Soetwas kann vorkommen und ist vielen bei anderen Betriebssystemen auch schon passiert, auch bei Windows oder Linux.

Was das Build-System selbst draus macht, darauf müßte man sich verlassen können, also auch auf Compiler, Linker etc., es gab so mal eine kompromittierte Entwicklungsumgebung für Apple-Anwendungen, dubiose Quelle wohl, so ich mich erinnere.

Selbst Compiler-Optimierungen sind manchen schon auf die Füße gefallen.

Und eben die Build-Abhängigkeiten, in dem Fall Google, nicht vergessen.

Das alles zu prüfen …
… sportlich.

Mich ärgert ansich, daß ich nicht eher dazu kam, mein eigenes angepasstes Build zu machen, meine alte Version lief unter Android 14 nicht, hier schmiert unter einem weiteren Benutzer auch die Protokollansicht ab, Konsequenz für mich erstmal, den weiteren Benutzer wieder zu löschen, war eh nur Test und vllt. ursprünglich auch Grund, seit langem auf weitere Benutzer zu verzichten, unter Android 10 tuts das Protokoll zumindest im Arbeitsprofil, das kann und will ich mit demGerät aber nicht testen.

Dennoch muß ich mich auch darauf verlassen können, daß Google da nicht nochwas mittels seiner Entwicklungsumgebung reinzaubert.

in dem Zusammenhang auch passend aktuell von heise

GitHub als Malware-Schleuder | heise online

https://heise.de/-9644525

Schade, daß NetGuard seit langem seinen eigenen Datenverkehr nicht mehr listet, warum das so ist, das steht in der FAQ.
Optional wäre das schon schön.

So eine abweichende Signierung hat aber auch den Vorteil, daß PlayStore-Nutzern die Version nicht einfach mal überschrieben wird.

Das war für mich im Oktober der Grund, die F-Droid-Version auf einem neuen Firmen-Gerät mit administriertem Arbeitsprofil vor Provisionierung zu installieren, auf dem vorhergehenden lief meine eigene mit einem Upgrade der Android-Version nicht mehr und zwang damit zur Nutzung der Playstore-Version dort.

Beim Umstieg die Einstellungen vorher zu exportieren und danach wieder zu importieren zu können, ist aber hilfreich. Um die Aktivierung der Pro-Funktionen kommt man aber nicht umhin.

1 „Gefällt mir“
19

@Indeedee:
Vielen Dank für den Hinweis!
Was mich sehr interessiert:

  1. Wie oft erfolgen diese Verbindungen? Gibt es dazu Erkenntnisse?
  2. Lässt sich diese Verbindung nur in der Firewall oder auch im DNS-Logging
    erkennen bzw. kann sie Pihole blocken?
20

Der initiale Versuch erfolgt, sobald das Netzwerk verfügbar ist. Solange die Verbindung geblockt wird, gibt es auch Neuversuche - da habe ich aber nicht genau auf ein zeitliches Muster geachtet.
Beim „Neuzuschalten“ braucht es aber offenbar etwas „Cooldown“. Heißt: Netzwerk „ein-aus-ein“ triggert nur beim ersten „ein“. Wenn zwischen erstem und zweiten „ein“ so 5 bis 10 Minuten liegen, geht’s auch beim zweiten „ein“ wieder los.

Wichtiger aber: wenn die Verbindung einmal steht und Daten abgeflossen sind, bedankt sich Google mit einer Rückmeldung und lädt dazu ein, sich alle 15 Minuten wieder zu melden. Wird vermutlich der Firebase-Standard sein.

Es handelt sich hier ja um einen kompletten Standardablauf: DNS-Anfrage > IPs kommen zurück > Verbindungsaufbau an IPs. Somit läßt sich das auch mit allen üblichen Mitteln ausserhalb von NetGuard blocken, sei es per DNS oder/und FireWall. Oder noch einfacher: F-Droid Version nutzen.

1 „Gefällt mir“