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

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

E:\WinDDK\7600.16385.0>

bin2coff

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 */

Addon:
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