brunodev85
Major Trojan detects ....
Ran 10.1 through a file checker and it set off many alerts.... (Edit all I did was post to show what I got from a virus test because people have the right to post about it and get answers for it and y'all losers attack me over it LMFAO)
Is it from the official source? People with much free time can build fake reports to destroy the emulator reputation.
Please close this issue.
Why do yall keep sending issues about viruses ? Do u have amnesia?, it's always , "i ran winlator through virustotal and found viruses", im pretty sure yall mental illness, there isn't any virus those are fake positives, they don't affect your phone
imma be honest my phone notifies me that it's a risky app despite it being downloaded from official source, tho I double check to make sure it's safe lol As I know, 10.0 had no issues with it, until 10.1 hotfix was introduced which causes false positives soo, yea
Reading the comments here, I got curious and tested both v10 and v10.1 - downloaded from GitHub -, then I put the results side by side:
| Tool | Report for v10 | Report for v10.1 |
|---|---|---|
| AhnLab-V3 | PUP/Android.Win32Agent.1297059 | PUP/Android.Win32Agent.1303141 |
| Avast-Mobile | APK:RepMalware [PUP] | Android:Evo-gen [Trj] |
| BitDefenderFalx | - | Android.Riskware.Agent.aMAA |
| Emsisoft | - | Gen:Variant.Trojan.Ppoly.5 (B) |
| Fortinet | - | W32/PossibleThreat |
| Ikarus | Trojan.Win32.Agent | Trojan.Dropper |
| Lionic | - | Trojan.AndroidOS.Generic.C!c |
| Symantec Mobile Insight | AppRisk:Generisk | AppRisk:Generisk |
| Trustlook | - | Android.Malware.General |
| VIPRE | - | Gen:Variant.Trojan.Ppoly.5 |
- The SHA256 hash for the file offered on GitHub matches the one on VirusTotal - included in the screenshot. So I can confirm that files officially distributed here were uploaded for testing, no one made that up.
- As an aging sysadmin, I've see plenty of false positives in my life, even for software I wrote and compiled myself on a clean machine. At the same time, I learned to pay attention and ask questions whenever possible, or avoid risk.
- This is something that should be handled officially, there's no point in belittling someone's report, especially when it's so easy to check for yourselves. It's entirely fair to raise concerns and ask for clarification.
So to the developer(s), can you please look into this, and let people know what to make of it? Thanks.
Since I didn't expect this report to be a duplicate, I didn't look for others. However, there are quite a few.
Related issues: #1411, #1406, #1246, #1178, #1102.
I also noticed issue #1196, with @Hnoodhlite claiming to speak on the behalf of the creator of this project - @brunodev85 -, but brunodev85 has not confirmed/authenticated that message in any way. So I went back even further and found issue #963, also from @Hnoodhlite. That issue was pinned by brunodev85 for 2 days, then unpinned, without a single comment about anything, which doesn't help.
I managed online communities while also being a developer for those platforms, and I know that it's quite easy to get overwhelmed with the activity, even when there's no negative feedback at all. The fact that there are dislikes here, to mere concerns, should tell you that you're overreacting and adding negativity for no good reason.
If you want to help, stop being negative about this topic and mention where these concerns have been previously discussed. Link to PcMacsterRace's investigation instead of poking at people or calling them mentally ill. Accept the fact that most people don't go back pages and pages of issues to check for all related discussions.
False positives are a thing, but so is malware. Respect people's concerns.
@kneekoo I know that I have spoken on behalf of @brunodev85 before, and I understand that most of what I said did not come directly from him. As someone who cares about the Winlator project, I only tried to help, even if sometimes I caused confusion or annoyed the developer.
I truly admire the work of brunodev85 and I have never doubted him for a moment. If I caused any problems, I sincerely apologize. My intention has always been to support the project and help keep the community organized.
And to those who keep spreading doubts and accusing the developer of including malware: nobody is forcing you to use Winlator. If you don’t trust it, remove it and use something else — but stop attacking the developer’s credibility without proof.
There are many developers who use Winlator, fork it, and contribute to its development. All of them know the source code of the emulator. If there was any malicious software inside, they would have raised the alarm immediately.
It is not my problem if someone chooses to remain ignorant. There are thousands of users of Winlator, and they are not fools.
Hello @kneekoo, I'm the Winlator developer, I don't know if you observed and analyzed in depth, but VirusTotal points the virus checks to the rootfs.xz file, in this file reside all the GLIBC binaries and libraries for the system to work correctly, this file is compressed in XZ (level 9) I've already done some tests by uncompressing the file and compressing it again in other formats like ZIP and VirusTotal signaled differently.
Piping in to mention:
ALL DETECTIONS ABOVE ARE HEURISTIC What does that mean? It means the Scanner did not neccessarily detect an explicit piece of Malware, but has detected enough "suspiciousness" to tip an Alarm. "Trojan.PPoly.5", in this case, is what i assume to be the model used.
WHY DOES WINLATOR TRIGGER HEURISTIC DETECTION? Well, it's quite simple. Winlator comes with not one, but two entire Operating Systems, including .dlls, fonts, .nls files, a custom kernel, AAAAAAANNNNNND drumroll a cross-system translation layer that INTERCEPTS ASSEMBLY-LEVEL CALLS. Of course, it does this to bridge the gap between x64 and ARM Architecture, but these heuristic algorithms DO NOT KNOW THIS. They do not analyze behavior, they match patterns and detect frequent infection vector files, such as system .dll files.
From a computing perspective, Winlator is essentially Frankenstein's Monster, patched together from multiple generations of software. Even the most advanced heuristics analysis Software is probably gonna be stumped when analyzing the Architecture, and thus won't be able to identify that all the "suspicious" files are actually in exactly the places they would be in a Linux Kernel or a Windows install.
Other detections simply state "PUP" which stands for "Potentially Unwanted Program" which is usually used to protect against Adware and the like- grandma's Internet Explorer Toolbars. Some particularly "enthusiastic" scanners will simply flag any program they do not recognize as PUPs.
Edit: Other detections include a "Riskware" trigger, so here's a desription of what is considered "Riskware", straight from Malwarebytes (https://www.malwarebytes.com/blog/detections/riskware-agent): "Riskware in general is a detection for items that are not strictly malicious, but pose some sort of risk for the user in another way. Some riskware tools can only be obtained at sites of a shady nature."
I assume the flagging as Riskware is due to A: The size and complexity of the App, and B: The presence of kernel pieces which interact with hardware
Both of which would pose a significant risk and would set off alarms for myself as well, were it not for the fact that, again, you are literally installing 2-2.5 Operating Systems worth of highly complex, low-level programming.
EDIT 2: Of course, this does not remove the need to look into these detections or ensure proper procedure, but filtering out disproportionate heuristic detection will significantly improve the quality of detections we DO get.
It is not my problem if someone chooses to remain ignorant. There are thousands of users of Winlator, and they are not fools.
The number of users is irrelevant - lots of people don't have anti-malware that would warn them in the first place, some people don't pay attention to warnings, and some take risks either way. So assessing the safety of any software by the number of its users is meaningless. If we choose to go by that reasoning, Windows is perfectly safe. 😁
@brunodev85 thanks a lot for looking into this, that's much appreciated. I did go deeper into this, though only partially yet. I'll look at opt/wine/lib/wine/i386-windows later.
Thanks to PcMacsterRace's investigation, I could take a few shortcuts but I double-checked everything anyway.
- I downloaded v10.1 and removed
rootfs.txzfrom it. - I uploaded the resulting archive to VirusTotal and there were no red flags at all.
- I uploaded the extracted
rootfs.txzto VirusTotal and that file got 12 red flags. - Only 4 directories in
rootfs.txzhave data, and I can independently confirm that the problem is strictly underopt:
| Directory | VirusTotal result |
|---|---|
| etc | safe |
| opt | red flags |
| usr | safe |
| var | safe |
- Then I isolated
opt/wine/lib/wine/i386-windowsand tested the remaining files underopt. However, that still triggered three red flags:
| File in v10.1 | Size |
|---|---|
| lib/wine/x86_64-windows/apisetschema.dll | 69632 bytes |
| lib/wine/x86_64-windows/rundll32.exe | 36864 bytes |
| lib/wine/x86_64-windows/opcservices.dll | 122800 bytes |
A major red flag was a combination of details about opcservices.dll - it's listed on the Relations page as being detected, but when you click its name or hash, you're redirected to a page having details about a file called xvkgcp.exe with the same file size and SHA-256 hash. This is like an executable file was renamed as a dll - typically a sign of malware.
When I scanned apisetschema.dll from my Wine-staging installation (coming directly from WineHQ) having a file of identical size, my file didn't trigger any warning. That looked like a great sign because it seemed like you probably sourced your Wine files from a place that somehow got compromised. But then...
When I scanned my local copy of rundll32.exe, it's identical to the one in v10.1 and the report is obviously identical. So this is now worth investigating with WineHQ. I'll try to get more info on this, and come back.
Thanks again for your reply.
A major red flag was a combination of details about
opcservices.dll- it's listed on the Relations page as being detected, but when you click its name or hash, you're redirected to a page having details about a file calledxvkgcp.exewith the same file size and SHA-256 hash. This is like an executable file was renamed as a dll - typically a sign of malware.When I scanned
apisetschema.dllfrom my Wine-staging installation (coming directly from WineHQ) having a file of identical size, my file didn't trigger any warning. That looked like a great sign because it seemed like you probably sourced your Wine files from a place that somehow got compromised. But then...When I scanned my local copy of
rundll32.exe, it's identical to the one in v10.1 and the report is obviously identical. So this is now worth investigating with WineHQ. I'll try to get more info on this, and come back.
Is it possible that you aquired the local rundll32.exe from the same place as Bruno? Also, could you share your detection, ideally both the "clean" and "compromised" detections? Edit: My bad, missed those Links. Edit 2: Check the "Execution Parents" for your clean apisteschema.dll in the Relations tab. Lots of detections there, checking to see if they are concrete or probablistic/heuristic. Edit 3: Seems most of them were Heuristic. Some, though were most definitely not, with concrete detections.
For rundll32.exe (0bf5c91a06574805c25364eb73943c9e8a5f9bf1fa4fd94fb1ffb014bd873c8f) We've got a detection for Bumblebee Loader within CAPE Sandbox, although other Sandboxes "only" report suspicious behavior, this could be due to sophisticated anti-sandbox measures.
What this specific thing appears to be doing (on a surface level) is checking both windows update and digicert for invalid certificates. I don't think rundll32 is supposed to do that, i just can't think of any reason why a malware loader would need a list of expired/invalid certs.
I think the best course of action would be to contact WineHQ, if you got the files from there, and send your sample in for Binary Analysis with some specialists.
Yeah, no, sadly, we probably got Malware. Looks like rundll32.exe may execute apisetschema.dll, which then links to these three wonderful sites:
http://ecs-office.s-0005.dual-s-msedge.net/ http://s-0005.dual-s-dc-msedge.net/ http://shed.s-0005.dual-s-dc-msedge.net/
If we look at them, what do we see? A plaintext base64 encoded string on each one, masquerading as an error code. I haven't quite decoded them yet, so they could be mundane, but let's be honest- no mundane program contacts those suspicious-ass domains with Base64 on them.
So, until we know more, i recommend SWIFTLY ejecting these particular three files from the Repo. Keep your samples, though. @brunodev85 @kneekoo
EDIT: I jumped the gun, AGAIN. Those URLs are probably "Front Door" DNS Zones for Microsoft Edge. I wouldn't consider this a disqualifying factor, they could still host Malware, especially since we don't know if they actually are, or may be some form of host service.
EDIT 2: This Behavior stood out to me: Files written \Device\ConDrv\Connect ->command line: C:\Windows\System32\cmd.exe cmd.exe /C rundll32.exe "C:\Users\user\Desktop\readme.dll",#1 (Note the passed Argument, "#1") ->parent command line: C:\Windows\System32\loaddll64.exe loaddll64.exe "C:\Users\user\Desktop\readme.dll"
Dunno about you guys, but "readme.dll" does not strike me as particularly trustworthy.
Ok, I looked at opt/wine/lib/wine/i386-windows and a lot of files triggered red flags.
| Detections | File |
|---|---|
| 18 / 72 | i386-windows/cards.dll |
| 10 / 71 | i386-windows/dllhost.exe |
| 7 / 72 | i386-windows/services.exe |
| 6 / 72 | i386-windows/presentationfontcache.exe |
| 5 / 72 | i386-windows/cscript.exe |
| 5 / 72 | i386-windows/sc.exe |
| 4 / 72 | i386-windows/aspnet_regiis.exe |
| 4 / 72 | i386-windows/attrib.exe |
| 4 / 71 | i386-windows/msinfo32.exe |
| 3 / 72 | i386-windows/arp.exe |
| 3 / 72 | i386-windows/cacls.exe |
| 3 / 72 | i386-windows/certutil.exe |
| 3 / 72 | i386-windows/chcp.com |
| 3 / 69 | i386-windows/control.exe |
| 3 / 72 | i386-windows/fc.exe |
| 3 / 72 | i386-windows/regsvcs.exe |
| 3 / 70 | i386-windows/wmplayer.exe |
| 3 / 71 | i386-windows/msidb.exe |
| 2 / 72 | i386-windows/clock.exe |
| 2 / 72 | i386-windows/cmd.exe |
| 2 / 71 | i386-windows/conhost.exe |
| 2 / 72 | i386-windows/klist.exe |
| 2 / 71 | i386-windows/whoami.exe |
| 2 / 72 | i386-windows/findstr.exe |
| 2 / 71 | i386-windows/reg.exe |
| 2 / 72 | i386-windows/secedit.exe |
| 1 / 72 | i386-windows/cabarc.exe |
| 1 / 71 | i386-windows/credui.dll |
| 1 / 71 | i386-windows/dism.exe |
| 1 / 67 | i386-windows/plugplay.exe |
| 1 / 71 | i386-windows/mtxdm.dll |
| 1 / 72 | i386-windows/taskmgr.exe |
Since they're quite a few, I decided to not go down the rabbit hole for each, and rather wait for @brunodev85 to drop by with another comment. Just in case the Wine files weren't sourced directly from WineHQ, it's worth looking at getting them from them, and that will probably reduce the number of files detected as malware. At least in the case of apisetschema.dll it may be the case that using WineHQ guarantees a clean copy. Not sure about all the others, but maybe you can take a look, @T1MM5H. Thanks a lot for your help so far.
I re-scanned the file and a lot more raised red flags.
For example, dllhost.exe behavior is unexpected for Wine, since they're not supposed to use Google products:
Files opened \crashpad_476_IXAVNCEEEZLPNXQF
Files dropped C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0 C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\Crashpad C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\Crashpad\attachments C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\Crashpad\metadata C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\Crashpad\reports C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\uninstall.cmd C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\updater.exe C:\Program Files\Google476_1374201312
attrib.exe also has an unexplained behavior (it should never do internet-related tasks):
Files opened \crashpad_3768_EEWUABURIDTTRQUO C:\Users<USER>\Downloads\
Files dropped C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0 C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\Crashpad C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\Crashpad\attachments C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\Crashpad\metadata C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\Crashpad\reports C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\uninstall.cmd C:\Program Files (x86)\Google\GoogleUpdater\140.0.7273.0\updater.exe C:\Program Files\Google3768_212736379
Continuing to find alarming behavior in this Report.
It runs multiple instances of the same, suspicious dlls, including by cmd proxy, and, as a cherry on top, it apparently kills the Windows Error Reporting service (though this may have been a feature of the Sandbox).
Weirdly enough, the CAPE Sandbox states the following processes were ran:
C:\Users\Bruno\Desktop\library.dll.manifest
C:\Users\Bruno\Desktop\library.dll
C:\Users\Bruno\Desktop\library.dll.123.Manifest
C:\Users\Bruno\Desktop\library.dll.124.Manifest
C:\Users\Bruno\Desktop\library.dll.2.Manifest
C:\Windows\System32\rundll32.exe
So unless, by sheer coincidence, the Sandbox "User" was named Bruno as well, i think we might have a case of a second-order payload that's been trained on @brunodev85s filesystem already. Perhaps this could indicate a coordinated attack on Winlator as a Project.
For example, dllhost.exe [behavior](https://www.virustotal.com/gui/file/> ba15856db706cdd987946032d1c8cf496486409d14f0b930b0d49327745fbdc1/behavior) is unexpected for Wine, since they're not supposed to use Google products:
Noticed that as well. Methinks that's probably another loader, or perhaps a payload. Note how they open files meant to look like directories, starting with a forward slash? I'm not familiar with Crashpad, but i'm fairly certain it's executable does not look like that. I smell more obfuscation.
Wow, look at chcp.com's behavior:
// this actually happens with others, including attrib.exe
Processes created "C:\Users<USER>\Desktop\software.exe" %SAMPLEPATH%\96f2a1e346e26b099571a86cc8200b3b1a9630ad5c4282b1f0b922f71c3805b9.exe C:\Program Files\Google4024_648137603\bin\updater.exe C:\Windows\System32\UI0Detect.exe
Shell commands %SAMPLEPATH% "%SAMPLEPATH%\96f2a1e346e26b099571a86cc8200b3b1a9630ad5c4282b1f0b922f71c3805b9.exe" "C:\Program Files\Google4024_648137603\bin\updater.exe" --update --system --enable-logging --vmodule=/chrome/updater/=2 /sessionid {93DE96A9-A4B7-4DB2-B691-EB611FDDD995} C:\Windows\system32\UI0Detect.exe
Processes injected %SAMPLEPATH%\96f2a1e346e26b099571a86cc8200b3b1a9630ad5c4282b1f0b922f71c3805b9.exe C:\Program Files\Google4024_648137603\bin\updater.exe
Processes terminated %SAMPLEPATH% %SAMPLEPATH%\96f2a1e346e26b099571a86cc8200b3b1a9630ad5c4282b1f0b922f71c3805b9.exe C:\Program Files\Google4024_648137603\bin\updater.exe C:\Windows\System32\UI0Detect.exe C:\Windows\System32\conhost.exe
It looks like malware to me.
I'm going to stop for today, but this is highly concerning. Bumblebee Loader is apparently very sophisticated in terms of Obfuscation and Anti-Sandboxing. I'm sorry to say, but i've high confidence that the above mentioned directory carries malware. @brunodev85 you may also want to verify that your machine is not compromised, considering the earlier-mentioned attempts by the Loader to work on the C:/Users/Bruno/ directory.
i think the only way is deleting the rootfs guys 😭😭 the virus is hacking my phone and the hackers changed my pasaword on my roblox acount 😔😭😭😭😭😭😱💔💦💦
Processes injected %SAMPLEPATH%\96f2a1e346e26b099571a86cc8200b3b1a9630ad5c4282b1f0b922f71c3805b9.exe C:\Program Files\Google4024_648137603\bin\updater.exe
OH BOY 🫠
i think the only way is deleting the rootfs guys 😭😭 the virus is hacking my phone and the hackers changed my pasaword on my roblox acount 😔😭😭😭😭😭😱💔💦💦
A: We cannot say that with confidence, as we lack information on the payload. B: It's unlikely that a Trojan inside the installation would have access to your phone's OS, except under absurdly specific circumstances. It was likely another piece of malware or a phish that caused your specific damage... ...unless my suspicion is correct and someone has specifically targeted Winlator in order to deploy Malware from Linux/Wine to Android, which would be a pretty impressive feat. Your report is appreciated, but without technical details, it's not really that useful at this stage.
A major red flag was a combination of details about opcservices.dll - it's listed on the Relations page as being detected, but when you click its name or hash, you're redirected to a page having details about a file called xvkgcp.exe with the same file size and SHA-256 hash. This is like an executable file was renamed as a dll - typically a sign of malware.
You were right. The sampled opcservices.dll is a re-named xvkgcp.exe. It's got 11 section headers, whereas OpcServices.dll (according to this site) is supposed to have six.
The .text section is supposed to be 1,336,320 bytes at 0x1000, in the sample it's 65,536 bytes at 0x4096. At least we know where to start with Binary analysis, eh?
EDIT: Report states that this file contains a resource named "WINE_REGISTRY" (d9a3f8e61df1cbf35d337fb62944da52e83347c735cc1e74dc13c3d1fccbf646). So, either we've just stumbled upon some sort of forbidden tech magic that the folks over at Wine devised, or we're dealing with Wine-specific malware. I am hoping to Christ it's the former, because if it's the latter, my little crackpot theory about this being a Winlator-targeted payload is gaining credibility.
@kneekoo Tagging you for latest update on my last post, RE: Wine_Registry inclusion.
Even if I ignore everything else and only care about attrib.exe and chcp.com, the fact that 2 old MS-DOS utilities touch the network is reason enough to decide that the Wine package is compromised. And the way they touch the network is also mind-boggling. Wine needs to be sourced from somewhere else.
In Summary we've got: One Semi-Confirmed Loader using compromised .dlls (Likely Bumblebee) At least three probable payloads, two masquerading as Chrome Updater Crashpad with dll sideloading, and one "/desktop/readme.dll" installer+cmdlet.
In fairness, these could also be one obfuscated payload. Anyone here got white-hat friends, perchance?
Confirmed a delivery or extraction mechanism. Cards.dll, quite ingeniously, appears to change where Windows Errors are written to (both for HKEY_LOCAL_MACHINE and HKEY_USER), then sets a Registry Key inside the Root Certificates store to a payload containing the a Registry Key for enabling something called Goproxy, or an URL to install it- i'm still analyzing the Binary.
It's possible it either dumps credentials into this file utilizing WER, as i described it messing with that Service earlier, or hijacks Windows Error Reporting to deliver it's payload or extract credentials.
Observe "Registry Key Set"
Edit: This could also be prepwork for extraction or injection, by creating a Root Certificate to fool Windows' Internal Networking components into Trusting a specific or general GoProxy domain.