Antivirus and .NET-ception

by Ryan 24. October 2012 14:15

So I was playing around the other day with a couple of antivirus products for Windows, trying to see if I could figure out ways to evade detection, (it was a slow day.) I feel very ambivalent pretty much hate antivirus software. As an IT guy, I know that it's a necessary evil, and every once in a while it does legitimately catch something that would have infected your system, but:

  • AV software often negatively impacts the performance of the entire system, unless you make so many concessions on what it doesn't scan that it practically defeats the purpose. I mean, yeah, your website probably would perform better if I excluded the entire inetpub folder, but then who's going to slow down that e-mail spam bot that you went and got yourself infected with? 
  • You might as well consider the installation of AV software on your machine a permanent modification. Just try and cleanly uninstall that crap I dare you.
  • False sense of security. Some AV products might be slightly better or worse than others, but none of them are approaching perfect. And none of them are a replacement for bad habits, such as clicking on all the links on that popup window that didn't get blocked by your web browser for some reason when you went to that one website with farm animals on it... I mean... I wouldn't know anything about that.

So the European Institute for Computer Antivirus Research (EICAR) made up this string of ASCII characters that antivirus product vendors and users can use to test their AV products. You can put it in a text file or in an executable file or whatever, and it's supposed to trigger the AV on your machine. Depending on your AV settings, even copying the EICAR string to your clipboard might trigger your antivirus. The "on-access" scanning of antivirus products uses a file system filter driver to intercept all disk I/O, or whenever an IRP_MJ_CREATE is issued for a file, but unless the AV product is also configured to actively scan memory and network activity, then you can evade it as long as your "evil code" stays in memory and doesn't touch the disk.

So I was playing around in Powershell and C#, and I wrote this rather silly bit of script... er, code... or scrode? It's a Powershell script that uses the Add-Type cmdlet to load in a C# class on the fly. That C# class in turn, contains code to compile some more code on the fly, and turn it into an executable. (Finally the Inception reference starts to make sense.) So just for fun I download the EICAR test file from the internet (which triggers some AV products, but not others, depending on how they're configured.) Now that I have the evil EICAR string in memory, I compile my executable, which does not itself contain any malicious code, so it won't trigger AV. Then I run that new process and pass the EICAR data to it as a parameter. In this way, I feel like I was able to get "malicious" data onto the computer and into a process that could then do whatever it wants with it - all without triggering the antivirus on the system because the EICAR data never touched the disk.

$SourceCode = @"
using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.CSharp;
using System.CodeDom.Compiler;

public class EvilClass
{
    public static void Main(string[] args)
    {
        var csc = new CSharpCodeProvider(new Dictionary<string, string>() { { "CompilerVersion", "v3.5" } });
        var parameters = new CompilerParameters(new[] { "mscorlib.dll", "System.Core.dll" }, Environment.GetEnvironmentVariable("temp") + "\\evil.exe", true);
        parameters.GenerateExecutable = true;
        CompilerResults results = csc.CompileAssemblyFromSource(parameters,
        @"using System;
		  using System.Reflection;
          class AnotherEvilClassInsideAnotherEvilClass 
			{				
				public static void Main(string[] args)
				{					
					string msg = ""Data in evil.exe Main(): "" + args[0];
					System.Console.WriteLine(msg);					
				}
            }");
        results.Errors.Cast<CompilerError>().ToList().ForEach(error => Console.WriteLine(error.ErrorText));		
    }
}
"@

Add-Type -TypeDefinition $SourceCode -Language CSharp

Write-Host "Downloading some evil code from the internet and displaying it in the console..."
ForEach($_ in $(New-Object System.Net.Webclient).DownloadData('http://eicar.org/download/eicar.com'))
{
	$evilString += [char]$_
	Write-Host $([char]$_) -NoNewLine -ForegroundColor Red
}
Write-Host "`nGenerating evil.exe..."
[EvilClass]::Main([String]::Empty)
Write-Host "Executing evil.exe..."
& $Env:TEMP\evil.exe $evilString
Write-Host "Deleting evil.exe..."
Remove-Item $Env:TEMP\evil.exe

And here is the scrode in action:

Powershell power

Web Server Upgrade

by Ryan 21. October 2012 13:29

Nothing too exciting to share right now, except that I upgraded this web server this morning from 2008 R2 to Server 2012.  The upgrade went perfectly, all my settings and applications were migrated properly, and most importantly the server was upgraded to IIS 8 and .NET 4.5 with no issues. I figured if there were going to be any problems, it was going to be there, since this website relies heavily on .NET.

I was able to remove the GUI shell, but I had to leave the "Graphical Management Tools and Infrastructure" feature enabled, as the server warned me that some certain important bits like IIS and SMTP might stop working without it. :P

A Minor (Literally) Windows Bug?

by Ryan 16. October 2012 10:03

So I was reading Windows Internals 6th ed. Pt II the other day, specifically the chapter about crash dumps, when I noticed something odd. It was in the output of the .dumpdebug command in the kernel debugger. Just to make sure it wasn't just a typo in the book, I have reproduced the oddity here:

Windbg

I have simply launched Windbg, loaded up a crash dump file, and issued the command .dumpdebug. In the header, you see the MajorVersion is 0f. The MinorVersion is 1db1. The MinorVersion I understand. 1db1 is hexadecimal and in decimal it translates to 7601. Most administrators will immediately realize the number 7601 as belonging to Windows 7 or 2008 R2 with service pack 1.

But what is the MajorVersion? 0F in hexadecimal translates to 15 in decimal. But what does 15 mean? This version of Windows is 6. The full version string displayed when I open up a Command Prompt on this machine for instance, is 6.1.7601. Major version = 6, minor version = 1, build number = 7601. Right?

So why does the kernel debugger show the MajorVersion of Windows to be 15? I wonder if I've found a bug...

Tags:

Windows

Mystery of the Performance Counters with Negative Denominators!

by Ryan 6. October 2012 17:43

So I finally solved a bit of a mystery, after wondering about it off an on for about 6 months.

A lot of us out there use some sort of monitoring program like SCOM that gathers some performance counter data from all of the servers in your environment, and uses that data to produce messages such as:

WARNING: Hey man, the CPU usage on SERVER01 is really high and has been for a while, so, you might wanna' go check that out.

But every once in a while, if for some reason the performance counters needed are unavailable, your monitoring application might say something like this:

ERROR: Unable to get performance counter data for SERVER01.

Well that happens to me somewhat frequently. Sometimes it's an error in the monitoring application, or sometimes the agent machine needs a lodctr /R or winmgmt /resync or something like that. But every once in a while it's more difficult to solve than that. I logged on to SERVER01 to see if I could simply add the performance counters needed to Perfmon. The objects and instances were there, but one of them looked odd. Then I decided to use typeperf.exe to get some data from the counters:

 

perfmon error

 

typeperf error

A counter with a negative denominator value was detected? Now contrary to that screenshot above, the -1's were intermittent, and would actually change to normal values for a few seconds, and then go back to negative ones. It was as if the scale of that counter was offset, and whenever real CPU load would occur, the counter would increase to positive values, but then as the CPU usage dropped back down closer to zero, the counter would fall below zero again.  Hmm... if you do a search for something like "missing performance counters," or "a counter with a negative denominator value," you'll get plenty of good links, as missing or corrupt performance counters are a somewhat common issue. Such as this, or this. Notice in that last link, that there is a vague reference to it being caused by "intermittent timing issues in the performance data handlers for many counters." The article fails however to offer any advice or anything more concrete than that. lodctr /R and winmgmt /resyncperf and all that usual stuff did nothing to help.

So I sat back and thought some more about the scope of the problem. I have only seen this issue two or three times in my career. The two cases I could remember both seemed to be on VMware virtual machines. One of them was a Windows 2003 operating system, and then a couple months later I saw it again on a Windows 2008 R2 VM. That phrase from that one KB stuck with me... "intermittent timing issues," and that made me think of hardware timing issues. But since these were VMs, they didn't exactly have hardware per se... but maybe it had something to do with the way in which the virtual machines communicate with their physical host. I was so close to figuring out the answer, but at the time I shrugged it off and shelved the issue in my mind for a while.

Then about a week ago the issue popped up again. Long story short, it turns out it was this all along:

VMware tools

Unchecking that "Time synchronization between the virtual machine and the ESX server" in the VMware tools app on the VM made the problem go away. Ugh. The answer had been so simple all along, yet it alluded me for months.

I feel better now that I at least have a solution for that particular scenario.  Now... back to Hyper-V.

EventLogClearer v1.0.1.22

by Ryan 30. September 2012 14:12

Update on 11/19/2012: Check out my updated version here.

I've been playing with Visual Studio 2012 the past couple of days, and this is the first full application I've written with it. I originally was going to try to make a Windows 8 modern-style application, but that's still a little too foreign to me and I ended up giving up and going back to a regular desktop application.

This application is designed to clear the selected event logs on remote systems. You can add the computer names manually, or you can scan the Active Directory of your current domain and the app will auto-populate the list with all the computers it found. There is some basic threading in the app to improve performance and GUI responsiveness. When you exit the app, your settings are saved in the Windows registry, and loaded back in again when you restart the application. All messages regarding success or failure will be shown in the Status window.

It requires .NET 4.5.  Testing was done on Windows 8 x64, but should run on any version of Windows with .NET 4.5. Thanks for Stackoverflow for helping me figure out that bug fix.

Screenshots:

EventLogClearer v1

 

EventLogClearer v1

Executable: EventLogClearer.exe (127.00 kb)

VS2012 Project (Source): EventLogClearer.v.1.0.1.22.zip (479.52 kb)

AliceAndBob v1.0: My Diffie-Hellman Tribute

by Ryan 25. September 2012 13:53

Sorry I haven't posted in a couple weeks. Busy as usual. However, I watched this video on Youtube the other day, which inspired me to write another C# application. It is of almost no actual use, but it is entertaining and maybe even a little educational.

It is my ode to the Diffie-Hellman key exchange concept, where two actors (Alice and Bob) are able to confidently exchange messages back and forth, even though Eve is eavesdropping on their line of communication and will intercept anything they send across the wire. This is because each Alice and Bob retain a secret key that is never shared publicly, but is an essential piece of information in coming to an agreement on a shared key. Alice and Bob are able to both agree on a shared key that can then be used as the seed in a symmetric encryption algorithm to hide their messages. Eve's only recourse is to calculate all possible discrete logarithms in attempt to arrive at the same solution as Alice and Bob did. With sufficiently large numbers, this can take a very, very long time. I highly recommend the Youtube video I posted above for a much nicer explanation.

I developed the application on Windows 7 x64, with .NET 4.0. (To make it work on Windows 8, I needed to put Microsoft.VisualBasic.PowerPacks.Vs.dll in the same directory since it wasn't on my Windows 8 machine.) Since this isn't a serious, production application, I didn't put any effort into error handling or threading, but I didn't encounter any crashes. I used the System.Numerics.BigInteger class to handle large numbers, but be careful when trying to use large numbers, as the calculations quickly become astronomical and it'll peg the processor it's running on. 

Without further ado, I present AliceAndBob v1.0:

AliceAndBobHelp

 

Here's the executable: AliceAndBob.exe (354.50 kb)

And here is the entire Visual Studio 2010 project (source code): AliceAndBob.zip (746.71 kb)

As always, bug reports and enhancement requests are welcome. Take it easy on me as I never claimed to be a mathematician or a cryptography guru, but I welcome your constructive criticisms.

A Lesser-Known Side-Effect of the Godaddy Outage

by Ryan 11. September 2012 11:21

ssl certSo GoDaddy.com experienced a massive denial of service attack and subsequent outage yesterday. GoDaddy hosts thousands of websites, email addresses, and global name servers. All of which were taken down yesterday for at least an hour or two. There are of course rumors that the "hacker group" Anonymous was somehow involved. Maybe they were, or maybe they weren't, but the fact is thousands of websites and millions of users across the globe were indiscriminately targeted. Lots of innocent, small businesses with online operations were unjustly hurt by the actions of whatever jackwagon(s) was/were involved.

The most obvious effect of the denial of service attack was that all Godaddy websites were inaccessible. Not just Godaddy.com itself, but all customer websites hosted by them. DNS records were unavailable for huge swaths of the internet.  Even the site http://www.downforeveryoneorjustme.com/ was overloaded by people wondering if a website was, in fact, down for everyone.

One lesser talked-about impact was that the Godaddy certificate revocation server was down too, which meant anyone on the web, and any automated monitoring tool that was monitoring the availability of HTTPS websites, became unable to check for the revocation of SSL certificates that were issued by Godaddy.

Some systems might return an error code 12057. The Windows WinInet API documentation defines it thusly:

#define ERROR_INTERNET_SEC_CERT_REV_FAILED    12057 // Unable to validate the revocation of the SSL certificate because the revocation server is unavailable
#define ERROR_WINHTTP_SECURE_CERT_REV_FAILED  12057 // Same as ERROR_INTERNET_SEC_CERT_REV_FAILED
#define CRYPT_E_REVOCATION_OFFLINE       0x80092013 // Since the revocation server was offline, the called function wasn't able to complete the revocation check

I.e., can't check for certificate revocation because Godaddy is getting pounded at the moment.

So the next question is, 'Should we care?'

If you absolutely just needed to clear this error, then you can go into the settings/options of your web browser, and uncheck the "Check for certificate revocation" option. Internet Explorer seems to have this enabled by default, but it can be switched off. Chrome has this unchecked by default but it can be turned on.

Personally I think we should care about checking for certificate revocation. By not checking for cert revocations, you're losing one of the big benefits that SSL certificates provide. If a certificate gets hacked, allowing the attacker to impersonate the intended certificate owner over the internet, I would certainly like to know if and when that certificate is revoked.

It may be more convenient and it may rely on one less component if you disable CRL checking, but if I browse to my online banking website one day, and I get a warning about it using a revoked certificate, I'm certainly not logging in!

Windows Hyper-V Server 2012

by Ryan 5. September 2012 15:17

Windows Server 2012 As you probably know, Windows Server went to General Availability yesterday.  So, I took the opportunity to upgrade my virtualization host from 2008 R2 to Windows Hyper-V Server 2012.  Hyper-V Server, which was introduced in the 2008 R2 era, is based on Server Core, meaning it has no GUI, and it comes with the Hyper-V role preinstalled.  Hyper-V Server has no licensing cost of its own - it's free - but it comes with no free guest VM licenses.

I'll say right off the bat that I love Server Core. I'm sad that I don't get to play with Server Core much in production environments, but I firmly believe that will be changing in the near future. The fact that there is literally nothing that you cannot do on the command line and/or Powershell, makes Server 2012 the absolute most scriptable and automatable Windows Server ever. By far. And on top of that, the newest version of Hyper-V is bursting at the seams with improvements over the last version, such as shared-nothing live migrations, a much more flexible and extensible virtual switch that can be modified with plugins, and improvements on every metric in regards to how much vRAM, vCPUs, VHD size, etc., that can be allocated to virtual machines. Server 2012 feels super-polished, and runs faster than any previous version of Windows, especially Core.

Now that I've drooled over the new server OS, let's talk about my real-world experiences with it so far.

I downloaded the Hyper-V Server 2012 ISO, and uploaded the installation wim file to my local Windows Deployment Server. After scooting all my existing virtual machines off the box, I rebooted it into PXE mode and began installing the new 2012 image. The install was quick and painless. No issues recognizing my RAID volumes, etc. When the newly created server booted up, it asked for a local administrator password. Standard stuff. Then, I was dumped into a desktop with two Cmd.exe shells open, one of which was running Sconfig.

Sconfig is a basic command-line program that comes with Server Core as a supplement to help administrators do some routine setup and administration tasks on their new Core servers, since they don't have a GUI to rely on. Sconfig can do basic things like rename the computer, join a domain, set up an IP address, enable remote management, etc.

sconfig

The point is that all of that stuff can be done without Sconfig, but Sconfig just makes it simpler to get up and running. Enabling remote management is particularly important, because that means we will be able to connect to this server remotely using MMC snapins, Powershell sessions, and the Remote Server Administration Tools (RSAT.) RSAT is not out for Windows 8/Server 2012 yet. But since I'm running Windows 8 on my workstation, and Windows 8 comes with client Hyper-V capabilities, that means I can add the Hyper-V Management Console on my workstation via the "Turn Windows features on or off" thing in the Control Panel. I'll then be able to connect to the Server 2012 hypervisor remotely and be able to play around with a GUI.

Speaking of Windows 8 - the Windows key is now your best friend. Hit Win+X on your keyboard. Now hit C. Try that a few times. Have you ever opened a command prompt that quickly before? No, you haven't.

So I did all the setup tasks there in Sconfig, and that's when I noticed that it doesn't seem that Sconfig is capable of setting IPv6 addresses on my network cards:

 

noipv6

Bummer, I'll have to do that later. All my servers run dual-stacked, so IPv6 addresses are important to me. After joining my domain, setting up the time zone, and setting up IPv4 addresses on the two NICs in this server, I figured I'd done all the damage I could do with Sconfig and logged out.

Now that remote desktop and remote management were enabled, I could do the rest of the setup of the server from the comfort of my Win8 desktop. First, I wanted to enter a remote Powershell session on the server:

PS C:\Users\ryan> New-PSSession -ComputerName hyper2012 | Enter-PSSession
[hyper2012]: PS C:\Users\ryan\Documents>

A one-liner and I'm in. First, let's set those IPv6 addresses. At first I thought to do it with netsh. But upon executing it, netsh gives me a little warning about how it will eventually be deprecated and that I should use Powershell instead. Well I don't want to use anything but the latest, so Powershell it is!

PS C:\Users\ryan> New-NetIPAddress -AddressFamily IPv6 -InterfaceIndex 13 -IPAddress "fd58:2c98:ee9c:279b::3" -PrefixLength 64

That's it. The cmdlet will accept the IP address without the Prefix Length, but the Prefix Length is very important. If you omit that, you will wonder why it's not working. Prefix length is the same thing as subnet mask. So if this were an IPv4 address, with a subnet mask of 255.255.255.0, I would use 24 as the prefix length. My IPv6 addresses use a 64 bit prefix length. Since these cmdlets are brand new, they're not fully documented yet. The Get-Help cmdlet did not help me beyond giving me the parameters of the cmdlet. But the cool thing about Powershell is that it's simple enough that you can pretty easily guess your way through it. Plus that's the coolest thing about using a new OS that's hot of the presses, is that you're getting to run through exercises that not many people have yet, and you can't just Google all the answers because the info is just not out there yet.

Now let's put some IPv6 DNS servers on these NICs to go along with our IP addresses:

PS C:\Users\ryan> Set-DnsClientServerAddress -Addresses fd58:2c98:ee9c:279b::1,fd58:2c98:ee9c:279b::2 -InterfaceIndex 13

One thing I noticed is that even though I enabled Remote Management on the server, that did not enable the firewall rules that allow me to remotely administer the Windows Firewall via MMC. So I needed to enable those firewall rules on the server:

PS C:\Users\ryan> Set-NetFirewallRule -Name RemoteFwAdmin-RPCSS-In-TCP -Enabled True
PS C:\Users\ryan> Set-NetFirewallRule -Name RemoteFwAdmin-In-TCP -Enabled True

I am in favor of using the Windows Firewall and I like to control it across all my servers via Group Policy. Almost every organization I have worked with unilaterally disables the Windows firewall on all their devices. I don't know why... you have centralized control of it on all your computers via Active Directory and it adds another layer of security to your environment. In fact, had I not been in such a hurry and if I had let the Group Policy run on this server, those firewall rules would have been automatically enabled and I wouldn't have had to do that manual step.

So far I'm loving it. You're reading this blog post right now on a virtual machine that is hosted on Hyper-V Server 2012. I've never been as excited about a new Windows Server release as I am about 2012, and I make sure that everyone around me knows it, for better or worse. :)

Are Windows Administrators Less Likely to Script/Automate?

by Ryan 29. August 2012 16:46

I wrote this bit as a comment on another blog this morning, and then after typing a thousand words I realized that it would make good fodder as a post on my own blog. The article that I was commenting on was on the topic that Windows administrators are less likely to script and/or automate because Windows uses a GUI and Linux is more CLI-centric. And because Linux is more CLI-focused, it is more natural for a Linux user to get into scripting than it is a Windows user. Without further ado, here is my comment on that article:


This article and these comments suffer from a lack of the presence of a good Microsoft engineer and/or administrator. As is common, this discussion so far has been a bunch of Linux admins complaining that Windows isn't more like Linux, but not offering much substance to the discussion from a pro-Microsoft perspective.

That said, I may be a Microsoft zealot, but I do understand and appreciate Linux. I think it’s a great, fast, modular, infinitely customizable and programmable operating system. So please don’t read this in anger, you Linux admins.

First I want to stay on track and pay respect to the original article, about scripting on Windows. Scripting has been an integral part of enterprise-grade Windows administration ever since Windows entered the enterprise ecosystem. It has evolved and gotten a lot better, especially since Powershell came on the scene, and it will continue to evolve and get better, but we've already been scripting and automating Windows in the enterprise space since the '90s. (Though maybe not as well as we would have liked back then.)

But I will make a concession. There are Windows admins out there that don't script. A lot of them. And I do view that as a problem. Here's the thing: I believe that what made Windows so popular in the first place - its accessibility and ease of use because of its GUI - is also what leads to Windows being frequently misused and misconfigured by unskilled Windows administrators. And that, in turn, leads people to blame Windows itself for problems that could have been avoided had you hired a better engineer or admin to do the job in the first place.

GUIs and wizards are nice and have always been a mainstay of Windows, but I won’t hire an engineer or administrator without good scripting abilities. Even on Windows you should not only know how to script, but you should want to script and have the innate desire to automate. If you find yourself sitting there clicking the same button over and over again, it should be natural for you to want to find a way to make that happen automatically so you can go do other more interesting things. Now that I think about it, that’s a positive character trait that applies universally to any occupation in the world.

And yeah, it was true for a long time that there were certain things in Windows that could only be accomplished via the GUI. But that’s changing – and quickly. For instance, Exchange Server is already fully converted to the point where every action you take in the GUI management console is just executing Powershell commands in the background. There’s even a little button in the management console that will give you a preview of the Powershell commands that will be executed if you hit the ‘OK’ button to commit your changes. SQL Server 2012 will be the first version of SQL that’ll go onto Server Core. (About time.) The list goes on, but the point is that Microsoft is definitely moving in the right direction by realizing that the command line is (and always has been) the way to go for creating an automatable server OS. Microsoft is continuing to put tons of effort into that as we speak.

However, just because scripting on Windows is getting better now doesn’t mean we haven’t already been writing batch files and VB scripts for a long time that do pretty impressive things, like migrate 10,000 employee profiles for an AD domain migration.

I really love Server Core, but it's just a GUI-less configuration of the same Windows we've been using all along. Any decent Windows admin has no trouble using Core, because the command line isn't scary or foreign to them. For instance, one of the comments on this article reads:

"The root of the problem seems to be that Linux started with the command line and added GUIs later, whereas Windows did it the other way around."

I think that's false. Windows started as a shell on top on top of DOS – a command line-only operating system. DOS was still the underpinning of Windows for a long time and even after Windows was re-architected and separated from DOS, the Command Prompt and command-line tools were and still are indispensible. Now I will grant you that Linux had way better shells and shell scripting capabilities than Windows did for a long time, and Microsoft did have to play catch-up in that area. Powershell and Server Core came along later and augmented the capabilities of and possibilities for Windows – but the fact remains we’ve been scripting and automating things using batch files and VB Script for a long time now.

There was also this comment: “Another cause for slow uptake is that Windows skills don't persist.”

Again I would say false. I can run a script I wrote in 1996 on Server 2012 just fine, with no modification. Have certain tools and functions evolved while others have been deprecated? Of course. Maybe a new version of Exchange came out with new buttons to click? Of course – that’s the evolution of technology. But your core skillset isn’t rendered irrelevant every time a new version of the software comes out. Not unless your skillset is very small and narrow.

There was also this comment:

“I also complain that PowerShell is not a "shell" in a traditional sense. It is not a means of fully interacting with the OS. There is no ecosystem of text editors, mail clients, and other tools that are needed in the daily operation and administration of servers and even clients.”

As I mentioned earlier, there are fewer and fewer things every day that cannot be done directly from Powershell or even regular command-line executables. And to the second sentence - I’m not sure if there will ever be a desire to go back to an MS-DOS Edit.exe style text editor or email clients… but I could probably write you a Powershell-based email client in an hour if you really wanted to read your emails with no formatted styles or fonts. :)


So in the end, I think the original article had a good point - there probably are, or were, more Linux admins out there with scripting abilities than Windows admins. But I also think that's in flux and Windows Server is poised in a better position than ever for the server market.

Mortal Countdown

by Ryan 21. August 2012 19:06

I admit, this one is a little bit macabre. But it's something I was thinking about, and I was thinking about programming at the same time, so I decided to write a C# app for it!

 

 

You can use the Setup function of the app to set your birthday in UTC, down to the second if you know it, and how many years you anticipate spending on this mortal coil. (A figure which is subject to change, obviously.) The settings are saved in HKCU so you do not need to reset the info every time you reopen the app. Warning: It's a little creepy when you realize the percentage has crept up every time you hover over the hourglass.

That's pretty much all there is to it. 64-bit Windows and .NET 4 are required. There's no good reason for that other than that I don't like 32-bit Windows and < .NET 4. It's 2012, people.

As always, feel free to hit me with bug reports and enhancement requests.

Here's the executable: Mortal Countdown.exe (40.50 kb)

And here's the source (VS2010): Mortal Countdown.zip (64.30 kb)

About Me

Name: Ryan Ries
Location: Texas, USA
Occupation: Systems Engineer 

I am a Windows engineer and Microsoft advocate, but I can run with pretty much any system that uses electricity.  I'm all about getting closer to the cutting edge of technology while using the right tool for the job.

This blog is about exploring IT and documenting the journey.


Blog Posts (or Vids) You Must Read (or See):

Pushing the Limits of Windows by Mark Russinovich
Mysteries of Windows Memory Management by Mark Russinovich
Accelerating Your IT Career by Ned Pyle
Post-Graduate AD Studies by Ned Pyle
MCM: Active Directory Series by PFE Platforms Team
Encodings And Character Sets by David C. Zentgraf
Active Directory Maximum Limits by Microsoft
How Kerberos Works in AD by Microsoft
How Active Directory Replication Topology Works by Microsoft
Hardcore Debugging by Andrew Richards
The NIST Definition of Cloud by NIST


MCITP: Enterprise Administrator

VCP5-DCV

Profile for Ryan Ries at Server Fault, Q&A for system administrators

LOPSA

GitHub: github.com/ryanries

 

I do not discuss my employers on this blog and all opinions expressed are mine and do not reflect the opinions of my employers.