views:

161

answers:

6

There are loads of profilers and static code analyzers out there for C# assemblies.

Just wonder if there are any methods to prevent being analyzed, because it does make me feel a bit nervous when being stripped.

I have searched all over the Internet and stackoverflow. There seems none for my wonder.

What I've got are only some even more scary titles like these (sorry, new user can't post hyper links, please google them):

"Assembly Manipulation and C#/VB.NET Code Injection"

"How To Inject a Managed .NET Assembly (DLL) Into Another Process"

Is it just me being too worried or what?

BTW, with C#, we are building a new winform client for a bank's customers to do online transactions. Should we not do this in the winform way or should we use some other language like Delphi, C++? Currently we have a winform client built with C++ Builder.

+3  A: 

If by analyzed you mean someone decompiling the code and looking at it, then the Dotfucstor that ships with VS Pro and above is a simple (free) tool to help here. There is a fuller functionality (but paid for) version that can do more.

To prevent someone tampering with your deployed assmebliles, use Strong Names.

Colin Desmond
Agreed obfuscation is the way to go. But understand no solution will be full proof.
Matthew Vines
You mean "fool proof". :)By staying in .NET managed code you can always be easily decompiled. Obfuscation is limited, to my knowledge, manipulating the strings that represent tokens (like calling every class, member, and variable "foo" or a non-ASCII character). This drastically hinders readability but it is by no means security. Mostly just clarifying .NET obfuscation rather than arguing.
Colin Burnett
For example, can hackers switch the account being transferred to (by injecting codes or changing a string value when the application is running)?
bo
Yes bo, they can do anything the user has permission to do. That's not a .NET thing either, any language is vulnerable once an attacker has control of the users system (not hard to do in most cases). An obfuscator will prevent casual inspection of the code, but it won't stop a determined attacker. It's probably a good idea to use one just on principle, but don't be fooled into thinking it's a solution.
Orclev
+3  A: 

Where there's a will, there's a way, whether it's managed code or native assembly. The key is to keep the important information on the SERVER end and maintain control of that.

lc
+2  A: 

Just about any application can be "analysed and injected". Some more than others. That's why you NEVER TRUST USER INPUT. You fully validate your user's requests on the server end, making sure you're not vulnerable to buffer overruns, sql injection and other attack vectors.

Obfuscators can make .NET assemblies harder to analyze. Using a secure key to strong-name your assemblies can make it much harder to alter your code. But, like everything else in the digital world, somebody can exploit a vulnerability and get around whatever safeguards you put in place.

Will
+2  A: 

The first thing you need to decide against what you are trying to protect? Obfuscators are useful only to protect "secret sauce" algorithms, but the attacker can simply extract the code and use it as black-box. In 99% of cases obfuscators are waste of money. If the attacker has physical access there is not much you can do.

felixg
+2  A: 

If the end user is running with administrative privileges then they will be able to attach a debugger, and modify your code, including target account details. My local friendly bank has given me a chip & pin reader that I have to enter the last n digits of the target account, which it hashes/encrypts with my bank card's Chip; I then enter the code from the device into the bank's web application which can checked at the bank's end as well. This mitigates "man in the middle" type attacks...

Rowland Shaw
+1  A: 

Security is only possible on systems you physically control access to, and even then not guaranteed, merely achievable. You must assume any code not executing on a system you control can and will be compromised. As Rowland Shaw stated, the best bet for a financial institution is some sort of physical token which effectively adds a offline unique component to all transactions that cannot be (easily) known ahead of time by an attacker operating from a compromised system. Even then you should be aware of the fact that if the users computer has been compromised and he logs in with his secure token from that point forward until the session ends the attacker is free to perform whatever actions the user has permission to, but at least in that case the user is more likely to notice the fraudulent activity.

Orclev