unable to load ExcelDna.ManagedHost

[bpie...@gmail.com]

This error appears on a single machine:  

The ExcelDna.ManagedHost assembly could not be loaded from source

The error code given is 0x15470D70, which oddly I cannot find by Googling.

This happened using 1.6.0-rc1, but everything had worked fine and it suddenly started happening for the user without any change to the add-in. I'm guessing it's related to some virus definition update or change in some security policy, but I figured worth seeing if anybody knows a potential cause. I am going to rebuild with the 1.6 release to see if that makes any difference.

As always, thanks to Govert for this amazing tool. I just signed on as a Github sponsor (long overdue), and I encourage others to do the same to support this fantastic resource.

Brian

[Govert van Drimmelen]

Hi Brian,

 

Thank you very much for signing up to support the Excel-DNA project on GitHub Sponsors!

 

Which runtime are you targeting with the add-in: .NET Framework or .NET 6?

That makes a difference to how the ExcelDna.ManagedHost.dll is loaded.

• For .NET Framework it is extracted from the embedded resource into memory, and loaded from there into the .NET AppDomain.
• For .NET 6 the file is extracted to a temp directory and loaded from the physical file.

 

I think the .NET 6 approach is more fragile, because an anti-virus or similar might block the file when it is written, or delete it before it can be loaded used.

 

You might also check whether you can update the .NET installation – I guess something can go wrong there as well.

 

There is now an option with Excel-DNA v 1.6.0 to make a completely ‘unpacked’ add-in, where all the assemblies are external to the .xll file.

For this you add a property to the project file:

    <ExcelDnaUnpack>true</ExcelDnaUnpack>

 

The result will be a version of the add-in in the publish directory where everything (including the Excel-DNA support assemblies like ExcelDna.ManagedHost.dll) is unpacked.

You can test on your problem computer with the files in this directory – it eliminates both the in-memory extraction of the resource, and the file copy to a temp directory.

So you should find that any anti-virus problem is already shown when you copy the files to a local directory.

 

The only other thought is to look in the Windows event logs for anything suspicious around the time you are trying to load the add-in.

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/9b3d02ca-5cb3-4418-bfdc-7fdf4078c95cn%40googlegroups.com.

[bpier...@gmail.com]

It's targeting .NET Framework. I'll ask them to check the Windows event logs, and also to check their .NET installation. If all else fails, it's easy enough to give them a version with everything unpacked. Thanks!

[bpier...@gmail.com]

I don't yet have word on whether the user is ok, but it may be more than a coincidence that ExcelDna.ManagedHost.dll is flagged on virustotal.com as suspicious (only ESET-NOD32, which says "A Variant Of MSIL/Packed.ExcelDna.A Suspicious"). I've tried re-building myself, but no yet in removing that flag. Welcome to any suggestions for how to build it so it looks sufficiently different.

Strangely, I can rebuild the packed ExcelDna and that isn't flagged. Well, if I enable every possible build optimization (I use VS 2022) then most of the warnings go away, and if I then sign it the remaining few go away ...even though, as far as I can tell, the embedded ExcelDna.ManagedHost.dll is still problematic.

Brian

[Govert van Drimmelen]

Hi Brian,

 

I suggest you report the false positive to ESET.

As I recall they are particularly helpful and responsive.

 

-Govert

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/8493d904-2e56-4ddb-9ef3-758bfb0bbd1an%40googlegroups.com.

[bpier...@gmail.com]

Just sent an email reporting the false positive now per the instructions on their Web site.

[bpier...@gmail.com]

Don't mind all my deletes. Just cleaning up typos (need more coffee).

ESET responded saying encryption of an embedded executable was the problem (full response and my reply below). I'll review the code to see where this may be happening in ExcelDna.ManagedHost.dll and attempt to build it without that to see if it helps. Happy to receive any advice if you know where I should look to do that quickly. Thanks again.

Here is the response from ESET...

Thank you for your submission.

ExcelDna is extremely abused by threat actors. And some security products started to make false positives, it means - detect also not malicious add-ins.
But ESET products were able to extract and scan the content of the embedded executables, and detect only malicious ones.

In the latest ExcelDna version the author made decision to outsmart heuristics(?) and add additional encryption for embedded executables (which HAVE TO be scanned to know if given object is malicious or not).
ESET products detect add-ins from this version as suspicious applications. The classification is correct.

Regards,
ESET Malware Response Team

I replied...

Thank you for the quick response. The false positive I am reporting is not for the ExcelDna add-in as a whole, it is for one of the individual dll files in it: ExcelDna.ManagedHost.dll. Possibly this is the component that has the encrypted executable you are referring to. I'm not sure what changes the author has made recently, but I'm sure he was attempting to avoid false positives that have been disruptive for his many legitimate users. If he were to remove that additional layer of encryption, would the ExcelDna.ManagedHost.dll library then be flagged as safe?

Thanks again

[Govert van Drimmelen]

Hi Brian,

 

That’s a very useful response – thank you very much.

 

They are correct that for v1.6 I’ve added an encoding to the packed assembly files to avoid some of the trouble, and that might make it harder for ESET to scan the internal assemblies in an add-in. There was a user contribution to add an option to leave the embedded assemblies uncompressed, but the implementation of my encoding clashes, so there is no option to make a completely transparent packed .xll, where the internal assemblies can then be scanned. We will add such an option for a point release – I think it will be a useful option, though I’ll probably not make it the default for now.

 

The unpacked ExcelDna.ManagedHost.dll file is itself not obfuscated or encoded, so you are right that detecting this individual file might give the wrong impression. But it might just be that this is the mechanism NOD32 uses to block the add-in / all add-ins using the Excel-DNA version from loading.

 

There response here is the most helpful I’ve seen from a security vendor. I’m happy to help then work towards a safe option. For now my best plan is to implement the ‘transparent and uncompressed packing’ option in addition to the existing ‘ExcelDnaUnpack’ option where there are no assemblies packed or encoded in any way. You can track the ‘transparent and uncompressed packing’ option with this issue: Change `ExcelDnaPackCompressResources: false` to also remove encoding and not compress all assemblies · Issue #513 · Excel-DNA/ExcelDna (github.com)

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/499cdc72-e0af-4e12-8c26-7db6e47f8d99n%40googlegroups.com.

[bpier...@gmail.com]

Thanks Govert. I'll be glad to try that point release whenever it is available. Below is their follow-up to my response, which seems to confirm what you stated -- that they are using that dll as a mechanism to detect the version:

From ESET:

Yes, the detection targets only one component, which is responsible for handling decryption and decompression of embeeded files.
Detecting ExcelDNA project was not and is not our goal, we were forced to do it because of author decission.

Previous version was and is not detected, and we hope we will be able to not detect also next version.

Regards,

ESET Malware Response Team

[Govert van Drimmelen]

Hi Brian,

I've now pushed Excel-DNA version 1.61.-alpha3 to NuGet.

This version does no encoding or compression of the assemblies when packed - everything is transparent.

I wonder if you could give this version a try in your environment.

-Govert

[bpier...@gmail.com]

Hi Govert,

When I build with this, virustotal.com reports that ESET still flags it the same way. When I build unpacked, I can see that it's still because ExcelDna.ManagedHost.dll is being flagged. So I suspect it will still be flagged on the production machine.

I'm not sure exactly how ESET works -- are they smart enough to not detect that dll as problematic if packed in a newer version of ExcelDna? Or maybe something about that dll needs to be changed enough so that it looks different to ESET, and then with the changes the changed version would not be re-flagged by them?

Brian

[Govert van Drimmelen]

Hi Brian,

 

Maybe you can ask them about this version.

I’m happy to cooperate and make other changes they might suggest to you.

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/7188a842-1c1c-409d-b039-36c52b9c4bfbn%40googlegroups.com.

[bpier...@gmail.com]

I sent an email asking them what needs to be done for it to be considered safe -- will post any response I receive here.

[bpier...@gmail.com]

Just now received the response below. I'll provide him that  ExcelDna.ManagedHost assembly that is still being flagged, but it seems they may not be satisfied until encryption code is actually removed (?!).

Thank you for your submission.

The code responsible for encryption is still present in binaries stored on github..
Please provide us the file which you believe is cleaned from unnecessary remnants and is still detected.

Regards,

ESET Malware Response Team

[Govert van Drimmelen]

Hi Brian,

I think I understand what they are looking at. In the repository I also have the binary add-ins in the Distribution directory, but I see for the 1.6.1-alpha3 version I did not push those to GitHub.

I will make another pre-release version in the next few days (1.6.1-alpha4) and will make sure to push the binaries too.

-Govert

[bpier...@gmail.com]

Sounds good. I'll hold off on responding until that is posted to confirm I still see the issue with alpha4, and if so will send them the file along with the note that GitHub has been updated.

Brian

[Govert van Drimmelen]

OK - I've published version 1.6.1-alpha4 to NuGet, and also pushed the binaries to the GitHub repository.

This version has no encoding or compression of the packed assemblies.

-Govert

[bpier...@gmail.com]

Hi Govert -- it's still only showing alpha3 available for ExcelDna.AddIn in NuGet (VisualStudio 2022 if it matters). The other components ...Integration, Intellisense and Registration... show alpha4 available.

Brian

[Govert van Drimmelen]

It sometimes takes a few hours – I suspect it also triggers some checking there.

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/575441ff-3e56-45ac-8fbe-97de19388268n%40googlegroups.com.

[bpier...@gmail.com]

Still only alpha3 available for ExcelDna.AddIn. Maybe it failed some check on their side?

[Govert van Drimmelen]

On my machine the new binaries have overnight been detected as a threat by Windows security.

I guess the new 'transparent' approach is now so different from the previous version (which was allowed by Microsoft), that we're back to square one with them.

I've tried to report these new binaries as false positives - we'll see what happens.

On NuGet I only see that the package is still 'Validating' after 20 hours.

-Govert

[bpier...@gmail.com]

I noticed that alpha5 is now posted. I rebuilt with that, confirmed the same flag on VirusTotal, and sent a response with details to ESET. Will revert once I have any update from them.

Brian

[bpier...@gmail.com]

Response from ESET:

Thank you for your submission.

The encryption key is still there, but not used. There is even a call made to decryption procedure but it is empty.
This one is some kind of work in progress, please wait to official release or just use previous version which was not detected.

Regards,

ESET Malware Response Team

[bpier...@gmail.com]

I'm attempting to build a version myself that will circumvent the false positive. Quick question, and I feel silly for asking -- but the running the latest code, the resources are not compressed in the xll. From what I can tell "compress" is true and it's not using the new managed resource resolver ...and for the life of me I can't find what I need to tweak to get the compression back (I did comment out the compress = false that impacts only the ExcelDna.xll and ExcelDna64.xll files). Any help on what I need to change is greatly appreciated. Thanks!

Brian

[Govert van Drimmelen]

Hi Brian,

 

Yes, we have removed both the encoding and the compression from the packed resource, to try to appease our anti-virus friends – that means the resources contain completely transparent Win32 binaries.

 

I think the line you you’ve commented out is the only place that is changed to disable the compression: Disabled compression. · Excel-DNA/ExcelDna@3df654c (github.com)

You would have to rebuild the whole solution and then build the packages to get a build task that has the compression enabled again when rebuilding your own project.

 

The managed resolver is only used if you:

• build your project on Linux, or
• build your project on Windows from the command-line with “dotnet build” and you also have the <ExcelDnaPackManagedResourcePackingOnWindows> property set in the project file.

 

I’ll make an update to the source to remove the commented out encoding methods as ESET suggests, and publish an updated version soon.

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/8f49c7e4-df88-4744-abbe-e7e5da2c00c3n%40googlegroups.com.

[Govert van Drimmelen]

Hi Brian,

I've now removed the remnants of the encoding code and re-published as v1.6.1-alpha6.

I'm a bit hesitant to make an 'official release' before ESET confirms that this is what they want.

-Govert

[bpier...@gmail.com]

Hi Govert -- I had done the same thing last night and ESET no longer flagged it per virustotal.com. To be doubly sure, I just installed alpha6 and can confirm that ESET no longer flags it. (Hooray!)

The compression is not a problem for ESET -- it was only the encoding. Obviously your call, but for an 'official release' I'd suggest reverting the disabled compression. If that is a problem for some virus provider, a user always has the option of changing the default config (or vice-versa and make it configurable but change the default to no compression).

Thanks again!

Brian

[Govert van Drimmelen]

Hi Brian,

 

I’m glad we are able to make ESET happy at last.

 

It seemed like a good idea to make a version where the packing is completely transparent – no compression or encoding – to keep any anti-virus that wants to look inside happy. Does the compression make a big difference in your life? How big are the uncompressed vs. compressed packed files?

 

Technically it would not be difficult to add the compression back, or even make it an option as you say. We just have to weigh the benefit of slightly smaller file vs. having another configuration option.

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/9aa80655-68f8-4e94-bd1b-2f8ae4ff06dfn%40googlegroups.com.

[Brian Pierce]

The lack of compression makes my xll over 20 MB vs about 6MB when compressed. Not really a big deal, but a significant difference - the only practical impact is that is makes pushing my addin to the cloud a bit slower, but again not major concern. FYI that even when compressed, there are no flags on virustotal if I digitally sign the file.

Best,

Brian

On Nov 8, 2022, at 8:37 AM, Govert van Drimmelen <govert.va...@gmail.com> wrote:



You received this message because you are subscribed to a topic in the Google Groups "Excel-DNA" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/exceldna/Tz2IHKIEziM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/000801d8f377%243715e830%24a541b890%24%40gmail.com.

[bpier...@gmail.com]

Hi Govert,

FYI that I tried upgrading to the latest 1.6.1 beta. The builds are much smaller now ...actually smaller than before with 1.6.0, which I didn't expect... but also VirusTotal shows the following flags raised:

  -Both Avast and AVG say Win32:DropperX-gen [Drp]

  -Kaspersky says HEUR:Trojan-PSW.MSIL.Agensla.gen

Maybe whatever changed that made things much smaller is causing the issue? For now I'm rolling back to the alpha6 since better to have larger files than the risk of an anti-virus issue.

Brian

[bpier...@gmail.com]

Looks like at least Avast and AVG may result from a change to the checks on virustotal, as xll files previously reported as clean now show as Win32:DropperX-gen [Drp] ...so a moving target.

Brian

[Govert van Drimmelen]

Hi Brian,

 

With the newest version, you can set a project property to disable the compression:

 

  <ExcelDnaPackCompressResources>false</ExcelDnaPackCompressResources>

 

That should let you run the current version, and still get the earlier behaviour.

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/25445288-13df-4abf-90d5-3f740f1bced4n%40googlegroups.com.

[bpier...@gmail.com]

Thanks Govert. I'll stick with the new Beta and leave things compressed now that I see even previously clear, uncompressed versions are flagged by AVG and Avast.

I submitted false positive reports for the ExcelDna.xll and ExcelDna64.xll files to Avast, AVG and Kaspersky yesterday. All 3 responded saying they have reviewed and marked the file "clean" in their databases. AVG indicated it could take 24 hours for the change to take effect. Those particular flags must not have been problematic for my users, anyway, but best to keep things as clean as possible.

Brian