I use signtool.exe to codesign a Windows executable.
Which options of this tool can be used to define that a few bytes should be omitted from the hash calculation, and thus allowing that a digitally signed executable can have 8 or 16 bytes modified later?
This technique has been used by Mozilla (their .exe installer is different for each download, but has the same digital signature), see How can a .exe be modified and still keep a valid digital signature?.
The WinAPI function ImageGetDigestStream has an option DigestLevel to exclude resource information from the hash computation, but how to use this option when actually with signtool.exe or a similar tool?
This is explained by Didier Stevens in an article here: It's in the signature and he also provides a tool "disitool" to manipulate the signature.
Here are the steps to sign a file using Authenticode, and to append some data to it without breaking the signature:
A) Create a code siging certificate (you'll be required to enter passwords):
MakeCert /n "CN=MyOrg" /r /h 0 /eku "1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13" /sv MyOrg.pvk MyOrg.cer
note: 1.3.6.1.5.5.7.3.3 is szOID_PKIX_KP_CODE_SIGNING and 1.3.6.1.4.1.311.10.3.13 is szOID_KP_LIFETIME_SIGNING. This will create a private key file and a certificate file.
B) Add certificate to store (needs admin rights, could be a different store):
Certutil -addStore TrustedPeople MyOrg.cer
C) Create a Pfx file to sign:
Pvk2Pfx /pvk MyOrg.pvk /pi [Password goes here] /spc MyOrg.cer /pfx MyOrg.pfx
D) Sign your file:
SignTool.exe sign /fd SHA256 /v /a /f MyOrg.pfx /p [Password goes here] MyFile.exe
At this point MyFile.exe is signed using Authenticode:
E) Create some data.txt file. I've created one that just contains the "[Kilroy was here!]" text.
F) Now run disitool:
python.exe disitool.py inject --paddata MyFile.exe data.txt MyFile2.exe
And here is the result, MyFile2.exe is still valid without resigning the file:
While you can see data.txt's content added to its end:
From the original file's end:
Related
I signed a .dll file with the help of those doc, makecert, pvk2pfx, signtool.
And the step as follow:
C:\Windows\System32>Makecert -pe -eku 1.3.6.1.5.5.7.3.3 -sv test.pvk -r -n "CN=forTest" test.cer
Succeeded
C:\Windows\System32>Cert2spc test.cer test.spc
Succeeded
C:\Windows\System32>pvk2pfx -pvk test.pvk -pi qweasdzxc -spc test.spc -pfx test.pfx -f
C:\Windows\System32>signtool sign /fd sha1 /f test.pfx /p qweasdzxc
D:\testDotDLL.dll
Done Adding Additional Store
Successfully signed: D:\testDotDLL.dll
Each step return success. but when I do verify, I get the error as below. Noticed, as shown in the below figure, I have added this cert to Trusted Certification Authorities store.
C:\Windows\System32>signtool verify D:\testDotDLL.dll
Index Algorithm Timestamp
========================================
SignTool Error: A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider.
Number of errors: 1
When I try to sign my exe file using signtool from windows, I used this command in a command line:
C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86>SignTool sign /debug /fd SHA1 /a /f certificate.crt xone.exe
But I got this:
The following certificates were considered:
Issued to: ***********
Issued by: ZeroSSL RSA Domain Secure Site CA
Expires: Sat May 28 01:59:59 2022
SHA1 hash: 71A05C21AC6C48EB5C253811D9E66D7E3D2443B2
After EKU filter, 0 certs were left.
After expiry filter, 0 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.
I don't understand where the problem is.
According to the manual of ssh-keygen
, -k flag generates some KRL file. What do these KRL files mean and how I specify a KRL location while using this flag?
According to FreeBSD Manual Pages BSD General Commands Manual :
KEY REVOCATION LISTS
ssh-keygen is able to manage OpenSSH format Key Revocation Lists (KRLs).
These binary files specify keys or certificates to be revoked using a
compact format, taking as little as one bit per certificate if they are
being revoked by serial number.
KRLs may be generated using the -k flag. This option reads one or more
files from the command line and generates a new KRL. The files may ei-
ther contain a KRL specification (see below) or public keys, listed one
per line. Plain public keys are revoked by listing their hash or con-
tents in the KRL and certificates revoked by serial number or key ID (if
the serial is zero or not available).
Revoking keys using a KRL specification offers explicit control over the
types of record used to revoke keys and may be used to directly revoke
certificates by serial number or key ID without having the complete orig-
inal certificate on hand. A KRL specification consists of lines contain-
ing one of the following directives followed by a colon and some direc-
tive-specific information.
serial: serial_number[-serial_number]
Revokes a certificate with the specified serial number. Serial
numbers are 64-bit values, not including zero and may be ex-
pressed in decimal, hex or octal. If two serial numbers are
specified separated by a hyphen, then the range of serial numbers
including and between each is revoked. The CA key must have been
specified on the ssh-keygen command line using the -s option.
id: key_id
Revokes a certificate with the specified key ID string. The CA
key must have been specified on the ssh-keygen command line using
the -s option.
key: public_key
Revokes the specified key. If a certificate is listed, then it
is revoked as a plain public key.
sha1: public_key
Revokes the specified key by its SHA1 hash.
KRLs may be updated using the -u flag in addition to -k. When this op-
tion is specified, keys listed via the command line are merged into the
KRL, adding to those already there.
It is also possible, given a KRL, to test whether it revokes a particular
key (or keys). The -Q flag will query an existing KRL, testing each key
specified on the command line. If any key listed on the command line has
been revoked (or an error encountered) then ssh-keygen will exit with a
non-zero exit status. A zero exit status will only be returned if no key
was revoked.
I'm trying to format whole USB from windows commandline.
In Linux it's quite easy - veracrypt --create diskPath
But when i'm trying to do that in windows it's impossible.
I'm trying to use this command
"VeraCrypt Format.exe" /create \\?\Volume{ad4200bf-2236-11e8-9b79-bcee7b594766}\ /password test /size 100M
Also this:
"VeraCrypt Format.exe" /create F: /password test /size 100M
Also - i want to encrypt whole partition, not only 100M, but i can't execute /craete without /size
VeraCrypt format command goes like this:
"VeraCrypt Format.exe" [/n] [/create] [/size number[{K|M|G|T}]] [/p
password] [/encryption {AES | Serpent | Twofish | AES(Twofish) |
AES(Twofish(Serpent)) | Serpent(AES) | Serpent(Twofish(AES)) |
Twofish(Serpent)}] [/hash
{sha256|sha-256|sha512|sha-512|whirlpool|ripemd160|ripemd-160}]
[/filesystem {None|FAT|NTFS}] [/dynamic] [/force] [/silent]
Now what you were trying should go like the below. You are missing the path or the subset of the parameters.
Create a 100 MB file container using the password test and formatted using FAT:
"C:\Program Files\VeraCrypt\VeraCrypt Format.exe" /create c:\pathofthevolume\testvolume.hc /password test /hash sha512 /encryption serpent /filesystem FAT /size 100M /force
And if you want to mount that automatically, then it should go like this:
Mount a volume called testvolume.tc using the password test, as the drive letter X.
veracrypt /v testvolume.tc /l x /a /p test /e /b
Refer the source LINK for details.
Hope it helps.
I am wondering what are the GUID suffixes for the RSA key container files stored in the machine and user key container stores. I cannot identify some of these as key containers through CAPI/CNG, although I'll expose my case using command line tools instead. Commands below are for PowerShell in an elevated prompt. On most machines, the GUID suffix is the same for all these file names, but on this one there are four different GUIDs, while the API is returning only keys with only one. What is this GUID? I do not like random secrets stored by I do not know what on my machine; are they safe to delete?
The content of the machine store directory is:
> ls -n $env:ProgramData\Microsoft\Crypto\Rsa\MachineKeys | sort { "$_"[-3..-1] }
d1f9044f5d7345da71c0d2efd2e4f59e_e9f96f2e-b8b7-49b2-85a5-840195eca603
d6d986f09a1ee04e24c949879fdb506c_a4dc5a56-574d-4e4b-ba8d-d88984f9a6c5
6de9cb26d2b98c01ec4e9e8b34824aa2_a4dc5a56-574d-4e4b-ba8d-d88984f9a6c5
76944fb33636aeddb9590521c2e8815a_a4dc5a56-574d-4e4b-ba8d-d88984f9a6c5
d6d986f09a1ee04e24c949879fdb506c_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
d1f9044f5d7345da71c0d2efd2e4f59e_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
76944fb33636aeddb9590521c2e8815a_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
6de9cb26d2b98c01ec4e9e8b34824aa2_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
ba8e1b9b5510957b3af7b811f05660de_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
d1f9044f5d7345da71c0d2efd2e4f59e_c6a7fc9d-32a6-41e4-afd5-7dc7b822029e
I sorted the list by the last three characters, so that it's easy to see in a glance that there are 4 distinct GUID suffixes to the key container files. Now let's enumerate the key reported by all installed CSPs. I'll get the list of providers, and later the list of each provider's keys using the certutil tool that comes with Windows. Its output requires some regex magic for parsing, which is not essential, just convenient:
> certutil -csplist | sls '^Provider Name: (.*)' | %{ $_.Matches[0].Groups[1].Value }
Microsoft Base Cryptographic Provider v1.0
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider
Microsoft Base DSS Cryptographic Provider
[...snip...]
The output for a single key lists the name, flags and the key container ID, the latter matching respective file name in the above directory (of course, we can see more keys from additional KSPs, smart cards, TPM etc.). Example for one provider (the -q makes some providers fail silently instead of asking for user's action, such as inserting a SmartCard):
> certutil -key -q
Microsoft Strong Cryptographic Provider:
iisConfigurationKey
6de9cb26d2b98c01ec4e9e8b34824aa2_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
RSA
AT_KEYEXCHANGE
iisWasKey
76944fb33636aeddb9590521c2e8815a_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
[...snip...]
Some key names are just GUIDs too, but if we grep out only the lines that start with at the least 20 hex digits, there will be only the IDs listed. So all key IDs from all providers can be concisely shown with:
> certutil -csplist | sls '^Provider Name: (.*)' | %{ $_.Matches[0].Groups[1].Value } |
%{ certutil -key -q -csp "$_" } | sls '^\s+[0-9a-f]{20}.+' | sort -u
597367cc37b886d7ee6c493e3befb421_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
6de9cb26d2b98c01ec4e9e8b34824aa2_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
76944fb33636aeddb9590521c2e8815a_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
ba8e1b9b5510957b3af7b811f05660de_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
d6d986f09a1ee04e24c949879fdb506c_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
f0e91f6485ac2d09485e4ec18135601e_f7fe3b04-ef9b-4b27-827f-953c5743e2ec
Here are actually 2 more keys than there are in the MachineKeys directory (they come from the KSP, in fact, certutil -key -csp KSP shows them, if you are wondering). But the fact is they all have the same GUID suffix _f7fe3b04-ef9b-4b27-827f-953c5743e2ec.
The machine was installed by the vendor (an HP notebook, to be exact). This is unlike other machines, that we assemble or buy barebone and install and configure by ourselves. And I am working with some sensitive data sometimes, so I am indeed paranoid vetting the software thoroughly before allowing machines to access sensitive data.
The OS is Windows 10, if that matters, but the same type of storage has not changed from Windows 7, AFAIK, even with the introduction of the new CNG API in 8.0 (or 8.1?).
Just in case anyone would find useful a PowerShell snippet to readably list keys by provider, I used this command:
> certutil -csplist | sls '^Provider Name: (.*)' | %{ $_.Matches[0].Groups[1].Value } |
%{ Write-Host -for Yellow "`n$_"; certutil -key -q -csp "$_" }
Found the answer here: https://serverfault.com/a/642279/451491
The file naming convention is x_y, where x is a random GUID to
uniquely identify the key, and y is the machine GUID found at
HKLM\SOFTWARE\Microsoft\Cryptography.