WEBVTT 00:01.260 --> 00:07.920 Let's begin from where we left off in the previous video, we have compiled the binary and we have disabled 00:07.970 --> 00:10.680 X, Stack, Keniry and Ocilla. 00:11.190 --> 00:13.890 Now let's see how we can crash this application. 00:14.250 --> 00:19.800 There are multiple ways we can simply produce a long input here on the terminal and we can crash the 00:19.800 --> 00:20.430 application. 00:20.860 --> 00:27.060 But what we are going to do is we are going to create a simple point program so we can use it as a template 00:27.060 --> 00:28.100 for the rest of the course. 00:28.570 --> 00:32.340 So let's create a file called Exploit One Dot P.L.. 00:38.660 --> 00:41.660 All right, and let's provide the shebang. 00:53.290 --> 00:58.960 And then let's use this particular line with a pipe set to one. 01:00.780 --> 01:07.350 This line forces are flush after every right and print, so the output appears as soon as it's generated 01:07.560 --> 01:08.860 rather than being buffered. 01:09.600 --> 01:16.020 Now let's create a variable called junk and let's give it three hundred is. 01:19.950 --> 01:22.440 All right, and then let's simply print it. 01:24.670 --> 01:30.700 And that's OK, so that's a very simple template that we are going to use throughout the course, right. 01:30.730 --> 01:40.060 So let's save the file and let's also make sure that we give it executable permissions so we can simply 01:40.060 --> 01:46.180 execute it using DOT instead of typing pool space, the filing every time we want to run it. 01:46.810 --> 01:49.790 So I haven't given it executable permissions. 01:50.840 --> 01:54.980 Now, this file should produce 300 days for us when executed. 01:55.300 --> 01:56.590 So let's quickly check it. 01:59.930 --> 02:00.450 There you go. 02:00.680 --> 02:06.950 There are 300 is on my screen, I'm not going to count them for you when I believe you trust your instructor. 02:07.460 --> 02:11.030 Now, let's ride this out, put into a file called Pillar One. 02:18.120 --> 02:23.620 We are going to do this multiple times, so you will get habituated by the time we finish this exploit. 02:24.090 --> 02:29.310 Now, what I'm going to do is I will simply run this vulnerable program and I will pass the contents 02:29.310 --> 02:31.890 of payload one as input to the program. 02:32.280 --> 02:33.060 Let's do that. 02:34.230 --> 02:35.790 Not vulnerable 02:38.190 --> 02:40.300 cat payload one. 02:41.820 --> 02:42.350 There you go. 02:42.690 --> 02:46.590 There is a segmentation fault and it says conduct. 02:47.040 --> 02:49.980 Let's check the current directly by typing ellis'. 02:50.730 --> 02:55.230 And if you notice, in the current directorate there is nothing like a Crashdown. 02:55.530 --> 02:58.910 There are no new files created due to this segmentation fault. 02:59.220 --> 03:05.820 So one interesting thing that we can do here is to enable code dumps so we can understand what caused 03:05.850 --> 03:08.580 the segmentation for it by analyzing the code. 03:09.030 --> 03:09.990 So let's run. 03:10.530 --> 03:18.190 You limit the C and hit enter currently set to zero. 03:18.720 --> 03:25.070 So let's say you limit Dash C unlimited and hit enter once again. 03:25.560 --> 03:27.990 Let's type you limit dash C. 03:28.020 --> 03:30.190 Now it is set to unlimited. 03:30.630 --> 03:39.450 Now once again, if we try to crash the application using the payload we have created, we should observe 03:39.450 --> 03:40.160 a new file. 03:41.670 --> 03:42.220 Dirigo. 03:42.590 --> 03:44.940 There is a new file called Code. 03:45.450 --> 03:52.260 This file is a code dump which gives us the details about the situation of this program and the time 03:52.260 --> 03:56.880 of the crash so we can use this code file to analyze the crash. 03:57.090 --> 04:01.200 It is something like black box for flight crashes, right? 04:01.230 --> 04:05.480 So let me show you how we can analyze the code file using Jilib. 04:06.270 --> 04:14.310 We can type GBE bascule for quite more, so we won't see a lot of outpoured when we are loading a file 04:14.340 --> 04:17.370 using Jilib and Dash code. 04:17.790 --> 04:23.160 And let's specify the name of the file, which is caught in this case, Dirigo. 04:23.610 --> 04:30.690 Now, if you see the output, it says the file code was generated by this command, which is here, 04:32.340 --> 04:36.930 and the segmentation fault is caused by this value. 04:37.920 --> 04:42.720 What it means is this long input has overwritten Oraibi somewhere. 04:43.140 --> 04:48.080 Arop is the register that decides what is the next instruction to be executed. 04:48.720 --> 04:55.680 If you notice, the next instruction to be executed is at this address, which is probably not a valid 04:55.680 --> 04:58.990 address, and that's the reason why the application is crashed. 04:59.310 --> 05:04.150 So, as I mentioned earlier, we can use the code dump to analyze the crash. 05:04.470 --> 05:06.930 We can also type in four registers 05:09.990 --> 05:14.350 to understand what values each register is holding at the time of the crash. 05:14.790 --> 05:22.440 As I mentioned, Oraibi is overwritten with this particular address and that's what is causing the crash. 05:22.980 --> 05:27.810 And there is another interesting thing that's happening here at the time of the crash. 05:27.810 --> 05:30.720 The Army register contains this value. 05:31.170 --> 05:34.950 This is part of the junk that we have used to crash the application. 05:35.310 --> 05:41.780 So this means it is out of our three hundred errors are loaded into our register. 05:42.390 --> 05:43.550 Let's keep that in mind. 05:43.560 --> 05:45.210 It may be useful for us later. 05:45.690 --> 05:49.160 Now, I just wanted to give you a brief idea about condoms. 05:49.500 --> 05:55.200 You can explore further if you are interested, but let's stop talking about condoms here and let's 05:55.200 --> 05:56.190 quit this job. 05:56.940 --> 06:02.540 We will come back to condoms later after completing our first buffer overflow exploit. 06:03.150 --> 06:09.720 So I'm just quoting here now, let us run the program itself in Greevey. 06:10.310 --> 06:14.040 I'm typing glib and slash vulnerable. 06:16.240 --> 06:18.940 And the file is loaded once again. 06:19.510 --> 06:22.680 Now, let's try this as main. 06:24.220 --> 06:27.060 This is the disassembly of the main function. 06:27.460 --> 06:32.260 And if you notice, there is a call to one underscore func. 06:32.710 --> 06:37.660 This is a function inside which we have a vulnerable ECPA function, if you remember. 06:37.990 --> 06:39.600 So let's quickly double check that. 06:39.910 --> 06:47.110 So I'm typing this as one underscore func D'Arrigo. 06:47.350 --> 06:51.430 We have a call to SDR S.P.I at PLB. 06:52.480 --> 06:58.570 We will discuss more details about procedure linkage, Jabel or Paldi and later in this course. 06:58.780 --> 07:04.090 But for now, just remember that there is a call to start CPA function inside. 07:04.090 --> 07:06.610 This one underscored Funt function. 07:07.150 --> 07:11.890 Now let's run the program by passing the contents of Paillard one as input. 07:12.100 --> 07:17.140 If you remember, we have loaded the vulnerable program in GDP, but we haven't run it. 07:17.590 --> 07:29.020 So I'm just clearing the screen and let's just type A run and get payload one. 07:29.890 --> 07:30.670 Let's get into. 07:32.840 --> 07:38.030 Look at that, if you notice this, there is a segmentation fight once again, and if you notice the 07:38.030 --> 07:41.800 output, Jeff is showing us all this beautiful output. 07:42.050 --> 07:47.240 If you're not using Jeff and if you are just using plain G.V., you will have to type a lot of different 07:47.240 --> 07:48.830 commands to see all these things. 07:49.100 --> 07:53.180 For example, you are seeing the registers here without Jeff. 07:53.180 --> 07:59.050 If you want to see the information of the registers, you will have to type in four registers playing 07:59.060 --> 07:59.460 Jollibee. 08:00.200 --> 08:04.220 But Jeff shows you many interesting details with every command you run. 08:04.580 --> 08:13.400 If you look at this, this is the state of registers and this is the stack and these are the instructions 08:13.400 --> 08:14.780 that are being executed. 08:15.410 --> 08:20.300 Now, if you look at the output, this is the same as what we have already seen within the code dump. 08:20.810 --> 08:29.570 It is have overwritten r b register, but we have passed 300 s and we don't know which eight are among 08:29.570 --> 08:32.750 those 300 s overwriting r, b, b register. 08:33.230 --> 08:40.280 We want to be able to find that if we can find out that offset of which eight is actually overriding 08:40.460 --> 08:45.420 the R B to register, we will be able to find out the offset to all right. 08:45.740 --> 08:52.040 IP register that will in turn help us to reletting the program, flow to some code that is written by 08:52.040 --> 08:52.310 us. 08:52.910 --> 08:58.580 Now, it may sound a little confusing, but by the time we finish this exploit, it will be clear. 08:59.120 --> 08:59.440 Right. 08:59.630 --> 09:01.160 So that's all for this video. 09:01.370 --> 09:08.480 In the next video, we're going to find the offset of how many s are needed to override IBP as well 09:08.480 --> 09:10.160 as our IP registers.