RealPlayer/RealDownloader poses as Firefox running on 64-bit Linux and sends HEAD and GET requests

I recently noticed some strange HTTP logs where a resource would be requested twice with two different User-Agent headers. In one case, the first request suggested the client was running Chrome on Windows, while the second request indicated that it was coming from Firefox on Linux. This didn’t make a lot of sense, so I did some digging.

The culprit turns out to be RealPlayer (and previously RealDownloader, a separate application that now seems to be abandoned). RealPlayer places an overlay over supported browsers (Internet Explorer, Firefox and Chrome and possibly others) that allows the user to save videos from web pages. It doesn’t seem to be a browser plugin as such – it runs in its own process and sends HTTP requests independently of the browser.

RealPlayer browser overlay

The software just happens to set the User-Agent header to something like Firefox running on 64-bit Linux. I sacrificed a virtual machine and installed all manner of RealPlayer software to try and reproduce this behaviour, and the latest version sends requests like the following:

Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20150101 Firefox/20.0 (Chrome)
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: close

Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20150101 Firefox/20.0 (Chrome)
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: close

My browser’s actual User-Agent header is:

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.15 Safari/537.36

Based on this blog post and this Yahoo! Answers question, the following User-Agent header was used by an earlier version of the software:

Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0 (Chrome)

The Gecko build date and Firefox version number (but not the ‘rv’ token!) have been bumped up, but everything else (including the weird trailing ‘Chrome’ identifier) are the same.

I bet somebody got a really nice bonus for that feature: The ‘Get Windows 10’ notification area icon

As the great Raymond Chen once wrote:

I often find myself saying, “I bet somebody got a really nice bonus for that feature.”

“That feature” is something aggressively user-hostile, like forcing a shortcut into the Quick Launch bar or the Favorites menu, like automatically turning on a taskbar toolbar, like adding an icon to the notification area that conveys no useful information but merely adds to the clutter, or (my favorite) like adding an extra item to the desktop context menu that takes several seconds to initialize and gives the user the ability to change some obscure feature of their video card.

The ‘Get Windows 10’ application that Microsoft deployed to Windows 7 and 8.1 machines earlier this year as a recommended – not even optional – update (KB3035583 ) sure fits this bill.

In short, every eligible Windows 7 and Windows 8.1 user ends up with this icon in their notification area: Get Windows 10 Icon

Apart from looking fairly ugly (that top edge in particular is a blurry mess), there’s no way to close it even temporarily, short of killing GWX.exe in the Task Manager – note also that no-one thought to give it a descriptive name; it’s just ‘GWX’.

I understand Microsoft’s desire to have users promptly upgrade to Windows 10 (even I wish they would delay its release by a year or so), but this kind of approach just destroys goodwill.

Fixing error 0xC190010C when attempting to update the Windows 10 Technical Preview

My Hyper-V virtual machine running the Windows 10 Technical Preview kept displaying the error code 0xC190010C when I attempted to update to the latest build (from 9841 to 9860).

I was able to resolve this issue by clearing the Windows Update cache as described here (essentially deleting the ‘SoftwareDistribution’ directory found in %WinDir%’ after stopping the Windows Update service).

What’s up with Office 2013’s context menu and tooltip shadows?

Update (2015-04-22): Somewhat surprisingly, a recent Office 2013 patch appears to have fixed this issue.

Update (2015-03-04): Office 2016 fixes this.

Update (2014-10-03): Office 2013 running on the Windows 10 Technical Preview (build 9841) exhibits the same issue :(

At some point in the not-too-distant past, Office 2013 started rendering strange shadow artefacts in the four corners of all context menus and tooltips:

Screenshot of Word 2013 Context Menu Shadow Artefacts

This didn’t always happen, as a quick search for ‘Word 2013 screenshots’ will reveal lots of images of glitch-free floating windows. I’m too lazy to check, but I’ll hazard a guess that this started happening with Windows 8.1 or Windows 8.1 Update 1.

Being Office, they’ve re-implemented every GUI element themselves instead of letting the OS handle them. One can sympathise with this approach, but it’s important to get the little details right. A bit like how the IE team should finally spend the time to get their scrollbars right. Of course, it’s folly to ever expect UI consistency on Windows when even Microsoft can’t get it right.

A man can dream, though. A man can dream.

Code samples on GitHub

I’ve put the code samples featured on this blog over the years on GitHub:

Fix Visual Studio 2013 Start Menu shortcuts

Click here to see this bug on Connect.

Visual Studio 2013 configures Start Menu shortcuts differently to earlier versions. Specifically, it adds a shortcut to ‘Visual Studio Tools’ (%PROGRAMFILES(X86)%Microsoft Visual Studio 12.0Common7ToolsShortcuts), where Visual Studio 2012 added a directory called ‘Visual Studio Tools’ and added copies of the shortcuts. This is all a bit confusing, but the end result is that searching in the Start Menu/Screen won’t bring up results for useful things like the Developer Command Prompt or Spy++.

This annoyed me sufficiently that I wrote a PowerShell script (run it as administrator) to restore the shortcut directory:

$shortcutpath = "$env:ProgramDataMicrosoftWindowsStart MenuProgramsVisual Studio 2013Visual Studio Tools.lnk"
$newshortcutdir = "$env:ProgramDataMicrosoftWindowsStart MenuProgramsVisual Studio 2013Visual Studio Tools"
If (Test-Path $shortcutpath) {
  $shell = New-Object -COM WScript.Shell
  $toolsdir = $shell.CreateShortcut($shortcutpath).TargetPath

  # create directory if necessary
  If (-Not(Test-Path $newshortcutdir)) {
    mkdir $newshortcutdir
  # copy shortcut files
  copy "$toolsdir*.lnk" $newshortcutdir
  # hide old shortcut
  $shortcut = Get-Item $shortcutpath -Force
  $shortcut.Attributes = $shortcut.Attributes -bor [System.IO.FileAttributes]::Hidden
} else {
  "Shortcut not found."

The Visual Studio Shortcuts directory doesn’t contain shortcuts to Spy++ (and a number of other programs). Here’s another script to restore shortcuts to Spy++:

$shortcutdir = "$env:ProgramDataMicrosoftWindowsStart MenuProgramsVisual Studio 2013Visual Studio Tools"
$toolsdir = "${env:ProgramFiles(x86)}Microsoft Visual Studio 12.0Common7Tools"
$shell = New-Object -COM WScript.Shell

$spyshortcut = $shell.CreateShortcut("$shortcutdirSpy++.lnk")
$spyshortcut.TargetPath = "$toolsdirspyxx.exe"

$spyshortcut = $shell.CreateShortcut("$shortcutdirSpy++ (64-bit).lnk")
$spyshortcut.TargetPath = "$toolsdirspyxx_amd64.exe"

ResEdit doesn’t work with the Windows SDK 8.0 and above (use 7.1 or below)

ResEdit is a nice resource file editor for Windows programs. Regrettably, it has some issues with the latest versions of the Windows SDK (8.0 and 8.1) – it’s possible to create a resource script (.rc) file, but you won’t be able to open it again later. Even if %PROGRAMFILES(x86)%Windows Kits8.1Include is set as include path, symbols like VOS_NT_WINDOWS32 (defined in verrsrc.h) won’t be resolved and you’ll get ‘undeclared identifier’ errors if your resource script contains them.

Use an earlier version of the Windows SDK (like 7.1) and ResEdit has no problem reading the header files.

For reference, I’m successfully using the following include paths:
%PROGRAMFILES(x86)%Microsoft SDKsWindowsv7.1AInclude
%PROGRAMFILES(x86)%Microsoft Visual Studio 12.0VCinclude

It’s not just me experiencing this issue:
ResEdit started to be Annoying‘ (January 2012)
Resedit Problem‘ (June 2014)

Html.AntiForgeryToken() sets an X-Frame-Options header with the value ‘SAMEORIGIN’

I recently migrated a project from ASP.NET MVC 4 to MVC 5 and the process went quite smoothly, except that all of a sudden my webpages were being returned with the X-Frame-Options header set with the value ‘SAMEORIGIN‘. This is actually a reasonable default as it helps mitigate the risk of ClickJacking. The website in question, however, is designed to run in an iFrame, and this header immediately caused issues.

After a fruitless search of all my code in Visual Studio for ‘X-Frame-Options’ and ‘SAMEORIGIN’, I decided to try Windows Grep as a last resort, and it found that ‘SAMEORIGIN’ was present in System.Web.WebPages.dll. Thanks to Microsoft making ASP.NET MVC open source, I was able to find the relevant code quite easily on GitHub; it turns out that the AntiForgeryWorker class adds the header when you call Html.AntiForgeryToken() as of August this year. Even better, there’s an easy way to prevent this behaviour: set the static property AntiForgeryConfig.SuppressXFrameOptionsHeader to true (I’ve done this in my Application_Start() method). MSDN doesn’t didn’t even document this property yet, so I’m lucky to have found it. Two other bloggers have written about this in English and Japanese.