"Uninstalled processes" in the "App history" tab of Task Manager

If you go to the App history tab of Task Manager on Windows 8 or newer and then enable Options | Show history for all processes, you'll probably get an extra entry called "Uninstalled processes" that took a few resources.

The name might be a little confusing, but from what I can tell, that entry displays the sums of all the resources used by processes launched from executables that can no longer be found. You can test this theory by making a copy of a standalone program, running it for a while, then deleting it. The things it used will be added to the "Uninstalled processes" row.

Based on my Super User answer.

AbiathRPC - Shared control of authentication challenge

A while back, I noted that it's less than ideal how an AbiathRPC server could order the client to sign anything the same length as a SHA256 hash. Putting the client in complete control of the message to be signed is also very bad, since that would enable replay attacks. I know I can't completely solve man-in-the-middle attacks without some sort of PKI, but I came to a good solution: have the server and client both be responsible for the signed message.

Now, the server still sends an authentication challenge for VeriMaps authentication, but the method that accepts the signed version now takes another part of the message in addition to the signature. When authenticating, the client generates a random bunch of bytes, appends that to the stuff received as the server's challenge, computes the SHA256 hash, and signs that.

AbiathRPC - Level downloading

A while ago in AbiathRPC development, I got the server to load levels from disk and transform them into something meaningful but also WCF-compatible. Today I got the client to download those levels and display them as though they were local. To do that, I had to write the level set proxy, which AbiathRPC swaps in when connecting to a server. It then clears the level view state dictionary (removing the image of the original temporary level), populates the level list in the Level menu, and updates the level label.

Server levels can be successfully viewed on the client. I am getting close to having some actual collaboration features working.

Overlaying big text on the screen with PowerShell

Somebody wanted to use a command-line-invokable script to throw up a massive text overlay on the screen. The easiest way to do that using only built-in Windows tools is, of course, PowerShell.

When this script is run, the word "Hi!" appears in blue on top of everything. It goes away once the text (not the area around it) is clicked.

Add-Type -AssemblyName System.Windows.Forms
$form = New-Object System.Windows.Forms.Form
$form.TransparencyKey = $form.BackColor
$form.WindowState = 'Maximized'
$form.FormBorderStyle = 'None'
$label = New-Object System.Windows.Forms.Label
$label.Font = New-Object System.Drawing.Font ($label.Font.FontFamily, 200)
$label.ForeColor = [System.Drawing.Color]::FromKnownColor('Blue')
$label.AutoSize = $true
$label.Text = 'Hi!'
$label.Add_Click({$form.Close()})
$form.Controls.Add($label)
[Windows.Forms.Application]::Run($form)

It works by creating a standard Windows form, removing its background, maximizing it, adding a label with really large text, and showing the form.

AbiathRPC - VeriMaps authentication

A few days ago, I threw together an implementation of authentication for AbiathRPC based on VeriMaps certificates. Today I actually tested it, and I found that it didn't work: the data to sign has to be the same length of a hash produced by the hash algorithm used by the signature formatter. (Makes sense.) I changed the server to SHA256 the GUID before sending it to the client as the challenge. After fixing a couple simple oversights, VeriMaps authentication works as intended.

I considered whether a malicious server could get a client to sign an arbitrary blob of data (e.g. the SHA512 hash for a VeriMaps-signed level set). The choice of SHA256 for this hash algorithm makes it impossible for the server to use a level set's hash as the challenge. This setup is still less than ideal, since it precludes any other VeriMaps security systems that use SHA256. Therefore, I will change the server to always produce a challenge that starts with some constant value (e.g. "RPC") and change the client to check for that before signing. Nothing I do here can defend against man-in-the-middle attacks, but that's what real TLS is for.

Getting the Chrome version without it updating itself

Somebody wanted to know how to get the product version of Google Chrome without going to the "about" page, since that could cause an auto-update. I suggested a method that works on many programs including Chrome: consult the Details tab of the executable's Properties window. If the version was included by the program's author, it'll be in the Product version row. You can pull that from a running process by using PowerShell:

(Get-Process 'chrome').MainModule[0].ProductVersion

Determining whether the system was up at a given time with PowerShell, kind of

There isn't an easy cut-and-dry way of determining whether a Windows machine was running at a given time. You could try to look through Kernel-Power events and try to match "off"-like ones with "on"-like ones, but that would be tricky to get right with all the various power state transitions, especially if you consider sudden power losses.

Instead, I suggest this slightly subjective but very simple PowerShell oneliner:

Get-WinEvent -LogName Application | ? {$_.TimeCreated -le '10/19/2016 12:45 PM'} | select -First 1

It consults the Application event log (one of the very active logs) to get the most recent event before the given time. If that event's time is more than three hours or so before the given time, it's likely that the system was not running. If a human is reading the output, the contents of the most recent event would also probably provide a clue as to whether the system was powering down.

Based on my Super User answer.