|
Well, it seems then reflection does not work as they should after obfuscating, although it should but it makes a lot of sense the reflection won't work on a class that has all of its properties and members' names scrambled.
I haven't tried myself, but I tried to disassemble a .NET assembly after obfuscated and the result was pretty impressive (I had no chance).
RGab
|
|
|
|
|
Strong keys don't prevent reverse engineering.
Obfuscating is the way to go but does not mean someone won't be able to reverse engineer the code. Obfuscating is supposed to just make it unbelievablly difficuly to understand, hopefully to the point where it looks like the equivalent of assembly code from a decompiled C++ program. And also people that want to truely decompile a program will find a way. It happens in natively compiled apps written in C and C++. All of the hacking/cracking tools can atest to that. Invest in a semi-decent Obfuscator and you should be safe from wondering kiddie eyes.
If there is a specific formula or business logic that absolutely has to be protected to the best of your abilities you could always write a COM object and utilize that object in your .NET application.
Keep in mind Java has the same afflicition and it hasn't stopped that environment.
I suppose you could also look at it from a different perspective. If someone does blatantly copy your code you will be able to tell by reverse engineering their code also.
I hope I never have to go back to C++ again. Environments like .NET and Java have allowed me to focus more on Architecture and design instead of worring about using strncpy instead of strcpy (Yes STL takes care of this, but the statement hopefully serves it's purpose.  I can't wait until I'm switching out crystals to boost warp engines.. oh yeah!
-
Drew
|
|
|
|
|
i think they should include obfuscation as part of .net (at least at a basic level!). Although i don't really see what the big problem is with.. is the source code itself valuable or is it the developer's knowledge of that code?
|
|
|
|
|
A basic version of Dotfuscator is included with VS.Net 2003, and I had heard (although I don't know for certain) that MS was including their own obfuscator in VS 2005 instead of using a 3rd-party tool.
Also, you may want to go to www.aspose.com and have a look at their obfuscator. It's free (unsupported except through their forums), but supposedly has more features than the free version of Dotfuscator. (I just recently ran across this, and haven't had a chance to evaluate its obfuscation yet. But it's supposed to include features that you have to pay for with Dotfuscator.)
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM user WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
|
Thanks, I'll take a look.
|
|
|
|
|
Ashley van Gerven wrote:
is the source code itself valuable or is it the developer's knowledge of that code?
If your software is not a commercial product, if your software does not have any encryption, if your software does not connect to a server that require authority. Yes, you can open your source code.
eric feng
www.infospec.com
|
|
|
|
|
Let me disagree with you. The most valuable part of
software is no it's source code, may be, it is less valuable part. The most important is support, quick bug fixes, small reaction time to changing market requirements. Lots of large financial and baknking systems are build on client-server architecture? where server side is implemented as stored procedures - source code is effectively open. All business logic is open source! I can't remember any time when it is more easy to adapt a piece of code from large and unknown product than write my own. In industrial systems the ability of decompiling and obtaining source code is not problem at all.
|
|
|
|
|
I agree software itself is not a secret, but how do you hide the secrets (etc: checking serial #, encrypting sensititive data) in the software?
what about one day your client show you a piece of your source code to challenge you?
Can you name 1 or 2 commercial software written by managed code? I am very interested.
eric feng
|
|
|
|
|
eric feng wrote:
Can you name 1 or 2 commercial software written by managed code? I am very interested.
Eric, I too have been waiting for large companies to release .NET windows apps. Well just yesterday i found that ATI[^] seem to have done so with their Catalyst application. It's a pretty major app by the looks of it.
However in line with this thread, i would imagine that they do obfuscate their assemblies.
|
|
|
|
|
Thanks Ashley, I will look into it.
eric feng
|
|
|
|
|
eric feng wrote:
encrypting sensititive data
Encryption which depends on the attacker not knowing the algorithm is also known as "security by obscurity". All the more reasons to open the code, so that someone may point out that it is totally useless.
--
Weiter, weiter, ins verderben.
Wir müssen leben bis wir sterben.
I blog too now[^]
|
|
|
|
|
Wow someone that knows security (This is not sarcastic.) It's amazing how many people think security by obscurity is good enough. For example all the algorithms for AES, DES3, RC4 are known yet it is very difficult to crack cipher text.
-
Drew
|
|
|
|
|
afinnell wrote:
Wow someone that knows security
My former professor would have me skinned if I didn't know basic cryptography. 
afinnell wrote:
For example all the algorithms for AES, DES3, RC4 are known yet it is very difficult to crack cipher text
Indeed. Add nonces to your protocols, and it'll make the cryptologist's job even harder as they can't make "educated guesses" about the content. Even better: never reuse symmetric keys (session keys), and protect key exchanges using very large asymmetric keys (time limited keys).
"Security by obscurity" solutions are often the invention of fools who decided that spending the extra 20 hours on research was a waste of time. Little do they understand that those 20 hours may come back and haunt them later for a lot longer period of time...
--
Weiter, weiter, ins verderben.
Wir müssen leben bis wir sterben.
I blog too now[^]
|
|
|
|
|
Well most of what you describe is the algorithm's used in SSL/TLS. For example creating a random master key to exchange the sym keys for the current session.
-
Drew
|
|
|
|
|
What came in mind first: JBuilder, IntelliJ IDEA. Theese are Java applications, but Java can be decompiled as easily, as .NET managed code.
|
|
|
|
|
authorization user/pass and configuration data shouldn't be in the source code in the first place, but in a separate data store. This data store should be encrypted if the information is sensitive.
However I agree with your commercial product comment - you don't want your competition getting ideas from your code. However I doubt many companies with the long term in mind would risk decompiling copyrighted software and using any part of it in their products.
I have to agree with the other comment above (by zlossik) - in line with my original comment - that the *support* is the valuable part, and the original developers are in the best position to do this.
|
|
|
|
|
Ashley van Gerven wrote:
authorization user/pass and configuration data shouldn't be in the source code in the first place, but in a separate data store. This data store should be encrypted if the information is sensitive.
even the user/password not in the source code, the way you retreive it, I can doing the exact way to get them by going through part of your source code. also I can create a small project directly call to your fuction to get them. am I right?
eric feng
|
|
|
|
|
yes you're right... you could use the source to find out how to retrieve the sensitive data.
|
|
|
|
|
For a determined person it's not very hard to explore the compiled code too (lots of keygens and cracks around the net). Hiding such things behind assembler code complexity and relying on it does't solve security problems. It seems to me we shouln choose another way to build truly secure products
|
|
|
|
|
I agree with you, there is no true secure method to block the determined person for now.
but, in .net windows application ANYONE can easily crack the security or keygen in few hours or even less.
eric feng
|
|
|
|
|
No objections. I don't want to say that it's not a problem, it is a problem and we should take it into account when making decisions. My main point was that any decisions must be carefully thought out, and my opinion is that ease of decompiling shouldn't be the only reason for not using managed code.
|
|
|
|
|
It's not only user/password or hardcoded data. Whenever a customer wants the source, he can have it, but for 5-10 times bigger charge. Most if not all of the bigger tech companies have nothing better to do than to analyse your work and use it, so I am out of business after the first project, no matter how good or fast development and support were. I once even had to give support for my source that was used in a different project (which I discoverd later).
Source code means the knowledge how to handle something, so if someone wants it, he has to pay me for. Sorry for that, but I been screwed more than once.
I'm happy for codeproject and all the good stuff in here, I use a lot that and have no problem of sharing information with you. I only dislike people that (ab)use you as a consultant and pay you as a programmer.
|
|
|
|
|
DiWa wrote:
Source code means the knowledge how to handle something
I have to agree with that; if your code gives your competition a quick answer to something that took you any length of time, then you lose any edge you might have had. Then rebuilding your idea in new code could hardly be linked back..
DiWa wrote:
use you as a consultant and pay you as a programmer
funny you should mention that... kindof finding myself in this situation these days 
|
|
|
|
|
eric feng wrote:
Anyone worry about your source code?
You mean my company's source code 
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Yes. Give me your EXE or DLL, I give you back with your source code in 2 minutes.
eric feng
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
