Fog Creek Software
Discussion Board




Preventing illegal use of my application. How?

I'm about to deploy a new application that generates management decision-support results, using a somewhat  complex algorithm that must be used only by licenced users. This algorithm is one of my client's main assets, and he has been developing and inproving it for many years.

So, I need to be sure that anyone that has not paid for the software will not be able to get results from the application, or at least make it very difficult.

I know that this has been always a problem for every developer and application vendor, and that there is no definitive solution, but in this case there is the oportunity to use any procedure, not matter how cumbersome to the user, to help avoid missuse.

Although the app is a VB6 .exe windows application, everything concerning the sensitive algorithm is encapsulated inside an activex .dll (VB6 dll).

I first thought of licensing the component using typical ActiveX licencing, but that does not prevent a licenced user from giving the application and licence key to someone else. Neither would do CD-Key protection.

I was thinking about some manual challenge-response process that would be performed at installation time. The installer would generate some hash of machine specific values, like machine name, IP address, operating system version, or anything that would help identify the specific installation. The user would have to copy and send that 'challenge' string to my customer. He would generate a response using the challenge message and some private key encryption and/or signing algorithm, and then will send the response to the user.

The application would not provide results until the response registration message was registered and validated with a public key. That would be needed in every installation, but that is not a problem since every licenced user does not need to install it on more than one machine (it is not a daily use application).

This is the only way that I have thought that might do the trick. But I'm not very sure about it.

I have no experience implementing such encryption and security features, and wanted to see if you had any recomentatios or resources on the subject.

Is there any good commercial solution ready that will work with VB ? Is ActiveX licencing useful for this ? Should I use windows CryptoAPI?

The range of operating systems I need to support is Win98/ME, 2000, XP.

Thank you very much for your time..

Sergio
Friday, May 16, 2003

You might try making that crucial function a SOAP over SSL operation. But you'll probably have to pass your working values by value (instead of by reference) (YMMV). Is this too much trouble? It might be, but it will protect it from illegal use for as long as you like.

Li-fan Chen
Friday, May 16, 2003

Sergio, your thinking is correct. The approach is to generate some identifier specific to the machine, then have the customer send that "serial number" to you, for which your company generates a key.

This approach doesn't inconvenience honest customers, and prevents easy transfer of licencing keys to other computers.

These schemes can of course be broken if someone is keen enough, but they're reasonable for commercial operation.


Friday, May 16, 2003

Try reading shareware authors messages boards on how they do this - and extra security they use if their app is on the Internet as a download (the moment these are released, they are under attack from crackers)

Some tips from this environment

- Don't put a clear text message in the binary saying something like "Thanks for entering the password" (or put dummy ones in, which aren't connected to the real one which doesn't appear in the binary)

- Spread the password check code all over your app and make the logic dependent on it.  If the code says something like if ( bPasswordEntered) { ...do this...}  the assembler it generates is easy to hack

- Don't write key check code in a language which is easy to disassemble like Java or C#.

- If you use C you might consider putting some dummy inline assembler which has the op code (but not the parameter bytes) for some instruction. Jump over this in your C code. It wil have no effect on the runtime, but might throw off their disassembler.

- Maybe make a whole bunch of possible passwords to test against, for each machine id. Only one of which is valid. The others are radically different (some can't be entered by accident), but don't have the same effect as the one true password.  This makes it harder for a hacker to figure out which one their key-generator will generate

- When making passwords or hashes for this, use logic that can not easily be reversed.  For example

// easy to reverse
// get X from user (a number they enter)
x++ ;
x=x*2;
x^=0xFFFF ;
if ( x == 0x1357 ) { AfxMessageBox( "Thank you entering password" ; }

looking at this, I know x needs to end up at 0x1357. Therefore hacker would work back thru the steps from the disassembly.
Before it was 0x1357 it was 0xECA8
Before it was 0xECA8 it was 0x7654
Before it was 0x7654 it was 0x7653

Irrevisible logic is one where it is real tough or time-consuming to work backwards, consider for example (this is stupid example, but illustrates the point) - it would take a lot of time to work out what you enter to end up with x == 0x1357

// Hard to reverse
// get X from user (a number they enter)
label0 :
if ( ( x & 0x000F ) > 8 ) goto label1;
if ( ( x & 0x00F0 ) > 0x80 ) goto label2;
if ( ( x & 0x0F00 ) > 0x800 ) goto label3;
if ( ( x & 0xF000 ) > 0x8000 ) goto label4;
goto done ;

label1: x^= 0x5A5A ; goto label0 ;
label2: x^= 0xA5A5 ; goto label0 ;
..etc..

done:
if ( x == 0x1357 ) { AfxMessageBox( "Thank you entering password" ; }


I do not have any experience of using commercial products (except dongles) for this type of thing.  The concern I have read on shareware boards, is these products could be under attack from more crackers... as compared to people who are only interested in your program would go after your specific scheme.

S. Tanna
Friday, May 16, 2003

Personally, I think trying to beat every possible attack is a misuse of resources, unless you're protecting missile intercept vectors or something.

For commercial software, the aim is to ensure customers know you expect payment, that they have a legal obligation to do this, and that they can't casually use the software without paying you.

People in companies know it's not worthwhile for them to misuse significant software. For small, low-priced applications, again, most people don't mind paying for something useful.


Saturday, May 17, 2003

Well, I sell shareware

Usually within 48 hours of releasing any new product on any big shareware site, some guy in China or Russia has released a crack or key code generator.  Fortunately these guys don't seem to test their stuff.

Using the above type of ideas - none of these cracks work.

That doesn't mean people don't try.  We get emails and calls every day, not to mention posts on our discussion board, from people who are trying them (we have methods to tell based on what they tell us), and this includes even big US fortune 500 companies, and even in one case a newspaper... In some cases they are blatant, they will openly admit to using a crack, sometimes saying something like "I was only trying it", or "people do it all the time"... and guess what, they often pay when they can't make the crack work.

Our sales TRIPLED when we tightened up the system (originally it was simple and was broken). Admittedly some of this was because the software got better at the same time (so more legit users), but undoubtedly some was due to the cracks not working any more.

S. Tanna
Saturday, May 17, 2003

I won't name any names, but based on some very bad first hand experience, I'd recommend being VERY cautious when looking at 3rd party solutions.  If you decide to go that way, do not assume that the 3rd party component is well tested and compatible with a variety of software and hardware configurations.  You will need to do a full battery of testing on a wide variety of machines yourself.  Make sure you spend plenty of time on the phone with tech support before you spend money because they might decide to ignore you afterwards.  Also, be willing to spend some time looking for related cracks on the net and trying to crack it yourself.  Some of the components available are VERY easy to crack.  Keep in mind that this is a critical component given that anything wrong with it might prevent customers who paid money for your product from using the product and they will get (justifiably) VERY upset about this.

If you decide to do it yourself, keep in mind that most of these systems (including, as far as I can tell, the one you described) come down to eventually to one point in the application where you do the test and check if it passed.  It's trivial for someone who wishes to crack your scheme, no matter how fancy your encrypted challenge & response mechanism is, to locate this point and simply NOP over it.  Your fancy encryption system never comes into play because someone changed the code to jump over it.  It can be more effective to sprinkle simple checks throughout the app rather than have one solid test in one location.

Somebody
Saturday, May 17, 2003

> It can be more effective to sprinkle simple checks throughout the app rather than have one solid test in one location.

I agree it.  Additionally I would make some vital part of your application dependent on the check occuring - i.e. so if the check is NOPed out, so essentially variables don't get initialized or something.

S. Tanna
Saturday, May 17, 2003

Incidentally, I'd strongly recommend setting up an automated key generator. It will make your clients much happier when they have to reformat a wayward system at 2am on a Sunday.

Philo

Philo
Saturday, May 17, 2003

Thank you very much to all of you.

Ok, so I will try to avoid using 3rd party solutions. That's for sure.

Unfortunately, I cannot setup server-side logic. As some of you suggested, I could have put the key functions as a remote service and that would've eliminated part of the risk.

I can't automate the key generation for the same reason. Maybe for a future version.

It's sad to say, but I wasn't given budget enough to go through all posible security risks. I might not take care of hacking/cracking scenarios this time, but would like to address at least the illegal user to user distribution problem.

Another more specific question:

What do you think is the more likely machine specific info that I can expect to succesfuly get in every machine? I just know that some of them have network acess and others don't  (some might not have even a lan adapter), so MAC address might not be the best choice.

Sergio
Saturday, May 17, 2003

If you can use the mac address, it's relatively painful to get at you need to use the SNMP dll to get at it. The winsock FAQ has more info on this. Personally I did using a mix of IPX/Netbios and the SNMP dll to make it work on all systems. Once upon a time you could get a GUID and the MAC address would be in it, however that changed with Win2K (I bugged it at the time) for privacy reasons. Personally I would be tempted use that as part of a key, for non networked system you could use the SID instead but this vulnerable to image copies of disks.
I would also suggest that you degrade the system somehow, possibly with a timer function i.e. it works but moans for a week , then goes readonly for a month, then dies. For most folks forcing them to have a NIC wouldn't be to big a hardship.

Peter Ibbotson
Saturday, May 17, 2003

S Tanna, thanks for that info, especially your own experiences as to the effectiveness of tightening up security.


Saturday, May 17, 2003

Here's the reality: you can't prevent anybody from hacking your code if you give them the code.

The sooner you accept the fact, that happier you'll be that you're not wasting ridiculous amounts of time on solutions that will be beaten. If you feel you absolutely MUST be up some line of defense, then you owe it to yourself to use a third party solution (unless, of course, your time is valueless).

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, May 17, 2003

If it is a commercial product, try using FlexLM

David Roper
Saturday, May 17, 2003

If you find out that you weren't given the budget to implement all the security you desire, then at least consider at least getting a metrics system in place so you can tell when legitimate or illegal use is taking place.

Ex: Always send the license key (original or copied from the net or generated by a generator) to a server (along with the unique system or network signature). If it's possible to crack your software so that it works without any use of license key registration.. have it request a patch (it could be a dummy patch) from your website after a random number of days or hours. This again reports more unreported cases (and might give you a chance to patch the software so that it fixes the vulnerability)

Give a report on how much the company is losing by not spending more on security. It might give you more budget should the company decide the commercial software has a future worth protecting.

Li-fan Chen
Saturday, May 17, 2003

My personal experience is the opposite

A few days spent on security, probably had more effect on product sales than years spent on improving the product. In other words, from coding time to revenue, it has had the by far the best ratio.

While obviously not unbreakable, it sets a higher bar for attempted crackers. It is the difference between locking your door, and merely putting a sign saying do not enter.

3rd party solutions are all well and good, but there could be the risk of somebody developing a universal hack for all products that use a particular third party solution.

S. Tanna
Saturday, May 17, 2003

Here are a few of my observations. I'm a non-programmer, but a software user.

1. Check out CollakeSoftware.com - you can add the .dll to the .exe and then compress the whole thing. That's an extra step for any hacker. I don't know if it's a big one, but it's there.

2. What about those programs that allow you to download the installer and then the installer goes out and downloads the components you want. I've seen this from Windows and Netscape and a few other places.

3. Keep changing the way you protect the software and releasing new dot versions. This way the hacker sites fall out of date on a regular basis. They'd have to bundle your app in with their hack to make it usable.

www.marktaw.com
Saturday, May 17, 2003

Hi Guys,

On a related note, has anyone here had any experience with Xheo.Licensing (http://www.xheo.com/Products/Licensing/)? It's a third-party .NET licensing component. The features list looks great. It supports activation, time-limiting, etc. I've read all of the reccomendations against FlexLM, so I've been keeping my eye out for a better option. This looks like it might be promising, but I haven't spent any time with it yet. Unless anyone has had any bad experiences with it I thiunk I might throw it into my next beta juist to check it out.

  --Josh

JWA
Saturday, May 17, 2003

Brad Wilson, I don't understand what you're saying when you say that providing "code" automatically exposes it to be being "hacked." That's quite obvious.

We're talking about providing executables. It's not accurate to describe that as "code." Code refers to source code. Is that what you meant?


Saturday, May 17, 2003

I should add too that I disagree with your claim. Registration systems prevent casual misuse, and good ones prevent even elaborate attacks.


Saturday, May 17, 2003

I believe SoftIce is the tool of choice for a lot of folks breaking these systems

I read a tutorial on some crack site, to learn how they did it, so I could make my systems harder to crack.

What softice does is allow them to break point the program while it is running and step thru the disassembly.

They then figure out the algorithm for how passwords are generated or patch the executable. Go back to my original ideas, and you'll see most of them are designed to stop (or make it tougher) for this kind of attack.


First look at naive example:

// easy to reverse
// get X from user (a number they enter)
x++ ;
x=x*2;
x^=0xFFFF ;
if ( x == 0x1357 ) { AfxMessageBox( "Thank you entering password" ; }

A cracker would look at the disassembly find the message string, work out how to trigger it (x==0x1357) amd then work back to figure out what X to enter.

or... a cracker would find a jump-not-equal instructions for x==0x1357 and patch it to a jump-equal.  THen any passwords except the real one, now works, by changing a single byte in youre executable.


Explaining my earlier suggestions

- Don't put a clear text message in the binary saying something like "Thanks for entering the password"

Why: They search the binary for this message, then work back through your program to see how it is triggered. 


- Spread the password check code all over your app and make the logic dependent on it.

Why: Otherwise they only have to patch a single byte/block of code.  By making your application logic dependent on it, you also mean that a less than careful patch would break the app.

- Don't write key check code in a language which is easy to disassemble like Java or C#.

Why: Obvious decompilers. For C or C++ they get back only x86 if they disassemble (which is more work to understand.especially without symbolic names).  Whereas for Java or C# they can get back something close to the original code including symbolic names, etc.

- If you use C you might consider putting some dummy inline assembler which has the op code (but not the parameter bytes) for some instruction. Jump over this in your C code. It will have no effect on the runtime, but might throw off their disassembler.

Why: It will throw off their disassembler. They have to start re-disassembling after each affected jump rather than disassemble the whole thing. You could make macros which did this which you pepper the relevant code with, and eat up tons of their time at trivial effort to you.

- Maybe make a whole bunch of possible passwords to test against, for each machine id. Only one of which is valid. The others are radically different (some can't be entered by accident), but don't have the same effect as the one true password.

Why: If they figure out the algorithm to generate passwords, it makes harder for them if they have figured out the algorithm for the one true password, or for one of the dummy passwords.  Also if they have to figure out a whole bunch of systems, and then work out which is correct, they are going to need a lot more time and effort to break it.

- When making passwords or hashes for this, use logic that can not easily be reversed. 

Why: Remember I said how they would try to work back from the part of code which says "Thanks for entering the password".  This makes it very hard to work backwards.

S. Tanna
Saturday, May 17, 2003

>> We're talking about providing executables. It's not accurate to describe that as "code." Code refers to source code. Is that what you meant? <<

Executables contain the program as machine code.  There are other programs (disassemblers) that'll convert this machine code into slightly more readable assembly code.  It is, without a doubt, accurate to describe an executable as code.  How else would the processor know what to do?  It's trivial for someone who knows what they're doing and who has the right tools to view the executable as code and to modify it to skip checks. 

Somebody
Saturday, May 17, 2003

Of course executables contain machine code, but that is not normally what is meant when people refer to "code." Anyway, this is a side issue. Sorry I raised it.


Sunday, May 18, 2003

One of the most tried tricks in our case is the “not-hands-on manager” type:

“We have discovered your product on the internet. Please send a pdf manual or help file to commence evaluation immediately, we are running out of time….”

=

“I am running your cracked product, help is nowhere to be found, send me some documentation please.”

WW
Sunday, May 18, 2003

How do you determine that they're not asking for the manual to legitimately evaluate the product? 

Somebody
Sunday, May 18, 2003

There is only one gauranteed way to prevent piracy: Don't release any software.

If that won't work for you, just accept that no matter how many thousands of dollars you spend on programmer wages while implementing your ultimate security system, someone will crack it in a weekend, if not sooner. All the excellent advice on how to prevent it taking 5 minutes rather than a weekend still won't keep your code from being broken.

If you must have a registration key to stop casual hackers (not a bad idea) then focus more on making it reliable and easy to use for your customers. Losing a sale to piracy is bad. Permanently driving a customer away from your business with a faulty protection system is worse.

andrew m
Sunday, May 18, 2003

If you really want to node-lock your software (let it only run on one machine) then rather than some sort of software solution, I'd suggest using a dongle.

A dongle is a little piece of hardware that stores your registration key and does the encryption for you. If the dongle is installed, the software runs. If it's not, the software won't run. Easy for you, and the user's got some flexibility, since if they want to move the software to another machine all they need to do is move the dongle.

The downsides are extra cost (you have to pay for the hardware), no download sales (since you need to ship hardware), and depending on the dongle hardware, potential driver issues (fear the parallel port dongle!).

And the final concern is that, of course, the protection WILL get broken, regardless of what you do or what you use.

Chris Tavares
Sunday, May 18, 2003

Dongle are probably the "best." That being said, I haven't seen a single security feature that couldn't be cracked eventually. Code is code. And it doesn't get more complicated then assembly which, while tedious, is not all that hard. All you need is soft ice and IDA. It's worth nothing that if you do due dilligence to make it reasonnably hard to do without circumventing the dongle/check, you've got DMCA protection on top of the stardard copyright law. Licenses are best enforced by lawyers.

Alex
Sunday, May 18, 2003

> If that won't work for you, just accept that no matter how many thousands of dollars you spend on programmer wages while implementing your ultimate security system, someone will crack it in a weekend ...

But protecting your work will more than pay for itself by the revenue you earn. For some reason you're comparing the cost of protection against the boolean of whether a scheme might be broken. It's not as simple as that.

Bank security systems could be broken if someone wanted to apply the resources. That doesn't stop them protecting their transfers.

Making applications good is all very well, but a protected good application will generate a lot more revenue than something anyone can rip off.

.
Sunday, May 18, 2003

All this talk about how to write your code to confound the crackers misses what I think are two important points.

First, I recognize that the crackers are smarter than I am.  They know assembler.  They have long experience in cracking programs.  They are determined, in a way only adolescent boys can be.  I cannot fight them head-on and win.

Second, once they have cracked my program, they have to make the crack available to other users somehow.  Now, all the crackers' "patch" programs I've ever seen check some combination of the size of the EXE file, its checksum, or its CRC.  If the EXE file doesn't match the version that they've cracked, the patch program doesn't apply its crack, obviously.  (Nothing damages a crackers reputation like someone applying a crack that not only doesn't work, but also corrupts the target program.)

So, the question to ask yourself is, how can I distribute copies of my software such that *every* copy has a unique size and CRC?  Once you've done that, cracking programs are useless - "all" you have to worry about now is whole cracked versions, shared registraion codes, etc.

Spaghetti Rustler
Monday, May 19, 2003

http://www.licenturion.com/

Check them out...

--
ee

eclectic_echidna
Monday, May 19, 2003

Not all patching programs do a full CRC check. Certainly, if it were clear that every version had a unique CRC, but it was easily to find and validate the block of code to change, they'd just do a partial CRC.

Brad Wilson (dotnetguy.techieswithcats.com)
Monday, May 19, 2003

> First, I recognize that the crackers are smarter than I am.  They know assembler.  They have long experience in cracking programs.  They are determined, in a way only adolescent boys can be.  I cannot fight them head-on and win.

I think this is way too pessimistic (sp?)

If you read how they do it, they nearly always use the same types of techniques, which can easily be frustrated

Even if you use plain C, you can write C code which generates horrific assembly

You can use psychology (head fakes) and mathematics to make their job way harder.  An example of a head fake is to make the cracker think their thing worked, but then reveal not a bit (days?) later.  If they are on a product line of cracking one program after another, they'll never even see it.

If some super cracker with unlimited time and resources comes after you, then you're probably stuffed.  But frankly, I don't believe most of the people who indulge in this type of activity are anywhere closed to this category.

As for lawyers, I think this should be the last resort rather than the first once, particularly if your software is inexpensive.  In any case, good luck pursuing a case against a person distributing your code from certain countries.

S. Tanna
Tuesday, May 20, 2003

All this dongle talk is making me blush...

Long Dongle Silver
Thursday, October 16, 2003

Hi!
    main e bohot socha kay tumhara masala kia hai mager mujhe kuch samajh nahi aayi kyoonke mujhe tumhara masala samajh main nahi aaya tha naa isliye main e socha k kyoon na ilm-e-jaffer, najoom yanay astrology , numerology,haziraat,roohaniyaat,moklaat se maloom kia jaaey to main maloom karnay k liye beth gaya to pata chala kay aap kay bhejay kay sirf 3 screw dhelay hain unko durust karo aap ka masla sahi ho jaaaaey ga
I hope that you understand

Master Josephthe thughoo
Thursday, July 22, 2004

*  Recent Topics

*  Fog Creek Home