I have a problem which I'm pretty sure that I can't solve without going back to the vendor, but I thought I would float the problem here first.
Anyway, I have an assembly from a 3rd party that I have to incorporate into existing applications, but it is not signed. This obviously gives me a load of headaches as all my existing product assemblies are signed, and to reference the new dll from these would require me to not sign them. I really don't want to do that.
Do I have any other options other than a) going back to the vendor to try and get them to sign it or b) not-signing any dll that references it?
Your best bet is to ask the vendor for a properly signed assembly.
Failing that, you do have the dirty option of disassembling the assembly with ILDASM, then reassembling it with your own strong name encryption key. This will require a bit of work. Talk to the vendor first, and perhaps even mention (not threaten) that you'd rather not have to disassemble their assembly.
Related
I am a game devoloper, When i release a new games, BOOM!!!, That game will be modded, and i am running online games, Soo it's huge lose for me, I am making games with Unity, Hope u guys can understand me, I want to add HashCheck to the games main file, Like "If file hash changed, Game,close"
Like :- I have Assembly-CSharp.dll as my main game data file, So if Modders want to mod my games, They Will just load Assembly-CSharp.dll into some decompiler and Edit the file
I have also tried "HEX" Protection, But they Bypasses it
So, I want to make, When Modders change Assembly-CSharp.dll the hash will be changed,
If Hash chnaged "Application.quit"
I am just trying to compare MD5 hash
But i am not getting, Even sample code anyware
I just need code to add HashCheck in
Assembly-CSharp.dll
Mean I need C# code
Sounds like strong-name assembly-signing might help you.
Amongst others, one benefit of strong-naming your assemblies is that they are signed with a digital signature, which protects the assembly from being tampered with.
If someone is to modify your assembly, the verification process which automatically occurs during assembly load will fail and throw an exception.
Strong names provide a strong integrity check [...] [, guaranteeing] that the contents of the assembly have not been changed since it was build.
Taken from docs.microsoft.
Read more about how to use strong-naming here.
EDIT
As toATwork has mentioned, strong-naming will not be of benefit here. Strong-naming insures your users that your assembly really comes from you and was not modified by others.
Users that want to modify your assembly will not be discouraged from tampering with your assembly!
Since hash checks can easily be bypassed as well, what I recommend is to use obfuscation in combination with tamper checks. You could use Dotfuscator, which is already included in Visual Studio.
I have created project in Windows Presentation Foundation which use some Assembly created by me and use in other project. But now i don't want others to use it and to reverse engineering ("Assembly to code").
i come to know about Assembly signing. Also i Have use ant try signing but i can easily Open code of Assembly in .Net reflector tool.
So please guide me in right direction.
It all depends on how much work you want to do, and how hard you want to make it.
If all you want is to stop people from being able to quickly decompile your assembly you can compress and/or encrypt the DLL itself, then write a loader for the assembly that brings it into memory, decodes and/or decompresses and loads the assembly in-memory. The compressed/encrypted data can be stored as a resource in another assembly which handles the unpacking if you like, although that makes it simpler to find the code that does the unpack.
This will only prevent casual inspection of your code. It won't slow down a determined reverse engineering attempt by much. Ultimately there isn't much at all that you can do to stop a skilled and determined attempt at reverse engineering.
It is a good practice to always sign executable files (exe, dll, ocx, etc.). On the other hand, with an open source project it may considered disregarding the contributions to the project from all other developers.
This is quite an ethical dilemma for me and I would like to hear more opinions on this from either people who have been in a similar situation or people who contributed to an open source project.
I would like to note that this question is for an open-source project that was written in C# using .NET 4 so when user clicks the executable, he or she will be prompted a warning stating that the file is from an untrusted publisher if it is not digitally signed.
By the way, the assemblies all have strong-naming (signature) already, but they are not digitally signed yet (i.e. using a Verisign Code signing certificate).
.Net is a diffrent beast as many features require (especially libraries) require the file to be signed with a strong name key, but those can be self signed with no complaint from the final product (it uses the programs cert not the libraries to pop up that message box you refer to in your original question).
However in the general case I see nothing wrong with a group signing the official distro with a private key. If you do something to the source and recompile technically "the file is from an untrusted publisher" as I may trust Canonical but I do not trust you. As long as the executable being not being signed from a specific publisher does not stop it from being used in the manner it was intended (the tivoization clause in the GPL) I see no reason NOT to sign your executables.
Saying that this is "quite an ethical dilemma" is probably blowing it out of proportion. You definitely want to code sign your executables, and I don't really see the problem with you signing it. For example, TortoiseSVN is signed by "Stefan Kueng, Open Source Developer".
That said, it is probably a good idea to form some kind of legal entity for your project, and then get the code-signing certificate in the name of your project's entity. That way, rather than you personally signing the executable (and thus "taking all the credit"), your project's name shows up as the publisher.
If you were in the US, I would suggest either forming a LLC or possibly a 501(c)(3) organization, which is exempt from income tax and allows individuals to make tax-deductable donations to the project. (Many open source projects organize as 501(c)(3) entities, including WordPress and jQuery.) I see you're in Turkey, so you'll have to research your local requirements for forming some kind of legal entity; once formed, you'll be able to get a certificate from a CA in the name of your project's entity rather than your own.
I need to bone up on my CLR compiling knowledge, so i'm going to speak in generalities... Appologies if I'm not being specific enough.
I'm working on an application that references a COM Library dll which has a number of dlls rolled into it. My question is, is it possible using Reflection to get a reference to the sub dll's assembly, namely to obtain the version number?
Or, if this question makes no sense, i'll try to rephrase.
No can do, you've got no way to find out what DLLs the COM server might be using. There isn't anything like Assembly.GetReferencedAssemblies() in unmanaged code. Process.Modules is about as close as you can get but there's no way to find out that the module you'll iterate was actually associated with the server instead of being loaded by, for example, OpenFileDialog or some obscure virus scanner crap.
If you know the DLL names and where they are located then you can use the FileVersionInfo class to obtain their unmanaged version resource info.
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/