Other [solved] Investigating Google's false positive virus checks

fredo · Apr 21, 2023

This is a continuation of: https://www.b4x.com/android/forum/t...-as-virus-false-positives.147513/#post-935210

The Problem

Apk files that are uploaded to Google Drive are marked there as virus infected.

Consequences:

The affected files can then no longer be shared via a share link.
The affected files can then no longer be uploaded to Play Store
Economic loss, as the product can no longer be marketed

1. Check: External Scan of apk
A check using virustotal.com gives 2 hits and 63 ok:

VirusTotal

www.virustotal.com

Icarus classifies it as "Trojan-Spy.AndroidOS.Agent"

The effect occurs with obfuscated and without obfuscation.

2. Check: Removal of libs and renewed external scan
With the help of @MarcoRome (see previous thread) some libs were looked at more closely and disabled individually.

The result of the scans was unchanged.

3. Check:
A new neutral default app (see "falsepostest1.zip") was scanned with the following result:
1 hit and 64 ok:

VirusTotal

www.virustotal.com

McAfee-GW-Edition classifies it as "BehavesLike.Suspicious.cc"

This result is different, but interesting.

4. Further, planned procedure

a) Create an empty default app with all libs of the source file

~~b) Create an empty default app with all libs and modules of the source file.~~

If anyone has experience with this problem or can make concrete usable suggestions, input would be appreciated.

fredo · Apr 23, 2023

Another new aspect:
Since the string search in the reengeneered apk file brought nothing, the additional info on Virustotal was looked at again more closely.

On https://www.virustotal.com/gui/file...8dd33d5dce3aacd1704c49eb2d6a1a7afb2?nocache=1
the Crowdsourced IDS rules “View matches” part reveals a Destination IP: 108.177.119.94

Google!

108.177.119.94 IP Address Details - IPinfo.io

Full IP address details for 108.177.119.94 (AS15169 Google LLC) including geolocation and map, hostname, and API details.

ipinfo.io

Let's inspect this IP on Virustotal: https://www.virustotal.com/gui/ip-address/108.177.119.94/detection

Result: The IP address is flagged as malicious detected by Xcitium

Preliminary findings
Since the IP is falsely marked as malicious by...

fredo · Apr 21, 2023

Check 4a
An empty default B4A project (without changes to the manifest),
with the libs of the source file (see "falsepostest2.zip")
was obfuscated compiled with version 12.20 64Bit
and then scanned with VT.

The result is the same as for the source file: false positive.

VirusTotal

www.virustotal.com

Next check
Remove and scan half of the libs blockwise

agraham · Apr 21, 2023

Obfuscation will probably not help with false positives. Obfuscation mangles only names but the virus checkers are looking for code patterns which obfuscation does not affect.

fredo · Apr 21, 2023

fredo said:
Next check
Remove and scan half of the libs blockwise

It is first assumed that the problem is within a lib.

In an effort to further narrow the problematic area, the lower half of the libs were removed.

Result: the false positives remained

Then these libs were removed:

firebaseanalytics
firebasenotifications
googleplaybilling
dateutils
encryption
ime

And the result had no more false positives. Everything seemed ok:

Logically, the change included "evil" libs.

As a cross check only some of the suspicious libs were activated:

firebaseanalytics
firebasenotifications
googleplaybilling
xui

The result had no false positives. Everything seemed ok:

Logically, one of these remaining libs must be bad:

dateutils
encryption
ime

They were tested seperately with unexpected results.

Only IME: "McAfee-GW-Edition: BehavesLike.Suspicious.cc"

Only DateUtils: "McAfee-GW-Edition: BehavesLike.Suspicious.cc"

Only Encryption: "McAfee-GW-Edition: BehavesLike.Suspicious.cc"

--> So none of the remaining suspects led to the problematic "Google detected"

Then it got weird.

A test only with the previously suspicious libs showed "everything ok".

An interim conclusion:

Isolating the culprit by activating libs separately in an empty project did not yield a clear result.

In particular, the last test contradicts the previous test results.

Next check
Assuming that the interfering code only arises when the lib is initialized, tests are now executed with simple lib calls.

fredo · Apr 22, 2023

fredo said:
tests are now executed with simple lib calls.

The "suspect" libs with initialization were used. The result was only "BehavesLike.Suspicious.cc".

Next check
Update of JAVA

Alain75 · Apr 22, 2023

agraham said:
Obfuscation will probably not help with false positives. Obfuscation mangles only names but the virus checkers are looking for code patterns which obfuscation does not affect.

I agree as I have the same problem with one of my 5 applications... Moreover, obfuscation deals only with strings in Process_Globals sub...

Alain75 · Apr 22, 2023

I have the same problem with one of my 5 applications I published on my google drive. I read it could be caused by a library but in my case, the only apk with problem doesn't use a library which others don't :

So I wonder what can I do...

As a workaround to enable download, I compress the file in an encrypted archive (with 7-zip) for which I give of course the password (application name in lowercase). That's not pretty of course but it stays functional...

fredo · Apr 23, 2023

fredo said:
Update of JAVA

Result: false positive ("BehavesLike.Suspicious.cc").

fredo · Apr 23, 2023

In the meantime, the contact to the company that misclassified the app could also be found:

Their answer is still pending.

fredo · Apr 23, 2023

All additional libraries (jar files used in the initial file) were uploaded separately to Virustotal.

One jar was classified by Jiangmin as "Suspect.Package.RLO"

Then the initial file was tested without TouchImagView lib.

The result was still false positive

fredo · Apr 23, 2023

New interesting twist
Since the initial investigations gave no indication of the cause of the classification, the steps taken so far have aimed to find the triggering area.

On the Virustotal results page, which evaluated the source file first, there is now additional information.

There is now a concrete reference to the violation.

B4X:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO Android Device Connectivity Check"; flow:established,to_server; urilen:13; http.method; content:"GET"; http.uri; content:"/generate_204"; fast_pattern; endswith; http.host; content:"connectivitycheck.gstatic.com"; http.accept_enc; content:"gzip"; depth:4; endswith; http.header_names; content:!"Cache"; content:!"Referer"; classtype:policy-violation; sid:2036220; rev:3; metadata:affected_product Android, attack_target Mobile_Client, created_at 2018_09_14, deployment Perimeter, deployment Internal, former_category POLICY, performance_impact Low, signature_severity Minor, tag Connectivity_Check, updated_at 2020_09_16;)

Next Step
Find and remove the affected places in the source file and check again.

fredo · Apr 23, 2023

The GET calls present in the initial file were neutralized and the app was rescanned.

Result unchanged: false positive.

fredo · Apr 23, 2023

Since no obvious location could be found in the source file, a search was performed around the contents of the "ET INFO Android Device Connectivity Check":

B4X:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO Android Device Connectivity Check";
 flow:established,to_server;
 urilen:13;
 http.method;
 content:"GET";
 http.uri;
 content:"/generate_204";
 fast_pattern;
 endswith;
 http.host;
 content:"connectivitycheck.gstatic.com";
 http.accept_enc;
 content:"gzip";
 depth:4;
 endswith;
 http.header_names;
 content:!"Cache";
 content:!"Referer";
 classtype:policy-violation;
 sid:2036220;
 rev:3;
 metadata:affected_product Android, attack_target Mobile_Client, created_at 2018_09_14, deployment Perimeter, deployment Internal, former_category POLICY, performance_impact Low, signature_severity Minor, tag Connectivity_Check, updated_at 2020_09_16;
)

The first google search for "content" "generate_204" resulted in this thread:

The URL “http://www.gstatic.com/generate_204” is opening up for no reason in Chrome

I use Chrome for browsing the web almost all the time Starting from a few days ago I have had the page http://www.gstatic.com/generate_204 open up in a new browser tab sometimes for seemingly no re...

superuser.com

The information seems to be logical and correct.

In this respect, the unobfuscated apk will be brought into a readable form by means of reenineering and relevant character strings will be searched for there.

The goal is still to find the triggering passage.

fredo · Apr 23, 2023

Another new aspect:
Since the string search in the reengeneered apk file brought nothing, the additional info on Virustotal was looked at again more closely.

On https://www.virustotal.com/gui/file...8dd33d5dce3aacd1704c49eb2d6a1a7afb2?nocache=1
the Crowdsourced IDS rules “View matches” part reveals a Destination IP: 108.177.119.94

Google!

108.177.119.94 IP Address Details - IPinfo.io

Full IP address details for 108.177.119.94 (AS15169 Google LLC) including geolocation and map, hostname, and API details.

ipinfo.io

Let's inspect this IP on Virustotal: https://www.virustotal.com/gui/ip-address/108.177.119.94/detection

Result: The IP address is flagged as malicious detected by Xcitium

Preliminary findings
Since the IP is falsely marked as malicious by Xcitium
the apk file is flagged as malicious by IKARUS.

A ticket was opened at Xcitium and IKARUS and the case was described. A response is still pending.

fredo · Apr 23, 2023

In the meantime, I wonder what part of the apk file makes a request for the affected IP.

Could this possibly have to do with connection requests around GoogleBilling or Firebase?

Sandman · Apr 23, 2023

You should be able to find that by greping the generated sources in Objects, I believe.

Alain75 · Apr 23, 2023

I had the same problem and detected with an empty application (no module, no code) and VirusTotal that the Reflection library is detected as malicious by 3 antivirus engines (Google, Avast mobile and Ikarus). I transformed my Reflection library calls (just a few happily) to JavaObject calls and I solved my problem : apk is no more detected by Google...

fredo · Apr 24, 2023

fredo said:
A ticket was opened at Xcitium and IKARUS and the case was described

Response from IKARUS after a few hours:

Dear Ladies and Gentlemen,
Many thanks for the delivered file.

***** false-positive *****

The false positive was removed and should not occur any more after our next database update.

This is an automatic generated e-mail, please do not reply.

A few more hours later, the source file was checked again with Virustotal
and is now rated OK.

So the essential approach to fix the false positive was the details information from Virustotal (as described in #14)

For now, the case seems to be closed.

However, a check of the initial problem did not yet give the all-clear.

A newly created apk file can still not be shared/downloaded from Google Drive, because the false positive is still active there.

Maybe it will take a few more days until the new status is propagated through all Google systems.

Other [solved] Investigating Google's false positive virus checks

Well-Known Member

Attachments

Well-Known Member

Attachments

Expert

Well-Known Member

Well-Known Member

Attachments

Member

Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Expert

Member

Well-Known Member

Similar Threads

Privacy & Transparency

Privacy & Transparency