Using an older version of VMWare Tools

Lost enough time with this already so I'll be short. First of all, yes, sometimes the latest version of the VMWare Tools can fail and you want to downgrade. I'm looking at you VMWare Tools 8.8.0 from VMWare Player 4.0.0 using a Windows 2000 image! And as you may have already found out, when that occurs, the VMWare Software as well as the VMWare community are less than helpful.

In case you're running the VMWare Player on Windows, to emulate another Windows virtual platform, here's what you should know:
  1. After they are downloaded by the Player, the VMWare tools are installed, as a windows.iso file, in your VMWare installation directory (typically C:\Program Files (x86)\VMWare\VMWare Player\). It is that ISO image that is mounted in the virtual machine during installation.
  2. You can obtain older versions of the VMWare Tools by navigating the not-intended-for-users VMWare Software Update directory, starting at http://softwareupdate.vmware.com/cds/vmw-desktop/player/.
  3. The VMWare Tools download is then found in <version>/<build>/windows/packages/ (eg. http://softwareupdate.vmware.com/cds/vmw-desktop/player/3.1.5/491717/windows/packages/ )
  4. Of course the download is not provided as an ISO, because that would be too easy. Instead, it's a tar of an exe that silently extracts and copies (overwrites) a new windows.iso in the VMWare directory. Thus, before you run that exe, you may want to rename your old windows.iso to something else, so that you can both tell whether the downgrade process completed successfully and have the ability to switch back between ISOs if needed.



cathash is a multiplatform MS CAT/Authenticode SHA-1 generation, inspired by cathash by Michel I. Gallant, but not using CryptCATAdminCalcHashFromFileHandle, and thus able to run on UNIX platforms, including big-endian ones.

It is intended for the computation of the custom SHA-1, used by Microsoft and others, to verify the authenticity of Windows executable (or regular files), using the algorithm detailed at the end of the "Windows Authenticode Portable Executable Signature Format" specifications.

The utility was heavily validated against Windows system files (32 and 64 bit), MSVC generated files, MinGW/MinGW-w64 generated files and so on, so it is expected to be fully compliant with the MS SHA-1.
If compiled on Windows, and unless you comment the VALIDATE_HASH define, the program will also validate its computation against the one from CryptCATAdminCalcHashFromFileHandle, for extra safety.

By the way, if you are interested in producing your own implementation, you may want to note that the MS specs omit the fact that the optional extra PE data, starting at SUM_OF_BYTES_HASHED, needs to be padded to the next 8 byte boundary for hashing.

Outside of its upcoming libwdi usage, this utility may come handy for UNIX users needing to validate the authenticity of Windows files.
The source, which comes along with a (signed) 32 bit Windows executable can either be downloaded here (direct link) or here (SourceForge).
You can also directly access cathash.c, to compile it using any of Visual Studio, WDK, MinGW, cygwin or UNIX based gcc.

IMPORTANT NOTE: As reported by Abid Bhat, some Windows XP system files, such as C:\Windows\system32\drivers\update.sys, C:\Windows\Driver Cache\i386\sp3.cab or C:\Windows\Driver Cache\i386\driver.cab, are not getting the expected hash when computed by the current version of cathash. I'll look into it when I get a chance, but it may take a while...


LINK : warning LNK4044: unrecognized option '/lib'; ignored

Error above from the WDK driving you crazy? And when you try link /lib everything is fine?

Well, How about removing that /nologo you have before /lib. Better now? And yes, I agree, whoever designed the MS linker to be this mind-numbingly picky about its option order should get a well deserved pie in face:
E:\WinDDK\7600.16385.0>link /lib /nologo

E:\WinDDK\7600.16385.0>link /nologo /lib
LINK : warning LNK4044: unrecognized option '/lib'; ignored
LINK : warning LNK4001: no object files specified; libraries used
LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
LINK : fatal error LNK1561: entry point must be defined




As part of the ongoing effort to add 7z compression to libwdi, I am publishing bin2coff, which is an improved version of the tool of the same name by Vortex. bin2coff is aimed at generating MS COFF object files that are simple wrappers for binary data, and that can be used by the MS (Visual Studio, WDK), MinGW (MinGW32, MinGW-w64) and other linker tools. Such a tool can be especially useful if you want to generate a library that contains a large chunk binary data. For instance, and this is what I plan to use it for in libwdi, you can use it to embed a complete 7z archive in a cross-compiled Win32 static library file, which you will then be able to extract at runtime.

What this version of bin2coff brings is 64 bit compatibility (MinGW-w64), the provision of a size variable besides the binary data, as well as the full sourcecode. A 32 bit Windows executable is also included in the archive, which you can either download here (direct link) or here (SourceForge).
Usage: bin2coff bin obj [label] [64bit]

  bin  : source binary data
  obj  : target object file, in MS COFF format.
  label: identifier for the extern data. If not provided, the name of the
         binary file without extension is used.
  64bit: produce a 64 bit compatible object - symbols are generated without
         leading underscores and machine type is set to x86_x64.

With your linker set properly, typical access from a C source is:

    extern uint8_t  label[]     /* binary data         */
    extern uint32_t label_size  /* size of binary data */

If, for some foolish reason, or just because you like it when things blow up in your face, you want to integrate bin2coff generation with libtool, you will find that you need to generate a .lo wrapper. In that case, the following Makefile excerpt might be of interest to you:
wdi_data.lo: bin2coff
# $* is the target without extension - here 'wdi_data'
 bin2coff $*.7z $*.o $(bin2coff_OPTIONS)
# libtool won't let us get away with a mere .o - we have to generate a .lo wrapper.
# What's more, the first comment from the .lo is mandatory and must contain the libtool version
 @echo "# Generated by $(shell $(LIBTOOL) --version | head -n 1)" > $@
 @echo "pic_object='$*.o'" >> $@
 @echo "non_pic_object='$*.o'" >> $@


Access denied and Windows 7

One of the annoying aspects of using NTFS is that, from time to time (eg. if Windows 8 preview corrupted your Windows 7 partition so bad that you had to reinstall the whole OS - see post #7), Windows will decide that you are no longer entitled to access your files, and while performing some operation or other you'll get something like:
There's nothing more infuriating in terms of computing than being denied access to files you should have access to.

The solution? Open an elevated command prompt and issue:
takeown /R  /F <Drive or directory>
Icacls <Drive or directory> /reset /T


Free code signing certificate for Open-Source Developers

After seeing a few "John Doe - Open Source Developer" authentication certificates pop up when installing Open Source packages on Windows, and investigating their origin, I was pleasantly surprised to find that Certum, which is a Certification Authority based in Poland, currently offers free Windows Authenticode signing certificates for Open Source Developers.

This means that, as an Free or Open Source Developer on Windows, you now have means to sign your applications and turn the following:

into the much nicer:

Obviously, this is great news for anyone dabbling into FOSS development, as it means we can now provide end users with Windows applications that they will see as trustworthy, without having to subscribe to the whole "your trustworthiness is only as big as your checkbook" scam.

To obtain your free code signing certificate then, you should follow the instructions provided here or go directly to the registration form.

Once you have submitted the form, you should receive an e-mail (in about a day) that takes you through the key generation process. This is one of the 2 steps you will need to complete to obtain the signing credentials, the other being the provision of some proof of your identity and FOSS involvement to Certum.
Also, be mindful that this first step results in the credential's private key being generated in your browser's store (rather than on Certum's servers, which is definitely a good thing), so you must ensure that, when you retrieve the final Authenticode credentials, you will do so using the same browser and the same machine as the one you used when completing this step. Else, you will not be able to export your credentials, which includes the private key, for SignTool.

The other step you will also need to complete is the provision of a proof of identity (copy of your passport, etc.) as a FOSS developer, since an Authenticode certificate is really an identity verification process.
While the Certum documentaion states that your proof of identity should be counter-signed by an official third party, I found it wasn't necessary. However, you should make sure that your proof of identity can be linked to your participation in public FOSS projects, so that Certum can confirm the validity of your request.

In all, it took about 2 days to obtain my Authenticode certificate, and I can't thank Certum enough for going against their obvious commercial interests in order to help the FOSS community. If you or your employer ever needs to purchase a commercial certificate, I hope you'll consider using Certum, as a reward for their efforts.

Now, one last hurdle you may face, after you've completed the whole process, is how to obtain of the full credential, i.e. private key + public key certificate, in the form of a p12 or pfx file, so that you can use it with SignTool.

As you will find, the default web interface ("Save binary" / "Save plain") only provides a download link for the public key certificate, which is useless for signing applications as access to the private key is also required. Thus you need to be able to export the private key along with the certificate, in a package that SignTool can consume. To do that, you first need to click on the "Install" button, to get the whole credential imported onto your browser security store (if prompted, make sure you mark the private key as exportable). Then, once in your store, your browser should provide the option to export it along with the private key, either as a p12 or pfx (and prompt you for a password to secure private key access). But please remember that, because of the private key generation mechanism, you must use the same browser as the one you conducted step 1 with, else you will not be able to import the final Authenticode credentials.

Addon: If you ever find that, even though you properly signed an executable requiring elevated access, the icon of the application does not display during the UAC prompt, please remember that the SYSTEM account needs to be have read access to your executable, to be able to display its icon => check out the Security tab in your files properties. If you don't see SYSTEM listed in "Group or user names", you need to add it manually.