|
I have downloaded a program that decompiles any .NET program to C# or VB.NET source code. For this reason, I stop using .NET; Microsoft does not have any solution to solve the problem yet, and I don't they will.
What do you think?
eric feng
|
|
|
|
|
What program is it? sounds cool.
wWw.KruncherInc.cOm
|
|
|
|
|
Have you ever heard about strong keys and obfuscating? Probably you should learn about .NET itself first, how high-level the IL code is in those assemblies and why it is possible to convert an IL source to C# source.
Obfuscating is easy and nobody will ever be able to disassemble the result.
RGab
|
|
|
|
|
I created one support instance with Microsoft support to discuss about this. they also recommand Dotfuscator. but did you ever try it? can you solve the following problem:
class MyClass
{
public string name
{ get { return "abcd"; } }
}
listbox.DisplayMember = "name";
MyClass a = new MyClass();
listbox.Items.Add(a);
after Dotfuscator scrambles the code, you won't get "abcd" in your list box.
you might need to buy a full version dotfuscator, then what about the stack trace?
eric feng
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
