Reversing LINQPad - Part 6 - Conclusions

In the previous posts, I have analyzed the LINQPad program, and a LINQPad Server proxy for creating valid Authorization Licenses. This post will summarize all that I have gleaned from my analysis to discuss ways I think could be used to target the LINQPad authorization scheme.

Introduction

LINQPad is a code snippet IDE that instantly executes C#, F# and VB expressions, statement blocks or programs dynamically - e.g. without a Visual Studio project or solution. There are paid versions that enhance the functionality by providing the user with Intellisense and a debugger. You can find out more information about the application on the website.

Disclaimer

I am not responsible for your use of the information provided here. At the time of this writing, the following information is not against the End User License Agreement as I will not be distributing modifications to LINQPad, sub-licensing it, or circumventing any paid edition usage restrictions. In this series; however, I will be discussing what protections the software has and what methods could be taken to bypass them.

Additional Work

Even after the patches have been made to the LINQPad.Resources.dll; it will have to be converted to the .bin format it was taken from. And then the original .bin file must be replaced with the patched file. XenocodeRCE@rtn-team suggested that this could be done with CodeCracker's Resource Manager.

Potential Exploit Points

Over the course of the analysis, I believe there are a total of four ways to upgrade LINQPad illegitimately. Overall, I found the LINQPad application to be pretty well protected. However, the application must trust the client for some important operations which will be the most likely place to bypass the protections. All of the illegitimate bypasses discussed below will require patches be made to the LINQPad assembly.

Register Online

As seen in the LINQPad Server application, the authorization can be directed to a false LINQPad Server via a proxy. This functionality is built into the application so that users can register the application from an isolated network. This is useful because it allows users to register machines that would otherwise be unable to communicate with the official LINQPad server. Even if the application did not provide this functionality, the request could still be directed to a false LINQPad Server via host file manipulation. Or the LINQPad application could be patched to use a different server.

There is not much that can be done to prevent this from occurring because the client decides where to route the request. The RegisterOnline functionality sends the server some data about the local machine and gets a response back. The client is trusted with this data to determine whether the application should be activated. The author does have some code to check if the response received back matches the signature (basically performs a CRC check on the response) but overall the client is trusted. Since the application parses the activation message on the client, a server can be created to give the expected response - with maybe a patch to the RSA key or to skip the validation check.

Register Offline

Also seen in the LINQPad Server application. This exploit uses the RegisterOffline capabilities of the client to generate a proper authorization license. If the application is not able to connect to the LINQPad Server then data about the machine is packaged into a string that must be pasted into the RegisterOffline form on linqpad.net. This is useful for applications that do not have internet access.

There is not much that can be done to prevent this from occurring either as the client contains all of the logic responsible for generating the Offline Data used by LINQPad Server to generate the response. Similarly, both the RegisterOnline and RegisterOffline capabilities reuse the sections of code responsible for parsing and validating the license - which is great for maintainability but also means they suffer from the same weaknesses.

Activation License Generation

A new method I thought of while analyzing the LINQPad and LINQPad Server applications is to skip the spoofing of the server and write an application to generate the Activation License on the machine being registered. This is similar to the other methods but does not require the user to set the proxy data or copy the Offline Data string to an application. The user simply sets the licensee name and generates an Activation license.

This one is difficult to prevent, because the activation message will be built using only the logic to check if the license is valid - just like the other exploits. This piggybacks on the previous exploits but does not rely on interpreting the data generated by LINQPad - instead it builds the message to take the code flow through the license verification that the user wants. If the license logic were to change, this could impact future versions however.

License File Generation

Instead of using LINQPad licensing logic, an application could be written to create the license file directly. This license file is checked upon start-up so the patches would still need to be made; similar to the previous exploits but this is another attack vector - and the number of steps the user has to take would be smaller. The code responsible for this is the RegisterLicense in the LicenseManager that stores the data in an xml file.

Not much can be done here because too much control is given to the client application. Any attempt to encrypt the data could be undone with a patch to the client or taken from the assembly.

Summary

I was impressed with the amount of time it took to analyze LINQPad. It turned out to be an interesting and enlightening subject. Although I believe too much control is given to the client when it comes to the licensing scheme. As soon as I understood the WSAgent class (and related classes) figuring out ways to bypass the licensing mechanism became trivial. All of the information I needed was included in the assembly. I realize that patches will have to be made to the assembly which would technically violate the integrity of the application. However, the patch required is trivial (in theory).

I believe one simply needs to alter the RSA key in the assembly to a public key that the user knows so that the generated license message will pass the validation check. From there the license data just needs to be reversed further to understand what each of the properties represents. I gave some brief suggestions to what these values could be - although not much analysis was done as it did not have to do with the protections. LINQPad is a great application and I will continue to use it as a test pad for small applications.

It is obvious the author of LINQPad has put a lot of time and care into cultivating a quality product. If you find LINQPad useful please support the author by purchasing a license.