I have application which needs to use a dll (also written by me) which has be independently verified by a government agency. We plan to modify the dll very rarely due to the re-verification which would be required. I want to prevent inadvertent modifications to this dll being picked up by my application. Is there a way to create a hash code for the dll and set up my application to only use this specific version.
This way if someone modified some of the code for the dll, when we build and run the application the app would fail to load the dll (because it had changed).
Any ideas/suggestions?
Cheers,
James
Using Strong Names does part of this and prevent anyone else tampering with your assembly, but doesn't stop you doing it by accident and then resigning.
We use an independent process to start our main application. Before launching the main app, the start up app MD5's all the assmeblies and compares them against a list of those it expects to see, if something has changed, the MD5 fails and the main app is not loaded.
If you really wanted compile time checking, you could probably write a pre-build step that did the same MD5 comparison and failed the build if it had changed.
I know that if you click on a dll Reference in your project you can select 'Specific Version' in its properties and set it to True, will this not do what you are after?
Phill
As Colin mentioned Strong Naming your assemblies will be the key as this includes both versioning & signing the assembly. The following couple of blog posts may help you with strong naming & versioning:
http://www.csharp411.com/net-assembly-faq-part-3-strong-names-and-signing/ (might be also worth reading the next part of this about the Global Assembly Cache)
http://philippetruche.wordpress.com/2008/08/12/net-assembly-versioning-lifecycle/
Related
I will briefly tell you the situation.
I got a C# project which uses some DLL created in C++.
Now, separately, I also have a C++ project, which was used to create that DLL some time ago.
Now, I wanted to debug the C++ DLL during running the C# project.
I enabled "Enable Unmanaged Code Debugging" in my C# project.
I started debugging C# project and stepping into some functions alongside.
All seemed to be ok. When I reached a function which belonged to C++ DLL,
it asked for the source of the C++ file, I had to browse to my C++ project.
(Before I think it complained about some .pdb files).
Now, I managed to step into the C++ function also, but as I step over and over, some of the data structures in that function don't seem to be populated with the data, e.g., please see screenshot below
You can see the blob data structure is empty, and same happened with DataParser (it was showing it had 0 items inside, whereas in code above you can see there are multiple items being added to it).
I would really appreciate some help, what is going wrong here? And where I could have done mistake. How can I debug this C++ DLL so that I also see what values are assigned to its variables currently?
Maybe my way of debugging this C++ DLL is wrong? The fact that the C# project is using an already created DLL, and I have this C++ project which was used to create this DLL some time ago - the fact that they are separate, maybe that has to do something with it also?
PS Before I had to make changes like this to C++ project and lower toolset because I use VS2012 (strange if project was created using VS2013 though because I think it is old project). Also the project uses lot of manually written other C++ classes. Maybe that is the problem also and somehow the compiler can't retrieve their values and definitions?
What are the steps in general to debug a C++ DLL file in a setup like I have?
EDIT: PPS. Also some other interesting facts I have seen. If I click F11(Step into) on the DataParser.Add function for example, not necessarily I am taken to the body of that function, it shows me body of other function (which might be somehow related to it).
Also if I press F10 say after first time Request.Add is called, it jumps over multiple Request.Add lines, and moves to the fifth one for example.
EDIT2: Also before I step into C++ code it is showing me warning that "the source is different version than the one that was used to create a DLL". Is this a problem?
Module and PDB
There is a link between a module (.dll/.exe) and the debug database (.pdb). This link is established via a timestamp and a checksum that is present in both files. Visual Studio checks the correctness of those, otherwise it will complain and not stop at breakpoints at all.
While other debuggers such as WinDbg have commands to turn that feature off, Visual Studio doesn't have such a feature and requires active manipulation (such as Chkmatch) to turn off the checmsum verification. As long as you didn't use such a tool, your debugging symbols are fine.
PDB and source
There is also a link between the debug database (.pdb) and the source. This link is established by file name and line numbers. As you can guess, your source code will not modified during compilation, so the source code does not contain any checksum or timestamp that could be verified.
Therefore, the source may have changed and the line numbers may not even match roughly any more. There are several reasons for line numbers to get broken. I have answered a similar question before and listed the following reasons for line number changes although the code itself did not change:
code reformat, which e.g. sorts the methods by visibility, so complete methods are moved
code reformat, which e.g. breaks long lines at 80 characters, usually this moves things down
optimize usings (R#) which removes 30 lines of unneeded imports, so things move up
insertion of comments or newlines
How to debug
Restore the exact source code of that version, if you can.
Debug completely without source, just by PDB information. This way you can keep the binary components, if that's important (e.g. if a bug can only be reproduced with that version)
Rebuild all modules to make the code match the modules again. That way you lose the binary and the problem may not reproduce any more.
This is what I'm trying to accomplish:
I have two applications. One is a client application the other one would be a compiler. Client uses encryption and for safety reasons I would like the users to be able to run the 'compiler' application, that would hard code a security key inside already compiled binary, so each client has its own encryption key stored inside of it. Is this even possible or the solution would be crazy? Thanks.
Sure all you are talking about is rewritting the MSIL code. Microsoft does this all the time with code contracts. Here is a link to an article explaining how: http://msdn.microsoft.com/en-us/magazine/cc188743.aspx
Another example: http://www.codeproject.com/Articles/20565/Assembly-Manipulation-and-C-VB-NET-Code-Injection
If your assembly is strongly signed, you cannot modify it. You cannot save back a modified .net assembly to disk. However, you can build your assemble ( As Kevin stated) to be able to modify the code loaded in memory at runtime. It will not affect the image on the disk and the modification will be run at every time the application is started.
Is it possible to create an app in C++ or C# so I can patch a exe file for copy protection purposes?
So if a user has an account on my website with the software tied to it, I can require them to enter a key which is checked with the database and then execute or show an error.
When I say "patch", I mean applying to an already built/compiled exe. Thanks for the help. :)
Its easily possible, many packers and protection systems like Themida do this, however, things like this can be easily cracked, thus you need to evaluate the effort vs reward required for someone to hack your program.
However, to directly answer your question, your best bet is to hook the code entry point defined in the PE and have it redirect to your checker (OS dependant). UPX is an opensource executable packer, and should provide a good base to use or point of reference asa it hooks the entry of the executable to run the unpacking engine. You can also find a few articles on packers and protectors here.
Depending on how complicated your copy protection is, "patching" may be in the simplest case just boiled down to writing a few bytes at selected offsets in the protected EXE file. This project may be interesting.
I've 2 .NET c# application without any security features. I wanted to implement a security mechanism myself which i will describe below, and i would like your comments if this is would work or there are things which i dont know.
So, when i need to run MyApp, i run AuthenticationAPP, this app will ask me for a security code.
IF code is correct -> load MyApp;
ELSE -> do not load app
What i was wondering is if there is a method to bypass this kind of mechanism and therefore transforming my authenticaitonAPP in uselessAPP very easly or if those methods are hard to implement.
thank you for any ideas/clarification.
You need to prevent the .net runtime from loading and executing any of the assemblies in MyApp. To ensure that you need to specify code permissions for your assemblies.
The code permissions has to check for a condition that can only be set correctly by AuthentificationAPP. It could something as simple as an encrypted call parameter from AuthentificationAPP to MyApp.
Then you have to make sure that your code can't be reverse engineered by a third party. So you have to look into code obfuscation and signing.
I think you can add code permissions on assembly level. So it could be that all you need is to add a single source file with assembly level code permissions and call context verification to each of you 1000 programs and the recompile those.
There exist different wrapping protection solutions like VMProtect, ASProtect, Armadillo etc.
Maybe they will fit your task.
I have an existing app which P/Invokes to a DLL residing in the same directory as the app itself.
Now (due to the fact that Canon produces one of the crappiest API's around) I need to support two versions of this API and determine at run-time which one I should use (old or new). Since the DLLs have the same name (the first one loads other DLLs with same names so just renaming the first one won't help me) I must keep them in different directories.
Hence my question: what options do I have to control what directory the DLL given in a DllImport declaration uses?
I guess I can start out by trying any of these two ideas:
1) Use "SetDllDirectory" to set my desired directory before doing the first P/Invoke and then reset it afterwards.
2) Load the desired DLL manually using "LoadLibraryEx" and hope that that will do the trick.
But are there any more ".NET:ish way" to try out first?
UPDATE: I realize that I can stuff all access to the DLLs in two separate .Net assemblies and then place each one of them in a separate directory with the corresponding API files. Then I can load the proper .Net assembly dynamically and the loading of the correct DLL whould happen automatically. Any reason that shouldn't work?
I can think of one: how would I go about debugging this stuff? It is possible to tell Visual Studio that an assembly (contained in my solution) shall be placed in a subdirectory and debugged from there?
My condolences, I've seen one of the APIs and it was indeed shockingly bad. The bigger problem is that you'll need to be able to convince Windows to find the DLL. They won't be in your .exe directory so the default won't work. Using SetDllDirectory() would work, using Environment.CurrentDirectory does too. LoadLibrary cannot work, the P/Invoke marshaller will use LoadLibrary itself.
If it is at all an option, you can use different names for the two P/Invoke declarations, using different arguments for the DllImport() constructor and using the EntryPoint attribute. Doesn't sound like that will fly.
I think 2nd option will work, but it will require to write a lot of code to manage dll loading in .net.
First one might work also, but i either don't like it.
Here is my suggestion: you can specify full path (and may be relative) in DllImport [DllImport(#"C:\dll\a32.dll"]
Your first option (P/Invoke with SetDllDirectory) is the option I personally prefer. Unfortunately, there isn't a ".NETish" way to handle loading native DLLs...which does make sense.
Starting with .NET Core 3.0, and also works with .NET 5 & .NET 6, you can use NativeLibrary.Load(string) to dynamically load DLLs at runtime, and use via P/Invoke normally.
Check this answer for more details: https://stackoverflow.com/a/69958827/211672