News Malware bei Google Play: Apps mit über 600 Mio. Downloads allein in 2023 entdeckt

Wenn der Anbieter sagt er könne da auch nichts machen. Ganz mein Humor.

Als ob man die Verantwortung einfach so aus Faulheit weiter schieben könnte.

Sollen sie sich halt mal was überlegen wie man den Code prüft.
Apple scheint es ja auch hin zu bekommen.
 
Der Google Play Store gilt gemeinhin als sicherste Quelle für den Download von Android-Apps.
Das habe ich immer genau anders gesehen. Außerdem ging ich davon aus das die meisten, die sich damit auskennen, ähnlich verhalten damit umgehen.

Selbst Google kann nicht alles prüfen

Und auch hier, als Entwickler, ist meine Erfahrung dass Google deutlich weniger ausgiebig Testet als Apple. Da liegen Welten im Testen als auch in der Kommunikation mit den Entwicklern.

Nachtrag: Google erfordert demnächst eine DUNS Nummer von Entwicklern sowie weitere Kontaktdetails. Vielleicht hilft es ja beim ausfiltern.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
@Haldi
Bei vorinstallierten Apps geht das meistens nicht, weil das nicht erwünscht ist. Bei allen anderen kein Problem und wenn doch, wäre ein Wechsel vom Handyhersteller mal ratsam, wenn der sowas normales dem Benutzer verweigert
 
Haldi schrieb:
Das könnte man ganz einfach umgehen....
Erschafft eine Berechtigung für Internet Zugriff.
Problem gelöst.
Ob mein Rechner oder QRcode Scanner jetzt ins Internet kann oder nicht behindert die Funktionalität in keiner Weise. Nur das Ganze Tracking wäre damit nicht mehr möglich und darum will google das nicht.
Selber schuld.
Genau, aber wer ein android Smartphone hat, der ist halt das Produkt von Google und wird getrackt und Daten werden abgezogen und verwertet.
 
@MrHeisenberg Nichts für ungut, aber hast du überhaupt je eine APK entpackt, bzw. weißt du, wie das geht? Wenn ja, dann schau dir doch mal eine Library mit einem Hexeditor an. Ganz unten ist die Version der verwendeten clang vermerkt. DAS IST KEIN JAVA! Also lern du erst mal, was hinter der Programmierung von Apps steht!
 
  • Gefällt mir
Reaktionen: Haldi und pseudopseudonym
@MrHeisenberg Was redest du da? Ich meine mich zu erinnern, dass das vor 10+ Jahren mal so war (selbst da bin ich mit nicht sicher), aber mittlerweile ist das definitiv nicht mehr der Fall.
Das "parts of" bezieht sich darauf, dass in Android-Apps in der Regel externe Libs benutzt werden, die nicht unbedingt die gleiche Programmiersprache wie die eigentliche App haben müssen.
 
MrHeisenberg schrieb:
Die App als solches ist aber trotzdem Java.
ist sie nicht. die fertige app ist der bytecode, der aus dem java und c/c++ source erstellt wurde. java als programmiersprache und java als laufzeitumgebung sind zwei verschiedene sachen.
 
@0x8100 Android Apps laufen auch nicht mehr zwangsläufig mit Java Bytecode, die Zeiten sind vorbei (war doch mal so, oder?).
 
der bytecode wird immer noch verwendet. früher mit dalvik, heute mit der android runtime. das ist ja ein vorteil dieses ansatzes: der programmierer erstellt und google verteilt nur den bytecode, lokal wird er aber durch die runtime für das jeweilige gerät in den passenden maschinencode übersetzt. sonst müsste man für jede cpu-architektur separate binaries vorhalten.
 
0x8100 schrieb:
ist sie nicht. die fertige app ist der bytecode, der aus dem java und c/c++ source erstellt wurde. java als programmiersprache und java als laufzeitumgebung sind zwei verschiedene sachen.
Die App wird in Java geschrieben, welches dann auch C++ enthalten kann, aber ohne den Java-Part kein C++:
https://source.android.com/docs/core/runtime?hl=de#Debugging_Imp
Die Android Runtime kann mit reinem C++ nichts anfangen!
Zeitkritischer Code in C++ o.ä. Zu Coden und in der App zu nutzen ist nichts neues bei Android, dennoch ist das Grundgerüst der App Java.
 
@MrHeisenberg Die Struktur einer APK (hier: Chrome):
Code:
├── AndroidManifest.xml
├── assets
├── classes.dex
├── lib
│   └── armeabi-v7a
│       ├── libarcore_sdk_c.so
│       ├── libcrashpad_handler_trampoline.so
│       ├── libelements.so
│       ├── libmonochrome.so
│       ├── liboptimization_guide_internal.so
│       └── libyoga.so
├── res
├── resources.arsc
└── stamp-cert-sha256

classes.dex -> Java

*.so-Dateien -> C++
, können NICHT dekompiliert werden, um den C++-Quellcode zu erhalten. Ist es nicht Open Source, können die *.so-Dateien nicht nachvollzogen werden -> Schadcode kann nicht erkannt werden. Verstanden?
 
  • Gefällt mir
Reaktionen: Tanzmusikus
PC295 schrieb:
Gibt es doch schon...
Als separates Menü sogar.
Nein gibt es nicht.
Wo gibt es eine Abfrage dafür?
Kannst alles einstellen, Mikrofon, Standort, Fotos, Kamera, aber nicht Internetzugriff einer App.
 
  • Gefällt mir
Reaktionen: arvan
0x8100 schrieb:
sonst müsste man für jede cpu-architektur separate binaries vorhalten.
Nicht "müsste", muss man für die beschriebene Art Apps tatsächlich, wobei das oft in ein APK gepackt wird (kann man zusammen bundlen). Sieht bei uns in der Play Console so aus (siehe das markierte):
IMG_20231111_172237_866.png


Für einige Apps gibt's auch getrennte APKs fur verschiedene Architekturen, hier ein Beispiel:
IMG_20231111_172240_619.png


Da der Chromium Open Source ist, kann ich wohl auch den APK-Mirror hier als Quelle angeben:
https://www.apkmirror.com/apk/bromite/chromium/chromium-106-0-5249-72-release/
 
  • Gefällt mir
Reaktionen: Haldi
Entscheident sind auch hier die Libraries, die an die CPU angepasst sein müssen. Ist die APK universal, enthält sie alle Libraries für alle CPUs (APK ist dann sehr groß) oder hat keine eigenen Libraries.
 
  • Gefällt mir
Reaktionen: pseudopseudonym
MrHeisenberg schrieb:
Die App wird in Java geschrieben, welches dann auch C++ enthalten kann, aber ohne den Java-Part kein C++
Nein, du brauchst ein winziges bisschen Java (oder Kotlin, inzwischen meistens das) als "Launcher". Der C++-Teil (oder Rust, oder, oder, oder) läuft nativ. Deswegen musst du den Teil auch für alle Zielplattformen kompilieren.
 
Zurück
Oben