Securing .Net code (the 3rd party conundrum)

I think, except for the open source community, any .Net project wants its code locked and secured. We are currently in the analysis phase of a large scale client-server project and it's simply not acceptable for us to provide a commercial solution which source code can be inspected to the last detail in a comfortable format.

However, this means making a ~2k investment on a 3rd party solution, because Microsoft doesn't offer the necessary tools to secure .Net source code. Out of the box, any compiled and shipped .Net project is the equivalent of an open source application limited by copyright notices, but not physically constrained. Anyone, with just general .net programming knowledge can reverse engineer a system. This isn't acceptable.

Being this such an intrinsic aspect to development, it's no wonder that while C# has seen quite an increase in enterprise development, to this day it still lacks any sort of sex appeal for general consumer software developers. The investment in 3rd party solutions can be too big for many of these small outfits.

What troubles me is that since the decision was made early on by Microsoft to not provide the tools and the mechanisms for properly securing source code in .Net, the proliferation of 3rd party solutions was inevitable. Essentially all of them with vested commercial interests. Any attempt now to do so would probably be met with angry anti-competitive cries from these companies which I suspect they could bring to court and win.

My questions... how much do you think this affects the adoption of .net for general consumer-grade software? Was it a mistake by Microsoft to not provide these tools? Could it provide them sometime in the future without risking a judicial backlash? Why do you think they didn't offer these solutions when the .Net platform was widely advertised as a development target for general consumer software and enterprise software alike? Doesn't Microsoft early decision contrasts with their desire to make the .Net platform ubiquitous in the Windows development arena?

I doubt that .net is ever going to be much more than "script kiddies delux" (present company excluded, of course)... As you point out it's beyond insecure and leaves one open to piracy at levels none of us would tolerate.

But it's also HUGE... both producing larger "executables" and requiring a monstrous run time library. If anyone actually cares about code-bloat anymore, .net is one significant cause of it.

I won't run .net code on my systems...

Quote:

---

Originally Posted by CommonTater

I doubt that .net is ever going to be much more than "script kiddies delux" (present company excluded, of course)... As you point out it's beyond insecure and leaves one open to piracy at levels none of us would tolerate.

---

Nothing could be farther from the truth! Code protection issues will eventually be addressed. Fact is, .NET runs on just about everything out there these days - cell phones, PDA-type devices, Unix and MS systems, etc. Both free and third-party libraries abound. Plus, it's open-standard (RIP Java!).

Quote:

---

Originally Posted by Sebastiani

Code protection issues will eventually be addressed.

---

Can I have your word on that? Because I have yet to see any indication of that ever happening.

Quote:

---

Originally Posted by CommonTater

But it's also HUGE... both producing larger "executables" and requiring a monstrous run time library. If anyone actually cares about code-bloat anymore, .net is one significant cause of it.

---

What are you talking about? I made a simple change calculator application in both C# and (as similarly as I possibly could) C++. The C++ executable was 53KB, the C# one was only 7KB. I'll show you the code for both if you'd like.

In fact, every program I've made in C# has come out as a surprisingly small executable size, especially compared to an equivalent C++ program.

Maybe if you spent some time using it instead of avoiding it like the plague and totally dismissing it you wouldn't have such a twisted view.

Quote:

---

Originally Posted by Mario F.

Can I have your word on that? Because I have yet to see any indication of that ever happening.

---

Simple, expand all non-external classes into PODs, and all non-recursive functions into inline code - right down to the metal, so to speak. The code would likely decompile to the equivalent of assembly language, probably...

I think it's call IL for intermediate language, but it serves the same purpose as assembly.

What do you mean by "source code can be inspected to the last detail?" Can you elaborate?

Maybe I misunderstood the context, but I don't think the ease of getting human readable source back is an issue for the average bit of consumer grade software. I can't count the number of crappy ".Net" implementations of disc layout (CD/DVD mastering software) I've seen that are all based on a CodeProject tutorial. They are all in the $5 to $10 range. I don't think it would break a project.

Then again, I don't think you mean consumer the way I have interpreted consumer. I think you are talking more about corporate software where trade secrets... are trade secrets. In that case, where crucial business logic could be discovered in a matter of moments without using the tools you reference, I'd say it affects the choices as much as the choice of platform or any other development tools. In other words, I don't imagine it effects the growth of ".Net" at all considering that it is, as you say, a known issue to be factored in to development costs.

Then again, I've seen some tools that obfuscate discovery by linking to libraries that carry a per seat cost. These sorts would probably be ignored in favor of better tools, but if that was the only option, or if the development costs can take another hit, I can easily see ".Net" being dropped in favor of a language or platform that isn't so easily reversed.

Soma

There's nothing wrong with the .NET framework, "bagging" it out without reason is stupid. Seriously, C# fixes a lot of problems that plague C++ (it also introduces some :-)).

Dotfuscator is the industry-standard for stopping reverse-engineering by such tools like "Reflector". Microsoft bought Dotfuscator rights long ago, and have since released "community versions". If you're developing commercial software, I'm sure you can pay for a Dotfuscator commercial license.

I think it doesn't really affect uptake of .NET at all, maybe for a few things. But with the whole SAS movement, it becomes slightly less relevant where the meat of the logic sits "in the cloud".

This problem covers all forms of software, it's just more prevalent with intermediate languages like IL or Java byte-code.

Quote:

---

Originally Posted by phantomotap

Then again, I don't think you mean consumer the way I have interpreted consumer. I think you are talking more about corporate software where trade secrets... are trade secrets.

---

By consumer-grade software I mean all software meant to be sold to the masses,.

Quote:

---

In other words, I don't imagine it effects the growth of ".Net" at all considering that it is, as you say, a known issue to be factored in to development costs.

---

Apparently however, of all the reasons I've heard not to use.Net in consumer-grade software, this one is the most recurrent. It's particularly damaging to small entrepreneurs who can't afford the 4 digit figure of current obfuscation solutions.

Quote:

---

Originally Posted by zacs

If you're developing commercial software, I'm sure you can pay for a Dotfuscator commercial license.

---

Oh, please....

Quote:

---

Originally Posted by zacs

But with the whole SAS movement, it becomes slightly less relevant where the meat of the logic sits "in the cloud".

---

Software keeps being primarily developed outside the cloud. And it will stay this way most probably for a very long time. This is particularly true for consumer-grade software, where SaaS is a looong way from becoming an acceptable and widespread practice.

Quote:

---

Originally Posted by CommonTater

I doubt that .net is ever going to be much more than "script kiddies delux" (present company excluded, of course)... As you point out it's beyond insecure and leaves one open to piracy at levels none of us would tolerate.

But it's also HUGE... both producing larger "executables" and requiring a monstrous run time library. If anyone actually cares about code-bloat anymore, .net is one significant cause of it.

I won't run .net code on my systems...

---

If you create a standalone application, it ends up being like 36 MB minimum I think. If you make an app that depends on .NET being installed, it should be very small.

I think .NET is fairly nice even though all the eyecandy that comes with it makes it a little slower than desired. I don't think it could still be that bloated/crappy after 4 major versions and quite a few years.

As far as obfuscating the code goes (Mario), I think you're stuck with using a paid product.

Quote:

---

Originally Posted by Epy

If you create a standalone application, it ends up being like 36 MB minimum I think.

---

:eek: For "Hello World"?? :confused:

In my entire life I've never written anything even 1/10th that size...

Free standing C proggies start at about around 16K.

Quote:

---

Originally Posted by CommonTater

:eek: For "Hello World"?? :confused:

In my entire life I've never written anything even 1/10th that size...

Free standing C proggies start at about around 16K.

---

You'd have the same problem with any non-native binaries. Java programs aren't going to do anything without the JRE installed. Python scripts need Python installed, etc. The actual .exe itself is very small; the size comes from the interpreter.

Quote:

---

Originally Posted by CommonTater

:eek: For "Hello World"?? :confused:

In my entire life I've never written anything even 1/10th that size...

Free standing C proggies start at about around 16K.

---

It's not exactly statically linking what it needs, it's including the whole runtime I think. I don't know that much about .NET, but I do know that there's a significant difference between standalone and .NET runtime dependent. The analogy to Java is pretty much right on.

Quote:

---

Originally Posted by Epy

... I don't know that much about .NET, ...

---

Then don't comment that it's "buggy/crappy", I work with it 8 hours a day and the framework is awesome. Perhaps once you've found yourself living in C++ world for example with "oh, that's not in the standard library -- you'll have to endure DLL/static library hell, or write it yourself". And no, I'm not being pro-Microsoft (just take a look at Mono).

We've discussed this morning the path to go and it's pretty much acquiring a copy of an obfuscator. Still other options were presented.

Eventually, if one does a deep study of the core technologies, one can write their own obfuscators. A good grasp of IL and the CLR should be pretty much what is required. Others pretty much have delineated the path (this particular series starts here, for instance). Ultimately, no simple feat though; which puts a whole lot of people out.

Obfuscating on our case it's not so much a protection against tampering. Our software will try to make its way into a highly competitive business with a good potential for profit. Our main concern is making it more difficult for the competition, in case someone decided to eyeball our methods. We do want to ensure some form of tampering protection though, since the client systems can be numbered in the tenths for every customer and we need to ensure that our software validation routines have a minimum of protection. Finally there's one third issue. Our software, being a POS and retail management system, must try to offer some protection against hacks meant to fake/alter data. The so-called "zappers" are a real threat on this type of business and on our country and in Europe (our planned markets) if the IRS or social security catch inconsistent data meant to fool the taxes, their first line of response is against exactly the software manufacturer.

The problem for us is the investment of course. 2K may not seem much, but it's already well and beyond our capabilities, if you consider other investments that had to be made to bring this startup to a solid start. It wasn't the case with software (to some extent) since we adopted the Microsoft BizSpark program. But we are paying rent, we are paying 2 other developers, we had to buy computers, we had to buy desks, chairs, ... I think you get the gist; all for a project that is planned to hit the market only by mid April next year. We simply don't have the money anymore. Right around the purchase of the computers, we had to start to pour in our own personal money.

So, for even smaller outfits and for the guy at home planning to develop, not for the enterprise market like we do, but for the consumer in general, .Net lack of any code protection is in my view a real bummer for the adoption of the language. I really trust this to be one of the most motivating factors for .Net development to not be so widespread in the consumer market. I for one cannot conceive developing closed source software in a language like C# for the consumer market without the need to at least give it a minimum of protection against tampering or inspection.

Quote:

---

Originally Posted by Mario F.

We've discussed this morning the path to go and it's pretty much acquiring a copy of an obfuscator. Still other options were presented.

Eventually, if one does a deep study of the core technologies, one can write their own obfuscators. A good grasp of IL and the CLR should be pretty much what is required. Others pretty much have delineated the path (this particular series starts here, for instance). Ultimately, no simple feat though; which puts a whole lot of people out.

Obfuscating on our case it's not so much a protection against tampering. Our software will try to make its way into a highly competitive business with a good potential for profit. Our main concern is making it more difficult for the competition, in case someone decided to eyeball our methods. We do want to ensure some form of tampering protection though, since the client systems can be numbered in the tenths for every customer and we need to ensure that our software validation routines have a minimum of protection. Finally there's one third issue. Our software, being a POS and retail management system, must try to offer some protection against hacks meant to fake/alter data. The so-called "zappers" are a real threat on this type of business and on our country and in Europe (our planned markets) if the IRS or social security catch inconsistent data meant to fool the taxes, their first line of response is against exactly the software manufacturer.

The problem for us is the investment of course. 2K may not seem much, but it's already well and beyond our capabilities, if you consider other investments that had to be made to bring this startup to a solid start. It wasn't the case with software (to some extent) since we adopted the Microsoft BizSpark program. But we are paying rent, we are paying 2 other developers, we had to buy computers, we had to buy desks, chairs, ... I think you get the gist; all for a project that is planned to hit the market only by mid April next year. We simply don't have the money anymore. Right around the purchase of the computers, we had to start to pour in our own personal money.

So, for even smaller outfits and for the guy at home planning to develop, not for the enterprise market like we do, but for the consumer in general, .Net lack of any code protection is in my view a real bummer for the adoption of the language. I really trust this to be one of the most motivating factors for .Net development to not be so widespread in the consumer market. I for one cannot conceive developing closed source software in a language like C# for the consumer market without the need to at least give it a minimum of protection against tampering or inspection.

---

Well, perhaps you could forgo the code-protection aspect until you land your first big client then? In the meantime, just write the code in such a way that uses a lot of unnecessary indirection, NOP's, lookup tables, and redundancy. Eventually, you can experiment with different obfuscator designs (you can use Mono Cecil to pull the bytecodes from the assembly) - not only will you save yourself from renewing software licenses, you'll have peace of mind...knowing that you have a system in place that gets job done properly!

Quote:

---

We've discussed this morning the path to go and it's pretty much acquiring a copy of an obfuscator. [...] I for one cannot conceive developing closed source software in a language like C# for the consumer market without the need to at least give it a minimum of protection against tampering or inspection.

---

Well, I understand your pain, and with that situation in mind, I'd agree that the obfuscator is a necessary purchase, but I second Sebastian's suggestion of waiting until you are nearly prepared for delivery to invest in such a tool.

I do have a question though. Would early investment in such a tool give you some sway in the event that an agency does pursue legal measures against you guys as the software developers? (I'm sure it would positively influence events here in the USA.)

Doesn't it suck that doing any decent business in the software world pretty much guarantee you'll be sued at some point?

Soma

Quote:

---

I doubt that .net is ever going to be much more than "script kiddies delux" (present company excluded, of course)... As you point out it's beyond insecure and leaves one open to piracy at levels none of us would tolerate.

---

I completely disagree. It is here to stay in one form or another. Whether the .NET title remains after the wow factor has worn off remains to be seen but the general concept is solid and powers and will power a great many applications. Most C++ dev houses have in one form or another switched to C# for various components or are in the process of switching. This probably does not apply to AAA video game studios but some Indie studios are using it.

Code obfuscation tools are a must with C# so it is one of those grin and bear it type things. But I don't think this slowed the adoption of .NET. I would also guess the adoption rate of .NET is bound to double or triple as the U.S. and various economies begin to recover and grow again.

Quote:

---

Originally Posted by phantomotap

Would early investment in such a tool give you some sway in the event that an agency does pursue legal measures against you guys as the software developers? (I'm sure it would positively influence events here in the USA.)

---

In some small way it could. But only in a small way. Currently, if we were to develop an open source cash register with no data encryption, we could still see it licensed for operation as long as the software respects the commercial law of any given country. But securing the code at this point would not provide us with any special advantage over state prosecution because all accounting-like software source code can be inspected by the proper officials if there is probable cause and some judge signs the order. But this legal requirement is only of small consequence. A company doesn't have many options to argue against "probable cause". Anything they may have is only part of their defense and will only be considered in full during the trial.

In any case, there's currently an European directive being drafted requiring all cash register software to be tamper proof. While this will not stop the most skilled fraudsters, it will still force developers of this type of software to secure code, data transmissions and data storage (including on RAM, I believe). So, for all effects the state actually wishes for companies to close and even protect to the best of their abilities their source code as a means to reduce fraud.

Are there any 3rd party security dongles that you can purchase from a vendor that could further limit access to the system? Perhaps the dongle could be hardwired into the system or board.

I honestly know nothing about dongles. Could take a look at that, I suppose. But that's perhaps taking it to a level I don't wish. My concerns about source code end the moment we are able to force a potential cracker to have to rely on asm to do their thing. Anything more than that and I'm probably not interested.

If you are a looking for a security dongle you should take a look at CodeMeter. We are also looking at using this to protect our software. The owners (Wibu) have offered hackers money prizes to hack this and no-one has won the prize yet, so it seems like one of the better options. http://www.wibu.us

Quote:

---

Originally Posted by Petrr

If you are a looking for a security dongle you should take a look at CodeMeter. We are also looking at using this to protect our software. The owners (Wibu) have offered hackers money prizes to hack this and no-one has won the prize yet, so it seems like one of the better options. http://www.wibu.us

---

Thanks for the recommendation. I'd be happy to assist you if you need something; just pm me.

In short .NET is easy to reverse engineer and crack. We frequently demo a crack of notepad that takes less than 5 minutes to engineer. Obfuscation is a good choice for a moderate level of security, but it's not seriously going to stop crackers if your software is interesting to them.

It's helpful to remember that security is scalar--there's no absolute point where you have total security. More security--like more locks on your front door--increases costs and sometimes reduces convenience. It's all about tradeoffs, just like designing an app.

We make both software-based protection systems as well as hardware. Hardware is essentially uncrackable the way we implement it. You can get into a hardware solution (dongle) with no upfront costs but a cost for each copy you sell. If that works for your business model, great. For some people, that model won't work at all. You can also consider a simple software activation method in low-risk markets (like the US) and using a dongle in higher-risk environments (like China). Both we and Safe-Net have solutions that make that mixed model very simple. There are also very low-cost dongles, but most of these have some issues (not trying to beat up competitors here, but you usually do get what you pay for).

In any case if you use a 3rd party solution to encrypt and protect your software be sure to follow the manufacturer's recommendations on how to implement. Many of our customers for some reason think they should use the API instead of our envelope and don't realize the envelope actually provides superior protection in most cases. And it's less work.

I took a cursory look at your products and they do seem fine indeed. Did also the obligatory search for cracks to your products and was pleasantly surprised by the absence of any relevant information. It may exist... who knows, right?... but isn't in the public domain to a point where it becomes a concern to most anyone deciding to use them.

However as I mentioned, my code security concerns end the moment I am able to force a cracker to have to use assembly in order to be successful in cracking our software. That's the level of security I am (we are) willing to pursue. In any case your company did earn an entry on my OneNote, just so you know. For the day when it may become necessary...