Hardware protection against piracy on Windows RT 8.1
Reading a small note on a well-known news resource, I saw a funny introduction: “ New Microsoft tablets seem to be created in order not to buy them .” The doubtful, in my opinion, statement is still supported by the difficult fate of the first version of the Surface RT and the amazing similarity of the new Surface 2 to it. However, our company has always been primarily about customers.
The essence of this article, which may seem a bit provocative to Habr's readers, is as follows: at the end of 2013, we will introduce a new Guardant Code micro electronic key to protect applications on Windows RT from piracy. Someone, perhaps, is already twisting his finger at his temple, but we do offer developers serious (!) Windows RT applications to protect their software with a hardware key.
In the article you will learn:
1. Why did we need Windows RT 8.1 and why the first Windows RT is bad in terms of our tasks
2. How the whole structure works
3. How the limited architecture did not allow us to provide support for the electronic key in the form of a microSD card
4. ... and what crutches can I get around
')
Even before the release of Surface, we discussed the possibility of expanding the list of our target platforms on Windows RT. Yet a certain faith in Microsoft was present, besides, they have money. With money and the right approach, you can unleash anything on the market — although so far they haven't really got it. At the same time, Android also became the king of the smartphone market not in one day - so time will show the correctness of the MS strategy. In any case, we got the first version of the Surface a year ago, studied it closely and decided not to do anything. It is dangerous to climb into a non-existent market with our products - it was necessary to wait for the results of Surface sales for a couple of quarters and evaluate the interest of our category of customers.
We waited, made conclusions - and put Surface in the far drawer of the table.
This status of the project lasted until mid-summer of 2013, when Microsoft [apparently out of hopelessness] decided to give impetus to its product and began distributing it almost free of charge to the field of education (I exaggerate, of course), and also made a price-drop for everyone else. And in the field of education, in fact, there are serious products and there is piracy. So, the input data for July 2013: there is a “promising” platform, there are interested customers, there is a ready-made base in the form of the Guardant Mobile project (focused on Android with microSD and USB keys). Getting to work.
We started with our youngest and very niche product: Guardant SD. It is a microSD card with a microcontroller (hardware accelerated cryptography) and 4GB of general-purpose memory. This thing allows you to load into yourself and execute on board applets in Java using a very simple API. Architecturally, everything is very similar to our Guardant Code key, and is sharpened for application protection. Expensive business applications, for example, “Mobile Waiter” on Android tablets. The meaning is this: we place an important part of Java code into an applet, embed calls to our API in place of the cut code - and everything, part of the code is now executed on the map, the application, in addition to a set of bytes, receives an uncopyable hardware artifact and piracy says absolutely no. It works on Android, Windows, Linux and we tried to make it work on Windows RT.
Did not work out. The setup came from, let's say, the partial limitation of Windows RT.
It all started with the fact that wonderful, convenient and user-oriented Windows RT categorically refuses to see files with the "hidden" flag. In principle, why do they need a competitor iPad. Lyrical digression: the exchange with the key occurs through a regular file on the card, which by default is created by the microcontroller as hidden. Actually, forcing Surface to see this file turned out to be virtually impossible.
However, in reality this is avoidable. If you carry out the pre-sale preparation of the card on any other platform - you can forcibly create this file unhidden, and the microcontroller will not touch this flag. Of course, the very first formatting of the card or deleting a file will make the key inoperable, but you can always recreate this file.
The real problem came from another place, even though it’s nearby. It all happened this way: we sported the main part of the code (the base of the low-level library implementing the exchange protocol with the card), tried to send the APDU to the card — and we cannot move beyond the first command. The feeling that the microcontroller simply does not want to give us the answers. In general, we did not have long to rummage through the Internet and torment the manufacturer of the microcontroller: in Windows RT, non-switchable read buffering was discovered. Those. You can send a request to the card and flush the record, but you can not read the answer - it takes it from the buffer. Obviously, Windows RT cannot assume that the file on the card can be changed from within it, in our case, by the microcontroller. A hundred man-hours of expensive development, although it was practically flushed down the toilet, but allowed us to better explore the platform.
Naturally, we rummaged through all the documentation and the Internet, talked to representatives of Microsoft, but got a line on the hands and left this project - it is impossible, it is impossible.
However, our engineering minds were not ready to give up so easily. It was hard to believe that there would not be a pair of crutches to circumvent this limitation. They found. Here is a two-step recipe:
1. Create a file on the card for the exchange of 400 MB.
2. We force the firmware to write the microcontroller's answers sequentially, and not all the time to the beginning of the file.
And here it is, unreliable and crooked - but a working solution. With this file size, Windows RT does not decide to cache it for reading completely, and since the answer is always written to a new address in the exchange file, it is perfectly readable. Slowly - due to the size of the file - but read.
Despite the solution found, it did not go into production due to the following concerns:
• A significant increase in RAM in future Surfaces may allow Windows RT to still cache this file for reading in its entirety (or at least in significant parts)
• We eat off a significant part of the 4GB flash memory card (and the slot for microSD in the tablet only)
• When 400MB runs out, the answers need to loop and write to the beginning of the file - and there already something can be cached
• It all works rather slowly.
Of course, we were pleased with our ingenuity, but decided to try to adapt Guardant Code micro USB to the tablet. Fortunately, the USB port is guaranteed there and the micro-key doesn’t interfere much (see the picture at the beginning of the article).
Deciding that with a USB key we would not run into these problems, we rushed into battle. Translated the key into the HID mode, stuck into the tablet - the key was determined, the LED is on. You can start sharing data.
We were again disappointed. In the WinRT API, there was not a single way to send something to a custom USB device, even despite our honest support for HID. Microsoft, of course, designed Windows RT as a closed ecosystem (operating system, hardware, single application store) - but this is shameless closeness.
By the end of July, the situation was as follows: hands are falling, our devices do not adapt to Surface, it's time to tell customers a decisive and reasonable "no."
And here we pay attention to the announced Windows RT 8.1, and already available Preview version.
On Windows RT (in particular, on Surface) a rather compulsory Windows Update is implemented. Thus, it can be assumed that the majority of Surface users (no matter how small their number may seem) will not take long to upgrade to 8.1. At the same time, in the new version, a pleasant surprise awaited us: support for working with arbitrary HID devices. As mentioned earlier, our modern dongles can work with a proprietary protocol that requires a driver, or in the HID mode. Work without a driver slightly reduces the speed and security of the exchange, but does not create any critical situation. Since for mobile platforms we support only Code, security still depends on the code that the client will transfer from the application to execute it on board the key.
The development process for Windows 8.1 was predictably successful. The new APIs from MS were excellent, even in the Preview version, and we didn’t face any significant difficulties. And finally, on the third attempt, we had a product for protection against piracy on Windows RT.
In fact, the developed library allows you to split the application into two parts:
1. Application for Windows Store
2. The key intellectual part rendered to the Code key (up to 50,000 lines of C code).
The code is called by a single CodeRun function, with an input and output buffer and a selector (to make a switch inside and select the desired code fragment for execution). Of course, you can create arbitrarily cunning logic using buffers to maximize the difficulty of analysis.
In fact, we get two things “for the price of one”: with a successful choice of a downloadable code, we have protection from analysis and modification (an important code inside the key), and, of course, we get an uncopyable entity in the form of a hardware key, which is an integral part of the application.
And a few important things in the end:
• In the application manifest, you need to manually add lines to allow work with dongle
• Even the most innocuous access to the key requires confirmation via the GUI dialog, so with the unit test library without a GUI, this is not even tested - there will be an exception
• You can not access the key from the main program thread
On this note, my story about Windows RT and copyright, I finish. As far as the hardware keys of protection are needed and appropriate at the end of 2013 on a platform that has not yet been spun, time will tell. At least MS was able to bail out $ 400 million from Surface sales in the last quarter, which is already a good sign, especially after writing off $ 900 million the year before last.
The essence of this article, which may seem a bit provocative to Habr's readers, is as follows: at the end of 2013, we will introduce a new Guardant Code micro electronic key to protect applications on Windows RT from piracy. Someone, perhaps, is already twisting his finger at his temple, but we do offer developers serious (!) Windows RT applications to protect their software with a hardware key.
In the article you will learn:
1. Why did we need Windows RT 8.1 and why the first Windows RT is bad in terms of our tasks
2. How the whole structure works
3. How the limited architecture did not allow us to provide support for the electronic key in the form of a microSD card
4. ... and what crutches can I get around
')
First contact
Even before the release of Surface, we discussed the possibility of expanding the list of our target platforms on Windows RT. Yet a certain faith in Microsoft was present, besides, they have money. With money and the right approach, you can unleash anything on the market — although so far they haven't really got it. At the same time, Android also became the king of the smartphone market not in one day - so time will show the correctness of the MS strategy. In any case, we got the first version of the Surface a year ago, studied it closely and decided not to do anything. It is dangerous to climb into a non-existent market with our products - it was necessary to wait for the results of Surface sales for a couple of quarters and evaluate the interest of our category of customers.
We waited, made conclusions - and put Surface in the far drawer of the table.
This status of the project lasted until mid-summer of 2013, when Microsoft [apparently out of hopelessness] decided to give impetus to its product and began distributing it almost free of charge to the field of education (I exaggerate, of course), and also made a price-drop for everyone else. And in the field of education, in fact, there are serious products and there is piracy. So, the input data for July 2013: there is a “promising” platform, there are interested customers, there is a ready-made base in the form of the Guardant Mobile project (focused on Android with microSD and USB keys). Getting to work.
Unsuccessful attempt
We started with our youngest and very niche product: Guardant SD. It is a microSD card with a microcontroller (hardware accelerated cryptography) and 4GB of general-purpose memory. This thing allows you to load into yourself and execute on board applets in Java using a very simple API. Architecturally, everything is very similar to our Guardant Code key, and is sharpened for application protection. Expensive business applications, for example, “Mobile Waiter” on Android tablets. The meaning is this: we place an important part of Java code into an applet, embed calls to our API in place of the cut code - and everything, part of the code is now executed on the map, the application, in addition to a set of bytes, receives an uncopyable hardware artifact and piracy says absolutely no. It works on Android, Windows, Linux and we tried to make it work on Windows RT.
Did not work out. The setup came from, let's say, the partial limitation of Windows RT.
It all started with the fact that wonderful, convenient and user-oriented Windows RT categorically refuses to see files with the "hidden" flag. In principle, why do they need a competitor iPad. Lyrical digression: the exchange with the key occurs through a regular file on the card, which by default is created by the microcontroller as hidden. Actually, forcing Surface to see this file turned out to be virtually impossible.
However, in reality this is avoidable. If you carry out the pre-sale preparation of the card on any other platform - you can forcibly create this file unhidden, and the microcontroller will not touch this flag. Of course, the very first formatting of the card or deleting a file will make the key inoperable, but you can always recreate this file.
The real problem came from another place, even though it’s nearby. It all happened this way: we sported the main part of the code (the base of the low-level library implementing the exchange protocol with the card), tried to send the APDU to the card — and we cannot move beyond the first command. The feeling that the microcontroller simply does not want to give us the answers. In general, we did not have long to rummage through the Internet and torment the manufacturer of the microcontroller: in Windows RT, non-switchable read buffering was discovered. Those. You can send a request to the card and flush the record, but you can not read the answer - it takes it from the buffer. Obviously, Windows RT cannot assume that the file on the card can be changed from within it, in our case, by the microcontroller. A hundred man-hours of expensive development, although it was practically flushed down the toilet, but allowed us to better explore the platform.
Naturally, we rummaged through all the documentation and the Internet, talked to representatives of Microsoft, but got a line on the hands and left this project - it is impossible, it is impossible.
However, our engineering minds were not ready to give up so easily. It was hard to believe that there would not be a pair of crutches to circumvent this limitation. They found. Here is a two-step recipe:
1. Create a file on the card for the exchange of 400 MB.
2. We force the firmware to write the microcontroller's answers sequentially, and not all the time to the beginning of the file.
And here it is, unreliable and crooked - but a working solution. With this file size, Windows RT does not decide to cache it for reading completely, and since the answer is always written to a new address in the exchange file, it is perfectly readable. Slowly - due to the size of the file - but read.
Despite the solution found, it did not go into production due to the following concerns:
• A significant increase in RAM in future Surfaces may allow Windows RT to still cache this file for reading in its entirety (or at least in significant parts)
• We eat off a significant part of the 4GB flash memory card (and the slot for microSD in the tablet only)
• When 400MB runs out, the answers need to loop and write to the beginning of the file - and there already something can be cached
• It all works rather slowly.
Of course, we were pleased with our ingenuity, but decided to try to adapt Guardant Code micro USB to the tablet. Fortunately, the USB port is guaranteed there and the micro-key doesn’t interfere much (see the picture at the beginning of the article).
Second failed attempt
Deciding that with a USB key we would not run into these problems, we rushed into battle. Translated the key into the HID mode, stuck into the tablet - the key was determined, the LED is on. You can start sharing data.
We were again disappointed. In the WinRT API, there was not a single way to send something to a custom USB device, even despite our honest support for HID. Microsoft, of course, designed Windows RT as a closed ecosystem (operating system, hardware, single application store) - but this is shameless closeness.
By the end of July, the situation was as follows: hands are falling, our devices do not adapt to Surface, it's time to tell customers a decisive and reasonable "no."
And here we pay attention to the announced Windows RT 8.1, and already available Preview version.
The third attempt, successful
On Windows RT (in particular, on Surface) a rather compulsory Windows Update is implemented. Thus, it can be assumed that the majority of Surface users (no matter how small their number may seem) will not take long to upgrade to 8.1. At the same time, in the new version, a pleasant surprise awaited us: support for working with arbitrary HID devices. As mentioned earlier, our modern dongles can work with a proprietary protocol that requires a driver, or in the HID mode. Work without a driver slightly reduces the speed and security of the exchange, but does not create any critical situation. Since for mobile platforms we support only Code, security still depends on the code that the client will transfer from the application to execute it on board the key.
The development process for Windows 8.1 was predictably successful. The new APIs from MS were excellent, even in the Preview version, and we didn’t face any significant difficulties. And finally, on the third attempt, we had a product for protection against piracy on Windows RT.
In fact, the developed library allows you to split the application into two parts:
1. Application for Windows Store
2. The key intellectual part rendered to the Code key (up to 50,000 lines of C code).
The code is called by a single CodeRun function, with an input and output buffer and a selector (to make a switch inside and select the desired code fragment for execution). Of course, you can create arbitrarily cunning logic using buffers to maximize the difficulty of analysis.
In fact, we get two things “for the price of one”: with a successful choice of a downloadable code, we have protection from analysis and modification (an important code inside the key), and, of course, we get an uncopyable entity in the form of a hardware key, which is an integral part of the application.
And a few important things in the end:
• In the application manifest, you need to manually add lines to allow work with dongle
• Even the most innocuous access to the key requires confirmation via the GUI dialog, so with the unit test library without a GUI, this is not even tested - there will be an exception
• You can not access the key from the main program thread
On this note, my story about Windows RT and copyright, I finish. As far as the hardware keys of protection are needed and appropriate at the end of 2013 on a platform that has not yet been spun, time will tell. At least MS was able to bail out $ 400 million from Surface sales in the last quarter, which is already a good sign, especially after writing off $ 900 million the year before last.
Source: https://habr.com/ru/post/199016/
All Articles