Deploy signed msi file to multiple machines using group policy

Windows Active Directory have two ways to deploy an application:

• Publish to a user
• Assign application to a user or a computer

Open Group Policy Editor, User Configuraiton->Software Settings->Software Installation. Then Click software installation container and select New->Package commands

More things:
The Group Policy can be used to deploy three kinds of files: msi (windows installer package), mst(transform files) and msp(patch files)

If you want to modify signed msi file, 

create a certificate and sign it using signtool.exe: the windows way

It is assumed that you have installed the Visual Studio 2005, and open a command promote for it:
(1) create the certificate:
makecert.exe -sv mykey.pvk -n "CN=Mycompany Inc." mycert.cer
now you will have the private key in mykey.pvk and the certificate in mycert.cer
(2) Convert the certificate to the software publisher certificate (.spc) format
cert2spc.exe mycert.cer mycert.spc
It will generate the mycert.spc, which will use together with mykey.pvk to sign your executable.
(3) Before sign it, you have to comtine these two files into a single PFX file
pvk2pfx.exe -pvk mykey.pvk -pi -spc mycert.spc -pfx mycert.pfx -po
You always have to specify a password for -po.
(4) now you can sign your code using
signtool.exe sign /f mycert.pfx /p /t /v filetobesigned
The url can be one of he following:
http://timestamp.verisign.com/scripts/timestamp.dll
http://timestamp.globalsign.com/scripts/timestamp.dll
http://timestamp.comodoca.com/authenticode

Add a customize data to an msi installer

The idea is to append the data to the certificate section at the end of the file. A little bit background first:

• How to generate/verify the signature: it hashes the executable and then used to make a digital certificate which is authenticated by some authority. This certificate is attached to the end of the PE executable in certificate table. When the executable is loaded, windows will compute the hash value and compares with the value in the certificate table. 
• There are three areas of PE executable are excluded from the hash computation:
• the checkum in the optional windows specific header, 4 bytes
• the certificate table entry in the optional windows specific header. 8 bytes
• The Digital certificat section at the end of the file. Variable length.

How to add the payload to a file without violate the signature: 

• PE header offset located at 0x3c, read that offset as pe_offset
• pe_offset will start with "PE\0\0", which is 4 bytes
• From the pe_offset, find out the Certificate Table Entry (after 28 bytes COFF header and other header 120 bytes), so the offset to the pe_offset should be 0x98 (152bytes)
• You can first read the certificate table entry offset (4 bytes), and then the size of the certificate table entry (4 bytes)
• Modify the size if you want to append the data.
• Now seek to the certificate table entry (the absolute location is in the previous certificate table entry offset), change again the certificate size if you modified it.
• Then go to the end of the file and add the new payload.
• Possibly calculate the new checksum of the file.

Note: this is true for 32 bits, and payload needs to be 64bits aligned. All the 32 bits constatnats are little endians.

Troublehsoot applications on Windows

I am looking at the ways to troubleshoot windows application crash. When a program error occurs in windows, the system will try to find a program error handler. If the error is not handled, the system will try to process un-handled errors by looking at registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug. If the Auto name entries, it will pop up a message box and need user to confirm. The Debugger specifies the which debug application will be used.

• Dr. Watson (drwtsn32): The debug tools that can create system log and core dump files. You can enable it by running "drwtsn32 -i"
• userdump.exe : This will work in Windows 7.
• In Windows 7, The Dr. Watson is replaced with the "Action Center", so you have to do following:
• Run Task Manager  
• Go to Processes tab and right-click on the crashed process
• Select the Create Dump File item;Select the Create Dump File item
• Pick the .DMP file created;
• Open Start->Run, type %USERPROFILE%\AppData\Local\Microsoft\Windows\WER\ReportArchive string and hit Enter;
• After that you will see a folder (or a few folders), the name of which starts with "Report"
• Collect the Report.wer file from the last created folder.

shutdown vs. close in the socket

I was using the boost asio in windows XP to develop a simple proxy. The proxy will relay the traffic between the browser and the upstream server. Every time when some data is received from the server side, the  boost c++ asio async_write , will be used to send all the response to the client socket, and then it will try to read more from the server side socket. If the server side closes the connection, the client side should already flush out the http response received, so it would be safe to close the client side socket.

However, this did not work sometimes, for example, http://sourceforge.net/projects/tailforwin32/ works for firefox but does not work for IE8. Even if the log shows that all data has been written to client socket, the page just cannot be displayed.

The IE8 may detect the connection close before read all the data in the wire: when using step debug, the IE8 can handle it properly. The idea is to shutdown both read and write of the client socket instead of close it, so that the IE8 can read the data and detect the socket is closing. Here is a good article on socket close vs. shutdown. The close will close the socket id for the process, but other process may still use it, and it is still open for read and write. The shutdown will close the read/write pipe for all process. Any read/write will result in EOF.

Stream based filter

I am thinking to create a filter which can parse/decompress/scan partial read HTTP data. The idea is to use three buffers and implement a customized istream and ostream, both will use a customerized streambuf. In the compression process:
a). the buffer to store compressed data in the customized streambuf.
b). when overflow is called, the first buffered data sent to the de-compressor which may also buffer the data internally. When it outputs the data, it may be sent to the third buffer.
c). the user defined stream buffer.

The streambuf has a few function has to be override:
a). Overflow() in output stream: there is no space in the buffer, write it out. The data between ibegin and iend is sent to the gzip library to compress to a file
b). Underflow() in input stream: there is no more character in the buffer, read more. The data read is decrypted by call gzip library and then dump to input buffer.

An other option is to use boost::iostreams::gzip

http://www.codeproject.com/KB/stl/zipstream.aspx