I am not a software engineer as you will see if you continue reading, however I managed to write a very valuable application that saves our company lots of money. I am not paid to write software, I was not paid for writing this application, nor is my job title software engineer so I would like to have total control over who uses this application if I ever had to leave since as far as I can tell it is not legally theirs (did not write during company hours either).
This may sound childish but I've put much much time into this and I've been maintaining it almost on a daily basis so I feel that I should have some control over it, or at least could sell it to my company if they ever had to let me go, or I wanted to move on.
My current protection scheme on this application looks something like this:
string version;
WebRequest request = WebRequest.Create("http://MyWebSiteURL/Licence text file that either says 'expired' or "not expired'");
WebResponse response = request.GetResponse();
StreamReader stream = new StreamReader(response.GetResponseStream());
version = stream.ReadToEnd();
stream.Close();
response.Close();
if (version == ("not expired") == false)
{
MessageBox.Show(Environment.NewLine + "application expired etc etc", "Version Control");
}
It checks my server for "not expired" (in plain text), and if the webrequest comes back as anything but "not expired", it ultimately pops up another form stating it is expired and allows you to type in a passcode for the day which is a multiplication of some predetermined numbers times the current date to create "day passes" if ever needed (I think Alan Turing just rolled over in his grave).
Not the best security scheme, but I thought it was pretty clever having no experience in software security. I have however heard of hex editing to get around security so I did a little test for science and found this area of my compiled EXE:
"System.Net.WebRequest." Which I filled in with zeros to look like this: System.Net000000000
That was all it took to offset the loading of the application to hiccup during the server check which allowed me to click "continue" and completely bypass all my "security" and go along using the program without it ever expiring.
Now would a normal person go to this length (hex editing) to try to get past my protection scheme? Not likely, however just as a learning experience, what could I do as an added step to make hex editing or any other common workarounds not work unless it was by "professional" cracker?
Again I'm not paranoid, I'm just eager to learn more about security of applications. I was both proud of myself and ashamed at the same time for creating and breaking my own protection.
If commenting, please be kind since I know this is probably a humerus post to those more informed than I as I really have little experience in writing software and have never taken any type of course etc. Thanks for reading!
Another way to bypass the license check is to redirect the checking url to localhost returning always the desired text...
A better way is to make a call to a function doing the same thing but make your server response a signed XML including the server response time-stamp, that you can check on addition with the system datetime (use UTC dates in both sides). It is also a good idea to throw exceptions whenever something is not the way you expect it, and control the flow of your program with exception handling.
Check the following to get a how to clue:
How to: Sign XML Documents with Digital Signatures
How to: Verify the Digital Signatures of XML Documents
Now would a normal person go to this length (hex editing) to try to
get past my protection scheme?
Well i guess, that depends on how useful the application is for that "normal person", and how determines he is to make it work.
Most .net application unless obfuscated can be easily de-compiled to the source code using tools like (Telerik JustDecompile) or they can simple use the ildasm to see the IL code, i heard there are tools to even de-compile obfuscated .net libraries, although i haven't used or found any.
With my little experience, i can suggest two approaches
Enforcing licensing and cracking it in a application which runs plainly on the user machine is a cat and mouse game, you can add some extra protection to your code by moving some part of the applications functionality to the server and expose it as a web service which your client can consume, the part you move to the server must be an important part for the application to work and should be something that is hard to simulate.
The other approach is to add a auto updater feature to your application that will check the server for latest updates, and when ever it finds a new version it will overwrite the older one, thus overriding any cracked version, this can be easily disabled, but if disabled this will also stop any bug fixes you might release
I tried both the approaches, but they are only useful to some extent and you have to decide whether it is worth the effort enforcing or not
Related
Apps downloaded from the Windows Store are installed in this location:
C:\Program Files\WindowsApps
If you look inside this folder you can access each application's .exe and use reflector to decompile them.
Currently, my Windows RT application sends a password over SSL to a WCF service to ensure that only people using my app can access my database (via the service).
If my code can be read by anybody, how can I ensure that only people using my Windows 8 app are accessing the service?
Thanks!
In the very general sense, it is impossible. If ever you create anything that is placed on the customer's computer, eventually you will stumble upon someone that will manage to decipher your code and understand how to call your service. You may obfuscate it into insane levels, but still it has to be executable by the processor, so the processor has to understand it. And if it does, then potentially anyone knowing assembly can understand it too. You may smartly obfuscate it so that it will be very time-consuming to cleanup the code from unimportant trash, but still, at some point of time someone will read it.
One of common defenses is in trying to detect who* is actually trying to use your service. This is why all the "portals" require you to "register". This way, the application identity is marginalized and it is the user who provides login, password, PGP keys, etc is checked and verified whether he/she is allowed to actually run your service.
Also, on the OS/framework layer, there are several ways to selectively provide "licenses" to your customers and then in your application you may use keys/hashes from the licenses to authenticate in your service. This may partially remove from the user the burden of remebering the passwords etc, or it may provide an additional authentication factor, or it may simply be a yes-no flag that allows to run the app or not. Still, it will not guard your code against being read. Licenses just help in verifying if the software copy is legit and if belongs to that specific user/computer.
You may act selectively only against 'reflectoring' (or dotpeeking, or ildasming, or ...). Those tools really make the decompilation easy (although the original reflector is now paid software). So, the simpliest form would be to use obfuscator that will make the decompilation impossible or harder - that cuts some percentage of the potential code-readers and you can assume scriptkiddies are gone. You may ignore obfuscators and you may write the service connector in native code (C++, not C++/cli). That will make the code completely un-reflectorable and un-ildasmable, and that will cut off another large percentage of people, but with some will still be left (me and thousands of others, but that's much less than millions).
While this does not give you definitive answer, I wanted to show you that you can only get some "level of hardness", but you cannot make it totally safe from being read. This is why you should focus on making the service access in that way, that showing your code to a stranger on the street does not compromise your security.
Now gettint to your problem: the core thing seems to lie not in the fact that your app uses some secret algorithms, but rather - that you have hardcoded the password in. You see, there's with this approach, they do not need to read your code at all. They just need to listen what data your app sends over the sockets..
Another issue is that everyone uses the same keyphrase.
A hardcoded magic string may be some sort of validation, but never authentication. If you want the app to be register-free, make the registration silent and automatic at first run? Of course, you will just bounce the problem: anyone could read the code and learn how to autoregister, and then they will make a clone.. But, again, like I've said: you never know who's on the other side. Is it your app, or is it an ideal-clone of it? Or maybe is it a clone that uses your own hacked-a-bit libraries to connect to you? If it looks like a duck, and quacks like a duck, it is a duck..
I need some ideas how to create a activation algorithm. For example i have demo certificate. Providing that the application runs in demo mode. When full version certificate is provided then application runs in full mode.
Is it even possible and how would be a good way creating this system?
One simple was i was thinking would be just have a 2 encrypted strings, now when the decryption is succsessful with the demo public key certificate then the application will run in demo mode and etc..
You could do something like:
Generate public/private key pair
As owner of private key, you can sign those "activation certificates" (called AC from now on)
In your app, with public key, you can check if the sign is correct
As Overbose mentioned -- you can't prevent reverse engineering. In general someone could take functionality and put it in his/hers own app and thus eliminate any possible activation algorithm. So you can only assume (or make) this is hard enough not to be worth the effort (this is the same as for cryptography -- when you make the cost of breaking the message greater then the profit of gaining it you can say it is well secured).
So you could:
Make executable self-verifying (signed by you, self-checking based on hard-coded public key (one thing: you must skip this value when self-checking)).
Do some tricks with pointers (point to the activation function, go to 7th bit and change value of it for something based on value of another pointer; in some weird places change hard-coded values to those based on occurrence of some bits in other places of the code; generally -- make it more difficult to break than by simply changing bits in executable with hex editor)
Try to make some protocol that your server would use to ask questions about the app ("gimme the value of 293 byte of yourself") and check answers.
Use imagination and think of some weird self-checking method nobody used before :)
As mentioned -- none of this is secure from cutting the authentication part off. But nothing is and this could make it harder for crackers.
Background: I've deployed an activation based system built on top of a third-party license system, i.e. server, database, e-commerce integrations. I've also separately written a C# activation system using RSA keys, but never deployed it.
Product Activation commonly means that the software must be activated on a given machine. I assume that's what you mean. If all you want to do is have two strings that mean "demo" and "purchased", then they will be decrypted and distributed within hours (assuming your product is valuable). There is just no point.
So. assuming you want "activation", then when the user purchases your software, the following process needs to happen:
Order-fulfillment software tells Server to generate "Purchase Key" and send to user
User enters "Purchase Key" into software
Software sends Purchase Key and unique Machine ID to server.
Server combines Purchase Key and Machine ID into a string and signs it with its certificate and returns it to user.
Software checks that signature is valid using Servers public key.
Software could check in lots of places: loading the sig in lots of places, checking it in others.
When generating Purchase Keys, the server can store not only what produce was purchased, but what level of product. You can also have "free" products that are time limited, so the user can try the full version of the software for 30 days.
You are using C#, so make sure you obfuscate the binaries, using dotfuscator or equivalent. However, even with that there is nothing you can do against a determined hacker. Your goal, I assume, is to force non-paying users to either be hackers themselves, or to have to risk using a cracked version: kids wont care, corporations might. YMMV.
The code that does the checking needs to be in every assembly that needs protecting, otherwise an attacker can trivially remove protection by replacing the assembly that does the checking. Cut and paste the code if you have to.
Or just buy something.
Another option is to have the server pre-generate "Purchase Keys" and give them to the Order fulfillment service, but then you dont get to link the key to the customers details (at least not until they register). Better to have the ecommerce server hit your server when a purchase has been made, and have your server send it out.
The hard part isn't so much the generation of activation keys as it is the creation of the server, database, and the integration with e-commerce software, and most of all, human issues: do you allow unlimited installs per Purchase Key? Only 1? If only 1 then you have to have customer-support and a way to allow a user to install it on a new machine. That's just one issue. All sorts of fun.
This guy wrote a blog post about a similar idea, explaining what he did with their own commercial software. Also wrote a list of recommendations about the most obvious cracking techniques. Hope it helps.
One simple was i was thinking would be just have a 2 encrypted
strings, now when the decryption is succsessful with the demo public
key certificate then the application will run in demo mode and etc..
Could be a simple solution. But this way you won't prevent someone to reverse engineer your binaries and make the execution jump to the correct line. Everyone has your program, has a complete version of it, so it's only a matter of find how to break this simple mechanism.
Maybe a better solution is encrypt a part of the binaries needed to use the full application version, instead of a simple string. This way to execute the application complete version someone need to decrypt those binaries in order to execute them.
Please take in consideration that even that solution isn't enough. There are other problems with that:
Does all the version of your tool will share the same encryption key? Breaking one of them for breaking all..
Even if you use a different key for each binary application released, does the encrypted binary are identical? Once cracked one, you can reuse the unencrypted binaries for all distributed applications.
How to solve these problems? There's no simple solution. Most of the more important commercial software with even sophisticated protection systems are broken just few hours or days after they have been released.
Product activation is not a problem that asymmetric cryptography can solve. Asymmetric cryptography is about keeping secrets from your adversary. The problem is that you can't keep a secret that is stored on you're adversaries machine, that would be security though obscurity.
The correct way to do product activation. Is to generate a Cryptographic Nonce that is stored in a database on your server. You give this Nonce to the customer when they buy the product, and then they activate it online. This activation process could download new material, which would make it more difficult for the attacker to modify the copy they have to "unlock" new features.
But even with DRM systems that require you to be online while using the product. Like the ones found in new games like "From Dust" are still broken within hours of their release.
One of the benefits of public key encryption is that you can verify the origin of a given piece of data. So if you store the public key in your assembly, then sign a given piece of data (say an authorization code or serial number) your assembly can verifiably determine that you were the one that created that data - and not a hacker. The actual data itself isn't all that important - it can be a simple pass/fail value.
This is actually pretty easy to do with .NET. You can use an x509 certificates or like we use in DeployLX Licensing the RSACryptoServiceProvider.
I would highly recommend buying a commercial product (doesn't really matter which one, though DeployLX is excellent) and not doing this yourself for 2 reasons
Even if you're a great developer, you'll probably get it wrong the first time. And any savings you might have enjoyed by rolling your own will be lost to recovering from that mistake.
You'll spend far more time working on your own system - time that you should spend making your product great.
The second phase in protecting the software is to make sure that it runs the way you created it - and hasn't been modified by a hacker. It really doesn't matter what encryption you use if hackers can check if( licensed ) to if( true ).
You can use AsProtect to solve this problem. This is good staring point.
I recently landed on old web application which is full of old school tricks
GET param : user info in URL parameters
Session informations
Hidden elements used for storing information
HTML/JS/CSS dumped in the page. Without proper encoding. etc.
Window.open to show popups.
XSS issues etc.
Concatenated SQL string good for blind SQL attacks.
and just many more...
to make things work. Looks like application is old over past 5-7 years (ASP.NET 1.1) and looks like the application code has failed to keep pace with better security practices.
Thankfully it looks like over period browsers and security testing tools evolved very well. Helping people/customer to report so many security issues every now and then. Keeping them happy and system secure has become pain.
Can someone please let me know in case you have faced something similar and help me get to some case study or something for how to addressed this ? test tools which are "freely" available which can be used to test web sites for security on developer environment ? What strategies should be used to deal with this situation ? How to progress.
Let me start by saying this: While there are open-source and free security scanner tools, none will be perfect. And in my experience (with PHP at least) they tend to return enough false-positives that it's barely worth running them (but that could have gotten better since I last used them). If you want to use one to try to help identify issues, by all means do so. But don't trust the output either way (from a false-positive and a false-negative perspective).
As far as how to tackle it, I would suggest a step-by-step approach. Pick one type of vulnerability, and eliminate it across the entire application. Then go to the next vulnerability type. So a potential game-plan might be (ordered by severity and ease of fixing):
Fix all SQL Injection vulnerabilities.
Go through the code, find all places where it does SQL queries, and make sure they are using prepared statements and that nothing can get in.
Fix all XSS vulnerabilities
Find all places where local information (user-submitted or otherwise) is properly sanitized and escaped (depending on the use-case).
Fix all CSRF vulnerabilites
Go through the site and make sure that all the form submissions are properly using a CSRF token system to protect them from fraudulent requests.
Fix any and all authentication and session fixation vulnerabilities
Make sure the authentication and session systems are secure from abuse. This involves making sure your cookies are clean and that any session identifiers are rotated often. And make sure you're storing passwords correctly...
Fix and information injection vulnerabilities
You state that there is user information in URLs and hidden form elements. Go through all of them and change it so that the user cannot inject values where they shouldn't be able to. If this means storing the data into a session object, do so.
Fix all information disclosure vulnerabilities
This is related to the former point, but slightly different. If you use a username in the URL, but can't do anything by changing it, then it's not an injection vulnerability, it's just a disclosure issue. Mop these up, but they are not nearly as critical (depending on what's disclosed of course).
Fix the output
Fix the encoding issues and any method that might generate invalid output. Make sure that everything is sane when it's outputted.
The important thing to note is that anything that you fix will make the application safer. If it's a live application right now, don't wait! Don't try to do everything, test and release. Pick a reasonable sized target (2 to 4 days of work max), complete the target, test and release. Then rinse and repeat. By iterating through the problems in this manor, you're making the site safer and safer as you go along. It will seem like less work to you because there is always an end in sight.
Now, if the application is severe enough, it may warrant a full rewrite. If that's the case, I'd still suggest cleaning up at least the big ticket items in the existing application prior to starting the rewrite. Clean up the SQL Injection, XSS and CSRF vulnerabilities at a bare minimum prior to doing anything else.
It's not an easy thing to do. But taken a small bite at a time, you can make significant progress while staying above water... Any little bit will help, so treat the journey as a series of steps rather than a whole. You'll be better off in the end...
Well, a google on each of the issues will help fix it, so I'll assume you're just worried about the actual risks.
This is easy to fix, just change to $_POST, which is a bit more secure, especially when used with session tokens.
This is still widely used, so I don't see an issue?
Meh, so long as that data is checked server side, and if it doesn't verify, the user has to relog or similar, this is acceptable. Of course, session is preferred, or even cookies.
Tidying up is just a long job, no issues unless passwords etc are being revealed in the JS. Css + html are almost always unencoded, so this seems fine.
I'm just not a fan of popups, and never use them, can't help here.
Well, host the script locally if possible, and sanitize any XSS that are essential, by stripping tags, URL encoding that kind of thing.
I encountered exactly this situation a couple of years ago on an e-commerce web site. It was in ASP.NET 1.1 and was absolutely appalling in terms of code quality and security practices. Further, I was told by management that a re-write was absolutely out of the question, and could not convince them to budge on that.
Over the course of 2 years I managed to get this system PCI-DSS compliant. This means we had to close all of those security loopholes one by one, and put in place practices to ensure they could not happen again.
The first problem is you have to find all the bugs and security flaws. You can use external vulnerability probing tools (I recommend QualysGuard). But manual testing is the only way to get complete coverage. Write out old fashioned test scripts to test for XSS, SQL injection, CSRF etc. and enlist the help of testers to run through these scripts. If you can automate these tests, it is well worth doing. But don't avoid covering a test case just because its too hard to automate. If you can afford security consultants, have them help you scope out the test coverage and write test cases.
This will give you:
a) a list of bugs/flaws
b) a repeatable way to test if you actually fixed each one
Then you can start refactoring and fixing each flaw.
The process I followed is:
step 1: refactor, step 2: test & release, step 3: go back to step 1.
I.e. there is a continuous cycle of fixing, testing & releasing. I would recommend you to commit to regular deployments to your production systems e.g. monthly, and squeeze as many "refactorings" into each release cycle as you can.
I found Automated security tools are almost useless due to:
a) they can provide you with a false sense of security
b) they can give you so many false positives that you are sent off on meaningless tangents instead of working on real security threats.
You really need to get to grips with the nature of each security vulnerability and understand exactly how it works. A good way to do this is to research each flaw (eg. start with OWASP top 10), and write a document that you could give to any developer on your team that would explain to them exactly what each flaw is you are trying to protect against and why. I think too often we reach for tools to help fix security flaws, thinking we can avoid the effort of really understanding each threat. Generally speaking, tools are only useful to improve productivity - you still have to take charge and run the show.
Resources:
1)Read the OWASP top 10.
2)The PCI-DSS specification is also really good stuff and helps you to think holistically about security - ie covering way more than just web applications, but databases, processes, firewall, DMZ/LAN separation etc. Even if its over the top for your requirements, its well worth browsing through.
It might be duplicate with other questions, but I swear that I googled a lot and search at StackOverflow.com a lot, and I cannot find the answer to my question:
In a C#.Net application, where to store the protection trial info, such as Expiration Date, Number of Used Times?
I understand that, all kinds of Software Protection strategies can be cracked by a sophiscated hacker (because they can almost always get around the expiration checking step). But what I'm now going to do is just to protect it in a reasonable manner that a "common"/"advanced" user cannot screw it up.
OK, in order to proof that I have googled and searched a lot at StackOverflow.com, I'm listing all the possible strategies I got:
1. Registry Entry
First, some users might not have the access to even read the Registry table.
Second, if we put the Protection Trial Info in a Registry Entry, the user can always find it out where it is by comparing the differences before and after the software installation. They can just simply change it.
OK, you might say that we should encrypt the Protection Trial Info, yes we can do that. But what if the user just change their system date before installing?
OK, you might say that we should also put a last-used date, if something is wrong, the last-used date could work as a protection guide. But what if the user just uninstall the software and delete all Registry Entries related to this software, and then reinstall the software?
I have no idea on how to deal with this. Please help.
A Plain File
First, there are some places to put the plain file:
2.a) a simple XML file under software installation path
2.b) configuration file
Again, the user can just uninstall the software and remove these plain file(s), and reinstall the software.
- The Software Itself
If we put the protection trial info (Expiration Date, we cannot put Number of Used Times) in the software itself, it is still susceptible to the cases I mentioned above. Furthermore, it's not even cool to do so.
- A Trial Product-Key
It works like a licensing process, that is, we put the Trial info into an RSA-signed string. However, it requires too many steps for a user to have a try of using the software (they might lose patience):
4.a) The user downloads the software;
4.b) The user sends an email to request a Trial Product-Key by providing user name (or email) or hardware info;
4.c) The server receives the request, RSA-signs it and send back to the user;
4.d) The user can now use it under the condition of (Expiration Date & Number of Used Times).
Now, the server has a record of the user's username or hardware info, so the user will be rejected to request a second trial. Is it legal to collection hardware info?
In a word, the user has to do one more extra step (request a Trial Product Key) just for having a try of using the software, which is not cool (thinking myself as a user).
NOTE: This question is not about the Licensing, instead, it's about where to store the TRIAL info. After the trial expires, the user should ask for a license (CD-Key/Product-Key). I'm going to use RSA signature (bound to User Hardware)
P.S.: My software will be targetting the China market, whose software market is different from US. Most people in China, they only buy hardware, they usually don't buy software like Micosoft Windows/Office (they just use pirated copies). However, some professional software aiming to a specific field, research people are still willing to buy it IF there is no crack version or the crack version is very difficult to install.
Either option 1 (plain registry key) or 2 (plain file) is just fine. Here's my reasoning:
Standard-privileged users do have read permissions for the registry. If they can't read your key, something else is wrong. Standard-privileged users do not have write permissions for the registry, but this doesn't matter because they also don't have permissions to install software in the first place. In other words, either the user will have permission to create your registry key at install time, or they'll need help installing anyway. Therefore the basic technical issues you raised for the registry key aren't really a factor.
Just don't worry about those users who do things like set back their system clock or manually hack the registry to break your key. Let me say that again: Just don't worry about users who make a conscious decision to alter their system in a significant way to get past your trial limitations — and make no mistake, setting back the system clock or editing the registry are significant modifications. The reason you shouldn't worry about these users is that they represent exactly $0 in potential income. A user willing to make to take this kind of conscious choice about pirating your software isn't going to just give up and decide to pay for your product if it doesn't work. If they can't get your software for free, they'll either go with a competitor or do without. You're in this to make money - you don't want to spend time and resources trying to grab sales you can't win or sending users to a competitor. Therefore, the basic security issues you raised for either option aren't a factor.
You won't find a single perfect solution. The efforts you put into this should be proportional to the price of the product you make. If it's worth a lot, then buy a professional solution. If not, then use any combination of methods that you find. Use the registry, request an online trial key, check if the user manipulates the system time, and so on.
I would suggest taking a slightly different tact.
Give a "lite" version of your software away. No trial, just really limited functionality.
If they want to trial a "professional" version then ask them to get a trial key. This should be encrypted in some format, store it where ever you want. When the app starts, test for the existence of this trial key. If it's there then decrypt it. Inside the key should be the expiration date of the software.
Test the date and act accordingly. If it doesn't exist then just run as the lite version.
To get a trial key, you can have them enter an email address and some other info you want into a box in your app. It's not unreasonable to ask that the machine be connected to the internet for this limited part. Even MS Office requires you to connect to the internet briefly to validate the keys. Have the app contact your server with the key request. Email them back the key.
For bonus points tie the trial key to some metric of the machine itself. Even if it's just the name of the box. Those change rarely and it's a trial anyway.
If you truly can't force them to be connected to the internet to acquire a key, then you can go a slightly different route. Have the app generate a request (which includes the machine name or something along those lines). Have the user either call you with that generated request id or have them plug it into a website. Then email them the key for that machine.
All of this prevents sharing keys. Has a fall back in case the key location is jacked with and prevents the key from being moved to other machines. It also gives you a way of doing this in a completely disconnected manner. Even if they rip the public encryption key out of your app to decrypt the software license key, they won't have your private encryption key in order to build a new license key file.
Now, key management is only one aspect of the evil you are fighting.
The next step is that you need to obfuscate your app in such a way that they can't simply decompile it and bypass your key checks. This is much more common than passing around key files.
You might even have multiple methods in the app that test for the key in different ways.. But this is a different question.
As a final bonus for those vindictive enough to do this: Seed the various pirate boards with key gen software that does interesting things to the machines of the people who are trying to rip you off. You can get really creative here.
Or, like Joel said, you could just simply not worry about them. After all, if they are going out of their way to find a cracked version of your software they weren't going to pay for it anyway and you really haven't lost anything.
Can you require that users using the trial be connected to the internet? If so just have the trial version contact a server during startup and you can check all sorts of things. you don't have to worry about storing stuff on the users computer or them tampering with the data or the system time.
I know this is an old thread, but I just stumbled upon it and other might find this useful.
A valid option these days could be that your application queries a rest service at install time to generate a trial or payed license. Every time the user opens the application the application queries the rest service for the license info that is linked to that one specific copy of software.
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.
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.
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.
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.
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.
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...
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.