Avast detects virus in ltchiptool-v4.6.0.exe
plasticbrain777 opened this issue · comments
The exe is detected as containing Win64:Evo-gen trojen. Couldnt find any other cases with quick google search.
Avast 23.8.6078 (build 23.8.8416.794)
Definition database: 231002-0
same with windows defender
Same with Bitdefender on both 4.5.1 and 4.6.
All versions show multiple malware threats on VirusTotal web site. v4.6.0 shows 25 detections, some older versions show fewer detections.
Why no reply from developers?
Here's a list:
Alibaba Trojan:Win64/Genric.c5930e79
ALYac Gen:Variant.Lazy.401408
Antiy-AVL Trojan/Win32.Caynamer
Arcabit Trojan.Lazy.D62000
Avast Win64:Evo-gen [Trj]
AVG Win64:Evo-gen [Trj]
BitDefender Gen:Variant.Lazy.401408
Bkav Pro W32.AIDetectMalware.64
Cylance Unsafe
DeepInstinct MALICIOUS
Emsisoft Gen:Variant.Lazy.401408 (B)
eScan Gen:Variant.Lazy.401408
Fortinet W32/PossibleThreat
GData Gen:Variant.Lazy.401408
Gridinsoft (no cloud) Trojan.Win64.Gen.oa!s1
Malwarebytes Malware.AI.4136543175
MAX Malware (ai Score=89)
McAfee Artemis!F6AAD6136A61
McAfee-GW-Edition Artemis
Microsoft Trojan:Win32/ScarletFlash.A
Sophos Mal/Generic-S
Trellix (FireEye) Gen:Variant.Lazy.401408
VIPRE Gen:Variant.Lazy.401408
Webroot W32.Malware.Gen
Zillya Trojan.Agent.Script.1739068
See #8.
We don't know what is causing these detections. They are obviously false-positives - the project is fully open source, you can compile it yourself if you want.
We do not have a fix for this issue. It is not planned to work on this, as it's near-impossible to find out what exactly makes the AV software classify it as malware.
See #8.
We don't know what is causing these detections. They are obviously false-positives - the project is fully open source, you can compile it yourself if you want.
We do not have a fix for this issue. It is not planned to work on this, as it's near-impossible to find out what exactly makes the AV software classify it as malware.
Re See #8: Ah yes, sorry I didn't look in the closed issues section. Thanks for that.
Still, it'll be interestion if anyone can pinpoint what exactly is causing this detection.
Sorry to say, but #8 is not a solution, really.
Just saying it's "obviously a false positive" does not make it so; what do you think makers of malware will say?
ALL versions (including 4.4.1) show multiple malware detections if tested with many checkers, as VirusTotal does.
I'm not suggesting that there IS (unfortunately I also can't say there isn't) malware in the program, just that, since it currently works good at what it's meant to do, some effort should be directed to eliminating this (in my opinion) not small problem, rather than new features.
While it may not be easy, all your future work may benefit from the effort.
Going through the source code and that of all the libraries it uses is not a solution; much as "open source" tries to make it so.
The python version did not work for me, unfortunately; but that may be my fault. Anyway, it may not be an alternative if it also doesn't work for others.
Sending your program to anti-virus companies to white-list it may be a solution; they may just do it or point you to why not which may help you fix it.
I understand your point, but I'm trying to explain that there is nothing we can do. Antivirus programs detect behavioral patterns of the software, which they may consider malicious, even if they aren't. Unfortunately, we don't know what exactly triggers the detection, and there is no way to find out - if there was, malware makers would have an easy job.
It might even be completely unrelated to ltchiptool itself, and caused by some dependency. Version 4.2.3 did NOT trigger AV software (as checked on virustotal). However, when I compiled 4.2.3 again, when 4.4.1 was the latest version and the problem appeared, this freshly compiled version was already flagged as malware. I have compared what dependencies were updated in the meantime, and checked what code differences were added (and checked GitHub issues of those projects to find similar malware detections). Nothing found.
I know that this might not be desirable for many people. You're free to use the PyPI version, checkout directly from GitHub, or even review the entire codebase to look for malware. If you're really concerned - use a virtual machine. Just know, that there is no "NOT A MALWARE" button on GitHub, and we can't fix an issue if we can never know what causes it.
Sorry, I may have been updating my post while you already replied; thank you for being so quick.
I agree that these scanner become more stupid even as they try to be smarter but I don't know if all the detections were heuristics.
I don't think "malware makers would have an easy job" if there was a way to find what triggers the detection, because they actually have to do whatever triggers the detection (encrypt your files, write to system folders, raw partitions, whatever else they do).
Anti-Virus companies do have an interest to not "false-positive", as they will be avoided if they have too many, so it's in their interest to help developers solve these problems, and have (some easy, some not so easy) mechanisms to submit files.
I only develop bare-metal FW so I don't know if, maybe, you could even submit libraries. Anyway, it looks that so far you may not have tried this path. I use avast so here is their process; I can't say it will work in your situation:
https://support.avast.com/en-ca/article/threat-lab-file-whitelist/#pc
A program like ltchiptool, should, in my opinion (I have no idea if it does much more than what I think it does), only read/write files and talk to UART; I don't know what behavior would cause malware checkers to flag it unless libraries you use may appear to do untoward stuff :-)
If it does do much more; maybe you could (please) make a "lite" version that just programs chips? Although even that might use libraries that are the culprit.
I have submitted ltchiptool to the Avast whitelist, and they have accepted it and removed false positive reputation. They say it might take some time until the changes propagate. Hopefully it will also apply to other AV software.
Chrome and Brave browser do not even allow downloading it. They just delete as dangerous!
Send the newest 4.7.0 to Avast as well for whitelisting... :/.
Hope it willl help.
Good news!
When the the actual link to the file
https://github.com/libretiny-eu/ltchiptool/releases/download/v4.7.0/ltchiptool-v4.7.0.exe
is entered at
https://www.virustotal.com
the results are nearly all virsu free meanwhile.
Thanks kuba2k2 for getting in touch with Avast et al, and your hard work!
Not sure if this helps anyone, but the file is primarily flagged because it uses crypto libraries found in many other malicious files. I will link the summary report for 4.10.1 for anyone elses perusal.
https://www.joesandbox.com/analysis/1367809/0/html
I dont see anything that would make it malicious in the report, just alot of similarities to malicious trojans / stealers / malware, because of the py crypto libraries. I am certainly not a professional malware researcher, but my job typically requires that I do some malware investigation.
Are crypto libraries needed for a chip loader tool?
"crypto" here is for cryptography, not currency. They aren't needed specifically for the flashing portion, but they are needed for the analyzing portions (like UPK2ESPhome).
I know what crypto is.
In my opinion, a flasher should just flash. Or at least there should exist a simple flasher that just flashes, even if other programs that do more may also flash.
It's also not clear to me why UPK2ESPhome needs crypto. I searched the web a bit without any results.
Then don't use it? Nobody is forcing you to. Tuya's storage partition is encrypted with cryptography. LTChipTool uses the reverse method of that to decrypt it and make it human/tool readable.
There is no need to be like that. It makes one think you don't like inquiring minds for some reason :-)
I don't think I ever said it's wrong; even if I may feel that things could be done differently; I admit I may be wrong.
I am trying to understand the reasons and help if I can. I used to write FW but at a lower level.
Getting back to the matter at hand; I thought writing a binary generated elsewhere doesn't need encryption to be flashed into a microcontroller except in high security applications, which I don't think this is.
I thought we're replacing the whole Tuya FW with new FW; in my case generated by ESPHome. Aren't we? I could be wrong.
If we are, why do we care what Tuya does? The microcontroller is not Tuya.
Or, is the ESPHome FW encrypted when flashing for some reason? Does the microcontroller require encrypted FW?
ltchiptool is a universal package used by LibreTiny - the GUI is just a part of it.
The core contains utilities for flashing the chips, as well as generating binaries from ELF files (that part is used by LibreTiny during compilation). This requires the crypto libraries, for example Beken's OTA is AES encrypted.
Tuya storage data, used by UPK2Esphome is also AES encrypted. So, even if we could get rid of the binary generation part, UPK would still require crypto.
ltchiptool is a whole toolset for dealing with the LibreTiny/tuya-cloudcutter ecosystem. We're not planning on writing separate flashing tools, because it's just easier to make plugins for ltchiptool and use its set of utilities and libraries.
And yes, we are replacing Tuya FW. But in order to have something to replace it with, we need to generate a YAML by UPK2Esphome, which needs crypto as said above.
That being said, millions of programs use cryptography for various reasons - whether it's data security, connection encryption, or even logging in or hashing. We may never know why do AV programs have issues with that. The truth is, you can write a simple, secure application using cryptography, or you can write a file-stealing malware or disk-encrypting ransomware without cryptography.
There is no need to be like that. It makes one think you don't like inquiring minds for some reason :-)
You were not inquiring, you're making blanket statements and complaining about how something open source isn't exactly as you like it.
I don't think I ever said it's wrong; even if I may feel that things could be done differently; I admit I may be wrong.
You very clearly did. You specifically said you didn't understand it, and that it should only do the simplest thing you understand of it.
I am trying to understand the reasons and help if I can.
Again, no. When explaining what things were doing, you just said it wasn't needed.
I used to write FW but at a lower level.
Then you should fully understand what cryptography is for if you've ever written anything related to security.
Getting back to the matter at hand; I thought writing a binary generated elsewhere doesn't need encryption to be flashed into a microcontroller except in high security applications, which I don't think this is.
As mentioned, this is a tool that does more than just write a binary. This tool is to help make Tuya devices function better without Tuya software, and being able to determine how Tuya configured those devices is part of that process, and decrypting the data they encrypted it also a part of that process.
I thought we're replacing the whole Tuya FW with new FW; in my case generated by ESPHome.
Yes, and to help people do that, LTChipTool is trying to help generate the most feature complete firmware it can. Not everyone knows how to write their own ESPHome configuration files. It's great if you do, but you're not every user. The majority need more than an empty non-functional base firmware.
If we are, why do we care what Tuya does? The microcontroller is not Tuya.
To make the devices functional. ESPHome doesn't magically make the device function just by placing it on a microcontroller.
Or, is the ESPHome FW encrypted when flashing for some reason? Does the microcontroller require encrypted FW?
No, ESPHome is not encrypted at the firmware level. But that doesn't mean noone needs the things included with this tool.