Category Archives: Technology

MSI Hacking: Intel SDK for OpenCL Installed on Windows 10

In doing a bit of spring cleaning on my home PC, which was upgraded from Windows 7 to 10 several months back, I came across one particular application whose installer was refusing to behave.  The product name was Intel® SDK for OpenCL* Applications 2013, and I had installed it several years ago under Windows 7, for reasons that are both mysterious and unimportant.

Normally, removing an application is as simple as opening the Add/Remove Programs dialog and clicking Uninstall.  But in the case of this particular tool, the (un)installer refused to function at all under Windows 10.  Any attempt to invoke it produced the following unhelpful little popup:

Intel® SDK for OpenCL* Applications 2013 designed to work on Microsoft Windows Vista* x64, Windows* 7 x64, Windows* 8 x64, Windows Server* 2008 R2 x64 operating systems only. The installer detected that you're trying to install the SDK on a different version. Aborting installation

At this point I had a few options.  Walking away and leaving it to sit on my hard drive forever was the obvious one, but a true nerd never turns down a challenge.  Downgrading to Windows 7 was right out, so I decided it was time to earn my stripes for the day.


First things first, let’s see what we can learn about the application.  Most traditional apps register their uninstallers in the registry, or we can query WMI from the command line.  I chose the latter.

wmic:root\cli> product where "name like '%opencl%'"

The output gives us an important piece of information: the location of the installer MSI in the package cache.


Installers are basically glorified zip files that include additional layers of features: instructions for where on the system to place the files, dialogs to present to the user, etc.  An Uninstaller is basically just an installer in reverse; it tells the system where the files are that need to be removed.  Now that we know where the (un)installer is stored, we can work on it.

MSI installers can be invoked from the command line, so we can try that option next.

msiexec /x C:\WINDOWS\Installer\1d2d2be.msi

No luck… same failure.

We could also enable debug logging with msiexec to gather more information, but at this point it’s pretty clear that the installer’s logic is broken.  It’s fairly common to prevent people from installing on an unknown version of Windows, but it’s a bit less sensible to prevent an uninstall, and it seems like whoever wrote the installer routines just never planned for this scenario.

Fortunately for us, unlike some install systems, MSI files are fairly easy to edit.  There are lots of tools you could use for this, but I chose one that is free, relatively light weight, and provided by none other than Microsoft (meaning it’s hopefully fairly safe too).  The tool is called Orca and it’s part of the Windows SDK.

Note that you don’t need the SDK for your version of Windows; any version that contains Orca will do.  You also don’t need everything in the SDK installer, which can be quite large.  In the case of the Windows 7 SDK, Orca is part of the Win32 Development Tools.


Frustratingly, the SDK doesn’t actually install the Orca application, it installs the Orca installer.  (We must go deeper!)  So, once the SDK is installed, pull up the SDK installation directory and locate Orca.msi.  Install that, and then you’re good.

Before launching Orca, make a copy of the installer MSI that you’re going to edit.  Always have a backup!  If anything goes wrong during the editing process, we’ll want a pristine copy to fallback on, or we may never get this app removed.

Now we launch Orca, and open up our edit copy of the problem MSI.  We can now browse (and modify) the MSI tables right from this tool.  In this case, I looked for the error message that I knew appeared when the installer failed.

And there it is…


The LaunchCondition table lists, as the name suggests, conditions the installer checks for before allowing the installation to proceed.  Or in my case, the uninstallation.  I select the offending condition in the menu, and Delete.  Save the MSI, and exit Orca.

Now all that remains is to put the new MSI where Windows expects to find it: the location named in WMI, where we originally found the file.  (For installed MSI products, Windows will use the installer from the cache, even if you launch a different installer with the same ID from somewhere else on the filesystem.)



New GitHub Project: trustymail

I’ve been running private mail service for years.  Spam filtering has long been one of the most difficult (impossible!) issues for small-time mail operators, but I usually enjoy the challenge, and using the various white/black listing and heuristics tools makes the experience manageable.

Still, I never entirely trust that important messages will survive the spam filtering process as intended, so I will occasionally whitelist senders that I know I want to hear from.  In my setup this usually means some combination of Postgrey and SpamAssassin configuration.

I finally decided to sit down and spend a few minutes scripting the configuration process so I could maintain one whitelist instead of multiple.  The script will format each config file as needed, and I don’t have to worry about my lists getting out of sync anymore.

The results are available on GitHub:

Failure to set SearchScopes with sysprep in Internet Explorer

It’s supposed to be possible to set the default search engine in Windows Internet Explorer using a custom unattend.xml file with sysprep.  This technique uses the SearchScopes configuration under Microsoft-Windows-IE-InternetExplorer.

If you’re maintaining images of Windows 8 or Windows Server 2012R2, you may have come across problems where these SearchScopes fail to apply correctly.  Sysprep will run successfully, but on startup Bing will still be the default search engine in IE.   After some investigation, the issue appears to be related to having certain (now obsolete) Windows Updates applied to the base image.

To resolve, search for KB2976627 and KB2987107 in the installed Windows updates, and remove them if found.  Reboot after removal, followed by a full check for new updates.  Install any pending updates as normal, and re-run sysprep.  Assuming your SearchScopes are properly configured, they should work now.

BOINC on FreeBSD 10.0

BOINC (Berkeley Open Infrastructure for Network Computing) is a multi-platform system for distributed computing.  While available for most mainstream operating systems like Windows and OS X, BOINC projects can also be run on FreeBSD.

Installing BOINC

The BOINC is available directly from the ports tree.  Assuming you already have FreeBSD 10 installed with the ports collection, just install the net/boinc-client port.  You can opt to include the GUI, or just the core client.

# portmaster net/boinc-client

To enable the BOINC client to run in the background, add boinc_client_enable to rc.conf:

# vi /etc/rc.conf

Installing Native Projects

BOINC is software that runs other software.  Generally speaking, the projects themselves provide binaries directly to the client, but many do not support FreeBSD as something of a niche operating system.  A small number of BOINC projects do have ports available which you can build straight from the tree.

You can search ports for boinc to see which projects are currently available.

# cd /usr/ports/
# make search name=boinc

If you find your project, just install the port to complete the process.

# portmaster astro/boinc-setiathome-v7

Once the application is installed, just use boinccmd to connect to your project account, and you’re done!

# boinccmd --project_attach [authenticator]

Running Linux Projects

As I mentioned in the last section, many projects (like World Community Grid) do not support FreeBSD natively.  Even though you can install the boinc client, if a project doesn’t provide FreeBSD-compatible files, their project software won’t run.  To compensate for this the FreeBSD client gives the option of using Linux emulation.  More projects are available for Linux than FreeBSD, so Linux emulation allows the FreeBSD client to also run project software that was written for clients on Linux… and expands the number of projects available by doing so.

The first step is to build or rebuild the boinc_client itself with Linux support.  If you already included this feature when you installed the client, you can skip rebuilding it.  If you aren’t sure, run make config to check.  You’ll also need to install the linux_base emulators port to provide Linux emulation to the system.

# cd /usr/ports/net/boinc-client
# make config
[select Linux]
# portmaster net/boinc-client emulators/linux_base-f10

Linux emulation should now be installed, but you may have to make a few more changes before project software will run.  Enable linux emulation in rc.conf:

# vi /etc/rc.conf

Enable shared memory features.  (If you get shmem errors from a project, check this.)

# vi /etc/devfs.conf
link /tmp shm

Finally, some documentation suggests setting the following flag in sysctl.

# vi /etc/sysctl.conf

That should it!  Don’t forget to reboot to ensure the system picks up all your changes.


If you’re still having trouble getting  your projects to run, check the client logs for errors.  The default ports client uses /var/db/boinc/ as a working directory.   stderrdae.txt and stdoutdae.txt store errors and output respectively.  You can also check the account_*.xml files to verify your account settings are correct.

Upgrading Apache from 2.2 to 2.4 (Ubuntu Precise to Trusty)

There are a few significant changes between Ubuntu Precise (12.04) and Trusty (14.04) with regard to Apache2 which may cause some headaches if you aren’t prepared to troubleshoot them.

conf.d to conf-enabled

/etc/apache2/conf.d is no longer sourced by apache.2conf.  Instead, conf files are now using the *-available and *-enabled scheme that modules and sites use.  You may need to port old configs over from conf.d to conf-available/enabled if you had anything non-default in there.

site names require “.conf” at the end now

Previously, any files in sites-enabled was loaded into Apache.  Now, apache2.conf has been changed slightly to only load sites configs ending in the name “.conf”

IncludeOptional sites-enabled/*.conf

access control has changed

The access control syntax has changed between versions.  For example,

Order allow,deny
Allow from all

is now written simply as

Require all granted

The updated apache2.conf  in Trusty also contains some default permissions which may or may not alter the way your existing vhosts behave, but these are easily adjusted.

There are many more changes as well, which are documented on the website:

NUT (Network UPS Tools) on Ubuntu Precise

Installing nut (Network UPS Tools) on Ubuntu Precise with a USB connected UPS (such as the CyberPower AVR series) may produce an error similar to the following:

Can’t connect to UPS [UPS] (cyberpower-ups): No such file or directory

The problem involves the fact that Ubuntu mounts the device as owned by root, but the nut daemon drops to an unprivileged account that doesn’t have the necessary access. The simple fix is to use udev to adjust the device permissions.

Connect the device and (as root) run lsusb and locate it. Note the Bus and Device IDs as well as the Vendor:Product ID pair.

Bus 001 Device 009: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS

You can check the current permissions in /dev.

File: ‘/dev/bus/usb/001/009′
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 5h/5d Inode: 28437 Links: 1 Device type: bd,8
Access: (0664/crw-rw-r–) Uid: ( 0/ root) Gid: ( 0/ root)

Now we just create a udev rule that controls the mount behavior.


ACTION==”add”, \
SUBSYSTEM==”usb”, \
ATTR{idVendor}==”0764“, ATTR{idProduct}==”0501“, \
MODE=”0660″, GROUP=”nut”

The rule watches for USB device additions with a vendor and product that match the UPS. It then sets the mode to 0660 and the group to nut instead of the default root. Reload udev, then disconnect and reconnect the device and test that the new permissions are correct. Now that the nut user group has read and write on the device, it should be able to start successfully.

This is an OEM record

We’ve been having an issue where our Dell servers will fill up their hardware event logs with the following, particularly during reboot:

Tue Jan 17 2012 09:02:00 This is an OEM record.
Tue Jan 17 2012 09:02:00 This is an OEM record.
Tue Jan 17 2012 09:02:00 This is an OEM record.

This is something of an issue since the event log fills up rather quickly, and you lose the ability to collect more meaningful logs (hardware failure!). But what does this mean, and why so many of the same message?

The short version is that Windows includes an IPMI driver which has the ability to also write to the machine system event log (SEL). Everywhere you see “This is an OEM record” is basically the DRAC’s way of saying “The OS wrote this, and I don’t know what it means.” The DRAC can only decode its own entries.

This handy article actually does a nice job of explaining how to use racadm to decode said logs: It also explains why Windows shutdowns tend to spam the logs with lots of entries, and how to stop it from doing so via a regedit.

Finally, here is the official Microsoft KB for disabling the IPMI logging: