my close friends kind of heard of me singing just around the area do a couple karaoke's here and there one of my sergeants actually had more information on a band and chorus out in the near Sambach Germany you get orders to go audition for four weeks I passed this was my new assignment and my new job for the unit that goes out there and breaks the ice we go out to the different nations and areas and these people who can't even speak English but enjoy music just as we do it brings a sense of togetherness for everybody the influence is all over my house always has been with my mom and the rest of her side of the family being the singers and my dad's side being nothing but dancers they just kind of joined forces I'm actually up there on the stage it's a it's definitely humbling breathtaking it's a wow moment every time I'm up there that person that gets the comfort out of singing in their car with the windows rolled up or the person singing in the shower with confidence it's that person on stage


This is Ed Murrow, and this is the canopy of ice that covers the Arctic Ocean. The frozen barrier that throughout history has barred shipping from a body of water five times the size of the Mediterranean Sea. Only once, shortly after the turn of the century, has man reached the North Pole by a surface route. No ship has ever reached the pole. Even the most powerful icebreakers are helpless against this frozen barrier. On April 25th, 1958, the Nautilus departed her home port of New London, Connecticut. Destination, the Pacific, by way of the Panama Canal. The announced purpose of this crew was to indoctrinate Pacific fleet units in the capabilities of nuclear submarines. Even as Nautilus plied the Atlantic waters southward for Panama, the thoughts of the crew occasionally turned to the three probes Nautilus had made under the ice pack of the Arctic in 1957. For preparations were being made for further under ice exploration to be conducted the following summer. Technicians were at work on a myriad of electronic equipment. A special modified version of an inertial navigation system, originally designed for use in missiles, had been installed. And the special high-latitude gyro compasses were checked and rechecked. Preparations were made for installing a pressure-proof TV camera for viewing the underside of the Arctic ice. But as the Nautilus transited the Panama Canal, her crew also thought of the West Coast ports they were scheduled to visit. San Diego, San Francisco, Seattle. And they thought of the long, tedious days of operations they were to conduct, initiating the personnel of the Pacific fleet in the ways of the nuclear navy. Finally, the West Coast tour was over. On the 9th of June, shortly after midnight, the Nautilus slipped quietly from her birth in Seattle, presumably starting her homeward voyage south. But the course set by the Nautilus actually took her farther and farther north. Unseen beneath the sea, the Nautilus journeyed north to the edge of the Arctic ice pack. Then, under. The voyage to the North Pole was underway, but this under-ice venture was short-lived. Unexpected ice conditions nearly turned this probe into the Bering and the Tukchi seas into disaster. The Nautilus was forced to turn back. Changes in the navy are commonplace, and the men of the navy are accustomed to changes. Therefore, it came as little surprise to hear that the Nautilus Pacific tour was to be prolonged, to include a visit to Hawaii. On June 28, the Nautilus sailed into Pearl Harbor, site of the navy's great Pacific submarine base. Rear Admiral Grenfell, the commander of the submarine force, U.S. Pacific Fleet, officially welcomed Nautilus and her crew to Hawaii. And the people of the islands opened their arms and their hearts to this great ship. Nothing was lacking. On the 23rd of July, Nautilus bid aloha to the islands of Hawaii. The Hawaiian interlude was over. Except at high-level conferences, no word of the recently attempted voyage to the pole had passed the lips of a single crew member. Presumably, the return trip to New London via the Panama Canal had commenced. The crew of the Nautilus, a few high-ranking navy officials and civilian scientists, and the President of the United States, knew that the men of the Nautilus had still another port to visit before they were to see their loved ones again. The port of call, Portland, England. And the shortest sea route from Hawaii to England is not by way of the Panama Canal. All hands on the Nautilus knew their destination, and the perilous route, they were to follow in reaching it.  This time, however, ice conditions had been thoroughly scouted from the air by the ship's navigator. Lieutenant Jenks had traveled to Alaska, in Cognito, and flown over the Arctic expanse many times, gathering vital information. Success was by no means assured, but the probability of success had been greatly increased. Each man had been given the opportunity to leave the ship before she embarked on this journey into the unknown. Not one had availed himself of this opportunity. The 2,900-mile journey to the narrow Bering Straits, which separate Alaska from Soviet Siberia, was used to good advantage in pouring over the plans for their mission under the ice. Operation Sunshine. Special charts provided by the Hydrographic Office were minutely studied. All electronic equipment was carefully tuned, and the revolutionary inertial navigation system and high-latitude compasses received the doting care of a favorite child. Periscope bearings were taken of landmarks on the coast of Alaska. The ship's position was carefully checked. The Nautilus took a last look at the vast expanse of Arctic ice which lay ahead. This is the foreboding site which greeted the Nautilus as she began the most important leg of her historic voyage. Then, nothing of the Nautilus remained to be seen above the surface of the sea. Silently and cautiously, the Nautilus knows down into the Barrow Sea Valley. Above, a continent of ice covering the Arctic sea, a frozen mantle of white that had always proved invincible to man's onslaught from the sea. Below, the little chart at bottom, and ahead, 1,800 miles of cold, watery darkness. Outside, water cold enough to kill a man in a matter of minutes. But within the cylindrical steel shell that is the hull of the Nautilus, the crew relaxes in a controlled atmosphere. Temperature? A constant 72 degrees. Relative humidity? 46%. Life was normal. For the Nautilus, everything was routine. Life aboard the Nautilus was very comfortable. The nuclear power plant which had driven her over 120,000 miles, mostly submerged, also provided heat and electricity. It provided the power which operates the jukebox, and the coke machine. It provided the light by which a man can shine his shoes, or read 20,000 leagues under the sea. And it provided the light by which a man could write a letter. By the time you get this, we will have completed our trip under the North Pole. A lot of people will probably make a big fuss over it, but this has really been a pretty easy cruise. It was a little hair-raising when we were trying to find our way under the ice, but the tensions eased up a bit now, and everybody's a little more relaxed. Some of the boys are holding rope yarn Sunday, cooks hustling up some chow, or take us playing the guitar. Yes, everybody was a little more relaxed, or almost everybody. But when you're making 20 knots, 400 feet under the Arctic ice pack, the navigator can't relax. Always ploughing, always checking his instruments. There were no stars to navigate by, no landmarks to be guided by. Even the depth of the water ahead was unknown. Few soundings existed of the Arctic Ocean, and most of these inaccurate. On the second day under the ice, the Nautilus routine was abruptly broken. Soundings indicated the ocean bottom was coming up rapidly to meet the ship. Speed was reduced, and further reduced. The depth of the water continued to decrease. Anxiously the ship crept forward. Was this to be the end of the journey? Was the Nautilus to be again frustrated in her attempt to gain the pole? Again, fortunes smiled on Nautilus. The sounding showed the bottom was leveling off, and finally deep water again. Nautilus had crossed an uncharted underwater mountain range and added another significant piece of information to the world's scant knowledge of the Arctic Ocean. Nautilus had the latest and best navigation equipment. But the best equipment in the world is only as good as the men who operated. And the men of the Nautilus are good. The objective of the Nautilus and every man aboard was now to attain the north pole and get through to the Atlantic. Even before reaching the pole, the Nautilus had again proven the value of nuclear power in submarine. As the sure hands of her crew guided her northward, the feeling of confidence in this ship was evident. There was no need to surface to revitalize the air. Carbon dioxide scrubbers and carbon monoxide burners purged the ship's air of unwanted gases. And fresh oxygen was periodically added to the atmosphere. There was no need to snorkel to recharge batteries. Nuclear power had made Nautilus virtually independent of the Earth's atmosphere. But confidence did not give way to complacency. The plotting continued, the listening continued, the looking continued. And as the Nautilus got nearer and nearer to the top of the world, quiet excitement began to mount. Until that report, distance to the pole, 1,000 yards. Commander William R. Anderson stepped to the microphone in the control. This is the captain speaking. In a few moments, Nautilus will realize a goal long sought by those who are maintaining the North Pole. I would like to suggest at this time, as we approach the pole, that we observe a brief period of silence, dedicated first, to he who has guided us so truly. Second, to all those men who have preceded us. Art of failure. And third, in our furnished hopes for a world peace. 2, 1, march. For the USA and the US Navy, the North Pole. There was quiet jubilation. But more significant, there was the sense of fulfillment. The feeling of satisfaction that every pioneer must feel in reaching his goal. The Greenland Sea. 36 hours after the historic polar crossing, the Nautilus surface. The voyage from Pacific to Atlantic, by way of the North Pole, was now a matter of record. Nautilus had made history. The men of the Nautilus had blazed a trail under the Arctic pack, which reduced the distance from the Orient to Europe by almost half. A feat which seems destined to have enormous impact on future sea commerce. On her return to New York from England, Nautilus received a hero's welcome from a grateful American people. Commander Anderson was awarded the Legion of Merit. And the entire crew was awarded the Presidential Unit Citation. The first such award ever made in peacetime. Rear Admiral Hammond G. Rickover, renowned as father of the nuclear submarine, was on hand to welcome the Nautilus as the personal representative of the President of the United States. The citizens of New York raised their voices in congratulations. And their voices echoed throughout the free world.


Yeah, I haven't had time to actually look at the earn it act enough, so I don't feel like I'm qualified to comment on that. But yeah, I think as it develops, it'll definitely be something we can look at. Ooh, ASCII emotes nice. All right, can everybody see my screen? Cool, thank you. All right, so you can see that all your chats are on here, so just for those that joined late. I'm going to be recording the chats as part of the online recording so that people can see your responses. So, you know, that's also tied to your name. It'll be on YouTube forever, act professionally, which I know you will. All right, cool. All right, let's get started. So let's see. There have been some questions in, let's see, there we go, all right. There's been a few questions about the assignment, so they'll be, you know, please come to office hours.  Join that, the TAs will be going over how to use GPG and all that fun stuff. And definitely be thinking about how you want to do that. So only about a third of the students have actually uploaded a key to the server successfully. It's about 120, so I'd like that number to go up so that you're all doing the assignment and everything's going well. So yeah, so join, you know, you're already, if you notice you already had a head start on attending recitation section virtually, so we'll be continuing that. We'll be posting that in the chat. It'll also be recorded and posted online, so you can check that out. Cool. All right. Yes, Ethan. No, it's, we'll probably be up tomorrow. It's literally, it's going to be pretty simple for you. It's just submit the, submit the uploaded ones and it will tell you roughly how many signatures are on it. It won't tell you of course which ones are true or not true because that would reduce the point of this. So yeah, so you'll just export out your public key because that will then have all the signatures on it, turn that in, and that'll be part. So it'll be on Gradescope very soon. I just need to develop that. Cool. All right. Let's get on with some networking.  We'll tell you how many signatures you have. That makes sense. Oh, yes. That's a good point. Yes. We will have, we'll be doing CTFs. We'll have two CTFs the rest of this semester. I'll make a post about this later today so we can schedule those in. The basic idea is you'll split up into teams. There will be a jeopardy style CTF. We can have several challenges of hacking challenges that we'll go through during class. We're setting up how to do, how to do this online in the best way. So if you have any suggestions, feel free to send it my way, the TAs way. We're kind of working with the TAs and the undergrad TAs to figure this out. No, office hours are not in person. Office out, everything is virtual now. So check Piazza for all the links for Zoom. Cool. Any extra credit CTF? Don't know about that. We'll see. All right. Cool. So going on to networking. What is CTF? Great question. Capture the flag. So it's basically like we're going to do an in-class hacking competition and that will be worth a portion of your grade. You can check that out on the syllabus. And so it'll be super fun, I promise. Cool. Okay. So we talked a lot on Tuesday about how networking works. So we've been looking at specifically how networks work for that kind of that first part of the network hop, right? So how do packets get from our machine to like our router or to the next hop on our local network? So as starting off, first of all, how does a host know whether a target IP address is on its local network or an external network? Yeah, mask. Yeah, the net mask. Great. So we talked about that, right? That's the way that the part of the information that a host needs to have in order to probably in order to figure out which hosts are local and which ones are remote is the net mask. Great. Awesome. Cool. So the next feature that we looked at, we need a way for, because when machines want to talk to each other on the internet, all they have is the IP address, right? So with the net mask, we have a way to tell is this IP address local or remote? If it's local, then I need to send it using the link layer to the next hop directly to that machine. And in order to do that, I need to know what's the underlying MAC address. So what is the MAC address, remember, is the hardware address at the link layer. So we need this address resolution protocol or ARP that actually does this translation so that two machines on a local network, one can ask another, hey, who has the IP address <IP_ADDRESS> if you do, tell me what your MAC address is. And so that's what they do. Cool. And so, okay, so then we talked about hubs and switches. So let me see if my drawing works now. I may have hopefully fixed this. Okay, that's a little bit better. Yes, nice. All right, cool. So as we talked, we talked a little bit about the difference between hubs and switches. So can somebody remind me about that? So what is the difference between a hub and a switch? Hub sent to all. And yeah, okay, cool. So we talked about that actually. I guess we didn't talk about exactly how switches work. But yeah, so hubs will send, and remember they both kind of all look the same, right? There's a box with different ports. You can think of different ethernet ports. Port one, port two, port three, and something like port four, yeah, cool. So hub not smart. Very good. Yes, I approve of that description. So okay, so on a hub, any data packet comes into any port. It comes out to every other port. And there's no kind of smarts in the system. So the really cool thing of what a switch does is a switch is smarter and keeps track of information. And specifically, it keeps track of what MAC addresses does it see on what ports. So if we have here, we have host A, which let's say has a, we'll call it MAC A, something like that. And here we will have host B connected to this port. And that has something like a MAC of B. Essentially, the start, and we'll say we have host C here with very similar details, right? So at the start, a switch knows nothing about the network. So it doesn't know where to send packets. So it will essentially broadcast all packets out everywhere. And then it will learn internally a mapping that says once it sees packets from host A, it will say, oh, MAC A, oops, that's on A, that's a P. MAC A is at port one. And then when host B responds, it will send back with MAC B is at port three. And that's how it knows. So wireless gets much more confusing. So I don't want to go into it very much. But wireless you can think of, if it's like thinking think of two ways on a unsecured wireless network. So if your wireless network has no password, it's essentially a hub and you can sniff all the traffic that's happening. If it's a secured network, it's much more like a switch and you can't actually see other people's traffic. Cool. So yeah, so this is basically how it does this mapping of MAC addresses to ports as packets are going. And so as that's actually happening. So this will get into specifically how we sniff. And so this is, oh, maybe, yeah, I will bring up my, so this kind of one of the key goals and one of the key attacks we always want to be thinking about inside of a network is how do, how can we sniff packets and how can we sniff traffic on the network? So some things that maybe you don't realize protocols like FTP, HTTP, some mail protocols like SMTP will send the username passwords in the clear over the network. So if you're able to see and read those packets, then you're able to steal that information. And so this is really one of the, sniff is, yeah, see or read both of. So sniff basically you can think of means read. See kind of, it really depends on the encryption, right? So if the network is encrypted, if the network traffic is encrypted, it doesn't matter that you can read it because you can't break that encryption. But maybe there are ways that you can break that. So there's other things to think about. So basically, so just like normally your network interface card will drop any packets that are not meant for you. That's what we saw. That's why hubs work is because your network interface will get all the packets, but anything that doesn't have a destination MAC address of let's say MAC address a will not be will not be shown. So so if it's in a hub, you can just actually read all that you set your network interface into promiscuous mode, which says send all the packets up on that network. And but of course, in a switch networks, this is why we looked at the difference between hubs and switches. If it's a hub, you don't have to do anything, you get all the traffic on the network. And if it's a switch, then you need to do a little bit more work and a little bit more information. Oh, sorry. Okay, so this is a kind of why we want to sniff, like I said, so a lot of protocols actually will transfer all of the authentication information in the clear. So username password. So when we looked at authentication, we were looking at how do we steal that authentication information. So we can do that by using by sniffing and identifying these protocols. So if you think this is something that is silly, who uses these types of things? Does anybody use, let's say, FTP for work, or maybe pop to access emails? Anybody know? Can maybe use the raise hand functionality? No, no one. Man, tough crowd. Some people. Good. Maybe you're just doing that because I asked. Well, thank you. Yeah. Okay. So we did, when I was in Santa Barbara, we did a pen test for our company. And part of what we did was use, we set up a tap on all the outgoing traffic of the network just to see what we could sniff. And so doing that, we ran this sniffer, collected all this data, and basically we found that somebody in marketing had a FTP site they were using. So we stole those username passwords. And then from there, that gave us access to their site, that gave us access to more information in the company. So these things are used kind of all the time. And so this is why this is such a useful tool. So there's a lot of different tools that you can use in order to sniff traffic. You can collect, analyze, and even replay traffic, which is pretty cool. I will say one of the super useful things you can kind of learn for your career is if you learn how to use effectively these sniffing tools. So specifically, when doing network debugging, like for instance, I was dealing with this crazy problem once where I was trying to set up a capture the flag system for my grad class, like an internal hacking assignment of web applications. And what I had to do was on the packets were somehow getting lost. And so I had to use TCP dump on all these different machines to figure out exactly where the data was being dropped so I could diagnose the problem and figure it out. So this thing comes up all the time and I will tell you if you learn how to use these tools and you understand networking, you will seem like a true expert to some of your colleagues when you have insanely weird networking problems that need to be solved by understanding exactly what's going on. So these are some of the examples of the tools. So TCP dump is a command line tool that collects traffic. It is basically the one I use a ton. And then you have other cool tools that can kind of rip apart traffic. So you have a tool that can replay traffic, something that can rip a packet of traffic apart into different flows. That's cool. And the other main tool is Wireshark. So this has support for a number of different protocols in order to parse and show everything that's going on. So hopefully, yeah, these are the most common tools using the industry for sure. Usually the way it works. So TCP dump is all command lines. So I can run and you need to run. So in order to set your network interface as promiscuous mode, you need to run it as root. Dash I sets the interface. Sick. Yeah, we'll talk about detection later on. So hold that thought once we really understand what's going on. Let me check what interface five. So I can do sudo TCP dump n. The dash n option means to not don't try to map IP addresses to their domain names because that can slow things down. Dash I interface five. And you can then specify a filter to say I only want let's say port 80 traffic. And then when I type in my super secret password, we should see a lot of traffic or nothing's happening on my computer. This seems sketchy. Let's just look at all of it. Yeah. All of these insane amounts of data and kind of the interesting thing. This is all UDP packets. So we can see the UDP here. We didn't get into. Yeah, this is definitely the stream, which is interesting. You can also see port numbers here. So this is my local machine to this port 80 one must be the port from zoom. So yeah, you can see a lot. And you can do things like five ARP. So you can look at all the ARP traffic. We'll see if anything actually comes up. Maybe I can try pinging Google.com in another window. Yeah, this is not a YouTube video. You can't rewind, but you can view it later on YouTube. So yeah, here you can see the ARP traffic. So I've used a filter to filter only the ARP traffic because I don't want to get all those crazy UDP packets from the stream. I want to actually see what's going on here. And yeah, OK, so yeah, so you can see all the ARP requests and replies that are happening inside my network. I can filter ICMP, which is the ping protocol. So I can see all of the ICMP echo request and reply. These are ping packets. So these are going from my IP address to this is we can see what the machine has mapped Google to on this window. So we can see <IP_ADDRESS>. We can do echo request and echo reply. And this is sending an IP packet from us to Google and getting that reply in order to measure the time latency that it takes. Now, so if we wanted to do something, ICMP write temp test.pcap, now I'm going to store some packets. I'm going to send some ICMP ping so you can see what Wireshark looks like, maybe. OK. Or I don't have Wireshark installed on this machine, so I won't be able to do that right now. But I could do that later. So you can see Wireshark gives you a nice graphical interface that you can dig into these packets. But yeah, this is the basic idea. Let's do this. I can show you something interesting. So let's do port 80. Somebody remind us what's port 80? HTTP? Yeah, thanks, Ty. And I want the option dash A. So the dash A option tries to output the ASCII values of the packet if it can do it. Let's go to example.com. And so we can see a ton, a lot of different packets. We can see here this is our HTTP get request, get slash HTTP 1.1. This is our get request. And then this is the response from the server, 404 not found, I guess not super interesting. But these are all the different packets, HTTP packets that get sent in order to make an HTTP request to the server. Let's see. I don't know if this will work. I think it will try to redirect you. Yeah. So this is what the output that I got, which is a 301 redirect. So it's redirecting me and saying, hey, I don't speak HTTP, only talk to me over HTTPS. But this shows you that you can actually see exactly what's going on inside all of the packets that you're sending. And this is what allows somebody, if they can sniff your packet, somebody can see exactly if you're not using HTTPS and you're just using HTTP, somebody can maybe manage the middle of your traffic and see exactly what packets you're sending and getting back. Cool. Any questions on tools like this? Any questions on basically network sniffing tools, let's say? Oh, two raised hands. I think these were raised earlier with the, I'm going to lower your hand. Boop, boop. Yeah, those were from asking about using FTP and work. OK. Yeah, Ethan, go ahead. Yes, exactly. These tools show you and they'll be able to capture for offline analysis exactly what packets are being sent on the network. Yeah, let me. I guess I was a little confused. These are two different things. But the difference between what a net mask is doing versus the ARP, the Adjusters of Wichita protocol. Right, so ARP, maybe we can go up here. ARP is trying to translate between IP addresses and MAC addresses. So for instance, like we can see right here. So here we can see this is an ARP packet saying, hey, on this network, who has <IP_ADDRESS>? Whoever has that tell <IP_ADDRESS>. So 0.27, I think is my machine, I believe. And this ARP reply is saying, hey, this is at this MAC address. So MAC address is actually what's used in order to map in order to send locally over through Ethernet. Nathan, you can use on the participants mode. There's a raise hand somewhere in there in the participants mode. Yeah, so anyways, back to the ARP. So ARP is to deal with this in order to just do this mapping to say what MAC address has what IP address. And the net mask is used to determine which ones are local IP addresses. What IP address can you send directly a packet to on your local network and which ones can't you do that? And we'll go through later one things you can't do, but we'll actually go through attacks that can happen just on your local network without even thinking about other hops. Does that answer your question? Yeah. OK, cool. Great, OK, so we have sniffing tools. Cool, so now one of the key things when we went and looked at ARP, right, so let's think about kind of this scenario again. So to remind us, we had host A who was at this IP address who wanted to send a ARP request to Hopes B because they wanted to ping them first. And to do that, they needed to know the MAC address of their IP address. And so they sent a aren't ARPs the only protocol used for security? Think about that as we talk about this here right now. So, OK, think about this from the two different hosts perspective, right, and specifically putting on your security hat. So here we have this ARP request from host A. Host B gets this ARP request. What? So when host B gets this, so if we just, let's say, maybe we can do this, just zoomed in on this, this host B gets this ARP request that says, hey, who has, and this ARP request is, who has <IP_ADDRESS>.10 tell <IP_ADDRESS>? So how does host B know that this IP address is actually the .100 is actually trying to, is actually the one that made that ARP request? I wonder if I wait longer if I'll get more. Right, correct. So they can't even check the MAC address because they don't know, right? Nothing, each host independently creates their own MAC address. They have no way to communicate with them except over ARP. So all they know is they just got a packet that claims that this <IP_ADDRESS> needs a, is wants to ask for their MAC address. And then let's think about it from the other way. So now, where's my, there we go. So now this ARP reply comes back, right? So this ARP reply says, well, 192., oops, hello. Let's see, ARP reply <IP_ADDRESS> is at 0131D98B8. So if we look at this from, why are these so annoying? Thank you, Mac, what are you doing? All right. So if we look at this just from host A's perspective, right? And we say, host A gets this ARP reply. This ARP reply says <IP_ADDRESS> is at 0131D98B8. How does, how does host A know that that is actually host B's IP address and MAC address? Yeah, so if we think about it, if we even go back to thinking about this protocol, right? So this is really an ethernet based protocol. So all it knows is that it received a packet. So host A received a packet that was two, that was a, sorry, this is the source. So that it was two, it's MAC address. So it knows that it's for host A. And it knows that the source MAC address is 0131D98B8. And it's saying, hey, <IP_ADDRESS> is at 0131D98B8, right? So what it can guarantee is it knows that this was meant for it, right? This packet was meant for host A. But other than that, it can't guarantee anything about this header. For instance, what if host C created an ARP reply that actually said, hey, <IP_ADDRESS> is at C's MAC address instead of B's MAC address. Does host A have any way to differentiate those two ARP replies? Yeah, fundamentally no. With all the information that it has here, it has no way of knowing. And this is actually, it's kind of crazy. It's this core vulnerability in this system to map IP addresses to MAC addresses that we can use in order to do ARP spoofing. So this is an attack that allows us to do all kinds of really cool stuff. And basically allows us to listen in on the communication between two machines. So the whole idea, and one of the really interesting things is the ARP protocol is stateless. So what this means is that when you send an ARP request, you don't keep track like, hey, I'm waiting for this ARP reply of this specific thing. And it means that ARP replies without a request will be accepted. So let's go to the board. Let's try drawing a little network. So let's see, we have our switch here. Okay, we're giving up on that ugly switch. Okay, we have a, wow. We have a switch. We have A, we have B, and we have C. All right, or let's go Alice Bob and we'll change this now to Eve.  So one thing, okay, so now if host A, host A and B wanna talk, but Eve wants to be able to steal their communication or let's say Eve wants to pretend to be host B to host A, right? So host A will send out an ARP, an ARP request and which machines on this network will get that ARP request? Yeah, all of them, right, B and E, because it's a broadcast. So an ARP request is a broadcast that goes to everyone on the network. And it's saying, and the ARP request here basically asks who has the IP address of B, right? Goes to all the machines on the network and let's say Eve is much, much faster than B, right? So Eve gets this packet. Eve says, hey, I wanna pretend to be host B. So Eve can create an ARP reply and say, let's see, say IPB is at, let's see, I'm gonna just use M for MAC address. So MAC address of Eve, right? And she can create this reply. And remember the interesting thing about kind of networking and is that nothing prevents her from creating this packet, right? So she sends this out, who gets this packet? So if it's ARP reply, where's it going to? Yeah, just host A, right? So only host A gets this packet because the ARP reply, if we go back, remember the ARP request included the MAC address of who was requesting it. So that that way the reply could be sent just to that MAC address. So this ARP reply will be sent from Eve back to A. A gets this and what's it gonna do, let's say in its internal ARP cache? Yeah, add it to the ARP table. It's gonna say IPB is at MAC address of Eve, right? Now, when we think of what does the packet look like that A will send to Eve, right? If we think about it at the IP level, so what's, so now A wants to send an IP packet to Eve, right? So at the IP level, what's the destination IP gonna be? Justin asked if the ARP table could have multiple IPB entries, let's say no for right now, but we'll talk about that in a second. Let's say B doesn't reply for whatever reason, right? So the destination address is gonna be what? So this is a packet that A wants to send to B. So what's the packet gonna look like? Yeah, okay, so, yeah, remember at the IP level, A wants to talk to B, which is all only IP addresses, right? So the destination IP address will be the IP address of B. What's the source IP address gonna be, right? IPA, because it's coming from A. All right, awesome. So we have this at our IP level. Now remember this packet will then be enclosed inside of a MAC, an Ethernet link layer packet and it will have destination MAC and source MAC. So A will use its ARP table in order to figure this out. So what does it think the destination MAC is? Yeah, the MAC address of Eve and the source MAC, MAC address of A. Now, assuming this is a switch network, where is this packet gonna go, right? It'll send it out, the switch says, oh, it looks at the MAC address of Eve, it looks at the destination MAC and it will send this only out to E. So it goes to the switch and goes directly to E. Now Eve gets this, let's say Eve just wants to pretend to be a B, right? So Eve gets this packet and then Eve wants to respond to it. How's Eve going to respond? So we'll think about the IP level. So DEST IP, source IP and DEST MAC, okay. So at the IP level, right? So if Eve is trying to pretend to be B and reply to this packet, what's the destination IP address gonna be? So DEST IP address will be IPA and the source IP, IPB. And what about now the destination MAC address? MAC address of A and the source MAC, MAC address of Eve, awesome. And then again, we could demonstrate that these are in two different layers, the link layer and the IP layer. And this packet again, when Eve sends it out to the switch, where's Eve gonna send it out? Or where, sorry, where's the switch gonna send it out? Just to A, exactly, just to A. So B never even sees this traffic. Okay, cool. So fundamentally, this is how we can use ARP spoofing in order to impersonate a machine on the network, right? So here, host A has absolutely no way of knowing that we've essentially taken over the IP address of B, right, because all it knows is it thinks that the IP address of B is at the MAC address of Eve and it has no way of knowing this. And actually the situation is even worse because as some people brought up, well, what if B replies, hey, the IP address of B is at the MAC address of B? So this is only for local networks. So right now we are specifically focusing only on local networks. So, cool. Okay, so now with that, now we have the problem that people brought up of what if B responds and then we ask the other question of, well, what, like what happens to this ARP table? Is it just to get added here that the IPB is MAC address of Eve and the MAC address of B? So most systems will use a, so because of this stateless nature, so the simple fact is that the operating system of host A will not keep track of what requests it made. So it won't say, oh, I made a request and now I'm waiting for a response and then I update the table and then I drop this reply from B. It's stateless, which means that whenever it gets an ARP reply, it just updates the table. So this means that, so in this case, if we were first and we beat B, we set our ARP reply of IPB is that MAC address of E that would update this table. But then when B's reply got in, that would now change this to MAC address of B. So as an attacker, what can we do to ensure that our MAC address is always in there? Yeah, so either be last or spam it. We can do it every five seconds. We don't even have to wait when they send a request. We can just keep sending ARP replies and we will guarantee that we will have altered the victim's ARP cache such that it's our MAC address. So the MAC address of Eve. And we can just keep sending that. So now, okay, so now let's see. So people are kind of asking, okay, what kind of information can you access or what's the impact of this kind of attack, right? So one thing now, if there's on this network, if A and B have a trust relationship, so let's say host A says IP address of B can log in to me without a password, right? Now Eve by impersonating that, by Eve impersonating A, then by, yeah, by Eve impersonating A, or sorry, by Eve impersonating B to A, they could let's say log in to host A as if they were host B. So we can use that to that effect. And then we'll see that we can actually, so let's take this one step further. So we've only impersonated A to think that we're B, but what if we actually wanted to, so now any communication from A to B will get sent to Eve, but what if we wanted to actually try to man in the middle and intercept the communication between A and B? So right now we've only done one branch of that, right? We've only intercepted the communication from A to B, but now we can use this exact same thing to do it from B to A, right? We can use the exact same technique, trick B to think that we're A, and so any packet they send to each other comes to us. So let's think of how that would work. So we have Alice connected, Bob and Eve. Okay, so, and the important thing, like what Steve's saying, the important thing is that this attack will work no matter if it's a switch or hub. I guess the thing I didn't mention is that you can actually in older switches, you could overload them to become a hub. If you make that table between what ports have what MAC addresses, if you make it huge, it will like just crash and turn into a hub. Modern switches I think are much more adept at that, and so you have really cool techniques to do this here. Okay, yeah, so let's think about this. So we wanna intercept the communications with A and B. So we know based on our last example, the very first thing we have to do is to send them each ARP replies to make us think that they're the other. So if we draw, if we think of this as like the ARP table of A, oops, that should be a P, and the ARP table of B, right? So what we wanna do, so Eve wants to send packets, ARP replies, so it wants to send an ARP reply to A saying IP of B is at MAC address of Eve, and an ARP reply to B saying the IP of A is at MAC address of Eve, so that that way in the ARP table here, we have for A, IP of B is at MAC address of Eve, and then what do we want here for B? IPA is at MAC address of Eve, oops, yeah, great. Right, so now any packet they send each other will come to Eve, right? Okay, so we've sent our ARP requests, we've got this set up, now A and B start talking to each other, right? So now let's walk through kind of the packets that get sent, so we'll do it kind of the similar way. We'll do it just like we did before. Destination MAC, source MAC, source IP, cool, okay. So destination MAC, so now, so let's think, so host A wants to send an IP packet to host B, what's the destination IP gonna be? Yeah, IPB and the source IP, IPA, and the destination MAC, E and the source MAC, MAC of A, cool. All right, so that packet gets sent out, I like drawing these little boxes around it. Cool, that packet gets sent to Eve, now Eve wants to now not just, Eve doesn't want to impersonate B and pretend to be B, they actually want to send this packet to B, right? So now Eve, I'm gonna just put in here data zero, so this is the zero with packet, it's the very first packet that it gets sent in here, that's some data that's getting sent, so Eve gets this packet, now Eve wants to send it to B to get their actual response, right? So yeah, so we can do, so now if we take the same packet, so the destination IP addresses IPB, source IP is now IPA and the same data of that packet, we didn't change it, but now what do I need to have as the link layer in order to get this packet from A to B? Yeah, so exactly, great. So the destination MAC address will be the MAC address of B and the source MAC address is gonna be what? Oh, we're having some fights in the chat. Yeah, so why is it the MAC of A? Oh, sorry, why is it the MAC of E? Yes, because B thinks E is A, right? We've tricked B here into thinking that IP address of A is at the MAC address of E. So when we send this from Eve sends this packet, right, to the switch, it gets sent out from Eve to B, which means it goes right here to B. B gets this packet, replies to it, and so what's that reply gonna look like? So let's start again at the destination IP, let's call it data one, right? So the next reply, so the reply in this next packet. So where is B's reply going to go? So what's the destination IP address? Yeah, specifically IPA and the source IP address, IPB, right? And the way to think about this is you just look here, right? You just look at, it has this packet, it has a packet from, it thinks IP address of B, sorry, to IP address of B from IP address of A, so to reply to that, it just flips it, right? So it says, okay, I'm making a reply, that reply is gonna go to the IP address of A and the source IP is gonna be the IP address of B, right? Now the question is then what are the MAC addresses? So what's the destination MAC address? Yeah, the MAC address of Eve and specifically why? Why is it going to be the MAC address of Eve? Exactly, the ARP table here, right? Let's see, I don't really like this. Yes, but this ARP table, right? It looks up in its ARP table, it says, oh, I'm sending a packet to IP address of A, I look in my ARP table, I use destination MAC of MAC address of Eve and then the source MAC address will be the MAC address of B, sends this packet out and now, so this packet goes out, so B sends this packet, where does the switch send this packet? Yeah, directly to Eve and then Eve gets it, now Eve what? So the way to think about it is MAC address is used to send packets locally inside of a local network and IP address is allows you to send packets not just to your local network but to external networks as well. Yeah, so now Eve needed to take this packet, right? Send it back to A, so we want the same data in that packet, so we'll call it data one again, right? So the same data, let's say she's not messing with it. So what's gonna be the IP address here? Oh, IP A, source IP, yeah, great. Yeah, great, so it doesn't mess that up and then destination MAC, MAC A and source MAC, yeah, because remember, A thinks that IPB is that MAC address of Eve, so Eve wants to make sure that these match, great, cool. So that packet then gets sent to the switch, gets sent to A and now we've been able to all communication between A and B, this process continues, Eve gets to see all communication between A and B. I don't understand the question, if you trace the route, would you see Eve? So extras, yeah, so as part of, some of you are saying, yeah, there's much more packets than just A and B talking, right? If A and B were talking directly, you'd only have one packet but you have now A sends to E, E sends to B, B sends to E, E sends to A, right? So there's more traffic happening here but that's because we're literally, we've essentially inserted Eve in between A and B and so this is, so we've basically sent spoofed art messages poisoning their cache, right? So these are the steps that we took, we spoofed A and B and we poisoned their art cache, we then, we acted as a router basically. So every time we got a packet, we sent it to the right person and we were able to essentially man in the middle of the attacks. So here's kind of another example of looking at that, maybe we can do a brief, just walk through this going. I know there's a way, swap displays, there we go. Yes, so Eve, exactly. So Eve, yeah, Eve doesn't reply normally, like Eve will send these packets out so that it doesn't do, it doesn't operate as part of the normal ARP traffic. So here we have two hosts and host C wants to intercept them. Initially, so these below here are the ARP caches of each of the machines and you can see host C will send ARP replies to each of the machines in order to poison their ARP caches with its MAC address. And here we have the ARP reply to host B and remember the interesting thing here is it can do this without there being a request, right? So it can just send these replies as often as it needs in order to do this. Now, when host A wants to send to host B, some secret data, it will send it first to host C, host C will send that to host B. No, so that, yeah, exactly. So the ARP table is on each of the, I think of it as the host operating system has this ARP table. The switch also has a, not an ARP table, but it has a port, MAC to port mapping. So it maps for every port on the switch what MAC addresses has it seen there. So now host C can see that and we're able to, now, no matter the fact that it's a, let's say a, where's the ARP table? Actually, your operating system stores it. So that's when you do what happened to my participant list. I lost chat, what's going on? There we go, got you back. Okay, yes, so since this is a gaping hole in the protocol, there are, let's see, let me, okay. Yeah, where's the ARP table actually stored? Your operating system stores it. So I don't know exactly, it depends on each OS. Okay, cool. So, yeah, is this a gaping hole in the protocol? Yes, so we use ARP because of backwards compatibility and it's actually a fundamentally difficult problem. Like how do you, these are machines, so we'll talk about solutions later on, but it's kind of a difficult problem because you want this protocol that like any machine can kind of connect to your local network at any time. And so you need this mechanism because you, unless you and the way, one way you can prevent against this is by hard coding all of the ARP tables in all of your hosts and have them be static, right? But the problem is what happens if you get a new machine and plug it into your network, like it would be a huge pain to go update every other host on that system if you have even tens or hundreds of hosts. Yeah, so the switch also, it's difficult for the switch to do it because let's say both B and E are pretending, are saying their host A, or sorry, both B and E say they have the MAC address of B, how does the switch know which one's actually correct, right? It would need to let some through and it doesn't have enough information to know which one is actually which. So there are tools, one of the fun things is, there are tools to do this. So Ettercap is a tool that you can use to do this and automate this process of intercepting traffic. So mixing this with TCP dump. So what you can do is two machines on your network. You can pretend to, you can use Ettercap to manage the middle of their traffic and then you can use TCP dump to look at all the traffic on the network. Are you talking about my volume? I suppose there is, but I don't, don't you have a volume setting? Okay, cool. So you can use Ettercap to manage the middle of the machines and then TCP dump to look at all the traffic between them. You can also, we didn't talk about this, but in this example, we sent data zero, we just sent the data from one to another. You could actually data foobar, right? So Eve can alter and change the data between A and B and they won't actually know it. So there are some ways to protect against this, which yeah, we'll talk about a little bit. So some interesting things. There are technologies that you can do authentication at the switch level. I think it's 802.11x or something. So that each host actually authenticates to the switch or to the system. So that way you don't have a rogue Eve on your network. So there are some types of things against this. I will say if you, well now that since you're at home, if you wanna play with this at home, I highly recommend setting up two machines, A and B and doing this from a third machine on your local network. Of course, as always assume, make sure you have permission from people involved, but this is a super cool way to actually see this attack in practice and that it actually works. Now you can go look on how to do that. Yes, not on the ASU network. Don't do that on the ASU network. Do it at home on a network you control with machines that you control. Yeah, it's definitely possible to mess this up if you start sending weird ARP requests or replies. So you definitely don't wanna do that. It's not a nice thing to do, right? They probably have countermeasures, I would suspect, but I don't know for a fact. And Wi-Fi is, I think Wi-Fi is tricky. It depends on if you can do this. I'm not sure of all the particulars because again, the switch knows much more about your machine and your MAC address so it may refuse to route traffic from your MAC address that's not for you. So yeah, those kind of details all depend. Are we gonna discuss? So I'd say specifically ARP spoofing. Prevent it. Yeah, so like we said, you can prevent this by having static ARP tables. You can also look for machines on your, you can be monitoring your network for hosts that are sending ARP requests without a reply. VPN is not related to ARP or IP spoofing. It is unrelated.  Yes, did I say it wrong? I meant sending ARP replies without a request, yeah. Yeah, Ethan. So I guess what I've ended up like prevented is like when I go to like a restaurant or something and I join their Wi-Fi, like how do I know like there isn't interception going on that I am being tripped in some way? Yeah, you don't. So when you're on a open public Wi-Fi, it's, so the main thing to do use HTTPS, right? So that has, like we said, it has built-in identity detection for, so it's verifying the authenticity of the remote website using the public key infrastructure. So that's kind of the main thing, but fundamentally when you're on an open Wi-Fi network, anybody around you can be sniffing the traffic of that Wi-Fi network. And they could be using ARP spoofing attacks or other types of attacks based on just listening to your traffic. Yeah, thanks. Yeah, Gala. So you said for VPN, you're actually sending your information to another computer and that computer is sending it to whatever you want. So could that computer, the middleman, could they also sniff into your information? Yep. So yeah, the way basically VPN works is this is you, and here's your VPN server. So VPN basically ensures that this communication is encrypted from you to the VPN so that your user is sent from you to the VPN, that packet, so your packet that you wanna get sent out gets moved from you to the VPN. And then the VPN just sends out that packet. So you send a packet P, it's encrypted to the VPN, and then the VPN sends out P as if it was you to the network, to wherever it's going, and it gets the reply back, and when it gets the reply back, it sends it back to you. So it's good if you don't trust this first hop, right? So in this case of what we were talking about, a coffee shop or a restaurant that has unencrypted Wi-Fi, this will encrypt all your traffic to the VPN so at least nobody on the local network can sniff or understand what you're doing. I see, thanks. Yep, it also protects if you, let's say don't trust your internet service provider, or you don't trust your, let's say your country is monitoring all external traffic with like a great firewall, then this could be one way around that, cool. And the other type of attack that we can do locally is IP spoofing. So we can, just like we saw, and this is kind of inherent in what we've been doing here, so this is just a generalization of what we've been looking at, right? As we've seen, basically nothing in here authenticates the source IP, right? So when you get a packet, you don't actually know if the IP address is a, if the IP address is real or not, right? So in all of these examples, so let's say this packet here, right? So in this packet was a packet from IP address of B with a source IP of IPA with data zero. So inside this IP packet, so this IP packet remember came, this packet came from A to Eve, so from A to Eve, and then this packet went from Eve to B. So when B gets this packet, what does it know about the, what can it trust inside this IP packet? Yeah, so the destination IP address, so why the destination IP address? Why can it trust that? Exactly, because host B actually got the packet, right? It was meant for host B, so Bob can know and understand that it is definitely for host B, right? So can it trust the source IP address? No, and here's a great example where we're literally looking at a packet that got sent and E is essentially spoofing this source IP address, right? And nothing prevents it from doing so. Same thing with the data, it has no way of knowing if this data was actually sent by host A or not, it has no way of doing that. And so this is kind of a general notion that you can impersonate any machine on your local network and we'll see this extended to multi hop routing later of how this is done. So in this example here in the slides, we have, let's see if we can do this real quick. Yeah, there we go, right? So we have our little network and here we have our attacker. So our attacker's IP address is technically 111, 1020, 121. They are sending a packet though as if they were from 111, 1020, 76, the cell phone to 111, 1020, 14 and impersonating that IP address, right? Oops, so this shows that, and like the ARPS hooping example shows, nothing actually verifies the identity of that IP address, when we end this specifically and this is the thing to always think about and we'll be thinking about this as we get further and further into different types of networking protocols is you get a packet, what information in that packet can you actually trust? And as we've seen here, really the only thing at the IP level that you can trust is the destination IP that it's actually for you, right? You can't trust anything else, you can't trust the source IP, you can't trust even the data that you were sent, you can trust maybe the destination Mac because you know it's from you but you also don't, can't trust the source Mac necessarily, cool. Okay, questions on maybe the local attacks that we talked about? So for ARPS boofing you are impersonating different machines, right? You're tricking, you're impersonating different IP addresses on your local network. You're saying that this IP address is belongs to my MAC address. Yeah, so IP spoofing is a general idea. So you don't need to ARPS spoof in order to IP spoof, you can send packets on a local network pretending to be different IP address. Yes, so if, let's see if, you could still, I guess technically yes, if IP spoofing was impossible, ARPS spoofing would also not work. You could still ARP poison because you could send ARP replies saying that this IP address is at this MAC address. So man in the middle is, so conceptually. So here we have Alice and Bob and here we have essentially Eve in the middle. That is, so man in the middle gets you two things. You can sniff all the traffic but you can also alter or drop or do anything you want, right? So you can, so this is different. I'd say spoofing is different, right? So this is a man in the middle where A and B are talking. If I just have Eve talking to B, but I'm pretending to be A, right? So B gets packets thinking that their IP address A but they're really from Eve, that would be impersonation, right? I'm impersonating. Eve is impersonating A whereas here Eve is performing a man in the middle attack from A and B. No, the switch doesn't know anything about IP addresses. So most switches operate only at the MAC level. Yeah, so all it knows is ports and MAC addresses. I mean, yes, it is possible but usually, yeah, I mean ARP is used by everything. Like look at your machine, do TCP dump, look at the ARP tables that's used all the time. It's super important. Yeah, so a good thing to think about. So in this case, so here we have A, B and E, right? So here it's clear Eve is let's say evil and connected to the network. So you may think, oh, this is easy to prevent. Let's prevent people from connecting to our network. Well, A, you can have a network like ASUs where there's ethernet ports everywhere. So anybody can just take their laptop and plug in. But even if you didn't do that, the other thing to think about is, well, what if E was a developer machine by Eve that downloaded some malware that's now running as Eve, right? So E could be connected to the network. So this can let you an attack of when you get access to one machine on the network to get you access to more and more machines on the network. I don't know an example, like an explicit example of when this has been used in an attack, but it's, but it definitely can be. And it's one of the tools inside of a penetration testers toolkit to let's say pivot from one machine to another to maybe, or to maybe sniff or steal username passwords or other types of information between different machines. How do you avoid being? Yeah, so you can have a static ARP table, but the problem is you need to put that on every single host. So if you have a new machine on your network, on your local network, and we saw networks can range from 253, 255 hosts, however you wanna think about that, to 65,000 all the way up to much larger. So how are you going to go and add those, like you'd have to update the static ARP tables every time you got one new machine, you have to add it to everyone on your network. So the question is on Stuxnet. So Stuxnet was Stuxnet basically scanned local networks to infect different hosts and spread that way. I don't think it's specifically used spoofing. Oh, so the question about MAC addresses, yeah. So this is a huge problem if you ever have a system where you either have two IP address, like two machines with the same IP address on your network or two machines with the same MAC address, it causes insane havoc. This actually happened to me in my lab doing my PhD. We ran out of IP addresses and the DHCP server would be reusing IP addresses. So you'd SSH to a machine and half the time it would fail and half the time it would succeed. And that's when you need to use things like TCP dump in order to figure out what's going on. Yes, so you should be switching to non-encrypted protocols. So that's, or sorry, encrypted protocols, right? So that's why there's a huge shift to move everything over to HTTPS. Google actually, I think recently in the last year or so bumped up, they will bump up your Google search engine ranking based on if you have HTTPS or not. Let's see, when the first ARP request is sent from A to B and Eve is trying to spoof, wouldn't B still know where the original message came from? No, so that's, so yeah. So B would see, let's say that ARP request from A, but if you look like on my network, right, we were getting ARP requests, like the time that things spend in the cache is pretty small, like 15 seconds or something. I'm sure it's different for different operating systems. So the fact that they're getting an ARP request doesn't mean to be that it's definitely getting some information later. So it wouldn't know maybe that packet got lost or the other thing to always remember in networking, maybe A just went away, right? So A sends an ARP request to B, B sends an ARP reply, and then A just shuts off. Like B doesn't know or care that it never got any packets, right? Cool, any other questions? We can, yes, chat will show up on the recording. It's on the lower left of the screen. So everything that's on this screen is being recorded. Let's see, cool. Well, we covered a lot. One of the coolest attacks that is really fun in networking. Also, so next time we'll talk about indirect delivery and routing. So now we'll extend the concept of, so we talked about exactly how packets move in your local network from one machine to the other. And then we'll look at how packets move externally from your network. So how they move from your machine all the way to Google. So yeah, keep signing those keys. Keep helping each other out. And yeah, hope you're all staying safe and staying sane. Yeah, I changed coal, I changed it so that the chat appears this time. The submission link will be open soon, probably tomorrow, Justin. I'll post it on Piazza. Cool. All right, see you everyone.


So I got a couple questions about using nvmr in the comments of one of my videos, and so this is just a quick overview of some of the points I wanted to highlight on using nvmr. These are a checklist of items I wanted to cover. The first thing is opening nvmr. So to do that is backslashrf. This will give you a console, but it also opens up the key bindings you need to run other things. Here I just ran backslashpd for executing a paragraph. There's also backslashd, backslashsa, backslashsd. All of these are commands you can use to execute lines or blocks or selections of code. Backslashro opens up the object explorer. So here I have an object called temperature. This is a data frame. You can switch back and forth between your objects and libraries by just clicking enter. You can also toggle your data frames or data frame objects. And you can also send columns to the console and see the output in your console. And you can keep the object explorer open so you can see objects populating as you execute them. After looking at the notes, we talked about rf to start nvmr. We talked about using execution modes such as backslashd, sd, sa, pd, backslashro opens up the object explorer. Backslashrh will open up a help. So if you want to go to a specific function and read the help file. So for example here ggplot you can run backslashrf and open up the help. Sorry, backslashr8. So you'd see a new window pop up and you can scroll down and kind of read the help page. I'm just going to run this on another function. I'm going to do backslashrh on read table. And again this will open up another window and you can go to a specific input, maybe the numerals argument. Here I'm just hitting pound to read details on the numerals argument. So I'm going to look at the bottom here. At the bottom there's, the main point of the script is to generate a plot. And so there's a plot function where I can run the whole script at backslashaa. And at the end a plot is generated. This does open up in a second window so don't expect a terminal plot. Alright, so here we talked about backslashrh, backslashaa to execute the whole script. Backslashrq will actually quit NMMR. So Ctrl XO will open up a dropdown to let you select a function for autocompletion. So here I'm typing Rn and then Ctrl XO and that will open up a dropdown so I can search through the functions. So that's a Ctrl XO autocomplete functionality. Rstop is something that I do use when I find out that my code is running a little bit too long so this little line here, 64 runs a sample that's going to take a long time to run. So I'm going to do colon Rstop to stop R so it doesn't just keep running. So that's really helpful. Our format is nice.  You'll have to install, I think it's a format R library, if you don't have it installed it'll just show up as a warning in your console and then just install the library it asks you to install. Alright, now onto the help commands. So this is useful for any Vim plugin that you use. So help nvmr will open up the nvmr help page. This is something you'd get with most large Vim packages, there's usually some kind of help file. So there's a table of contents here. Those red highlighted titles you can do help nvmr use, help nvmr key bindings, all of those are things that you can search for with the help command within this larger document. I'm just kind of scrolling through the help page. So what I cover here is really just scratching the surface. You'll find by reading the help page, especially I think the nvmr use section is where all the power is. So you'll see we cover backslash rf, there's a number of others and also there's configurations that the help page will tell you that you can set. Some people don't like doing, you'll see nvmr when you do shift underscore, you'll get the assign operator. I've become accustomed to that so that's not a big issue for me. Some people like to remap that. And so in the help page they talk about how to remap that. That covers I think the main topics in nvmr and I hope that gets you going. Thanks for watching.