stavroskasidis / blazorwasmantivirusprotection Goto Github PK

On two different development machines, we've experienced build errors after referencing this package.

It seems that nuget packages are no longer recognised.

I was able to get building again after clearing my nuget folders. I, strangely, also had to reinstall the .Net 6 SDK.

This happens even when publishing in Debug mode.

Attached is an example of the errors experienced. We're using .Net 6.0.102 and Visual Studio 2022 17.0.6, on Windows 11.

The CleanOldDlls function doesn't appear to work correctly with the Xor process. I think this is due to the the IsDllHeaderBz check being incorrect when the file is Xor'ed.

If you run a publish the files are Xored if you run another publish straight after the files are reverted unless you manually clean the directory.

I'm not sure if there is some specific relevance to the BZ header or if its arbitrary?

If its arbitrary could there be an option to pick the header similar to how we can choose the file extension? (2 bytes I guess).

The reason I suggest this is I noted after I released a project with BZ headers but .dll file extensions our filter started blocking it. I released with corrected file extensions and the filter still blocked it. I assume this is because the file hash was the same as one already blocked. I disabled trimming on the blocked file to force a hash change and it went straight through.

This may be related to #6

If we can change the header it gives us a way to force a hash change.

There may be other ways to force a hash change along the lines of null 0x00 characters on the end of the dll. I haven't looked into if that will work or corrupt the dll's though.

I have localization implemented with Microsoft.Extensions.Localization package. And I am face with this error:

What do you recommend to do with it?

I am running builds on a AWS based virtual machine and the build step constantly fails during the Xor step on random files. I originally thought that the Antivirus was causing it but the failures are still consistently happening with the Antivirus disabled.

I strongly suspect that the process is stepping on itself.

D:\BuildAgents\BuildTools\NugetCache\blazorwasmantivirusprotection\2.4.0\build\net6.0\BlazorWasmAntivirusProtection.targets(28,3): error MSB4018: The "ObfuscateDlls" task failed unexpectedly. [D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\Project.Client.csproj]
D:\BuildAgents\BuildTools\NugetCache\blazorwasmantivirusprotection\2.4.0\build\net6.0\BlazorWasmAntivirusProtection.targets(28,3): error MSB4018: System.IO.IOException: The process cannot access the file 'D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\obj\Release\net6.0\linked\CurrieTechnologies.Razor.Clipboard.dll' because it is being used by another process. [D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\Project.Client.csproj]
D:\BuildAgents\BuildTools\NugetCache\blazorwasmantivirusprotection\2.4.0\build\net6.0\BlazorWasmAntivirusProtection.targets(28,3): error MSB4018:    at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options) [D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\Project.Client.csproj]
D:\BuildAgents\BuildTools\NugetCache\blazorwasmantivirusprotection\2.4.0\build\net6.0\BlazorWasmAntivirusProtection.targets(28,3): error MSB4018:    at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize) [D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\Project.Client.csproj]
D:\BuildAgents\BuildTools\NugetCache\blazorwasmantivirusprotection\2.4.0\build\net6.0\BlazorWasmAntivirusProtection.targets(28,3): error MSB4018:    at System.IO.File.OpenHandle(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize) [D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\Project.Client.csproj]
D:\BuildAgents\BuildTools\NugetCache\blazorwasmantivirusprotection\2.4.0\build\net6.0\BlazorWasmAntivirusProtection.targets(28,3): error MSB4018:    at System.IO.File.WriteAllBytes(String path, Byte[] bytes) [D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\Project.Client.csproj]
D:\BuildAgents\BuildTools\NugetCache\blazorwasmantivirusprotection\2.4.0\build\net6.0\BlazorWasmAntivirusProtection.targets(28,3): error MSB4018:    at BlazorWasmAntivirusProtection.Tasks.ObfuscateDlls.Execute() [D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\Project.Client.csproj]
D:\BuildAgents\BuildTools\NugetCache\blazorwasmantivirusprotection\2.4.0\build\net6.0\BlazorWasmAntivirusProtection.targets(28,3): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\Project.Client.csproj]
D:\BuildAgents\BuildTools\NugetCache\blazorwasmantivirusprotection\2.4.0\build\net6.0\BlazorWasmAntivirusProtection.targets(28,3): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [D:\BuildAgents\BuildServer\_work\1\s\Src\Project.Client\Project.Client.csproj]

GData Internet Security flags up files written to the cache, whether using this package or not.

GData considers the files to be trojans.

I wonder if it is the application/octet-stream MIME type still present in the file?

I'm getting Error: Error loading ICU asset. while adding BlazorWasmAntivirusProtection that runs under Azure WAF.

This is how it looks like:

Another question is whether it's confirmed that BlazorWasmAntivirusProtection works successfully with Azure WAF?

Steps to reproduce:

1. dotnet new blazorwasm -n test
2. dotnet add package BlazorWasmAntivirusProtection

Publish, upload to Azure AppService that secured with WAF.

Project .csproj looks like this:

<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="BlazorWasmAntivirusProtection" Version="1.8.5" />
    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="6.0.7" />
    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="6.0.7" PrivateAssets="all" />
  </ItemGroup>

</Project>

Helllo.

The following error occurs in my blazor wasm project on publishing with Xor obfuscation enabled;

Publish has encountered an error.
Build failed. Check the Output window for more details.

A diagnostic log has been written to the following location:
"C:\Users\MyUserID\AppData\Local\Temp\tmpEC7.tmp"

Severity	Code	Description	Project	File	Line	Suppression State
Error		The "ObfuscateDlls" task returned false but did not log an error.

When I turned Xor obfuscation off, publishing succeeded.

My blazor wasm project refers an extermal .net standard 2.0 assembly, whcih has been obfuscated with other .NET obfuscator.
I suspect that it may result the issue.

So, I think that ignoring specific dll files in obfuscation may be required.

Best regards.

Hmmm, so upgraded my project to .Net 7 yesterday and got a new report from a user after I hadn't heard a peep after adding the AV protection a few months ago.

Die Datei [...]\Mozilla\Firefox\Profiles\b93zdwlj.default-release\storage\default\https+++lostmerchants.com\cache\morgue\33{c36484e8-6fc5-42bb-b202-371d08f9d421}.tmp ist mit Trojan.Upatre.Crypted.2 infiziert.

Honestly not sure this is even actionable at the moment but figured I'd bring it up in case anyone else runs into it. I ran VirusTotal against my site and the DLL URLs that had caused issues prior to adding BWAP and they come back clean. Looks like it's some sort of temp file in the cache created by Firefox, the only files I even have in that directory are ".final" files and they all exist as unique GUIDs so good luck on me trying to figure out which cache item it could even be.

Could be some change in the framework or maybe not.

Just to confirm the Xoring approach bypasses Sophos Endpoint Agent.

This recently (at least here) started detecting the files as Windows Executable irrespective of a header change and the appending of a Guid that I tried in my fork. Great work.

I had to use BlazorWasmAntivirusProtection to get around the stupid issue with antivirus blocking all DLL file downloads.

Since installing this NuGet package, my main index page loads with no problems. Then I can log in as an instructor, then as a student, then take a 60-question test. When I click "finish" on the test, I get this error on the test results page:

blazor.webassembly.js:1 TypeError: Failed to fetch dynamically imported module: https://server/siteName/page/_content/BlazorWasmAntivirusProtection/BlazorWasmAntivirusProtection.lib.module.js
(anonymous) @ blazor.webassembly.js:1

Similarly, I can load the index page, then click the Admin login option, and I get the above error.

Do you know of any reason that the file would just disappear from the Sources list between page clicks?

This is my Sources tab in Admin Tools when I'm on any of the pages that work:

This is my Sources tab in Admin Tools when I'm on any of the pages that don't work:

I'm at my wit's end.

Edit: It's looking for the code in the wrong place. It's looking in server/site/page/_content/..., when it should be looking in server/site/_content/...

I'm not sure why, though. Does anyone have any thoughts?

We would like to implement BlazorWasmAntivirusProtection because of problems at one of our customers, but adding the nuget packages the build steps are not executed.

After some trial and error we found out that the problem is caused by the runtime identifier we use to build our project. Removing <RuntimeIdentifier>win-x64</RuntimeIdentifier> from our server csproj makes the build step to be executed.

We have the feeling that the extra folder in the bin folder for the runtimeidentifier is the cause, but we don't know where in the package this is a problem.

So building the project without the runtimeidentifier gives the following path:
Server\bin\Release\net7.0\publish\wwwroot\_framework

With runtime identifier it becomes:
Server\bin\Release\net7.0\win-x64\publish\wwwroot\_framework

Is this something that can be fixed in the next version?

I think there may be an issue with the Brotli compression on version 2.2.1 (I haven't tried most of the versions between 1.8.5 and 2.2.1). I didn't notice till recently since I'm deployed behind Cloudflare and they seem to request the uncompressed asset generally.

This was specifically trying to access the /_framework/blazor.boot.json file, though I didn't really try with others since that's the first one to fail in the load process.

If I try and use Postman with "Accept-Encoding": "gzip, deflate, br" the request returns a 200 OK but a zero-length file. Works fine if I request after removing "br" in which case I get back a gzip encoding, and also works fine with no Accept-Encoding in which case I get back a non-compressed file.

Not entirely sure why this blows up like it does, I'm guessing Kestrel isn't liking the file for some reason? This is on .Net 7 (running on a Linux docker container from the standard MS containers) for reference as well. No errors logged anywhere that I can tell in either my host container on the Nginx proxy in front of it.

I followed the instruction from readme of this repo. I dont know what i have done wrong. The published files arent renamed.

I added the nuget package to both my client and server app.
I then deleted al bin/obj files.
I then published to Azure.

When the app runs I just see "Loading..." on the screen. No attempts are made to download app binaries, and I don't see any 404's or console errors.

The issue is caused by changes in the startup script. Since the old one cannot handle the encryption etc.
As this image shows the startup script is read from the cache, causing it to handle it the old way.

The issue is following. Absolutely unreadable but i've been able to trace it to this.

As for my suggestion, for files that we don't want cached we usually add a query string to them to be able to make sure that the browser requests them again. Maybe it would be possible to add a property that you can change in the .csproj which is appended as a query string in the blazor.boot.json. That would make blazor load it with the query string and prevent it from reading it from the cache.

I have a hosted blazor project that hosts two WASM apps. One at root / and one at /Public this is to enable different security on each. This is based on the multiple hosting example here https://github.com/javiercn/BlazorMultipleApps updated to .NET 6.0.

Dll's in both projects get the headers changed as PublishBlazorBootStaticWebAsset is passed in for each project but renaming is only on the first _framework folder found:

var frameworkDir = Directory.GetDirectories(PublishDir, "_framework", SearchOption.AllDirectories).First();

My project will have _Framework at wwwroot/_framework and wwwroot/Public/_framework.

Changing to a foreach loop appears to fix it although I am not sure if serviceworker needs adjusting too (I don't use it) I imagine a second service worker would end up in wwwroot/Public

foreach(var frameworkDir in Directory.GetDirectories(PublishDir, "_framework", SearchOption.AllDirectories))

There may be a cleaner way to do this. I assume the PublishBlazorBootStaticWebAsset isn't available after Publish otherwise you would just loop the files with a special case for blazor.boot.json and service-worker-assets.js

I tried to open an issue here too : dotnet/aspnetcore#44782

Did someone has any xp with this messy proxy ? I cannot access anything in term of policies or config but it stops my wasm blazor very well.

The release notes only seems to point to an update to the .NET SDK version update to .NET 7.0.

From what I can tell:

• there is no breaking change
• .NET 6.0 is a supported target framework

Is that right?

Environment:

• windows 10
• visual studio 2022 17.4.0,
• .net 6
• BlazorWasmAntivirusProtection version 2.0

To reproduce:

1. Created a new blazor webassebmly project with Asp.net core hosting, HTTPS and PWA checked.
2. Installed BlazorWasmAntivirusProtection version 2.0 to both server and client projects
3. Publish

Ran into this error:
Error The "BlazorWasmAntivirusProtection.Tasks.CleanOldDlls" task could not be loaded from the assembly C:\Users\me\.nuget\packages\blazorwasmantivirusprotection\2.0.0\build\net6.0....\tasks\BlazorWasmAntivirusProtection.Tasks.dll. Could not load file or assembly 'System.Runtime, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

With my other existing project the error is a little different, marked in bold:
Error The "BlazorWasmAntivirusProtection.Tasks.ObfuscateDlls" task could not be loaded from the assembly C:\Users\me\.nuget\packages\blazorwasmantivirusprotection\1.9.0\build\net6.0....\tasks\BlazorWasmAntivirusProtection.Tasks.dll. Could not load file or assembly 'System.Runtime, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

I deleted the these folders

• "C:\Users\me\.nuget\packages\blazorwasmantivirusprotection"
• obj of both server and client projects
• bin of both server and client projects

and then ran a dotnet restore, but it doesn't fix it.

I have a hosted blazor project where <StaticWebAssetBasePath> is set on the client project in order to serve the blazor wasm app from a subdirectory. The blazor wasm app's index.html has a <base href="/app/" /> set, which inturn causes the browser to load everything from /app.

However BlazorWasmAntivirusProtection.lib.module.js is only available at https://localhost:15563/_content/BlazorWasmAntivirusProtection/BlazorWasmAntivirusProtection.lib.module.js and not at https://localhost:15563/app/_content/BlazorWasmAntivirusProtection/BlazorWasmAntivirusProtection.lib.module.js.

I've opened a PR so that it's easier to see a repro #15.

If I figure what needs to change, I'll post an update.

Hello.

I am developing a blazor wasm app for LOB application.
So, it is very important to pass web firewall.

Can I use both AOT compilation and XOR obfuscation?
Or, is it enough to apply AOT compliation and dll renaming only?

Best regards.

Hello Stavros

I temporarily abandoned my Blazor project about a year ago because there where too many problems - one of them was high risk of firewall/antivirus blocking. Your solution seems perfect. My project is a public website that must be properly indexed by Google and other robots. To achieve this I have to use prerendering.

Is your solution compatible with prerendering? You wrote that assemblies are obfuscated during publishing. Do you leave original files so they can be used on the server in the prerendering phase?

@stavroskasidis Thank you for your wonderful works. This package solves many issues.

And as per the documentation - https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-8-preview-4/#webcil-packaging-for-blazor-webassembly-apps ,

Starting .NET 8 Blazor wasm releases will support webcil format. So I would like to understand how this package will different from that? Please can you assist?

We are experiencing the same phenomenon as described in this issue: Build errors after referencing this package

Referencing this package and making the first publish all builds fails after that.

It doesn't matter if we publish from VS 2022 or from the command line.

What happens is that when we publish the project this package obfuscates the wrong files, it obfuscates the files in the nuget-cache folder and not the actual published files.

BlazorWasmAntivirusProtection: Xor'ed dll C:\Users\xxxxx\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\6.0.5\runtimes\browser-wasm\lib\net6.0\System.Security.dll
BlazorWasmAntivirusProtection: Xor'ed dll C:\Users\xxxxx\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\6.0.5\runtimes\browser-wasm\lib\net6.0\System.Security.Principal.dll
BlazorWasmAntivirusProtection: Xor'ed dll C:\Users\xxxxx\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\6.0.5\runtimes\browser-wasm\lib\net6.0\System.Security.Principal.Windows.dll
BlazorWasmAntivirusProtection: Xor'ed dll C:\Users\xxxxx\.nuget\packages\microsoft.netcore.app.runtime.mono.browser-wasm\6.0.5\runtimes\browser-wasm\lib\net6.0\System.Security.SecureString.dll

To be able to make a new build, we have to remove all files from the nuget-cache folder.

Using VS 2022, Net 6.03 and version 1.8 of this package. Doing a Release publish to local folder.

Any suggestions?

I tried to combine this Library with LazyLoading according to this guide:
https://docs.microsoft.com/en-us/aspnet/core/blazor/webassembly-lazy-load-assemblies?view=aspnetcore-6.0#router-component-configuration

Unfortunately the project file configuration only allows ".dll" Files
https://docs.microsoft.com/en-us/aspnet/core/blazor/webassembly-lazy-load-assemblies?view=aspnetcore-6.0#project-file-configuration

So when using this approach, the AntivirusProtection gets bypassed and the pure DLLs are loaded directly.

Is there a way to use LazyLoading with AntivirusProtection?