0

I am given 3 DLLs (API to external system) and I can use those with my executable on Windows 7 32bit .net 4.

Then I need to sign my executable with a strong name.

It mandates that the API DLLs will also be signed with the same strong name, if I understand correct.

And I've seen posts how to do that (ildasm/ilasm, or Brutal Developer, or Crypto Obfuscator) and tried everything I put my hands on. Yet still getting "strong name signed assemblies must specify a public key in their InternalsVisibleTo declaration".

Anyone been there also and managed to get out safely?

Regards, Oren

PS 1, I did manage to make it work on Windows 7 64bit (there the 3 API's DLLs were signed with Crypto Obfuscator done by previous developer). I started to investigate when it did not work in 32bit and I have realized I am using the signed DLLs. Then I've located the original DLLs, but was only able to run without "strong name" in neither my assemblies nor the API. Any other combination, even when my assemblies were not signed (or everything was signed to the best of my knowledge), did not work.

PS 2, I have also another DLL of mine, which works nicely with the executable (I sign both, so I have a total of 5 assemblies, 2 mine and 3 given), I'm not sure it is related, but brought it here anyhow.

Oren
  • 976
  • 9
  • 23
  • Not the *same* strong name. You just need to specify the public key in the `InternalsVisibleTo` attribute declaration. The error message is pretty clear on that. Why are you trying to hack your way into the internals of the API DLLs? They're probably internal for a reason. – Luaan Apr 15 '15 at 09:50
  • Hi Luaan. I can specify the public key in InternalsVisibleTo on my executable. I have tried this. Yet I don't have access to the API DLLs source, and I'm not sure why am I considered to be touching their internals. I just followed an example they gave. I am using the same strong name in all places and with all attempts. This is what I picked up from my investigation (to try to sign the DLLs that one does not have access to with the same strong name). – Oren Apr 15 '15 at 11:52
  • Oh, you need your application to be signed, while the 3rd party libraries don't have a signed version? – Luaan Apr 15 '15 at 11:56
  • Yes, this is the issue. And there are some threads of what to do in this situation, but I think I've tried everything out there by now. – Oren Apr 15 '15 at 12:24

1 Answers1

2

It seems that your problem is that you need your application to be signed, while using an unsigned 3rd party library. You tried to solve that problem by signing the 3rd party library, but that introduced new errors.

Given this assumption, the problem is quite clear - the individual DLLs of the 3rd party library are using internals of each other (at least one of them does this to at least one of the others), which is why it's using the InternalsVisibleTo. The error you're getting is because you've signed the assemblies in a hacky way, and didn't make sure all the references the assemblies have among themselves are updated as well - so the InternalsVisibleTo is now referencing an invalid DLL, which means that .NET will prohibit the target DLL from using internals of the other library.

To fix this, you need to change the InternalsVisibleTo declarations in the 3rd party libraries. This is easy to do in the IL - just find the attribute declaration, and change the assembly name to include the public key (e.g. from InternalsVisibleTo("MyLibrary") to InternalsVIsibleTo("MyLibrary, PublicKey=4564651357987621321...")).

However, I have to note that this is considered reverse engineering, and it might be prohibited by the license of the 3rd party. Make sure what you're doing is legal, and if not, communicate directly with the 3rd party provider to find a proper solution.

Luaan
  • 62,244
  • 7
  • 97
  • 116
  • I will try this. This is a most promising idea. I will update the thread with my findings. – Oren Apr 15 '15 at 12:29
  • You are probably correct. I have 'ildasm' the 3 API DLLs, and indeed 2 of them contain InternalsVIsibleTo. Next I need to figure out how to change the file, as it is given as: ".custom instance void [mscorlib]System.Runtime.CompilerServices.InternalsVisibleToAttribute::.ctor(string) = ( 01 00 2 ... )", I'll try to ildasm a DLL with what you describe and copy from there. – Oren Apr 16 '15 at 08:50
  • @Oren Yup. You can find the correct value quite easily - it should be in the `il` file, or you can use reflection to get the fully qualified name, which contains the public key as well. – Luaan Apr 16 '15 at 08:52
  • Okay, your lead was great, and I also found http://stackoverflow.com/questions/10738008/accessing-newly-signed-third-party-dll-gives-error . I have learned today about .Net assemblies more than I ever wanted to know. Did not manage to make it work still. Yet now verified that it works on 64bit (everything strong name signed), and will try to convince the other stakeholders. – Oren Apr 16 '15 at 12:53
  • @Oren Interesting. Are you sure the assemblies are still AnyCPU? Perhaps you mistakenly changed them to 64-bit only? – Luaan Apr 16 '15 at 14:06
  • Hi, how to check? I did not change intentionally. Maybe this is how they were built by the API provider? – Oren Apr 16 '15 at 14:12
  • With corflags, everything I have shows 0 next to 32bit. Does it mean that it is only 64bit? – Oren Apr 16 '15 at 14:21
  • http://stackoverflow.com/questions/18608785/how-to-interpret-the-corflags-flags Okay so I think the answer is no. I have everything with anyCPU. – Oren Apr 16 '15 at 14:28
  • @Oren Is it possible that the old assemblies are cached somewhere? They would have the same version and public key, after all. Can you try on a different computer, somewhere you never tried before? – Luaan Apr 16 '15 at 15:17
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/75414/discussion-between-oren-and-luaan). – Oren Apr 16 '15 at 15:26