(See Anyone know what CompatTelRunner.exe is/does?)

Using procexp.exe, I found that the offending process was started from a scheduled task, namely, Microsoft Compatibility Appraiser, which is found in Computer Manager under Task Scheduler\Microsoft\Windows\Application Experience\ProgramDataUpdater. There are three tasks in that folder.

The description of the task says "Collects program telemetry information if opted-in to the Microsoft Customer Experience Improvement Program.", so I suppose we can simply opt-out from the telemetry program and this should not run anymore. I believe that is in Settings->Privacy->Feedback.

However, Windows Insider machines probably require this to be on, in which case we can go about disabling the tasks in Task Scheduler.

While I do not consider this an 'official'  solution, it alleviated the problem in my machines as far as I can tell.

In honor of the good-old-days, I have recreated the Windows 1.0 screenshot from the Windows History, using Windows 10 programs and Outlook:

What other features of Windows 1.0 should we expect from Windows 10?

But more importantly...if the trend continues, will Windows 13 look like Windows 3.1?

Only time will tell...

PS: while you are here, don't forget to run MSDOS in your Windows Phone - they are already bringing back Win 3.1, so you can start getting used to it again.

:-)

Obviously, it was taking forever to get any meaningful amount of coins - which is by design, I get it. The game allows you to pay real cash for these virtual coins, in the hopes that the emotional connection you have with the game will make you think it is worth paying for.

Unlike my kid, I have lost the energy to spend on such endeavors so I began wondering how the game implemented their 'coin storage'.

In this particular game, which I'll leave unnamed for the sake of the developers, you can buy coins over and over, so my instinct was to assume they were simply storing the amount of coins a gamer has in the LocalSettings of the ApplicationData class, which are implemented in Win8 using Registry hives. That being the case, we can load and inspect hives manually in the registry, so I decided to give it a try.

I loaded the Registry Editor, selected the HKEY_LOCAL_MACHINE root and chose File->Load Hive. The %USERPROFILE%\AppData\Local\Packages folder contains user settings for the modern Win8 applications. Each app has its own folder and under that there is the Settings\settings.dat file, which happens to be a registry hive. We loaded that and explored the keys and values. As luck would have it, this particular game happens to store the number of coins the games has with a setting named, guess what, "coins".

Oh, that's too easy...

WinRT settings uses binary blobs to store the values in the registry, but I noticed a pattern among them, so it was a safe bet that part of the blob was encoding the type of the data ("integer" in this case) while the first 4 bytes of the "coins" value were the raw hex value of the number of coins we had accumulated so far in the game.

I just bumped that value up to FFFFFFFF and unloaded the hive. To be honest, I expected the app to crash, but after restarting the game I found that I was the (not so proud) owner of a lot of coins and that we could use them at will. There were other settings as well in the game that you could buy with the coins, and I suppose I could have tweaked them as well.

The whole process took a couple of minutes, if that much. Again, way to easy....

Out of that little exercise in cheating I came up with three lessons:

1. For the kids who love playing the game:
   The game lost its appeal. If you want to keep playing that funny addictive game you love so much, don't cheat! After all, if you cheat and 'beat' the game like this you lose the emotional connection you would otherwise have with the game and then it is just not that much fun anymore.
    
2. For the kids whose dads (like me) just won't let them pay for games on a daily-basis, or if you just want to see how the game works without having to play for endless hours:
   Emotional-connection? Yeah, right. We can try to tweak the game settings and see what happens - with the usual disclaimer that doing so can render the game unplayable if you don't know what you are doing. There is also the option of running in the debugger - that's always fun... :-)
    
3. And the real objective of this post, is for developers out there:
   Do add a minimum of encryption on top of these things that people are supposed to pay for, otherwise it is a lost opportunity for profit. A little work with the DataProtectionProvider or some other API will protect these settings from quick tweaks like this and that translates to either an actual purchase or at least some more hours of game play and the ads that come along with them, and those are money in the pocket, so there's no reason to leave things in the open.

Obviously, not every game out there makes this mistake, so this only works on a case-by-case basis.

And it is likely that the popular games that you REALLY want to do something like this will be exactly the ones where they will protect themselves.

:-)

Exchange Control Panel is a web application designed to provide self-service management of Exchange features to end-users and administrators alike.

For the end-user, ECP appears as the OWA Options page, where one goes to customize a number of settings, like Inbox Rules, Out-of-Office and Voice Mail settings – you can see a complete list in this online help topic. ECP is also integrated with Outlook 2010 in the sense that the UI for certain options in Outlook are in fact implemented by the ECP application.

ECP lights up additional options when a user with administrative permissions logs in and presents options such as management of mailboxes, groups and external contacts as well as other scenarios like Reset Passwords, Delivery Reports, configuration of mailbox service plans and user roles, all according to the user’s rights specified by Exchange’s Role Based Access Control (RBAC).

ECP Architecture

ECP is designed as an ASP.net AJAX application, built on top of business logic provided by the Exchange PowerShell cmdlets and using WCF web services and JSON to communicate between the client application and the server application.

The client side of ECP runs in multiple browsers while the server side runs in Windows 2008+IIS7, in an Exchange server setup as a Client Access Server.

ECP uses the same PowerShell cmdlets available in the command line interface, keeping our motto that ‘anything you can do in the UI, you can do in the command line’. The same set of RBAC permissions controls what a user can do in PowerShell and in the ECP UI.

From a logical point of view, ECP is divided in three parts:

• Common Infrastructure
  Several pieces that make ECP work are part of a common infrastructure shared with other Exchange applications, like Outlook Web Access (OWA) and Exchange Management Web Service (EMWS). These include things like Live ID authentication, RBAC, PowerShell and more mundane things like tracing, performance counters, event log, etc. Several teams work with this code one way or another.
  
  
• ECP Application Infrastructure
  ECP itself provides an infrastructure of common controls, scripts, services and resources necessary to build Exchange features. There's usually nothing too particular to Exchange itself in this code as one could use it to build other types of applications with it. Infrastructure code can be simple or complex depending on the needs of all features that use it. It eventually stops growing as it meets the requirements of all features. The idea is that only the ECP team deals with this code.
  
  
• Feature Code
  Finally, in ECP there are pages and controls that implement one particular feature of Exchange. This is the part of ECP that grows over time, as more and more features are added to it. The idea is to make writing feature code so easy that we can let component teams write their own feature UI, just like they build their own cmdlets. In most cases, feature UI in ECP boils down to a list view or a form, with web services used as data source.

Physically, ECP code can be divided in four main groups:

• Server Controls
  Server-side controls written in C# gives us the necessary functionality and abstractions that simplify the creation of markup files. They are part of ECP's Infrastructure.
  
  
• ECP Client Library
  The ECP client-side application is written in Script#, compiled into JavaScript and executed on the browser. For the most part it is all Infrastructure code although complex features have scripts of their own.
  
  
• ECP Web Services
  A set of C# WCF web services with JSON behavior provide the client library with the necessary entry points to invoke cmdlets in the server. Each feature provides its own data contracts and the final web service code, which is implemented with the help of base classes provided by the Infrastructure.
  
  NOTE: the web services endpoints exposed by ECP are not regarded as public API and serve only the needs of the ECP application – they are not to be used as a general programming endpoint as their requirements can change from version to version. Applications that wish to call Exchange management functions remotely must use Remote PowerShell.
  
  
• UI Markup
  ECP UI is built with ASPX and ASCX markup files, where we define the controls to show, the web service that provides data for the page, client side data-bindings and the RBAC permissions required by each control.
  
  The markup pages are divided in the following groups:
  • Infrastructure pages provide the main frame and a set of error pages for the application.
  • Feature List View pages, shows a list of objects and their associated commands.
  • Feature Form Pages, shows a form where users can edit the properties of an object.

In most cases feature-specific pages do not require any additional code-behind, since all the heavy lifting is done by the infrastructure controls, either on server code or client code.

The following diagram gives us a high level view of how the pieces come together to form ECP:

The ECP client library and the Microsoft AJAX framework run in the client browser.

Browser requests are handled by IIS and are authenticated with either Windows Live ID, Windows or OWA’s Form Based Authentication, depending if we are in a datacenter or in an enterprise deployment.

After the request is authenticated we build the user session, where we keep track of the user settings and in particular of the user’s permissions. At this point we can authorize the request.

Requests for UI components is handled by the ASPX handler of each page. Feature pages and application wide pages (such as default.aspx and error.aspx) rely on the server controls infrastructure to render the proper HTML and JavaScript to be executed by the browser. RBAC is involved to hide portions of the UI that the user does not have permissions to use, or to make them read-only.

Web service calls are handled by the respective WCF service, exposed by a JSON end-point. Each specific feature provides its own web service with a set of well-known contracts understood by the server controls and the client library. While the contracts are generic, allowing each feature to control exactly what comes in and what goes out in each web service call, all features look and behave the same, allowing a single set of controls to work seamlessly across all features.

The feature web services uses infrastructure code to translate data between WCF data contracts and PowerShell cmdlets, to invoke the respective cmdlets and to return data from PowerShell to the client application to consume. RBAC is involved to restrict access to just the cmdlets and parameters that the user has access.

Once the request reaches cmdlet code the operation is persisted in the system by the appropriate business logic.

Summary

• Exchange 2010 Web Management Interface, aka, Exchange Control Panel is an ASP.Net application running in an Exchange Client Access server.
• Uses ASP.net to render HTML UI.
• Uses Script# to compile C# into JavaScript.
• Client code runs in multiple browsers.
• Uses WCF+JSON to respond to web service calls from the client application.
• Uses RBAC to control what users can see or not in the application UI and what cmdlets and parameters can be used in web services.
• Uses Exchange PowerShell Cmdlets to execute business logic.

In future articles we will look at those individual pieces in more details.

The main idea with SecureString is that you would never store a password or other textual secret in plain text, unencrypted memory – at least not in a System.String instance. Unfortunately, SecureString was introduced in the framework only after plenty of APIs were built and shipped using passwords stored in String, such as System.Net.NetworkCredential, so an application that must use these APIs has no option but to convert SecureStrings to strings.

However, the SecureString class itself doesn’t provide any methods to get back a plain string with its content, exactly to discourage this type of usage. What a developer has to do is use functions from System.Runtime.InteropServices.Marshal to get a native buffer with the plain string, marshal the value into a managed string then – very importantly – free the native buffer.

And this is where I’ve seen people people making mistakes. You can certainly spot the problems in the following functions:

public static string BAD_ConvertToUnsecureString(this SecureString securePassword)
{
    IntPtr unmanagedString = Marshal.SecureStringToGlobalAllocUnicode(securePassword);
    var s = Marshal.PtrToStringUni(unmanagedString);
    Marshal.ZeroFreeGlobalAllocUnicode(unmanagedString);
    return s;
}

public static string REALLY_BAD_ConvertToUnsecureString(this SecureString securePassword)
{
    IntPtr unmanagedString = Marshal.SecureStringToGlobalAllocUnicode(securePassword);
    return Marshal.PtrToStringUni(unmanagedString);
}

The first one is almost ok, but if an exception happens after the native buffer is allocated then we leak that password. The second one is just plain wrong; the developer completely forgot to free the native buffer, introducing an unconditional leak of that password.

I’ve seen both mistakes being freely cut-and-paste because the original code was embedded in a larger function that was doing multiple things, so the details of the conversion were easy to overlook. Lacking a simple, reusable function leads to that, so don’t let these bugs creep into your project.

The correct implementation is to use a try/finally block to free the native buffer. Here’s an example, using SecureStringToGlobalAllocUnicode and ZeroFreeGlobalAllocUnicode:

public static string ConvertToUnsecureString(this SecureString securePassword)
{
    if (securePassword == null)
        throw new ArgumentNullException("securePassword");

    IntPtr unmanagedString = IntPtr.Zero;
    try
    {
        unmanagedString = Marshal.SecureStringToGlobalAllocUnicode(securePassword);
        return Marshal.PtrToStringUni(unmanagedString);
    }
    finally
    {
        Marshal.ZeroFreeGlobalAllocUnicode(unmanagedString);
    }
}

Please understand that a little village bursts on fire every time you call such a function, but if you do need it, write it like this, so there’s no excuse for anyone to write that code again.

The extension method syntax makes it easy to call the conversion as if it was part of SecureString itself:

SecureString password = someCodeToGetSecureString();
var credentials = new NetworkCredential(userName, password.ConvertToUnsecureString())

While at it you may want to provide the counterpart that converts a plain String to a SecureString. Following the same pattern as above we’ll have:

public static SecureString ConvertToSecureString(this string password)
{
    if (password == null)
        throw new ArgumentNullException("password");

    unsafe
    {
        fixed (char* passwordChars = password)
        {
            var securePassword = new SecureString(passwordChars, password.Length);
            securePassword.MakeReadOnly();
            return securePassword;
        }
    }
}

The important point here is to mark the secure string as read-only before returning it – it is very unlikely that you’ll need to edit a secure string that was created from an existing string. You’ll also note that in the above example I used unsafe code to initialize the SecureString from its fixed/char* representation, which is about 10x faster than using AppendChar. If you are not allowed to use unsafe code, don’t worry, just write it using AppendChar and it works fine.

I’m not proud to have clear text passwords in my process memory, but we’ll have to live with it until the day somebody updates the framework to use SecureString everywhere, particularly in System.Net.

If you need to learn more about SecureString this post is a great start: https://blogs.msdn.com/shawnfa/archive/2004/05/27/143254.aspx.