For the first time I have noticed that one of the mscordacwks DLLs in my collection is different (SVN told me). As I did some research I figured out that there are LDR versions and GDR versions of those DLLs.
For the files in question I noticed that one of them is not digitally signed, but the other one is (by Microsoft luckily).
So now I have the following questions:
If I have an LDR and a GDR version, how do I figure out which one is which?
Are both, GDR and LDR version of the DLL, signed by Microsoft?
Since one of them isn't signed, could someone inject malicious code into mscordacwks.dll which then gets executed on my machine with debugging privileges when I use it in WinDbg?
I'll try to find out where I got the unsigned DLL from. It is quite likely that I downloaded it from some some more or less dubious website when I needed that particular version.
FYI: the VirusTotal analysis did not reveal any viruses.
Thanks to the help in the comments I can summarize:
Digital signatures
According to Hans Passant, all Microsoft DLLs should be signed, so we have to be careful with unsigned ones.
Unfortunately this statement is not 100% true which I verified for the Mscordacwks.dll 2.0.50727.312 and SOS.dll 2.0.50727.312. Microsoft has shipped that version with Windows Vista. I tried that by installing Windows Vista from scratch.
This is the output of sigcheck -h on the DLL which come with Windows Vista:
Verified: Unsigned
Link date: 09:05 19.10.2006
Publisher: Microsoft Corporation
Description: Microsoft .NET External Data Access Support
Product: Microsoft« .NET Framework
Prod version: 2.0.50727.312
File version: 2.0.50727.312 (rtmLHS.050727-3100)
MachineType: 32-bit
MD5: 9252D83D169E84A442BB154A79AC2189
SHA1: 63464F337295D689384BAA514F260C54D06291C6
PESHA1: 99D57B38C554FFD4BEC6E6C2FAD7F77B980CB47B
PE256: EF387EF84028497D5F7D231ED3A6F5FB05C02D96BD3B0E470C6BEBFAD6942AC8
SHA256: 5ADB79D39FC8401CB9542B571EEEC82CAFCADAE2F26997C789E14EC8E9635C08
And also see the detailed information from VirusTotal which has the same hash codes. Please note the fact that the website is a bit misleading by listing "Authenticode signature block". In fact that is just the version information of the file. The most important line labelled "Signature verification: Signed file, verified signature" is missing for this DLL.
This is how it should look like if the file was really signed:
The output of sigcheck and Windows Explorer also show that that the file is not signed:
Verified: Unsigned
Link date: 09:05 19.10.2006
Publisher: Microsoft Corporation
Description: Microsoft .NET External Data Access Support
Product: Microsoft« .NET Framework
Prod version: 2.0.50727.312
File version: 2.0.50727.312 (rtmLHS.050727-3100)
MachineType: 32-bit
Screenshot of Windows Explorer where the file does not have a digital signatures tab:
At the end of the VirusTotal report, you find a statement by NIST (National Institute of Standards and Technology) which says that the file is delivered with Windows Vista Ultimate and that it seems to be safe. This is the website I am being led to after I uploaded an unsigned version.
Distinguishing GDR and LDR versions
The SysInternals sigcheck tool displays more information on the version number than Windows Explorer. If it includes "GDR", it is a GDR version. If it does not contain GDR, it is an LDR version.
To get a string for comparison in C#, you can use the following code:
var versionInfo = FileVersionInfo.GetVersionInfo(fullFileName);
var fileVersion = versionInfo.FileVersion;
Affected versions
I checked all my DLLs for signatures and found more unsigned DLLs than expected. However, most files have already been scanned on VirusTotal before. However, none of these versions has a NIST entry.
x86 SOS 1.1.4322.2032 VirusTotal
x86 SOS 2.0.50767.312 VirusTotal
x86 Mscordacwks 2.0.50767.312 VirusTotal
x86 Mscordacwks 2.0.50767.3603 VirusTotal
x86 Mscordacwks 2.0.50727.3623 VirusTotal
x64 SOS 2.0.50767.3074 VirusTotal
x64 Mscordacwks 4.0.30319.1008 VirusTotal
Malicious code injection
As stated by Jeroen Mostert, the DLLMain entry point will be executed, therefore there is the possibility of malicious code injection.
Related
I bought a new computer recently and uploaded this project to a FTP server and then downloaded it to my new computer but now it is causing this error:
Unhandled Exception: System.InvalidProgramException: Common Language Runtime det
ected an invalid program.
at Nancy.Conventions.NancyConventions.<Validate>b__1(Tuple'2 result)
at System.Linq.Enumerable.WhereEnumerableIterator'1.MoveNext()
at Nancy.Conventions.NancyConventions.Validate()
at Nancy.Bootstrapper.NancyBootstrapperBase'1.Initialise()
at Nancy.Hosting.Self.NancyHost..ctor(INancyBootstrapper bootstrapper, HostCo
nfiguration configuration, Uri[] baseUris)
at Nancy.Hosting.Self.NancyHost..ctor(Uri baseUri, INancyBootstrapper bootstr
apper, HostConfiguration configuration)
at PokerServer.Program.startServer() in f:\Projects\Visual Studio\PokerServer
\PokerServer\Program.cs:line 93
at PokerServer.Program.Main() in f:\Projects\Visual Studio\PokerServer\PokerS
erver\Program.cs:line 23
It worked well on the old computer.
I have updated .NET (and all other updates under Windows Update as mentioned in another thread).
I have tried deactive and active "Code optimization" without any problems.
The directory is not the same as before, not sure if that can cause this problem?
I verify my code with peverify and if I understand it correctly everything looks good:
F:\Projects\Visual Studio\PokerServer\PokerServer\bin\Debug>peverify PokerServer
.exe /md /il
Microsoft (R) .NET Framework PE Verifier. Version 4.0.30319.33440
Copyright (c) Microsoft Corporation. All rights reserved.
All Classes and Methods in PokerServer.exe Verified.
Any help is highly appreciated!
Are you actually compiling the project on the new computer or just running the application?
If you're just running it, did you verify that the application assembly or assemblies are actually identical on both computers? I suggest, you first rule out the option, that something happened during the data transfer.
If you're compiling it, what are you compiling it with? VIsual Studio? Which version?
In any case, the error is not related to the file directory, the application is in. According to MSDN, the exception should only be thrown when the compiled application is invalid (i.e. in case of a bug in the compiler). You can find more info in this knowledge base article. Try running the PEVerify tool and rebuilding the application in debug configurtion as the article suggests.
I removed the old Nancy dependency and installed it again from Nuget and now it works.
After doing a lot of search, I still couldn't get the solution for the question.
I have a mdmp file. The call stack shows it is using mscorlib.ni.dll. So to get the function information, I need to get its pdb file.
The version of mscorlib.ni.dll is 2.0.50727.3655.
I believe it comes from .Net Framework 3.5.
Since mscorlib.ni.dll is the native optimized dll which is generated by ngen.exe, so I need to use ngen.exe createpdb to generate pdf for this dll.
ngen.exe createpdb "C:\Windows\assembly\...\mscorlib.ni.dll" "C:\SymbolCache"
Here is the result:
I can't find ngen.exe in folder "C:\Windows\Microsoft.NET\Framework64\v3.5"
I could find ngen.exe in folder "C:\Windows\Microsoft.NET\Framework64\v2", but it does not have createpdb option.
I could find ngen.exe in folder "C:\Windows\Microsoft.NET\Framework64\v4.0.30319" and it does support createpdb option, but it reports error.
Microsoft (R) CLR Native Image Generator - Version 4.0.30319.18408
Copyright (c) Microsoft Corporation. All rights reserved. Invalid
header found in native image
'C:\Windows\assembly\NativeImages_v2.0.507
7_64\mscorlib\5cd1c2848ff40eb0a8c149706ee394fa\mscorlib.ni.dll'.
Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL))
So I have no idea how to get the pdb for this mscorlib.ni.dll of Net Framework 3.5.
Any idea?
I had the same error message until I realized I call ngen.exe from the Framework64 folder. Apparently, the mscorlib.ni.dll was not 64-bit.
So I used the 32-bit version of ngen.exe from the folder C:\Windows\Microsoft.NET\Framework\v4.0.30319 and it successfully produced the PDB.
However, the path to your mscorlib.ni.dll includes ...\NativeImages_v2.0.507 7_64\..., which indicates it is 64-bit, so this might be a different issue.
Like the answer from Monsignor, for me the solution was to match the bit-ness (64-bit or 32-bit). My minidump was 64-bit so I had to go to the Framework64 folder and run ngen from there and it was fine. I originally got the same ngen error as described here (Invalid header found in native image...E_FAIL) because I was in the Framework folder instead of the Framework64 folder (facepalm).
However, even though the ngen command worked...the pdb that was generated ultimately was still not accepted by VS 2013 as a matching symbol file, in my scenario.
I've added a reference to the CUDAfy.NET library via NuGet.
<package id="CUDAfy.NET" version="1.12.4695.21111" targetFramework="net45" />
When I run my program, I hit a Win32Exception:
The system cannot find the file specified
This happens on the first actual line of the program:
CudafyModule km = CudafyTranslator.Cudafy();
There's no indication from the exception object as to what file they're attempting to load.
How can I get past this problem?
EDIT
I see the same exception when running the bundled examples from the Codeplex download in VS2010 using .NET 4.0.
The strack trace is:
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at Cudafy.CudafyModule.Compile(eGPUCompiler mode, Boolean deleteGeneratedCode)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Version cudaVersion, Boolean compile, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy(ePlatform platform, eArchitecture arch, Type[] types)
at Cudafy.Translator.CudafyTranslator.Cudafy()
Setting VS to break on thrown exceptions shows the ProcessStartInfo object at the top of the stack in the locals pane of the debugger.
The relevant properties are:
FileName = nvcc
Arguments = -m64 -arch=sm_12 "c:\<path>\CUDAFYSOURCETEMP.cu" -o "c:\<path>\CUDAFYSOURCETEMP.ptx" --ptx
Some information from this article explains that the CUDA Toolkit must be installed. Fair enough.
Ensure that the C++ compiler (cl.exe) is on the search path. This set-up of NVCC is actually the toughest stage of the whole process, so please persevere. Read any errors you get carefully - most likely they are related to not finding cl.exe or not having either 32-bit or 64-bit CUDA Toolkit.
That article discusses version 4 of the toolkit, but version 5 is available now and supported since CUDAfy v1.1.
Download from https://developer.nvidia.com/cuda-downloads
Note that the 64-bit version of the CUDA Toolkit 5.0 is a 942 MB download. If you install everything you'll need an additional 2815 MB. The toolkit alone requires 928 MB.
EDIT After installing the CUDA Toolkit 5.0, the program failed with a CudafyCompileException at the same source line:
Compilation error: nvcc : fatal error : Cannot find compiler 'cl.exe' in PATH
Searching my system drive:
C:\>dir /s cl.exe
This shows many different versions of the compiler/linker, both from VS 10.0 and 11.0. Apparently only cl.exe versions 9 and 10 are supported, so I opted for the VS10.0 amd64 version, I included the following in my PATH environment variable:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64
Your path may be different, depending upon your CPU. I recommend running the search to see your options.
Note that you will have to restart VS after changing the PATH environment variable if you already have it open.
After taking these steps, my basic program ran successfully.
This may also happen if you had at some point installed CUDA Toolkit v7.5, but realized that the most recent version of CUDAfy supports CUDA 7.0.
On uninstalling CUDA 7.5 from the control panel, some files/folders may still remain. You should delete these manually. You may use CUDAfyViewer to see which version of CUDA Toolkit is being accessed.
I'm trying to interop with the ImageMagick library in Mono on a Mac. I installed the ImageMagick library with MacPorts and have verified that the file libMagickWand.dylib exists in the directory /opt/local/lib. I've also created a soft link to that file in the directory /usr/local/lib.
Here's my DllImport statement:
[DllImport("libMagickWand", EntryPoint = "MagickWandGenesis")]
static extern void WandGenesis();
Here's my App.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<dllmap dll="libMagickWand" target="/opt/local/lib/libMagickWand.dylib" />
</configuration>
And, at the call to WandGenesis();, I get a DllNotFoundException, with the message 'libMagickWand'.
I've read this page and I think I'm following all the rules. Is there anything else I can try?
Update:
I ran the .exe with MONO_LOG_LEVEL=debug. Here is the pertinent information:
Mono: DllImport error loading library 'dlopen(/opt/local/lib/libMagickWand.5.dylib, 9):
no suitable image found.
Did find: /opt/local/lib/libMagickWand.5.dylib: mach-o, but wrong architecture'.
wrong architecture: I'm running Snow Leopard in 32-bit mode and always have. I installed ImageMagick with MacPorts, and I installed Mono with the Mac package from mono-project.com. What would have been compiled with a different architecture?
Update:
I think I found my problem:
MacBook-Pro:lib ken$ lipo -info libMagickWand.5.dylib
Non-fat file: libMagickWand.5.dylib is architecture: x86_64
Update:
...but I'm still having issues. I can't seem to figure out how to compile ImageMagick with i386 architecture. When I try to do so using flags, it complains about other libraries that were compiled as 64-bit.
Update:
Mono on Mac OS X is 32 bit (at least usually, you can confirm that with mono --version) and you are trying to link with 64bit binary which is not possible. You have to provide 32-bit binary (or use 64-bit Mono).
Do you have the error even when only the library's file name is in the target and the library is placed appropriately (or the DYLD_LIBRARY_PATH set)? In such case please provide the output of mono executed with MONO_LOG_LEVEL=debug.
I am having to building mono from sources, since the Ubuntu package from badgerports is outdated (does not support .Net 4.0)
This is what I have done so far (mostly following instructions here):
cloned mono git repository
switched to branch tagged 2.6 (git checkout mono-2-6)
installed minimal mono on my machine so mono and mcs are available on machine
run ./autogen.sh --prefix=/usr/local
run make
After a few modules compile correctly, I get this error:
make[4]: Entering directory `/home/oompah/work/dev/mono/mono/mini'
CC mini.lo
CC liveness.lo
liveness.c: In function ‘mono_liveness_handle_exception_clauses’:
liveness.c:137: error: ‘MonoCompile’ has no member named ‘header’
make[4]: *** [liveness.lo] Error 1
make[4]: Leaving directory `/home/oompah/work/dev/mono/mono/mini'
make[3]: *** [all] Error 2
I have looked at the offending code, and indeed a header member is being accessed ...
void
mono_liveness_handle_exception_clauses (MonoCompile *cfg)
{
MonoBasicBlock *bb;
GSList *visited = NULL;
MonoMethodHeader *header = cfg->header;
...
}
Has anyone managed to build mono-2.6 (or later) on Ubuntu?
I've used the scripts provided at integratedwebsystems successfully to compile a recent version of mono on my system and run .net 4.0 applications.
an improved version of the script can be found on firegrass' github account
Joe Shields is packaging Mono 2.10 and is patching everything to default to .NET 4.0 for Ubuntu, you might want to poke him on twitter #directhex.