I want to learn a little bit about the logic of the execution of a digitally signed exe file. I am trying to invert a byte of a signed exe file, more specifically the SHA1 hash (I know that this modification results in a corrupt file or signature). With signtool I am getting the following output for chrome.exe:
Issued to: Google LLC
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Wed Nov 17 13:00:00 2021
SHA1 hash: CB7E84887F3C6015FE7EDFB4F8F36DF7DC10590E
Is there a tool I can use to change any byte of the SHA1 hash, save the exe and then execute it? I tried different hex editors but can't find the "SHA1 hash string".
I would like to know how Windows handles this kind of modification (execute anyway, error message etc.).
Related
Like many I have received the MSB3325 strong naming error, I am targeting a pfx file and have tried to install the certificate directly to the CSP at the given container. The certificate is installed on the machine I am working on.
I generated the CSR through OpenSSL and received a p7b from a Certificate Authority, which I then converted to pfx with the key used in generating the CSR (I have also tried using online converters from different CAs to ensure I was not messing up the conversion through OpenSSL). I can confirm the pfx certificate contains the same key.
The sn -i cert.pfx VS_KEY_XXXXXXXXXXXXXXXX succeeds in pairing to the container but I get the exact same error and a failed build. I have tried many times to recreate the pfx and delete the container to pair to the new one. Initially I did not sign a password to the certificate (just pressed enter) but I have also tried giving it one, it made no difference.
I am trying to sign a WPF project and so far have been frustratingly unsuccessful.
Am I missing something? Many hours of research and all results come up to use the sn -i command to fix the problem.
I was trying to do an npm install today and ran into an error that looks like this:
The authenticity of host 'github.com (140.82.114.3)' can't be established <trash due to npm overwriting part of the line>
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
I have redacted the actual fingerprint but it was hex digits. In another question some of the answers establish that you should verify the authenticity of this key here. But when I go to this page I see keys in a totally different format:
SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 (RSA)
SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM (ECDSA)
SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (Ed25519)
I'm assuming since the message I saw mentioned ECDSA I should be trying to compare it to the second value, but beyond this, how do I get this value in the xx:xx:xx... format? You would assume that something important like this would be easy to compare so I'm a bit puzzled as to why there seems to be some excessive friction.
The format you're seeing for your fingerprints is the legacy hex format using MD5. Because MD5 is insecure and no longer suitable for use, since OpenSSH 6.8, fingerprints are printed using SHA-256 and base64. SHA-256 is presently considered secure and is a good choice for a cryptographic hash function.
This probably means that you're using a very old version of OpenSSH, possibly on an unsupported operating system, such as CentOS 6. If your OS is no longer supported, you should upgrade to one receiving security updates for everyone's benefit.
If in the meantime you still need to access GitHub, you can download the actual keys (as well as the fingerprints) from the GitHub API. If you save the ECDSA key into a file, say key, then you can run ssh-keygen -l -f key and it will print the fingerprint for that key in a format you can use.
I decided to install Gentoo and it is suggested to verify the cryptographic signature of downloaded files and the checksum. So I went through 100 pages of PGP4Win manual, trying to figured out how to import keys and validate the signature. I have managed to import the keys but I would need to know if it is OK that the signature appears to be in order only when I verify the key's fingerprint. When I just import keys, the signature is invalid.
Another weird thing was that when I compared the checksum of livecd.iso and digests.asc file with WinMD5 checksum was different, so does it mean that downloaded image is corrupted?
Thank you for help
I have to buy a code-signing certificate, for signing Win32 applications, and I was considering whether to pick an EV one.
The advantages of EV certificates I was able to find are:
Immediate Smartscreen reputation establisment (instead of waiting for 3k downloads? [source] )
Maintainance of Smartscreen reputation across certificate renewals [source] (probably a moot point if point 1 applies anyway)
Option for delivery on a hardware token, often not available for normal certificates
I wonder if they bring other advantages, for example if applications signed with them are more trusted than applications signed with non-EV certificates by antivirus, firewalls and other security applications (they get less blocked, provoke more favourable warnings, etc.).
I restate the case I'm most interested in: are you aware of differences in treatment by some specific antivirus/firewall/security application of applications signed with EV certificates, vs. applications signed with standard certificates?
Disclosure: I work for an AV vendor.
I wonder if they bring other advantages, for example if applications
signed with them are more trusted than applications signed with non-EV
certificates by antivirus, firewalls and other security applications
This depends on the vendor making the security application, or their current(*) policy. Both security vendors I have worked for ignored the presence of the certificate when scanning for malware. There are several reasons for this:
Just because the code is signed doesn't mean it is not malicious. It only means it has not been modified after it has been signed. For example, a relatively large number of adware applications is signed.
Malware writes have used stolen certificates in past, and thus we cannot be truly sure it was used by the original author. This is why I mentioned "current policy" above, as this could change overnight.
Verifying a certificate is a complex and relatively slow process which requires reading the whole file from disk - an expensive operation for a non-SSD storage. It also requires performing some public key cryptography operations which are CPU-intensive. Thus for some large executable files checking the certificate might take longer than scanning the file for malware.
And since we generally don't look at certificate at all, it doesn't matter whether it is standard or EV.
I have a different experience than #George Y. Our Code Signing EV-Certificate from Sectigo did help to avoid false positives in Norton 360. I don't know about other Antivirus software - to be tested.
Note:My different experience from #George Y. doesn't imply
that he is wrong. The difference can be due to many
factors, such as Antivirus Software Company policies, ... Also, my
experience is based on positive results I get today from the code
signing. More tests in the future (and experiences from our users) will prove if these positive results were temporary or permanent.
1. Before code signing
Before the code signature, our users got warnings like this:
Even worse, Norton 360 would simply remove a lot of executables and .pyd files automatically - thereby breaking our software completely:
It was a complete disaster.
2. After code signing
Today, I signed our application for the first time with our new EV-Certificate. I signed not only the .exe files, but also the .dll, .so and .pyd files. When signing these files, I first check if they already have a signature, to avoid double signing .dll files from third party opensource binaries that we include in our build. Here is my Python script that automates this procedure:
import os, subprocess
# 'exefiles' is a Python list of filepaths
# to .exe, .dll, .so and .pyd files. Each
# filepath in this list is an absolute path
# with forward slashes.
quote = '"'
for f in exefiles:
cmd = f"signtool verify /pa {quote}{f}{quote}"
result = subprocess.run(
cmd,
stdin = subprocess.DEVNULL,
stdout = subprocess.PIPE,
stderr = subprocess.PIPE,
cwd = os.getcwd(),
encoding = 'utf-8',
)
if result.returncode:
# Verification failed, so the file is not yet signed
cmd = f"signtool sign /tr http://timestamp.sectigo.com /td sha256 /fd sha256 /a {quote}{f}{quote}"
result = subprocess.run(
cmd,
stdin = subprocess.DEVNULL,
stdout = subprocess.PIPE,
stderr = subprocess.PIPE,
cwd = os.getcwd(),
encoding = 'utf-8',
)
if result.returncode:
# Code signing failed!
print(f"Sign: '{f.split('/')[-1]}' failed")
else:
# Code signing succeeded
print(f"Sign: '{f.split('/')[-1]}'")
else:
# Verification succeeded, so the file was already signed
print(f"Already signed: '{f.split('/')[-1]}'")
The results are promising so far. Windows SmartScreen no longer generates warnings. Norton 360 neither. I've tried on both my laptop and a desktop with a clean Norton 360 install - both of them trust the application (unlike before the code signature).
Fingers crossed it will stay this way. Let's also hope other Antivirus software will trust our application.
Note:
As of writing this post, our signed application is only available for testers on https://new.embeetle.com
It will be available soon on our public website https://embeetle.com as well - but not yet today.
I have a process that uses web services via sockets/https. My code is erroring out all of a sudden when using sockets. I'm guessing it's something to do with progress internal certificate manager.
These are the errors that are occurring.
---------------------------
Error
---------------------------
Secure Socket Layer (SSL) failure. error code -54: certificate signature failure: for b0f3e76e.0 in n:\progra~1\oe101c\certs (9318)
---------------------------
Error
---------------------------
Connection failure for host api.constantcontact.com port 443 transport TCP. (9407)
---------------------------
Error
---------------------------
Invalid socket object used in WRITE method. (9178)
I then decided to get the Cert Chain from the site who's service I was using. I ran this command to get this.
openssl s_client -connect api.constantcontact.com:443 -showcerts > certs.out
After getting the certs I extracted each one into it's own file and tiled them cert1.cer, cert2.cer and cert3.cer. I registered them with the certutil and the error was still occurring.
I then converted all three of them using this command.
openssl x509 -in cert1.cer -out cert1.pem -outform PEM
Then tried registering them again and still no solution.
I registered them in proenv this way.
certutil -import cert1.pem
they imported correctly but I am still getting this error. Is there something that I am missing or could this be something entirely different. In the original error the hash b0f3e76e.0 is in fact being generated by the 3rd cert. I attempted to delete the hash in the certs folder and regenerate it. I'm completely clueless at this point. The app has worked for awhile and i remember having this issue in the past but can't remember what fixed it. Seems as though when someone was changing from a virtual drive to a physical drive that progress is installed on this error started popping back up.
Thanks
Sorry I miss understood. YOu can google the b0f3e76e.0 and try to find the rootCA for it. Then copy the contents of it and using certutil -import on it to see if that works for you.
For example:
URL https://alphassl.com.ua/support/root.pem
copy and paste it to notepad. Save it as rootCA.pem
use certutil -import rootCa.pem. This will give you the certificate the ABL program is looking for to hand shake withthe server you are using for ssl socket connection.
Again sorry for misunderstanding.
The server side may have changed the certificate. YOu may want to re-import the certificate from the server using
openssl s_client -connect api.constantcontact.com:443 -showcerts > certs.out
Then after doing the import, see which hash formatted file you are getting the error. You can google it and find the certificate and use certutil -import again for that specific hash formatted certificate.
I had experienced this types of issue before where they all of a suddent change the certificate which can have chain certificates. Also generates from different certificate authority leveling their own company name.
It also could be that the certificate expired. I just looked at the rootCA on the URL I have mentioned, the validity is expired.
Validity
Not Before: Sep 1 12:00:00 1998 GMT
Not After : Jan 28 12:00:00 2014 GMT
You need to find one that has the valid date for expiration.
this solution is in startup.pf in C:\Progress\OpenEdge, edit and add in last line -sslverify 0 ...
example.
-cpinternal ISO8859-1
-cpstream ISO8859-1
-cpcoll Spanish9
-cpcase Basic
-d dmy
-numsep 44
-numdec 46
-sslverify 0