Latest / DevQuestions with Tim Corey / 030 How do I prevent the user from de-compiling my C# application?

Transcript

030 How do I prevent the user from de-compiling my C# application? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:26
  SPEAKER_01: How do I prevent the user from decompiling my C Sharp application?
• 0:30
  SPEAKER_01: This is a question that's asked quite a bit, actually.
• 0:33
  SPEAKER_01: Um, but in this case, Lupus Rex was the one asking on YouTube.
• 0:37
  SPEAKER_01: And so let's get into how do you do that?
• 0:40
  SPEAKER_01: How do you prevent your code from being stolen once you publish your application?
• 0:45
  SPEAKER_01: And the first thing I talk about here is desktop versus web.
• 0:50
  SPEAKER_01: There's a bit of a difference here between the two.
• 0:53
  SPEAKER_01: If you are create a website, most likely you're controlling the server that it runs on.
• 1:01
  SPEAKER_01: Therefore, there's no need for any kind of protection for your source code because it's all on your server.
• 1:09
  SPEAKER_01: Even the code that that might run on, let's say, Blazor server where it's sending part of the code down to the client, that's not a problem because your secure and safe code is still secure and safe on the server.
• 1:26
  SPEAKER_01: Now, if you have a fully client-side application with Blazor WebAssembly, then all of that C sharp code is going to be on the client.
• 1:37
  SPEAKER_01: You really can't obfuscate obfuscate that or protect that from decompiling anyway because it runs in the browser.
• 1:46
  SPEAKER_01: It's essentially the same as Angular, React, or View applications where the entire source code is available and visible.
• 1:55
  SPEAKER_01: You can do some stuff to try and make it a little harder to read, but at the end of the day, it's still available for anyone to see.
• 2:02
  SPEAKER_01: But in those circumstances, you're still talking to a server side of some kind to get your data.
• 2:10
  SPEAKER_01: And that's where the security comes in, and the you know, proprietary stuff can be behind your API.
• 2:17
  SPEAKER_01: So even there, that's not really a problem.
• 2:20
  SPEAKER_01: Where you get into more of a problem is in desktop applications or services or web applications where you're distributing the web application to a client.
• 2:32
  SPEAKER_01: So let's talk about what you do in those circumstances to protect your code.
• 2:38
  SPEAKER_01: And the first thing I want you to remember is that you're never gonna fully protect your code.
• 2:45
  SPEAKER_01: I know that sounds hard.
• 2:47
  SPEAKER_01: Um there's always a way to decompile an application.
• 2:52
  SPEAKER_01: Always, because your computer has to execute that application.
• 2:56
  SPEAKER_01: So even if you rewrote it entirely in assembly language and even try to encrypt that, it still has to be read by your machine or the user's machine.
• 3:07
  SPEAKER_01: Therefore, there is still a way to decompile it.
• 3:10
  SPEAKER_01: The operating system still has to read it.
• 3:13
  SPEAKER_01: So we're talking about here not fully stopping the decompilation process, but limiting that process.
• 3:23
  SPEAKER_01: And that's the first thing to understand is there's a difference here.
• 3:27
  SPEAKER_01: So what are the problems with obfuscation?
• 3:31
  SPEAKER_01: Because that's one of the possibilities, is there's obfuscator and other tools that will obfuscate your code.
• 3:37
  SPEAKER_01: And if you don't know what that means, essentially when we write code, we write code read by humans.
• 3:44
  SPEAKER_01: So we do things like a um, you know, greeting method.
• 3:50
  SPEAKER_01: Well, what is that method do probably?
• 3:52
  SPEAKER_01: It probably greets the user.
• 3:54
  SPEAKER_01: And we have other methods like close out application method.
• 3:58
  SPEAKER_01: What do you think that does?
• 3:59
  SPEAKER_01: It probably closes out the application.
• 4:01
  SPEAKER_01: And so you can read through our code and understand what's going on.
• 4:05
  SPEAKER_01: A obfuscator will take those methods and rename them as method A and method B.
• 4:12
  SPEAKER_01: That's a little hard to understand what's going on because even inside there, there's variables.
• 4:18
  SPEAKER_01: Well, instead of first name and last name, it's variable A and variable B and variable C.
• 4:24
  SPEAKER_01: That's really confusing.
• 4:25
  SPEAKER_01: And so that's the kind of the point of obfuscation.
• 4:29
  SPEAKER_01: It's not to encrypt your code or to fully protect it.
• 4:34
  SPEAKER_01: What it's there to do is make it really hard to understand.
• 4:38
  SPEAKER_01: And the harder your code it is to understand, the harder it is to reverse engineer.
• 4:44
  SPEAKER_01: So there are tools that will help you go the opposite direction.
• 4:49
  SPEAKER_01: So just note that obfuscation is possible, but it's not the full solution, at least not for fully protecting your code.
• 5:01
  SPEAKER_01: So don't think because you obviously obfuscate your code that your code is 100% protected.
• 5:07
  SPEAKER_01: The other problem with obfuscation of code is when you're trying to debug a problem.
• 5:14
  SPEAKER_01: Because if your problem is in production, you have a weird problem.
• 5:20
  SPEAKER_01: Your error reports, you see a stack trace, you'll see, okay, method A called method C, which called method B, which had variables A, B, C, D, and E in them.
• 5:30
  SPEAKER_01: And you're like, I don't know.
• 5:33
  SPEAKER_01: And depending on your obfuscator, you may get some tools to help reverse that, where you um you know run it through a filter and that changes the stack trace back to the original calls.
• 5:45
  SPEAKER_01: Those can work or they cannot, it depends.
• 5:48
  SPEAKER_01: Um, and you have to manage those files as well to make sure you have the right file for the right deployment and so on.
• 5:55
  SPEAKER_01: So there's things you can do there, but that does make your life a little harder, especially if using third-party tools to capture your error reports, which might not work as well with the reverse engineering process.
• 6:09
  SPEAKER_01: So there's also the idea of some other third-party tools that that seem to encrypt your code or otherwise protect your code.
• 6:20
  SPEAKER_01: Here's the deal.
• 6:22
  SPEAKER_01: Your code, like I said, is always gonna be reverse engineered.
• 6:26
  SPEAKER_01: But your goal is not to stop reverse engineering.
• 6:31
  SPEAKER_01: I know it sounds weird, but your goal is to prevent easy reverse engineering.
• 6:38
  SPEAKER_01: Let's think for a moment, if you didn't do anything to your code, so your code gets compiled.
• 6:43
  SPEAKER_01: There are decompilers out there that will help decompile DLLs back to C sharp code.
• 6:50
  SPEAKER_01: But even if you ran those tools, they're not perfect and they're not full.
• 6:56
  SPEAKER_01: And so what would happen is I got an experiment for you.
• 7:00
  SPEAKER_01: Why don't you try to take an application of some size that you built, compiled, now try and decompile it and create a new application, a new executable based upon that code.
• 7:12
  SPEAKER_01: You can do it, but it's gonna take you a little more time than you'd think.
• 7:16
  SPEAKER_01: And that's what we're talking about here is how much time and effort does it take?
• 7:21
  SPEAKER_01: Because let's just say you put an application out there.
• 7:25
  SPEAKER_01: Um, let's say it's a to-do list, very, very simple application.
• 7:28
  SPEAKER_01: You create a to-do list, you're gonna sell this application.
• 7:31
  SPEAKER_01: And so you you create it, maybe even put um use a third-party tool like Paddle or something else, where you put um some kind of key on it where you have to have a security key in order to unlock the full features and use it and make sure they have an account and they have paid for it.
• 7:49
  SPEAKER_01: And then someone comes along and says, I know I'm gonna do, I'm gonna reverse engineer that to-do list.
• 7:55
  SPEAKER_01: And they take that and reverse engineer it.
• 7:57
  SPEAKER_01: And they build a whole new application, they spend however many weeks it's gonna take to reverse engineer that application and rebuild it.
• 8:05
  SPEAKER_01: And they do that, and they take out the piece that talks to your authentication server or your um your key server, so there's no more restrictions on unpaid users.
• 8:18
  SPEAKER_01: But then you come out with version 1.1, where you add a new feature or you fix a bug.
• 8:25
  SPEAKER_01: They don't get that.
• 8:27
  SPEAKER_01: In order to get that, they have to reverse engineer your new application and figure out all the changes and move them over to their application.
• 8:37
  SPEAKER_01: And then you come out with a new version, and they have to do the same thing all over again.
• 8:42
  SPEAKER_01: And so the amount of work it takes to do that really isn't worth it for most things.
• 8:49
  SPEAKER_01: And that's what it really comes down to is how much effort is worth it.
• 8:56
  SPEAKER_01: I have to deal this a lot with my courses.
• 9:00
  SPEAKER_01: If you don't know, I you probably do, but if you don't know, I sell courses on imtimcorey.com.
• 9:07
  SPEAKER_01: It's similar to what I do on YouTube, but it's a lot more comprehensive, and there's a lot more, you know, um, a more cohesive whole to a series of videos that are all focused around a topic or a section.
• 9:21
  SPEAKER_01: For example, I have the foundation C sharp series.
• 9:24
  SPEAKER_01: That's 40 plus hours, 145 videos or so that takes you from knowing nothing in C sharp all the way through kind of a junior level developer, maybe even mid-level, depending on how you practice.
• 9:36
  SPEAKER_01: Well, I sell those courses, but someone could take those courses and sell them illegally.
• 9:44
  SPEAKER_01: And people have.
• 9:46
  SPEAKER_01: And you might say, well, Timmy, you gotta protect that.
• 9:49
  SPEAKER_01: And yeah, I do, but I have to balance that with how much I make your life miserable as the paying customer.
• 9:59
  SPEAKER_01: If you pay for, legitimately pay for my course, I don't want you to have a hard time.
• 10:05
  SPEAKER_01: I don't want to have you to go through hoops and all these security lockdowns, you know, to you know, make sure you're you and make sure I have the DCMA or whatever, you know, security on all my videos so that um, I don't think it's DCMA, but anyways, have all the security stuff on my videos so that you know it makes it so hard for you to watch the videos you bought just because I want to make sure that someone doesn't get it for free.
• 10:31
  SPEAKER_01: Because really, those will get cracked too.
• 10:34
  SPEAKER_01: And so I'll make your life miserable and I won't really stop many people.
• 10:40
  SPEAKER_01: And so what I do is I try and make it a little bit more difficult than just falling off a log in order to get my stuff.
• 10:49
  SPEAKER_01: You have to do a little bit of work in order to get my courses for free.
• 10:54
  SPEAKER_01: But if you're doing that point, you know what?
• 10:58
  SPEAKER_01: I can't help that.
• 11:00
  SPEAKER_01: I can't make you ethical, I can't stop you from stealing from me.
• 11:05
  SPEAKER_01: But it is what it is.
• 11:08
  SPEAKER_01: It at the end of the day, it's it is hurting my business, but not a ton because they probably wouldn't buy it anyway.
• 11:15
  SPEAKER_01: Um, but maybe some people would, and so I'm losing some money.
• 11:19
  SPEAKER_01: But I don't want to hurt the people I'm trying to help.
• 11:22
  SPEAKER_01: And so when you're looking at your software, don't hurt the people who are paying for your software in order to try and prevent one more person from stealing your code.
• 11:34
  SPEAKER_01: Someone's gonna do it if it's at all valuable, someone's gonna find a way to steal your code, it's just gonna happen.
• 11:41
  SPEAKER_01: But you can do certain things to prevent it.
• 11:44
  SPEAKER_01: Obfuscation is not a bad thing if you really think you need it.
• 11:48
  SPEAKER_01: But for me personally, I don't use obfuscation that often, even in paid products, because I think it's too much of too many hoops to jump through.
• 11:59
  SPEAKER_01: I will use licenses and license keys as long as they are simple and not obtrusive.
• 12:07
  SPEAKER_01: That's a big deal for me.
• 12:09
  SPEAKER_01: So I encourage you to thinking about reverse engineering your application.
• 12:14
  SPEAKER_01: First of all, your application probably isn't life-changing.
• 12:20
  SPEAKER_01: I I I don't want to mean that in a derogatory manner, but if you're gonna have a hundred people buy your application, you don't need security on it.
• 12:31
  SPEAKER_01: It's only if your application is sold to 10,000 or 100,000 people that you think about, well, maybe I should think about at least raising that barrier to um making it a little harder to get my application source code.
• 12:48
  SPEAKER_01: Or if your application is going to bring in hundreds of thousands of dollars.
• 12:51
  SPEAKER_01: Maybe think about that at that point.
• 12:53
  SPEAKER_01: But at the same time, if you're getting to that point, then maybe what you should think about is having a secure API that gives part of your application information.
• 13:04
  SPEAKER_01: And then even if they stole all your source code, it wouldn't matter because your business logic or your certain pieces are behind a secure API that they have to have a legitimate login to.
• 13:17
  SPEAKER_01: There's things you can do.
• 13:19
  SPEAKER_01: Okay.
• 13:20
  SPEAKER_01: So don't get overly caught up on obfuscation of code or encryption of code or licensing, all that kind of stuff.
• 13:30
  SPEAKER_01: Start small, start simple, and remember who your clients are and make sure you take care of them before you try and prevent other people.
• 13:41
  SPEAKER_01: Take care of your paying clients and make their lives easier rather than make their lives miserable in order to prevent one person from stealing your code.
• 13:50
  SPEAKER_01: Okay, that's my thoughts.
• 13:52
  SPEAKER_01: Thanks to the question lupus rex.
• 13:55
  SPEAKER_01: Um, and if you'd like your question answered in a series, either use the form of the podcast page on I amtimcorey.com or leave a comment on the YouTube video.
• 14:05
  SPEAKER_01: As always, sharing this episode is appreciated.
• 14:09
  SPEAKER_01: Thanks for listening.
• 14:10
  SPEAKER_01: As always, I am Tim Corey.
• 14:12
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 14:15
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 14:19
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
• 14:26
  SPEAKER_00: You can also send your questions to questions at Iamtimcorey.com.
• 14:31
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 14:38
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to IamtimCore.com and enroll in a course.