HOME | DD

Description
body div#devskin0 hr { }

How to Protect your code:

When you begin your programming projects theft is probably one of the lasts things you think of before you click compile, but unfortunately that is simply the reality of it. Programming theft happens so frequently because it is so very easy to steal someone else's work and claim it as your own. The shocking truth is that even large companies like Apple, Google, Microsoft and android are known to steal code from small time programmers. If you create something new and unique it is likely that your work will be stolen from you.

Here is some of the ways you can prevent your code from being stolen.

1:
Obfuscation, is probably the first thing you should do to newly compiled code. It jams the programming language of your code so that only a computer can read it, making it very tedious work for a code thief to sift though your work and find out what does what. By obscuring your code what you really do is replace the standard library of words used to program, with a new library of words that means nothing to a programmer.

As an example, System.out.println("hello world"); would become w.d.f("hello world"); . This means that while it is possible for a programmer to read your work, the process becomes very drawn out as they have to re-establish what each line of code means. The weakness of this method is that your program still needs to be understood by the computer and somewhere in ram your un-obfuscated work is being read.

Personally I use encrypted words as my library of words I use to obscure my code. The reason for this is because encryption uses many symbols that a computer isn't meant to display to the user, meaning when my code is opened it often results in the hackers computer crashing

2:
End User Licence Agreement, is one of the most important ways to protect your code. Not only will it protect you from illegal distribution of your source code, but it will protect your from lawsuits. It is an agreement, meaning it is a digital hand shake that global and international laws will hold your end user to. Just like a written agreement the end user can not agree to never steal your work and then sell illegal copies down the road. By selling your work and breaking your agreement they lose any and all right to your program and as such you can by all means take way your program from them. However the main flaw in this agreement is in court the opposition can claim that they never saw your agreement or couldn't understand it. Which is why when you install apps you usually get stuck behind that licence agreement page that forces you to scroll down and click 'I have read and understand the agreement'. You can do the same or add a splash screen that pops up with your app saying, 'By using this program, you agree to be bound by the terms and conditions set forth in the end user license agreement found in the program and in the file Licence.txt.' Which will protect you no matter what!

3:
Copy and Paste prevention, From within your code you can do many different things to prevent hacking. A time stamp check inside your program makes sure that the currently running program was created between a preset date. This can further be reinforced by adding a region of creation check, which would check in which time zone was this program created. If it doesn't match what the program says it should, your code won't run.

4:
Hex editor block, When your program runs it is un-obscured into virtual memory. This means that if someone adds a debugger to your program before it can run, the debugger can capture what the unobscured words of your code are. Now this might seem like a serious flaw, making obscuring perfectly useless, but it is fortunately very easy to prevent hex debuggers. From within your code you can tell your program to run itself once more and then close the currently running version of itself. This means any attached debuggers close with the first run and the new run is free from any attachments, because debuggers require time to harvest your code you can rest assured that they won't get very far

5:
Encryption, Though many programs do not allow you to encrypt your code directly that doesn't stop you from encrypting libraries outside your code. By including a file outside your code, vital to your programs successful execution, you limit the hacker's ability to steal your work. However! There is one serious flaw with this method, a hacker can see inside your code and obtain your decryption key!!! HA, but that is where the hacker is wrong! If you use your programs own hashcode, altered slightly inside your program, you prevent them from seeing inside your code without losing the very key they need to decrypt your library file. Meaning there is no way for them to decrypt the library file vital for your programs execution, and no way your program will work without it.

Just remember to mark your program read only as most modern computers move around the hard drive placement of files(the index), this means that the hash code of your program will change resulting in it no longer working.

Also remember to convert your encrypted file directly into virtual memory instead of decrypting it back on your hard drive(though this doesn't help the hacker gain access to your code it leaves your library vulnerable to theft)

6:
Repercussions, Though it is illegal to 'blow up' hackers computers you have got to add repercussions to any attempt to hack your code, and there is a legal way to do so...It is call, reasonable deniability Many large companies do just that. You will often find that a program will say something on the lines of, 'Due to problems unforeseeable by Microsoft, Windows has stopped work. This is by no fault of Microsoft but due to a conflict from an outside source' This right before your Windows computer crashes and never works again.

Basically what you want to do is exercise your right to protect your program without cheating or robbing your clients/customers. Whilst you can't out right say you are crashing your program on purpose to defend it against a hack attempt, you can say that 'something' unexpected has happened and as a result your program has been damaged irreparably. It is illegal to crash your program of course, being that it can be used to exploit the end user(like microsoft does all the time), but if you can claim that 'something' unforseeable has damaged your program then it is ok. That something of course being a hack attempt but you really don't want to throw around accusations when a court case is the result.

Personally what I do is I say that the external library has been damaged, and that my program can not run without it. Being that my library is just a text file the fault then falls on the software in charge of the text file and not me. Meaning that I can not be sued for producing a program which stopped working due to a change in software or hardware.

7:
Legal statement, A copyright and a disclaimer is very important to anyone who plans on selling or distributing their work. The disclaimer warrants you of any damages or lose to your clients, and the copyright gives you authority to defend your work. The reason this is so low down on my list is because it is virtually useless against a large corporation or country who decides they like your code and simply must have it. The fact is not every country respects the laws of copyright and corporations can win any court case if they have the money to fight against you. They can even claim that by defending your code you are breaking the law, twisting reality to do their bidding. There have been many such cases where corporations have claimed that by selling your software you should give up your source code unprotected to them, regardless of how ridiculous that sounds. Which is a very important aspect to remember to add to your copyright

'By distributing this program the author(this is you) has not sold there right to keep there source code secret. The author retains their right to their source code and only provides a limited right to their clients to use the product, the client has no right therefore to read or distribute the Authors source code in any way shape or form'

8:
Run your code server side, A server side code means that the user has no access to your source code and all the processing happens on the internet/sever. Giving users full functionality without any of the code. The main problem with this is that you need to have a server, which is expensive, and you need to have a program that generates you more money than the monthly fee running from the server. This protects your code from basic attacks but it doesn't 100% insure safety since the server can always be hacked. The main benefit is that you no longer need to distribute your code and the speed of your code can only be limited by the servers speed, not clients computers.

...

This concludes 'How to protect your code'. Please if there is anything you would like to add or anything I got wrong or needs further explaining, feel free to contribute.

:D (Big Grin) — Description
body div#devskin0 hr { }

How to Protect your code:

When you begin your programming projects theft is probably one of the lasts things you think of before you click compile, but unfortunately that is simply the reality of it. Programming theft happens so frequently because it is so very easy to steal someone else's work and claim it as your own. The shocking truth is that even large companies like Apple, Google, Microsoft and android are known to steal code from small time programmers. If you create something new and unique it is likely that your work will be stolen from you.

Here is some of the ways you can prevent your code from being stolen.

1:
Obfuscation, is probably the first thing you should do to newly compiled code. It jams the programming language of your code so that only a computer can read it, making it very tedious work for a code thief to sift though your work and find out what does what. By obscuring your code what you really do is replace the standard library of words used to program, with a new library of words that means nothing to a programmer.

As an example, System.out.println("hello world"); would become w.d.f("hello world"); . This means that while it is possible for a programmer to read your work, the process becomes very drawn out as they have to re-establish what each line of code means. The weakness of this method is that your program still needs to be understood by the computer and somewhere in ram your un-obfuscated work is being read.

Personally I use encrypted words as my library of words I use to obscure my code. The reason for this is because encryption uses many symbols that a computer isn't meant to display to the user, meaning when my code is opened it often results in the hackers computer crashing

2:
End User Licence Agreement, is one of the most important ways to protect your code. Not only will it protect you from illegal distribution of your source code, but it will protect your from lawsuits. It is an agreement, meaning it is a digital hand shake that global and international laws will hold your end user to. Just like a written agreement the end user can not agree to never steal your work and then sell illegal copies down the road. By selling your work and breaking your agreement they lose any and all right to your program and as such you can by all means take way your program from them. However the main flaw in this agreement is in court the opposition can claim that they never saw your agreement or couldn't understand it. Which is why when you install apps you usually get stuck behind that licence agreement page that forces you to scroll down and click 'I have read and understand the agreement'. You can do the same or add a splash screen that pops up with your app saying, 'By using this program, you agree to be bound by the terms and conditions set forth in the end user license agreement found in the program and in the file Licence.txt.' Which will protect you no matter what!

3:
Copy and Paste prevention, From within your code you can do many different things to prevent hacking. A time stamp check inside your program makes sure that the currently running program was created between a preset date. This can further be reinforced by adding a region of creation check, which would check in which time zone was this program created. If it doesn't match what the program says it should, your code won't run.

4:
Hex editor block, When your program runs it is un-obscured into virtual memory. This means that if someone adds a debugger to your program before it can run, the debugger can capture what the unobscured words of your code are. Now this might seem like a serious flaw, making obscuring perfectly useless, but it is fortunately very easy to prevent hex debuggers. From within your code you can tell your program to run itself once more and then close the currently running version of itself. This means any attached debuggers close with the first run and the new run is free from any attachments, because debuggers require time to harvest your code you can rest assured that they won't get very far

5:
Encryption, Though many programs do not allow you to encrypt your code directly that doesn't stop you from encrypting libraries outside your code. By including a file outside your code, vital to your programs successful execution, you limit the hacker's ability to steal your work. However! There is one serious flaw with this method, a hacker can see inside your code and obtain your decryption key!!! HA, but that is where the hacker is wrong! If you use your programs own hashcode, altered slightly inside your program, you prevent them from seeing inside your code without losing the very key they need to decrypt your library file. Meaning there is no way for them to decrypt the library file vital for your programs execution, and no way your program will work without it.

Just remember to mark your program read only as most modern computers move around the hard drive placement of files(the index), this means that the hash code of your program will change resulting in it no longer working.

Also remember to convert your encrypted file directly into virtual memory instead of decrypting it back on your hard drive(though this doesn't help the hacker gain access to your code it leaves your library vulnerable to theft)

6:
Repercussions, Though it is illegal to 'blow up' hackers computers you have got to add repercussions to any attempt to hack your code, and there is a legal way to do so...It is call, reasonable deniability Many large companies do just that. You will often find that a program will say something on the lines of, 'Due to problems unforeseeable by Microsoft, Windows has stopped work. This is by no fault of Microsoft but due to a conflict from an outside source' This right before your Windows computer crashes and never works again.

Basically what you want to do is exercise your right to protect your program without cheating or robbing your clients/customers. Whilst you can't out right say you are crashing your program on purpose to defend it against a hack attempt, you can say that 'something' unexpected has happened and as a result your program has been damaged irreparably. It is illegal to crash your program of course, being that it can be used to exploit the end user(like microsoft does all the time), but if you can claim that 'something' unforseeable has damaged your program then it is ok. That something of course being a hack attempt but you really don't want to throw around accusations when a court case is the result.

Personally what I do is I say that the external library has been damaged, and that my program can not run without it. Being that my library is just a text file the fault then falls on the software in charge of the text file and not me. Meaning that I can not be sued for producing a program which stopped working due to a change in software or hardware.

7:
Legal statement, A copyright and a disclaimer is very important to anyone who plans on selling or distributing their work. The disclaimer warrants you of any damages or lose to your clients, and the copyright gives you authority to defend your work. The reason this is so low down on my list is because it is virtually useless against a large corporation or country who decides they like your code and simply must have it. The fact is not every country respects the laws of copyright and corporations can win any court case if they have the money to fight against you. They can even claim that by defending your code you are breaking the law, twisting reality to do their bidding. There have been many such cases where corporations have claimed that by selling your software you should give up your source code unprotected to them, regardless of how ridiculous that sounds. Which is a very important aspect to remember to add to your copyright

'By distributing this program the author(this is you) has not sold there right to keep there source code secret. The author retains their right to their source code and only provides a limited right to their clients to use the product, the client has no right therefore to read or distribute the Authors source code in any way shape or form'

8:
Run your code server side, A server side code means that the user has no access to your source code and all the processing happens on the internet/sever. Giving users full functionality without any of the code. The main problem with this is that you need to have a server, which is expensive, and you need to have a program that generates you more money than the monthly fee running from the server. This protects your code from basic attacks but it doesn't 100% insure safety since the server can always be hacked. The main benefit is that you no longer need to distribute your code and the speed of your code can only be limited by the servers speed, not clients computers.

...

This concludes 'How to protect your code'. Please if there is anything you would like to add or anything I got wrong or needs further explaining, feel free to contribute.