- Grab 1 arbitrary signed executable from your system. Preferrably a Microsoft one to make the test more catching.
- Append garbage data at EOF, but make sure it's size is a multiple of FileAlignment (found in the Optional Header). Use hex editor or just "copy /b source.exe+garbage.data new.exe"
- Increase the size of the certificate as given by its entry in the Data Directories. Increased the value by what you added in step 2. Most easily done with a PE editor.
- Also increase the size of the certificate as given inside the certificate itself. It's the first 4 bytes. Do this with a hex editor.
- Finally, also update the checksum as found in the Optional Header. This last step is likely only necessary if you're modifying a boot application.
Verify the certificate by right-clicking on the file and go to Properties, and then to Digital signatures.
So what does this mean? Have currently no idea, but I think one should use other means (like SHA1 of file) for validating such files on the system. But the added data/code will not be executed, so it will not affect the functioning of the target program, although data is hidden in the file. That means the real usage likely is limited to data hiding (steganography). For instance, it may be possible to spread data around with chunks inside several files too.
So what do you think? Is there something wrong with how Windows evaluates the digital certificates in executables? Or is it as expected but irrelevant?
A PoC, DigitalSignatureTweaker is now added; http://reboot.pro/fi...gnaturetweaker/ or by following my mediafire account. It supports both 32-bit and 64-bit compiled executables and runs on both x86 and x64 OS too. The new version also supports compression, encryption and timestamp manipulation. In addition, a separate program is included to extract the hidden data. There's more information in the included readme.