---
title: "Jon McCoy -- The Mindset to Reverse Engineer"
url: https://appsecpodcast.com/jon-mccoy-the-mindset-to-reverse-engineer/
date: 2016-12-21
duration_seconds: 1530
guests: ["Jon Mccoy"]
topics: ["Conferences and Community"]
audio: https://www.buzzsprout.com/1730684/episodes/8122725-jon-mccoy-the-mindset-to-reverse-engineer.mp3
transcript: true
---

# Jon McCoy -- The Mindset to Reverse Engineer

*December 21, 2016 · 26 min*

with [Jon Mccoy](https://appsecpodcast.com/guests/jon-mccoy/)

on [Conferences and Community](https://appsecpodcast.com/topics/conferences-and-community/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122725-jon-mccoy-the-mindset-to-reverse-engineer.mp3)

## Show notes

How does a developer learn to take software apart and use that knowledge to build it more securely? Jon McCoy joins Chris and Robert to discuss reverse engineering, the habits of a breaker, and the connection between offensive research and everyday development. He explains what reverse engineering means, describes experiments with malware and .NET applications, and shows how familiar practices such as unit testing can incorporate security thinking. The conversation explores framework protections, how much coding knowledge penetration testers need, and the role of local developer and security communities. Jon’s advice for newcomers is practical: choose an application, inspect how it works, and learn by experimenting. The episode emphasizes curiosity and repeated hands-on work as foundations for deeper software understanding.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Jon Mccoy:  
→ [Jon McCoy on X](https://x.com/thejonmccoy)  
→ [Jon McCoy on GitHub](https://github.com/theJonMccoy)

Mentioned in this episode:  
→ [NDC Conferences](https://ndcconferences.com/)  
→ [DEF CON](https://defcon.org/)  
→ [Metasploit](https://www.metasploit.com/)

Chapters:  
00:00 Reverse engineering with Jon McCoy  
01:53 Why a developer became interested in security  
02:27 What reverse engineering means  
03:24 Teaching security through familiar developer practices  
04:06 Adding security thinking to unit tests  
05:00 Malware experiments and the breaker mindset  
07:56 Helping others learn to break software  
11:22 Security in the .NET framework  
14:39 How much code should a penetration tester know?  
17:45 Learning through developer and security communities  
19:47 A first month of learning to reverse engineer  
21:26 Resources and hands-on experimentation

## Transcript

*4,345 words · assemblyai*

**0:05 Robert Hurlbut:** The Application Security Podcast. Here we go.

**0:10 Chris Romeo:** Hi friends, this is Robert and joining me is Chris, and today we're going to be talking to John McCoy. He is a developer turned security person in the last number of years and he's been helping developers understand more about security. In this podcast, we're going to talk to him about reverse engineering malware, talk about some .NET security, and other topics. So join us. So today we have John McCoy with us to talk about security, developer security in particular. So thank you, John, for joining us. So, you know, one of the things we like to do when we get started is in these podcasts, we'd like to ask the person that we have on to tell us their superhero origin story, which essentially means, you know, every superhero has a story. And so we'd like to ask, you know, how did you get started in this? Well, tell us a little bit about your background.

**1:21 Jon Mccoy:** Yeah, I definitely started as a developer, and I was doing HIPAA regulation coding backend, and my eyes were kind of bleeding. And some of my friends showed me what security was, and I kind of ended up going to the research lab and staring at what could really be done in the security side and just It seemed like the next evolution of coding techniques, being able to interact with programs on a deeper level. Just got hooked.

**1:53 Chris Romeo:** Great. So what was it about security in particular that was interesting to you as a developer? I mean, did you start out just writing regular— I mean, what do you call regular code? But doing applications and things like that. What was it that got you, hey, I want to look at more and think about this and apply security?

**2:12 Jon Mccoy:** On my own, I had always kind of been into reverse engineering and that kind of thing, but I actually didn't have— I didn't know it was a thing. I didn't know it was a security technique. And once I got into security, I found out that I was a powerhouse. Like, in development, I thought I was a weirdo.

**2:27 Robert Hurlbut:** Hey, John, you mentioned reverse engineering. So just so our audience knows, what is reverse engineering?

**2:35 Jon Mccoy:** It's looking at a previous application. So like when you look at an HTML webpage and you see the HTML for it, you can learn how to do that. I did the same thing with applications. So I pulled apart Microsoft applications to find out what was inside of them, what were the APIs they were using. And I actually learned coding from pulling apart other people's programs and looking at the source code some of the time, but most of the time it was just the bytecode inside of it, the almost the DNA of the program.

**3:03 Robert Hurlbut:** Okay, so it's, it's taking somebody else's software, picking it apart and understanding how it works. That's, that's what's happening when someone does reverse engineering.

**3:14 Jon Mccoy:** Yeah, and for developers, I would almost say it's doing a code review forcibly on someone else's application against their will.

**3:21 Robert Hurlbut:** Against their will, okay.

**3:24 Chris Romeo:** Tell us a little bit about this idea of the developer-focused security. When you were applying all these— in fact, we've talked about it a little bit before, but I think that's been part of your career, right? Trying to help developers understand not only what you did, but how to help them do the same thing. Is that right?

**3:42 Jon Mccoy:** Oh yeah, especially when I do corporate trainings, it's often focused at hardening their teams all the way from security, but to their development staff. And the more I got into security, I found that a little bit of security knowledge or doing something slightly differently at the developer code level, architecture level, could yield huge security bonus.

**4:06 Chris Romeo:** Okay. How did you help them to understand, for example, I've written lots of unit tests testing all kinds of things. How did you help them to understand the difference between a regular unit test and applying security into that unit test? What were some ways you helped them with that?

**4:21 Jon Mccoy:** Sure. I would bake it from the concept of the story level where you're doing a unit test for maybe a SQL record push, but we can do a unit test for SQL injection. it can test the same thing. And when an intern comes in and adds SQL injection back into the program, the unit test now breaks, and it's in that minutes to get the fix turned around. At the next level, it's typically some sort of accessing resources without authenticated privileges or that kind of thing, and just rolling in security unit tests using the same vernacular that developers are used to.

**5:00 Chris Romeo:** Right. Okay. That makes sense. I like that. So just thinking about also some other things that you've done in your career, I know you've done some defense type of programming, defensive type of programming, but you've also done a lot of breaker type of programming, right? And development and so forth. So tell us a little bit about that and in particular that mindset and how it may even apply to AppSec.

**5:22 Jon Mccoy:** Sure. I don't know if it was quite, applicable in market, but I started writing Frankenstein applications where I take 2 applications and intermingle their code and logic. So I'd take a piece of malware that is a CNC in Twitter's home, and I would embed it into the login sequence, login module to SQL Server Management Studio, and kind of take that malware and just hook it right into that core critical part of the application. for writing some software and trying to show that it's quickly doable and to give developers a place to harden against. So kind of rapidly developed, like 5 lines of code, weaponized payload.

**6:06 Robert Hurlbut:** So you had— wait, you had malware? So you took a piece of malware. I'm fascinated by this idea. You took a piece of malware and you decompiled it to the point where you could take an executable portion of the code and you embedded that within another application. So what was the main goal there? To try and get that— were you trying to get that malware code to run when somebody ran the SQL Server Administrator?

**6:31 Jon Mccoy:** Actually just took the DLL itself and didn't even decompile it and embedded it as a resource.

**6:37 Robert Hurlbut:** Oh, okay.

**6:38 Jon Mccoy:** Yeah. And then I hooked it in. So when the malware did like a reboot sequence, it would cause a change of password on SQL Server Management Studio and just proof of concept, like a testing harness. I also wrote the opposite. I wrote a hardening module to add 2-factor authentication and password retry attempts to harden SQL Server Management Studio as well, to show that you could arbitrarily add security on top of it as well as break security.

**7:07 Robert Hurlbut:** You're like a magician. You're just making things appear, making things disappear. That's pretty incredible.

**7:14 Jon Mccoy:** Yeah.

**7:15 Chris Romeo:** Yeah.

**7:15 Jon Mccoy:** And trying to get it to 10 or 20 clicks so developers could go home and watch the video and do it. I tried to make it really accessible.

**7:23 Robert Hurlbut:** And those are all free and open source also. You develop a bunch of tools, but those are free and open source so that anybody can go download them and try them out.

**7:33 Jon Mccoy:** Yeah.

**7:34 Robert Hurlbut:** Yeah.

**7:35 Jon Mccoy:** The repos are definitely up. They're hard to find, but it's definitely open source and free and It should always be free. I have no intention of ever converting it.

**7:43 Chris Romeo:** Wow, that's great. So tell me about— I mean, you did this. I mean, there was something that was interesting to you and you figured out a few things and saw what you could do.

**7:56 Jon Mccoy:** How would you teach that?

**7:56 Chris Romeo:** How do you help people, other people to do that very thing, that kind of breaker mindset? Do you have any thoughts on that?

**8:02 Jon Mccoy:** Yeah, I usually run people to kind of the core. I work in .NET a lot. .NET, C#. I run them to kind of the core level of .NET at the IL level and get them comfortable of looking at a program through, through the eyes of IL and look at functions and kind of that forensics approach of like dissecting it like a file table. Hey, John, what you have?

**8:27 Robert Hurlbut:** Hey, what's, what's IL?

**8:28 Jon Mccoy:** Intermediate Language. It's bytecode inside of the application. It's really quite powerful. It runs cross-platform, so you can take IL for Windows and put it on Mac, Linux, iPhone, Android, and have it kick off and run. If you write your malware or your security app in IL.NET, you can port it to any platform theoretically. Tunneling down through IL, look at that, and then take IL, put it in memory, inject in memory, and see the IL turn into assembly code. and then watch the memory space and the process get laid out. And then again, pull it apart like a file table and see what you have to work with and see that it's malleable. Applications and memory on disk are completely malleable and there's nothing stopping you from shifting into them and changing them however you see fit.

**9:18 Chris Romeo:** Wow. So those are some classes or courses that you teach.

**9:24 Jon Mccoy:** If someone wants to see them, they should check out Black Hat or DEF CON 18, 19 that I did some talks there. And most of the classes that I teach are defensive. The black hats don't pay a lot of money in normal training scenarios, but I feel better about teaching white hat security and getting paid. All of my black hat stuff, I try to keep it completely free and not make any money from it.

**9:47 Chris Romeo:** Okay, sure, makes sense. And you mentioned that you do a lot of work in .NET, and you also mentioned some things about— I think it sounds like some cross-platform Tell us a little bit about that and what you've been finding, and in particular, any security aspects of .NET. I mean, I'm very well familiar with that as well, been doing that for a number of years. Yeah, but tell me about your own experiences.

**10:08 Jon Mccoy:** I came out into .NET and it was kind of an open space in the security market back in the day and found my niche there. As far as security goes, you don't really have buffer overflows and a lot of those last-generation really lethal bugs have been mitigated almost completely away. Being cross-platform, .NET is your go-to if you want to build an iOS, Android app. It really is delivering the holy grail of build once, deploy everywhere. You can build your business logic, put it into Linux, migrate it over to a Mac, and be able to use the same codebase that you've been working with and testing deployed pretty agnostically.

**10:50 Chris Romeo:** Now, is that with the .NET Core stuff?

**10:52 Jon Mccoy:** Yeah, yeah. .NET's an open standard like HTML. It was developed as its core ethos to be any language in, any platform out, and it really is delivering. I've done embedded hardware modules to execute attacks and written it all in .NET all the way up the stack. And kind of my new weaponization is being able to embed like Metasploit payloads inside of .NET packagers and hybrid them together, which kind of came out of the blue for me.

**11:22 Robert Hurlbut:** I got a question. I got a question about just .NET security in general. So I think about the direction that Java's gone in in its lifetime and how Java seems to be resistant in the standard itself to adopting a lot of security things directly into the underlying libraries. What is your impression then of .NET? Is it the same type of a scenario or is .NET set up better at the framework level for security?

**11:56 Jon Mccoy:** It's a back-and-forth battle. .NET has been evolving, but I've been really impressed with it coming out with a security measure such as code access security, deploying it, seeing if there was ways to get around it, and then evolving in response. at the framework level. I'm quite impressed by it. I'm a fanboy.

**12:15 Chris Romeo:** Except that they dropped it. They dropped it.

**12:20 Jon Mccoy:** I know.

**12:22 Chris Romeo:** I think it was too difficult. That's all I— that's what I've heard is it was just too difficult. I remember the same thing. I remember teaching it. I loved it. It was the greatest thing. I applied it to a lot of different things, but it was very niche, it seemed to be, and just difficult for most people to get it right, essentially to get it right, because it was Kind of easy to get it wrong, it turned out.

**12:44 Jon Mccoy:** Yeah, and for all your listeners, it was in 3.5, a really good version of .NET. But yeah, .NET's really proven out to be pretty secure. It always has holes that keep coming up, but it seems like they're actually willing to make core framework changes, even breaking changes, in order to progress the security model. It seems like a pretty good community standard.

**13:06 Robert Hurlbut:** Yeah, that's good. That sounds different than what I've heard about the Java standard, and I'm not certainly on the inside of either, either. I'm just going by what I hear across the community. And so that's good news that this— the framework itself is thinking about security and they're, they're not resistant to doing things to make the environment more secure. Because I truly believe the framework is where it's at here. Let's make the frameworks as secure as possible and then everybody can take advantage of those things without— and we'll just teach the next generation of programmers that they won't have an opportunity to make some of the bad decisions that we can make today.

**13:44 Chris Romeo:** Yeah, and I agree. There are some things I know, even in my own research in .NET security, I know that, for example, on the website, the anti-XSS, things like that, that used to be a thing you went and downloaded and applied to your application, and now it's built into all the controls. So I agree, you know, the framework's where it's at. Framework's where it's at.

**14:09 Robert Hurlbut:** I should get a t-shirt that says that. The framework is where it's at. I'll sell like 3 of them.

**14:19 Chris Romeo:** So, go ahead.

**14:20 Jon Mccoy:** Yeah. When I was building tools, I kind of looked at how to build breaking tools to focus on things that were intrinsic to coding. So, not really taking advantage of the framework, but just being able to dig into an application and break it one by one. Yeah.

**14:39 Robert Hurlbut:** I got another question that somebody just asked me recently, and based on the fact that they asked me the question, they said, how much coding should I actually need to know as a penetration tester or a breaker? And so I'm going to flip the question back around on you because you came from the other side of this. So what's your take on that from the connection between being a solid developer and knowing the languages How in-depth does somebody have to go into the language to actually attack .NET?

**15:09 Jon Mccoy:** So if they're a breaker and they're attacking .NET specifically?

**15:14 Robert Hurlbut:** Yeah, sure.

**15:15 Jon Mccoy:** Depends on whether you want to be a tool jockey or like really write malware. But to do a penetration review, a penetration test, I would say with the tools, it's, it's very minimal to get to a functional level. To be, to be at a capable level, I think I would say you need to understand the different paradigms of coding. So like you have event-driven, you have object-oriented, you have reactive code, and that these are almost patterns of style that the coder will follow. And so if you know they're using an ORM, you know there are certain attacks that they, they might not be vulnerable to. And if you don't know what the ORM is, how they get used, their coding style, then it's kind of a a giant spaghetti mess. If you know they're using event-driven, then you know to look in a very specific area for how it's doing authentication and how it's doing validation. And so, I would say, like, the coding standards are key to being able to pull apart an application and do an assessment.

**16:17 Robert Hurlbut:** Does that mean you have to be able to write the code though? Like, how do you approach that?

**16:23 Jon Mccoy:** Just look at what people are griping about and common problems that their ORM are facing. Development is a lifelong pursuit. I'm a, I don't know, probably going on 20-year developer, and I still feel kind of like a newbie. So, it's as deep as you want to dig.

**16:41 Robert Hurlbut:** Yeah, yeah. That's why I like to talk to people like you because I like when people have that type of a perspective to say, I've been doing this for 20 years and I'm still trying to figure it out, because that's the bigger security community too. Anybody that tells you, Well, I'm a security expert. If I hear somebody say that, I'm like, uh, I want to get away from you before somebody knocks you over here because I've been doing this for 20 years and I don't consider myself an expert. I learn new things every day. I've learned 10 things on this call, on this podcast interview right now. I'm learning all these things about .NET. So—

**17:16 Jon Mccoy:** Okay.

**17:16 Robert Hurlbut:** We're not all— to say you're an expert is such a dangerous thing. And it sounds like you're the same mindset of let's just keep learning and keep growing as security people.

**17:26 Jon Mccoy:** Oh yeah. And I would definitely say for developers, community for security is where it's at. Come to an AppSec USA conference, come to a local White Hat meetup, and talking to the community is how I learned most of my security. And it's really a community-oriented skill set, I think.

**17:45 Robert Hurlbut:** That's good. So, you said AppSec USA, that's a, you know, from a conference perspective, that gives you a bigger, you know, that's a bigger stage. What, uh, what are some of the meetups that you, that you like to attend? Do you do just security ones or do you do developer ones or, or give us some direct examples if you would? I'm just curious as to where you, where you're spending your time from a meetup perspective.

**18:07 Jon Mccoy:** Sure. In the white hat space, I definitely think AppSec's where it's at, OWASP. And in the developer space in .NET, the one that I was most impressed with was the NDC, New Developers Conference. Uh, hosted over in Norway, London, Australia, and quite an impressive conference for developers and .NET. Yeah, 3 very different communities, Black Hat, White Hat, and Developer are completely different places.

**18:35 Robert Hurlbut:** Yeah, and I think that's really neat how you're moving between those. A lot of times we get, as a security community, we fall into that. People have been overusing this idea of getting outside of the echo chamber and all that, but it's true. Because a lot of times— and I actually went to, uh, I spoke at a software test professionals conference last year where there were no security people. It was just software testers. And I was like, this is the coolest thing because normally I go to conferences and I speak and I'm talking to all the people that already agree with me and understand what I'm talking about and they're just nodding their heads all the time. But I was at the software test professionals and I had some people that were kind of like, wow, vulnerability scanning, pen testing, this is kind of cool, tell me more. Instruct me more.

**19:19 Jon Mccoy:** Oh, yeah, yeah, that have never heard about a scan. And that's actually one of the biggest problems that I found when you're talking between different departments is they have completely different knowledge bases that, that if you go to developers and say, why don't you run a security scan, they'll just look at you kind of funny. And if you go to security people and say, hey, why don't you do a code audit and an architecture review, they just turn their heads and throw their hands up. That cross-functionality is definitely where it's at.

**19:47 Robert Hurlbut:** Yeah, definitely agree. So, kind of, so, so let's say that I was, well, I am somebody with limited knowledge of .NET other than what we've had in this conversation. So, if I was going to start getting involved or learning how to break .NET applications and I have no background in reverse engineering, very limited exposure to the language itself, What would you recommend that I do in the first month or first quarter? And are there any resources or anything you would point us to where I could go to start with a ground— kind of a foundational-level understanding of what you're trying to do?

**20:24 Jon Mccoy:** Sure. Poke around your own system and find an app that you care about, something like your VPN, your communication software, your messaging software, and pull it apart and see what it does. And if you're, if you're kind of new to coding, I would go over to CodeProject, and they have a bunch of projects where people describe almost line by line how they put together a code project and what it does and give you solid examples to work from. Check out my talks, DEF CON 18, 19. Um, Topher Timson just did a talk, uh, at DEF CON, definitely worth a a look, some great tools coming out. And I really say find something that you are passionate about pulling apart. So like if you're really interested for how they did a Twitter hook, then you can reach in and get that code and be able just to pull it out like you would pull it out from a web page. Learn from the programs you have on disk.

**21:26 Robert Hurlbut:** So is there any, any website or book or anything that you would recommend that would give me that foundational— you know, some people like to just get it all, they like to have the whole package, at least at an introductory level, all together in one. So is there any resource that you have recommended to other people in the past or that you would kind of point me in a direction for?

**21:49 Jon Mccoy:** There's Rootkit Security, I think, from Azrael Metazula. That was kind of interesting, but I've seen some books come out from .NET, but I actually haven't read them. Gray Hat Hacking, I think, came out for .NET. I found the most powerful tool is actual Visual Studio. Like, you can just drag a random executable into Visual Studio, like a DLL or executable from SQL Server Management Studio, and just start coding against it.

**22:19 Chris Romeo:** So it becomes kind of an API that you're calling then at that point, right? So you have all the the different classes and so forth, and you just start looking at it, right? And taking a look at what you can call. Is that essentially what you were doing there?

**22:31 Jon Mccoy:** You can drive a hook in with Graywolf and get back into it and actually run it inside of them. Yeah, yeah. And there's nothing stopping you. And an executable is the same as a DLL except for there's a flag set.

**22:43 Robert Hurlbut:** So, John, I just wanted to pinpoint one thing and kind of point this out for our listeners because You've gone back a couple of different times and said, as an answer to various questions, to load up an executable and pick it apart. And I just—

**23:02 Jon Mccoy:** Mm-hmm.

**23:02 Robert Hurlbut:** And I think that's great advice. I think I see that as that's how you are refining your skills, and you're almost encouraging the person, if you're really serious about this, go start doing it. Don't study it. Don't go to college for 18 years to become a licensed reverse engineer. Load it up in a debugger, load it up in the Visual Studio, whatever you have available to you, and tear it apart. And then answer the questions. Figure out a list of questions, answer them, tear it apart some more, write more, find and figure out more questions, and create your own answers. So, um, so that's, that's what I see. That's what I hear you describing to me. I think that's— and I think that's good advice. Do you have anything to add as far as that mindset? that you would want to instill in people?

**23:48 Jon Mccoy:** That's really good. I would say come and hit up community people. Like, I'm always happy to give back to the community, and I've done literally tens of thousands of free trainings. I've done as many free trainings as I can for developers, security people, basically anyone that will listen to me. So the community, there's a lot of, a lot of people that are happy to help.

**24:12 Robert Hurlbut:** Yeah, that's great. And that's, uh, so folks can reach out to you on Twitter. Your, uh, handle on Twitter is, uh, @TheJonMcCoy.

**24:21 Jon Mccoy:** J-O-N-M-C-C-O-Y.

**24:22 Robert Hurlbut:** Awesome. So yeah, so I would expect that some of our listeners will reach out to you and want to continue this conversation, but we definitely thank you for your time today and for educating me about .NET as well as the rest of our listeners. So Thank you very much, and we really appreciate it.

**24:39 Jon Mccoy:** Thanks for having such a good podcast. It really makes a good community. Thanks.

**24:45 Robert Hurlbut:** Thank you.

**24:46 Chris Romeo:** Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Boring and TJ, and the outro is Southern Delight by Stefan Kartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.com.

---

Source: https://appsecpodcast.com/jon-mccoy-the-mindset-to-reverse-engineer/