Hello, this is Thor Gunnels. Today we'll be exploring Nearpod. It's a web platform that can be used to adapt and enhance your existing lessons, making them more engaging, effective, and enjoyable for you and your students, either in synchronous or asynchronous environments. Before we get started, don't forget to subscribe and hit that bell to enable notifications for our channel or by clicking on our logo during the video. Also, leave us a comment or check out our related videos by clicking on the pop-up cards in the upper right corner. Here's how to get started with Nearpod so you can go far and beyond with this powerful tool. This video presupposes you already have a Nearpod account and can basically navigate around the platform comfortably. If you're a complete newbie, please check out the Nearpod beginner videos located on the DeerDIS YouTube video channel. When you initially come into Nearpod, you have a few options. Either you can log in with a lesson in mind or you can let the ideas that you find here enhance what you already planned to do already. I'm going to show you a few lessons that will illustrate the utility and the variety of things you can do with Nearpod to enhance your teaching and make it more engaging. As mentioned before, you can go over to the Nearpod library. You can look at current events. You can search for lessons by subject, by grade, by standards. Ari has something in mind. I basically want to do a background and enhancement to my King Lear unit on Shakespeare. The first thing I'm going to show you is about Shakespeare's theater. The globe. Now, what I've got here is a nice splash page. It's something for the kids to look at when they come in. Next, there's a VR version that I have included in here. There is a field trip that you can do on Nearpod and you can search various places. This just happened to be one that I found. Very nice. It allows the kids to go around. Then I've got a little discussion here. What are some challenges just based upon what you just saw? The audiences and the actors might face when seeing a play at the globe. They can type their responses in here. They can even do the text or pictures. Now, I've got a little YouTube video that I've included. The YouTube video is of King Lear, actually at the globe. Not only does it a good performance, but it also gives you an idea of what it feels like to be sitting in the audience and what it might feel like from different angles. This one ends with a poll. Just ask a simple question. Would you like to see a performance? Would you enjoy seeing one at the globe? Then this can be the start of a discussion in class. Next, I've got King Lear Act 1, Act 2 and Act 3. These are all using resources that we've purchased from teachers, paid teachers. So it just gives you an idea of what you can do to jazz up the even things that you've purchased outside of the school. Again, I've got a nice splash page and something for the kids to look at when they come in. Here's a review of what they're going to do. They're going to take a look at the included PDF of Act 1 notes on review. And then they're going to be instructed to type out short responses at the end. I've embedded the PDF in here so that the kids can go through. They can see it. They can read each one of these. They can take notes on it if they need to in case they weren't paying attention while we were doing the playing class. Then they've got the questions embedded. Here are the questions. Here's where they can type in their response or they can record an audio. What's neat about this is that I've done this on every one. So if on the second one, they feel like they don't feel like they want to type, they can record their audio. Act 2, I've done something a little bit different here. There's the splash page again. Now this one I've included flip grid responses, which allow the kids to use their phones. They can use webcams. There's also the notes again, just like before they can take notes as they come through here or just use them as a review. And when they get into flip grid, things get completely crazy. You can include so many neat things in here. You can just record the response based upon the question that's given. You can use an immersive reader to help you read things inside the text. You can even embed videos in here so that the kids can get in here and then play a video of this as a review of a summary of Act 2, Scene 1, in case they just didn't understand it. Next one I did something similar. This one is talking about Edgar's decision to play a completely different character called Thomas Bedlam. If you click on this video, it shows you 16 different versions of Thomas Bedlam. Very cool. Then they can record their response based upon that question. And this goes on and on just like that. Finally, I've got this version which is using the exact same materials but in a different way. Now this one what I did was I'm using it as an embedded presentation. So I took the PowerPoint. I used a near pod in the extension with Google Slides and I uploaded it. So now it runs like a slideshow. Now the same thing with this one. The kids can take their notes. They can just review. And then when they get to the end, which I'll fast forward here to, again, we have open-ended responses. You can type the response in. You can record an audio. You can do a number of things with this. This is barely scratching the surface of what near pod will do. This just gives you a taste of what you can do with three different versions of the same resource from outside and one that I've created myself. If you have any questions or you would like any further suggestions, please reach out to me. I'm listed as Eric Govals at the district or you can reach out to case sellers as well. I hope you've enjoyed this presentation and you learned something today. And you can go far and beyond, above and away with near pod. Thanks so much for watching. Be sure to like, comment, or reply to one of our other videos or share the playlist below. Subscribe to our channel and enable notifications that you don't miss out on the next episode. Don't forget to check out our other resources like this cast podcast and see what else is going on at Orick County Schools. Be sure to follow us at Dear Dis is on social media or contact us via email or our blog.


My name is Michael Coppola and I will be presenting Owning the Network Adventures in Router Root Kits. Start off just a little bit who I am. I'm a security consultant at a small consulting firm, virtual security research out of Boston and just a side note we are hiring. I'm an undergraduate at Northeastern University. Just in the past I've done some stuff, played some competitions and won some of them. And if you want to see more information about this talk, as well as some other work I've done, my site is pop-pop-ret.net. So a little bit, how did I come on this topic? How did this all start? A year ago I was on a penetration test and I came across a device called a MicroTik router. Basically MicroTik is a brand of router that's based on a very minimalistic Linux distribution but there's a lot of stuff going on in user lands. Specifically, one thing of interest is that you can install modules on these routers through the MPK packages.  So this got me thinking, if we can install code on these MicroTik routers, even if they're vendor provided, what happens if we're able to create our own MPK package and possibly execute our own code on the device? Can we get a root shell? And this got me thinking. Unfortunately, there wasn't, the work done on MPK packages was mostly done on, the existing work was mostly done on very old versions. I believe it was version two of the MicroTik router. And there's not very many of those around. But version two, you can basically blow apart MPK package, stick your own code in, package it and run homebrew software on the device. But newer versions, I believe three or four, version three or four, the MPK format had an extra layer of encryption and no one had really figured that out yet. But they got me thinking, if this idea could be applied to MicroTik routers, why not apply it to all consumer routers? As many of you have probably seen this page or something similar to it on your consumer router, you can download an update for the firmware from Netgear site or the Belkin site or D-Link site and basically reflash the router through the web interface and you get a newer version of it. But what happens if we take that version of the software right off of the firmware, right off the vendor site, manipulate it to install our own code in a reflash of device through the web panel? So the big question brings us to can a universal process be developed to modify SOHO router firmware images to deploy malicious code without altering the interface or functionality of the device? And in hacker circles, we like to call this a root kit. So the intentions of this talk, I'm not going to teach you how to be a super early hacker. I'm not a reverse engineer but I'm going to share my experience pursuing a topic in a challenge I encountered, the mistakes I made and hopefully you guys can take something away from this talk, go home and do the same stuff that I was able to do, gain some better insight into the internals of the routers and release a project, release a project that I've been working on for the past number of months to help facilitate basically the back dooring of routers. And at the end, we'll do some demos, we'll pop some shells and put some devices. That's why everybody's here. So some prior work before getting into this, I wanted to see what work had already been done. Three main areas that I found a lot of help with was the open WRT and DDWRT communities. They've done a lot of work with custom firmware, homebrew firmware, a lot of reverse engineering and profiling of the router devices and the firmware that runs on them as well as a project called the firmware mod kit and basically it's a conglomeration of a lot of tools that help deconstruct and reconstruct firmware images and as well as the Site Dev TTY S0. They've done a lot of firmware modding, reverse engineering as well as exploitation of routers and embedded devices in general. So what are the use cases or something like this? I'm sure as many of you have seen out in the field or in a pen test, a lot of things have default passwords, admin, admin, admin password or just no password at all. Especially home routers. Plug them into a network, plug your computers in and you go. Basically, if you have access to the admin panel, what's the worst that you can do? You can forward some ports if you really wanted to. You can toss a network, but that doesn't help somebody who actually wants to further their exploitation of the network. So as well as if there's a vulnerability in the rider itself that gets you access to it, whether it's at the command level like a shell or just access to the admin panel through remote code execution or an auth bypass. I believe the two talks after me will actually be doing more of that stuff. As well as one vector which I didn't look much into but seems very possible is actually CSRFing the file upload. You can iframe the, put an iframe to a default IP <IP_ADDRESS> as well as a default password which is probably going to be there. And you can CSRF the actual uploading of firmware. So browse to a website and you get owned. Not just your computer, not just your browser, but your entire network. So a couple of routers that I looked at specifically for this project. The WNR 1000 version 3. It's made by Netgear and it uses the proprietary Netgear CHK format which will go into a little bit more later for the actual structuring of the firmware image. It uses MIPS architecture and as we'll see almost every consumer router out there, at least I was able to use was based on MIPS. And these use really old versions of Linux which is great. This one was used in Linux 2.4.20 which I believe came out in November 2004, 2002. And that's really old. It uses the common firmware environment boot loader as well as for the read-only SquashFS file system version 3.0. The next router that I looked at was a WGR 6.4 version 9. Pretty much same specs across the board except this is using an even older version of SquashFS. The next router was the Belkin FD5 7234 with version 1110. It uses the extended firmware header format which is proprietary to Belkin I believe. Again MIPS, the same old version of Linux, the same boot loader but this uses the read-only KramFS file system. And as well as the TrendNet TW 652 BRP version 3.2R this uses the proprietary Realtek firmware format. Again MIPS using a newer version of Linux 2.6 but I believe this one came out in 2006. It's still pretty old. For a boot loader it doesn't use CFE but instead it uses the DASU boot loader and uses a newer version of SquashFS. So basically what's the generalized technique that it came up with? The five points to pointage, profile the image, extract the parts from the image, deploy the payload, repack the image and update the metadata in that order. It seems fairly intuitive when you break it down like that. But going from zero to the end product it took a lot of playing around, a lot of trial and error and this is by following these steps you can essentially use the same generalized technique and approach any firmware image whether it's been already reverse engineered or not. So before we even started or before I even started working on this project we needed to basically see, obviously we're going to be reflashing the device but obviously we're probably going to be reflashing it with something that's not supposed to be flashed with. So what happens when we break the device, how are we going to recover from it? You're not going to go out and buy 50 routers at $20 each. So one thing that I found out was that nearly every consumer router that I found, they offer a serial port on the circuit board itself. There are four or six or any number of solder pads on the device and basically you have to do is find the terminals, solder the connectors and you get a root shell as well as access to the boot loader and it lets you profile device, lets you view the startup sequence and view more information about what hardware is actually running on it and what specific software is running on it. It lets you test new payloads fairly quickly and easily as well as debugging when payloads go wrong or when reflashing the device goes wrong in case it rejects the firmware that you tried to reflasher it with or it just doesn't work at all. And again the boot loader, by breaking to the boot loader, it gives you an easy recovery, a quick testing of new firmware images and we'll go into how that works very soon. So basically connecting to the console, you're looking for four pins, ground BCC which is positive voltage, TX, RX for transmit and receive and just for example on the WGR614B9, these six pins at the bottom left constitute the serial port but we only care about four of them. A closer look, we have VCC, RX, TX and ground. This can mostly be found usually by trial and error just by trying every possible configuration of connecting the pins to the solder pads but if you want to do it intelligently there's also, you can use a multimeter and first find ground and then find a positive voltage testing for resistance and then basically trying every configuration for RX and TX. So basically this would be the serial pin out for the WGR614B9, we have the four pins and we're going to connect ground to ground VCC to VCC but we're going to cross TX and RX because you want the transmitting side to go to the receiving side and the receiving side to go to the transmitting side and basically this very simple circuit of crossing TX and RX is what constitutes a null modem but we run into a problem, we can't directly connect to the router because computers run at 12 volts and routers run at 3.3 volts and if you connect it directly it's going to fry the router and that's not very constructive. So what we need to do is introduce a voltage shifter into the circuit to prevent damage and facilitate this communication. So luckily Spark Fun has these little kits you can buy for seven bucks, they're really fun solder projects, put them together, you plug in a serial cable on one side and you have your four terminals on the other side and this is the end result of what it looks like, fairly simple, you have some LEDs that show when communication is going and this is what it looks like actually solder to the board. You don't really want to solder directly to it because these are very small and fragile solder pads.  But as you see we have ground and VCC on either side connected to each other and RX and TX are crisscrossing. So again receiving goes to transmitting and transmitting goes to receiving. So by doing this you can see we put up the router, we connect to the serial console and we have a root shell. Obviously this doesn't help us for the end product but it lets us mess around with the router, see what's on the file system, see what's running in the kernel and basically lets us do some debugging with real feedback in real time. So this is once the router has booted up and the next one is actually breaking to the boot loader. As you see we broke to the CFE prompt just by holding down control C at the initial boot up sequence and if you run the TFDPD commands in CFE we'll actually start listening on a TFDP server and you can send firmware images over Ethernet to it. It will write that in there, do some integrity checks, tell you if the checksums are wrong and tell you what it's supposed to be and then if everything works out it will reflash the device, write it to memory and then try to boot into it and then you have real time feedback to see if your firmware works or not and what to do to fix it in case it doesn't. So now we have ways to recover, we have a way to debug, how are we going to do the first step, profiling the actual firmware image itself. So this question that we have is basically what exactly makes up this giant blob of binary? We download something from that gear and it's just a .bin file, it's a .chk file and you have no idea what it is. Is there a boot loader in there? Is it a kernel, a file system? These concepts that we know run on this device but we don't know exactly where it is located and early attempts to find these items were crude and limited in helpfulness, basically run strings on it, run hex dump, run file on it but nothing really gives us any tangible feedback. One thing that we can notice immediately is that there's this string, it looks something like a serial number or a model number and it says netgear at the end but again that's just something interesting, it doesn't actually give us any tangible feedback on where to go from there. So if we ran a file at the file command at offset zero and that didn't help us, what happens if you run the file command at every possible offset? Basically, will we be able to find a file system? Will we be able to find a kernel?  But luckily doing some research online there's this great tool called BinWalk. I believe the FRAC FRAK talk the other day actually integrated with BinWalk as well. Basically, this tool identifies headers, files and code inside just generally files but specifically suited towards firmware images. It uses a mix of lib magic and custom signature database in order to detect these headers and it's made by the great guys at TTY-0. And the best part is that BinWalk runs in seven seconds and my script ran for two hours and it got amazing results and it was accurate right off the bat. So we see here we have a TRX firmware header, we don't know exactly what that is but maybe we'll look at it a little bit later. We have this blob of LZMA, we don't know what it is but we'll look at it later and we have this file system using the read only squash FS format. This is something that we can work with and we'll look at that next. So basically extracting from the image, how are we going to take these items and work with them from this giant blob. We want to, in this specific image, we want to extract the headers, the LZMA blob and the squash FS file system. Fairly simple, just use DD. We'll start off at zero because we're fairly certain there's going to be a header even if it didn't detect it. It has to be something off at zero. And we'll take the first 86 bytes to include the first header and the TRX header. Simple.  And we take out this blob, we decompress it and run strings on it and lo and behold here is our Linux kernel. Maybe we can work with this a little bit later. And extract the squash FS file system. Again, just find the offset and extract it. And now the next step is going to be unpacking the file system because that would be the easiest to work with. And if you need to find a way to unpack squash FS, basically we use the unsquash FS utility. And firmware market has a great collection of I believe almost every unsquash FS utility that's available publicly on the internet. Ones that are both open source also proprietary patches that vendors add to squash FS for their own firmware images. But the only problem is that none of them worked. So what are we going to do? The great thing about these routers is that I believe back in 2009 there was a big issue with the fact that all these routers were running Linux, they're running busy box, they're running squash FS, all open source GPL software, but they're not releasing source code for them. So 2009 everybody basically was forced to release their source code. So we can go online to net your site, download the source code for this router, and look for maybe this unsquash FS utility is in there, but it's not. And we see there's no unsquash FS.C in this directory, but we know that it's supposed to be there because it's in the make file, but they removed it. So there's a couple different options that we could basically take at this point. We can try to reverse engineer the actual proprietary patches that Netgear added to this specific squash FS archive. Or maybe we can keep looking online for something that firmware market doesn't have, but again that didn't work. And I usually like to not put forth effort if it's not necessary. It's part of the whole lazy hacker thing. But so why don't we just ask Netgear for the utility, maybe they'll come through.  I believe that this utility is supposed to be in here, it's not in the source code. May I have it please? And the response is I'm sorry that we cannot modify the source code of this router because it's not an open source. And first of all, that makes no sense. Just English wise. And second of all, the source code is available. That's the reason I'm sending the ticket in the first place. So I send the reply. Thank you. I believe that this is GPL, however. Please release the source code. And he replies, he sends me a link on Netgear site and possibly, oh, maybe this is our answer. Maybe there's some different source code that I didn't see on the site. And he sends me a link to the former download page. All right. So I'm like two weeks into this already. And I'm getting kind of frustrated, but I'm still being polite. So I ask, can we escalate this ticket to technical, like to second level technical support, somebody who isn't just reading off the script and possibly get some actual answers. So he escalates the ticket. Two weeks later I get a reply. Here is the download link to the file you requested. And it worked. So if there's any lesson to be taken away from this, it never hurts to ask and you don't know what will happen. All right. Great. Next step, deploying the payload. We have this unpack file system. How can we deploy a payload into this thing and then put it back together and then get code execution on the device. So just looking at the environment. We have a minimalistic Linux system. We have two vectors. We can do this through user land, which is dirtier, quicker, more portable. You can run a single binary across every device because it's the same architecture. It's all Linux. Or you can do kernel land, which is stealthier, but you have more development considerations and it's less portable. You have to tailor it to each specific device. So just looking at user land is very simple. Just do a quick backdoor code and see. Drop it on the file system. Again, you have the same one binary, which is executable across nearly every device. You have the file, but you have a problem. The file is visible. The process is available, visible. But honestly, who cares? No one's going to see the file system. No one's going to see the process list unless you solder into the pads, which at that point is probably sitting in an FBI office and some friends at person's desk. But one problem which might come up is that there's a small subset of routers where you can actually view the list of currently active connections. I didn't come across that very often, but I know that my own home router does that. So something that we should consider. So how can we combat this? Well, at that point, we're going to have to go to kernel land, but we'll talk about that next. So very simply compile, cross compile your C to MIPS. Drop it on the file system and basically find some binary that's always going to run on boot, which is the HTTP server. Now replace it with a shell script that runs our bind shell in the background and then dispatches off to the real HTTP server. And as you see, pack it together, boot up the device, and we netcat to the port, and we have remote root shell. So our next vector could be affecting it via kernel land. You have three possible methods through this infection through a Linux kernel module, infection through def KMM. We're basically editing kernel memory on the fly, or we can do static kernel patching. The problem is that a bug in a code is not just going to kill our payload as userland would, but it's actually going to take down the router and take down the entire network. So if we do do any kernel land modifications, we're going to have to have as little code as possible, put as much code as possible in userland if possible. And another issue is that it has to be compiled against the specific kernel tree if you're doing a Linux kernel module. And even though a lot of routers use the same version of Linux, it's not very universal because we're going to have to download the source code for each router and compile it against that tree. And if you've worked with any GPL source code archives from like any routers, you'll find that they don't actually compile on the first try. They don't compile on the second try or the third try. So it's a real pain in the butt. But again, we have this benefit that all the files, processes and connections are hidden. So let's see, we'll take a look at Linux kernel modules. We won't look at KMM or set a kernel patch that could be future work, but even it's not entirely necessary. It's just more work than you actually need to do. The great thing about using old versions of Linux set, basic root techniques from old frack articles from 2000s, 2001, 1999 are still relevant, as well as all the root kit code that has been updated in years such as Adore. So just a quick look at LKMs, you need an in and exit function that runs on install and uninstall. And if we want to hide processes, we simply hook the redirectory function that's associated with the slash proc directory. Every process running on the system is represented by a directory in slash proc with the PID. That's the name. If you want to hide files and directories, we simply hook the redirectory function associated with the folder that it's in. And if you want to hide connections, we simply hook the output functions associated with proc net TCP and UDP. So a quick structure of how LKMs would look on Linux 2.4 is simple. You have an init module function, a cleanup module function. We put our hooking code in init module and put our unhooking code in cleanup module. And it's pretty much the same concept, but it's a little different in 2.6, except the only difference is that you can really just define arbitrary names for in and exit functions. So a quick look, how would we hide processes and the same idea of files on Linux 2.4 and 2.6? Again, it's simple. You simply open a file pointer to the slash proc directly if you were looking to hide processes. You do some magic to find the redirectory pointer within the file pointer structure. And basically it's just a game of swapping out file pointers. You take the redirectory pointer that's there and simply set it to pointer to your new function, which in this case is the endproc redirectory function. And it takes a callback, a pointer to a callback function called fill directory, which we're going to have to replace. Fill directory is run on every iteration, every item in the directory that is being called on. So all we do is inside this fill directory function is simply have a conditional, have a conditional, is this the file, is this the process ID that we're looking to hide? If so, return zero, if not, run the original one. Very simple.  Not that you don't know how to do it, but it's just a lot of parsing, a lot of dirty code I have to write. Looking at a door and g, this is how it's done. It couldn't off it on a slide, but basically the same concepts apply. Basically run the initial, run the original function that returns the information associated with active connections, listening ports on the router, and simply parse out the information that you don't want. So we get the original output of PROCNET TCP, simply iterate through and remove any entries that we don't want and then display it to the user. And then Linux 2.6 is a little easier, but again it follows the same method. Open a file pointer to the PROCNET TCP, replace the file pointer to the function that is used whenever you call PROCNET TCP or read from it, and simply run the original TCP for sequence show function and then parse through the output and remove anything that you don't need or you don't want to show. And every network utility on Linux basically is just parsing output from PROCNET TCP, PROCNET UDP. Netstat is literally just a wrapper around this file, this virtual file and just print it out in pretty formats. Bringing to the next step, repacking the image. Okay, so we have a router image, we were able to extract everything that we wanted, unpack the file system, deploy our payload, how are we going to put it all back together? It's fairly simple, just rebuild the file system in the opposite way that you unpacked it, append the extracted and generated parts back together again, add any sections to define links if necessary. If you look at hex dumps you'll see that even though there is a file system at offset 1000s and it ends at offset 2000s, sometimes they'll just put 10 kilobytes of null bytes just to reach some padding, some padding necessity and we won't worry about metadata yet, we'll take care of that next.  We can use binwalk to verify that we put it back together the way that we took it apart. Paging the image is simple, just dd from dev zero, add it to the end until you get where you want to be. And we're going to leave 58 bytes at the beginning as a placeholder for regenerating that unknown header at the beginning of the firmer image that we saw with the binwalk output there was offset 58, there's a TRX header, but the first 58 bytes we weren't able to identify, but we'll take a closer look at that in the next section. Updating the image metadata, basically this specific firmer had a netgear CHK header. You can tell by the first four bytes are the magic number, star, pound, dollar sign, carrot. And this is, we found this by grepping through the source code for the router, not for the specific string but for the hex decimal representation of it and it was in a defined somewhere in some random file. And looking through we have other data points such as header length and eight bytes of reserved data which doesn't really affect anything, we don't care what's in there. And the kernel checks some, the root file system checks some, the kernel length, root file system length, image checks some, header checks some, and then this board ID, which as you can see next slide, this is that string that we found in our initial profiling of the device. And the HDR zero immediately after it isn't actually part of the board ID but it's actually the beginning of our TRX header. And the TRX header is used to provide metadata about the LZM A blob, the Linux kernel that was directly after it. But as you see we have the header length which is 58 bytes, reserved 8 bytes which we don't really care about, it has no effect on anything we do. The kernel checks some, which we're going to have to, we don't have to worry about because we didn't change the kernel but if we did change it we'd have to update this checks some. And apparently in this specific router they actually don't care about the root file system checks some because the length and checks some are both zeroed out on the stock firmware image. The kernel length which we don't have to change, and image checks some and header checks some, which we're going to have to have to recalculate this because we change the image and we change the header. And how are we going to generate this? Luckily that we have the source code, we have this beautiful utility called packet, you literally give it all the input set you need and it creates the header for you and automatically prepends it to the firmware image and bam this is our final product. We're going to reflash the device with this and we're going to get our shell. So this is where my code comes in. I developed over the past few months a framework called the router post exploitation framework. Basically it abstracts and exploits the process of back to our router firmware images. I believe the website is up, it's in a red mine repository. So if you want to grab it, do it quick before somebody pulls out the red mine zero day and takes it down. And basically the way that it works is you provide an input from our image, you provide the output from our image to the file name that you want output to and the name of the payload and it does everything magically. You don't have to worry about extracting, putting it back together. And basically this is going to allow us to basically create new firmware images for devices. And we don't have to, again, worry about the internals but just say which payload do we want? Do you want a bind shell? Do you want a network sniffer? Do you want a bot net? And it will create this, you ask for input on depending on which payload you decide and it pops out a nice firmware image, reflash the device and we have our shell. So I'm going to do some demos here. All right. Let me just swap this out. So just a little, just a little bit about this. This is RPF. This is the list of things that you can do with it. Basically a couple of flags that just generate more information. And if you want to, you can leave the temporary files in slash temp so that you can instrument on the files if you want to do anything else with them in their extracted form. And we'll take a look at what modules we have so far. Here we go. These are all the firmware images I've been looking at so far. We have Belkin, D-Link, LinkSys, Netgear, and TrendNet. And there's four stages at which the module can be at. Verify, which means it works. You finish the module for that specific router or for that specific firmware image, try it on hardware and it works. It's verified. Unverified, which means you wrote the code. You're fairly certain it's going to work right off the bat or with very little modifications, but it's awaiting a testing on a actual hardware. And I tried to test it on many devices as I could, but unfortunately Ebay always doesn't have the largest selection. There's a roadblock, which basically means there's going to be some work involved. There's something that's stopping the progress moving forward with unpacking and repacking the image. There's going to be some reverse engineering work involved in testing, which means it's currently in development. So let me just set up the network here and we'll start reflashing some routers. Okay. Again, just emulating some sort of attack on a default router that's out there to login with default credentials, ebb and password. We go to the router update page and this gives us a vector to introduce arbitrary code to execute on the device. So we have our firmers here. We're going to use WNR 1000 version 3 firmware and we want to output it to a firmware image that lets us spawn a bind shell. Now this is very simple. It checks the checksum of the firmware image that you input against the module checksum and extracts all those items from the firmware image and asks which port you want to listen on, you want to listen on an elite port and this is our outputted firmware image. Now we're going to reflash the device with this and it's going to ask us is the same one that you want. Yes. And this will just take a minute. In the meantime, is anybody have any questions? Sorry? Yes. Yeah, it was a Lynxus device. This particular Lynxus device uses a file system called PFS slash 0.9. There is very, very, very little information about this file system or archive format available online and the only implementations I found are very broken. They only provide limited support on unpacking the file system. No support for repacking it back together and the only potentially full implementation I found was on a completely Japanese site. All the documentation was in Japanese and it was written in a scripting language called hot soup processor which was just don't want to deal with that. There's another few seconds and it should be ready already. And here is our shell listening on the device. Okay, so this is fine and dandy. We have a root shell on this device that we can access any time remotely but the file system is read only and that's the real pain in the butt. This thing has very, very limited capacity for installing any new software on it. The only writeable part is in slash temp and we only have a couple kilobytes to actually install new code on it. So we'll run into a couple other proof of concept here. Say instead we didn't want to have a bind shell but instead we wanted to install a network sniffer. And if you want extra output, verbose output, just give the slash v flag. And you can see all the intermediary steps that are going on. We track the firmware, we unsquash the file system and we enter our payload. Which port do we want to listen on? In order to receive this SNF traffic port 113 goes through and we'll use the same file name. Write our upgrade, upload and it reflashes again. How many of you are planning to stay in here for FX's talk? There's a possibility of clearing the room.  There's a possibility of switching this over to track one. Hang tight. We'll let you know what we're going to do. Sorry about that. So any other questions in the meantime? The question was did I find any writers that had signed firmware images? Signed firmware images. Personally I did not. A lot of these personal devices are just using upfuscated proprietary firmware formats. The most they're compressed but again you can decompress them or have some patch to open source utility but no I actually did not come across any that were signed. But that is one thing that vendors could do in order to prevent this type of attack. This works. I may have just bricked the router. Let's try a different one. Okay. While this goes. Any other questions? Yes? The question was do old writers use busybox? Yeah. As far as I was able to tell almost every writer just use busybox. Busybox is a single binary that let you include a whole bunch of common unix utilities in a single binary. And instead of having a different binary for LS, a different binary for cat, a lot of extra overhead, you just have a single binary and you have a sim link to the original one. But yes, everyone that I did encounter did use busybox. Sorry, say that again? No. Sorry, could you come up closer? I can't hear you. I don't think I have. Yes? Oh, the sniffer is running in user land. It opens a raw socket on all ports and simply prints the output to it pipes the output to another port. Hopefully this writer comes back. There we go. Okay. So we netcat to the control port and here we can see the dump of all TCP packets that are going through it. Obviously we don't have, I don't have a network connection here or connection so I can't go out and show any going to Facebook or anything. But you can see just accessing the writer from the admin panel. You can see all the traffic going through. We can go back and inspect it and find passwords say if we were logging in to the panel. Here authorization basic and here's base 64 encoded version of what our login is. So my last demo, let me just get this set up here. So this we can get a shell, we can sniff network traffic but what if we wanted to do something just completely and utterly malicious or if we wanted to install a botnet on our firmware image. So the address of our router or of our IRC server, port of our IRC server channel and prefix something that hope this works. And wait for this thing to finish reflashing and if all goes in well, all goes well, then we should be seeing a new Nick in the channel. Yes. Yeah, I mean obviously if there are vulnerabilities in the router itself, you can always get access to the admin panel that way but the best protection I guess is just to set a strong password on the admin panel. Any other questions? Yes. I believe the question was can you upgrade the firmware from a modified firmware? Yes, you could. That's one potential route for future development. Obviously you can make it so you can prevent any new firmwares from being flashed to it but that might be conspicuous. But yes, at the moment rewriting the firmware after it's been installed will overwrite the firmware and put a fresh copy on it. Any other questions? Yes. The question was have I tried any other man-in-the-middle attacks such as SSL strip? I have not but that's definitely, there's a lot of potential. The only issue that might be a limiting factor is compiling all the code and getting it on the router because you really only have like 10 kilobytes to work with. Actually be flashing the router, killed my connection. I don't remember how much you have but again it's only a couple kilobytes or like a megabyte or something. There's very little space on these and here is our botnetted router and we can do all sorts of fun stuff with it. We can send it shell command. Hopefully the demo guys are not looking upon us favorably today. But there take my word for it there's a lot of cool stuff you can do with this. There's actually implemented DDoS command just for fun but if you check this out online there's on the site you can download this on your own router. This is the first time it actually hasn't worked. So yep. So I believe I run out of time but quickly some things I like to give the people at midnightcode.org they did a lot of work with Belkin reverse engineering and profiling. I like to thank Dan Rosenberg for kicking my button to gear to actually get a talk submitted and as well as the great people at OpenWRT and DDWRT who have helped a lot along the way. So thank you.


Good morning, everybody. Thanks for coming out this morning. First of all, a special thank you to DEF CON and all the organizers for having me here. The hospitality so far has been great. I'd also like to make a public statement here that it's great to see some minority groups strongly represented here. I've noticed the increase in women and non-white guys at DEF CON, which is very positive, and I think diversity is an important thing for us to progress. So keep it up, and let's go together strong in this one. So CryptoKitties launched the Alpha just over a year ago, and it was really wild. We had tons of fun doing it. And for many people, it was actually the first time that they ever interacted with the blockchain in general. And for us, we felt that we were onto something new. A lot has happened since then. You know, we've had many lessons that we learned, and I'm here today to talk to you about some of them. Our community and our ecosystem has also grown significantly. We've had third-party apps like Kitty Hats come and expose this IDF extensibility of non-fungible tokens. We've had CryptoGoods who came along and did this whole physical representation of NFTs, which was pretty cool. We've had tons of fun arts.  And our team has also grown since then, so I want to give a special shout-out to our team over there. We hail from 20 different countries, 18 plus different countries, 20 plus different languages, over six employees, so big shout-out to the team, all ranging from a variety of different backgrounds, different experiences and whatnot. So like I said, I'm here today to talk to you about user experience and blockchain.  I'm gonna break this down into three overarching lessons, and these lessons are gonna be very kind of human-to-human relatable, because I believe that if we can think and build our products for humans, then they're gonna be much stronger. So lesson one is titled Talk. And I'll begin this lesson by telling you a little bit about myself. So my name is Nick. I'm one of the founding members of CryptoKitties, and I'm the lead front-end engineer over at the Kitty Den. I was born and raised in the Caribbean on a small island called Trinidad, and I spent 19 warm years in the tropics. I had a very strong interest in arts and sciences, and at the age of 19, I left Trinidad, and I went to Montreal to study mechanical engineering. When I came back to Trinidad, I decided to go to the other side of my brain and start a fashion brand. So I was designing a parallel, producing it, selling it, and through a parallel design, I decided to learn how to do web development because I wanted to sell my clothes online. Eventually, I got a job as a web developer at an advertising agency, and a year and a half later, I quit that job, and I went traveling around the world. During that time, I built up a technical blog that had, I think, about half a million readers per month in its peak, and that was a time for me to really discover what did I want in this industry. I came back to Trinidad at some point, and then went to the Bay Area for a few months. And in November of 2019, I joined Axiom Zen as a front-end engineer. Initially, I had worked out of the Chilean office, and then I worked in Trinidad for six more months as well. And in January of 2017, I moved to Vancouver, and I sacrificed all the sun and warmth for a little bit of snow and cold. But it was a really good choice for me because seven months later, we were scheming cryptocurrencies, and in December of last year, we launched, we released the cats into the wild. So why am I telling you this? What relevance does my life story have to user experience? Well, the way that I think is that now that you know a little bit about me, we've established a little bit of a human connection. And the more that you get to know me, and the more that I get to know you, the easier it is going to be for us to build our relationship. So I'll tell you a little bit about cryptocurrencies. Yes, it was an app. Yes, it was a product that we developed. Yes, we just put cats on the blockchain. But for us, you know, we did a lot more. We gave these cats names. We gave them a story. And people felt really strong connections to the cats that they owned, because they had a story. And the interesting thing in this space is that we use a lot of technical words like interoperability and extensibility and whatnot. But outside of this room, outside of DevCon, nobody understands that. But by crafting narratives and crafting stories for the cats and for the ecosystem, we bring meaning and we bring life and we establish this really good human connection. So lesson one concludes, we give whatever you're building a personality. Give it a voice, let it tell stories. Because storytelling is important for establishing a human connection. And a human connection is really important for building a long-term relationship. So lesson two will be about listening. You know, we just went over talking. How do you talk to establish a connection? Well, you have to return in favor. You have to listen to the people that you talk to. So in December of 2017, CryptoKitties was released to the masses. I'm just gonna get a little water, excuse me, sorry. Can I get a sip? Thank you. Apologies. So in December of 2017, CryptoKitties was launched to the masses. And by December 8th, three days later, we were literally on fire. I had been working for about six weeks straight with my team pulling like 16-hour days. You know, we were pretty exhausted by then. And I remember it was a Saturday. I was just trying to have a normal day.  And then I got a few text messages from some of my coworkers saying that Genesis, which was cat number one of CryptoKitties, had just sold for $120,000. And I knew at that point that any sign of relaxation was officially out the window. And it showed, you know. I mean, in that first month, we had 1.6 million in web traffic. We had over 200,000 wallets created. And we had 52,000 new kitty owners.  It was high time for us and for CryptoKitties. And, you know, we had to deal with that. I mean, at that point, it was immediately exposed that, you know, the network couldn't handle the traffic. Different geth nodes were just completely failing because of mem pools getting clogged. Our API, which was listening to events on said geth nodes, was just not picking up the events anymore. Our front end was just not showing the correct data as a result of that. And it was a nightmare, you know. Users were so new to this thing that they were just burning money on gas. They had no idea what they were doing. At that point, I think in the first two or three months or so, users had spent over $2 million in gas. Some people were spending up to 10 times more in gas without even realizing it, like 10 times more than they should have. And tons of it was wasted on failed transactions, you know. This is such a new environment for users. They just didn't know. And we were kind of freaking out, you know, we're dealing with people's money. We're dealing with completely new technology here. What do we do? So we had three options. Number one is just let them burn gas, you know, let it be. But that was a big no from our part because we were dealing with people's money and we have to protect people a lot better when things are new and especially when we're dealing with money. Option number two was to go for like a more preventative measure entirely. We tried to control the UI a little bit and prevent users from conducting transactions that we knew or that we assumed might be guaranteed to fail. But this also backfired because, you know, because of these multiple layers of information travel from the blockchain all the way up to your applications. Info just gets lost along the way and especially when get instances failover and then the API goes down, it's usually heavy traffic and the front end is just assuming the wrong information. So we ended up in a situation where we were literally blocking people from, you know, buying and breeding their cats and that was also a bad thing. So option three kind of sits somewhere in the middle or not really in the middle, but it's more like let's take the lessons of option one and two and apply it and let's give some user education and guidance here, you know, let's teach users like what is it that they're into in this new space. And during the alpha of CryptoKitties, we made a couple of wrong assumptions, you know, we thought that our users would just kind of get it. Yeah, we were testing whether they would like the pictures of the cats and whether they would get down with this old cat breeding thing and they did, but we did make a couple of assumptions that they would kind of get the whole blockchain thing and we were wrong. They were actually confused, you know, there was a lot of newness and a lot of unfamiliarity around that technology. But as soon as we gave people a little bit of guidance, they felt a lot more comfortable. They started to fall in love. The messages that we were getting through our various social channels at that point were hilarious, you know, people were just fascinated by this whole ownership of NFTs on the blockchain, you know, oh, I own this cat, this piece of digital art, you know. And that user guidance really paid off big time for us. We took that as a lesson to introduce more and more guidance throughout the app during its, throughout the web app during its lifecycle, development lifecycle. We started to talk about gas and we had these birthing fees for cats as well. We continuously educated people about that, you know, we got them educated through the onboarding and that type of thing. And people started to have this growing familiarity with the ecosystem. One of the most important things for us that was missing early on was what was happening after our interact? What was happening after our transact?   If you are buying something on Amazon, you know, you get this shipping receipts and you have this comfort that it's gonna be in the mail in a couple days or so.  So we started to introduce this thing about what happens after our transact, you know. We started to give them this activity feed where they say, listen, you have attempted to do something, you can go track it on Ethascan and you can see the progress of it and that gave a little bit of tangibility to the whole purchasing for users and they felt a lot more comfortable. We followed that up with giving them emails about when the transactions were successful and that gave them a second degree of comfort. So I'll conclude lesson two by saying users need guidance when they're in unknown territory. They need lots of guidance and education when they're uncomfortable. This is concepts that I like to refer to as the failure path. And in engineering and design, the failure path is a path that a user takes where they make continuously wrong steps. It could be things like entering an invalid email followed by entering a weak password following by clicking the wrong button. You know, if your users continuously take wrong steps, your UI and the user experience could become pretty daunting and terrifying very quickly. And if we can guide users through that failure path, if we could make each step of the way pleasant for them and educate them as to why they ended up in this situation as opposed to presenting them with random error messages that bear no meaning, then they would feel a lot more comfortable. They would start to gain familiarity with the surroundings. So lesson three is about connecting. I talk to you and then I listen to you. Our relationship is becoming established. How do we build a deeper connection? And how do we grow that connection and strengthen it? So in an ideal world, you know, we tell our story through our products. We gain the user's interest and we guide them through the early stages.  You know, through onboarding and guidance, they're able to start interacting with the most important parts of your apps immediately. They are able to start engaging and having fun and getting integrated into whatever is you're building. But in blockchain, it's not straightforward at all. It is really a hazy maze before they can actually start engaging with anything. After we get visitors and after we get them to do whatever sign up flow exists at all, we have to introduce them to wallets because in blockchain, you can't do anything without a wallet. You know, you have to have a wallet to store your NFTs or to store whatever token it is your app is running. And in order to engage with any token at all, you need cryptocurrency. So this new user who was just immediately, was first of all just interested in cats, now they are learning about wallets and cryptocurrency. So we get them to sign up for our app a wallet and Coinbase to buy some crypto, you know. They finally get through to that. They manage to get some Ether. Maybe it takes them a couple of days because they have to validate their credit card and then they have to compile the Ether itself. And then after they buy it, they are like, okay, what's this thing? I have to wait. I have just given money and I have to wait to get something in return. And that's very unusual for people. And at this point, they are wrapping their head around this thing and they already kind of lost the plots. They are wondering, well, which one is the wallets and which one is the app? I don't really remember, you know. And then finally after that, maybe like three or four days later, they can interact, you know. They can get involved. They can play the game. And that's just, that is so unusual for users. It feels like we've literally gone backwards, at CryptoKitties for us. We've spent days onboarding people through conversations and messages and say, hey, well, this is what this thing does and this is what this thing does. And it's shocking that people stick it through. I mean, it's good news that people stick it through. It's a positive sign. It's a reassurance for us that it could catch on. But look at the steps there, you know. And at every one of these steps, there are huge drop-offs. And at some steps, you can't even control the drop-off, right? Because they're third-party applications. This is, it's totally out of your control at this point. It's starting to become like cognitive overload, you know. In lesson two, we spoke about guidance, but now there's too much guidance. There's too much education. You know, people came to this app because really they just wanted to buy some cute cats. And now they have a PhD in cryptocurrency on wallets and like blockchain, you know, and they didn't want that. Like the majority of users just don't want that. On the numbers show, the current state of the ecosystem reflects that. A year ago, we had 52,000 new kitty owners within the first month. But today, the user of the top 100 apps combined are less than 10,000. And the number of CryptoKitties players are a small portion of that. But you know, we're in this together.  And I believe that together we can address these problems. But the big question is obviously how? So has anybody here used a Game Boy? Very nice. So my experience with Game Boy in the 90s growing up was I got it. I put a game inside, I switched it on, and I started to play. And it was a very kind of a natural feeling. You know, I didn't have to go and read the Game Boy manual. I probably threw it out. I didn't have to go and read the game manual either. I threw that out as well. The technology, which was a Game Boy, if we want to map the Game Boy itself to the blockchain and the game itself to say like CryptoKitties, for example, both of these were very self-guided pieces of technology. And the relationship felt very natural. And I actually went down the rabbit hole before this presentation of looking at Game Boy commercials from the 90s. And there are some really, really weird ones that I encourage everybody to check out. But one thing that was a prominent theme was the messaging. Game Boy didn't try to sell me on what their CPU specs were or what their LCD screen specs were. Their messaging across the majority of the ads was simple, was that you can have all the power of Nintendo right in the palm of your hands. And that was enough. That was all I needed as a user. I didn't care about the hardware. I just wanted to play. And with the games, it was the same as well. You know, with Zelda, the messaging in one of these super weird commercials was you travel through many worlds with endless characters and their eternally ventures. And it's lovely. It's simple.  You're not banking on this insane, intense onboarding experiences. The blockchain is different, right? Blockchain is new. Blockchain is there's no familiarity in this space at all. But it is our job to build that familiarity and to take these underlying concepts and to abstract them entirely. Because a day-to-day user, they don't care about the things that we care about as developers. They don't care about securing their private keys. They don't care about gas. They don't care about different clients for different wallets. They want this feeling of familiarity. They want this feeling of comfort. And we need to start thinking like them and talking to them like humans. We need to speak their language through our products. And we're not doing that right now. It's tough to do that right now because there's just so much cognitive overhead. So lesson three is really about making friends easy. And what I mean by that is make growing the connection that a user has with your products easy. Make strengthening that relationship easier. What we've seen at CryptoKitties is that blockchain and non-fungible tokens and crypto assets and digital art are a great way for users to self-express, to create, and to collaborate, and to grow this technology together. And we need to provide that. If we want to appeal to the masses, if we want to grow the market together, we need to start giving these delightful experiences for users. We need to start making all of those abstractions for people. And we need to start getting them together and letting them engage with each other and experience joy through the apps that we build. And that needs to be our mission. Like UX is everybody's problem. It is not just for the designer. It is not just for the product manager or the UX expert. It is all of our problems. We need to start thinking like that. So at CryptoKitties, we have this bold statement. Let's bring the next billion users to the blockchain. And it's wildly ambitious. So my call here for you today is to let's do something a bit more realistic for now. Let's take those metrics and 10X them. Let's get our users from 10,000 to 100,000 by next year. Let's take these steps together. Let's build the tools. Let's build the ecosystem that we need. Let's think about our users. Think about the people outside of this conference. That's what's going to drive the technology forward. And DAPA Labs, which is the parent company of CryptoKitties, that is what we're doing. We are building the ecosystem for the next wave of users. So I encourage you to check out what is DAPA.XYZ for some more information about what we're doing and the tools that we're building and the ecosystem that we're creating to create these abstractions for people and to make onboarding to the blockchain much better. Thank you very much, everybody. I do have four minutes and 45 seconds for questions, if anybody has any. A little bit of shyness. OK. Toys? Like physical toys? So the design direction of CryptoKitties is something that we hold on to very strongly. We've explored some physical toys, some digital goods as well. But we need to get it right, because our artists and our creative team, they spent lots of time perfecting and maintaining this standard for the art of the cats. So we're experimenting. We're looking to see what's out there. But it needs to be done right here. Oh, that's like a totally different product altogether, though. Sorry. Yeah. Thank you. What, sorry? Hi. You said you had a fall in daily active users from December to now. Yes. But you didn't really talk about what you might do to activate all the people who are non-active users. Can you speak about that for a minute? Yeah, definitely. So this early success of CryptoKitties has been largely about community engagement. We have this product in the hands of the community as quickly as possible. And we've been iterating based on their feedback. And I think that's important for any product that you're building. And for reactivation of users, it's been about keeping engaged with them as much as possible without being annoying, obviously. But it's tough, right? Like I said, I showed on one of my slides, there are so many hurdles that you have to get users to overcome. And really, it's about guiding them. You have to pin points where did they drop off, and why. And see what can you do at that point to re-engage them. From a human to human perspective, if you lost interest in something and I was trying to regain your interest and I told you about 10 other different things, you would lose interest even more, right? But if you can pinpoint where they lost interest and why, usually it's just because they had a bad experience. They got lost. And with a little bit of guidance through that one particular step, it could be super helpful. So narrowing down the information that you give to users to reactivate them is something that's super helpful. And also understanding why it happened in the first place. I feel very strongly about the human-to-human connection, as you can see. I think it's super important that, especially now that there's a ton of different pieces of software and apps out there in the world, they're in the millions by now. The ones that really engage with people and they make you feel like, there's human beings behind this. I think they have my back. That's where you're going to start to see your success. Yeah. Yeah. Thank you. We can talk after. Yes. You want to use the mic so everybody can hear you. I'm sorry. Thanks very much. And real congrats on being the first proper interactive user experience in this space. What do you think about all the me-to's that have come along since? Do you find it a, is it kind of, are they honoring you? Or are you just happy to see what other people are doing with this? Or what are your thoughts? Sorry. All the me-to sort of crypto-kitty-like products that have come. Competition is very important and healthy. If there was only one of our kinds in any space, then it would just mean that that space is unsuccessful. So I would, I encourage everybody to go out there and push the boundaries and see what's possible and add more competition and do different things. Crypto-kitties was an experiment for us, right? We're still in day zero of blockchain development and of DAP development. And everybody should be going out there and being experimental as well. So I encourage people to, I encourage the copycats. I love to see it. And we've made friends with them as well, you know. So it's a good thing. Hi. You have the ambition of, or you stated the ambition of 100,000 DAP users in Q3. Scaling is still an issue. Are you looking at Plasma or other Layer 2 solutions for crypto-kitties? So for crypto-kitties specifically, the way that we feel right now is that because it was an experiment, because it's our Gen Zero projects at DAPLA Labs, we will leave it there as is. Future experiences or games or applications that we build, we will consider like other, you know, as you said, like Plasma or sidechains or whatever. Yeah, so that's for future, but for crypto-kitties, it will stay on the main network for its life. That looks like it. Or anybody else? Yeah. OK. Hello, everyone. Thank you for this interesting presentation. I'm a UX designer, and I'm really curious what would be your piece of advice for UXers? For UX in general? Yes, and for the process that we follow and how you would like us to collaborate with developers. Any advice I can bring back to my team? Yeah, so I'll give you some insights into the way that we work. I'll talk about two different things. One is how we work as a team internally. So we have this concept called three-in-the-box. And three-in-the-box is where, if you're trying to solve a specific problem, you get people from different disciplines in the same room together. And people from different disciplines. So if we're trying to solve any problem, let's get a designer, let's get an engineer, and let's get a product person in a room together to discuss. Because everybody's going to say something that's going to impact the other person's way of thinking. If I, as an engineer, am like, listen, this is not possible, but this is, it can trigger some thought process in a designer's mind. To be like, oh, that's cool. Maybe I will design for that instead. And the same goes vice versa. If the designer could encourage me to think a certain way, then it will help me to develop better. And I mean, I have a very, very high respect for UI and UX people. They are some of my favorite people to work with just because of the way that they think. And they inform a lot of decisions I make during my engineering process. But that's internally. There's only so many decisions that you can make internally. But as soon as you put it out there, users are just going to do something totally unexpected. So user testing as quickly as possible is extremely important, especially in this industry where things are so new. There is no written standard. There's no article, there's no famous 10 usability design article for blockchain. It doesn't exist. We have to write those articles. And the only way we're going to write those articles is by doing the research ourselves. And we need to just, whatever it is we're testing, if it's a feature or full-fledged product, get it into the hands of users as early as possible and observe them. Observe their actions, take notes, and ask them tons of questions. Yeah. That's it. Oh, sorry, one more. That's it. All right, time is up. But we'll meet outside. Cool. Thank you, everybody.


We're here in Matooge district today where there has been a lot of families arrived here from different districts of the province. They pretty much left their homes with nothing more than the cogs on their back carrying a little bit of food and water and their children as they went. They've arrived here with no shelter materials nothing to be able to store and carry water and to be able to produce food so they're very vulnerable situation. We're providing here enough sticks and bamboo for people to make a basic shelter enough for a family of five to eight people so they don't have to sleep outside or on the veranda of the homes of the host families. We're doing this at the time of the coronavirus pandemic so we're having to make sure people really take care of social distancing or washing their hands before they start coming through the distribution process and keeping a good distance between each other and we're also using this chance to educate them as much as we know about the risks of coronavirus contagion and spread and measures they can take to keep safe.


Welcome to All Hands Update, I'm Petty Officer Jonathan Pankaw with your headlines from around the fleet. Training Air Wing 2 completed its 700,000th training hour May 31st at Naval Air Station Kingsville, Texas. The flight training hour milestone took more than 20 years to complete using the T-45 Goss Hawk training aircraft. Air Wing 2 trains more than 150 student naval aviators each year. The future USS Minnesota was delivered to the Navy June 6th, 11 months ahead of schedule. Originally projected to arrive in April of 2014, the Virginia-class submarine took a record breaking 63 months for Huntington Ingalls Industries' Newport News Shipbuilding 2 complete. You could read more about these stories at Navy.mil. From All Hands Update, thanks for watching.


Hello and welcome to the session, let's discuss the following question. It says, find the interval in which the function f given by fx is equal to sin x minus cos x, x lying between 0 to 2 pi is increasing or decreasing. So let's now move on to the solution. The given function is sin x minus cos x. Now to find the interval in which the function is increasing or decreasing, we need to find the derivative of the function that is f dash x. Our derivative of sin x is cos x and the derivative of cos x is minus sin x. So this becomes plus sin x. Now this can be again written as root 2 into cos x into sin pi by 4 because we know that sin pi by 4 is 1 by root 2 plus sin x cos pi by 4. Again cos pi by 4 is 1 by root 2. Now this is equal to root 2 into sin x plus pi by 4. This is by the formula sin a plus b is equal to sin a plus sin a cos b plus sin b cos a. Now for the function to be increasing, we must have f dash x to be greater than 0. So this implies root 2 into sin x plus pi by 4 is greater than 0. So this implies sin x plus pi by 4 is greater than 0. Now since sin x plus pi by 4 is greater than 0, that means x plus pi by 4 lies between 0 to pi. As we know that if sin theta is greater than 0, then theta lies between 0 to pi. And here theta is x plus pi by 4. So we have 0 is less than x plus pi by 4 is less than pi. So we have minus pi by 4 is less than x is less than pi minus pi by 4 is 3 by 4. So this can be again written as minus pi by 4 is less than x is less than 0 or 0 is less than x is less than 3 pi by 4. Now the given interval is 0 to 2 pi. And we see that these values of x that is when x lies between minus pi by 4 to 0 lies outside the interval 0 to 2 pi. So we ignore this interval and we have x belonging to the open interval 0 to 3 pi by 4. So this implies fx is increasing on the interval 0 to 3 pi by 4. Now for fx to be decreasing we must have f dash x less than 0 that is root 2 into sin x plus pi by 4 is less than 0. So this implies sin x plus pi by 4 is less than 0. Now sin theta is less than 0 that means theta lies between pi to 2 pi. That means x plus pi by 4 lies between pi to 2 pi. So this implies pi minus pi by 4 is less than x is less than 2 pi minus pi by 4. So this implies 3 pi by 4 is less than x is less than 7 pi by 4. Hence fx decreasing on the interval 3 pi by 4 to 7 pi by 4. So the given function is increasing on the interval 0 to 3 pi by 4 and it is decreasing on the interval 3 pi by 4 to 7 pi by 4. So this completes the question and the session. Bye for now. Take care. Have a good day.