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

fredo

Well-Known Member
Licensed User
Longtime User
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:

21-04-_2023_10-27-01.jpg

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:
21-04-_2023_10-49-14.jpg


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.
 

Attachments

  • falsepostest1.zip
    9 KB · Views: 64
Last edited:
Solution
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
23-04-_2023_06-49-23.jpg


Google!

Let's inspect this IP on Virustotal: https://www.virustotal.com/gui/ip-address/108.177.119.94/detection
23-04-_2023_11-54-52.jpg
Result: The IP address is flagged as malicious detected by Xcitium

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

fredo

Well-Known Member
Licensed User
Longtime User
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.

21-04-_2023_11-59-59.jpg



Next check
Remove and scan half of the libs blockwise
 

Attachments

  • falsepostest2.zip
    9.2 KB · Views: 58
Upvote 0

fredo

Well-Known Member
Licensed User
Longtime User
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
21-04-_2023_12-30-17.jpg



Then these libs were removed:
  • firebaseanalytics
  • firebasenotifications
  • googleplaybilling
  • dateutils
  • encryption
  • ime
And the result had no more false positives. Everything seemed ok:
21-04-_2023_12-33-46.jpg

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:
21-04-_2023_12-37-13.jpg



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"
21-04-_2023_12-39-25.jpg

Only DateUtils: "McAfee-GW-Edition: BehavesLike.Suspicious.cc"
21-04-_2023_12-45-45.jpg

Only Encryption: "McAfee-GW-Edition: BehavesLike.Suspicious.cc"
21-04-_2023_12-49-02.jpg


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

21-04-_2023_12-58-33.jpg


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.
 
Last edited:
Upvote 0

Alain75

Member
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...
 
Upvote 0

Alain75

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

Image.jpg


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...
 
Upvote 0

fredo

Well-Known Member
Licensed User
Longtime User
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.

23-04-_2023_06-47-01.jpg

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;)

23-04-_2023_06-49-23.jpg


Next Step
Find and remove the affected places in the source file and check again.
 
Last edited:
Upvote 0

fredo

Well-Known Member
Licensed User
Longtime User
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 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.
 
Upvote 0

fredo

Well-Known Member
Licensed User
Longtime User
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
23-04-_2023_06-49-23.jpg


Google!

Let's inspect this IP on Virustotal: https://www.virustotal.com/gui/ip-address/108.177.119.94/detection
23-04-_2023_11-54-52.jpg
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.
 
Upvote 0
Solution

Alain75

Member
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...
 
Upvote 0

fredo

Well-Known Member
Licensed User
Longtime User
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.
 
Upvote 0
Top