Sohn bekommt @kinderus Überraschungs Ei ... ihr wisst schon, das Ding wo früher mal coole Sachen drin waren ... Getriebe, Metallzahnräder richtige Schwungräder
"Spannung, Spaß, Spiel"
Wir kaufen die nur noch selten, weil Heute nur noch Plastikmüll drin ist.
Mein Sohn rennt also wie angestochen durch die Bude und sucht verzweifelt den Beipackzettel zu dem Plastikmüll.
Ich wundere mich, ist ja alles schon zusammengebaut.
Er findet ihn ...
Ich verstehe, ist ein QR Code drauf, das sagt ihm was.
Er: Papa kann ich den mit deinem Handy scannen und die App spielen (App hat er also auch gleich abgeleitet)
Ich: Vergiss es, kostenlose Apps sind alle 😈... ich beschäftige mich gerade damit.
Sohn sauer, ich gehe Rauchen
Überlege und öffne bei Zigarette mal die Datenschutzbestimmungen.
App explizit für Kinder ... Verantwortung wird an Eltern übertragen (COPPA konform)
Die eingebaute Gesichtserkennung speichert keinerlei Daten und ??? die so erhaltenen Daten werden auch nicht an Dritte weitergegeben ???
Passt schon!
Komme zurück von meiner Zigarette und gehe zu meinem Sohn (schlechtes Gewissen).
Ich: Hey Kumpel, hab das mal ge-checkt ... klar kannst du die App mal probieren, aber wir nehmen eins von meinen anderen Handys zum testen.
Gleich nach der Installation bin ich gefordert
Datenschutzrichlinie ist die gleiche wie ich schon gelesen habe, passt auch
Gleich nach dem "user consent" ... oder "parent consent" gehen dann die ersten Daten an Google raus (da kann Ferrero Kinder nicht viel machen, schätze ich)
Kamera Zugriff ... lieber nicht, das mit den Daten zur Gesichtserkennung habe ich in den "privacy terms" nicht so richtig gerafft
Schnell Nickname, Geschlecht (optional), Haut- und Augenfarbe festlegen ... und los geht's
Sohn spielt, Papa schaut mal an welche Tracker Daten gesendet werden
Erstaunlich: Crashlytics bekommt nur Gerätehersteller, Gerätemodell und die Buildnummer des ROMs.
Unity3D geht ganz leer aus (bis auf den ping-back zur Nutzeraktivität)
Hmm ... vielleicht sollte ich nicht nach bekannten Trackern filtern!
Was ist den 'sdk.easyar.com' ... da gehen ja fast alle Gerätedaten hin, die mit den beschränkten Berechtigungen der App abrufbar sind (einschließlich persistenter Android ID)
Ach so! Das ist nur der nette "Cloud basierte Bilderkennungs-Service" aus Shanghai ... quasi direkt von neben an.
Danke Ferrero, ich de-installiere die App mal wieder, bevor mein Sohn versehentlich doch noch Kamera-Zugriff erlaubt
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Put another day into bypassing anti debug/instrumentation measures of the "DJI Go 4" app. Reached my goal, but in contrast to published reports on the app results are very disappointing. Not much is sent outside by the app
To put it into perspective, here are the same visualizations for the Burger King app. Compared to DJI it has to be called a privacy nightmare
The BK app not only sends out your location (before the confirmation dialog in "King Finder" tab), it also combines re-settable and persistent identifiers (Android ID and Advertising ID). This allows bridging user initiated resets of the Advertising ID.
Okay, I managed to instrument the "DJI Go 4" Android application (packed with SecNeo, ptrace-based debugger avoidance).
Here's a quick example with @fridadotre frida-trace utiliy (tracing lib.c->open calls).
Steps to reproduce in a few minutes in this thread ... stay tuned
First things first:
1) I am running the app on a arm32 device (armeabi-v7a) 2) I want to avoid repackaging the APK, thus modifications are done directly on the device, once "DJI Go 4" is installed (requires root) 3) @fridadotre is used in gadget-mode
Step 1)
The SecNeo packed APK ships with various native libs.
The most interesting one is "libDexHelper.so".
Unfortunately this ELF lib has no dynamic section, thus we need an easier target to inject the Frida agent.
Throughout last days, I struggled instrumenting Google SafetyNet protected apps with @fridadotre (meanwhile 14.0.6), because SafetyNet's "basic integrity" check failed.
The test device runs LineageOS + Magisk.
Let me share how I approached this issue
The root issue was an outdated version of "Google Play Services", which was fixed by installing the most recent version of "Open GApps". This bumped GMS to version 20.39.15
In order to pass the SafetyNet basicIntegrity check, "MagiskHide" comes to help. It has to be applied to the Google Play Services (formerly known as Google Mobiles Services aka GMS)
Recently SafetyNet checks started failing on one of my test devices.
The cause is that the request for the "attestation ID" is failing, with error status -129.
The status code -129 corresponds to a failed Binder transaction. The service backing the called Binder interface is 'KeyAttestationApplicationIdProviderService'.
The specific method is `getKeyAttestationApplicationId`.
Is anybody used such an issue where the Binder ...
... interface IPC call fails? Any guidance on how to fix or further investigate this is welcome!
About one and a half years ago, I disclosed several security issues affecting @Logitech wireless peripherals (mainly "Unifying" brand, but others - e.g. "G-Series Lightspeed" - are affected too).
Because of recent requests, I want to briefly review the flaws
1/n
1) CVE-2019-13053 covers a an issue, which allows an attacker to inject encrypted keystrokes over the air, without knowing the actual encryption keys. The root cause is unproper protection against counter reuse for underlying AES CTR.
In order to exploit this ...
2/n
... is required to get knowledge of about 8 keypresses while sniffing encrypted wireless traffic. This step is only required once. If the victim uses a clicker - for example - an attacker could get knowledge on a pressed key sequence, by observing how the slides ...
3/n
If you are interested in what data Android Apps push out to AppsFlyer, it might be a good idea to utilize @fridadotre to hook the 'af*' methods of class 'com.appsflyer.AFLogger'.
The screenshot shows an example of the app 'Bild'
1/n
The screenshot contains to events, related to outbound http requests.
1) The one starting with "url:", which contains a request URI 2) The next event starting with "data:", which contains the **unecrypted** content, which is sent out ("appsflyerkey" redacted)
2/n
If you inspect the corresponding HTTPS request, the actual data is encrypted (at least it should be).
So if you have to proof the the data from "AFLogger" is contained in the request, you have to decrypt the body content