Securing .Net code (the 3rd party conundrum)

[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.

[Sebastiani]

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!

[phantomotap]

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

[VirtualAce]

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.

[Mario F.]

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.

[VirtualAce]

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.

[Mario F.]

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.

[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

[Wibu-Systems]

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.

[Mario F.]

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...