 High protection, how not to implement the license-protecting in the dotnet system? Hi, so current talk is about the implementation and how to not to implement the protection of intellectual brokerage in dotnet systems. So we'll talk about some approaches and let's see. So who am I? I'm a security research manager at Spadio Labs in Trusweb. It's a great place, recommender. Before, I worked in a check mass as a security lead and software architect. And before, many years ago, I worked in Elbit at the Dianato system. Today's topic is not related to VALF and web security. It's something different. It's all about dotnet. More specifically, it's about intellectual property. As some of you know, dotnet is a funny acronym that can be easily translated into IPNOW by Google Translate. If you translate, for example, in this way. Actually, all dotnet can be easily translated to dotnow in the sense of application security and keeping your secrets. So the purpose of current talk is actually the impossible mission. It's how to protect the valuable information in dotnet code. Dotnet platform is a very good choice for algorithms, for prototyping, for rapid development, for many other cases, but not so suitable for storing your secrets. In order to show how system itself makes the attacker life much easier. So what is valuable information and why it's impossible to protect. So I put here some secrets that can be found in code sorted by potential damage to your business. So source code and algorithms. It's painful if it leaked, but it's not catastrophic in most cases. Worse if system restrictions, limitations, hidden abilities are leaked. More worse when a URLs and database connection stream is available to the attacker. And, of course, passwords, keys for symmetric encryption, any sort of hard-coded strings that can lead to certificates or private IDs or keys, can be placed in your code only for hackers' pleasure. Also, license enforcement, strict limitations, also the very important secrets that could remain secret. And why it's impossible? Mostly because of architecture and philosophy of dotnet. Everything dotnet is open to investigation and to easy investigation. And even the worst is easy investigation by free automatic tools that can be downloaded from GitHub. On deployed system that's already compiled and deployed, you can see the code, metadata, system calls, call tables, memory, heap, strings, and everything. And you can do this with simple tools. By looking to the structure of data and to the heap, you can see real values of class instances and variables and see strings in drift text. Also, you can inject code into compiled pointers and change behavior of the system on the fly or almost on the fly. So, why we can go to fight anyway? Because we can make the attacker work harder. Let's see a short example. So, continue later to show some examples. So, why we can talk about impossible protection? Where we can start when we can stop? System protection and hacking is a set of economic questions. So, just effort or revenue equation. So, there are a few questions here. Is hacking your system will give economic effort or economic value to attacker? What's the revenue? And is the revenue is good enough to attacker for asking effort? And how much resources the attacker must invest to hacking your system? And how easy to reproduce a breach? Also, how long it will take to you to know that system was compromised and understood the real amount of damage? How fast you can respond and keep the holes? And when you can answer all these questions, you can go with your dotnet system to the jungle or to the market. So, how we can protect the property in this jungle? Here, I want to show some basic approaches. The basic approach is very simple. Let's use obfuscation. Obfuscation is standard tool. There are many different free or almost free tools that can do obfuscation. It's easy standard. It can be applied without changes. But wrong. The interface are not obfuscated by most tools. Even by sophisticated tools when you do obfuscation only on part of your code. So, many of interface remains open. It can be easily found and updated by hardware. At least, you need to change your interface before obfuscation. And the obfuscation tools can be downloaded from GitHub and easiest to use in obfuscation. I will try again to show some samples with the screen. I have some issues with this. So, for example, a very simple tool that most of you already know, I'm sure. It's Il's Pi that I put here in my compiled binary. It's compiled in the release mode. And by investigation, this exam, you just can see all code in lyrics. In secret algorithms, test of license, for example, some button, they check the license. Let's see what this sophisticated system can do. Just test for license. Let's test what we will see in obfuscated code. So, I do some basic obfuscation. Try to open the same tool again. Let's see what's the difference. And obfuscation really helped me. As you can see, almost remains the same. I continue to see my code. It's a little bit obfuscated, but not too much. So, it's not stopping to understand what happens. You just see the code. And you can update it. You'll see later how we can update obfuscated code and change behavior of the system. Obfuscation, that not all obfuscator can do correct string encryption. And in most cases, every string includes URLs, keys, and connection string remains open to hacker. So, sometimes it's almost open and can be easily decrypted by analyzing the obfuscated code. Algorithms can be easily transferred to CEPDA code and analyzed also. As we can see here, back to the example, how we can analyze the code, how we can analyze encrypted code and understand exactly what the algorithms do. So, it's only a change that we see in encryption in obfuscation is the name of the variables and sometimes the names of internal interfaces. But it's not too problem for us to understand what happens. For example, I will try to update the system. So, I invoke standard disassembly from my Microsoft. It's located in a Microsoft SDK. It produces assembly code. I just will search for license string and we will try to update it without deposition. So, this looks like some license test. So, we can see in assembly, for example, license is okay or license is wrong. So, we can just put here, you see it's address of flow with license okay. Save and recompile. It completes successfully. It's produce application to put delays here. Because the license delay is not affected by this. I need to put it in the same folder to run. Wow, nice. We have a license. So, we put some assembly change in obfuscated code. And without affecting the sophisticated license delay, it's only affected only call to this delay. When we use tools, for example, D4. It's a well-known tool for decompilation. We can return it back almost any kind of application. I just show. You can see from... So, I try to depuscate the obfuscated version of my binary. Now it's depuscated. Put in some place this folder. It's getting cleaned. So, we'll return to ill spy. Let's see that all our code is returned. So, magic not work with the spy. But as you see, you can work without this. So, some problem with the tool probably. Let's continue. I have something in addition to say. So, as I say, everything is possible to change even after obfuscation. At least simple obfuscation is not issue for attacker. And what is the solution? Maybe we will do double obfuscation. Obfuscate twice with same tool. But it will not work. This can use the defuscator twice. So, if you want to use obfuscation, use different tools in line. And I will show how. And there is the ultimate weapon against all kinds of obfuscation. When attacker can build his own library with your interfaces in all code in interesting functions. It contains test for license, for certificate, for keys. Other function can be bypassed to original binary. It's kind of a delay in the middle solution. It will not be shown here due to some problems with the presentation. But it can be an ultimate killer of obfuscation. And what's about internal delay with C code is that it cannot be easy to deassembly C code in GLLs. So, the problem is that you must call this GLL from somewhere in .NET code. And these places can be attacked. And in addition, it will not prevent the memory mapping and heap investigations on these places. This option can help a little bit with hitting the algorithm in some of the business logics. It will not help so much with license enforcement. Some basic approach is put here in one slide. It's some kind of dialogue of a developer with a hacker. So, an important GLL is seen. Is it enough? So, the hacker can ask if you test who is the signer of the GLLs. Okay, we're adding test for Signer also. As is Signer ID is hard coded, it can be nice. So, we can retrieve the private key or just can affect your code and insert our key. So, you will test for my signature and not for your signature. Okay, we will limit encryption, obfuscation of all these functions. But that attacker can replace all functions than test for license with his own function in a simple place, a simple way as we see by editing even in notepad. So, we can encrypt everything obfuscated and sing it with certificates. So, it will be some pain to maintain the system with total encryptions, but it can be solution. But the attacker can search for use of a crypto API in GLLs and figure out what GLL can be attacked or what GLL must be attacked because we will not use crypto GLL in every place. It probably will be only in interesting places to attack it. So, what we can do? Actually, we can start with not to do. We will not store everything, anything hard coded. No password, no keys, no connection strings in code. Everything that you have in code can be analyzed or sometimes it can be replaced by a hacker. And when a system will be compromised, it will be hard to change the code again and to push the updates to all customers. It depends of your system, of course. Don't do single point of security check. Maybe it's one of the single cases when copy-paste in your code is allowed. Just do many point of security checks. Additional don't do is a... Remember, when you build your secrets dynamically and store in simple form in the memory, it also can be stolen and can be investigated. So, do something more complicated and use crypto libraries to store secrets. For example, crypto strings instead of strings and so on. In dotnet world, all memory is accessible with easy by simple tools. When you smash the secret between your code and date so we do some self-dostatic calculation to store the key, it's only illusion or defense. It doesn't change anything. Your secret key is still available in the memory. Or when an attacker will gain access to your code after deposition, you can just run the same code and get access to your hidden key. So, don't do smash of secrets in the code. Anything can't do it. So, what we can do? So, add extra calls for encryption API into license testing in every place in your code even when it's not needed to complicate the automatic search. This will add extra work to attacker. Add random keys and suspicious strings into your code but not your string but not your code information. So, use a randomization key just place it in your code the attacker will spend time to analyze it and to multiply the security checks. In this case, as a former software architect I can say to you, this is the place when you can do copy paste, multiply your test. And important, try to break into a system by yourselves. Do it before the hacker door. So, use strong encryption. Don't produce encryption for yourself. It's a lot of good tools in the market. So, do strong encryption and stronger randomization. And implement and use the revocation mechanism for keys and for certificates. Be responsive to creaches. And use more sophisticated, more complicated protocols than use of functions with protocols whose name is license OK. It can be hacked too easily. As you've shown, even on a sophisticated code it can be found easily. So, use something more complicated to ensure license policy. And add strong digital signature to all DLLs in the system to all binaries and every time check it. Not only on startup time, check it periodically even when you don't need it exactly. This will prevent or add additional effort to attacker to replace the DLLs or to analyze it. And check the signature and signers ID every time. But not by storing them in the code. And be able to update the security mechanism without code updates and without the installation of the system at customer side because it's not possible in most cases. It will allow you to be responsive to possible breach quickly. And yes, you can use different frustration tools at once, one after other but using the most able mode each of them. You can use, for example, dot full scatter with most able mode and after dot full scatter use dot reactor, for example, with his most able mode everyone with his own string encryption and call flow obfuscation. It will not give you unbreakable system but analyzing and breaking into this system will be much, much harder. So maybe you will be not economically. For example, I try to show what the reactor can do after when it works on obfuscated DLLs it's again to the pain of this screen. The additional obfuscation tool as you see, this code is... we cannot obfuscate... we cannot analyze with Hill Spy at least we need more sophisticated tools to understand what happens here. It's not impossible to understand because some interfaces remain open and sometimes it also can be analyzed but again not with this tool it's more sophisticated. But when you use inline for example, dot full scatter with most encryption and after this you will use reactor with most encryption it will make attacker work much, much harder so maybe it will turn the breach into non-economical. Take too many resources to breach and when you will be able to update the systems quickly you will need to breach again in some places. So almost finished the talk and thank you for watching us and for quit snoring. Here is my contacts. Now I'm working in security research not so close to dotnet working on both application firewall and web server security you see my contacts happy to meet you after the meeting. Thank you.