C# Licensing System

You're right. What about if you add a method that checks for any of these code injection apps and app simply shuts down if it detects any suspicious apps running?

Perhaps, but it 's easy to defeat. One can simply pause the app, inject, dump the code, make an agent to remove the check, inject the agent -> done.

Also, what about signing binaries? it wouldn't make any difference since the 'loaded' code can still be accessed in memory and they could just make an application that disables security through memory?

Indeed.

Generally, protection is a very hard problem due to the nature of the language.
 
Generally, protection is a very hard problem due to the nature of the language.
What about in comparison to C++, would the process be much more complex from injecting in C# compiled binary vs C++ binary?
 
Last edited:
What about in comparison to C++, would the process be much more complex from injecting in C# compiled binary vs C++ binary?

Yes. While the process remains the same, the entry bar is significantly lower in .net/java because you get readable source code to work with. That makes cracking/modifying/re-branding .net/java apps orders of magnitude easier than having to deal with obfuscated assembly code flow.
 
.. the entry bar is significantly lower in .net/java because you get readable source code to work with.
So if it's obfuscated, it would be just as complex to deal with as obfuscated C++ binary?
 
So if it's obfuscated, it would be just as complex to deal with as obfuscated C++ binary?

No, not at all. .net/java obfuscation has 2 problems:

  • It is quite easily reversed statically
  • When it 's not, you run the program and since it 's de-obfuscated in memory, you grab it from there by injecting your agent. More fuss this way, but still easy.

The key here is that you get the source code more or less intact. You can't do that with native programs, you get unusable (in terms of re-usability assembly code).
 
Major issue is that everyone uses the same licensing mechanism. In the end, everyone ends up with the same if(isLicenseValid) check. Move your important code to a server and render your software useless without it. Let's take for example a simple bot that makes twitter accounts, it would navigate to the homepage, signup page, request captcha and final step is to send the registration request. What would happen if you had a server which would send the registration request, and not the client itself? Cracking the client would be useless then, since it doesn't work without your server which can not be cracked since no one has access to it, other than you. The only negative aspect of this I can think of is that it'll be a little bit slower, but you will be 100% safe and won't have to worry about cracks. But don't worry about cracks, push frequent updates; offer quality customer support and people won't mind paying you.
 
What would happen if you had a server which would send the registration request, and not the client itself?
That wouldn't work out well in this particular case, since ether you have to use clients proxies on the server or use the servers IP. But this is a good approach, if there are no "critical" requests that require clients identity.
 
That wouldn't work out well in this particular case, since ether you have to use clients proxies on the server or use the servers IP. But this is a good approach, if there are no "critical" requests that require clients identity.

Nowadays proxies are required for every automating aspect, so I'd say that it doesn't really matter. But this was just an example, it doesn't have to be the registration request. The server could be getting a cookie which the client needs to finalize the registration, etc.
 
No, not at all. .net/java obfuscation has 2 problems:

  • It is quite easily reversed statically
  • When it 's not, you run the program and since it 's de-obfuscated in memory, you grab it from there by injecting your agent. More fuss this way, but still easy.

The key here is that you get the source code more or less intact. You can't do that with native programs, you get unusable (in terms of re-usability assembly code).

Is there any articles showing how to do this? I would love to reverse engineer
a bot that I have.
 
Just talk over SSL to your signed server and wireshark's pretty useless unless you can find the clients private key from program memory, in which case you can decode only half the traffic. A pretty big headache for any potential reverse engineer.
 
I'm just gonna leave this here

video

this guy makes a mockery of .NET applications.

Many of those attacks can be repurposed for other runtimes with reflection (Java, PHP, etc.), just the specifics are a little different. But even a native x86 app with a nasty (from a reverse engineers perspective) protector like Themida isn't immune to reverse engineering, it's just a case of making it not worth the cracker's time.

I use Phoenix Protector to protect my .NET applications, it's free and has good features like bytecode obfuscation to make decompiling unpacked applications to source a headache. For licensing I handle that myself.
 
But even a native x86 app with a nasty (from a reverse engineers perspective) protector like Themida isn't immune to reverse engineering, it's just a case of making it not worth the cracker's time.

Of course. The problem in my view isn't cracking the app - although it 's much much easier in .net. The problem is getting the source code and re-purposing/selling the app. You can't do that with native code.

I use Phoenix Protector to protect my .NET applications

Which is publicly reversible. ;) So what 's the point besides telling yourself you did what you could regarding protection? :)
 
Last edited:
Of course. The problem in my view isn't cracking the app - although it 's much much easier in .net. The problem is getting the source code and re-purposing/selling the app. You can't do that with native code.

Not entirely true, if you can get a good enough knowledge of the application you can inject your own replacement GUI pretty easily. Or you can strip out the tasty, useful algorithms and fixup the memory references and make yourself a DLL with the sections of compiled code. If the GUI content is based on the resources section of exe then editing that is very simple. Still you are correct that it's much easier in .NET


Which is publicly reversible. ;) So what 's the point besides telling yourself you did what you could regarding protection? :)

I haven't seen any attacks against 1.9, only older versions. Do the old attacks still work?

Ultimate software protection in my opinion is remote, necessary, unique-data-for-every-request processing by your server. I used that in a completely unobfuscated PHP script once, never got broken and the rest of code was open source for others to tweak to their needs :) In my eyes this the best solution for everyone, near perfect software freedom but still giving you rights management, but you gotta have your server doing things that are hard to find out! Obviously this style has its drawbacks and isn't suitable for every situation.
 
Not entirely true, if you can get a good enough knowledge of the application you can inject your own replacement GUI pretty easily. Or you can strip out the tasty, useful algorithms and fixup the memory references and make yourself a DLL with the sections of compiled code. If the GUI content is based on the resources section of exe then editing that is very simple. Still you are correct that it's much easier in .NET

Yes, but first you 'd have to unpack it. And if it uses a VM protection like in the case of Themida you mentioned, that 's really hard work. The knowledge bar is raised very very much in contrast to .net reversing (and so the risk is minimized accordingly).
I haven't seen any attacks against 1.9, only older versions. Do the old attacks still work?

I haven't tried, I suppose you 'll have to test :)

Ultimate software protection in my opinion is remote, necessary, unique-data-for-every-request processing by your server.

Indeed.

Obviously this style has its drawbacks and isn't suitable for every situation.

Indeed again :)
 
Just thought of a neat way of doing things re: server side code, assuming you were creating a bot of some kind making HTTPS requests (a pretty common thing!), you could just have your bot client act as an SSL proxy in between your server and the target server, that way the client never knows what is being sent to the target server, but your server is never connecting to the target server, only the client. Definitely gonna have to play around with this today to see if I can make it happen!

Edit: Even for unencrypted connections, you could just pipe the traffic through a Tor exit node so it's still SSL/TLS that the client is forwarding.
 
Last edited:
you could just have your bot client act as an SSL proxy in between your server and the target server

Since the server is doing all the work, why bother tunneling it through the client?
 
Back
Top