OSR published a Q&A session with someone from Microsoft on their blog. The topic were the changes in requirements of Windows 10 driver signing compared to earlier Windows versions.
In one statement Microsoft Program Manager James Murray said (bold part):
Peter: The new driver signing procedure indicates you have to build a
CAB file to upload for signing, and you sign that CAB file with your
EV Cert. Why a CAB file (and not something common like a ZIP
archive)? How do you build the CAB file? Is there a particular
process or tool to use?
James: CAB was chosen as CABs themselves are PE files. This simplifies
the signing process somewhat, as signtool.exe has “native” support. If
we had chosen a ZIP Archive (note, we’d still like to move that
direction), we would have needed to provide a separate signing
mechanism. Something akin to the HLK studio, a small tool with the
capability to sign ZIP or OPCs.
That surprised me. I am aware of plenty of the PE/COFF details, but was never under the impression that CAB files fit in there. It doesn't seem to be about self-extracting executables containing a CAB either.
I had to open a CAB file in my hex editor to see it for myself, but somehow I was unable to see in what sense the statement would be true.
Can anyone provide details as to how/why CAB files are PE files?
CAB files are not, in general, PE files - they have entirely different structures.
For instance, the CAB file structure starts with the characters 'M', 'S', 'C', 'F' to identifiy it as a Microsoft Cabinet File - while a PE file's structure typically starts with an executable MS-DOS stub.
It may be possible to create a file that is both: both formats allow a certain amount of flexibility, including reserved areas, that might allow the constraints of both formats to be satisfied at once. But in general a cabinet file will not be a valid PE file.
I expect Mr Murray knew that the signtool utility could cope with PE files and CAB files, and assumed that was because CAB files were a special case of PE files, but in fact the tool just has native support for both formats.
Related
Just out of curiosity, I would like to understand the behaviors of those self contained installer programs and try to write a simple installer myself.
I did some search on Google and did not really find a useful article explaining it. However AFAIK, an installer should have a small chunk of code residing in the top of the executable. It pulls data out from the rear of the executable and interprets them as files according to an inventory file (probably xml?). Other operations such as writing register entries can also be specified in the inventory file.
Now is my guess of the file structure true? If so I think I just need to read about the PE format and then it would be conceptually easy for me to implement it. If my guess is wrong, I would love to know how exactly it works.
Thanks for your time!
Normally installer packages are self-contained compressed executables (SFX) that contains:
A small installer executable
A compressed file structure with files to extract
Some configuration files (xml, ini, json, properties) to define file destinations, registry entries, desktop/start menu shortcuts, instalation modes
Extra files (dll, icon/image resources) to make the installer work.
For MSI packages, it's a bit more complex. It's a propietary format packaged as a SQL database in a COM structured storage file. It contains also a virtual file system inside the installation package (file access using file streams).
You can review some free tools and check many typical features to make installer executables like:
Wix (For MSI installers) http://wixtoolset.org/
Nullsoft Installer (NSIS) http://nsis.sourceforge.net/Main_Page
Inno Setup http://www.jrsoftware.org/isinfo.php
For Windows it's pretty much
Declarative: MSI, AppX, ClickOnce
Imperative: any number of third party tools, scripts and home grown EXEs
MSI is typically your best choice. The runtime is already part of windows so when you double click the MSI database MSIEXEC takes over. The point of the declarative models is to separate what needs to be done from how you do it. The imperative models are basically some simple to complex framework to write procedural code to do the actual installation work.
It's far to broad of a question to ask in detail how any of these work at a low level. For MSI it's all in the Windows Platform SDK documentation on MSDN.
Universal Windows apps are in .appx file, which is simply a zip of a bunch of files and metadata. Most of the metadata files are extensively documented on the Microsoft website and are trivial to parse and/or regenerate. However AppxSignature.p7x remains a mystery.
From this diagram (source):
AppxSignature.p7x should have hashes of the AppxBlockMap.xml, content & directory hashes, and a signature. However I cannot find any documentation of the AppxSignature.p7x file itself. Ideally I would like to use an alternative tool to produce and verify this signature, e.g. openssl/gnutls or similar. A practical use for this is to update and repackage apps on Linux, and prepare .appxupload file for the Windows Store.
As described in the blog post you link to, the AppxBlockMap.xml file stores cryptographic block hashes for every file in the package. This file is verified and secured with a digital signature when the package is signed using authenticode.
So, on windows, you have two tools:
MakeAppx.exe that creates the package (.zip format) and the blockmap file at the same time. This is important, as what's in the block map corresponds closely to the .zip file bits, you can't just any zipping tool for this step, you must program the zip/app package creation using some ZIP API.
SignTool.exe that adds the signature to the package using "standard" authenticode.
With the Windows API you can do the same as MakeAppx using the
Packaging API and you can do the same as SignTool using The SignerSign function.
The whole MakeAppx process is not documented IMHO, but the blockmap schema is in fact described here: Package block map schema reference which is relatively easy to understand.
The Authenticode signature for PE document is documented here: Windows Authenticode Portable Executable Signature Format
But it's only for PE (.dll, .exe, etc.) files (note it's also possible to sign .CAB files), and I don't think how SignerSign builds AppxSignature.p7x is documented. However, there is an open source tool here that does it here: https://github.com/facebook/fb-util-for-appx. You will notice this file https://github.com/facebook/fb-util-for-appx/blob/master/PrivateHeaders/APPX/Sign.h that declares what should be used as input for signing. I have no idea where they got that information.
The P7X format is just 0x504B4358 ("PKCX") followed by PKCS #7 data in the DER format. DER is described by ASN.1.
This question might seem to be duplicated with this and this that are similar. But it is not! First- I am getting this error from the setup file and not from the program that I am distributing Second -the version is different, the directories in Installshield 2009 an 10.5 differ. .
I'm trying to fix an error caused by Windows compatibility mode in my setup, which is built with Installshield 10.5. So far my research led me to a conclusion that i need to add [this][3] to my manifest file. I saw that Microsoft's tool mt.exe could extract a manifest file from a dll, however I did not see anywhere that it can extract it from an executable file.
So my questions are the following:
Is there any way to view the manifest file of a Setup.exe built with Installshield?
Is there any way to configure this manifest file for the certain project in Installshield?
[3]Can one edit an InstallShield setup.exe's manifest file?
As far as I know, mt.exe will work fine on EXE files; both EXE and DLL files are Portable Executable (PE) files, and PE files use the exact same structure for resources such as the manifest. Visual Studio, CFF explorer, and countless other tools (including raw resource APIs) will also work to view and possibly update manifests in general.
However for a built InstallShield setup.exe, there is a twist. InstallShield uses areas in the file to store information that are not described in the PE format. Tools that update the resources on an EXE can inadvertently destroy this data as they do not expect it to be there, nor do they know how to detect or adjust it.
InstallShield 12 or so and later allow you to specify a manifest, and it selects the manifest from files it ships that you can update before it adds them to the setup.exe. In addition, there is a tool called ISReMan that is aware of the extra information and can update the manifest correctly when that data is present.
By the way, it's generally helpful to mention the actual problem you're trying to solve, in case the method you've chosen (in this case updating the manifest) is not the correct solution. Note as well that InstallShield 10.5 is over 10 years old, and knows nothing about UAC, PCA, and other Vista and later technologies; adjusting the manifest may not help fix, say, an elevation-related problem.
Note as well that I am paid to work on InstallShield, so I may be biased when I recommend things like upgrading. :)
I've a java project which has set of libraries and xml files in separate directories. But when I see cabinet file which I created it has all the files in one place (with out sub directories though I can see files). Can I create a cabinet file which includes sub folders?
If it is not possible to include directories in cabinet file, once I release cabinet file to my end user for his installation then should I need to provide INF file to him along with cabinet file?
Can any one provide sample INF file for this problem?
What is the immediate step an end user will perform once he receive cabinet file? Will he open it with IE?
To answer your first question: Yes cabints do support directores. See this blog post for example. If you use makecab as tool you can create a directive file which controls which files are zipped and into which directories (may be different ones) they are extracted.
Example:
C:\temp>type files.txt
C:\temp\test1\files.txt
.Set DestinationDir=TestDir1
C:\temp\test1\test2\2.txt
.Set DestinationDir=TestDir2
C:\temp\test1\test3\2.txt
With the following command I could create the cab file
makecab /d "CabinetName1=test.cab" /f files.txt
When I open the cab with 7-Zip I can see that the file 2.txt will go to TestDir1 and TestDir2 as expected. That said why do you bother with a cab file? I your application does not need an installer you could use a zip file with much less hassle.
But if you need to create some installer I would recommend to use the WIX toolkit where you "only" need to declare what gets installed to which location in an xml file. For more infos please consult the manual. The WIX toolkit also creates the cab files needed by msi for you.
You want to distribute a java application which may be largely OS independant but the installer, if you need one, is not. Please use for each target platform the preferred installation mechanism to ensure the least amount of problems to your customers.
Yes I know this advice sucks. But deployment is also an important development activity which always was (and I fear always will be) much more complex and error prone than one might initially hope.
My installer build "signs" a DLL using a Code Signing certificate during the build process.
I've noticed that if I try to build twice in succession, the second build fails because the DLL is already signed so signcode chokes. Obviously I can fix this by signing a copy of the DLL in the build, but the problem intrigued me:
Is it possible to "unsign" a DLL, and if not, why not...?
signtool remove /s C:\path\to.exe.or.dll
signtool is available in Windows SDK, and must be at least from Windows 8 SDK kit (version 6.2.9200.20789) to have the remove command supported.
You can use delcert.exe from the this XDA Forum post.
here is a small tool that strips (removes) digital sign (Authenticode)
from PE executable files like *.exe, *.dll, *.mui, etc.
It's fairly easy to remove the signature from a .dll file using the ImageRemoveCertificate API.
You don't have any language specified in your tags but this article shows how to implement it in C#. Remove digital signature from a file using C#
Other than that, if you are looking for a simple tool to do the work for you, you can use FileUnsigner.
Another possible option is to switch to the SignTool.exe. It comes with the Windows SDK and signing a binary that has already been signed does not generate an error. I use signtool.exe in my build process and haven't any difficulties with it, even when something is already signed.
Also, check out the question What's the main difference between signcode.exe and signtool.exe?
Sure it's possible, but not trivial.
Although it would be easier to save a copy of the presigned DLL.
This digital signature is little more than an extra section appended to the end of a PE file. You could write a program that deleted the signature, if you want.
It's not quite as simple as truncating the file; you have to remove references to the signature in the file header. It could get complicated if the DLL has multiple signatures and you just want to remove one.
The format of a PE file is publicly documented here
Check if your build tool supports "Re-signing". This should replace all existing signatures.
If not, you can use Stud_PE to remove the signature block.
Open the DLL or EXE in Stud_PE, go to the sections tab, right click the digital signature section and select "Delete section". However, this needs user interaction. Old versions of the tool could destroy the file.