Seven viruses in Virus Total
Jgarcia118 opened this issue · comments
Virus Total showing seven viruses/malware. Virus Total never showed any issues before.
Posting it here for references: https://www.virustotal.com/gui/file/d4ed7218ff758cc93e7f5fdf261910a5c950b30fa78df0c09a8da130617d280e/detection
But I'm fairly sure it's a false positive, likely because this app tries to connect to a set of different APIs of websites (of course, to fetch update data). Also, the app is open-source, so you can go through the code by yourself.
I suspect it's the root install.
The app is open source, if you don't trust the binaries you can always build them yourself.
Me too, virus detected is shown in avast and McAfee.
Same here on Huawei Mate 10 Pro internal antivirus check.
It also (falsely) alerts me.
Been getting these warnings for a week or so on my Huawei P30 Lite. The phone is not rooted.
Been getting these warnings for a week or so on my Huawei P30 Lite. The phone is not rooted.
Huawei p40 lite, same thing here.
And FYI, Huawei phones are basically impossible to root.
It doesn't matter if your phone is rooted or not, the root functions inside the APK are likely what's tripping the AVs.
These malware reports look identical to the ones that Aurora Store had a few weeks back which turned out to be false positives. Aurora store Dev got in touch with each of the companies flagging Aurora Store as malware and managed to get all false positives taken off. Would advise @rumboalla doing the same.
It's the root library used for root installs (https://github.com/Chainfire/libsuperuser)
I have made 2 different test builds:
- All the root install code removed including the library. No virus detected.
- All the root install code removed but the library is used to perform a "ls" as root. Virus detected by Avast (Avast-Mobile
Android:Evo-gen [Trj])
Apologies for the duplicate (linked above), but find some additional details there. To me it's pretty sure a false positive. At least 2 of the scanning engine have a history of false positives exactly with this one (Android:Evo-gen) – so the other two might have a "bad signature" as well. With the latest release, it's just 4 engines left reporting they "found something".
From #479
What's peculiar to me is that, though VT is a sibling company & presumably is used in the service, GPlay Protect has never flagged APKUpdater on my stock unrooted Android, even those last 3 versions, so it seems Google itself doesn't believe those reports?!
Probably they came to the very same conclusion ("false positives"). Btw, AFAIK VT is run by Google even, isn't it?
AFAICT, both Google & VirusTotal's corporation Chronicle are (again) subsidiaries of Alphabet.
There is no way Play Protect uses VT as is. I am sure they have either their own engine or very few select engines that they use and not all 60+ that VT works with.
Bit of curiosity got me to https://www.virustotal.com/gui/file/397dcb0bff985556b3ea7c26dd975e5319882d9b8e1eb0ffe0a266d65b7a7715/detection - (Root related) stuff like App Manager and Droid-ify all came back "clean" besides maybe tripping some IDS which is to be expected.
What could get interesting is the class they threw it into, seems to be quite a bit of activity there.
The latest 3.0.2 update comes back clean for me apart from Avast is still flagging it. I have Avast embedded in a system app on my old Xiaomi Poco X3 NFC phone and is notorious for flagging apps for seemingly no reason.
I checked my records and the anti virus companies and the reason why they flagged ApkUpdater having malware and/or being dangerous to have installed were the same ones that Aurora Store had when they went through the same. It begs the question how originally Google comes up in the virus total report saying 'detected' yet a scan with Google play protect says the app is clean.
It is most disturbing to see open source apps being flagged as dangerous without good reason.
EDIT Most strange. When I scan with the virustotal app it only detects Avast as being the one still flagging this as malware but going on virus total site it comes up with 5?
While Android allows for plenty of freedom, us here being the tiny minority making legitimate use of it, combined with the "strict" Play Store "moderation" which makes up the vast majority of "good" activity coming from/seen on Android devices probably results in more than usual false positives pushed into production/live detection as the use of mentioned libraries/mechanisms/behavior shows up much more often in malware than known/used legitimate Applications.
Does company Y know that they just flagged several legitimate Apps while trying to get stuff under control ? do they care enough ? It's not like Google is knocking on their door to get things resolved.
(A few users getting their favourite App flagged vs potentially catching more stuff)
And as you might've come across a few stories lately and over the years, even the biggest companies get hit by (sometimes devastating) false positives.
Still a different situation obviously (big player vs small community) but still important to mention to avoid drifting into potential "clearly malicious/targeted flagging!!1!" accusations, you've all seen how that ends. (General advice, not! related to @Deerp1976's comment to make that clear. Totally agree on that one)
Manual outreach might work for now (like Aurora) but with Engines not even in agreement on the type, you might just end up back here after a lot of stress getting things worked out with every single (responsive) company as now different companies might flag it with thread XY getting traction.
(No idea though, never done it, never have to hopefully)
Might all seem obvious that this is the price we pay by moving around outside the bubble (mainstream?), I'll still highly suggest to get familiar with the other tabs Virustotal provides in reports, for a more complete picture than just "X/Y flagged your app!".
And yes I'm aware of the crowd out there leaving "just don't use AntiVirus/Virustotal!" comments everywhere...not gonna comment further on that one.
Edit: ImranR98/Obtainium#1082 (Let's see how that goes)
Edit2 actually looking at classes.dex "detections" like duh "BehavesLike.DEX.Suspicious.vl" might turn keeping Open Source Apps detection free into something interesting..who can come up with the most logical explanation for a given classification.
Anyway things have come as far as they have today, unless things drastically change towards "mass concern" flagging levels, nothing much will change (and that might be a/the way to go anyway ?).
There's also the move towards reproduceable builds by default -> greater FDroid coverage/trust, bigger (?) Apks provided by @IzzySoft further securing the space.
(Sorry for the unrelated tag, just trying to keep non participating readers on what I'm getting at)
Still leaves the fact that more and more is being done by default on Smartphones, while users expanding their App collection/use beyond the "protected" Play Store pool, while maybe even aware of more frequent topics like this, their device might ship with a "Security" App that might not see it that way, bringing us back to square 1. (Don't forget the "maybe I shouldn't have.." thought when walking into a whole new world, scary warning messages and concerned users in Open GitHub issues...you know, we've been there.)
As Play Store Guidelines get tighter...
Anyway enough of an essay from me.
I'll still highly suggest to get familiar with the other tabs Virustotal provides in reports
I also recommend having such apps scanned by Pithus, which gives you some extra insights. Here's an example report I had to call for as "some company" kept bombing me with take-down request for an app mentioned by some "malware attack" (that malware seemingly called URLs of several APKs in my repo – all of them innocent victims), which helped me repel that request (especially take a look at the last 3 tabs with the code, behavior and network analysis).
reproduceable builds
For details on that you might wish to read my article Reproducible builds, signing keys, and binary repos – which includes hints for precautions developers can take (mostly on securing their keystores and the case of loss).
I also recommend having such apps scanned by Pithus, which gives you some extra insights.
Thanks for this, @IzzySoft. For some reason, I couldn't find a link to its source from there, so that's https://github.com/Pithus/bazaar. It seems built partially from some of VT's framework.
Pithus even uses VT results (links to them in its threat analysis), but that's all I can say. We use it with reviews at F-Droid.
@IzzySoft well first thank you for jumping in again (twice apparently) with further suggestions and insight on how to move forward.
As I absolutely not intended the post to turn into what it eventually did, I apparently left out a bunch of context relevant things...even leaving a random "bigger (?) apks" in there, a not really intended "still have to read up on that one" given that until fairly recently I remember discussions about Apps staying GitHub only, due to FDroid requirements & your APK size limit as "hurdles"... In short: seeing Sideband with a whopping 68MB in your repo surprised me. (One less entry in Obtainium 👍)
Anyway for anyone not wanting to dive to deep/start somewhere/keep track of things, I'll leave https://github.com/LibChecker/LibChecker here as an easy to get into, on device basic "allrounder". (Not perfect or all-knowing of course)
Are those "Bug Fixes and Performance Improvements" just more Ads & Telemetry ? now you know. Doesn't prevent the 💩 from making it onto your device of course, might make you look out for more honest, free and open alternatives though.
App Y using libwebp, last updated x months ago ? Might want to look into it. (Some Devs actually only pushed an update after being asked about it (despite the, you know, "attention" it got, weeks later - some still haven't & might never - not calling anyone out - tricky topic meeting my obviously limited insight and involvement)
While not really the intended use case for it, it absolutely shows those and many more changes assuming a fairly recent snapshot exists.
Totally not related to the current Issue but I couldn't help it, again.
Might have to start moving and catching up on stuff again, if I intend to contribute useful on topic things going forward (bit of self reflection in the end to round things off 👍 )
</essay end, forgetting most of the things worth mentioning anyway>
@TotallyAvailable I have a hypothesis that the reason for these false positives happening lately is down to these anti virus companies just updating their heuristic databases and then spotting something that 'might' be dangerous so announce it in virus total under a generic malware brand which seems to cover a broad aspect of things and only check to see if they are valid if they get enough responses asking them for further information. A bit cynical perhaps but I've seen this a few times now. You can do a simple test of modifying an APK that's getting flagged as malware and change the signature of it. Upload that to virus total and you will most likely get a clean result.
I must admit I have lost confidence in being able to trust Virus Total lately but have opted for an attitude of if more than 10 companies report an app is suspicious, that gives me enough cause to be concerned to uninstall it or dont install it in the first place but I have to question the validity of these reports as some of them just seem crazy. I've just ran a scan on my pixel 5 device with the virus total app which can scan both system and user installed apps. I currently have 16 system apps that TrustMicro-HouseCall are saying have a Trojan called Troj_Gen.R002V01J023. How can this possibly be taken seriously?
It honestly feels that instead of bringing clarity and resolution, these reports instead bring confusion and doubt.
I mean I can absolutely see it, (VT) being Google "owned" obviously only adds more fuel to it. While my opinion on Google/Alphabet would certainly get me kicked out of those circles (still using plenty of Google/Play Store/Google Employee side project stuff), there's obviously not enough pressure/punishment to get things done just "broadly" enough and cleaned up quickly after a mistake, like you know, Google saying "stop flagging apps we scanned and slapped 'Play Protected' on" or just casually destroying Windows Installations around the world.
Also hard to know who is going to suffer this time if no known legit part of App xy is in whatever "test before push" may or may not take place.
Thought about starting another essay on the findings mentioned by @rumboalla but meh...I'll just wait and see how things go.
Next someone starts flagging every apk not signed by Google (Google Play Signing).
Obviously if there's little to no legitimate feedback (or is being ignored, don't forget the other side of things, malicious false positive reports) from those tiny affected communities (I certainly don't scan every single update for every single app I use, if an app would ever give me the desire to do so...I'd rather look for alternatives), kinda wondering how many Open Source user actually depend on (fresh) VT results vs the collective trust and attention the dev has (assuming a direct download).
The build in Security Apps are obviously the end boss for non rooted users in this case and OEMs obviously want it to be this way (They only want the best for their users of course), no conspiracy there.
Without specifically checking related (in behavior) apps, I probably would've never stumbled over the one Obtainium got flagged with myself. With eyes on the commits, it would just be another independent false positive, business as usual.
Heck, what got me actually to pay more attention to the bigger picture again is the existence of #479, if someone you put that much trust into, rings a bell, I'm listening.
There's obviously the whole topic of dependencies I'll leave untouched for now.
Anyway, while I mentioned my VT usage (and no Windows (I know...) Installation is ever complete without Process Explorer) your "modify the file for a clean result" just matches what should not be forgotten -> No (serious) bad guy (aware of commonly used security tools) would ever start without a clean sheet.... obviously you only hit 'send' if iteration XY is looking as legitimate as it gets, unrelated to just VT obviously.
TL:DR...eggs'n'baskets - the multi layered approach is the way, just don't dig to deep.
Next someone starts flagging every apk not signed by Google (Google Play Signing).
Next? Didn't we have that already? With apps even being uninstalled if they were installed from e.g. F-Droid, but left alone when the exactly same build was installed via PlayStore? Like, F-Droid version of KDEConnect uninstalled by PlayProtect?
And yeah, if it's only 5 VT engines or less (and usually that's mostly "minor ones" plus the "usually false ones" we just encountered here), to me that means it's most likely a false positive. The good thing to VT is it includes so many engines (60+) and thus gives you that comparison.
if someone you put that much trust into
blush 😳 I'll give my best to live up to that, thanks!
Next? Didn't we have that already? With apps even being uninstalled if they were installed from e.g. F-Droid, but left alone when the exactly same build was installed via PlayStore? Like, F-Droid version of KDEConnect uninstalled by PlayProtect?
Missing this one just goes to show the massive difference in knowledge about the current situation between us. While I'm kinda talking outa my behind, piecing stuff together I might've picked up wherever over the years, as 1 person with a bigger App arsenal in use than necessary (I'm aware of that one at least)... and rarely enough of a concern to really start digging, I obviously only come across so many things (including plenty of totally not unhinged rants targeted towards Google ofc) compared to your deep and active involvement in everything (as I might miss half the things...I'll go with "everything").
blush 😳 I'll give my best to live up to that, thanks!
Your deep involvement and continued return to related Conversations, (pro)actively jumping in on related things...and as shown in the recent FreePaint situation, you are obviously well aware of why we use your Repo and FDroid, certainly not just for the convenience.
(Would I have reached out via email (still sitting on the pre-accident ver.) ? ...the quoted response sums up my concern doing that perfectly. Certainly got me thinking about my approach on things. Not meant to be an attack on the dev to be clear, not a situation I would want to be in.)
And as mistakes happen when we get the most comfortable, and this is not meant to sound like a lack of confidence into the things put in place, I still do not Auto Update, ever. (Might not be for everyone, that's just what I settled for)
To avoid another endless-drifting-off-topic novel, thank you and no pressure (!), there's already enough of that, I can only imagine.
deep and active involvement in everything
Considering I run my own repo, and am also one of the maintainers at F-Droid, many things come to me without me actively searching for them, yeah. And yes, I take those things quite serious – not just for me, but for others as well. Call me a dreamer, but I still haven't given up pushing against e.g. the current state of surveillance, privacy invasion – and most people giving in out of frustration (don't think that stuff isn't frustrating me as well; I had to stop getting involved in some areas to be able to at least taking useful steps in those where I can). Not to forget explaining the differences between "free", "open" and "libre" over and again 🙈
you are obviously well aware of why we use your Repo and FDroid
Sure I am. Guess why I'm running mine 😉 And it often brings me into conflicts, due to my limited resources. If I hadn't to say "No" to larger apps (there are exceptions as you've noticed, but they are few; I can explain on them in another place if there's interest), and to keep double-listings limited, my repo today would host at least twice the amount of apps it actually does (and be at least 4 times the current storage size). On the other hand, the "per-app size limit" has lead to smaller apps more than once, which is a good "outcome" (side-effect?).
I still do not Auto Update, ever.
Honestly: I don't either 🙈
there's already enough of that, I can only imagine.
Oh yes, there is. And you probably can only imagine half of it (for the authors as well as for us maintainers, and others involved). Let's NOT delve into that…
my repo today would host at least twice the amount of apps it actually does (and be at least 4 times the current storage size). On the other hand, the "per-app size limit" has lead to smaller apps more than once, which is a good "outcome" (side-effect?).
Which can still be seen as unresolved "issue" given that every update comes as full sized package. I remember reading about it back in 2018 (already late to the party) about the state of delta updates. As things apparently haven't gotten out of control in terms of filesize and userbase since then and the ever increasing Data Volume/Speed you get per €/$... I don't even know why I just mentioned it again besides obviously having an eye on it given the manual update process (and complete lack of knowledge on the possible technical implementation). That's still purely from my privileged point of view of course, plenty of users out there would certainly benefit from diffs vs full.
On the Play Store side of things...stuff certainly got bloated beyond reasoning.
The only "side-effect" I'd "call out" given the size limit would be me manually pulling the -v8a version, assuming the dev decided to (obviously) go with broader compatibility for the inclusion. Not even a nitpick just me doing stuff differently.
What I do like to mention though is (not-yet reproducible) Apps switching from your Repo to FDroid and the following removal to avoid double listings potentially leaving users paying less attention (than me) "stranded". (Squawker as fairly recent example)
Apps might provide means of 'Update Available' Notices of course, still requiring a change in behavior.
Or I might just be completely ignoring something (I'd never do that!) while typing yet another wall of text with a lotta words for little actual "what I'm trying to say".
As I literally have no data on the pool sizes...how many FDroid users even know about your existence..I might've just blown a non issue out of proportion.
And yes the "Dreamer" - I have sadly completely given up on that one at some point while still paying way to much attention to certain things...forever stuck in a state of denial. Add a bucket of paranoia after touching the bottomless pit called "Cyber Security" and you get me, soaking up all the negatives for none of the benefits for dancing out of line, if that makes sense.
We're getting very much off-topic here, @TotallyAvailable – as interesting as it is. And yes, I'm aware with the issue of non-RB apps moving over to F-Droid, but I cannot help it. And in-app updaters are … well, a separate issue (and too much to discuss here – OT etc. Short note: if they notify of an update, where is it available then?).
how many FDroid users even know about your existence
Enough to cause 2.5 TB of traffic per month, numbers growing, having almost doubled within the last year, tripled since 2 years ago 😉
We're getting very much off-topic here, @TotallyAvailable – as interesting as it is.
Just really hard to not make use of the opportunity to get a better look on the situation in a more natural way than me (or someone else) trying to reach out privately. (Probably time to let things happen and resume on topic discussions when necessary though)
Short note: if they notify of an update, where is it available then?).
That was purely me trying to not reflect too much based on my usecase. As I don't even need half a set of fingers to count the number of in-app self updaters I make use of.
More of a "assuming the move was planned ahead of time, leave a notice pointing back to the 'direct' release somewhere" type of thing, not always possible, besides the credits with source already being there of course.
That's all I (personally) really want though, a toggle (important !) in the settings offering to periodically check for new versions, with some logic behind it.
Say check once a day (during active usage), suppress notice if release less than x hours/days old, if the App drops out of your repo or the user changes behavior (settled on their setup) it'll eventually notify about the situation or at least serve as a reminder to check in on their FDroid client of choice (again during active usage)
(Assuming you try to avoid double listings in, say Droid-ify and Obtainium for [App], not also manually having an eye on the dev repo, would eventually leave you stranded unless you notice the entry making it towards the top after an index refresh, without offering you to update... lots of if's in a specific situation and I don't even need to paint a picture here as you are aware of it and actively working towards solving it, that is, unless the dev opts for a separate .fdroid build)
Enough to cause 2.5 TB of traffic per month, numbers growing, having almost doubled within the last year, tripled since 2 years ago 😉
That would only be like 7142 users updating Mulch+Webview, once...talking about the effects of app-size limitations. (Just a comparison as those 2 and their size are obviously a bit of a special topic in itsef)
Also excluding the overhead of direct site visits and non cached pictures of course.
Initially really only meant to hold onto something, I literally have no overview on how often Apps actually do the (unplanned) move vs user's left stranded due to their usage pattern (roaming outside the defaults)...me not going off topic, impossible.
Anyway, without going into the possible downsides and resulting problems of your ever increasing popularity, you obviously deal with those every day, that's good to hear. Given all (your) recent blog posts, maybe, just maybe, I might end up joining in on that dream of yours again, as it certainly doesn't look like it's ending any time soon/too late to be part of it.
And sorry about bothering you again (unrelated to my "ending" words above) @IzzySoft but also semi (trust) related, asksven/BetterBatteryStats#906 I did wonder about the implications of his words back then, now I'm (apparently) in the situation to actually ask, is there a backstory/clarification (that I could read about) or am I reading more into it than necessary.
You can do a simple test of modifying an APK that's getting flagged as malware and change the signature of it. Upload that to virus total and you will most likely get a clean result.
https://www.virustotal.com/gui/file/671676f68988d5ea75711c5f301b4faee5343d7b2814627e66d3f551791ffe8c/detection Someone did and the results do indeed add more confusion.
Closing this, no more warnings.
https://www.virustotal.com/gui/file/791890a4711a588e0a6fed144e357ac5f07539e5ba9a534afb06a58ac8c3e19b