Earlier today, we reported that the installer of the A320-X by FSLabs contained a possible malware file with the name of “test.exe”. This file has since been confirmed to be a program that is able to look up Google Chrome usernames and passwords saved to the users computer. This report contained a statement from FSLabs CEO, Lefteris giving insight into what had happened. You can read the full story at this link.
Minutes ago, Lefteris added brand new statement on what has been going on. Similar to our last story, I’m going to simply copy and paste large portions of the text. This isn’t due to being lazy, but simply to ensure facts are being misinterpreted by myself for the community. However, here’s a brief summary:
- Lefteris reiterated that the “text.exe” file would only run under a very specific set of criteria to catch the pirate who had been avoiding FSLabs’ original security processes
- An apology was issued and FSLabs take full responsibility for this
- Customers who still feel their trust was violated are able to claim a full refund through the support ticket system
- There were multiple safe-guards in place to prevent the “test.exe” from running, although they realise this doesn’t justify even temporarily extracting it via the installer
- Another reiteration that no personal data was sent or kept
- The installer in question has been replaced and that FSLabs will never use such a ‘heavy-handed’ approach again in the future.
Like I said, this is just a summary of the lengthy post on their forums. I have copied it down below, or you can read it at FSLabs’ website. I strongly recommend you read it in full.
Again, please respect the comment section below and any questions for FSLabs, please go their forums directly where a member of the team can reach out to you.
We feel that it’s only fair that we disclose fully the extent of our DRM efforts here. So let’s discuss exactly that now – but first, I need to personally direct my attention to those who feel offended by our actions and to say that we realize it’s an issue whose extent we hadn’t grasped at first, but now fully understand and apologize that we offended you in any way.
I also want to thank the majority of our customers who have declared their support and continued trust already but for those who feel their trust was violated, we feel it’s only fair to offer full refunds of your P3Dv4 purchase, just let us know through a support ticket.
1) So – what exactly did our installers do?
As soon as the user entered their customer information (order ID / serial number / email) it verified this against our server database. Genuine customers and any other legitimate serial numbers trigger a full proper installation and no tool was called / used to figure out any pirate info. The installer that temporarily extracted the tool would remove it as part of its normal cleanup operation upon proper installation completion.
2) What happened with misspelled / misunderstood / unknown serial numbers?
As soon as any such wrongfully typed or mistyped piece of information would be detected, the installer would simply alert the user on the mistype and return to ask for the data again. It would not cause any tool to be called to figure out any pirate info, it simply stopped and waited for corrected information.
Again, no personal data would ever be extracted.
3) When – exactly – would the tool be triggered?
Flash back to our first A320-X release for FSX / P3Dv3 (32bit) – we discovered soon after the release of our product for those simulator versions that there were specific crackers who were successful in sidetracking our protection system by using offline serial number generators. We could not find how this would happen, but we happened upon a particular set of information (username / email / serial number) that would occur recurrently from specific IP addresses. We tried to add more tests in our subsequent installer releases, but the specific crackers were also upping their game in ensuring they sidetracked our installer. We even went so far as to figure out exactly who the cracker was (we have his name available upon request of any authorities), but unfortunately we could not be able to enter the registration-only web sites he was using to provide this information to other pirates. We found through the IP addresses tracked that the particular cracker had used Chrome to contact our servers so we decided to capture his information directly – and ONLY his information (obviously, we understand now that people got very upset about this – we’re very sorry once again!) as we had a very good idea of what serial number the cracker used in his efforts.
With our P3Dv4 installer, we discovered through more detailed installation logs that there was a specific set of pirate data that came up over and over again – so we decided to target that set of data directly. As a result, we made our server listen for a specific subset of data sent from the installer and when that was triggered, to dump that cracker’s information needed for us to gain access to those illicit web sites, so we could then forward the information to proper legal authorities.
What is very ironic here was that this method worked, in fact, and we were able to receive this information. We discovered with dismay that behind this person, there was an entire web of operations that had been set up that not only provided an interested person with a pirate copy of our product, but it used its own eSellerate key generators together with offline activators (by changing the activation server IP addresses to match the pirate servers) that would validate those keys directly. Apart from our company, there was a whole host of other flight simulator developer companies whose products were being shared and offline keys generated.
Here are two images that showcase two of the web sites in question. In the first, one can clearly see how extensive the damage to all our favorite add-on providers is.
4) How does that affect YOU as a customer?
The tool that was used to dump the pirate’s information will never execute on your machine – unless you were the particular person targeted that used that set of data mentioned above. Even if only some of the data matched, the installer would receive a negative response from our server and never execute it. Safe-guards on our servers ensured there was no possibility that any user other than the one targeted would actually have his personal details compromised. Even so, we realize that it doesn’t justify even temporarily extracting it via the installer on people uninvolved with this situation – this was a mistake.
As I mentioned in the first paragraph above, I wanted to ensure full disclosure first and foremost to our customers, some of who feel their trust was violated. This was not our intention and we take full responsibility. What we now understand to have been an overly heavy-handed approach to our DRM installer efforts also meant that our support team strictly followed the instruction guidelines without being aware of the inclusion of DRM tools in any of our installers.
I also want to reiterate there was no personal data sent or kept that would mean a breach of privacy, except for that subset of information regarding the web sites mentioned above.
We have already replaced the installer in question and can only promise you that we will do everything in our power to rectify the issue with those who feel offended, as well as never use any such heavy-handed approach in the future. Once again, we humbly apologize!
19 FEB 2018