Anti Piracy

[Herbie63 0]

Hi everybody,Like many of us I'm doing some things for a 3PD. And like all of us we're thinking about a way to protect our work against piracy.I'm trying to realize a new approach by making parts of the aircraft or gauges invisible so that the use of the aircraft gives no real fun (I hope). For this I need to read out a computer (hardware) specific information like the computer name, the MAC-ID or whatever.This info will have to be sent to the 3PD to generate a computer specific code. This code will be compared at aircraft ini with the info of thePC where the sim is running on. Actually it's a bit more complicated, but I guess you can imagine how it will work. Something similar like MS's FS registration.I know this can be hacked or cracked but in the end it will lead to significant less piracy, I hope.Now, there are two questions:A) Is this (reading out a computer specific info) legal or would it get in conflict with any laws / personal rights? (Maybe something like an EULA could solve this problem... ?):( Is a C++ gauge able to read out such an information like the Computer name or MAC-ID?Thanks for your help!Herbert

[Guest ziporama]

As far as your first question, you should probably get advice from legal counsel.As for the second part, you can access what you want from the C/C++ runtime library. Typically, this kind of information is obtained through WMI services in windows.The machine IDs you can use include the hard disk volume ID (unique for the partition), the CPU ID, BIOS serial number, and the network MAC ID. The later can be tricky because it can be changed fairly easily. CPU ID is much harder, but that is a BIOS setting. Not all BIOS settings are equal, and you'll be hard pressed finding any one of those returning data all the time - each motherboard/CPU combination will give you different results.There are several examples on the web on how to get that information and make it reasonably consistent across the board.Etienne

[Rocky 128]

I also thought abou this question...In fact, your goal is that when you provide a software to a customer, this customer is the only one who can use it. If he gives it to his friend (or to the whole planet), this software will not work for others.So you thought about identifying the customer through some hardware unique IDs. Good idea, but people usually don't like this. Why? Just because if they format or change their HD, the HD number changes. If they change their PC, their CPU ID, BIOS and MAC address will change. Consequence: they have to re-contact the vendor to get a new key. But what happens if this happens 2 or 3 years after they purchased the product? What if they can't find their proof of purchase? What if the vendor does not exist any more? In other words, it is a good solution, but it has some limits.Now I thought about another idea: I generate a key based on the e-mail address of the customer. If someone wants to provide his key on Internet, he also has to provide his e-mail address and he is identified. It is a very weak protection because many people have just created a temporary Hotmail address and used it for purchase.So I came to the final idea, never implemented yet: What do you think about generating a key based on the credit card number of the customer? Imagine the scenario: the customer uses his credit card to purchase, so you have the number. Then you lock the software so that the key IS the credit card number, and you ask the customer to enter his credit card number to register the product. Do you think he will be willing to put his credit card number on Internet? I don't think so... It means that people can upload he software on pirate sites, but nobody can use it because the key (the credit card number of the buyer) will never be provided on a website.Your opinion about this is welcome, don't hesitate to tell me what you think.Eric

[Varmint007 2]

Hi Eric,I use a hardware algorithm, but it's weighted for hardware changes. In other words, you can change a drive, change a mobo or even a combination of things over time without triggering an invalid hardware code. This alleviates SOME of the headache. Of course if you go an build or buy a completely new computer, the end-user must still perform a license transfer. But if the transfer process if automated, then that can also be a fairly painless experience.Regarding your credit card idea, it sounds great in theory, but don't you still need to be able to parse your own keys? In other words, the software still needs to know if it's dealing with a valid key, so what's to stop somebody from just distributing a stolen credit card number with the software, even if the credit card has been canceled long beforehand? --Jon

[Rocky 128]

Hi Jon,I understand your point. It looks like you are building the most efficient protection system. By any chance, will you licence it or do you develop it only for 1 3PD? I ask you this because some of my friends may be interested in using it ;-)About the credit card system, you're partially right. But in my scenario, the customers use their credit card to buy the software online, so you have it, and you are sure that it is valid. Then you generate your key, based on this number. So you are sure the number is valid at this time. But you're right, if the credit card expires 2 months after the product purchase, the number has no validity any more and it can be distributed on a pirate website...Eric

[Varmint007 2]

Eric, I use a commercially available SDK which also happens to offer completely automated activations and even a very robust customer ticketing and tracking system. You can even perform remote deactivations if, for example, a cc returns fraudulent or a customer creates a chargeback. I also use the system to distribute automatic updates and notices any time our aircraft utility is run.I can't give you the name of the system here, but if you email me at j b l u m @ vrsimulations dot com I'll be happy to show you what it is and let you decide if it might suit your purposes. I should add that I'm not actually using this system to protect gauges themselves - yet. I use it for an aircraft manager which is in turn critical for using the aircraft.They also have a wrapper version which may work fine for things like .dll or .gau files, but the SDK version is much more customizable.--Jon

[Herbie63 0]

Eric,That idea sounds interesting. But do you really see the credit card number? Isn't the payment processed by a secure system that does NOT give you the credit card number of your customers?Herbert

[Rocky 128]

Herbert,You're right, this is the case with most payment solution such as Paypal that I have used. But I think this can be negotiated with the electronic payment provider. But anyway I think this is not the good solution...Eric

[Herbie63 0]

Reduced to the very basic things a secure protection would have to work like this, I think:The code to check if the add on (in this example an aircraft) is allowed to run on a certain machine should be inside the model. As much as I know it is almost impossible to decompile a mdl file to change a piece of code inside. But even if so - only a very few should have this capability.That piece of codes needs to check a hardware / software specific parameter. Maybe the Windows serial might be the best, as this will remain the same even if you add new hardware.Now you need to know about the customer's Windows serial - and this will be the problem - not in technical terms, but in legal...But let's imagine the customer will tell you that serial (or maybe an other not that 'critical' hard-/software detail). So the best would be to compile the model individually for each customer.So one unique product for one unique customer. No chance that it will work on an other machine.What's missing now is a convenient way to compile the model with the necessary piece of code for each single customer.Unfortunately all this is beyond my skills, but maybe if someone gets that working she/he will me let me know how...Best,Herbert

[n4gix 4,947]

Unfortunately, it is not possible to inject any type of "code" into a .mdl file at all. The only type of code allowed is XML, and that is only used to drive animations and/or control visibility of specific "parts" of the model.The only "custom variables" allowed in a .mdl are of the L:var,unit type, and those are (a) stored in plain ASCII text in the .mdl and (:( easily "discoverable" even without opening the .mdl to look!There are several freeware "gauges" that will display all custom L:vars while the sim is running, such as Doug Dawson's XML_ID gauge.

[Herbie63 0]

Bill, I thought about making the model (or major parts of it) invisible if a certain condition does not meet. That should be possible. Of course the aircraft would run on the machine, but what fun to fly something invisible...But if those custom parts can be read by opening the mdl (I did not know that, never tried...) you are right, it might be difficult if not impossible. What a pitty...

[n4gix 4,947]

>Bill, I thought about making the model (or major parts of it)>invisible if a certain condition does not meet. That should be>possible. Of course the aircraft would run on the machine, but>what fun to fly something invisible...Well, that is certainly possible (and has been done already). Although not "undecodeable," having several nonsense custom L:vars scattered throughout the model all having to be set to some specific sum of values makes it a lot more difficult, as the model then becomes tied to the C gauge system, which itself may be protected via a license system similar to that provided by Flight1 in their developer tools.