[00:00.000 --> 00:04.180]  Not just for security, but all the fun things you can do with binary analysis.
[00:04.960 --> 00:13.400]  And the idea of binary analysis is we are going to gather information about what a program does from the binary alone.
[00:13.800 --> 00:15.680]  We are not going to need source code.
[00:16.480 --> 00:24.420]  And the goal is to gather as much knowledge about what that program does as you would have if you had the source code.
[00:24.420 --> 00:31.340]  And once you can do that, binary equals source, and it's all open source.
[00:34.980 --> 00:37.600]  So, why would we want to do this?
[00:38.200 --> 00:46.500]  Well, one thing is proprietary software, the people who sell it rely on the fact that you don't know what the program is doing.
[00:48.140 --> 00:50.020]  So, there's obscurity here.
[00:50.160 --> 00:56.140]  Unless there's a way of telling what the program is doing for the binary, they have security by obscurity.
[00:56.320 --> 01:02.400]  They also do all kinds of things with that program that they might necessarily want you to know how to do.
[01:02.600 --> 01:04.340]  They need to get these lights, too, though.
[01:04.460 --> 01:05.280]  They're all signed.
[01:05.280 --> 01:15.500]  DRA licensing things, schemes come to mind, but things like spyware, a lot of monastic stuff happening on programs, and all that stuff is distributed by binary, of course.
[01:18.240 --> 01:24.640]  Another nice thing to do with binary analysis is see if someone has stolen your source code.
[01:25.440 --> 01:31.060]  If they've stolen your source code and put it in your program, put it in their program.
[01:31.180 --> 01:42.780]  It's typically very difficult, without sophisticated tools, to figure out that your algorithm, your routine, is in someone else's program.
[01:42.780 --> 01:52.240]  So, if someone is taking a GPL code and putting it in their software, it's relatively difficult to figure that out.
[01:52.840 --> 01:55.240]  With binary analysis, we can do it fairly quickly.
[01:57.780 --> 02:00.340]  Then, of course, there's a security vulnerability problem.
[02:00.600 --> 02:01.860]  How do you audit the binary?
[02:02.660 --> 02:06.540]  It's very difficult to do manually, tracing through with the debugger.
[02:06.540 --> 02:21.280]  So, if you have a binary analysis tool, which can basically convert that program into a model which is similar to the source code, with the same amount of knowledge as the source code, now you can start auditing that for security vulnerabilities.
[02:21.600 --> 02:25.300]  So, you can take a binary and do the same things you can do in a source code audit.
[02:30.940 --> 02:38.640]  Another reason you would want to do binary analysis is some stuff really has to be in a binary.
[02:38.900 --> 02:42.220]  Those are your things like your compiler.
[02:43.100 --> 02:45.420]  You need a compiler to build a compiler.
[02:45.700 --> 02:47.600]  You need a compiler to build other code.
[02:47.880 --> 02:49.660]  How do you know what that compiler is doing?
[02:50.400 --> 02:51.880]  It's a difficult problem.
[02:51.880 --> 03:02.940]  How it's probably the most interesting program to backdoor, which Ken Johnson did in the early 80s.
[03:03.720 --> 03:10.220]  He wrote a paper in 1985 on Reflections on Trusting Trust to talk about what he did.
[03:10.580 --> 03:15.740]  What he did was he wanted to backdoor the login program for units.
[03:15.740 --> 03:33.320]  But instead of just modifying the source code for the login program, which he thought would be detected rather easily, what he did was he modified the source code to the compiler, so whenever it saw the login program being compiled, it would insert a backdoor into the login program.
[03:35.300 --> 03:42.580]  He did this ostensibly because he was sick of system administrators asking him questions, and he wanted to just log into their systems to fix the problems.
[03:44.960 --> 03:46.260]  Ostensibly, that was his reasoning.
[03:46.620 --> 03:48.960]  So, I guess Ken Thompson was a hacker too, of course.
[03:51.280 --> 04:00.300]  So, what he did was he modified the compiler to put the backdoor in, and then he compiled that, and then he distributed the binary compiler.
[04:00.680 --> 04:05.900]  So, without binary analysis, there's no way to find this backdoor on your system.
[04:07.860 --> 04:09.160]  It's a very interesting paper.
[04:09.360 --> 04:10.900]  I highly recommend it.
[04:15.120 --> 04:17.880]  So, now I'm going to hand it over to DilDog here.
[04:17.960 --> 04:22.000]  He's going to go into some of the more technical details of what's going on behind the scenes here.
[04:26.920 --> 04:27.340]  Okay.
[04:27.340 --> 04:27.760]  Hello.
[04:28.260 --> 04:28.700]  Thank you.
[04:31.080 --> 04:54.960]  So, binary analysis is typically a process that, you know, until recently has been done very much by hand with disassemblers, with tools like hex editors, someone who's done a lot of vulnerability finding and exploit generation, and it generally has gotten to the point,
[04:55.020 --> 05:15.220]  you know, where you can, you know, open up a program and a tool like IDEA Pro or GDB, search for an instance of a problem, such as, you know, you find, like, an S print up or something, and hone in on that and, you know, do the actual manual looking at it and,
[05:15.240 --> 05:24.340]  like, trying to trace it back to a place where maybe you might be able to get a variable into a certain place or whatever, and, you know, trace that all the way through to the point of exploit.
[05:24.580 --> 05:44.080]  That process is something that human beings do that can be automated enough with tools such that you don't actually need to, you know, do it all by hand.
[05:44.140 --> 05:48.160]  It can take hours and hours and hours of pouring over hex dumps and disassembling things.
[05:49.360 --> 06:04.500]  If, for example, all of the data flow of a program, which is the map of sort of all the definitions and variables to all the uses of those variables, if you were to have that map already available, there would be no time spent tracing.
[06:04.780 --> 06:09.340]  You would just, you know, block the graph and say, no, here, this is possible.
[06:09.480 --> 06:10.880]  In fact, you could do that with a script.
[06:11.640 --> 06:14.460]  You could, you know, write a script that queried these graphs.
[06:14.780 --> 06:21.000]  Now, of course, the generation of the graphs is a hard problem, but it's not intractable.
[06:22.800 --> 06:33.400]  If anyone has ever, in the audience here, has ever built a compiler of any sort, then you're probably familiar with the concepts of data flow and control flow, which are two parallel things that make a computer program go.
[06:34.420 --> 06:41.700]  So, if you have the source code, you generate these intermediate representations and then convert that into a binary.
[06:43.860 --> 06:51.020]  What we've done over the last three or four years is develop a tool which could be thought of as a decompiler.
[06:52.760 --> 06:59.640]  And it builds those same models from the binaries and could, if you wanted, export source code from that.
[07:01.460 --> 07:02.460]  Sure, go ahead.
[07:05.700 --> 07:09.820]  So, basically there's like four parts of a system that does this.
[07:10.400 --> 07:16.240]  And they are related to compiler construction, but we've taken the different tackles starting with the binaries.
[07:16.440 --> 07:26.720]  So, we have a front end that works much like a disassembler, but disassembles to an intermediate language, a representation that's transformable.
[07:26.720 --> 07:39.600]  You have a transformable entity that represents low-level instructions like calls and conditional jumps and things like that.
[07:39.820 --> 07:53.340]  You also have high-level constructs in the same language, things like for loops and procedure calls that are expressions that have return values and parameters and variables.
[07:53.340 --> 07:55.980]  All those high-level concepts are all present in the same language.
[07:56.700 --> 08:02.040]  And then you write a set of transforms that get you from the low-level to the high-level representation.
[08:03.880 --> 08:10.740]  We start off, you know, feeding in any debug symbols that we happen to have, if you happen to have those, which makes your life a lot easier.
[08:11.660 --> 08:14.580]  It gives you some type information so you don't have to reconstruct it.
[08:16.080 --> 08:22.880]  And then you go into a data flow transformer, which basically undoes the register coloring problem.
[08:24.080 --> 08:29.600]  Building and reconstructing variable lifetimes is sort of a key process.
[08:29.740 --> 08:35.820]  You want to make as many variables as possible and merge them together to form this data flow graph.
[08:37.360 --> 08:48.540]  And eventually, you know, when you're done with this process, you have a whole series of variables with non-overlapping lifetimes that represent the flow of, you know, the sort of maximal flow of data in the system.
[08:49.900 --> 08:57.540]  Once you have that, what you sort of, what you have is almost readable once you've done this process.
[08:57.540 --> 09:02.760]  And that feeds directly into a control flow transformer.
[09:02.860 --> 09:06.560]  A control flow transformer looks at things like an unconditional jump.
[09:07.160 --> 09:11.760]  Or a condition, you know, that lead, that jumps to the, you know, the head of a loop.
[09:12.700 --> 09:16.980]  With a conditional jump at the top that jumps to the end and finds constructs like that.
[09:18.400 --> 09:25.420]  If anyone is interested in program transformation, that's, you know, a little higher.
[09:25.560 --> 09:31.200]  You know, a commonly analyzed computer science concept that is really applicable in this area.
[09:32.860 --> 09:44.820]  So, you know, it does things like interval analysis and regenerates high-level control flow for things like loops, conditional, two-way, three-way, N-way conditionals.
[09:45.220 --> 09:50.480]  And virtual function calls, things like that.
[09:52.240 --> 09:54.880]  And then once you've done that, you know, you have these high-level semantics.
[09:55.620 --> 10:01.980]  In this intermediate language, which just need to be exported in a language that's readable.
[10:02.980 --> 10:03.940]  You know, pick one.
[10:04.860 --> 10:08.160]  You know, for the most part, semantics are the same from language to language.
[10:08.420 --> 10:11.640]  Some languages can express certain concepts better than others.
[10:13.580 --> 10:19.980]  For example, some languages can do multi-level exits.
[10:19.980 --> 10:24.000]  Like, you know, in C, if you're in C, you know that there's a break statement.
[10:24.400 --> 10:26.840]  And that breaks you out of the current level of loop that you're in.
[10:29.980 --> 10:32.980]  You can't say break to and break out of two levels of loop, though.
[10:33.060 --> 10:41.200]  You actually have to use a break and then another, like maybe a boolean, followed by another break, in order to actually do that construct.
[10:41.200 --> 10:44.460]  Some languages actually have break two, for example.
[10:44.780 --> 10:49.360]  And you can represent and transform those concepts.
[10:49.980 --> 10:56.040]  Like, note that to add break two to C, all I have to do is introduce a boolean in order to do that.
[10:56.520 --> 11:06.000]  There's a certain transformability that lets you say, if I want to add a control flow construct, I can do so by adding a data flow construct in its place, if I have the accessibility to do that.
[11:06.120 --> 11:08.020]  Some languages can do go-to's, some can't.
[11:09.600 --> 11:12.600]  But, you know, there are certain classes of language.
[11:12.800 --> 11:24.140]  As long as your intermediate form can represent all of the different types of control flow and data flow, then you can analyze everything from C to Java to C-sharp to C++ to whatever.
[11:24.140 --> 11:33.820]  Our arbitrary output language is generally called resourceable, and arbitrary input binary would be called retargetable.
[11:34.020 --> 11:43.360]  So, what we've done is we've built a retargetable resourceable decompiler that generates high-level models and control flow using a few different techniques.
[11:45.060 --> 11:48.500]  Once you've got a model, you can do interprocedural analysis.
[11:48.500 --> 12:02.940]  This is something that humans are generally pretty bad at, but computers can be very good at the notion that you can create a variable lifetime by saying something like, new, new of a class or something.
[12:03.160 --> 12:04.740]  We store some data in it.
[12:04.960 --> 12:08.920]  And then several procedures later or deeper in the tree, we use that data.
[12:10.620 --> 12:14.000]  Generally, humans take a very, very long time to track that kind of data flow.
[12:14.960 --> 12:17.880]  But, you know, to a computer, it's just looking at the graph.
[12:17.880 --> 12:26.800]  You know, so it's something that we should be delegating more of, so we don't have to spend our brain cells doing...
[12:27.640 --> 12:29.000]  It's just simply that we lack...
[12:29.420 --> 12:32.760]  You know, until recently, we've lacked good tools to do this kind of work.
[12:34.540 --> 12:43.440]  The other thing that this model affords you once you've built it is the ability to ask arbitrary questions of it.
[12:44.460 --> 12:45.000]  You can...
[12:46.300 --> 12:52.480]  Right now, I can say, you know, right-click on a variable, as you see it, and ask the question, what possible variable...
[12:53.100 --> 12:56.360]  What possible values does this variable have at this point?
[12:57.540 --> 13:01.960]  And what possible control flow paths can be from point A to point B in the code?
[13:02.560 --> 13:05.660]  And what are the constraints on the data flow in order to do that?
[13:07.000 --> 13:09.060]  Those kinds of questions are exceptionally valuable.
[13:09.320 --> 13:15.240]  We ask ourselves those questions when we're writing exploits, because that tells you whether or not the program...
[13:15.240 --> 13:17.780]  or the vulnerability that you found is actually a problem or not.
[13:17.920 --> 13:19.100]  It's, can I get there from here?
[13:19.780 --> 13:26.620]  If I have tainted data input coming in off the command line or off of a network packet, does it actually make it to the bad string copy?
[13:27.940 --> 13:37.120]  You know, being able to traverse the graph and just answer that question is, you know, in record time, sort of a great equalizer for those of us that are hunting things.
[13:40.160 --> 13:40.600]  So...
[13:43.180 --> 13:44.480]  Yeah, I don't know.
[13:44.780 --> 13:45.240]  Let's see.
[13:47.260 --> 13:50.620]  Once you've built a graph, certain things just completely fall out.
[13:50.860 --> 13:54.020]  You know, you can say, you know, does this thing use the network?
[13:56.300 --> 14:00.700]  You know, if this program that you've written that shouldn't be using the network, and it does, it just kind of sticks out.
[14:01.100 --> 14:03.720]  You know, you see all the different calls to the different functions.
[14:03.800 --> 14:06.200]  You can call system, and you're like, okay, it shouldn't be calling system.
[14:06.640 --> 14:11.540]  You know, basically, building a program profile and comparing against that is the first very simple thing you can do.
[14:11.760 --> 14:23.340]  Much more complex scripts can be built, though, that do things from data tainting to range propagation to, you know, just basically figuring out, you know, sort of automating the process of exploit generation.
[14:23.340 --> 14:26.920]  Finding all the hot spots, propagating danger.
[14:27.620 --> 14:32.280]  Coming up with an abstraction for what's dangerous in a program, and propagating that throughout the entire thing.
[14:33.620 --> 14:42.940]  You know, these are constructs that are much easier to do with a tool than humans, no matter how good you are at it.
[14:47.080 --> 14:47.760]  Sure.
[14:48.140 --> 14:49.480]  I'm going to turn it back over a while here.
[14:49.900 --> 14:57.680]  Just for an example of just a script that you might write once you have this modeled.
[14:58.920 --> 15:06.420]  A very common problem with web applications is something called SQL injection.
[15:08.040 --> 15:21.060]  And what you can do is you can codify in a set of rules what causes a SQL injection problem in a program.
[15:22.460 --> 15:26.260]  So, we would write, basically, we would write a script and it would look something like this.
[15:26.400 --> 15:36.260]  We'd say, what are all the function calls that a program can do that call out to a SQL library?
[15:36.260 --> 15:38.060]  So, things like only BC calls.
[15:38.340 --> 15:43.580]  In Java, you'd have a call, execute query.
[15:45.560 --> 15:53.300]  So, you build a list of all the functions that basically are, quote, dangerous, right?
[15:53.600 --> 16:05.420]  Because, you know, unless the data going into this call is trusted, has been validated, and you know what it is, you're going to have a SQL injection problem.
[16:06.060 --> 16:09.260]  So, you build up that list of function calls.
[16:09.940 --> 16:12.660]  And on the other... then you build up a second list.
[16:12.740 --> 16:17.060]  And the second list is all the ways that input comes into your program.
[16:17.700 --> 16:22.380]  So, you know, reading stuff out of, you know, an HTTP request.
[16:24.000 --> 16:25.900]  The APIs are doing that.
[16:26.120 --> 16:30.480]  Or just reading data directly from the socket.
[16:30.480 --> 16:33.400]  Or reading data from standard input.
[16:33.740 --> 16:40.300]  And you build up this other list of all these functions that pull input into your program.
[16:42.020 --> 16:44.720]  Then what you do is you use the data flow.
[16:45.520 --> 17:07.380]  And for all those dangerous SQL calls, you follow the data flow back and see if any of that data, any data, you know, a few bytes of it, whatever, if any of it came from those untrusted sources, it has to pass through a validator function to make sure that the data is known.
[17:07.700 --> 17:11.420]  Or you have a SQL injection vulnerability.
[17:11.420 --> 17:15.060]  So, if it's something like Java, you're using the struts framework.
[17:15.360 --> 17:20.440]  This very clear structural way of doing validation.
[17:21.540 --> 17:28.580]  And what we can do is we can follow the data flows and see if you're passing through a validator function.
[17:28.820 --> 17:33.820]  Or if it's just arbitrary, you know, sort of arbitrary C code.
[17:33.820 --> 17:37.280]  You know, you can flag where your validator functions are.
[17:37.620 --> 17:50.060]  And we can look at all the different data flow paths and quickly tell you if there's some path that gets from, you know, basically untrusted to something which needed to be trusted very, very quickly.
[17:50.680 --> 17:56.900]  And the power of automating this stuff with scripts is, sure, a human could do this.
[17:56.900 --> 17:58.460]  And a human does a really good job.
[17:58.780 --> 18:03.400]  But the problem with the human is, the human does a really bad job of looking at a hundred different cases.
[18:03.780 --> 18:05.200]  Because humans make mistakes.
[18:05.480 --> 18:07.960]  And I don't know if any of you have ever done code review.
[18:08.340 --> 18:13.520]  But, you know, after eight hours, you might miss one of those hundred cases.
[18:15.460 --> 18:19.420]  And then there might be some other guy who's got a binary analysis program who runs it through.
[18:19.420 --> 18:22.460]  And finds the one case that you missed.
[18:23.420 --> 18:36.080]  So, the beauty of the automated approach really is the consistency and the repeatability of the analysis.
[18:36.560 --> 18:43.380]  That if it knows how to find one class of problem, it'll always find that class of problems.
[18:43.620 --> 18:48.720]  It's certainly not going to find all problems you can have in a program.
[18:48.720 --> 18:51.780]  Some things are very difficult to find in an automated way.
[18:52.560 --> 18:57.000]  But, a huge amount of the vulnerabilities that are major vulnerabilities out there.
[18:57.300 --> 19:06.580]  Things like buffer overflows, format string problems, integer overflows, SQL injection, cross-site scripting, things like path traversal.
[19:06.580 --> 19:18.120]  So, these types of problems are very well known, well defined, and they don't rely on understanding the design of the program, what the program is doing.
[19:18.300 --> 19:23.520]  They're just very structural problems, which can be defined with a set of rules.
[19:24.400 --> 19:30.700]  And, uh, the model can just be scanned, um, with, uh, with that set of rules.
[19:47.960 --> 19:50.280]  ...ability that's exploitable to break into something.
[19:50.500 --> 19:55.300]  But, security is very much sort of an, sort of an all-paths problem.
[19:55.300 --> 20:01.680]  You need to secure just about everything, because if you leave one hole, that's the one they're going to break in a little bit.
[20:02.040 --> 20:06.700]  So, um, there's sort of an order of magnitude difference there.
[20:06.820 --> 20:14.700]  That makes the, the life of, um, the person breaking in a lot easier than the person trying to secure the program.
[20:14.700 --> 20:23.960]  Um, tools that are automated sort of level playing field a little bit, by allowing people to find every instance of a problem and address it.
[20:24.480 --> 20:29.760]  Um, you know, whether they actually get around to addressing it is more of a political problem.
[20:30.000 --> 20:37.480]  But, uh, um, you know, it, you know, you need, you need sort of this robotic exercise to be able to deal with the problem.
[20:37.720 --> 20:45.680]  You know, if everyone's got an automated tool, then finding one problem versus finding all problems happens at the, at the same rate.
[20:46.280 --> 20:46.640]  Yeah.
[20:46.820 --> 20:49.140]  So that's, that's, that's a big boon for people trying to fix stuff.
[20:49.700 --> 20:53.560]  Um, let's see what we have here.
[20:54.740 --> 20:55.100]  Um,
[20:58.640 --> 21:00.480]  well, we can, I can just, I can point at this.
[21:00.600 --> 21:05.500]  This, this is not an amazingly, uh, accurate analysis at this point.
[21:05.500 --> 21:07.280]  But it's, it's something we can poke at.
[21:07.520 --> 21:09.760]  Um, I don't even know where this came from.
[21:09.840 --> 21:10.360]  This came from what?
[21:10.420 --> 21:10.720]  Apache?
[21:11.760 --> 21:12.600]  Or some library?
[21:12.600 --> 21:14.440]  It's a support library for Apache for Windows.
[21:15.240 --> 21:19.420]  There's, Apache for Windows has this function called true random in it.
[21:20.420 --> 21:23.160]  And it sits inside some DLL.
[21:23.680 --> 21:27.620]  Um, if I'm remembering correctly, uh, we didn't have source code to that.
[21:28.840 --> 21:29.280]  Right.
[21:29.680 --> 21:29.880]  Right.
[21:29.880 --> 21:33.000]  It's, it's actually something that you don't have source code to, which is kind of weird.
[21:33.260 --> 21:37.500]  You can get it, but it doesn't come with the actual tar of everything.
[21:37.500 --> 21:47.640]  Um, so we fitted it into this and, you know, what you're seeing here, you know, it doesn't look like a human written C or C++, but it doesn't need to be.
[21:47.880 --> 21:51.000]  Because it's just the computer that's got to understand it for the most part.
[21:51.520 --> 21:59.540]  Um, internally there's, um, there's, uh, a graph sort of representation that you really can't see here.
[21:59.540 --> 22:01.260]  But it's just sort of the generated source.
[22:02.180 --> 22:06.660]  You know, we, you take the program, we feed it into this tool, which we wrote called Smart Risk Analyzer.
[22:07.060 --> 22:17.820]  Um, sort of, uh, uh, you know, it's, uh, you know, you feed this in, it runs, it chucks for, you know, four or five hours on, on an executable.
[22:18.280 --> 22:22.200]  Produces these graphs and lets you run scripts off of the, uh, scanned menu there.
[22:22.200 --> 22:25.220]  You can see that there's a little, uh, tag at the bottom.
[22:25.960 --> 22:28.200]  Um, a little warning thing.
[22:29.240 --> 22:33.960]  And, uh, it's pointing out that SRAND is being seeded with something that is effectively constant.
[22:36.000 --> 22:39.180]  Which really doesn't make for true random numbers terribly well.
[22:39.740 --> 22:45.620]  Um, but you wouldn't know that if you didn't have the source code, which we didn't have, but we found the problem anyway.
[22:47.060 --> 23:07.260]  That's sort of the, the point, is you don't always have the source, but you really do want to, uh, you know, if there's, you know, let's say somebody messes up and, uh, instead of using, like, a left shift, they used just a less than sign or something in their code.
[23:07.900 --> 23:11.340]  Um, and that caused a completely different semantic to happen.
[23:11.860 --> 23:16.740]  Then, you know, you might not notice looking at the source because it's, you know, it's passable.
[23:17.400 --> 23:20.140]  Uh, because it, you know, it looks like any other thing.
[23:20.140 --> 23:24.580]  Um, but, you know, the problem may escape human attention, but it won't escape a script.
[23:25.300 --> 23:31.500]  Um, a very, very good example of this recently was in the Linux kernel.
[23:31.760 --> 23:41.400]  If anyone caught the vulnerability where someone had inserted, actually removed a single character during a check-in from the V4 call.
[23:41.900 --> 23:47.860]  basically said, if UID equals zero, then blah, blah, blah.
[23:48.600 --> 23:52.460]  Um, except that it wasn't double equals, they took out one of them.
[23:52.640 --> 23:56.460]  And so that if you called VueForg, it set your UID to zero.
[23:58.420 --> 24:00.680]  Again, could be, you know, plausibly deniable.
[24:01.740 --> 24:05.260]  And, you know, and definitely escapes people's attention for a while.
[24:05.780 --> 24:10.680]  Um, but wouldn't escape the attention of a script because it's not looking at the source.
[24:10.860 --> 24:11.320]  It doesn't care.
[24:11.420 --> 24:12.660]  It just wants to know what the program does.
[24:12.660 --> 24:23.640]  Insofar that compilation could be viewed as encryption, that the CPU could be considered a decryption device in the same context.
[24:24.360 --> 24:34.320]  Um, the idea is basically, you know, all your semantics have to eventually meet the CPU if, you know, you've written.
[24:34.620 --> 24:44.060]  So, going from the binary's standpoint is the only way to be sure that you're analyzing what the CPU is actually going to be running.
[24:44.780 --> 24:46.220]  Um, that's the tack that we took.
[24:46.680 --> 24:53.060]  Um, you know, there's a lot of source scanners out there, but there are very few effective binary scanners out there.
[24:53.200 --> 24:53.940]  This is one of them.
[24:54.440 --> 24:58.620]  Um, there are other tools which purport to do that kind of work.
[24:58.980 --> 25:11.000]  Um, IDEA Pro is very good at producing disassembled output and combined with some scripts that are publicly available, um, can do certain types of data flow analysis.
[25:11.340 --> 25:16.800]  It's not quite as automated as this, but it's very, very good if anyone wants to play around with this stuff.
[25:17.060 --> 25:23.240]  Um, I only say that because this program is not currently available for, uh, download.
[25:23.480 --> 25:24.180]  It's not free.
[25:24.680 --> 25:28.400]  Uh, and it consumed about four years of my life in order to make it.
[25:28.960 --> 25:33.620]  Um, so eventually the technology will get out there, but it's not quite there yet.
[25:33.620 --> 25:39.100]  Um, so give another, another couple months and, uh, you're going to be hearing more and more about this kind of stuff.
[25:39.600 --> 25:40.040]  Um,
[25:43.960 --> 25:47.760]  in theory we could, in theory we could actually do it live here.
[25:48.320 --> 25:48.900]  Hold on.
[25:49.680 --> 25:50.060]  Do you want to?
[25:51.640 --> 25:53.680]  Oh, this is actually the program itself.
[25:54.100 --> 25:58.300]  Um, I fed a Microsoft binary into it.
[25:58.300 --> 26:03.340]  Um, did you know that you have source, uh, not source code, but you have symbols, uh, you
[26:10.630 --> 26:11.670]  equivalent to source code.
[26:12.110 --> 26:14.130]  Um, once you feed it in through something like this.
[26:14.550 --> 26:22.710]  What I did was I fed it in the AVI file decoder, because it's small and I didn't have that much time before this step, this talk.
[26:23.110 --> 26:26.310]  Um, anything huge usually takes 24 hours to analyze.
[26:26.550 --> 26:28.630]  It's just a really process-intensive task.
[26:29.330 --> 26:35.170]  Um, decompilation is a much more intensive process than compilation because you're reconstructing stuff, not throwing it away.
[26:35.830 --> 26:45.710]  Um, but yeah, so I fed this in there because AVI files are opened automatically by Internet Explorer, which makes this, you know, any, any holes found in it, chances are they're remote and you can do it through email.
[26:46.710 --> 26:54.430]  Um, so yeah, we've poked at it, um, and you can see there that we've generated some stuff for like AVI build filter.
[26:54.910 --> 27:01.290]  Um, you know, if there's stuff inside, this is for creating and reading back AVI files.
[27:01.910 --> 27:09.990]  Um, there's a local alloc that it does, um, which it then passes interprocedurally to, um, something else.
[27:10.310 --> 27:16.750]  Um, and it's just noting, uh, you know, that this is potentially the start of a data flow.
[27:17.090 --> 27:30.050]  Um, and the analysis scripts that we have in there right now are not, uh, not too deep, but it's, it's noting that this is the start of, you know, a 64-byte chunk that could possibly be overwritten later, so it marks it as a possible error.
[27:30.050 --> 27:42.330]  It also went through and marked all the different calls to sprintf, which are in the AVI file decoder, which, you know, they're down there.
[27:42.970 --> 27:49.190]  Um, yeah, so you can see it sprinting into a buffer and, you know, querying some value out of the registry.
[27:49.910 --> 28:04.350]  Um, all of this stuff, for the most part, is, uh, stuff that you could, in theory, see with a, um, a disassembler, but it makes a lot more sense if you can just kind of click through it, um, with a tool like this.
[28:04.510 --> 28:05.450]  You know, it's a lot faster.
[28:06.010 --> 28:14.210]  Um, so, I would, I would, uh, actually just, you know, feed some programs that I wouldn't let you look at it, but you'd actually be sitting here all night.
[28:14.650 --> 28:16.190]  Um, it's not terribly amusing.
[28:16.330 --> 28:19.410]  It sits there, and the progress bar doesn't move for a very long time.
[28:19.630 --> 28:23.950]  Um, but, uh, you know, just wanted to show you that it's real.
[28:25.270 --> 28:25.990]  That it works.
[28:32.320 --> 28:43.340]  So, I'm actually gonna hand it over to him again, so he can talk about, uh, other uses of this kind of technology, including differential binary analysis, and, uh, you know, what use that is to the world.
[28:46.850 --> 29:01.370]  So, uh, a particularly interesting use of, uh, binary analysis would be to be able to just look at two versions of a program and see what changed.
[29:01.950 --> 29:10.670]  So, one, uh, one, one interesting case of this is when a vendor ships a patch for a security vulnerability.
[29:11.810 --> 29:17.810]  Can I do a comparison between the program, say it's some DLL that's getting patched?
[29:18.330 --> 29:21.510]  Can I look at that DLL before, and can I look at it after?
[29:22.230 --> 29:36.090]  Um, so even if it's a differential patch, um, and not just like a complete overlay, um, I can look at the before and after, and, uh, try to determine what the patch did.
[29:36.790 --> 29:46.190]  Um, both, did it fix a security vulnerability that may have been, um, unknown.
[29:46.550 --> 29:49.590]  Um, and the vendor didn't say anything about that one.
[29:50.230 --> 29:54.770]  Um, did the patch install some new DRM code?
[29:55.470 --> 30:07.290]  Just kind of slip it in there, you know, like you got to upgrade your media player for, uh, security vulnerability, and all of a sudden now, uh, uh, you can't play your wares that you hacked up before.
[30:07.750 --> 30:22.510]  Um, so, but, so, but the really interesting thing is, um, you know, can I figure out what the vulnerability, what the details of the vulnerability are just by looking at the patch?
[30:23.650 --> 30:41.950]  Um, the way, um, differential, uh, binary analysis works is the graphs that, uh, DilDog was talking about, the control flow and the data flow graphs, um, can be compared before and after.
[30:42.350 --> 30:53.870]  And this is much easier than comparing source code, um, because, uh, basically, there's a lot of, um, a lot of research has gone into comparing graphs.
[30:54.170 --> 31:01.890]  And there are, you can actually, there are programs out there, um, open source programs, that you can feed graphs into.
[31:02.210 --> 31:05.150]  And it will tell you exactly, are these graphs the same?
[31:05.610 --> 31:08.330]  Uh, or where, where are the differences in the graphs?
[31:10.090 --> 31:13.090]  Right, did, things could just be shuffled around.
[31:13.270 --> 31:16.170]  You could be just trying to obfuscate code and just shuffle things around.
[31:16.170 --> 31:22.490]  But if the control flow is essentially just still the same, it's just a bunch of go-tos, the graphs will end up being the same.
[31:23.570 --> 31:37.930]  So, when you compare the, the control flow graphs, um, right away, it'll highlight those pieces of, the pieces of code that, um, that have changed, and you can zero in, um, right, right on those pieces of code.
[31:38.290 --> 31:54.330]  So the idea is you're gonna basically unlink these, these, these files down to the individual functions, and then you're gonna compare both the, the, uh, the, uh, the call tree of the entire, of the entire, uh, module or, or process.
[31:54.770 --> 31:59.950]  But then you're also gonna, you're gonna compare the graphs, um, within, within each function.
[32:00.810 --> 32:07.310]  Um, there's, uh, two papers, if you want more detail on exactly how to go ahead and do this.
[32:07.310 --> 32:08.570]  There's two papers out there.
[32:08.710 --> 32:13.050]  One's, um, by Halvar Flake, and one's by, uh, Todd Sabin.
[32:13.610 --> 32:18.790]  Um, and, uh, I, I, I recommend, uh, looking into those.
[32:18.990 --> 32:27.410]  It's, uh, uh, eye-opening what you can, what you can quickly, quickly do, um, from a, uh, from a patch, once it's, once it's out there.
[32:29.050 --> 32:31.570]  Um, so here's my cheesy graphic.
[32:32.950 --> 32:49.830]  Um, so, the idea about discovering vulnerability details from patches, if you can automate that process, that really changes the, uh, the whole Internet threat model.
[32:50.870 --> 32:57.650]  Um, uh, Colonel Boyd, um, I think it was in the Army, maybe the Air Force.
[32:58.790 --> 33:06.590]  Um, came up with this, uh, this concept called OODA, Observation, Orientation, Decision, Action.
[33:06.970 --> 33:10.930]  And it's basically the doctrine of, uh, of modern warfare.
[33:11.650 --> 33:23.770]  And, um, the idea is you have to, um, you know, obviously more information on the battlefield, um, helps you beat the enemy.
[33:25.030 --> 33:40.290]  But, um, um, you're basically unstoppable if your loop, where you observe, you orientate that new, uh, information to what you already know, you make a decision, and you carry out an action.
[33:40.290 --> 33:55.090]  If you can do those four things faster than, essentially, the enemy can change the situation, basically, you always, you always win.
[33:55.270 --> 33:59.990]  So the idea is to make your OODA loop faster than the enemy's OODA loop.
[34:00.790 --> 34:04.030]  And that's basically how modern warfare is conducted these days.
[34:05.050 --> 34:12.930]  So, you can apply that theory to, to, basically, information warfare.
[34:13.910 --> 34:25.150]  And, uh, basically, there's a, you know, there's a sort of, the daily, the daily battle out there is vulnerabilities get discovered, and vulnerabilities get patched.
[34:27.190 --> 34:46.650]  And, uh, there's been a lot of, uh, a lot of research on, um, William Arbaugh did a paper a few years ago, and, uh, uh, Qualis has been, uh, distributing papers, a paper on, um, their research on how quickly, quickly things get patched.
[34:47.810 --> 34:51.810]  And, uh, essentially, this is sort of a half-life to things getting patched.
[34:52.370 --> 34:55.790]  Um, and I think, uh, what was it, 30 days was the half-life?
[34:56.130 --> 35:01.330]  So half of the systems are patched in 30 days, and then another half in 60 days, another half in 90 days.
[35:01.730 --> 35:07.850]  And then it kind of tails off for a while, and then eventually, um, it actually starts going back up again a little bit.
[35:07.850 --> 35:29.570]  Um, but, the idea is if you can, if you can, if you can quickly determine what the vulnerability is from the patch and build the exploit, then you're always going to have, um, you're always going to have a significant, a certain number of machines on the Internet that you can control.
[35:29.570 --> 35:50.070]  So, this is just, this is just basically a fact of, of, of the future, is because we're continuously patching systems, with technology like differential, uh, binary analysis on patches, and the ability to quickly create exploits, means that we're always going to be in a situation where,
[35:50.430 --> 35:56.170]  um, a large percentage of the Internet is basically owned by, you know, who knows?
[35:56.170 --> 35:57.030]  Who knows who?
[35:57.250 --> 36:02.430]  And I'm sure the, uh, you know, the info war guys in the Air Force know this very well.
[36:03.870 --> 36:11.250]  Um, so what are some countermeasures to, uh, to binary analysis?
[36:12.650 --> 36:16.730]  So, the technology's new, but we might as well think about how people are going to try to defeat it, right?
[36:18.290 --> 36:32.350]  So, a lot of, um, a lot of, uh, things like DRM code or, um, license manager code, or code that people really don't want you to know, um, what's going on.
[36:32.450 --> 36:38.590]  The code that they know that you'll take the time to disassemble or poke through with the debugger.
[36:39.310 --> 36:44.610]  What they do to protect the code is they make it self-modifying code.
[36:45.410 --> 36:50.110]  So, while the code is running, it's, um, it's changing itself.
[36:51.030 --> 36:58.190]  And, um, a lot, a lot, a lot of this is actually, um, using encryption.
[36:58.190 --> 37:03.070]  So, the code will be encrypted, and it'll be decrypted on the file.
[37:03.070 --> 37:11.470]  It'll be, as, as, as it hits certain blocks of code, um, it'll, just before it gets to that block of code, it will, it will decrypt that next block.
[37:12.230 --> 37:13.730]  And then, and then re-encrypt it.
[37:13.830 --> 37:18.930]  So, even while, of course, on disk it's encrypted, but even in memory, um, it's, it's encrypted.
[37:19.350 --> 37:27.870]  So, this is really going to throw, uh, a problem into binary analysis, because, essentially, the code just looks like, uh, random data.
[37:29.130 --> 37:32.210]  Um, so, we thought about this problem.
[37:32.210 --> 37:35.110]  And we said, what, what are we going to do in this situation?
[37:35.450 --> 37:37.110]  And we don't, we haven't built this yet.
[37:37.470 --> 37:59.390]  But the idea is to, um, build a, uh, uh, since the CPU needs to know what the real instruction is at some point, what you do is you build in a, uh, a journaler, which, when the instruction, uh, before it goes to the CPU, uh, basically gets written out to a,
[37:59.390 --> 38:00.090]  to a file.
[38:00.090 --> 38:10.350]  And you essentially, uh, journal, journal the program, uh, all this, all this, uh, and you might need hardware to do this, um, some sort of software.
[38:11.210 --> 38:13.850]  The software in me, like CPU, like soft ice kind of thing.
[38:15.250 --> 38:27.710]  Um, and, uh, then you, then essentially you're going to have to do things like collapse loops and things back, um, but you can get, you, you should be able to get the original, the original code back.
[38:27.710 --> 38:30.050]  So, the future is bright for binary analysis.
[38:30.190 --> 38:31.570]  Don't worry about self-modifying code.
[38:36.580 --> 38:45.020]  Um, it wouldn't be 26, uh, 100 or hope if, uh, we didn't talk about something with the, uh, legal system, right?
[38:48.520 --> 38:53.380]  So, there is one problem with binary analysis, and that's license agreements.
[38:55.440 --> 38:57.420]  Just a little, little, little problem there.
[38:58.340 --> 39:14.380]  Um, almost all proprietary software, and they thought of this 20 years ago, because they knew there was going to be all kinds of ways of poking into the binary, um, comes with a license agreement which says you cannot disassemble, you cannot decompile,
[39:14.840 --> 39:18.100]  you cannot reverse engineer this software.
[39:20.360 --> 39:23.560]  So, what the vendor is saying is, trust us.
[39:24.640 --> 39:27.320]  This binary only does good things.
[39:27.760 --> 39:30.680]  It does things that we told you did.
[39:30.920 --> 39:32.820]  And it has no security problems in it.
[39:33.940 --> 39:40.520]  If that was the case, uh, there wouldn't really be a problem with, with, with those kind of license agreements.
[39:41.000 --> 39:46.300]  But we know, reality is extremely divergent from that situation.
[39:46.600 --> 39:52.760]  Almost all software that does anything real, or I'll say all software that does anything real has security vulnerabilities in it.
[39:54.200 --> 40:04.220]  And, uh, all software is probably doing something which you don't know what it's doing, and you might, and you might want to for legitimate, legitimate reasons.
[40:05.700 --> 40:20.380]  Um, so, essentially the way the license agreements are, are written now, is you have no right to, to do a security analysis of, of, of, of a binary.
[40:21.240 --> 40:22.760]  Um, in this, in this way.
[40:23.380 --> 40:29.700]  You have no right to, to know what kind of, uh, files this, you know, the program is modifying.
[40:30.320 --> 40:45.640]  Um, so, we, we need to have, basically, some, some laws that allow people to do the kind of inspection on, on, on software that they can do on other things in the, in the physical world.
[40:46.280 --> 40:53.480]  Um, but, uh, due to the power of software companies, um, I'm not, I'm not holding my breath.
[40:53.480 --> 41:06.360]  I, I, I think the only way that this would happen is, if it could be shown, that binary analysis tools, actually, can help, um, can, can help with the security problem.
[41:07.340 --> 41:09.480]  And, you know, convincing the U.S.
[41:09.620 --> 41:19.560]  government that, they should use these types of tools, on all the software they purchase, to see what the quantity of security vulnerabilities is.
[41:19.560 --> 41:27.240]  It's just, at least to just get a rough feel for, is this thing, you know, written, written well, or is it written extremely poorly?
[41:27.880 --> 41:30.460]  Um, from a security standpoint.
[41:31.140 --> 41:43.940]  Um, I, I think that's one of the, one of the, one of the only ways that we're going to get, get some changes that allow people to inspect, inspect software legally.
[41:47.840 --> 42:00.060]  Um, and if that was the case, the next step would be, we could actually have, you know, software certification labs, which could run these types of tools, and give you an assay report on a piece of software.
[42:00.480 --> 42:11.040]  Just like, uh, you know, you can send your water to some testing agency, and they will tell you how much lead you have, and do you have poisons in that water.
[42:11.040 --> 42:12.600]  And anyone can do that.
[42:13.460 --> 42:23.840]  Most, uh, most, um, most governments, uh, local governments that have things like well water, test their water regularly.
[42:24.880 --> 42:26.460]  Um, that's the law.
[42:27.020 --> 42:29.100]  But, you can test the water too.
[42:30.380 --> 42:50.200]  Um, if you had, um, a way to send a piece of software to a lab, and come back with an assay report and say, uh, uh, this program looks like it has 700, uh, buffer overflows in it, 400 format string attacks, it has, uh, three SQL injection attacks.
[42:50.940 --> 43:03.520]  Um, and, uh, by the way, um, it's listening, um, it's listening to the, uh, the raw network device, and, uh, you probably, you probably want to know that.
[43:03.520 --> 43:11.640]  Um, and, uh, right now, there isn't anything like that, and, uh, there probably, there probably should be.
[43:11.800 --> 43:21.560]  I, I, I'm always constantly amazed how we treat software as something completely different than all the other things we know how to do well, um, in, in society.
[43:22.320 --> 43:27.540]  Um, to, uh, you know, protect ourselves on a societal level, and protect ourselves on an individual level.
[43:27.540 --> 43:32.160]  So, when it gets to things like proprietary software, the rules are just completely different.
[43:33.100 --> 43:36.620]  Just, you know, hopefully it will change.
[43:39.240 --> 43:46.960]  Um, finally, uh, and this is, uh, I think pretty far out there, but, uh, you know, you have to strive for something.
[43:46.960 --> 44:08.200]  Um, the idea of automatically fixing security vulnerabilities in a binary, where you would decompile the program, analyze it, find the vulnerabilities, and then come, then what, what you would do is you would have a rule set about how to fix certain classes of problems,
[44:08.640 --> 44:12.640]  automate those fixes, and then recompile the program.
[44:14.460 --> 44:21.860]  Um, I think that, that, that, um, creates an order of magnitude problem on top of what we're already doing.
[44:22.380 --> 44:28.520]  But, uh, you know, maybe someday, um, you'll be able to do that on, uh, on, on software.
[44:28.720 --> 44:39.320]  So you could actually, um, no matter how poorly the vendor, the vendor, uh, wrote the software, you, you could fix at least a subset, um, of, of, of the problem.
[44:39.320 --> 44:44.200]  Um, you know, a good example would be something like, you know, SQL injection.
[44:44.680 --> 44:56.920]  You could just, if you detected that, what you could do is you could just put a, a, a call in to do a validator function right before it went to the SQL query, and you could easily patch in a, a, a fix there.
[44:57.660 --> 45:08.560]  Um, one, uh, way to, to think about that, um, I just, I actually just thought of this right now, sort of, uh, extending the concept of firewall to software semantics.
[45:08.880 --> 45:17.280]  There are certain, once you have everything in graph form, there are certain patterns that would be considered bad or malicious.
[45:18.020 --> 45:29.420]  Detecting those and not allowing them to run, or fixing them, or changing them, or transforming them away, um, could be thought of as sort of a block rule on a certain type of programming operation.
[45:29.960 --> 45:34.960]  Um, I don't know where I'm going with this, but it's an interesting idea to think of it that way.
[45:35.100 --> 45:39.800]  It's just sort of an abstraction layer above, uh, you know, just looking at data.
[45:40.060 --> 45:43.540]  This is looking at that code, um, in that way.
[45:43.680 --> 45:45.160]  In the same way that one might look at data.
[45:49.760 --> 45:52.260]  Um, it's all the same once you get, once you get the graph.
[45:54.980 --> 46:00.340]  So, yeah, at this point, um, I would, uh, open up the floor for any kind of questions.
[46:00.340 --> 46:09.100]  Anyone would like to, if you want to actually ask a question, come up, um, to the mic in the middle here, and, uh, get in line.
[46:11.240 --> 46:13.180]  How much is the software going to be?
[46:13.400 --> 46:15.340]  How much does the software cost?
[46:17.760 --> 46:24.760]  Uh, well, you know, right now, we're, um, using it internally as a consulting service.
[46:24.760 --> 46:31.000]  Um, we kind of use it as a robotic exoskeleton for our consultants to make them superhumans.
[46:31.780 --> 46:45.360]  Um, and, uh, when we get around to making this software public, I'm pretty sure you'll see some numbers on our website in the order of magnitude of four to five digits, depending on how much money you want to pay us.
[46:47.200 --> 46:52.080]  Um, but, you know, as, as is anything, you know, we have to pay back our research time.
[46:52.740 --> 46:54.400]  Um, so, first question.
[46:57.000 --> 46:58.400]  Can I speak a little closer?
[46:58.640 --> 47:00.020]  I don't know if, is that on?
[47:00.440 --> 47:00.980]  Should be.
[47:01.700 --> 47:01.980]  Hello?
[47:03.140 --> 47:05.980]  Uh, what does your point-throughs ADS?
[47:06.280 --> 47:08.400]  Point-throughs, point-throughs, and, uh...
[47:08.400 --> 47:10.400]  I, it's not loud enough, I can't hear her.
[47:10.940 --> 47:13.040]  I'm working, I just, if you can talk about for a moment.
[47:14.280 --> 47:14.980]  Go ahead.
[47:22.160 --> 47:24.180]  I, I can't quite understand the question.
[47:24.600 --> 47:25.340]  How well does it handle pointers?
[47:25.340 --> 47:26.720]  How well does it handle pointers, the program?
[47:27.000 --> 47:27.160]  Okay.
[47:27.520 --> 47:34.740]  Um, uh, well, uh, there's a component of the system called a range propagator.
[47:35.020 --> 47:52.020]  And a range propagator, basically, it sees things like the dereference of an expression and, um, says, um, uh, it allows you to query what the value of that pointer is at that point.
[47:52.380 --> 47:57.160]  It does, it kind of walks back through the code and finds what the range is of that pointer.
[47:57.160 --> 48:07.000]  Now, if the pointer happens to be, you know, a constant, like a location, like a location on the stack, then that's just a stack variable when you dereference it, and it just turns it into that.
[48:07.480 --> 48:16.300]  Um, basically, we would build these frames, and if pointers are simply pointers, then they're just a variable like any other variable.
[48:16.300 --> 48:21.380]  If they're dereferenced, then you may be making other variables based on them.
[48:22.040 --> 48:25.280]  So, we have this generalized concept of layered variables.
[48:25.620 --> 48:34.540]  You know, you start off with registers, and if you dereference that once, you get a frame, um, which could be a stack frame or a this pointer.
[48:34.840 --> 48:39.040]  If there's a this pointer, then you might get a, um, a class out of it.
[48:39.520 --> 48:45.240]  Um, if you dereference that again, then you may be doing things like passing things by reference from one function to another.
[48:45.600 --> 48:50.240]  Um, so, you know, when you ask the question, how does it handle pointers?
[48:50.420 --> 48:52.000]  It handles them like any other variable.
[48:53.020 --> 48:56.200]  Um, and it, it, they're just a component of the graph like anything else.
[48:56.380 --> 49:03.660]  But we note that there is a special operation called a dereference, um, as well as a reference, but that was, that was a little easier.
[49:04.080 --> 49:08.800]  Um, uh, that adds semantics to the system.
[49:11.580 --> 49:13.020]  Anyway, I hope, I hope that helps.
[49:13.780 --> 49:15.440]  Why is, why are we heading back now?
[49:15.820 --> 49:17.020]  Um, because that's not a wireless environment.
[49:18.120 --> 49:25.920]  Uh, Todd, um, when, when you were talking about, uh, self-modifying code, you said that you weren't worried about that as far as Talking to the wireless mic?
[49:26.700 --> 49:27.600]  Are you speaking to the wireless mic?
[49:28.160 --> 49:28.240]  Oh, great.
[49:28.600 --> 49:28.880]  Thank you.
[49:29.300 --> 49:36.580]  Um, you said you weren't worried about, uh, self-modifying code as to how it related to the future of automated binary analysis.
[49:36.920 --> 49:37.060]  Yep.
[49:37.460 --> 49:43.460]  Uh, do you want to talk a little bit about how maybe, uh, you know, trust computing initiatives and planning and whatnot?
[49:43.700 --> 49:44.520]  I think that mic's a little high.
[49:44.520 --> 49:44.780]  It's ringing.
[49:45.400 --> 50:18.280]  Um, trust computing, uh, effectively adds a hardware component to, uh, the software problem of, uh, you know, so that, basically, you know, if, if one was to do all of the encryption and hardware on, on, on, on an executable, I'm gonna come up with a horrible example of a program that cannot be disassembled by anything but the CPU because it's,
[50:18.440 --> 50:31.900]  um, because it's decrypted on, let's say, the motherboard right before it goes to the CPU, you know, so you, when you talk about self-modifying, um, it's basically equivalent to the whole encryption problem.
[50:32.580 --> 50:32.720]  Um,
[50:36.190 --> 50:40.290]  your question is effectively the same as what are we gonna do about trusted computing in general?
[50:40.570 --> 50:41.770]  And the answer is emulation.
[50:42.250 --> 51:00.850]  Um, once people can, you know, you know, deduce, you know, what the various public and private keys are and things that are built into the motherboard, emulating that layer, you know, in a system, effectively, you just need to be able to, you know, get at the CPU,
[51:01.310 --> 51:03.530]  uh, and what it is, what it's intending to do.
[51:03.750 --> 51:10.610]  If the semantics are completely obscured, then this kind of, you know, binary analysis technique really can't be used.
[51:11.250 --> 51:18.350]  Um, however, in so far that everything that is, you can do it one way, you can do it another way.
[51:18.490 --> 51:20.130]  Um, you can do it the opposite way.
[51:20.650 --> 51:25.530]  As long as, uh, you know, it's like, as long as you can decrypt the, the image.
[51:25.690 --> 51:27.550]  I mean, it had to, it had to come from somewhere.
[51:27.850 --> 51:29.150]  So, I don't know.
[51:30.170 --> 51:32.610]  It's, uh, it's not necessarily a problem for binary analysis.
[51:32.810 --> 51:35.510]  So far that it's just what do we do about just computing in general?
[51:35.610 --> 51:36.950]  How do we get at the, at the bits?
[51:37.350 --> 51:38.870]  So, I hope that helps.
[51:41.470 --> 51:41.870]  Hey.
[51:42.070 --> 51:42.650]  What's going on?
[51:42.750 --> 51:43.090]  What's up, dude?
[51:44.250 --> 51:46.650]  So, uh, so, so two questions.
[51:46.870 --> 51:53.550]  One, um, um, you know, if GCC, if you go and throw it, like, dash 06 way, you're not going to...
[51:53.550 --> 51:54.690]  Well, dash 06.
[51:54.910 --> 51:55.330]  Yeah, yeah.
[51:55.390 --> 51:55.990]  Optimize to...
[51:55.990 --> 51:57.190]  You're not going to get any useful code.
[51:57.530 --> 51:57.930]  Maybe.
[51:58.270 --> 51:59.970]  It's kind of, it's kind of here to...
[51:59.970 --> 52:04.610]  A lot of times, you know, we turn up the end, we crank up the optimization on the compiler, especially GCC.
[52:04.790 --> 52:04.990]  Sure.
[52:05.710 --> 52:15.210]  I'm wondering if you ever found using these techniques, um, security problems that are accidentally introduced by high level optimization.
[52:15.450 --> 52:15.890]  That's the first part.
[52:16.230 --> 52:19.090]  The second one is, uh, more theoretical questions.
[52:19.350 --> 52:22.850]  Has any of your work ever started to run into the down use of formal undecidability?
[52:26.250 --> 52:31.470]  Um, the first question, um, was about the, um,
[52:36.550 --> 52:38.730]  I'm just trying to think of a proper answer.
[52:39.170 --> 52:47.070]  Um, no, I haven't actually seen a compiler introduce a bug, but we've come awfully close.
[52:47.250 --> 53:00.030]  There was a, there was a time when we compiled a program with, um, with GCC and it, uh, the decompiler really threw a part on it.
[53:02.050 --> 53:09.290]  And, you know, it was saying, you know, like, this, uh, stir copy or whatever is writing way past the end of this buffer, what the heck is going on here?
[53:09.650 --> 53:13.810]  And we're looking at it, and it really just wasn't what the person wrote.
[53:14.650 --> 53:16.450]  You know, we thought it was just a bug in the decompiler.
[53:16.610 --> 53:20.550]  I mean, this thing is, you know, had its fair share of bugs, and maybe it was just our problem.
[53:21.010 --> 53:25.550]  And, you know, we started at it for, it must have been 45 minutes, just staring at it.
[53:25.650 --> 53:31.630]  I mean, we didn't believe that what was decompiled was actually what the person had written and sourced.
[53:31.710 --> 53:45.430]  But it turned out that, uh, due to some very clever pound defines, what was, uh, actually, uh, being compiled was a lot different than what it looked like.
[53:45.930 --> 54:02.070]  Um, there's some cases, um, you know, where, you know, it's just the human problem, you know, and, you know, the compiler itself was not inserting a vulnerability there, but it's something that we just would not have found unless we were using a binary analysis tool.
[54:02.490 --> 54:08.390]  Um, to answer the other question, I didn't actually hear the very end of what you said, formal what?
[54:08.710 --> 54:10.710]  Uh, formalize undecided ability.
[54:11.270 --> 54:19.370]  Um, um, I, uh, I haven't done a whole lot of research in that area, so I didn't tell you.
[54:19.970 --> 54:22.430]  Um, regardless, I think that's the last question that we have.
[54:22.670 --> 54:24.890]  We just got the red card, so that's five minutes.
[54:24.990 --> 54:28.310]  If people want to grab beers with us later, we might be able to talk about this stuff.
[54:28.510 --> 54:29.690]  So, all right, thanks.