February 18, 2011 at 5:45 pm
We currently have a performance issue with a 3rd party app.
The SQL code is not encrypted, the rest of the code mainly is stored in dll's.
I admitt I analyzed the vendors SQL code. But not to copy it nor to replace it with my own version. All I used it for is to get a deeper insight about why it's performing so poorly.
I told the vendor their code needs some serious improvement and provided a link here and there to support my arguments.
Assuming they would have used CLR's or other methods to obfuscate their code I still would have questioned the performance based on data volume, business rules and duration.
But steeling some vendors code? No way. If I would find a piece of code I really like to and I haven't come across before, I usually ask the vendor for permission to use it. It's been never denied as of today.
Unless your product is best in class, uses unique techniques, performs excellent and provides a high level of flexibility at low cost I'd either ask for the source code or go to a more open product.
As a side note: you wouldn't want me as your customer realizing your product has an issue and there's nothing I can do about it or nothing available to trace it down... I would have made sure your company is liable for any loss in our production due to a software failure...
February 21, 2011 at 7:13 am
This was removed by the editor as SPAM
February 22, 2011 at 8:01 am
Putting stuff in CLR isn't going to help anything. I can extract an assembly out of a database and look at in Reflector and see what its doing in seconds.
If you actually want to make it harder you could put the logic in an old school extended stored procedure written in unmanaged code(C or C++). That way they would actually have to disassemble the machine code to get at it.
February 22, 2011 at 8:29 am
You can use reflector and you will get only rubbish. There are ways how to deal with Reflector.
February 22, 2011 at 9:35 am
Still even with obfuscation its still CLR which is going to be easier to backwards engineer than disassembling native machine code.
February 22, 2011 at 9:44 am
Right, anything can be taken under reversal engineering, even native (push ebp - mov ebp, esp - mov eax, 10h -... I do know a bit about it :-)) but it takes a lot of time, and time is money. If the price of analyses exceed price of development then things are OK.
February 22, 2011 at 9:44 am
I am right ?
February 22, 2011 at 9:50 am
If you're just moving SQL code into a CLR procedure and executing it from there, you can obfuscate the .Net code until the cows come home, it will still be perfectly readable in a Profiler trace or in the cached plans in the DMV.
February 22, 2011 at 9:53 am
Yes, but at least key parts can be hidden in armored CLR.
February 22, 2011 at 10:00 am
Quite a few very experienced people have given exactly the same assesment of what you're planning to do and advised strongly against it.
Not much more I can say really other than that I'll keep my fingers crossed I never have to deal with your company's software as it will be a performance/maintenance nightmare.
February 22, 2011 at 10:07 am
And what would you advise to us? To serve to all the competitors de-facto source code on golden plate and share with them results of years of research and development ? What about the money spent on investments ? Or move to other business ? Definitely no! I do agree it is never ending game but we have to do it.
February 22, 2011 at 10:15 am
1 stored procedure with a mass of declared variables and GOTO statements, nobody would want to reverse engineer that :hehe:
Of all the apps out there that use SQL code, the few that I have seen that have been encrypted, were encrypted out of shame (as previously stated). The rest were not worth looking at unless it was to tell the vendor what to fix.
I have seen code of more value on this site, so dont see the point. All the real logic (stuff worth stealing) should be contained in the application or the data IN the DB
February 22, 2011 at 10:19 am
Yes. I think that SQL server should be used for fast and consistent data access but final processing is job for CLR.
February 22, 2011 at 10:34 am
You seem content on using CLR (like you were at the start of the thread), so let us know how it goes.
My 5 cents: If you're using CLR to hide code...and for what I can decipher no other reason: I wouldn't buy your product.
How will you answer the question from the DBA "why does it need CLR?"
Carlton.
February 22, 2011 at 10:40 am
DBAs have very little to do with the buy or not to buy decisions in the real world. Competitive design and price and - that's what's all about.
Viewing 15 posts - 16 through 30 (of 40 total)
You must be logged in to reply to this topic. Login to reply