Should I say Microsoft Idiot

G

georgepatotk

Contributor
Joined
Mar 1, 2004
Messages
432
Location
Malaysia
I think Microsoft really stupid in allowing their high-end .net language to be decompile-able. What a joke?

I had secure my VB6 application from decompiled in the olden day but, now in this new age, with this modern technology, my application is decompiled by my competitor. The source code is not a problem, but, the logic I had been written all this while.

They just decompile and with just the first few classes, they got the logic on how do I communicate with my Dongle, how do I calculate my Activation code. What the f**k.

seems few thread in extreme forums. Doesn't seem to have a real good solution/cure for this issue. Kinda fed up with this product now.

I am wondering why they didn't solve this before they launch their so called new .NET technology. This is really their fault in making our application so unsafe from those lovely hackers....
 
Decompilation of .Net code in most cases isn't really that big a deal anyway. In terms of securing software I've yet to see any other language that prevents people hacking / cracking the software regardless of how complex the resultant code is.

At least under .Net if you have given your application a strong name then changes to the .exe / .dll are detectable by the runtime and this will prevent execution of a compromised application.

If you are regarding the securing of the ideas or algorithms behind the application then one of the many obfuscators for .Net might be worth investigating - however you really need to decide if the effort is really justified. If your code is really that revolutionary then something like a patent may be a much more effective way of securing your IP.
 
Going to have to disagree with PD on this one.

You dont need ground breaking ideas or algorithms in order to justify wanting to keep your code to yourself. Coding takes Time. Anyone who has competitors probably shouldnt use .NET unless they're using an obfuscator, and a good one. So, anyone who wants to make a real program has to shell out hundreds or thousands of dollars for a good obfuscator.

Yes, any code can be decompiled or hacked.. but the issue has always been how hard it is to do. .NET is basically an open book for any fool who wants to edit your code to cut/paste/edit. You might as well hand out your source code directly if you're not obfuscating.

Patents and Copyrights? Ask the movie and music industry how much those are worth in a global economy connected by the internet :)
 
Patents and Copyrights? Ask the movie and music industry how much those are worth in a global economy connected by the internet
Click to expand...

This is what I meant. We should do protection on the beginning part (means coding part). Not on the distribution part.

So I think, obfuscator is my only choice.
And I really hate this. St***d Microsoft F**k*r.
 
Patents are effective

NeuralJack said:
Patents and Copyrights? Ask the movie and music industry how much those are worth in a global economy connected by the internet :)
Click to expand...

This is just plain wrong.

A patent and a copyright are two very different beasts, and drawing analogies with the entertainment industry is quite misleading. If the issue at hand were software piracy then I would agree software publishers do have to fight to prevent it. However, george is not concerned about theft of complete software but about theft of software design, which is not perpitrated by people sharing files but by developers reusing code and ideas.

Software patents, at least in the U.S., Canada, and most of Europe, are considered an effective means of preventing software design theft. The amount of people out there getting rich off the back of them says it all.

Design theft is nothing new, and the fact that it is slightly more convenient to disassemble a .Net assembly than a native one is a moot point. But hey, nobody is forcing you to use .Net, Java or any other technology.

:rolleyes:
 
Re: Patents are effective

Patents only prevent the big fish from stealing your algorithms from you.

What can you do against the small fish? You can't take them to court because its not economically viable, and even detecting that they have violated your patent takes time and effort to reverse engineer THEIR program.

Filing a patent for your algorithm is equivilent to handing it over for free to all the small fish in the world. The best way to keep the small fish from using your algorithm is to NOT patent it.

Its a catch-22.

If you are serious about protecting your intellectual property then don't impliment it in a managed language, dont patent it, and make sure that when you are doing business that the contract lets you rape them sour if you catch them breaking it. Contract law is a much better place to be.
 
Re: Patents are effective

MrPaul said:
But hey, nobody is forcing you to use .Net, Java or any other technology.
Click to expand...

Nope, I use .Net because I like it. I like it enough to compensate for bad MS decisions with obfuscation software (if i have to). It's a simple argument here.. why make it easier for people to disassemble your code than it already is? Why make piracy, code stealing, etc easier?

And why make us worry harder about whether or not we CAN actually enforce a patent or copyright in another country? Not that a small business would even try to do that.

If MS sold an obfuscater It'd all make sense to me..
 
Re: Patents are effective

Which bad decision is that?

Using an intermediate language is actualy a good thing from where I stand.

My latest project, which juggles 64-bit values, does so using the 64-bit general purpose registers on 64-bit machines, but will still run on 32-bit machines without a rebuild.

I cannot honestly say that there is a performance disadvantage either since several of my routines (the important ones, infact) are pushing ~2.5 instructions per clock cycle which is very near the impossible-to-reach limit of 3 per cycle on AMD64's

I believe that you are simply wishing that the .NET languages were something that they weren't intended to be. Yes, it sucks if you have been a VB programmer who is now left without an equivilent upgrade path that produces machine code binaries .. but Microsoft had never promised one to you.
 
Just an idea,

One programmer write an application for a bank. and the very first screen is for login. And on this login page, it has actually encrypt the username and password into different type of alien language before send over the network.

I am a hacker. And i wanna crack this system. What i have to do is try to have a copy of this application, maybe just the exe file. I could obtain it from my friend/s who is working in the bank. and i decompile it.

With the so called high technology like 128bit encryption and bla bla bla... i can break it with a decompiler on the exe file. And the usage of those encryption end up lose battle on this game easily. With just few hundred dollar, i can now get the encryption algorithm.. :P

no matter how good is an obfuscator, i still able to see the pattern of the program. try renaming one by one on the methods and variable. I can crack it.

This is actually a very serious issue. We are not aware of it because we still not yet facing the problem/s. And if microsoft don't do any enhancement on this, sure i can tell... one day, paper headline will be something like, "Country A being bom by Osama, with the usage of obfuscator in cracking the nuclear application, they obtain the president password by purchasing a thousand dollar obfuscator from internet". then only u will know the affect.
 
In this case the approach is wrong - you shouldn't be storing the encryption key on a client when requiring secure network communications or attempting to design your own encryption algorithms.

Given the above situation I would suggest using an established and secure mechanism like SSL to handle the encryption rather than writing my own anyway.
 
Still you don't get my point.
I am just trying to tell you that it is very DANGEROUS.
Not just for this encryption case.

understand? DANGEROUS???? :P
 
Perhaps I don't get your point but personally I really don't see this as being a big problem. For most business software the algorithms etc. aren't of such importance that decompiling them would be a show stopper - an obfuscator would probably be useful in such a situation if you did need to make it harder to decompile though.

If you are in the habit of giving your assemblies a strong name then this should help prevent people hacking the il itself as any changes to the file will prevent the CLR loading it, this could possible help reduce the number of cracks that simply patch a few bytes here and there to disable serial / dongle / whatever checks.

Ultimately it becomes a trade off, writing code in C / C++ would make it much harder (not impossible) to decompile but is a far more labour intensive approach to software development. .Net gives a much easier development process but there is the possibility of decompilation (again how serious this is depends on exactly what you are doing). The ability to mix languages may be of use - write the critical bits in C / C++ / personal language of choice and then call this functionality from the .Net application.

If decompilation is such a major problem then .Net is probably not the most suitable tool and should have been discounted early in the application design phase. Describing this as
very DANGEROUS
Click to expand...
just seems a bit of an overreaction given the fact that any software can be reverse engineered if it is deployed out to client machines regardless of language - the trick is to figure out how to avoid sensitive routines etc. being deployed in this manner.
 
I was pretty shocked when I first learned how easily decompiled IL was as well. I was outraged until I came to the realization that nobody really cares. The effort required to reverse engineer or decompile code, even IL, is sufficient to discourage almost everyone from bothering. Put in some simple security measures and you should be good to go in all but the most extreme situations (which are rarely if ever applicable).

I'd wager that the likelihood that a password or algorithm is compromised through simple human error is greater than someone taking the time to reverse engineer your software.
 
Encryption doesn't rely on obfuscation

georgepatotk said:
With the so called high technology like 128bit encryption and bla bla bla... i can break it with a decompiler on the exe file. And the usage of those encryption end up lose battle on this game easily. With just few hundred dollar, i can now get the encryption algorithm..
Click to expand...

So the hacker now has the encryption algorithm. This in itself is not a security risk, since any decent algorithm will involve keys of some sort. The algorithms and processes behind many trusted cryptographic standards are well documented. If the stength of the encryption depends at all upon the secrecy of the algorithm then the encryption is pretty poor from the outset.

Not to mention any hacker worth his or her salt is going to be able to reverse engineer a native application just as easily as a .Net assembly or Java class.

PlausiblyDamp pretty much nailed it with:

PlausiblyDamp said:
If decompilation is such a major problem then .Net is probably not the most suitable tool and should have been discounted early in the application design phase.
Click to expand...
 
Re: Encryption doesn't rely on obfuscation

So, with so much comments, the issue doesn't seems to be an issue to most of the people. But, for me, it is still very much important. No offence, we might be thinking differently and dealing with different things.

Originally Posted by PlausiblyDamp
If decompilation is such a major problem then .Net is probably not the most suitable tool and should have been discounted early in the application design phase.

Microsoft didn't mentioned this to me while in the introduction of this product in the launching hall. And I was not even know about this when i purchase it. And now, my whole application is developed.

Ok, forget it.... my fault anyway for trusting microsoft so much...
 
Re: Encryption doesn't rely on obfuscation

georgepatotk, I think we all understand your position and your frustration, but with something as important as security, whether it is a dongle that provides job security or a client's social security number, the most important thing you can possibly do is research. As you've come to find, a nifty security scheme is useless if you don't meticulously identify and eliminate holes in the security.

It's unfortunate, and a hard way to learn an important lesson, and I don't deny that Microsoft should have done more to make the potential problem appearent, but in the end the responsibility ultimately falls to you. We certainly can't blame you for venting, though.
 
Back
Top