Why isn't my console application assembly digitally signed even after I specified it to be signed in the project properties?
Asked
Active
Viewed 302 times
1
-
How do you determine that the executable is not signed? – jdweng Dec 22 '20 at 16:31
-
There is a Digital Signatures tab in exe properties of file – Rod Dec 22 '20 at 16:43
-
How do you know the tab is correct. Maybe the tab is wrong but file is signed? The only real way of knowing is to modify the file. Put a text string in the file and then change the text and see if exe runs. – jdweng Dec 22 '20 at 16:48
-
@jdweng how do you put a string in an EXE file and later try changing that string and still keep the EXE file runnable? In my opinion, the point of signing an EXE file is to ensure that it has a strong name and a valid author (provider) info which is validated by a third-party side. The app loading the signed dlls requires the exact strong names and the unsigned app (exe file itself) is always warned by the OS (Windows) at the time of opening. I mean the purpose of signing here is not likely to ensure the file integrity. – Hopeless Dec 22 '20 at 17:57
-
Substituting a string constant (one character) in an executable will not stop the code from running. A Digital Signature adds a hash to the code so a hacker cannot tamper with the file and make changes. I do not think you understand what a digital signature does to an executable. The digital signature prevents hackers from adding undetected viruses to the executable. – jdweng Dec 22 '20 at 18:26
-
@jdweng thanks for your info, actually I understand the use of digital signature *generally* but not think it's applied to the exe file like that (as I've explained before). I mean the signature can be used to identify the signed object but will generally not cause the object to be useless (e.g: in case of signature embedded in a photo, you can verify if the photo is tampered or not but that photo is always shown as it is - not some kind of blank). I've heard about crackers modifying an existing exe and making it run just fine (using Ollydbg,...), so I did not think tampering makes it broken – Hopeless Dec 22 '20 at 18:36
-
See Wiki : https://en.wikipedia.org/wiki/Code_signing. How can I tell if an EXE is digitally signed? From a Windows operating system: Right click the file the main executable file (.exe), select Properties > Digital Signatures. Under Signature list, select the Signature, and click Details. You will see information regarding the Code Signing certificate that was used to sign the executable. – jdweng Dec 22 '20 at 18:39
-
@jdweng I've just googled around I found that some guys successfully tampered a signed exe and kept its signature as well as running fine. Really in my impression, the `Ollydbg` tool has been used to modify a lot of exe/dlls and I've never thought a signed exe will not run after modified. Its signature will be broken of course (so some warning window may appear) but it should run just fine. If a signed exe can protect tampering, the `Ollydbg` seems to be fairly useless because the publishers can just sign their products. Thanks for your sharing. – Hopeless Dec 22 '20 at 18:59
-
How long did it take the hacker to successfully tamper the file? How large was the executable? The strength of a hash is good if it take a hacker 100 years to tamper. If it takes only 5 minutes than it is not good. As the size of the executable gets larger the time probably increases. That is why the keep on going to newer versions of TLS and encryption algorithm. What they found is using Neural Network programming makes it easy to break the hash. So the newer algorithm are designed to make it harder to break. – jdweng Dec 22 '20 at 19:05
-
@jdweng I just skimmed through how they tamper it, looks like there are some hidden section insides the exe that can be tampered. Anyway if you watch videos about `Ollydbg` (or some other similar tool), you see that a pro can patch an exe in not much time. I think the problem is not decrypting which takes a lot of time, the problem is the OS does not protect the signed exec in the way it should or simply it cannot detect the tampered exec (modified using tool). The cracker may accept to remove all the signature but its main logic can be cloned & modified just fine ... – Hopeless Dec 22 '20 at 19:11
-
...unless it's protected using some other methods (e.g: obfuscation, ...) to make it harder to be tampered at the assembly level. – Hopeless Dec 22 '20 at 19:11
2 Answers
2
Because strong name signing and code signing are different things. Only the later causes the Digital Signature tab to appear in Windows Explorer executable file properties window while what you do is the former.
The text of "Sign you assembly" checkbox in Visual Studio may indeed be a little misleading as it doesn't specify the type of signing it regards to. The whole weight of that clarification lays on the combobox' label below saying "Choose a strong name key file".
See:
Signing of .NET Assemblies
and
difference between signtool and sn or al for assembly signing

user1121956
- 1,843
- 2
- 20
- 34
0
Try strong naming as assembly (I haven't tested it so might not work):
In Visual Studio, navigate to AssemblyInfo.cs.
Add this code below underneath the 'AssemblyFileVersion()' one.
[assembly: AssemblyKeyFile("C:\\ConsoleApp1.exe")]

NC101
- 18
- 2
-
This doesn't work for me. It says ```AssemblyKeyFile``` so shouldn't that be my ```.pfx``` file? – Rod Dec 22 '20 at 20:21
-
Yes it should be. I don't know how to convert it into that extension though. – NC101 Dec 23 '20 at 11:23