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

[fredo]

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

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

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]

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

VirusTotal

www.virustotal.com

Next check
Remove and scan half of the libs blockwise

 

[agraham]

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]

Next check
Remove and scan half of the libs blockwise

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

Spoiler: The details

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]

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]

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]

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]

Update of JAVA

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

 

[fredo]

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



Their answer is still pending.

 

[fredo]

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]

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.

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]

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

Result unchanged: false positive.

 

[fredo]

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":

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]

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

Spoiler: IP is owned by...

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]

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]

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

 

[Alain75]

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]

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.