 Let's get started. So thanks, everyone, for coming in today, Friday. Good to see everyone this morning. See, everyone's not quite as full as normal. I don't know if it's because of the assignment or what. We don't have to super spread out, right, everyone? Everybody says that, but nobody does that, actually. Even in faculty meetings, the faculty spread out like crazy. It's really fun. OK. So questions on assignment one? Maybe say something about the small package. Yeah, I will. Let me see if there's any other questions. Any other questions? We can use the redx package like we're using. Yes, you can use the redx by absolutely. The only packages you can't use are anything that does HTTP parsing. That's good. You can use regular expressions to parse it. You can use the URL library to parse the URLs. What if we use a part of the HTTP library that doesn't do the actual HTTP call? You should ask me if it's OK. Yeah, so I can make sure. Yeah. Does it have to handle multiple connections? What should a server do? Handle multiple connections. Yeah, it should handle multiple connections, right? Because the idea is you're creating a server that's a backdoor, right? So if you have a server and when you connect to it, you have to do some long running job in the background. When the administrator scans it, right, you don't want that thing to crash or fail or to not respond to that connection. You want it to respond and say, hey, no, no, 404, like look elsewhere. These aren't the drawings you're looking for. OK, some things that I posted. So I posted on here the list of apps of Ubuntu packages that are installed on the submission system. So this is all of them. If you know any discrepancies, please tell me. I can fix it. It's easier to fix it now rather than an hour before the due date. So a bunch of stuff on here. So if you need to see if your package that you want is on here, you can easily look on here. There's the link. I also sent a, yeah, so here is the link of all of the trusty packages. So trustees to links distribution that we're using, right, 14.04. So you go in here. You can find your package. You can look. You can craft. So the submission system is up all the way up. It's 90% up. Wow. That's a great perspective. So you can create an account, right, which you should do. All of your ASU IDs if you're registered for the course or haven't registered for the course should be in here. If you have any problems or it's not in there, please let me know or if you're here illegally and not actually involved in the course but you want to get an account here. I'm totally happy to do that. Just send me an email. I'll add your ASU ID on there. You should come up with a hacker alias. A cool hacker alias for later homework assignments. We'll be posting maybe some scores or rankings or how people are doing throughout the week, you know, so we can see who's hacking what systems. And so this is a checkbox you can use to say if you want to obdyscape that on the public, anytime your hacker alias is public, you'll be obdyscated. So you can, you know, be creative to the cool hacker alias and then a password. So I'm going to say this now. So I created this system. It does the bare minimum it needs to do so that we can test your projects, right? So did I do things like implement a password reset mechanism and email you your password thing? No, I did not. I'm fairly certain since it came out of the mailing list, I'm pretty sure that I am hashing and hashing very well all of your passwords. I think would be correct. So that should not be a problem. But that means that I can't, and I think it is faultless. I can't be correct. Yeah, automatically does that. So, you know, so I don't know your passwords. If you email me and say like, I don't know my password, then I have to manually go into the server, create a new password and change it. I'll probably ask the TA to change that at some point. So it's a little easier, but you know. So should you use your Gmail password on here? Why not? You're saying password on multiple sites anyway. Yeah, what if I'm lying to you, right? And I'm logging all of your passwords to bring in your Gmail account, right? It's not HTTPS. It's also not HTTPS. Yeah, because that's a famous setup. I'll try to do it at some point. But this is just your submission thing, right? It doesn't work. It's just to keep you all out from each other so we can tell you all apart, right? Cool. All right, so once you create an account, you'll be able to log in. And I just realized I'm in the wrong browser because I don't know the password here. Also, so I did say, OK, well, OK, then, a second. Let's see if this logging works. Yes. OK, this is my awesome hacker alias. So you can submit assignment one. So the only thing that's working right now is the smoke test because I had to, basically, I created these to do the smoke test for my system to make sure that you can submit things. They would automatically get assessed, all that kind of stuff. So I can, let's see, this is for my 591 class. So this should definitely not compile. I can submit a make file. And then you can submit as many source files as you want. I can do a smoke test. It will tell me that, yes, it was successfully submitted. The smoke test had 100 submissions. I don't know. It doesn't really matter. I can change that at any time. And so then I can check the status. And it's going to say that it's submitted and it's still pending. When it actually gets some output, it will tell me the output. It will tell me it failed to compile the project. And here's the first 750 characters from the output. Characters of output from, that's all right. So this will tell you what's wrong and it'll help you try and debug your program. And if we refresh, I don't know exactly how long this takes because I haven't timed this yet. But at a certain point, this will stop and it will give us output for this submission or everything crashed. But hopefully it does it in a way that we will never know about this because you don't know about it. Ha, there we go. So you get feedback pretty quickly. You also notice there's no fancy like, oh, it's in progress and there's no time remaining, right? So, you know, you have to give it some time. So yeah, it tells me that it couldn't, it tried to, so it tried to make, but it failed. So it tried to do this copy thing and it tried to look for a discovery file. The discovery file is not there. I can probably add that information here. We can see here in this test case when I tried to execute discovery, right? That didn't exist because I submitted a big file for a completely different project to do a completely different thing. So very soon, definitely by the end of this weekend, I'm going to have a way for you to take this smoke test submission and then submit it actually for project two so it can actually be evaluated with the real test cases. So I'll have it soon, but this will install, it's exactly the same process. So it's going to install all the packages you install. It's going to compile it just the way we set on the website. It's going to do everything. So that way, when it passes these two cases, then you know you're at least good to go that your program actually compiles. All right, any questions on this? Pretty basic. It's not super complicated. If you have any problems, email me. There'll be problems. I'll hand that off now. There's all my problems, but we'll be able to solve them together. Okay, important note about this IP address here. Oh, all right. I can't do that. Okay. So this is the IP address of my lab. 192.219.253.30. So do not scan or run anything against this lab, right? So this IP address is the external-facing IP address for our entire lab and all the research that we do. So the IP address is not fair game. IP address at this specific port is fine. It's forwarding to a server in our cloud where all this submission stuff is running. So if you find something on that or you find something in the website, please let me know, right? Be an ethical security researcher. As long as you're making a good-faith effort to not break into your fellow students and get their submissions and submit them as your own or otherwise interfere with their submissions, right? Then I think it's good. So this is a place you can play around with and try to bang on. So I don't know. I tried to code it very securely, but we'll see. Stuff happens. The one thing that's definitely not really fair game all I don't think... So the submission system, so we're taking code from you and actually executing it, right? Right. Which is actually what you want to do oftentimes when you're exploiting something, right? You want to get a foreign system to execute code of your choosing. We are doing that here. So use this responsibly. So I think I set it up pretty well so that you shouldn't be able to mess around with it, but those systems are running everybody's submissions, right? So if you mess one of those up and you've messed up that system for everyone else. So don't... If you do something really cool like you're able to exploit the Linux kernel or something and get root on that machine, that's really cool. You should let me know. But if you're running code on there to figure out the hidden test cases and then send them to you on TCP or an email or something, that's not cool. You're breaking the assignment, not the actual security of the system. Yes, we all know you're running code there. You can do whatever you want, right? But the point is actually implementing the assignments. Is that clear? Kind of fair? Fair rules? If you have any questions, just let me know. We're happy to talk about it. Do we get worked? Okay. So we've looked at that so far. We've looked at how the network works, how networking works. Does this look dark to you guys too? Yeah, this is the same problem that happened before. Let's see if just plugging... So you do see that, that it's dark on the sides. The system would, a lot of that would cause that to happen. All right, we'll try this one more time. Yeah, there. Maybe, maybe I have something to say. Resolution. I think the resolution switching between it definitely doesn't like... Okay, good. Little distraction. All right. So we've talked about how networking works, how packets move on our local network, right? What does it mean? What does a local network mean? Is that just like a vague term? Like, does it mean something? The local network means... In the same subnet? Yeah, we're on the same subnet, right? So when you configure the IP settings of your machine, right, the subnet says, hey, any IP address that's a prefix or within the subnet is on my local area network. So I know I can directly talk to any other machine on my subnet. Okay. So we talked about that, right? We haven't even gone into how packets reverse the interface and how they get out, right? We've only been looking at local area networks. And we've talked about why do we want to... We've talked about sniffing the network, right? We want to sniff the network. We want to be able to get information that we shouldn't be able to get. And so this is what we're going to look at now. So network sniffing is the start of a lot of local area network attacks. The basic idea is that... So by default, what's actually getting the packets on your machine? Your packets, your IP packets come into your machine. I have one of the layers it goes through. The network card. The network card, yeah. So the network card first, it maybe does some processing then throws it up to the kernel or the hypervisor depending exactly how I've done. Probably up to the kernel. And then the kernel sends it to you, the application if you're listening on that, right? So by default, what is the... You're making an efficient network card, right? What are you going to do if you get a packet that's not destined for your physical MAC address? Drop it. Drop it, yeah, right? You know you're not going to do anything with it, right? So you just drop it on the floor. You ignore it, right? Which makes sense because it's efficient. And the physical card knows its MAC address, right? But they, you know, either debugging or any kinds of other things, right? You actually don't want that. You want to see all the packets that are on the network. And so there's a way to set your network interface into what's called promiscuous mode where it actually will pass up all the packets that are not destined for that specific MAC address. And then it's up to the other layer to decide what to do with it. So the operating system has to decide if it deals with that packet or not and for your application. So is this it? We just say, bang. We set this little bit, this mode on our network card and now we're going to go. We can snip everything. You have to back it to an encrypted, I guess. Encryption is not encrypted. We don't really care about that. We still have to read it to know if it's encrypted, right? We still need to be able to read it at some point. So can we snip everything we want now? What are we talking about on networks? What do we know about how a local area network is working? Packet is sent to every other computer on the network. All of it has to first establish a connection to every other machine. Right. So we have ARP. So remember on ARP, right? So when we want to know some of these physical address, we broadcast a message to everyone in our local network. So are we going to get those packets when we send ourselves to Permissio's mode? Yes. Yeah. By default, it's broadcasting to everything in the subnet. So those messages are coming physically to our car. Right? So we can listen to that. Can we just listen to any other arbitrary packets? That are being routed via me. What's that? That are being routed via me, I could listen to all of those. That are being routed via you. Yeah. So what were the two architectures for a local area network, like the physical devices? Switch and hub. Right? So here, so does that affect what you can snip? Yes. Why? What's that? In hub, they broadcast to everybody. Yeah, exactly. If you're on a hub, you're done. Right? Every news packets are coming to you anyways because you're on a hub. So all those packets that you're getting in, as long as you're in Permissio's mode, you can read them. You can see exactly what's going on in the network. But if you're on a switched port, or you're on a switched network, it becomes more tricky. Because by default, packets destined for another MAC address don't go to your port. The switch keeps track of what MAC addresses are coming from which ports, and so that way it only sends out on that port. So we're going to look at that. So we talked about a little bit about kind of high level why sniffing. Some of the other reasons why you want to do sniffing because aside from it's just really cool, you can steal financial information. A lot of protocols that are still in use nowadays transfer authentication information in the clear. So if you ever connected to an FTP site where you had to do username password, that username password is sent on 100% in the clear. Same with POP, same with HTTP with basic authentication, actually with all the types of authentication. It's still sent over in the clear. IMAC, what's POP and IMAC? Yeah, reading email, right? SMTP is the simple mail transfer protocol for sending me an email. I don't know what they stand for. Any of you know what's up their heads? POP and IMAC. Post office protocol. Post office protocol and let's see what. Internet message. That actually makes sense. Post office protocol and internet message access protocol. Not very inventive things. So, because these protocols just send in the clear, this isn't a class about encryption, you can learn about how to break encryption and all that stuff, but here we're not even talking about encryption, they're not even being encrypted, they're just sending it out. So we can actually collect username passwords, files that are being transferred, mailed, and oftentimes we'll save that data to a file and try to analyze it later to look for these things. And this is stuff that happens all the time. When you think, well, we have SFTP, right? You can do that securely. We have HTTPS, you can do POP or IMAC over SSL, so all that's encrypted. But we've actually seen this when I was doing a pen test at a company in Santa Barbara. They gave us a tap on all their network traffic and we were listening to it and we saw that somebody was using an FTP server and was sending username and password in the clear so that when we connected to it, we were able to see that they were, it was there, I think it was one of their marketing people, like a little marketing site that was up there and so once we got in, we could poke around in there and we could have uploaded files and changed all that stuff. So, you know, this stuff happens all the time. You'd be very surprised by this kind of stuff that happens. Okay, so we want to, so I was going to say we could do it, we could sniff on the network ourselves, which you can do, but there's a lot of layers in between you and the packets. So there's a lot of tools that actually help make sniffing a lot easier and they're good for hacking, penetration testing, trying to understand and really also for trying to understand what's going on in the network. So really, if you ever encounter tricky troubleshooting network problems of why isn't this packet, this request getting to this server where it should be getting, these are the kind of tools you look for. Really good command line tool, the most famous, best one in my opinion is TCP dump, which collects traffic, so you can set filters on it as we'll see to change which types of traffic. TCP flow will take in a TCP dump file, analyze the TCP connections, the flows, right? So TCP connection, we're going to get to it, but it's IP, source IP, source port, destination IP, destination port, and that constitutes a flow and so it's able to take from the TCP dump and rip out all the flows into separate files so that you can see all the communication that's happening today. TCP replay is a super fun tool to play with because it will replay TCP dump traffic to another host. So you can try to record something, maybe try to play against your own system or back at them or something like that. Graphical tools, Wireshark is kind of the standard graphical version of TCP dump. It will look at the network, see what's going on, and try to reassemble from the raw IP packets into TCP flows and it has all support for all kinds of other protocols to then say, oh, this looks like an HTTP, that means this whole conversation is HTTP and so I can parse it and I know exactly that this is the sequence, you know, the mode and the request and the URL that's being requested and this is the response with the response code, all of that stuff. So TCP dump is really kind of the core. It's a simple tool but used all the time. And it's based on the important thing, kind of one of the important things here, is that it's actually based on a library so it uses this library lidpcap to actually do the network capture. And the idea is you can code your application against lidpcap and then you can run it on Windows or on Linux or on the Mac or whatever, any operating system and lidpcap is platform-independent, it will be implemented to do the packet sniffing. Also really cool is that you can specify an expression that defines which packets have to be printed or which packets to print or capture or how to print, how to capture. Very useful stuff for windowing out everything that's going to be in there. So we talked very briefly about that you need to set promiscuous mode on your network interface. So can all of your programs do that? If any program is running on your machine can it set promiscuous mode on your network art? Does it require pseudo? Yes. Does it require pseudo? Why would it require pseudo? Because it's part of the hardware. Because it's part of the hardware? You talk about hardware a lot though through the operating system that doesn't require pseudo, right? Or root, the L way of religion. Why would you need it? Do you need it? It might be by individual board you want to listen to so it might you stop that and find it. Exactly, yes. So this is actually a little forward preview but you have two applications running as two different users on your device or on your server. By default they can't access each other's memory they can't read each other's files unless it's explicitly allowed. They have privilege separation and it's a network application. It's probably reading on a certain port waiting for input files. So now if another file without any privileges can just listen for every packet that comes into the network and I've got all this other application's data and everything that comes in there, right? So you're essentially being able to elevate your privileges up from a normal application, a normal user to higher privileges. So that's why TCP dump requires root privileges to be able to set the interface to permissivism. One way to do this is you can have TCP dump output a file and then you can use TCP dump later as a non-root user to not have to do this. Cool, so let's look at an example. It's still held up. I don't know. Okay, this is the homework submission server but I should update that. It's not a good thing to show everyone. So I can run... So first I have to tell TCP dump what interface I want to listen to. So on Linux, I have configured, shows you all the interfaces that are configured and the default that shows you the interfaces that are up, right? These are the physical links. So this says Ethernet 0 it has this hardware address. So what's this hardware address? Mac address, exactly. And we have the internet address here. What's the mask name? We don't really talk about it. How's that mask work like this? Now, starting to build networks and ending to it with the hosts. It's relative to the subnet link. How much leads are reserved for the subnet? Yeah, exactly. So the mask specifies so the ones, right? 255, 255 is all ones. Those specify the subnet range and the zeros are the individual hosts in the subnet. So this means I'm on the subnet 172.21 right? Anything below that is on the same subnet. So I know I can probably pass packets there. So now if I do so if I just do if I do tzp dump actually kind of worried I'm doing this in front of everyone that's going to break, we'll see. Okay, I use the dash I option to specify exactly which interface I want to be listening on. I'll do Ethernet 0 what's the low? Hello? Let's still do back pose. Is it a physical? It's like a physical. To send to your site. It's like a kind of a I don't know, pseudo-design device. It's exactly the right term, but basically if you want to send a packet to yourself you can send it out to that device and it will just stay on your local machine within the operating system. It doesn't go out to the network if you try to do the hard thing to figure out how to get back to itself. I don't know what to do on this. What does it tell me? I don't have permissions. I tried to ask the operating system hey, set the permissions bit on Ethernet 0. It says no, because I don't have the permissions to do that. So I have to run it as pseudo. What does running as pseudo do? As root. Yes, it executes it as root. So we'll get into exactly what that means. If you're only used to Windows systems, root is basically the administrator to the machine. So we can run tcp.withsudo. Alright, and it's going to give me some output. Okay, good. I was waiting for it to give me a lot of output. Okay. So then it's giving me a whole bunch of information about this network, right? It's telling me that it's yeah, that there's and this is, let's see, okay, so part of the problem is so you see these IP addresses? Or this is the hostname, right? So actually we'll try to resolve IP addresses and turn them into hostnames for you to be nice. Honestly, they get in the way a lot of times. So I usually use this dash n to say don't do that. And minus v. Okay. Perfect. So now you can see here, so these are time stamps and these are the type of packet. So we can say at this time there's an IP packet from, why is there four? Why is there five octets here? What is that? For port. Yeah, the last one is the port. Exactly. So it's saying that IP 172.21.076 at port 22 set data to. So that's the directional. 1090.64.9 on this port. And these are the TCP flags that were set, the TCP sequence number, the act number, the window, any options that were set. That there's probably an act, yeah, there's an act back on this connection to know that we actually got the data and then received it. We're getting some, anybody know what an MBT, MBT, I think it is. It's not a rhetorical thing. Or I mean, I don't know. I don't know. We see other UDP packets, like this is running an open stack network. I don't know what other stuff's happening here. We can see here, very interesting, right? So it's saying that, right, so we saw this in the slide. So here we have a request for, hey, 172.21.068, who has that? And if you can find out, tell me at 172.21.0.24. And we can see there's a bunch of stuff here. So what's this, what's port 22? FTP? SSH? SSH, yeah, SSH. I think FTP is what, 20 and 21 or something? 21, 21, 21. There's two ports. SFTP is different. Yeah, FTP is a data in the control port. So there's like two. I don't remember exactly what they are. So 22 is SSH. So what is this traffic that I'm listening to? Who's SSH? Did I just stumble on the somebody's awesome SSH connection? One of my students, I can start messing with their experiment. Yeah, it's me. I'm SSH to this machine. This is my SSH traffic. Clearly don't want that. It's kind of boring. And actually, it'll just go forever, right? Because every time TCP dump outputs something, it sends data to me, to my machine over SSH, which means it's going to create a new answer in TCP. It's going to keep going forever and ever and ever. So then you can add options to the TCP dump to say, let's say we don't want port 22. So now this is going to be every non-EGDP packet. So R, we've got to reply. Okay. Yeah, so we say we have R. Where does that reply? It's there. Somebody said there. Down? There we go. Yeah, so we can see an R for fly, which probably I think was us. We're 172.21.076. But, right, we can see all this data. All this is happening constantly on the port. That's why you can look at the servers, right? They're constantly flashing. And it's all this stuff. It's all these packets. Our packets, every kind of packet is happening on the network. Yeah, we can even do, we can, if we want more information, I don't know what just doing Dash B does. Oh, that debugs the protocol more. So yeah, we can break down the protocol more. We can, let's say if we do, I think X will show us the actual Ethernet, the first couple bytes of the Ethernet. Sorry, of the packet itself. So we can actually look at the bytes and then look at them in text value. Oh, this is weird. We can learn a lot of stuff here. Oh. Okay, whatever. That's an IPv6 packet. So you can see lots of stuff in here. Lots of stuff happening on the network. That's why they're super complicated. So it has all kinds of things, all kinds of options. The ones I use are usually at Dash N to not translate the names from IP addresses to domain names. It also actually delays the TCP dump output while it's trying to resolve all these IP addresses so it's generating more traffic. You can print it in hex. You can use a specific network interface. You can repack it from a file. You can write to a file. The depth S option is really important. It used to be that by default it would not capture all the packets. Why wouldn't you want to capture all the packets? It's too much traffic. It could be too much data. You're trying to sniff on the network and it's just generating so much data. But the problem is if you're trying to, I've heard stories of people trying to do experiments and trying to do data capture. They forget the dash S option and they end up only capturing the headers of all the data, which is only about 60 bytes or something. You've lost all this really important data that you can't get. It is to capture all, so the default switch. It will capture all traffic unless you specifically tell it not to. Then you can specify a file for that filter expression that we were writing in the not port 22. This is the key. The frame body for the IP packet was 1500 bytes. Why would you want to set it to 65,000? Oh, the Ethernet. You may not be on Ethernet. I see. Because an IP could be that big. Okay, so those filter expressions are really important. You can define some kind of qualifier like a host. You can say where the host is a certain fully qualified domain name. PCP number was all that for an IP address. You can sniff certain subnets. So you can say you only want a certain subnet. Certain ports. The direction you can specify I only want to sniff packets that originate from host error. Or you can say destination. I only want packets that are going to a certain host. You can say both. I'm not going to skip over this. It goes faster. But you can specify the protocol. So if it's an Ethernet, I only want to capture Ethernet packets. I don't want anything else that's different. IP, ARP traffic, operators. So you can use and or not to develop as complicated of an expression as you want. What you can do here is that it's going to filter it from your file. Which can be handy if you're capturing on a system on a command line. And then you want to take that file transfer to your local machine to use Wiresharp to then look at that traffic. There's other kind of special characters. You can see it's a broadcast packet. It goes crazy as much as you want to do. The other thing, really cool thing is you have access to a raw packet data. So you can say give me all packets where a certain byte or bit is set. Like you can say IP datagrams with options. So you can say that IP0 and it with OXF is now 5. Then you can see all the IP datagrams that have options set. And so there's all kind of stuff you can do putting it all together. This is TCP dumping on an interface not resolving the domain names to domain names and all that packet info. This, the dash W is writing out to a file. R is just reading for the file. So what's the difference between the dollar sign and the hash or the pound? Ash is soon at first running as a root. So that's why there's no pseudo in front of there. So in the examples I'll try to keep that up. That's kind of the convention. When you're on a terminal or a shell that is running as the root user you be careful and think about what you're doing. Right? So this is the way to do that. Yeah, we can set an arc packets where the seven byte is a certain value or bit is a byte is a certain value. So it's actually built on, the really cool thing is it's built on this library lid pcap. So you're actually not just limited to using these premade tools, right? You're all programmers? Not your head? Yes. So you could build your own TCP dump or your own whatever you want to do, your own SNIP or using lid pcap. It has a whole bunch of options I'm not going to get into. You get actually the raw packet and then you can do whatever you want to it. You can read all the bytes. You can alter it, change it. You can cast it to an IP packet to then understand what it looks like as an IP packet, all that kind of stuff. So this allows us to SNIP but we said all those packets that we were just SNIPing were basically for my machine or packets destined for anybody else really for that we saw. It didn't allow us to eavesdrop on somebody else's conversation. It was only broadcast because presumably that system is running on a switched network and not a hub based network. Because hub is just broadcasting everything out. So what can we do? You're going to switch network. You want to be able to SNIP all the traffic. You want to be able to get all the traffic. So what can we do? Come on with the tax, your hackers. Yeah, in the back. You think Moscow will be the one who predicted to be the to mask or just change your Mac basically to be the battery receivers. So you're going to personally make them get some of the traffic. Look at all the hard requests and come up with all the hardware that's all the MAC addresses for all the other machines and then use that to kind of replace it to the switch. Yeah, you could do something like that. What do we know about a switch? Think about it. It's a layer 2 device. We can change the R table entries. It's a what? Layer 2 device. So we can change the R table entries. It's a device, right? The important thing is it's a device. How much memory does it have? A limited amount, right? Compared to your machine, right? I actually don't know. It's interesting to look at how much memory they have. It's probably safe to say it doesn't have 4 gigs of memory right? So what if we just flooded the switch with a bunch of MAC addresses, right? We made it, right? It's keeping track, just like you guys said, right? It's keeping track of all the R tables on the switch itself, right? It's mapping chords to our MAC addresses. What happens when that gets really big? It overflows. It overflows. You could overflow? Yeah, so you're a switch maker, right? You could put yourself in Cisco, or Juniper, whatever you choose, right? You make a switch. What do you do when the switch fails? Reboot? What if it happens again? What's not a good thing you could do? There's like 5 days, right? We're thinking about the switch from a switches perspective. The switch itself, like an engineering type thing, right? Or even a business thing. Should the switch just crash and shut off? Why not? So what's about your product? If you just got a lot of traffic and you ended up crashing, right? Like, it's a crappy product. Yeah. That's more like a quality of service kind of thing of how to ensure fair bandwidth allocation of the switch, right? But they draw a package if they're not being used. Even if you are going to down this one, right? Yeah, but I can make packages really fast. Like, I send out thousands of just independent MAC addresses on the network. The active record, this is actually the memory system that's going to remove whatever's there on it and then put it as what you have. Maybe. Maybe it doesn't. It depends on how they go to it. But in general, right? So, yeah. Yeah, right? You want it to just still work, right? Forget all the switching stuff. It can work just as a simple hub, right? And it'll keep working. Yeah, exactly, right? So, hey. Then somebody, it crashes, whatever, something, don't care. It's still going to work. So, if we do that to our advantage, if we know the switch is built like this, we can flood the network with MAC with MAC addresses, send out a bunch of packets. It's maintaining this mapping, right? And in some, you know, I'm not claiming this happens in every case, right? With every system. But, you know, so you're saying that it'll not maintain the R table and directly forward to the... Yeah, it'll just crash, right? I mean, you can't, whatever, any error happens in operating system but an error happens, well, you don't want to stop shuttling packets around, right? But let's just switch into a hub mode. So, this would be one way, right? So, you just basically force the switch to turn into a hub. So, you're basically using the fail state of the device. And because it can fail to a hub, and yeah, you have a performance degradation but it's still working, right? So, from a, you know, safety that's, but from a security perspective, right? Now we're able to transition that device into an insecure or less secure state so that we can now sniff all traffic. Yeah, in effect. What if the second switch comes in to this... What happens to this? Well, you have other issues to deal with. Yeah, then it wouldn't be a problem. Or it'd be like, what if it just drops the last map entry? Like, what if it's loaded correctly and it doesn't do this? Then you have to try other things. That's what we'll look at. So, the other thing we look at, right? We talked to somebody who said earlier that, well, we just duplicate. We can actually listen to all of our broadcasts and we can make our own list of IP addresses and MAC addresses. And then we can send out on the court that, hey, we're at this MAC address, right? We can send out packets so that way it associates the victim's MAC address with our MAC address. And so, ideally, the switch will record this in the table and send that traffic to our machine or both machines, which would be really good, because then that machine doesn't know we're actually doing anything, right? They don't know if they're missing packets. Well, then it's coming to us and we're good too. But part of the problem there is then we come to this typing game, right? Well, but as soon as then that other machine sends out a packet, then it's just going to put that entry in its table and associate that court with that MAC address and then when the reply comes back it's probably going to go there. So we either have to do this a lot and continuously, right, to make sure our entry is in there. But then we've kind of taken that other machine off the network, right? Because that machine can't really talk to anybody because it never gets a reply back, right? It tries to make a request. All replies go to us instead of them. We sniff a packet and then stop wait for it to reply and then go again but then we're kind of missing, we're still missing the packets also that it's sending, right? We're not getting any packets that it's sending out. So this definitely is an option. It has some problems. So what do we know about the ARP and some broadcasts, right? So Sygnac Tower works. So we broadcast and say, who has 172, whatever, whatever IP address? I am this IP address and this MAC address. Yeah, they send back, hey, they send back a response that says I'm this MAC address and I'm this IP address. So we think back to the protocol. What linked those two requests and responses? The first question. The IP address, right? So yeah, so when I say, hey, who has IP address, we'll say 10, I'm IP address 9, right, and this is my MAC address. And then when they respond back they say, hey, I'm IP address 10 at this MAC address, IP address 9. Here you go. So the two pieces of information that link it, right, are basically the sender's MAC address and the sender's IP address. Because that's how it knows to send the ARP reply back to that person. Isn't there, like, an ARP request like doing the wood process? Our reverse, our ARP is reverse ARP. Reverse, our ARP is reverse ARP where you ask, I think I'm pretty sure it's the opposite where you ask who has this MAC address to tell me and then they tell you their IP address. It's not used as much. That's why they're covering it too much. So what guarantees in the system or the protocol that we can't send an ARP request a response before we receive a request? We need the IP to send the response. Yeah, we need to know the IP address, right? But when we're a machine, right, we send out a request, we get a response. There's nothing linking those two things. So if we just receive a response that says hey, I'm IP address 9 on MAC address B. So we say, okay, boom, we update our table. So can we broadcast our reply? We can't, I don't think we can broadcast a reply that maybe ignored. I'm not 100% sure. What we can do is we can try pinging or figuring out who's on our local network so we get that entire table and then we can send each of them a request to say that so essentially we're spoofing or poisoning their ARP caches and saying that hey, that IP address we want to talk to is actually me, my MAC address. So this is a super cool attack. So the goal is we want to actually, this is going to allow us to send all traffic in between two hosts on the network with this ARP spoofing. Basically we tell victim A hey, if you want to talk to victim B it's my MAC address and then if you tell victim B hey, if you want to talk to A you have to use my MAC address and so this way all the traffic goes through us and we're able to impersonate and man in the middle all of that traffic. So we'll get exactly how this works on Monday.