Hi guys,
First off, I apologize for the length of this post/question/issue. I have posted a couple times to Experts Exchange and got few answers, and most of those had been attempted already with bad results, so I feel the need to give a moderately long background intro that hopefully will explain what we have done in the past and why we moved on from it.
Our application is very large, written in VB.NET (VS2010) and based on the .NET Framework 4.0. It currently has about 6000 paying users (with a monthly fee), and sees about 20-50 new registrations per day, most of which are previous users that are abusing the trial system in one way or another.
While I cannot name the software I will say that many of you would be familiar with it - I only bring that up to stress one single point: Hackers will go to any length to crack this software. Its not something that a simple fix will "fix" :)
When we first launched the software, the only authentication we used was via HTTP post. Upon logging in the computers hardware ID would be stored on our server, but at the time it was not validated in any way other than to make sure that it was only one of 3 allowed for that user. Obviously this weak security was cracked pretty quick and easy by someone modifying the .EXE file itself to simply bypass the HTTP registration check.
To stop that we moved to SSL based authentication, but left everything else the same. That took the hackers about a week - the result was they used their own web server to pass back a registration string on request from any client using SSL. After that we integrated a check of the SSL certificate's thumbprint which stumped them for about 2 weeks, but they somehow (I still dont understand how, exactly) managed to spoof the SSL certificate including thumbprint on their own server.
Next we added code signing and tamper-proofing using a stronger obfuscator. Again, they managed to get around it - tho now they have stopped trying to modify the .exe and instead used a loader application to somehow control all IO from our app including SSL requests.
Then we decided to start saving the applications settings (which are critical to its operation) on our servers, and only releasing them to the client app after successful authentication. That worked a little better - but again it was eventually cracked so that the hackers web server is now providing that function as well.
There was a lot of back and forth that went on over the course of all these changes (they happened over several months), and a lot of lessons learned, but the end result was that the app was still cracked by hackers.
We were approached later by a gentleman claiming to be able to crack-proof our app. he never completed the code, and never 100% explained how it would work, but from what I understand there were several concepts that would come in to play, including the following:
First a request would be made to our servers that sent the user info - user/pass - via SSL and also encrypted with a public key. The response would be decrypted with the same key, but in addition to the other things it would contain a new public key specific to that users session that would be used for all further communication from that client to our server.
After that phaze a new request would be made using the new keys to request a critical piece of data without which the application could not function - this was the key to the whole thing. As I understand it, this piece of data would include at least one (and likely 2-3) methods from our application that were removed before compiling, or perhaps compiled as overridable with the base method empty or just containing a THROW statement or some such - so that if they were not overridden (is that a word? lol) the error would be thrown instead of the critical work being done by those methods. Those methods would then be passed as a highly encrypted string to the client using the new SSL and RSA combination established in the last step, and then compiled on the fly and injected in to the the application using CodeDom? Again, I am not a expert at this... this is just how I understood that it would work.
Another point was that the downloaded RSA key would either contain or be derived in part from the users username and password, so that other users could not use the same downloaded code, and the code would also be validated after decryption by way of a HASH check of some kind also done via SSL/RSA.
Now... Unfortunately I did not ask enough questions and the guy that promised this solution never finished it, and to be honest I just do not see how it all fits together. I consider myself a good developer... but there is just too much with which I have little knowledge or experience at work here, not the least of which is encryption in general.
What I need is a kick in the right direction in implementing this solution... or introduced to someone looking for a contract to implement it. We used Elance.com before and since he never finished the project, we did not have to pay - so we are not out anything, other than the fact that we have an un-secured app out there lol. So we are willing to hire someone to take it over if necessary. To be honest tho, I think I would rather learn how to do this and get it done myself if at all possible. That would make upkeeping the system easier.
Oh last point - we push out a new software release once per week that contains new content, which is ever-changing. We would like each release changed in some way to prevent the same hack/crack that worked on the previous versions from working, such as changing the public key used for the initial encryption or some such. :)
I hope to get some good ideas here... I have never used this forum, but from the looks of things it may be the largest of its kind and I am glad I found it :)
Thanks all,
Dave
First off, I apologize for the length of this post/question/issue. I have posted a couple times to Experts Exchange and got few answers, and most of those had been attempted already with bad results, so I feel the need to give a moderately long background intro that hopefully will explain what we have done in the past and why we moved on from it.
Our application is very large, written in VB.NET (VS2010) and based on the .NET Framework 4.0. It currently has about 6000 paying users (with a monthly fee), and sees about 20-50 new registrations per day, most of which are previous users that are abusing the trial system in one way or another.
While I cannot name the software I will say that many of you would be familiar with it - I only bring that up to stress one single point: Hackers will go to any length to crack this software. Its not something that a simple fix will "fix" :)
When we first launched the software, the only authentication we used was via HTTP post. Upon logging in the computers hardware ID would be stored on our server, but at the time it was not validated in any way other than to make sure that it was only one of 3 allowed for that user. Obviously this weak security was cracked pretty quick and easy by someone modifying the .EXE file itself to simply bypass the HTTP registration check.
To stop that we moved to SSL based authentication, but left everything else the same. That took the hackers about a week - the result was they used their own web server to pass back a registration string on request from any client using SSL. After that we integrated a check of the SSL certificate's thumbprint which stumped them for about 2 weeks, but they somehow (I still dont understand how, exactly) managed to spoof the SSL certificate including thumbprint on their own server.
Next we added code signing and tamper-proofing using a stronger obfuscator. Again, they managed to get around it - tho now they have stopped trying to modify the .exe and instead used a loader application to somehow control all IO from our app including SSL requests.
Then we decided to start saving the applications settings (which are critical to its operation) on our servers, and only releasing them to the client app after successful authentication. That worked a little better - but again it was eventually cracked so that the hackers web server is now providing that function as well.
There was a lot of back and forth that went on over the course of all these changes (they happened over several months), and a lot of lessons learned, but the end result was that the app was still cracked by hackers.
We were approached later by a gentleman claiming to be able to crack-proof our app. he never completed the code, and never 100% explained how it would work, but from what I understand there were several concepts that would come in to play, including the following:
First a request would be made to our servers that sent the user info - user/pass - via SSL and also encrypted with a public key. The response would be decrypted with the same key, but in addition to the other things it would contain a new public key specific to that users session that would be used for all further communication from that client to our server.
After that phaze a new request would be made using the new keys to request a critical piece of data without which the application could not function - this was the key to the whole thing. As I understand it, this piece of data would include at least one (and likely 2-3) methods from our application that were removed before compiling, or perhaps compiled as overridable with the base method empty or just containing a THROW statement or some such - so that if they were not overridden (is that a word? lol) the error would be thrown instead of the critical work being done by those methods. Those methods would then be passed as a highly encrypted string to the client using the new SSL and RSA combination established in the last step, and then compiled on the fly and injected in to the the application using CodeDom? Again, I am not a expert at this... this is just how I understood that it would work.
Another point was that the downloaded RSA key would either contain or be derived in part from the users username and password, so that other users could not use the same downloaded code, and the code would also be validated after decryption by way of a HASH check of some kind also done via SSL/RSA.
Now... Unfortunately I did not ask enough questions and the guy that promised this solution never finished it, and to be honest I just do not see how it all fits together. I consider myself a good developer... but there is just too much with which I have little knowledge or experience at work here, not the least of which is encryption in general.
What I need is a kick in the right direction in implementing this solution... or introduced to someone looking for a contract to implement it. We used Elance.com before and since he never finished the project, we did not have to pay - so we are not out anything, other than the fact that we have an un-secured app out there lol. So we are willing to hire someone to take it over if necessary. To be honest tho, I think I would rather learn how to do this and get it done myself if at all possible. That would make upkeeping the system easier.
Oh last point - we push out a new software release once per week that contains new content, which is ever-changing. We would like each release changed in some way to prevent the same hack/crack that worked on the previous versions from working, such as changing the public key used for the initial encryption or some such. :)
I hope to get some good ideas here... I have never used this forum, but from the looks of things it may be the largest of its kind and I am glad I found it :)
Thanks all,
Dave