I am trying to modify a method in a third-party dll
Use ILDASM to generate IL
Modify IL method
Use ILASM to generate DLL (FAILURE)
I found the reason due to this error is the third-party dll contains unmanaged code.
Is there any way that I can succeed?
Related
i'm trying to understand how dll hijacking works practically for educational purpose.
I also try to fund some countermeasure as i'm currently programming a software with a friend that contains dll and an executable in a archive.
Currently the best solution i found is to check checksum of dll loaded. Are there better solution ? I want avoid solution like check EV certificat etc...
According the exploitation of dll hijacking if i understand well, the attacker just need to replace the dll by a malicious dll that as malicious code that is executed in entrypoint ?
I have created a dll with messagebox code in c, and i have created a buggy code (executable) to make a proof of concept. This worked fine. (here the image : https://ibb.co/GpDF3sP)
But when i try test it with true software on market this doesn't work. (https://ibb.co/PDLxF59 and https://ibb.co/QJP4Hxj dll is not loaded after i changed it) Any idea ?
Attacker must create same DLL export table as in your DLL. Then he just load your original DLL module in fake one and pass all calls to it, so attacker's DLL will be used like a proxy for each call.
Honestly, if you're loading DLL statically with Windows PE loader, checksum and certificate are not so reliable methods. For example, if I have access to filesystem for write, I can replace your original DLL with fake one, start your process in suspended state, replace DLL to original behind your EXE module, resume your process execution (file moving operation is available even DLL file is using). And you can check DLL checksum and it will be correct for you, but actually you will use fake DLL which already loaded in memory.
For protect you may use algorithm:
Do not use static DLL linkage. Load DLL manually using LoadLibraryEx without calling DllMain with flag LOAD_LIBRARY_AS_IMAGE_RESOURCE
Verify checksum of DLL code in memory, not in the file. If checksum is not valid, do not do next steps
Load all DLL dependencies and call DllMain manually <-- this is most complicated step, so you need to resolve all DLL refs by hands
Load required DLL functions using GetProcAddress or by parsing DLL export table manually, and use them
Of course, this can not avoid checksum verification and it is complicated way, but you can prevent most of simple attack methods.
Depends on deep of implementation step #3, some of DLLs will not work, if you didn't implement thread local storage (TLS) calls
All question are related to a .net project dll in .net framework 2.0 that exposes itself as COM.
1) If we don't specify any GUIDs in the source code (typelib, classes, interfaces) who is generating the GUIDs? The compiler or regasm?
2) The GUIDs values exists in the dll, in the tlb or in both files?
3) Any developer with the same source code would generate the very same GUIDs independently on the machine where she builds or run regasm?
4) If I run regasm passing existing dll and tlb files, what happens If the dll and the tlb doesn't match? Regasm regenerate the tlb file with uptodate elements and GUIDs? Or it registers the TypeLib with the current tlb file?
5) What is the point of running regasm with dll and tlb parameters set?
Tlb file is part of what you deploy or it is best practice to only deploy the dll and let regasm generate the tlb on the fly?
6) And last question, is tlb really required? What is the point of having a tlb file? Is not all the information already in the registry? What extra info it provides?
7) When unregistering with regasm, what we need to provide? The dll? The Tlb? Both? What happens if dll (or tlb) doesn't match with existing reg entries? If already registered with tlb option but I run regasm unregister with dll only it would delete the TypeLyb entry too?
8) Regarding bitness, regasm will always generate entries under SysWow64 too? The regasm under Framework64 do the same as the one under Framework?
A type library is the exact equivalent of .NET metadata. It is most of all useful to the client programmer, it makes the compiler and the IDE smart about your library. Providing auto-completion and syntax checking so the odds of a mismatch between his code and yours are minimal. The registration step is necessary so your files can be found back. The type library is normally embedded as a resource in the DLL itself, like .NET metadata, but the .NET build model does not make that easy to do. The client compiler uses the type library info to generate the appropriate COM calls. Guids are a big deal because that is what the client compiler needs to use, identifier names play no role. There is a way to use "late binding" using names, the exact equivalent of Reflection in .NET, but that does not involve a type library.
who is generating the GUIDs?
The CLR does. Every .NET interface or class has one, regardless if it is [ComVisible(true)]. Exposed also through the Type.GUID property. If you didn't use the [Guid] attribute on the type then it runs an algorithm to generate the Guid that uses the type declaration as input. Or in other words, if you make any changes to the type then you can be sure that the Guid will have a different value. Which is the basic reason you should never use the [Guid] attribute, unless you have to create an exact drop-in replacement and cannot recompile client code. The TLBID comes from the AssemblyInfo.cs file that was auto-generated when you created the project.
in the dll, in the tlb or in both files?
It only exists in the DLL when you used the [Guid] attribute, but normally it is generated at runtime as explained above. It is always present in the type library, that's how the client compiler knows to create an object of your class and use its interface(s).
would generate the very same GUIDs
Yes, only the type declaration plays a role.
If I run regasm passing existing dll and tlb files
Regasm can only create a type library, as requested with its /tlb option, it cannot take an existing one. It otherwise does the exact same thing as Tlbexp.exe does, use Reflection to enumerate the types in the assembly to find the [ComVisible(true)] ones and generate the matching type library declaration. The extra thing it does is write the registry key for the type library to HKLM/Software/Classes/Typelib. So the client IDE can find it back.
What is the point of running regasm with dll and tlb parameters set?
No real idea with "dll parameter" might mean. As noted above, use /tlb to generate the type library. Whether or not you deploy the type library depends on its usage, if you don't also provide the client code then you should always deploy it so the client programmer can use it. Other usage of the type library is the subject of this post. If you're not sure how the client programmer is going to use your code then always deploy.
Is not all the information already in the registry?
What's in the registry is limited, only enough info to find the type library file back. The description of your interfaces, their method signatures, guids and the CLSID that the factory function needs is in the type library.
When unregistering with regasm, what we need to provide?
Exact same thing as registering it, you only add /unregister. You must also provide /tlb if you used it previously so the TypeLib registry key can be deleted. It can be pretty important to automate this while you are busy developing and testing the library, since the guids are normally auto-generated you can produce a lot of garbage in the registry. As well as ugly head-scratching when you forget to run Regasm. Project > Properties > Build tab, "Register for COM interop" checkbox. But with the downside that you have to run VS elevated so it can write to the registry.
regasm will always generate entries under SysWow64 too?
SysWow64 plays no role, do always avoid deploying to c:\windows. But yes, bitness does matter, the registry is structured so a 64-bit app cannot accidentally create an object in a 32-bit library and die on an ugly exception. And the other way around. A 32-bit client app will read registry keys from HKLM/Software/WOW6432Node, you only get your registry keys there is you used the 32-bit version of Regasm. Notable perhaps is that it is usually fine to run both flavors of Regasm, given that C# code can run on any platform.
I'm trying to get TFS team-build to reliably build a WPF C# app. This app relies on a VB6Lib.dll which we maintain, this VB6Lib.dll itself relies on other C# libs that we also maintain.
I've set up a build definition to build (in order):
VbDependencies.sln (all libs in this have com interop set, thus the VB6 can find their TLBs)
buildVB6Lib.proj (an msbuild file which calls "VB6.exe /make /d" to make the VBLib.dll on the build server, as part of this script I've been copying the VB6Lib.dll output to C:\tmp)
MainApp.sln (in my workspace, I've added a reference to C:\tmp\VB6Lib.dll)
Does this sound ok
?
On my dev laptop I usually build the VB6, copy its output to \tmp and then regsvr32 it there before adding a reference to it in my C# solution. It's this step that I'm not convinced my build def is doing.
Also, is there a way to get more useful output from the VB6 build, currently I get "Compile Error in File 'xxx.bas' Can' find project of library", but not which actual library it can't find.
You are correct in that the critical point in your build process on the development system lies in registering the COM object. However, one does not in general want to register the COM object on the build server, as this can cause all kinds of versioning issues and silent failures when the wrong COM object is registered or the registration fails.
The proper way to accomplish this is to generate an interop assembly manually and reference that instead of the COM object. This is accomplished with the tlbimp utility, for instance:
tlbimp ..\Libraries\VBLib.dll /out:..\Libraries\Interop.VBLib.dll
Run that command on your development system, then remove the reference to VB6Lib.dll and add a reference to Interop.VBLib.dll. You can then add the tlbimp command as a prebuild event in the referencing project so that the interop assembly is always build from the correct version, and you will never again need to have your COM object registered on the build system.
I'm converting a VB6 dll to VB.Net using Visual Studio 2008 Express. I want to use the same .dll to integrate with Excel via Excel-DNA, but also to be available via COM (I need to be able to call it from VBScript and VBA).
If I leave the assembly unsigned, I have access to all of the ExcelDNA functionality but no COM access.
If I sign the assembly with a strong name, then when I try to build the .dll I get the following error:
Unable to emit assembly: Referenced assembly 'ExcelDna.Integration' does not have a strong name
What are my options?
You don't have to strong-name a [ComVisible] assembly. It is only required when you want to install it in the GAC. Not strictly necessary although not a bad idea to fight DLL Hell. You need to register it with Regasm.exe using the /codebase option. Visual Studio already does that automatically, although the option might be missing in the Express edition.
Fixing the second problem shouldn't be hard either. Just rebuild the Excel-DNA solution from the source code you can download from Codeplex.
Excel-DNA has an option to expose your .NET classes to COM directly, so you can use them directly from VBA as regular COM classes.
To do this your class must be ComVisible (or the whole assembly must be ComVisible), and you must mark the ExternalLibrary as ComServer='true' in the .dna file, something like:
<DnaLibrary RuntimeVersion='v4.0' />
<ExternalLibrary Path='MyAddIn.dll' ComServer='true' />
</DnaLibrary>
Then you have some options for registration:
either call "Regsvr32.exe MyAddInDna.xll"
or in the AutoOpen of your add-in, call ExcelDna.Integration.ComServer.RegisterServer()
Both of these set the registry entries so that the .xll file becomes the COM server for your classes. You can then access them late-bound from VBA, with CreateObject("MyNameSpace.MyClass").
You need another step to set up a type library (to give you intellisense in VBA). For this you generate the type library with tlbexp.exe. The regsvr32 / ComServer.RegisterServer call will find the type library and register it too.
You can also pack the .dll into your .xll file (adding a pack='true' attribute to the ExternalLibrary tag) and the type library will also be packed if present, and registered from the resource in the .xll file when you call Regsvr32.exe
So the end result could be a single file .xll add-in that is both an Excel Add-In with UDFs, ribbons, RTD servers and also a COM server that you can access from VBA.
More info in the discussions here: http://exceldna.codeplex.com/discussions/252721 and here: http://groups.google.com/group/exceldna/browse_frm/thread/4c5a71efbe96d885.
My Problem: I am using Matlab COM Automation Server to call and execute matlab .m files from a VB.Net plugin for a CAD program called Rhino 3D. The code works flawlessly when set up as a simple Windows Application in Visual Studio, but when I insert it (and make the requisite reference) into my .Net plugin and test it in the CAD program I get the following error:
"Could not load file or assembly 'Interop.MLApp, Version 1.0.0.0,
culture=neutral, PublicKeyToken=null' or one of its dependencies.
the system cannot find the file specified."
What I've Tried: I am baffled as to why this occurs, but I was able to contact the CAD program's technical support staff and they suggested that it has something to do with their DotNet SDK having trouble with references that are located far outside the CAD program directory. They didn't have any solutions so I tried playing around with copylocal and this made no difference. I tried using other COM libraries and the Open Office automation server works fine, although uses url's instead of requiring a reference. I also tested Excel, which does require a reference, and it returned the error: "retrieving the COM class factory for component with CLSID {...} failed due to the following error: 80040154." This may or may not be related to the issue with the Matlab COM reference, but I thought was worthwhile to share. Perhaps is there another way to reference Interop.MLApp?
I would appreciate any suggestions or thoughts on how I might make the Matlab Interop.MLApp reference work.
Best regards,
Ben
Try moving the assembly file(s) for MLApp into the bin directory. Based on everything I've read, this seems to be a glitch of some sort during the generation of the assembly binding where all the assemblies are merged together and their locations are assumed. I've included some links where I gleaned a bit of information about it.
http://blogs.msdn.com/isha/archive/2009/04/04/issues-with-wcf-service-when-the-asp-net-website-is-deployed-using-the-web-deployment-project-and-as-non-updatable-project.aspx
ttp://social.msdn.microsoft.com/Forums/en/netfxremoting/thread/30df57a8-2a57-4f9f-a120-30c24bc11681
ttp://social.msdn.microsoft.com/Forums/en/netfxremoting/thread/30df57a8-2a57-4f9f-a120-30c24bc11681
ttp://www.sitefinity.com/support/forums/sitefinity-3-x/bugs-issues/cannot-load-file-or-assembly-error.aspx
ttp://forums.asp.net/t/986130.aspx?PageIndex=8
ttp://stackoverflow.com/questions/408002/could-not-load-file-or-assembly-xxxx-or-one-of-its-dependencies-the-system-can