Hey everybody, Dr. O. This video I want to cover the cell membrane also known as the plasm membrane. So obviously why is it important? The cell membrane is what keeps things that have to stay out, out keeps things that have to stay in, in, and also is a way to move material. So let's go ahead and dive right in with some of the key terms you probably would have heard about cell or plasm membrane. So let's start here with the fact that they're called a phospholipid bilayer. And that's because they're made of these phospholipids here which have that phosphate head and the lipid tails. Now the key here is that the head of a phospholipid is hydrophilic or water loving. The tails are hydrophobic. So I'm going to go back here to this image. The reason they form a phospholipid bilayer is because the hydrophilic heads are all exposed to water either outside or inside the cell and the hydrophobic tails are avoiding water. They're hiding from it. So if you were to pour these phospholipids into a glass of water, they would actually form a membrane like this. So both sides are happy. So that's where you get the term phospholipid bilayer. The other major way you're going to hear a cell membrane described is as a fluid mosaic model. This one's pretty cool. So let me jump ahead here and show you. So this would be what a typical plasm membrane looks like. This one would be of a bacteria. I'll explain why in a moment. But so the reason it's called a fluid mosaic model is number one. It's fluid because it's not rigid, right? It looks like a rigid cell. Whenever you see it, just a drawing of a plasm membrane, it looks rigid and looks like all these structures are stuck there, anchored there, and they're going to stay there. That's just not the case. The consistency of this cell membrane would be the same as something like olive oil. And the structures that are built into that phospholipid bilayer are actually just free floating through there. So think about things like floating on a pond of water, something like that. So that's the fluid portion of the fluid mosaic model. The reason it's called a mosaic, like when I think of a mosaic, I think of a picture made of a hundred or a thousand other pictures, right? So mosaic just means multiple different pieces. So yes, you do have the phospholipid bilayer, but you also have as you can see here some glycolipids, glycoproteins, and other types of proteins that are built right into it as well. That's why it's a mosaic, a combination of different structures that are put together in a fluid, non-rigid pattern. So how did I know that this would have been a bacterial cell membrane? Because there is one critical ingredient that's missing. Let me show you here. You'll notice you're going to see a lot of similarities here. But look what happened.  Look at those yellow structures. Those are cholesterol. So cholesterol is a sterol. And what cholesterol does is it keeps your cells from tearing open. It keeps them from lysing if water rushes into them. So a reason this is significant is because bacteria don't have these sterols, which is why they need cell walls outside of their cell membrane. So our cells don't need cell walls for that reason. That's why cholesterol is wildly important. I always like to stick up for cholesterol because it's been so demonized, but every cell makes it because every cell needs it. So it is very, very important. So that's where you get the fluid mosaic model of the cell or plasma membrane. So I'll just go ahead and stay here and again, just talk about if in a word, what I would call the plasma membrane is a gatekeeper. And that's because it is a selectively permeable membrane, also known as a semi permeable membrane. So what that means is some things can freely move through the plasma membrane. Other things either can't move through it or have to be funneled through it. So for example, like your oxygen and carbon dioxide, they're both small, they're both lipid soluble. They can just traverse right through the cell membrane. They go wherever they want really, whereas other things are either going to have to be transported in and out or they're just not going to be able to make it through. So that's what it means to be semi permeable or selectively permeable. Reason this is so important is because to be a living cell, you have to have a plasma membrane that is selectively permeable. If you have a freely permeable cell membrane or membrane, then anything goes wherever it wants, which means you can't keep things inside the cell that have to stay in. You can't keep things out that have to stay out either. So that wouldn't work. And then if you had an impermeable membrane, nothing could get in, which means you couldn't get food or resources into this cell and nothing could get out, which means you couldn't get waste products out. So that's not going to work either. So I call it a gatekeeper or a bouncer because the plasma membrane or cell membrane determines what does get to enter and leave and what can't. Now again, it can't control everything, like oxygen is going to go wherever it wants, but that's why I like that term gatekeeper. I also do call the plasma membrane the brain of the cell. I know when you talk about control centers and brains, people use to think of the nucleus, but the plasma membrane is what senses the external environment and responds. Just like your brain receives sensory information and then responds. So I like to think of it as really a much more important piece than just a wall. All right, so that is the fact that your plasma membranes are selectively permeable. We've already mentioned why cholesterol is there in your animal cells and just to go back. So this would be a bacterial one, lots and lots of similarities, but no cholesterol. So outside this cell membrane would be a cell wall. There's different types of cell walls, but I won't go into that right now. What else to cover here? So I just wanted to put the structure of cholesterol here and just so you could see it. But I think that's about it for the plasma membrane itself. Now I do want to just show you, you see a lot of different structures here, these different shades of purple and blue, these proteins. So I have one more image that shows the different types of proteins. There's your phospholipid bilayer with the hydrophilic heads on the inside and outside and the hydrophobic tails on the inside. But notice these are the different types of proteins you're going to see inside these membranes. So an integral membrane protein is going to be one that runs through the entire length and is built into that plasma membrane. And then you have your peripheral proteins, like the little ones there on the top and the bottom. And the last group you can see labeled here would be the channel proteins. They're going to have a pore so things can move through them. In other videos we'll talk about chemically gated channels and voltage gated channels and all this. But for now I just want to kind of walk through a recipe for how to make a plasma membrane and what all these key pieces are.  So that fluid mosaic model, all these different pieces come together to form this cell membrane. That is what makes a cell a cell and makes a cell, makes it possible for a cell to be alive. So all right, I hope this helps. Have a wonderful day. Be blessed.


Hey, hello, and welcome to Show and Tell. It's me, guest host, John Park, and you are here just in the nick of time to catch a bunch of really cool projects and things that people have elected to come on and show and tell. One of the things I'm gonna show and tell is I just noticed today that this, we can do automatic background blurring here in StreamYard now, which is fun. But if you move real quick, you can reveal the trick and see sharp stuff back there. So I'm gonna be self-amusing with that. But you don't have to. You can instead be amused by all the cool stuff that our guests have brought on. So to start off, we're gonna head over to Las Vegas, Nevada and our good friend from DigiKey, Kevin Walsest. Hey, JP, how you doing? Good, thanks. How are you? I am good. I am not in Minnesota where it is minus, I think minus 15 below right now or something crazy like that. I'm in Las Vegas and I am attending CES. Ah, right on. The first event I've been to in a few years and it's different, but what I really wanna share with you guys, first off, thank you for 2021. It was a great year for DigiKey. Everybody from the entire 804 community, you guys are all fantastic. I'm not sure what we sold with inventory constraints, but we had a really good year. So thank you, everybody. Excellent. And we're hoping inventory gets better and better as we go through 2022. So what I wanna share with you, what did I see at CES? What's big? What's driving innovation for the next 2022 and beyond? One of the coolest things I saw today and I saw it at a number of booths is artificial intelligence. You walk by these booths and they have cameras set up with age recognition and there was one where I turned sideways and it would recognize that I was wearing a backpack and it had a 65% chance that that was a backpack. It was really cool to see how people are using artificial intelligence in different ways. Another company had an assembly management setup where if you had to put 20 bolts onto, you're building a motor and for some reason you missed one, this AI would detect it and it would not let the conveyor belt move forward. It's just, they had 1.5 millimeter range of accuracy. So it was unbelievable. And then of course, electric vehicles. There's so many companies making electric vehicles that I've never heard of. It was pretty interesting. And is that a range from scooters or smaller up through cars and construction vehicles? Like what kind of stuff are people making? It was everything. There was a lot of scooters. There was more consumer vehicles than I've ever seen and there was even like five or six different semi-tractors and semi-trucks. Even like combines and excavator equipment. It was crazy. And then the third thing I wanted to hit on is how do you make everything low energy? I mean, that's the big thing. We want to use as little power and get the most bang for a buck. So basically I wanted to come on and thank everybody for a great 2021. We're looking forward to 2022. We're glad it's here. And I look forward to another great year spent on Wednesdays with all of you five folks. Likewise. Thank you so much, Kevin.  All right. Correct. Take care. Take care. All right. Next up we got our own Dan Halbert. Hey, Dan. Hi, everybody. I've got my friend Einstein here. Hey. Walking some of the mess on the bed. And so what I'm going to show you today is that I'd like to show you another demo on the continuing saga of how to use async.io, how to do cooperative multitasking and circuit Python. So we have kind of a canonical example here which is a new pixel animation. You can see it's spinning around here and we like to control like the direction and how fast and how slow it goes.  It's kind of painful. But if instead we look at writing this using async.io tasks, you can kind of break it up into nice pieces and have it really more modular than you had before. So for instance, we've got new pixel stuff here. Notice I got the, this is a non sequitur but I've got a piece of paper over this because it's much easier to see the new pixel when it's got a little diffuser. So that's a hint for anybody who's doing a demo and I got the brightness turned out to 3%. So we have a little bit of shared state here. We have a circuit Python class called controls and it remembers whether or not you're running in reverse and remembers how long a delay there is between the steps of the animation. That's all it does. It's just a little bit of state. And we've got a classic rainbow cycle, pixel animation here that's running all the time that uses the values here to decide which direction to go and how long to wait. Like it's sleeping for the wait time. And then we've got two pin monitoring things here. One monitor is a direction button so you can flip the direction and the other monitors two buttons to make it slow down or speed up. And all these things do, they use the keypad module which is new in circuit Python, relatively new past few months and they change the values that are in this object here. So then we start three async tasks. One for the, to monitor the direction button, one to monitor the speed button and one to monitor and want to actually do the work and we set them running and they talk to each other. So if I press like the button here you can see it go in the other direction. And if I press these buttons like I press the slower button getting slower and slower and slower. And it's not profound, except that much easier to write this code than it was. It is always hard for me to do this kind of stuff. Honestly, this is profound for me because it's sort of the core of so many of the projects that I want to build is I just need some things happening that are essentially happening at the same time and it is always such a challenge for me to code my way out of that sort of one thing at a time that normally is going on. So. Exactly, we hope that this will serve as a canonical example. We're going to, this is going to be a canonical example we'll put in a bunch of guides. Kat, and he's going to work on optimizing this for each board. Yeah, I know, really excited about it. Look for it on the async.io Crawford multitasking guide in a few days. Oh, awesome. Thank you. And thank you for all the work that went into making this as seemingly easy as you've made it for the user. Cause I know under the hood it's anything but, right? To get this. We also thank MicroPython people who did a lot of the work on this. Yeah. Appreciate that. Fantastic. Oh, awesome. Thank you so much. Very excited about this. You're welcome. Thanks, Dan. All right, we'll see you next time. Way cool. All right, let me bring on Noah and Pedro. Hey guys. Hey, Javi. Hey, Happy. 2022. Almost said one. Yeah, same to you. Yeah. Happy 2020. Another hug to Dan, man. Dude, we are going to definitely use that in some sort of proper. Yeah. Some sort of enclosure. Something to do. That is too freaking awesome. Yeah, so easing into 2022. Lamar found these that, you know, she's always seen all the trends going on on Twitter.  And then I was like, I'll put that on the project list. It's pretty cool. It was in base camp. And then my freaking ear pods went right through the wash. No.  Oh man. Work it over. But now I will be wearing these because if I had these, took them off and put them in my pocket. I definitely would have saw that. So these are all the NinjaFlex 3 printed. So they're nice and flexible. Show it over here. And of course, the other thing Lamar wanted to show off is that fairies come in all different colors. So we got all these. All these skin tone colors in the Adafruit shop. We have like the almond peach and the, I think it's caramel. Caramel candies, what my color is. And then I forget what the other darker ones are. But of course you can be like purple, like I don't know, avatar or something or green baby Yoda. But yeah, done a couple of different cosplay ideas to go ahead and hold on to your whatever ear buds. Some of the ones that she linked to, they all came with like, like their own ear bud and were like, people already have their own. So we wanted to design something that you could use with your buds, you already have. So of course all fusion, you can edit the files that are just Bayesian curves. You can edit to whatever pointiness or your shape or whatnot. And they fit like the pros and the second gen and the third gen ear buds. So nice, simple little project that would have definitely been useful last week for me. So check that out. Learn guide and all the files are up on the learning system. Yeah, maybe if someone's customizing that they could add a little notch for their N95 masks to hook onto as well.  Yeah, I wish I thought of that. User mod will be user mod. Yeah, there you go. Very nice. Thanks for bringing those.  So check that out. And I think it was like a layer by layer on the, it's a pretty stuff. Yeah, yeah, QT5. Yeah. Cool. Thanks. See you guys. Thanks, P. All right. So let's see, we've got what about 20 minutes left. So if everyone could take just a couple of minutes we have quite a few people to show up your project we'll move through fairly quick so that we can then have time to get to ask an engineer which is gonna be up next. So let's bring on our own Jepler next.  There you are. Hello. I am not hearing you. I do not hear you. I'll go to the next person and we'll come back to you. All right. How about Todd Bot? Let's bring on Todd Bot here. Hey, Todd. Hey. So you may recall I was playing around with putting the Mazi Arduino Synth Library on this thing. Very cool. I've now been putting it on the much more powerful and much smaller QTiPie or Seeds Jiao. And let me switch my cameras so I can actually show you this and have them play. And so here it is. Just plug it in. Get a little power, turn it on. And this one I call 80s dystopia. Oh, it's ominous. Very ominous. And it's just an algorithmic synth program that plays. And then this one is called basically the same circuit. Just the QTiPie, the jack and a resistor and a capacitor. This one, whoop, wrong way around. I call 80s chase. Yes. Yeah. Get to the speed boat. Yeah. So yeah, so that's what these things are. A lot of fun. Mazi is a great library, but it is sort of like a 10 year old library that is made back in the eight bit days of Arduino. And so it shows a little bit of its age, but it works pretty well. And for a little tiny $5 microcontroller, you can make synthesizers out of them. It's pretty cool. And I love the idea of just carrying a collection of songs that's each just on a different hardware project on a breadboard. Yeah, which you feel, you know. 80s chase for sure. Thanks, Todd. Cheers. All right, let's try again with Jepler. All right, is there audio this time? I hear you. Hey. That'll teach me to come to a different computer. I was a little bit scrambling, but anyway, I put a 3D printing guide up on the 80 fruit learn system last week. And it is this little thing. It is a 3D printed lamp. Beautiful. No microcontrollers inside, just three meters of LED strips. And then you can dim it, whoops, with the little variable power supply from the 80 fruit. So I can't get this in frame and turn it, but you can turn it to any brightness and there's no flicker. And anyway, if you think this is interesting, you can check out the guide on 80 fruit learn system. Very cool. And that's a set of 3D printable parts that you assembled. So there's 12 prints around the outside and you stuff the LED strip up them carefully. Wire them all onto a board at the bottom and just stick in your barrel jack power supply. And I'd love it if somebody would figure out how to like make it a ceiling lamp. Oh yeah. But as it is, it just sits on a desk and looks great. Oh, it's beautiful. Really gorgeous. Thanks for putting that together and for sharing the guide and looking forward to seeing some remakes with that. All right, don't blind yourself. See you around JP. Bye. All right, next up we got Foamy Guy, who is a pair of cameras. Hey. Hello, Jim. Hello, JP. So I also owe a hug for this one to Noah and Pedro who made the CAD files. They make CAD files for a lot of the 80 fruit parts. I was able to import the CAD file from the feather RP2040 into Minecraft. And then I did a little bit of decorating on it, turned it pink to match the pink feather that I have hooked up to it. And then I thought it would be cool if we could kind of link the two together. So I have written a plugin for Minecraft where it allows the feather in the game to link up with the feather in real life. So we have this one hooked up to pin D13, which is a little LED on the feather so I can turn it on and off using the lever inside of Minecraft. We also have D5 over here, it's hooked up to an LED, just an external one. So essentially the same thing, but we can turn that one on and off. And then we can also do inputs the other way. So these ones are hooked up to pistons and I have them hooked up to these buttons. I can push the button down and it will raise the piston. And this one's also cool because it has this bouncy block on the top of it. So when you push it, it will kind of bounce you up into the air, which is a lot of fun. That's so fun. And then I have two more here. This one will shoot a snowball. I can push the button here and it will fire a snowball out of the little dispenser here. And then this one over here is the last one that I have hooked up, which is hooked up to this physical switch. So it's like a big old metal switch up here that you switch back and forth and you can flip the switch to open the secret door there and walk through, get to the other side and you can switch it right back like that to close it. Oh, it's fantastic. So yep, that's what I've been up to. Again, thanks definitely to Noa and Pedro. It would definitely not have been as cool without this model. This was really cool the way that it got imported but this has been a lot of fun. So love it. This is really true. Is this something that you are gonna show people how to do or share or maybe just demo it for the- Yeah, definitely. So I've streamed a bunch of the work that went into it. If folks are interested, I have a couple three or four streams on YouTube and Twitch, you can find them where I went through the process of making this. And I definitely will publish all the code and everything as well, the plugin and the code that runs on the feather. That's great. Thanks for doing that. This is really, it's just a joy to watch that. It's really fun. Yeah, thank you. Great job. Thanks, Tim. Yep, thanks. See ya. All right, that's super, super cool. Cool. Let's see, next up we've got Michael. Hey, Michael. Hey, hopefully my camera's not too laggy.  But yeah, recently, actually last week, I got the new QT Pi, the ESP32 S2 one. And I've been having a lot of fun with it. One of the things I did was this. I basically, oh, is that showing on the screen? I don't, oh, there we go. There it is, yep.  So I could get JSON API data. And I wrote like a little thing with it. And then another thing I've been doing with it. Oh, not that, there we go. Hopefully that shows up. But I'm trying to make another watch. I made another watch before with the glasses driver board and it got timed with Bluetooth. But because this syncs with Wi-Fi, I can just get the Wi-Fi syncing from a web server. So that's the idea behind it. And yeah, my camera's super laggy. I don't know what's going on with OBS, but hey. Right, but cool projects. And those are both, did you say those are both with the new S2, the QT Pi? Yeah, it's both with the new ESP32 S2 QT Pi which is super fun. I'll post the JSON parsing thing in the Discord. Awesome, good. Thanks for doing that. Those are looking really cool. It's very exciting. Thanks. All right, thanks so much. We'll see you next time. Okay, next up we've got Liz. Let's see, DIY. Hey, Liz. Hey, how's it going? Good, thanks. What's happening here? It's very yellow and cool looking. Yes. So I've built up a passive mixer. So it's a four input, one output. And passive mixers are cool because they don't need any power. So if I just bring up the main out, got two synths going. And yeah. We're not seeing camera update, but we did hear your synths getting mixed, but it's a still, it got frozen, unfortunately. Oh, okay. But we can imagine what happened. You turned some knobs on it. Yeah, I actually switched to the pots. Yeah. And there's going to be a learn guide coming out on this. I just got into review this afternoon, so. Excellent. And so this is just, you said it's a passive mixer. So it is just pretty much potentiometers. Yeah, and jacks. Yeah. So we've got the guts here. Oh, we're still not seeing any image updates. No, no. So we'll have to look at the guide then or come on back next week and we'll take a look inside. Very cool and beautiful print. Thanks for putting that together and showing it off. Thank you. Have a good one. Bye. Okay, let's see. Next up, we have Dylan. Hey, Dylan. Hello. How are you doing? I'm doing well. Thanks. How about you? What's going on? So I have a little keyboard project to show. I'm going to try to flip my camera. I think I just, I might have to, I haven't used this app before. All right. Hey, there we go. Can you see that? Yes. Okay. Yeah. So I kept seeing this cute little keyboard called the 2% milk all over the internet. And so this is kind of my little remix of that. 2% popsicle. It's adorable. Oh, sorry. I can't quite, Oh no. Well, maybe he'll come back, but that was too adorable. I'm dying to know what went into the making of that little popsicle macro pad. So try to come on back in. If you can otherwise, please come back next week. All right, let's see. Let's move on. We've got Duke here waiting to come on. So yeah, I think they got booted. They might've touched the wrong button on their app. All right, so Duke, hey. Hello. Hello. So actually my project could directly relate from Dan's improvements that he's been making. Yeah. So I've been working on some lights to put in the back of the soft top of my truck. So it's got the aluminum rails that the soft top drapes over. And so I've been going through and slowly designing a iterations of clamps to clamp around that pole. And then I've kind of ended up at this final design where I feel like it's not going to push against the fabric and minimize this hardware and is flexible enough to get around the pole. And so what I'm going to do is it's got two poles that go across that I want to put like precisely a meter of LEDs across. Let me see if I can share this. There we go. So I've been working with the NRF 52840 and a couple of the new potentiometers and some rotary. So we have brightness controls, color control and then a mode button or a mode rotary. So then what I want to do is use the second rotary to select the effect and then the select one to select the mode. Right now I just have it on one rotary. But it definitely would benefit from a synchronous input. So many projects do. That's great. That was really cool. So this is going to be, you say it's going to be interior lighting? Yeah. So it's a soft top that goes over the bed of a truck. And so if you're camping out of the bed of the truck having lights inside will be nice. So one of the effects that I was actually playing with was actually the sparkle effect that I believe Katni did. Yeah. Where it kind of will do like a little night sky blink. Oh, nice. That's really cool. And then just even if I'm working out of the back of the truck, if I just need to get something at night or whatnot, be able to turn it on. So one of the things I actually did too is that it has a high brightness mode where these are RGBW LEDs. But I have a pretty small BEC that can't handle both strips at full brightness with RGB and W on. But it'll work for the burst. So I have a program to time out where it can only be running in that for like 30 seconds. And then it requires a 30 second cool down before it'll allow you to do it again. It's smart. Yeah. That's probably been working on. Very cool. Well, nice looking project. And please come on back and show us some pictures of it or video of it up in the truck when you get that snapped into there with your little clamps. Very cool project. Yep. Thank you. Thanks, Duke. Take care. All right. Okay. Well, I think that's gonna do it. We are gonna have a few minutes to go and grab a beverage before we have Ask an Engineer coming up just in five minutes. So stay tuned for that. And please come on by next week with your projects. Thanks everyone for bringing your excellent projects on this week to show and tell. Freighter for New Industries, I'm John Park and I will see you soon. I'll see you tomorrow on John Park's Workshop, in fact. Bye-bye.


Welcome back to DEF CON 28 safe mode blue team village live stream today. We're going to be talking with their arms talking, but he'll be talking Connor Morley. Discussing our haven the UEFI memory space decision to be misused reminder if you have any questions for the speaker. You can obviously reach them at their Twitter handle dealing with DM then within the discord channel or reach them on the flamingo hotel text talks track one will be watching for questions there. And over to you, Connor. Thank you very much. So hi everyone. My name is going to Morley. I'm a threat hunter with a secure countercept, which is an MDR DRT service. Today, I'll be talking about the UEFI memory space, how it can be exploited by a range of attackers and how I can defend against it. And I give it the upname of Alta Haven. So, proper agenda, what we're going to run through I'm going to do a quick crash course on what exactly UEFI is, why this is of interest to attackers and defenders and how to exploit the UEFI memory space. Regardless of your point of view, so all the way from APT actors all the way down to script kids. And you've got to go over some of the issues with defending against exploitation of this memory sector, how we can overcome those difficulties and monitor this memory area, and what this means for others in industry. So let's dive straight in the course of what exactly is UEFI. So a lot of people may have heard the term UEFI may not know exactly what it is. So you if I stands for the unified extensible family interface. It's the successor to BIOS. Most people will be familiar with BIOS basically the output system. It interfaces between the mechanical elements of a system and its operating system. So effectively it works as a translational between the operating system and the firmware hardware of your device hence firmware interface. And so for example, if the operating system requests a file to be opened, the file command gets run from the OS through the UEFI to the firmware of your storage device, it then allocates that memory sector and returns there and then that's how it's read. It's a very, very general basic overview. It's key for all system functionality. It's conductible boot operations. It can as I said, it conducts all interfaces between between the software and hardware. And it is essential and all modern computers. So it is found everywhere regardless of operating system that you're using. It's also widely considered almost secure and BIOS. So we introduced the concept of some secure boot. So secure boot is the idea that when drivers are loaded at boot time, the REM signature is checked in order to guarantee and verify that they're the correct and authorized driver. This idea of secure boot actually eliminated a really easy physical access bypass to older machines, which basically means as soon as you had physical access to a machine, you could easily bypass any security. One of the key things to mention about UEFI is that it is stored on the independent chip on your motherboard and NV round chip, which is totally isolated. It's its own independent component of the machine and it is attached to the motherboard. So it's completely isolated from everything else. It is its own piece of kit. So just to really intensify and solidify where this sits in your computer. So the UEFI, as I said, sits between your operating system and firmware and the firmware that talks to the hardware. So operating system, if you want to talk to your hardware, has to go through the UEFI. It's essentially, it is essentially just a translation layer of operating system commands down to firmware layer commands to receive whatever the system needs to do. So most people, when you're talking about UEFI and BIOS, they'll think of this sort of screen, you know, your boot screen, and sometimes with, you know, boot manual settings as one of those options at the bottom. But the majority of the users will see this sort of screen and just, you know, folk by as it puts up the computer and not the BIOS. Some people will obviously go into those settings, which looks something like this. So on the left you have the older BIOS settings configuration menu. And on the right you have the newer UEFI interactive GUI. So one of the things that UEFI actually allows to do is the use of graphic user interfaces, which is not available in BIOS. This allows for, as you can see, this is there, allows for branding, it allows for, you know, CPU temperatures and all this sort of stuff. It also allows for point and click, so use for mouse, whereas BIOS doesn't. This is to do primarily with how UEFI operates using UEFI binary files, which allows it with these layers so you can't talk about it. Again, so this allows for security settings, it allows for the boot order to be configured and such things like that. So most people will think this is sort of the limit of what you can, oh, this will be like the limit of what most people have dealt with. But the UEFI itself is actually a lot more complicated. It does a lot more in relation to your host. It runs the entire time that your computer is operating. And so it's not just the boot service, it's fundamental to all operations of all modern hosts that you find around the world. So there's a lot more to it, a lot of people and I'm not privy to. The key thing to note is it is always active, it is essential, and it's isolated from the rest of the system. So why is UEFI interesting to attackers and defenders alike? So why are attackers' red teamers looking at UEFI? So as I said earlier, the UEFI is isolated from the rest of the system on its own little island of Silicone. So it's segregated from the rest of the system by design. Because it's isolated, it's not well known about and it's considered quite low level technology. It's commonly overlooked in a lot of attack situations and normally isolated to the sort of APT root kit, sort of attack frameworks and methodologies and TDPs. So it's normally overlooked in most operations by defenders. So it gives this sort of idea that it's lucrative and valuable for attackers. The other thing to note is that remediation of anything on the UEFI is really difficult. With a lot of components on a machine, obviously you can shop and change them, hard drives, RAMs, if you really had to, changing the UEFI, if you had to, much more difficult. A lot of the time they're soldered onto the motherboard. So as you can imagine, changing that is a real pain. And even removing it, obviously interactively through an interface can be really tricky if you don't have experience with the UEFI. So as I said, there's a whole section later on that I'm going to cover about why remediation is difficult. And I'm going to go over that in a lot more detail. One of the other things to note about the UEFI is that by standard, by its own, by the standards of UEFI, everything written to it is automatically put as persistent. So it's non-volatile and everything that's written will automatically stay there throughout boots, which as you can imagine, from a sort of persistence attack methodology, sort of mentality, is inherently quite valuable. So although this is why attackers are looking at it, why are they looking at it now? What exactly has changed? So as I said, it's normally as being root kits and level of actors, ATPs, because it's a complex sort of area that a lot of people would look or don't really understand. But what's happened is that since Windows, actually since Windows actually, surprisingly, but more recently since Windows Vista and onwards, Windows has, Microsoft had gradually introduced more runtime access to the UEFI memory space. So the UEFI runs boot services and runtime services, and through the iterations of Windows and obviously their updates and newer versions, they've steadily introduced more and more runtime service access to the UEFI memory space. So research done last year at DEF CON, DEF CON 27, Michael Libowitz and Tova Timson, they did a whole presentation on this type of attack about how to avoid 300s and EDR by utilizing the UEFI memory space because it avoids detection. I was really recommending their research, really cool stuff, and obviously this is where this entire piece of research stemmed from. And they went into how they could use native Windows API functions to read and write into the UEFI memory space. So originally, when I first saw the talk, I thought, oh, this is worrying, but surely there must be a area around this. Again, this is a section that will come later on, but it was a gap that was found, or that I, when looking into it, I did see was in the security defensive structure. So because of their research, there is now very, not because of the research, but because of Microsoft's expansion to the runtime service access. There is, by their exposure, Windows API basic functionalities that allow read and write access into this lucrative, sort of not well understood memory sector that's isolated from the rest of the system, which is pretty valuable. So how is it that the UEFI memory space is exploited all the way from the AAPT actors, all the way down to strictities or newer attackers? So the way LibreWidth's intims and exposed was to use a C-sharp, pre-compiled payloads, using kind of 32.da.l exported functions, and get a firmware environment variable EX, and set a firmware environment variable EX. As you can imagine, these are the read and write functions. With these two methods, the attacker can install a payload into this memory space and then create an external persistence mechanism to read from this isolated memory space at a later point or by trigger in order to run a more malicious or internal payload or a beacon or agent or anything like that from the UEFI memory space. This obviously requires the payloads to be pre-built, so they have to be autotargeted and have an understanding of where they're going and what they can leverage out of the environment they're going into. It also has to specify at the time of compilation the variable names and the GUIDs or the vendor IDs of the variable they're going to be injecting into the memory space. And because of this, and obviously you have to have an understanding of how C-Shark can be used for API DLL interactions in order to leverage the 32.da.l in order to access the UEFI and write into it. So you have to have a good understanding and preparedness of who you're going to attack, how you're going to attack them, and obviously an understanding of the programming language itself in order to utilize it. So as attack methods go, this is quite advanced compared to obviously how you're pasting off the internet and running it as you like. You also have to have an understanding of UEFI variable constructs, their attributes, and how they're constructed. So there's a lot of layers to this sort of attack, but it is very powerful and you can leverage correctly as demonstrated was very effective. I decided to approach this from another angle, so instead of going for something pre-compiled and thought about what if we could just do like a drive-by sort of attack. So we went back to the old tried-and-true PowerShell, which is able to leverage the same DLL import functionality. So ignoring high-level codes, we found that the same functionality into the UEFI and space read and write could be annulated in PowerShell just as effective. You can do this as a PowerShell script or you can actually do it as a on-the-fly sort of write to terminal and execute, and both work just as well. The only caveat for both attacks is that it has to be run at an administrative level. The reason for this is the session that you're using in order to have firmware edit privileges. You have to do token escalation that can only occur as an admin. So emulating what Timsman and Liberwitz did, I was able to replicate this as a PowerShell, as I said, as a script and as a drive-by, and they were both extremely effective and fully functional. It was only after I'd translated their C-Shop code into PowerShell I found that a guy called Michael Nejas, sorry if I'm pronouncing that wrong, he's actually already written a PowerShell module online which you can download and import, which has the read and write functionality nicely wrapped as two separate functions, arguments, and all this sort of stuff, making the copy paste of my PowerShell scripting even easier and much smaller because you don't have to take into account the token escalation and importing the APIs and understanding how to do that. It does it all for you. So we've gone from pre-compiled targeted C-Shop payloads to very small on-the-fly copy paste PowerShell scripting, which as you can imagine, if you put that online, anyone can tweak the payload inside in and start playing around with it, and it's much easier to do much quicker. So I made some POC code. There's a link at the end for a repository where this is available to everyone. So the POC code is PowerShell, and we've done some reverse shell payload. The idea is that you've done some reverse shell payload into your file and then immediately runs it. So it's just a write, read, execute. Obviously in the real world, as I said earlier, you'd obviously write it to the memory space, you create persistence, read it later, extract it in an execute. For a POC, this seemed to work very well. So when I tested this, so the antivirus that I was using on the host, Windows 10, it detected obviously the reverse shell when it was running to memory, which is what you'd expect, but it didn't terminate it and it didn't remove the payload itself in the UEFI memory space. So the payload itself was still on the host, even after the AV had flagged it, which I'll demonstrate later. As an extra point, this will tie into the defensive problems later. As an attacker, what you might want to do is the first write operation you have into a UEFI memory space and the persistence that you create. When you run that first payload, delete the original entry into UEFI and the persistence and recreate it again. The reason is that the payload inside the first UEFI, if they find the way that you've injected into it, they can not see trace that back and figure out what you put there or what you've labeled it under and things like that. Whereas if you do it a second time from an encoded or encrypted payload inside the UEFI that you've been extracted and run again, it becomes much, much harder for investigators to track that from a point of infection to where you're going and what we're doing. So now comes the tricky bit. I do have a demo. So the demo has been created, this is a heads up to, it was OBS of a virtual machine, however it is fairly small. So I do apologize. The videos themselves are available afterwards. They'll be available for people to look over. And it will be a good description of what's around. So this is the first one. So this screen shows the drive-by payload that I'm going to be using in Notepad. As you can see, it's in by arrays. So I copy that. This payload is fairly available from the repository that's available at the end. This is pasted into the administrative PowerShell terminal. As you can see the who am I, CM underscore test. That's now being executed. So that's being written into UFI memory space and then being extracted and executed. So we're going to go to my attack box where I have a reverse TCP handler waiting for the connection from the POC code, which is going to be extracted from UFI memory. So we give that a few seconds and there it is. So that's the reverse shell from the UFI hosted payload and the who am I shows that it is CM underscore test. So it's the same machine that we just ran the PowerShell POC code on. One thing to note is that the PowerShell instance in that case will be running in the background. We'll be running in the background. So when you SCSQ to the output to PID of the PowerShell instance that it can be running as as a POC code, obviously in real attacks you wouldn't keep it as a PowerShell instance. You might migrate it to something else, but there we go. So that's the basically the balance of moving from generating payloads and then targeted attacks all the way down to probably pasting and giving this an effect. So that's the attack side of it. What about defending? So there are a number of issues with defending UFI memory space. And to understand these issues it's good to understand why Microsoft has slowly included more access controls to this memory space in their iterative versions. One of the main reasons is the simplification for firmware updates and maintenance. So for example, if you're a vendor of hardware, if you want to update the firmware of your device in the old versions you'd have to run the update and all you'd have to do specialised boot time scans in order to check that it was the correct version. Whereas now using these interfaces the operating system is able to run software that can check the installed version, make sure it's compatible, the right type, the right vendor, so on and so forth. It's also able to change the boot order from runtime so you no longer have to go into the UFI or BIOS menu. You can just do that straight from the operating system which obviously is much more user friendly for a lot of users. One of the interesting things is that in development of Windows they use UFI variables and memory space for crash dump data. So if you ever run Windows developer editions and you have a crash you'll find that it will output crash data to the UFI memory space because it's non-volatile by nature. They know that it will be stored so that they output there. It allows for much easier maintenance and upgrading and patching of the firmware level of a machine. But what restrictions are there on this variable access that Windows has introduced? Well, none, effectively. The only restriction I could find was a variable size. Over a certain size when you try to extract it you may have some issues because it assumes that it's going to be a certain size. You can overload the UFI if you try to run it off although I haven't actually tried that and I don't know if you can recommend it. You must provide if you want to read data from the UFI you must provide the variable name and the GUID or the vendor ID to access that particular variable's data. And this is where the trouble arises from. There is no currently available way to enumerate the variables well, there wasn't. A variable way to enumerate the variables on the UFI RAM chip at runtime with only one exception which Ligritz and TOEFA, Timson demonstrated last year. I couldn't find any other except for one exception which I'll cover in a second. Therefore, users, software systems, operating systems and anything like that can only access variables that they already know exist and they already have the necessary credentials for. So from a defense point of view that creates an issue. If an attacker creates a new variable with a randomized name and a GUID that's non-specific an attacker, a defender can't enumerate these variables and therefore can't analyze what's inside the UFI memory system. So these, any Nazis they put in there effectively go undetected because the defender doesn't know where they're called and can't extract them, can't access them. So the only exception that was found was a typical chip sec. It was designed by the guys over at Intel and it's a deep firmware security analysis and repair tool. It's really powerful. I was quite impressed with it. It does help the UFI variables at runtime. It was the only tool and I did a lot of searching and I could find it did that. But the tool itself, even in their invocations they say it's not for production, it's for development only. It's very large. It's quite clunky. It requires the installation of a custom kernel driver and it also requires the disable the disablement of certain security functions in order for it to operate. Which obviously as a defense software if you're going to be using this remotely in production is counter-intuitive. So although it does what I was looking for it just, it wasn't capable of doing it in the way that was required. So how to monitor, although those are the difficulties how do you monitor the memory space? So I tested a lot of methods in order to try and find runtime access and enumeration. This is just a few of them. I spent a lot of time going through these methods. So examination of runtime enumeration. First of all I looked at the UFI specification itself which is really extensive. There are a lot of sections that explain how you can enumerate UFI variables but they mainly focus on what's called the EFI shell which is a specialized shell that can be accessed to boot time in order to interface with the EFI layer of your device. It requires a custom loader to be put normally on a removal medium which you then access and it provides the shell. So the specification provides a lot of information about commands that can be run in this particular terminal this sort of environment in order to get these variables but not enough really to do it from runtime. So it was inconclusive and I couldn't find runtime services from the specification unfortunately. Attempts to, so the operating system as I said Windows introduced the interaction for the operating system to have access and control over certain elements of UFI. UFI should have an understanding of what is in there. So analyzing how the operating system interfaces with the UFI showed that it works off of a database inside the isolated EFI partition of your hard drive. From that partition it then interfaces with a file called BCD which is a registry file so key value pairs which effectively match up to the values that it already knows about at installation. So backtracing this all the way down by the way the BCD file in the EFI partition is held by system so you can't access it from while you're running the Windows system which was always a fun caveat. So the operating system only knows what it knows at installation it can't enumerate what is in the EFI memory space. So unfortunately that was the dead end. I turned back to Chipsec as it was the only tool that I could find that did what I was looking for and the source code is fully available online which is really, really cool really good things to look at. So I began looking at how it functions I began following its procedures and how it accesses the memory. On assessment I found that it imported something called EDK2 which seemed to be very important in EFI enumeration. Effectively what the EDK2 does is after a lot of time playing with it extracting it running it independently from Chipsec which was very difficult I found that instead of accessing it from runtime what EDK2 does is it creates what's called an EFI payload which can be running within an EFI shell to output specific results. So it's more like a compiler for EFI payloads or capsules as you may call them which was run from Chipsec for I think mainly for remediation or repairs to the firmware. Unfortunately it didn't do what I was looking for which was obviously runtime enumeration. So the operating system doesn't enumerate it only has a list of what it already knows. The specification didn't provide the information I was looking for and the tool under analysis that I knew could do it I stumbled to the first hurdle and couldn't figure out how it was operating so I ended up kind of down a rabbit hole for quite a while trying to think myself out of it. Eventually I did basically knuckle down and get back to Chipsec and I spent a lot of time following it, debugging it really analyzing how it worked and eventually I figure out through its project process how that accesses the UFI memory space from runtime. And to do this it uses an undocumented function of the NTDLL.DL file called NTEnumerateSystemEnvironmentVariable about to use EX and what this command does is it extracts the variable information within UFI to a buffer of your creation which can then be extracted and carved to find each variable within it. So you run this function from the NTDLL it provides a data blob in a buffer which you can then loop through and carve and extract all of the variables for analysis. And this proved to be a great success. From the Chipsec tool I extracted the methodology I put it in a lightweight wrapper and really analyzed it through its paces. The resulting POC code which is in Python runs on everything Windows 7 forward tested. It should in theory run on Windows XP because the function within NTDLL was introduced in one of the NTDLL versions which was released alongside a Windows XP Service Pack 2. So technically it should run on Windows XP but I didn't try that one. It does check if the system you're on is de-reified based before it allows it to run which is obviously something else to know. As it uses the native NTD NTDLL.DLL which is found on every single Windows host you're not required to install anything custom except for Python and also run the POC code so it leverages local files in order to enumerate this memory space. As with the attacks it must be run as admin because of the token escalation that's required for firmware access. As you can see from the left when running this POC Python code it did successfully dump all of the EFI variables including malicious codes that were not defined anywhere else and allowed them for analysis as byte data and as translated unicode. So we've gone from a very large powerful common key tool to a very lightweight wrapped Python script which can run on any Windows host post Windows 7. I do have another demo for that there with me. So this just shows Python code we're now going to run Python file as you can see it's outputting the EFI variables nice and clearly as you can see the one's going past although maybe quite small on your screen is showing the DEF CON demo P2 entries that was from the attack that I demonstrated earlier along with the associated byte data and the unicode of the reverse TCP payload that I generated using NSFNM. There we are that I'm left there it's DEF CON demo DEF CON demo hyphen P1 as an example of how that works so so now we have an understanding of how this attack can be used at all range of attack levels how it can be monitored and defended against very lightweight and integrated into defensive software what does this mean for computer users and as researchers everyone can be targeted equally everyone can patch them now so despite the obvious with which all critical attackers can leverage this memory space using the APA function exposed last year and as I demonstrated can be all the way up from defined calculated attack methodology all the way down to type by copy pasting defenders equally have the equal ease in accessing and enumerating this memory space for analysis so although standard hunting procedures or antivirus or defensive technologies may not look into this currently the integration of such technologies now is very very easy so integration into standard detection rules processes techniques and defensive software is extremely extremely easy using the lightweight capabilities that I've outlined which effectively neuter this is a malicious heathen on all available modern operands modern hosts it also allows for increased sort of research in this area so although we now can monitor this they may be custom payloads that they use that are specific or they might be malware variations that are specific for leveraging this memory space which allow us to create custom rules and remediation methods in order to remove this as a threat so as we can now enumerate these attack these malicious payloads when they're on a unified memory space it also allows us to remediate it by leveraging the same capabilities of the attackers that read right if a defender knows what the payloads are called and where they're stored they can overwrite and remove their payloads from a victim's host so we are in a situation now where attackers have this capability to leverage this isolated memory space the defenders equally have the same level of ease in order to monitor and neuter any attempts to leverage it so that's me that's my email if anyone has any questions the github below is the repository with the POC codes as well as the full research paper which explains the processes taken and has a lot more technical information than this presentation so if anyone does have any questions please feel free to email me there's also the talk of text channel if anyone has any questions there or please feel free to direct message me and I will answer any questions that I'm capable of and I look forward to hearing from you guys the last slide I have prepared so please if anyone has any questions please feel free to comment thank you very much thanks a lot Conor appreciate it good talk thank you