February 18, 2011 at 6:09 am
Is there a real way how to prevent thiefs from stealing source code of stored procedures written in T-SQL with tools like Profiler, resp. various decryptors? I am not interested in "Shield" from the reasons I do not want get in, rather somethign more standard. CLR can be a way, but I am still able to see query and command text in debugger, profiler displays on recomplie text. Any way how to deal with it ??
February 18, 2011 at 6:17 am
This was removed by the editor as SPAM
February 18, 2011 at 6:20 am
Yes, of course, but this is very weak protection, dozens of decryption tools can be downloaded. I mean somenthing stronger like the "Shield" but preferably not 3rd party product.
February 18, 2011 at 6:28 am
Host the SQL Server and don't give them permissions to see the code.
If you give (or sell) the database and the client installs it on their server, there is not a thing you can do to stop them getting the code if they want. This type of thing is usually dealt with by licence agreements and the like.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 18, 2011 at 6:29 am
With Encryption isn't real encryption - it's very easily reversible.
There are no ways to truly hide every command you run against a SQL Server. SQL code is not source code in the traditional programming sense. It's not compiled in to a binary, it's an instruction that you're running against another company's product and that product allows admins to view statements that are being executed.
The only way to truly do it is to provide your product as a managed service hosted by your company and not allow the SQL Database to be deployed externally.
You can certainly obfuscate to a certain extent through moving code in the app layer and using CLR's (that have been obfuscated themselves), but in the DMV's and if looking in profiler, someone will always be able to see the code. You'll also make your application a lot less maintainable in the process.
February 18, 2011 at 6:46 am
CLR seems to be a way, nevertheless debugger still displays SQL commands. Any way to stop it ?
February 18, 2011 at 6:55 am
CLR is not a way. It's trivial to decompile CLR.
If you give your clients a database, you cannot stop them from reading the code in the stored procedures. Don't go and put things that are best done in T-SQL in CLR just to make it harder to read, you're hindering your development and the server performance.
If you absolutely must keep anyone from viewing the code, you have to host the database yourself.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 18, 2011 at 9:01 am
You are right, just CLR is NOT a way, but I can prepare CLR code obfuscated such a way that it would take ages to rewrite it into readable form, but still perfectly working and fast.
February 18, 2011 at 9:10 am
To what end?
You cripple any ability to maintain the code, you hinder performance and for what?
If the code must be completely confidential, host the SQL server. Otherwise put copyright and such in the licence agreement and use the legal system to punish offenders.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 18, 2011 at 9:16 am
Stopping thieves this way is not ideal, I do agree, but it is better than let them steal your work. Btw, deploy clr is one way process so maintenance aspects plays small role, but as for T-SQL you are right. Thanks for help with my consideration!
February 18, 2011 at 9:29 am
sdffdfad faadffad (2/18/2011)
Stopping thieves this way is not ideal, I do agree, but it is better than let them steal your work.
I'm sorry, but unless you're written the T-SQL equivalent of the 'Great American Novel', there's nothing in your code anyone wants to steal. In my experience most of the code vendors hide is so badly written I suspect they're hiding it out of shame.
It's not code that's the hard thing to write, it's the ideas behind it that are of value. If I see what your app is doing is doing (from the front end), I'm probably not going to have too much difficulty writing my own version of it if I really wanted to.
http://facility9.com/2010/04/08/encrypted-stored-procedures-and-their-effect-on-my-rug
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 18, 2011 at 10:42 am
sdffdfad faadffad (2/18/2011)
Stopping thieves this way is not ideal, I do agree, but it is better than let them steal your work. Btw, deploy clr is one way process so maintenance aspects plays small role, but as for T-SQL you are right. Thanks for help with my consideration!
I completely agree with Gail.
1) You'll make the solution less manageable/less performant
2) It will do nothing to prevent access to what you're running against SQL Server regardless of whether you obfuscate the .Net code
3) I've never encountered a single reference to a person/organisation ever stealing any SQL code
4) What value would it give to anyone? SQL is by definition simple and declarative. Unless someone also took all the application code and deployed the exact same solution it hardly saves a huge amount of time to market - Are you really writing anything groundbreaking that's never been attempted in SQL Server before??
If you're in any way bothered about it, the only way to do this is to host the database internally and provide the service rather than the software.
February 18, 2011 at 10:42 am
GilaMonster (2/18/2011)
I'm sorry, but unless you're written the T-SQL equivalent of the 'Great American Novel', there's nothing in your code anyone wants to steal. In my experience most of the code vendors hide is so badly written I suspect they're hiding it out of shame.
It is not like hiding the code for some thing like you said but there may be lot of reasons. The person who keeps his database at client side is not afraid of what the code is written (as you said badly or ugly manner).The client might be stealing our code and they develope with our code.Thats is only main reason why all the developers and managers are worried.Developers and other peoples have worked day and night for the project,and these thief’s will steal our code with in half hour or so that hurts more than what you have stated above.That is the only main reason much worried.
Thanks
Parthi
February 18, 2011 at 12:33 pm
parthi-1705 (2/18/2011)
The client might be stealing our code and they develope with our code.Thats is only main reason why all the developers and managers are worried.Developers and other peoples have worked day and night for the project,and these thief’s will steal our code with in half hour or so
Again, unless you have written something so revolutionary that it's striking awe and wonder into anyone reading it, no. People buy 3rd party products because it's cheaper and easier than developing the solution in-house. Not so they can take what you've done, reverse engineer it and use it themselves.
If your client is stealing your code (and really, that doesn't happen anywhere close to as often as some people seem to think), you have a legal recourse. Sue them, charge them with theft of intellectual property and, if they try to resell it, copyright violation.
If someone is determined to steal your code, nothing you can do in SQL will stop them. All that this obfuscation does is deter the merely curious.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 18, 2011 at 12:37 pm
HowardW (2/18/2011)
If you're in any way bothered about it, the only way to do this is to host the database internally and provide the service rather than the software.
And I've seen one case only where there was a legit need for that. A logistics company had implemented their entire supply chain/warehouse location optimisation code in SQL. It was some of the most complex SQL code I have ever seen, and it was the product of years of research and investigation. The code alone would have been worthless, the code combined with the weightings in the tables was their entire business.
Their solution - host the SQL server, allow their clients access only to the application.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 15 posts - 1 through 15 (of 40 total)
You must be logged in to reply to this topic. Login to reply