View previous topic :: View next topic |
Author |
Message |
marty Professional Member
Joined: 10 May 2001 Posts: 789
|
Posted: Sat Dec 04, 2004 5:24 am Post subject: |
|
|
Dragonsphere wrote:
Quote: | Really the biggest issue as an Extension developer and prob. why most of us have virtually stopped writting Extensions is that there is no way to protect our regcodes and no way to protect the source code in the VDS Exe. |
I cant say how much I agree with this! Exactly why I stopped. |
|
Back to top |
|
|
vdsalchemist Admin Team
Joined: 23 Oct 2001 Posts: 1448 Location: Florida, USA
|
Posted: Sat Dec 04, 2004 3:02 pm Post subject: |
|
|
Jules,
I wish you would get rid of the TRACE command and the other debug functions in the Runtime DLL. They serve no purpose great enough to justify having our software hacked. _________________ Home of
Give VDS a new purpose!
|
|
Back to top |
|
|
Skit3000 Admin Team
Joined: 11 May 2002 Posts: 2166 Location: The Netherlands
|
Posted: Sat Dec 04, 2004 3:37 pm Post subject: |
|
|
DragonSphere, I don't think that only the trace command can be used to hack VDS programs. The problem is that VDS is an intepreter, and that to execute the code, the program first has to decode it back into the original state. And I think that's the biggest problem of an interpreter language... _________________ [ Add autocomplete functionality to your VDS IDE windows! ]
Voor Nederlandse beginners met VDS: bekijk ook eens deze tutorial! |
|
Back to top |
|
|
vdsalchemist Admin Team
Joined: 23 Oct 2001 Posts: 1448 Location: Florida, USA
|
Posted: Sun Dec 05, 2004 2:21 pm Post subject: |
|
|
Skit3000 wrote: | DragonSphere, I don't think that only the trace command can be used to hack VDS programs. The problem is that VDS is an intepreter, and that to execute the code, the program first has to decode it back into the original state. And I think that's the biggest problem of an interpreter language... |
Skit I know this already but it does not help that VDS provides commands and functions to do this. The Trace command and the API functions for debug offers very little use the the VDS programmer. I see no other reason to use them so why make it easier for someone to crack VDS? Many other programming languages do this. They provide tons of debugging tools and while it is sometimes nice to know what is going on inside of the compiler it does not outweigh the cost of software theft. _________________ Home of
Give VDS a new purpose!
|
|
Back to top |
|
|
FreezingFire Admin Team
Joined: 23 Jun 2002 Posts: 3508
|
Posted: Sun Dec 05, 2004 5:13 pm Post subject: |
|
|
Why don't we use an encryption such as blowfish or DES? These
encryption routines cannot be decrypted unless you have the correct key
and initialization vector. It baffles me why we would use some home-made
encryption method instead of one that we know works?
It would even be possible to use multiple encryption methods so nobody
knows what ones were used.
I think we need better source code security. _________________ FreezingFire
VDSWORLD.com
Site Admin Team |
|
Back to top |
|
|
PGWARE Web Host
Joined: 29 Dec 2001 Posts: 1562
|
Posted: Sun Dec 05, 2004 6:01 pm Post subject: |
|
|
You can use encryption but that doesnt matter because your passphrase and init vector would still need to be included within the code in order to decrypt. Basically giving away the secret to your encryption once someone locates the iv and passphrase within the code. Really its not that hard to do. |
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Mon Dec 06, 2004 10:16 am Post subject: |
|
|
marty wrote: | Dragonsphere wrote:
Quote: | Really the biggest issue as an Extension developer and prob. why most of us have virtually stopped writting Extensions is that there is no way to protect our regcodes and no way to protect the source code in the VDS Exe. |
I cant say how much I agree with this! Exactly why I stopped. |
That's not an issue for VDS to solve. It's up to you how you protect your intellectual property. The whole notion of providing a full version whose functionality is released by entering in a code is pretty stupid. Why not provide for download a version that only works with the IDE, and send the full version only to those who have paid?
But to be frank, if the majority of users of a VDS extension are people so dishonest they will use an illegal code, then perhaps it's time to forget continuing to develop VDS. There are cracks available for most successful software products and this does not affect their success. Developers constantly blame crackers for poor sales when the truth is the real problem is there either isn't a market for a product, or there is too much (or better) competition. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Mon Dec 06, 2004 10:23 am Post subject: |
|
|
dragonsphere wrote: | Jules,
I wish you would get rid of the TRACE command and the other debug functions in the Runtime DLL. They serve no purpose great enough to justify having our software hacked. |
This paranoia about hackers is absurd. It would be ridiculous to remove a useful debug tool because of this. Hackers are a tiny minority of people of absolutely no importance in the real world, and software developers waste far too much time and effort on trying to defeat them, which they would be better off spending on developing a better product.
In any case, the TRACE facility can only be invoked by compiling TRACE commands into the program, so it is up to the individual developer whether they want to leave this as an option that can be enabled in a distributed program or not. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Mon Dec 06, 2004 10:31 am Post subject: |
|
|
dragonsphere wrote: | Skit I know this already but it does not help that VDS provides commands and functions to do this. The Trace command and the API functions for debug offers very little use the the VDS programmer. I see no other reason to use them so why make it easier for someone to crack VDS? Many other programming languages do this. They provide tons of debugging tools and while it is sometimes nice to know what is going on inside of the compiler it does not outweigh the cost of software theft. |
The TRACE command can only be invoked by inserting commands into the script itself. Other entry points into the runtime are no use to anything except the VDS IDE.
No-one but a loser is going to spend time reverse engineering a program, so why worry about it. 99% of computer users are honest people, so if your program is going to make money, it will make money whether it can be cracked or not. ALL software can be cracked and disassembled if you put enough effort into it. Unless your program is making a million bucks a year, the amount you lose through this is not worth worrying about, and if it's making that much you might as well not be bothered about these losses anyway. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Mon Dec 06, 2004 10:38 am Post subject: |
|
|
FreezingFire wrote: | Why don't we use an encryption such as blowfish or DES? These
encryption routines cannot be decrypted unless you have the correct key
and initialization vector. It baffles me why we would use some home-made
encryption method instead of one that we know works?
It would even be possible to use multiple encryption methods so nobody
knows what ones were used.
I think we need better source code security. |
It would make no difference what encryption method was used, because the VDS runtime has to be able to decrypt the code before it can start executing it, therefore the decryption key has to be stored somewhere. If the VDS runtime can decrypt the script, then it is going to be possible for someone else to find out how to do it. The only secure way would be to send the key separately and have the user type in a code each time they run the program, which of course is ridiculous.
In my opinion, the time that was spent by CR developing a new encryption method for VDS 5, which delayed the release for a long time, was a complete waste of time. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Mon Dec 06, 2004 10:41 am Post subject: |
|
|
PGWARE wrote: | You can use encryption but that doesnt matter because your passphrase and init vector would still need to be included within the code in order to decrypt. Basically giving away the secret to your encryption once someone locates the iv and passphrase within the code. Really its not that hard to do. |
At last! A comment from someone who understands the issue and can view it in perspective. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
bbelcher Contributor
Joined: 30 Jul 2002 Posts: 172
|
Posted: Mon Dec 06, 2004 12:46 pm Post subject: |
|
|
I'm trying to follow this thread but it might be a little over it since I'm not a dll developer so forgive me in advance if I step all over it.
Couldn't you create a dll with the encrypted string in the dll and use the iv and passphrase as the reg code that is sent to the users. I know this would require a recompile of each dll sent to each reg user but maybe there could be a way to automate this.
Just a thought and if I'm off course please correct me. |
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Mon Dec 06, 2004 1:09 pm Post subject: |
|
|
What you have to bear in mind is that DLLs are distributed. I think your idea could result in a system where a user installs a VDS app developed by A, and another developed by B, both of which use an extension. When B's copy of the DLL overwrites A's, A's application stops working. You could work around this by installing the DLL in the same directory as the app, I suppose, but some people tinker with their PCs and might try tidying up their hard disk by deleting multiple copies.
So the DLLs have to be the same for everyone. But there is no reason why the DLL couldn't reqire a license file to be present in the home directory of the application that uses it. How that file is created and used would be entirely up to the DLL developer. It is not the role of VDS to provide built-in software protection mechanisms, anymore than Delphi, VB etc. do for developers using those languages. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
jules Professional Member
Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Mon Dec 06, 2004 1:45 pm Post subject: |
|
|
dragonsphere wrote: | At the very least I would like to see improvements in the VDS UNIT's world. I would like for them to have some kind of header information that can be read without me having to write a function to provide Version resource information. This is why I was asking for DLL abilities. |
I consider VDS DSUs to be like Delphi DCUs or the OBJ library files produced by traditional language compilers. None of those have the kind of capabilities you are suggesting. DSUs aren't intended to be distributed, so there is really no need for user-accessible version checking.
If someone created very large, but very versatile DSUs that were used in a large number of programs then that would be a reason for creating a DLL rather than compiling the DSU into every application. I got the impression, though, that most people wanted VDS to create integrated EXEs, which suggests that a feature which required more DLLs to be distributed along with the EXE would not be popular. _________________ The Tech Pro
www.tech-pro.net |
|
Back to top |
|
|
PGWARE Web Host
Joined: 29 Dec 2001 Posts: 1562
|
Posted: Mon Dec 06, 2004 4:58 pm Post subject: |
|
|
I can understand the need to protect dll's and dsu's but the reality is whatever you try to do to protect them there is always a way to decompile or find ways to bypass the protection. Sure you should provide some basic protection but spending too much time on protection is a waste of time in my opinion.
I suspect most users are worried about new features and additions into future versions of VDS rather the focusing directly on security/protection. That doesnt' mean not to focus on security at all but people (at least I am) are wanting actual real new functionality they can see and use for themselves rather than something that works behind the scenes within the software. |
|
Back to top |
|
|
|