Protecting Proprietary SQL code
-
Unfortunately, competitors who want to figure out how your code works will disassemble, use profiler, etc., to do so. The key is to do as much as is reasonable to protect yourself within a certain cost level.
As Antares has already pointed out, competitors (or users) will go to the point of disassembling code if they have to. I know of a case where one company was posting that they were having problems with certain trace flags in one of the Microsoft news groups. The response from Microsoft was quick and to the point: how did you get that flag because it's undocumented and not intended for use outside of Microsoft? The answer: we disassembled SQL Server and found it. I don't know what happened from that point forward because the conversation left the newsgroup.
As far as detecting whether or not profiler is running, consider a couple of things... one, unless you require secure communications, they can sniff the network traffic. Two, there's quite a bit of info in syscacheobjects, as you yourself have hit upon, and this doesn't even take into consideration DBCC INPUTBUFFER or fn_getsql.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
Besides if you copyright your code and can prove they stole the code (not the concept) from you then you have legal grounds to get a nice chunk of change for their dubious act.
As for the folks who were stupid enough to state they disassembled something, dumb@$$. I come across lot's of things in SQL that are undocumented using just their built in tools and their isn't much you can't do as long as you can figure out how to interpret the output. Also, a lot of times you can find things out simply by looking at the exe and associated files in Notepad. Debates on wether that is or isn't technically disassembling all over the place.
And besides a competitor can always just write their own version by studing the functionality of yours and not really have to look at the code. In fact they may do just that and since they don't base on your source may hit on something better. That is just the nature of free market.
So unless you are going to wrap everything up in a room, throw away the key and pray no one else remotely has the same idea you just have to take the chance you have the better product and always improve it. If not then you never get anything out of it anyway.
-
quote:
And besides a competitor can always just write their own version by studing the functionality of yours and not really have to look at the code. In fact they may do just that and since they don't base on your source may hit on something better. That is just the nature of free market.
This is very true. I'm going to date myself, but here goes. When IBM was rolling forward with their Micro-Channel Architecture (MCA), they made sure to threaten everyone and his brother who might possibly reverse-engineer MCA. A couple of companies, after looking at the functionality, performed their own development efforts and documented every step of the of the process in case IBM decided to sue.
Ultimately MCA and PS/2 flopped, but this wasn't because of the technology but rather because of IBM's attempt to re-corner a runaway clone market. People were used to getting cheap clones and companies like Compaq kept progressing down the same road and didn't go to MCA. As a result, IBM was left standing all alone.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
You never have to crack or decrypt 'with encryption'.....
Just make sure you have the profiler on when the sproc is created.....
( hi hi )
-
More of a semantics issue... Using Profiler works if you can be in place prior to the install. However, if the install already occurred or the vendor did something like package a detached database with the objects already created, then Profiler no longer is an option.
The bottom line is still that you can only do so much. Protect as much as is reasonable based on your acceptable cost. Keep in mind that someone who is set to do so will get access to the code.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
Edited by - bkelley on 02/11/2003 09:39:21 AM
K. Brian Kelley
@kbriankelley -
All our code is decrypted on production servers.
-
How about writing your own .DLL and calling a set of extended stored procedures? Any of you guys have any comments on that?
-
You've made it harder to get at the code (though a disassembler still does it). The only requirement is you've got to have someone with the expertise in C++/VC++. Doable.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
I've thought about everyones input and have decided to take the following approach:
1)Obfuscate the SQL, removing all semantic clues including:
- Comments
- formating
- meaningful table, column, view names
- meaningful SP, UDF, Trigger names
- meaningful Variable and alias names
- rename above using nondeterministic alg
2)Add decoy SQL and Objects and returned data that is excercised in various calls at non critical times. With some decoy data returned to the client it would be difficult to understand whats going on without also decompileing and deobfuscating the middle tier.
4)Add Copyright to all
3)Encrypt all SPs
2)Distribute the server side code as a detached database (havn't tried this yet but i assume its possible to restore a detached db from an install process)
Having thought about this I think obfuscation with decoy code could offer the best protection in that it would require the most effort to access the conceptual content of the code.
This is my conclusion but will still value any futher feedback, specifically how this approach could be improved or if there are any easily exploitable holes in this approach that I may have overlooked....
-
I would also add remove any Foreign Key constraints and do checking in your code. This will make it harder to understand table interactions. Relationships are dead giveaways. But of course this means you have to ensure validation is properly done with care.
-
I tried to figure out how an app worked that encrypted SPs and encrypted the key fields in the tables, used numbers and letters for table names and column names, used no RI code, etc. It was a mess, but I was able to extend it to do what I needed it to becuase all I needed to know was what it was doing with the data, which is readily available in the log. What I didn't get from the log were selects, just inserts updates and deletes which is what I was looking for. The encrypted keys were easy to figure out.
-
quote:
I've thought about everyones input and have decided to take the following approach:>SNIP<
Um, please tell me what the name of your product will be or is so I can avoid it like the plague.
no matter how paranoid YOU are about having your code copied, there's a fair amount of reasons NOT to encrypt your sprocs/ sql code.
#1 is, you aren't perfect, and your product will probably fail somewhere in production, and someone is giong to be cursing the day you were born when they can't make a quick fix to the system to get it back up and running again. ONYX software does this with their SProcs, and it's a royal pain in the arse.
-
Firstly I'ld love to know just what is so sensitive about your SQL.
Secondly, to get an idea of just what you are up against, take a look at some of the SQL Server white papers at http://www.ngssoftware.com -- none of the papers relate directly to your problem, as far as I know, but what should stand out is:
1) Clever people with time on their hands crack things just for the intellectual challenge (or possibly for commercial benefit in this case)
2) They will often publish their findings, meaning less clever busy people can crack too.
I agree with the suggestions that you use non technical means to protect your rights, such as establishing copyright and drawing up contracts with all clients (don't forget the developers while you are at it).
-
Though this may seem a little harsh, it's not meant to be... rather it's the "What If?" and the "Uh-oh, we hit a wall" types of things that are running through my mind with this approach.
quote:
2)Add decoy SQL and Objects and returned data that is excercised in various calls at non critical times. With some decoy data returned to the client it would be difficult to understand whats going on without also decompileing and deobfuscating the middle tier.
If you do this, you're intentionally limiting the performance of your app, are you not? You're going to place additional load on the middle layer. You're going to create more network traffic than what is necessary. You're going to work the database engine harder than it needs to be. If you run into an issue with your app's performance for a client, how are you going to explain that they need to buy more hardware because you have these auxilary processes running that do nothing but obfuscate what you're trying to do? Especially after their DBA smugly points out that he's cracked your method (which will happen) so they could understand the implications. That's a question/answer you don't want to have to face.
Also, consider if you use non-sensical names, the people you punish most are your developers. The main reason we have variables, functions, and other programming constructs with rational names is because we've seen the other side and the grass isn't greener. I remember trying to track what B$ and D$ were and I'll be honest in saying I don't ever want to go back to those days. I would rather see CustomerName and ProductCategory than the previous approach.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley
@kbriankelley -
Interesting thread. Lets know throw too many rocks though. I agree that I don't think it can be done to the point of unbreakable. That said, perhaps there are situations where a good try is worthwhile. If this is one of them, let's offer every idea we can to try to make it better.
Some super duper business algorithm might be one reason, another might be in smaller vertical apps to reduce the chance that end users will try to tweak your app, driving up your support costs. I think this is one place where using Access as a back end might have some advantages over MSDE, since you can protect the entire db with a password. Nothing to stop someone from attaching to MSDE. Still, I hear you - nothing is unbreakable!
On the obfuscation, I think if you were to do this I'd look at using a tool similar to the ones published for .Net. Run it AFTER you've coded and tested rather than using a bunch of freaky object names while you code.
Andy
Viewing 15 posts - 16 through 30 (of 50 total)
You must be logged in to reply to this topic. Login to reply