MS C# weirdness: GZip code is talking to China ?
-
I have my own serialize/deserialize code that i've been using for years that, optionally, uses the GZip facility MS provides in System.IO.Compression, and, System.Runtime.Serialization. A new C# WinForm project i started in VS22 to try and see what using Blazor webassembly was like, and that used Gzip to save state compiled, but, would not run ... no error message; it just exited the app with no output. Figuring there was some weirdness goin' down with Blazor/VS 22, I went and tested a previous VS2019 project that used the old library; saving using GZip showed the same puzzling behavior., The code that invokes GZip is bog-standard:
using System.IO.Compression;
using System.Runtime.Serialization;
// in some method where 'dcs is a DataContractSerializer instance, 'flename is valid file name
using (FileStream compressedFileStream = File.Create(filename))
{
using (var compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, true))
{
dcs.WriteObject(compressionStream, typeof(T));
compressionStream.Close();
}
}Oh .. my firewall/virus thing (EmsiSoft) was blocking the .exe ... the details surprised me:<\
Quote:
12/9/2021 11:44:19 AM quarantined Malware "Behavior.CryptoMalware" in "test blazor dec 4 2021.exe". Cloud Host Rule modified "Block silently" for host "42.180.243.234"
That IP appears to be in China:
Quote:
P Address: 42.180.243.234 IP Location: China, Liaoning, Liaoyang IP Owner: Unicom Liaoning Province Network
Of course i'll submit a report to EmsiSoft, but, wonder if anything in this scenario you see i might be overlooking. thanks !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
I have my own serialize/deserialize code that i've been using for years that, optionally, uses the GZip facility MS provides in System.IO.Compression, and, System.Runtime.Serialization. A new C# WinForm project i started in VS22 to try and see what using Blazor webassembly was like, and that used Gzip to save state compiled, but, would not run ... no error message; it just exited the app with no output. Figuring there was some weirdness goin' down with Blazor/VS 22, I went and tested a previous VS2019 project that used the old library; saving using GZip showed the same puzzling behavior., The code that invokes GZip is bog-standard:
using System.IO.Compression;
using System.Runtime.Serialization;
// in some method where 'dcs is a DataContractSerializer instance, 'flename is valid file name
using (FileStream compressedFileStream = File.Create(filename))
{
using (var compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, true))
{
dcs.WriteObject(compressionStream, typeof(T));
compressionStream.Close();
}
}Oh .. my firewall/virus thing (EmsiSoft) was blocking the .exe ... the details surprised me:<\
Quote:
12/9/2021 11:44:19 AM quarantined Malware "Behavior.CryptoMalware" in "test blazor dec 4 2021.exe". Cloud Host Rule modified "Block silently" for host "42.180.243.234"
That IP appears to be in China:
Quote:
P Address: 42.180.243.234 IP Location: China, Liaoning, Liaoyang IP Owner: Unicom Liaoning Province Network
Of course i'll submit a report to EmsiSoft, but, wonder if anything in this scenario you see i might be overlooking. thanks !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Doesn't seem great... It's possible that code has been injected from your PC, I'd run a scan locally as well as copying the code to a new PC and building/testing from there.
-
I have my own serialize/deserialize code that i've been using for years that, optionally, uses the GZip facility MS provides in System.IO.Compression, and, System.Runtime.Serialization. A new C# WinForm project i started in VS22 to try and see what using Blazor webassembly was like, and that used Gzip to save state compiled, but, would not run ... no error message; it just exited the app with no output. Figuring there was some weirdness goin' down with Blazor/VS 22, I went and tested a previous VS2019 project that used the old library; saving using GZip showed the same puzzling behavior., The code that invokes GZip is bog-standard:
using System.IO.Compression;
using System.Runtime.Serialization;
// in some method where 'dcs is a DataContractSerializer instance, 'flename is valid file name
using (FileStream compressedFileStream = File.Create(filename))
{
using (var compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, true))
{
dcs.WriteObject(compressionStream, typeof(T));
compressionStream.Close();
}
}Oh .. my firewall/virus thing (EmsiSoft) was blocking the .exe ... the details surprised me:<\
Quote:
12/9/2021 11:44:19 AM quarantined Malware "Behavior.CryptoMalware" in "test blazor dec 4 2021.exe". Cloud Host Rule modified "Block silently" for host "42.180.243.234"
That IP appears to be in China:
Quote:
P Address: 42.180.243.234 IP Location: China, Liaoning, Liaoyang IP Owner: Unicom Liaoning Province Network
Of course i'll submit a report to EmsiSoft, but, wonder if anything in this scenario you see i might be overlooking. thanks !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Please keep us updated! That's.. concerning! :O
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I have my own serialize/deserialize code that i've been using for years that, optionally, uses the GZip facility MS provides in System.IO.Compression, and, System.Runtime.Serialization. A new C# WinForm project i started in VS22 to try and see what using Blazor webassembly was like, and that used Gzip to save state compiled, but, would not run ... no error message; it just exited the app with no output. Figuring there was some weirdness goin' down with Blazor/VS 22, I went and tested a previous VS2019 project that used the old library; saving using GZip showed the same puzzling behavior., The code that invokes GZip is bog-standard:
using System.IO.Compression;
using System.Runtime.Serialization;
// in some method where 'dcs is a DataContractSerializer instance, 'flename is valid file name
using (FileStream compressedFileStream = File.Create(filename))
{
using (var compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, true))
{
dcs.WriteObject(compressionStream, typeof(T));
compressionStream.Close();
}
}Oh .. my firewall/virus thing (EmsiSoft) was blocking the .exe ... the details surprised me:<\
Quote:
12/9/2021 11:44:19 AM quarantined Malware "Behavior.CryptoMalware" in "test blazor dec 4 2021.exe". Cloud Host Rule modified "Block silently" for host "42.180.243.234"
That IP appears to be in China:
Quote:
P Address: 42.180.243.234 IP Location: China, Liaoning, Liaoyang IP Owner: Unicom Liaoning Province Network
Of course i'll submit a report to EmsiSoft, but, wonder if anything in this scenario you see i might be overlooking. thanks !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
I would check your PC - it seems to be infected...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
I have my own serialize/deserialize code that i've been using for years that, optionally, uses the GZip facility MS provides in System.IO.Compression, and, System.Runtime.Serialization. A new C# WinForm project i started in VS22 to try and see what using Blazor webassembly was like, and that used Gzip to save state compiled, but, would not run ... no error message; it just exited the app with no output. Figuring there was some weirdness goin' down with Blazor/VS 22, I went and tested a previous VS2019 project that used the old library; saving using GZip showed the same puzzling behavior., The code that invokes GZip is bog-standard:
using System.IO.Compression;
using System.Runtime.Serialization;
// in some method where 'dcs is a DataContractSerializer instance, 'flename is valid file name
using (FileStream compressedFileStream = File.Create(filename))
{
using (var compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, true))
{
dcs.WriteObject(compressionStream, typeof(T));
compressionStream.Close();
}
}Oh .. my firewall/virus thing (EmsiSoft) was blocking the .exe ... the details surprised me:<\
Quote:
12/9/2021 11:44:19 AM quarantined Malware "Behavior.CryptoMalware" in "test blazor dec 4 2021.exe". Cloud Host Rule modified "Block silently" for host "42.180.243.234"
That IP appears to be in China:
Quote:
P Address: 42.180.243.234 IP Location: China, Liaoning, Liaoyang IP Owner: Unicom Liaoning Province Network
Of course i'll submit a report to EmsiSoft, but, wonder if anything in this scenario you see i might be overlooking. thanks !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Update: i should have added to my original message: 1) on first detecting the odd behavior, i ran a complete scan ... all clean. 2) since i a/b tested in both VS 2019 and VSA 2022 the same apps using standard xml serialize techniques, and no unexpected behavior appeared, and the av software was not triggered ... i assumed the hypothesis that use of GZip was the trigger here was relatively strong.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Update: i should have added to my original message: 1) on first detecting the odd behavior, i ran a complete scan ... all clean. 2) since i a/b tested in both VS 2019 and VSA 2022 the same apps using standard xml serialize techniques, and no unexpected behavior appeared, and the av software was not triggered ... i assumed the hypothesis that use of GZip was the trigger here was relatively strong.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
You may follow the code here - Source Browser[^]
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
Update: i should have added to my original message: 1) on first detecting the odd behavior, i ran a complete scan ... all clean. 2) since i a/b tested in both VS 2019 and VSA 2022 the same apps using standard xml serialize techniques, and no unexpected behavior appeared, and the av software was not triggered ... i assumed the hypothesis that use of GZip was the trigger here was relatively strong.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Using your code created an exe - it runs without any alert. Asked for a direct scan from my ESET Endpoint Security and nothing came up...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
Using your code created an exe - it runs without any alert. Asked for a direct scan from my ESET Endpoint Security and nothing came up...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
Thanks, Kornfeld, May i ask what version IDE and app (WinForm ?, WPF ?) and FrameWork version you are using ? i suspect that's not a factor here ... just curious. fyi: Emsisoft is not blocking the .exe files of other projects in VS-19 or -22 when they are run.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Thanks, Kornfeld, May i ask what version IDE and app (WinForm ?, WPF ?) and FrameWork version you are using ? i suspect that's not a factor here ... just curious. fyi: Emsisoft is not blocking the .exe files of other projects in VS-19 or -22 when they are run.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
VS 2022 NET 6.0 Console Application
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
I have my own serialize/deserialize code that i've been using for years that, optionally, uses the GZip facility MS provides in System.IO.Compression, and, System.Runtime.Serialization. A new C# WinForm project i started in VS22 to try and see what using Blazor webassembly was like, and that used Gzip to save state compiled, but, would not run ... no error message; it just exited the app with no output. Figuring there was some weirdness goin' down with Blazor/VS 22, I went and tested a previous VS2019 project that used the old library; saving using GZip showed the same puzzling behavior., The code that invokes GZip is bog-standard:
using System.IO.Compression;
using System.Runtime.Serialization;
// in some method where 'dcs is a DataContractSerializer instance, 'flename is valid file name
using (FileStream compressedFileStream = File.Create(filename))
{
using (var compressionStream =
new GZipStream(compressedFileStream, CompressionLevel.Optimal, true))
{
dcs.WriteObject(compressionStream, typeof(T));
compressionStream.Close();
}
}Oh .. my firewall/virus thing (EmsiSoft) was blocking the .exe ... the details surprised me:<\
Quote:
12/9/2021 11:44:19 AM quarantined Malware "Behavior.CryptoMalware" in "test blazor dec 4 2021.exe". Cloud Host Rule modified "Block silently" for host "42.180.243.234"
That IP appears to be in China:
Quote:
P Address: 42.180.243.234 IP Location: China, Liaoning, Liaoyang IP Owner: Unicom Liaoning Province Network
Of course i'll submit a report to EmsiSoft, but, wonder if anything in this scenario you see i might be overlooking. thanks !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Verify your dotNet dlls haven't been infected. In fact, I'd double check the entire machine for malware, including rootkits.
thanks, as i said in my update message above, that was the first thing i did after seeing the odd behavior. the fact that only the code calls GZip produces the error is a sign the dll is not infected, since that same dll provides the code for standard XML serialization which works without error.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
thanks, as i said in my update message above, that was the first thing i did after seeing the odd behavior. the fact that only the code calls GZip produces the error is a sign the dll is not infected, since that same dll provides the code for standard XML serialization which works without error.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
It could still be infected. Malware tends to be some of the best written software on the planet.
Have you had a direct experience with a MS dll infected with any form of malware that is triggered only when a specific facility in the dll is invoked ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
