HeatblurJester.dll Virus Warnings?

[Steve Gee]

Installed DCS on a new PC yesterday and I'm getting a virus warning on the HeatblurJester.dll file in two instances. I don't care for virus warnings.

[Raisuli]

52 minutes ago, Steve Gee said:

Installed DCS on a new PC yesterday and I'm getting a virus warning on the HeatblurJester.dll file in two instances. I don't care for virus warnings.

How's your risk tolerance? 

Either exclude that file from the scan or stop using it (and quite likely the entire module) and submit it to your virus scan vendor for analysis.  The former is quick, the latter is slow.

[Zabuzard]

17 hours ago, Steve Gee said:

Installed DCS on a new PC yesterday and I'm getting a virus warning on the HeatblurJester.dll file in two instances. I don't care for virus warnings.

The actual warning you are seeing is "potentially unwanted application" (not "virus"). You can ignore it safely.

It currently happens to most aircraft in DCS and will hopefully be soon fixed in an upcoming Windows Defender update.

[Steve Gee]

10 hours ago, Zabuzard said:

The actual warning you are seeing is "potentially unwanted application" (not "virus"). You can ignore it safely.

It currently happens to most aircraft in DCS and will hopefully be soon fixed in an upcoming Windows Defender update.

Thanks, was wondering why a new file would come up with warnings like that. I allowed the specific 3 files but not the folder, I'll take them one at a time as they come. With all the drama in DCS lately, ain't gonna open that folder up for potential unchecked shenanigans.

[GKOver]

I have made a complete repair of my DCS World installation that there are only official files being installed. And I am using this Computer only for my simulations: DCS World and Flightsimulator. For nothing else.

 

But by using windows defender I have found five !!! files which are being marked containing the trojan.mprotect.

 

Checking these files against virustotal.com showed quite dangerous results which can‘t be ignored:

Beside: the other infos on the other tabs are also not good….

Edited July 1, 2024 by GKOver

[Zabuzard]

3 hours ago, GKOver said:

Beside: the other infos on the other tabs are also not good….

These are all false positives related to how DCS packs the DLL files.

This is very common and normal on games. You also get it on any AAA game if they wouldnt announce each game patch to all AntiVir producers for explicit whitelisting before releasing the patch. Been there myself, its a super annoying process that also delays the entire patch cycle.

Edited July 1, 2024 by Zabuzard

[riojax]

On 7/1/2024 at 2:57 PM, Zabuzard said:

These are all false positives related to how DCS packs the DLL files.

This is very common and normal on games. You also get it on any AAA game if they wouldnt announce each game patch to all AntiVir producers for explicit whitelisting before releasing the patch. Been there myself, its a super annoying process that also delays the entire patch cycle.

Are you completely sure that is a false positive?

Is this your personal opinion, or is this an official Heatblur statement?

Assuming that the original code is clean, how do you know that the used packer that is closed source doesn't inject malicious code as the AV is pointing?

Would you maintain these same words on trial?

Edited July 5, 2024 by riojax

[Cobra847]

2 hours ago, riojax said:

Are you completely sure that is a false positive?

Is this your personal opinion, or is this an official Heatblur statement?

Assuming that the original code is clean, how do you know that the used packer that is closed source doesn't inject malicious code as the AV is pointing?

Would you maintain these same words on trial?

 

If you want to sue us, then do so. That's the official Heatblur statement.

Stop this nonsense, it's not productive.

If you don't trust the "closed source packer" by Eagle Dynamics then why are you running any DCS code at all on your computer!?!

Edited July 5, 2024 by Cobra847

[Rudel_chw]

9 minutes ago, Cobra847 said:

If you want to sue us, then do so. That's the official Heatblur statement.

this got to receive the "best reply of the year" award 

[MAXsenna]

this got to receive the "best reply of the year" award 

I agree!

Sent from my SM-A536B using Tapatalk

[Cobra847]

Seriously though, I get it, privacy is important, and safety of your hardware, data, computer is important. Full stop. But Heatblur Simulations does not ship malware to your computers. Period. 

Talking about some magical, hypothetical court case about us shipping malware is not productive and is just frustrating.

Why would we, Heatblur Simulations, after 11 years of working hard to build our reputation and put every single fibre of our being into our products decide to start shipping viruses or spyware to customers? To a small flight simulation niche, at that? It makes no sense. What would we possibly stand to gain?

The simple answer is that we don't, and if we do something that you guys are unhappy with, we will take steps to try and amend and fix it. 

Edited July 5, 2024 by Cobra847

[riojax]

1 hour ago, Cobra847 said:

If you want to sue us, then do so. That's the official Heatblur statement.

Right, this is a basic right; independent of whether you want it or not, I don't need your permission. But it is not very good as an official response to a client on a legit question.

 

Quote

Stop this nonsense, it's not productive.

I think that it is productive to have a good response about why a lot AV vendors are marking this software as unsafe after recent updates.

 

Quote

If you don't trust the "closed source packer" by Eagle Dynamics then why are you running any DCS code at all on your computer!?!

I don't know if it is ED who makes this packer, but my AV detects that it is VMProtect, and I do not trust on this product as equal lot AV vendors.

[Cobra847]

7 minutes ago, riojax said:

Right, this is a basic right; independent of whether you want it or not, I don't need your permission. But it is not very good as an official response to a client on a legit question.

 

I think that it is productive to have a good response about why a lot AV vendors are marking this software as unsafe after recent updates.

 

I don't know if it is ED who makes this packer, but my AV detects that it is VMProtect, and I do not trust on this product as equal lot AV vendors.

Because it turns into a frustrating defensive discussion. How can we help customers and discuss concers when the reply is "Would you say the same thing in court?"
It turns the discussion and two-way street into a simple attack vector, I don't know how we can answer such questions.

I am always happy to discuss and have responses to customers. One can ping me on Discord, or even call me (the number is on our webpage).   

During the runup to release (i.e. before the binaries were packed by ED) we also had a few false positives on our DLL's. Sometimes it's just the signature of what it does which is considered suspicious enough that it triggers the basic algorithm in the AV programs. To give you an example; for HeatblurJester, it could be because it reads the compiled .lua files in the Jester folder. The simple act of a dll getting invoked and reading files could be causing this. We also dynamically alter some of the UI code and pass through a lot of stuff between DLLs and the frontends. It might not even be VMProtect causing the false flag.

Ultimately I'm happy to explain anything we do, when or why. I get that us using CEF for UI purposes is not for everyone for example, but we can't make everyone happy with our choices.

What I can guarantee is that we will not ever intentionally ship malware to you, our customers, who are the most important thing to us at the end of the day.

I don't think Eagle Dynamics would do so either for their only, key product that ships to hundreds of thousands of customers.

Edited July 5, 2024 by Cobra847

[riojax]

12 minutes ago, Cobra847 said:

Seriously though, I get it, but talking about some magical, hypothetical court case about us shipping malware is not productive and is just frustrating.

It is also frustrating to have the same response that it is a "false positive" without any technical detail, which is why a lot AV vendors are marking this as unsafe.

 

Quote

Privacy is important, and safety of your hardware, data, computer is important. Full stop. Heatblur Simulations does not ship malware to your computers. Period.

Privacy is important, and also a basic right for EU citizens, and your product is still sending unsolicited telemetry and data to Google and other third parties as reported here (and do it with the "offline mode" selected and the DCS GDPR-compliant check marked, in a clear violation of it)

 

Quote

Why would we, Heatblur Simulations, after 11 years of working hard to build our reputation and put every single fibre of our being into our products decide to start shipping viruses or spyware to customers? To a small flight simulation niche, at that!? It makes no sense. What would we possibly stand to gain?

The simple answer is that we don't, and if we do something that you guys are unhappy with, we will take steps to try and amend and fix it. 

Fix the privacy issues to be fully GDPR-compliant, and also work on the packer problem detected by AV vendors. This is not a bug like the dozens of pages reported; the GDPR violation is a serious issue.

 

[riojax]

11 minutes ago, Cobra847 said:

  Because it turns into a frustrating defensive discussion. How can we help customers and discuss concers when the reply is "Would you say the same thing in court?"
It turns the discussion and two-way street into a simple attack vector, I don't know how we can answer such questions.

I am always happy to discuss and have responses to customers. One can ping me on Discord, or even call me (the number is on our webpage).   

I can't understand why it turns into a defensive to ask for a truthful, accurate, serious, unequivocal and firm response (as you say in court) and was not my intent; as a customer, I only want a proper research, public communication and fix.

Quote

 During the runup to release (i.e. before the binaries were packed by ED) we also had a few false positives on our DLL's. Sometimes it's just the signature of what it does which is considered suspicious enough that it triggers the basic algorithm in the AV programs. To give you an example; for HeatblurJester, it could be because it reads the compiled .lua files in the Jester folder. The simple act of a dll getting invoked and reading files could be causing this. We also dynamically alter some of the UI code and pass through a lot of stuff between DLLs and the frontends. It might not even be VMProtect causing the false flag.

Ok, if you are dealing with it, us too, and as you can understand, for us as clients to deactivate the AV is not a fix.

Quote

Ultimately I'm happy to explain anything we do, when or why. I get that us using CEF for UI purposes is not for everyone for example, but we can't make everyone happy with our choices.

Yes, but it was a nasty surprise for some. If you want to embed a web browser in a product that don't need it as a flight simulator, please, communicate it as some clients can decide to no purchase it because don't want to have it.

Quote

What I can guarantee is that we will not ever intentionally ship malware to you, our customers, who are the most important thing to us at the end of the day.

I don't think Eagle Dynamics would do so either for their only, key product that ships to hundreds of thousands of customers.

Ok, and thank you. This is an initial proper response, but it is also welcome to research what the VMProtect is doing and why AV vendors are marking it as unsecure, and finally make a proper fix that allows us to use our AV and your product at the same time.

[Cobra847]

39 minutes ago, riojax said:

It is also frustrating to have the same response that it is a "false positive" without any technical detail, which is why a lot AV vendors are marking this as unsafe.

 

Privacy is important, and also a basic right for EU citizens, and your product is still sending unsolicited telemetry and data to Google and other third parties as reported here (and do it with the "offline mode" selected and the DCS GDPR-compliant check marked, in a clear violation of it)

 

Fix the privacy issues to be fully GDPR-compliant, and also work on the packer problem detected by AV vendors. This is not a bug like the dozens of pages reported; the GDPR violation is a serious issue.

 

The current build has the remaining bug that it will try to grab the video DRM plugin from the google update API server, and that's it. It's removed in the latest build which was supposed to launch yesterday. That should be the only remaining outside communication if you have the offline tag set and if not then, yes, it is absolutely a bug.

You can firewall HBUI.exe temporarily for now if you don't want it to try and download the plugin. The rest of privacy concerns are clearly described in our privacy policy linked from the EULA and our webpage, and are further covered by setting HBUI to be fully offline. GDPR is important, but again, it's not really productive to throw it in our faces as if we're some sort of evil corporation stealing your user data and you keep banging this same drum on hoggit, dcsexposed, floggit and here. 
 

Quote

I can't understand why it turns into a defensive to ask for a truthful, accurate, serious, unequivocal and firm response (as you say in court) and was not my intent; as a customer, I only want a proper research, public communication and fix.

We're not being defensive. We're explaining. Which I think is exactly what you were hoping for?

We don't actually know ourselves why it triggers. We have 0 insight into the codebases or algorithms used by various AV programs. These are massive, mega corporations that don't exactly communicate this. The only thing we can do is to send our binaries in for "analysis" and have them whitelisted - but that's all.

Ultimately this is a relationship of trust. Either you trust Heatblur and our decade long history to not destroy your computers or hack your data - or you don't. The AV popup is somewhat secondary to that, ultimately.

The most we can do is to send our binaries and .exe's in for whitelisting, until then we can only recommend turning off AV for those specific binaries. 

 

Quote

Yes, but it was a nasty surprise for some. If you want to embed a web browser in a product that don't need it as a flight simulator, please, communicate it as some clients can decide to no purchase it because don't want to have it.

CEF is used in tons of products, that you likely use daily. BTW, it *was* explained what HBUI is in our March delay update - at which point we offered no questions asked refunds for pre-orders. And we still sort of do; including to you if you feel you want one.  

It is also your opinion that it is not needed. For us, it offers tons of new features, the ability to display the manual in-game, faster UI development, the ability to open a browser and watch tutorials, and far more. Just because you don't like it doesn't mean it doesn't come with a lot of pros. It is time for DCS to have EFBs and more advanced UI features, such as character customization. 

I think we've proven that to the point where it's going to become a standard feature in DCS, and so not only do we do all the legwork on getting the feature in and working into DCS and prove it's useful, but we also catch all the critique. Fun!


Ultimately, this discussion is somewhat like trying to defend our design and technical choices while at the same time trying to somehow explain we're not actually malicious actors. The former I can do easily, the latter you have to assign to us yourself based on our track record. Whatever I can do or discuss to help in that end, I will.
 

Edited July 5, 2024 by Cobra847

[riojax]

6 minutes ago, Cobra847 said:

It does not send unsolicited telemetry, I'm not sure where you're getting that information from. The current build has the bug that it will try to grab the video DRM plugin from the google update API server, and that's it. It's removed in the latest build which was supposed to launch yesterday.

You can firewall HBUI.exe temporarily for now if you don't want it to try and download the plugin. The rest of privacy concerns are clearly described in our privacy policy linked from the EULA and our webpage, and are covered by setting HBUI to be fully offline.

Check the bug reports, as for example, the data sent to id.google.xx is telemetry.

Quote

We're not being defensive. We're explaining. 

We don't actually know ourselves why it triggers. We have 0 insight into the codebases or algorithms used by various AV programs. These are massive, mega corporations that don't exactly communicate this sort of stuff. The only thing we can do is to send our binaries in for "analysis" and have them whitelisted - but that's all.

Ultimately this is a relationship of trust. Either you trust Heatblur and our decade long history to not destroy your computers or hack your data - or you don't. The AV popup is somewhat secondary to that.

Ok, please, next time when you see those problems that can affect the trust, make a public statement with all the research information at the moment that you have knowledge of them. It is not good for the trust to wait several weeks asking for this and only get the response that it is a "false positive" when a lot of trustworthy AV vendors say otherwise.

Quote

CEF is used in tons of products, that you likely use daily - and BTW; it was explained in our March delay update - at which point we offered no questions asked refunds for pre-orders.

It is also your opinion that it is not needed. For us, it offers tons of new features, the ability to display the manual in-game, faster UI development, the ability to open a browser and watch tutorials, and far more. Just because you don't like it doesn't mean it doesn't come with a lot of pros. 

I think we've proven that to the point where it's going to become a standard feature in DCS.

It is not a thing about likening; embedding CEF has a lot of cons too, for example, the huge RAM and CPU usage, and you demonstrated in your F-14 module that all can be made using the DCS UI except the video tutorials and the manual, which are totally optional. It would be great to have a checkbox to disable CEF and not load it on CPU and RAM, disabling the manual and browser.

[Cobra847]

11 minutes ago, riojax said:

Check the bug reports, as for example, the data sent to id.google.xx is telemetry.

Ok, please, next time when you see those problems that can affect the trust, make a public statement with all the research information at the moment that you have knowledge of them. It is not good for the trust to wait several weeks asking for this and only get the response that it is a "false positive" when a lot of trustworthy AV vendors say otherwise.

It is not a thing about likening; embedding CEF has a lot of cons too, for example, the huge RAM and CPU usage, and you demonstrated in your F-14 module that all can be made using the DCS UI except the video tutorials and the manual, which are totally optional. It would be great to have a checkbox to disable CEF and not load it on CPU and RAM, disabling the manual and browser.

Absolutely, from the otherside just keep in mind that we do things in good faith - and don't do crazy stuff just for the sake of it.

Adding CEF was not easy. We went through a lot of difficulty and trouble to try and push the bar in features; and we think we have good reasons for it. Trust me, Jester UI in v1 is hell. Adding a single menu was a total pain, not to mention the total impossibility to do things like localization or mouse interaction. 

With regards to JESTER UI; especially with the 30hz tickbox checked, CEF for JUI should not take more than 100mb VRAM (at most!) and reduce your CPU perf by 5-10% when the menu is open. When it is closed it should be fully sleeping and causing virtually no performance impact.

Edited July 5, 2024 by Cobra847

[riojax]

15 minutes ago, Cobra847 said:

Absolutely, from the otherside just keep in mind that we do things in good faith - and don't do crazy stuff just for the sake of it.

Adding CEF was not easy. We went through a lot of difficulty and trouble to try and push the bar in features; and we think we have good reasons for it. Trust me, Jester UI in v1 is hell. Adding a single menu was a total pain, not to mention the total impossibility to do things like localization or mouse interaction. 

With regards to JESTER UI; especially with the 30hz tickbox checked, CEF for JUI should not take more than 100mb VRAM (at most!) and reduce your CPU perf by 5-10% when the menu is open. When it is closed it should be fully sleeping and causing virtually no performance impact.

It is good to hear it. I want to trust HB, and optimizing the JUI is a good way to do it, but don't forget to make an active open communication, fix all privacy/network issues, AV detection, and all other dozens of bug reports like the radar performance and the actual jester skill.

Edited July 5, 2024 by riojax

[BJ55]

2 hours ago, riojax said:

trustworthy AV vendors

I can say a lot about my lost trust in some of those vendors, since they bricked our workstations multiple times... (ESET is OK'ish if configured properly)

VMProtect has 2 big issues right now: it's from a Russian company, US megacorporations want global dominance, and since 2022 source code leaks it's being used to spread malware, the files you recieve from ED updater are safe, but if your system is already compromised every payload you recive from the net could be infected.

CEF: the only network request i've logged with offline mode is update.google, but I've also disabled Quic, so if it's trying to use UDP it goes nowhere. Add a line to hosts file and you're ready to go, no more ping to and data slurping from EvilCorp™.

Edited July 5, 2024 by BJ55

[IronMike]

5 minutes ago, BJ55 said:

CEF: the only network request i've logged with offline mode is update.google, but I've also disabled Quic, so if it's trying to use UDP it goes nowhere. Add a line to hosts file and you're ready to go, no more ping to and data slurping from EvilCorp™.

This has already been fixed for the upcoming patch.

[Schmidtfire]

I have friends that has completely uninstalled DCS to be on the safe side until the warning issues has been resolved. To be fair, It was not only Heatblur products but also
warnings from another 3rd party.

Im 100% sure that there are nothing malicious going on, but there are other players who takes the warnings very seriously these days. It really needs to be fixed as soon as possible.

[MAXsenna]

I have friends that has completely uninstalled DCS to be on the safe side until the warning issues has been resolved. To be fair, It was not only Heatblur products but also
warnings from another 3rd party.

Im 100% sure that there are nothing malicious going on, but there are other players who takes the warnings very seriously these days. It really needs to be fixed as soon as possible.

Depends on what you put into by "fixed" and by "whom" I guess.

Sent from my SM-A536B using Tapatalk

[Hiob]

1 hour ago, Schmidtfire said:

I have friends that has completely uninstalled DCS to be on the safe side until the warning issues has been resolved. To be fair, It was not only Heatblur products but also
warnings from another 3rd party.

Im 100% sure that there are nothing malicious going on, but there are other players who takes the warnings very seriously these days. It really needs to be fixed as soon as possible.

Problem is that the issue lays with the AVs giving falls positives and not first and foremost with the software developers.

And uninstalling DCS about some false positive AV alarms is just….. well, an overreaction.

[MAXsenna]

Problem is that the issue lays with the AVs giving falls positives and not first and foremost with the software developers.
And uninstalling DCS about some false positive AV alarms is just….. well, an overreaction.

In this day and age best practice is to do whatever you do on the Internet on a VM which you snapshot every day anyways.

Sent from my SM-A536B using Tapatalk