Hello, everyone. My name is Jukkaris, and I work in the Intel Open Source Technology Center in Espo Finland. Our GOMS Team Develops Communication Technologies for Linux and Zephyr OS. This presentation describes new and native internet protocol stack for Zephyr. Currently, Zephyr has a Contiki micro IP-based networking stack. This new native stack will replace the legacy stack and initially provide same functionality as the old one. Native stack in this context means that the IP stack is fully integrated to Zephyr. It's using Zephyr coding style and is fully optimized to be used in Zephyr. So you may wonder why would we need the native stack. The Contiki-based IP stack initially provided suitable features for experimenting. But new feature requests were created and the limitations of the legacy stack were realized. And there's a list of some features that are missing in the legacy stack. So there's no possibility to have a dual stack IPv4 and IPv6. IPv6 is the more important one for IoT use cases as it's using heavily in 1504 and Bluetooth networks. Use of IPv4 is still important, but it's only used in Ethernet and Wi-Fi networks. Also, the legacy stack can support only one network technology at the time. This means that one cannot have Bluetooth and 15.4 networks connected at the same time. Related to this, there cannot be multiple network interfaces at the same time. For example, you cannot have multiple 15.4 radios running at the same time or having like a sleep or Ethernet connectivity at the same time. The legacy stack uses so-called big memory buffers. Its buffer is 1,280 bytes long in order to be able to receive one full IPv6 packet. This is quite suboptimal as typically the network packets in IoT protocols like co-op are very small way under 100 bytes. As the server is also multi-threaded operating system, using micro IP in this environment is a bit cumbersome, because micro IP stack is basically a one big loop that running in server in this way is very suboptimal. Also as these IoT devices just need to work, testing the functionality is really important. So we need the way to verify that each new commit in the networking code does not cause any regression. For these purposes, we are creating a unit and component and functionality testing. And these tests need to run after each commit to the source tree. With legacy stack this is a bit difficult as the code base already exists, and it's slightly easier to create these tests for a new stack. So why not port some existing stacks to server? There's a lot of third-party stacks available. Initially we used Kondike-based stack when we were creating IP support for server. It worked, but it had limitations as seen in the previous slide. The initial port tried to make possible to merge upstream fixes into the stack, but that became later impossible because the changes we needed to make to the code in order to be it being usable in server was just too much. There's also one big issue if one uses to use existing third-party stack as a library. It requires use of adaptation layers to adapt the library to the host operating system. For example, FNET and lightweight IP both provides hooks to enable them to be used in different environments. The extra adaptation layer scores is some memory overhead, because we need to map the buffering in these libraries to the native buffering, what is available in server. If we don't have this adaptation layer, meaning that we are deeply integrating this third-party stack into the operating system, I can server, then usually the code needs to be heavily modified. So instead we can just create the native stack instead. But this doesn't mean that we could not reuse the code from third-party library. For example, we have a TCP implementation that is based on FNET. And it's just that we cannot push back changes back to FNET or take patches easily from it, because the code has been changed so much. What this means in practice that the native stack is now the upstream stack. Having a unified look and feel of the code is also important. It is much easier to read the code and create the patches, if the code looks unified throughout the code base. This is very obvious if you have ever looked contiki-based code in the server legacy IP stack. One big improvement in the native stack will be the automatic utilization of the unit testing. For each commit we will run several unit tests automatically. It is certainly possible to create unit tests for third-party stacks, but this usually requires more work than creating these tests while developing the stack. So what exactly have we done with the native stack? First of all, we created IPv6 and IPv4 stacks so that they can go exist at the same time. The IP3 layer uses the common L2 layer that helps to abstract the device driver away. There's a picture in the following slides. This way it's easier to implement network interface support, so that we can support multiple technologies at the same time. We took relevant code from existing stacks like TCP from Fnet and Ripple from Contiki. We needed to heavily modify the code in order to support the server natively. We made also the network buffers much smaller in the native stack. The big buffers are gone, although if you really need those you can still create such buffers, if you don't have memory constraints. Now the smaller buffers are chained together to create support for a larger amount of data. With the native stack we can also now send data larger than 1,280 bytes. As I already mentioned we created the functionality testing framework that verify the native stack is working as expected. This is done in order to catch the regression in the code. The key features in the new native stack are dual IPv6 and IPv4 support. We have effective memory management. We have a possibility to have a minimal copy data path, but this is not always possible. For example the IPv6 header compression requires some memory copy. We also support thread requirements, but the stack does not support thread. Compared to the legacy stack all configuration can be done via kconfig. In legacy stack some config options were required to be changed in header file. As I already mentioned one really important key feature is the utilization of testing harness. In the right hand side there is a high level picture of the network data path. We have one RX fiber or thread, these are called fibers in Zephyr. That receives data from the device driver. The device driver is abstracted as a network interface. The RX fiber runs the protocol dispatcher logic. So depending on the data like UDP or TCP the dispatcher checks if there are any applications listening corresponding destination board. Then it passes the data to the correct application for further processing. Any control traffic like ICMP messages are handled in the course stack. But it is possible to hook into the system and get this directed to the application if really needed. In the TX side we have one TX thread for each network interface. And applications write their data to the TX5O that is then read by corresponding TX fiber. The data is then checked very minimally and passed to the device driver for sending. If the packet sending is okay the device driver will release the network buffer that was sent just now. And if the packet sending fails the upper stack may retry or discard the packet. In the lower levels we have the L2 abstraction layer which is very thin. Its purpose is to provide lower level services for various technologies. For example IPv4 ARP for Ethernet is handled here. It is possible to share L2 code between same type of technology device drivers like if you have multiple Ethernet interfaces or if you have a sleep and Ethernet at the same time they both share the same L2 code. The 15.4 stack has been enhanced in the native L2 layer. In legacy stack the 15.4 support was very simple and not fully spec compliant. In the legacy stack we are missing for example scanning and association and disassociation. The network management API can be used to start a network scan. It can also send events when important things happen in the stack. Like when a new IP address is added to the system. Applications can re-listen these events or activate some commands to initiate this scanning for example. As I already mentioned the automatic testing is one of the key features of the native stack. It's very crucial that we do this properly. We need to verify that any change to the code does not cause any regression. Creating these tests is not a trivial task but we need to do it. While building the stack it's a bit easier than writing them from scratch to the existing. If you want to see the code it's there they are in the tests slash net. For conformance testing we are currently investigating Tahi that is used for IPv6 testing. If you have any good suggestions for tools that help conformance testing we would be grateful to hear. Then some lower level detail to the stack. This is one part that is very important that the stack will perform optimally. Many third party stacks have a similar network buffer management scheme implemented. But it's not really possible to combine them with the separate network buffer implementation. This means that the third party stacks like Fnet would need to be changed to use the separate network buffers. The network buffers are allocated from pools and only the available memory limits the number of pools you can have. Although individual network buffer elements in one pool must have the same size. It is possible to chain these network pools, network buffers together. The chain can have different size elements in it. And this way we can actually receive larger amount of data than this 1,280 bytes. That is limiting factor in the legacy stack. Typically the size of the fragment in the chain should be selected according to the lower level network technology MTU. For example in 15.04 the buffer size should be 128 bytes in order to avoid any extra memory copy in the L2 driver. This L2 driver prepares the packet to be sent. So it doesn't need to fragment or reassemble the packets in the lower levels. The network buffer can have a user part combined with it. This means that the protocol specific data can be attached to the individual network buffer. For example we store IPv6 specific data in the user data part in order to speed up the parsing of the network packet. Typically we do it so that the first fragment of the head of the buffer chain contains this user specific data and all the network data is in the subsequent fragments. And all aspects of the network buffers can be configured via K-config. Some lower level details also continues. If the system is configured optimally the size of the network buffer is selected so that each buffer can have a link layer headers and MTU size data in it. So it's possible to reserve some extra space for link layer headers in each fragment. This is optional but recommended. So if we allocate these headers beforehand we don't need to copy data in the lower part of the stack when the link layer headers are put in this network data. But anyway the network buffer memory is not linear so it must be partitioned properly when applications are sending data. We have an API for doing that so applications do not really need to know about this. The link layer information is automatically added by corresponding L2 driver when sending to the network. In the receiving side the same principle applies. The data needs to be read in chunks by the application. But we have a helper API for doing that. Currently the code can be found in the Zephyr OS Git 3 under the net branch. And the current plan is to merge it to the 1.7 release. So the plan is that when 1.6 is merge windows opens we merge this code into the master questions. Yes, yes, there is... Did you talk about the API? No, no. We have a new API that resembles the BSD socket API. It's not really identical to it but it maps to the BSD socket API. And provides both asynchronous and synchronous APIs for the applications. No extra shim layers for these purposes. All the sample applications will be kind of work with the new stack. But any extra external applications need to be changed. You can add new fragments into this list if needed. Yeah, that's very easy. It's just to duplicate. What do you mean by duplicating it? There are several protocols running on the same error. And they need to modify the same errors. Somehow you will be testing it to duplicate packet. And you can change it based on... Do I need to duplicate full packet in this case or can I just duplicate? Yeah, I think you need to duplicate the whole packet. How does the new stack go for performance wise? Only ad hoc testing so far, so I don't have any measurements. But it's faster and smaller memory footprint. And one big reason is that we have less fibers, which means that we have less stack in use. And also the original kod contained a lot of extra stuff that was not really compiled out properly. So now we only have in the code what really is required for the functionality. We have a DHCP4 client already merged and DNS client also is available. Well, the Wi-Fi, we don't support Wi-Fi at the moment. But it's work to be done in the future. We have the management APIs for doing various management things. At the moment we just merged it in, so there's not much functionality yet. But we are adding right now scanning support and association to a pan. Well, at the moment the code is not yet there, but we are adding it. We are investigating this. There's no support for that yet. Yeah, there are a lot of tools available, but not many are open sourced. There are commercial tools. Yeah, of course we need for this kind of complex scenarios, we need a proper testing environment and real hardware and so on. We have this in QMO, we are doing functionality testing. So we are checking that we are sending some packet and is it correct and so on. It's kind of inside one QMO. Yeah, that's very interesting. Oh, okay. All right, good. All right, if that's it. Thank you.


So today, myself and a bunch of other mentors from NATO countries flew here, we landed here in Mika live and had a quick tour of the airfield after the words we saw a demonstration of a bunch of Ukrainian aircraft flying around and saw some paratroops and search and rescue capabilities as well. Following that, we had a tour of the various aircraft types they have here in Mika live. We were introduced to all their various capabilities. So we're here on Exercise Sea Breeze 21 to build the capacity of Ukraine, the United States, NATO countries and other NATO peace partners to work together in the Black Sea region in order to build strength and sure security in the event of any future conflict.


Hey guys, uh, Jeremy here with the review for Teen Titans Go To The Movies. I'll be the first to admit I am amazingly surprised I went and saw this movie. I was a big fan of the original Teen Titans show, I didn't watch it as much as I would say I watched Batman Beyond or the animated series, but whenever it was on during my high school days, I would pretty much watch it from end to end. I love the voice cast, I thought that was great, and I thought that the show had an edge of maturity that was unexpected but very welcome, especially with the character Slade, who was voiced by Ron Perlman. And I never thought that Deathstroke would be such an imposing and dark character. His relationship with Raven in that show was amazing. And like I said, Ron Perlman killed it with that voice. However, when the show was cancelled or ended and then it came back as Teen Titans Go, I was like, oh cool, they have the original cast back.   And I watched a few episodes of it and it was very kid-ish. It was very childish, it was these heroes, but in a very childish setting and I was immediately turned off and it never came back to it. So when this came out, I saw the reviews for it were pretty good and I was, how is that possible? And as people were saying, it's not just a kid's movie, it has kid elements in it, but it also has a lot of meta humor and even it's self-aware of how seriously the show was taken. And then there was this little tidbit at the end, apparently, that really would interest people. So I watched it and I'll admit it's like watching a Lego movie, but hand-drawn. The amount of energy, of child action, of meta humor, of consistent song, dance, flavor, explosion, and color is very much like watching the Lego movie. The characters are very self-aware of the DC universe, Marvel universe, all these other things. There's a lot of really very well written in humor.  But the whole movie revolves around the idea of the Teen Titans wanting to get their own movie, specifically Robin wanted to get his own movie, but he's always keep on being sidelined for Alfred, the Batmobile, the Utility Belt, everyone getting a hero movie before he does. And it, again, it kind of talks about the self-awareness of just how big the superhero movie business is and the self-awareness of the heroes with how much a movie matters to them. And there's a lot of hidden Easter eggs in the background too.  There's a lot of these posters, these art pieces that are both interesting movie ideas as well as great parodies of movies that have been made already. And I did enjoy that aspect to it. And there's a lot of really catchy songs, like an inspirational song about life, which just so happens to have Michael Bolton singing it, which I admit was pretty surprising. There's actually a really funny part with his character. And I admit, I laughed out loud a couple of times. I was, I saw this as a matinee showing, but I was laughing at a bit of the jokes in this film out loud, and that was a big surprise. I didn't expect that. It is what it is. It's a very simplistic, very generic. You'll know what the story is, the first five minutes you step into the film, but it's the music, the humor, and the meta awareness that really makes this film above a piece of garbage. And I did enjoy that aspect to it. Admittedly, it's not a very rewatchable movie. I'll just keep listening to that song over and over again. But the film itself, I will probably forget I've seen this when I go and look over my movie tickets. I'm like, oh yeah, I saw that this year. So it's not exactly the most memorable of movies, but it is an entertaining movie, not just for kids, but also for adults. And there is this little tidbit at the end, too, that you should stick around for. Because, well, I'll just say it looks like they're going to try and bring a mature version of Teen Titans back. Whether it be as a movie, which they've done, they've done Teen Titans or Young Justice versus Justice League and all that other stuff.  But then again, I did appreciate that this show points out a lot of the garbage that Teen Titans Go was a part of. And that's pretty cool. I don't know if it's the original creators of the show, but if they did, that's some pretty good balls on them to admit their faults for that. Anyways, I'm going to give Teen Titans Go to the movies a 4 out of 7. It's an enjoyable movie. It's a funny time. It's got some good music. And it's a lot better than I thought it would be. Anyways, guys, that's all from me. I hope you liked this video. If you did, leave a like. And if you're interested in more, maybe subscribe. Otherwise, that's all from me. I'll see you guys next time.


My name is Scott Miller and I am here with offensive computing and I'm going to be presenting a new bioinformatics inspired binary analysis toward coding style and motif identification. And there's a lot of people who are helping me up here. I was NSF, Scholarship for Student Service recipient and there's a number of people here, some of which are in the crowd heckling me now even as we speak. So the big thing that motivated this particular speech, there's a member who couldn't be with us this year at DEF CON, he was here last year. So this is dedicated to that B guy. I'm going to be talking about the concept of what I did for my thesis work and then how it was extended. It's a technique or a suite I'm deeming binblast after the basic local alignment and search tool. I'll be talking a bit about that and then I'm going to look at two separate applications. One is inversion analysis which is very important if you're trying to protect your own networks and systems and I'm going to work on or then follow that up with a discussion on the application for automatic signature generation for viruses. All of this, everything you're going to see in this presentation is just in preliminary work. It's the actual development of the system was highly theoretical, required a lot of testing, proving and validation, but even at the end of all of that, unfortunately right now the code is just at a prototype stage. So I'm in the process of stepping this up and going a number of different directions. So at the end, if I don't get to field your question directly, I'll be down in the corner over there and I'd more than like to hear your input. So as I kind of started off the speech, our current policy to defense, at least on a larger scale, is that we have various policy software and hardware that are trying to keep our systems clean and secure. The bad thing about this is that when a new exploit or new threat or something new comes out, if it's done well, it's going to require some patch to that system. It's going to require a change in policy. It's going to require changes in firewalls. It's going to require changes in hardware. The problem with this is that any time you make a change in a very complicated system, you're going to have to verify that this patch on the system has actually done two things. One, fix the problem that it was supposed to fix. And two, actually not create any additional problems. And as I'm sure all of you know, this is a very, very difficult proposition. And worse than that, not only you have to do all this on your own, but the time that you have to be able to verify and validate all of these patches is decreasing very, very quickly as motivated threats, I suppose, dominantly by monetary concerns are basically finding profit in your inability to fix and repair your system. Long and short of it, the very tools that we're using ourselves right now to defend ourselves are contributing to the very problem. So, well, what can we do about this? Well, there's a number of things we can do. One approach, I suppose, is just stick our head in the ground and ignore it. Another one is to actually start trying to take a more proactive approach to the defense of our security networks. So, as far as being able to do this, we need to start considering, when we bring code on to our system, what sort of function does it have? And fortunately for us, this sort of functional analysis from various codes is nothing new. In the biology world, they've been having to deal with this for many, many years now. And a lot of our new cancer drugs and research is the result of some very, very good work that was done in the early 90s. So, kind of fun here to draw. This is the analog that actually I was using for all of this work that you're seeing today. And that we have the code, your genetic code in every one of your cells, is eventually transcribed from DNA to RNA. And then it's translated from RNA into various proteins that allow you to stand. And further than those, these proteins enable you to form bones and all sorts of stuff like that. What's very interesting is that this is not in the least bit a conservative process. At every step, when you go from DNA to RNA, there is a lot of information that gets cut out. And when you move from RNA to proteins, there is, again, a lot of information that gets cut out. So with respect to functional analysis in a biology domain, you're given a protein, all right? Well, what section of my genetic code actually coded for this protein? Well, geez, that's a good question. It's a very difficult question, too. But it's kind of interesting because we've got the same sort of situation when you're compiling source code. Because when you go from source to object code, well, you're losing something. And when you go from object code to linking into an executable binary, that process, too, loses a lot of information. And that linking step may be compounded by additional packers and encryptors and all of this stuff, which basically serve only to remove more and more information. So it becomes harder and harder to sort of look at the original function given the final product. So one of the ways that the biology domain has come up to address this particular problem is, as I said earlier, a tool by the name of the basic local alignment and search tool, which was developed by Dr. Carlin and Dr. Altschul back in 1994 when the paper was done. And superficially, all it is is it's a scored string matching algorithm. So you've got a quick example at the bottom here. And you can see we're going to do an alignment of two words. Let's say, if the characters match, we're going to add one. If the characters differ, we subtract one. So it goes along and we're adding stuff up until we reach what appears to be a local maximum of four because THES and THES match. And after that, it starts to taper down. So this brings up a couple of important points. The BLAST algorithm is actually an approximation. It's trying to come up with a local minima for this, basically find the string that has the highest match. But it's also important that it doesn't try to match everything in the entire string, because then you basically get back trivial answers. You'd say, well, does this file match this file? And it would come back and say, yes. Which is not unto itself entirely useful. So under the covers, the entire process is funded on a first order Markov chain model, which makes an assumption that is not up on this slide, but it's kind of important to know. And that assumption is made because it is a first order Markov model that the choice of the next instruction is not dependent on the choice of the previous instruction. I have very, very good reason to believe that this is not the case. There are certain sections. Compilers have automatically generated code. So it handles certain sections like structures and this and that. And every compiler has its own little way of saying, all right, I'm going to take this particular structure access and I'm going to use this set of op codes and fill in the memory offsets, fill in the registers. It's a template. So the assumption, superficially, it seems as though the assumption that using this sort of technique is flawed. Ooh, I've got this problem because the choice of instructions is not strictly independent. However, this is also a similar, there's a similar problem in the biology domain as well. So the kind of over what I was trying to do here is just get the start of this concept. Because once I get this first blast approach working, there's a number of variations on the blast algorithm in the biology domain that can handle this sort of repetition. And I'm only going to briefly talk about those. So how did I come up with all this? Well, I looked at what Distra Watch said at the time or the top five Linux installation. I stripped out all of the binary packages they had on there, looked at all of their instructions, which came up to half a billion instructions and then came up with a little storage format which reduced it into a common four-byte format. So there's the first two letters of the mnemonic were used in the operator class. And that choice, two instead of three, actually maximizes a particular namespace, which is kind of beyond the scope of this presentation, unfortunately. And then I went and truncated the operator to one byte and then had the operands to two bytes. So this is kind of making the assumption that in a system, the operands are the most likely to change. And I think this is a fairly safe assumption to make in the x86 system. So what can we do with all this? Well, I'm working on getting together a suite of all of these program in more of a production code setting, which does not have the, perhaps, the tedium of my thesis where I was actually sitting with a piece of paper next to my computer writing out offsets. So where it's going right now is I've developed a couple major analysis tools. I've got a quick little program to help build your libraries and indexes, basically reducing everything into that four-byte format that I was talking about earlier. And then after that, we have the actual comparison engine. And then kind of as a nasty side effect, it's necessary to filter the output. And this relates to the statement I made earlier, because the input is not random. The input choices are not random. There's a lot of extra interesting stuff that comes out of it, which is something that needs some work in the future. I'll get to that in a bit. And then there's also a program that helps with some visualizations. It does some side-by-side disassembly, helps generate some tables necessary for other tools, things along those lines. So this is kind of the overview of what I have so far. The general process I've kind of thought of is basically you use makelib to build up your library.  You pipe the output through it. And after that, you run that through match output to get the result that you want. The kind of unfortunate thing of this is any time you're starting to go from prototype to production code, your definition of what you need to do functionally changes. I spent a lot of time working on a web interface, which unfortunately does not have the utility I'd hoped it to have. So instead, now I'm going to focus a bit more on the command line tools. But this is kind of a sample of what I was able to come up with, where you can see the raw results are in the lower right window and some of the similarity in coverage tools are in the upper left corner. That's kind of hard to see. I apologize about that. So with that said, here's one particular application that I kind of see for this technique. And that is inversion analysis. So we have here, we're going to do a version analysis of SendMail. So we've got four versions of SendMail and two controls. The negative control, which is completely as far away from the mail transfer agent that's server and socket base that I could get, which is a graphics side scroller by the name of Chromium. And then I have a positive control, which is a sort of competitor mail transport agent to SendMail post fix. Now, it's kind of interesting here. I want to point out that the last entry, SendMail891, is the only one that was compiled with a pre-GCC3 compiler, which this shows up a little bit later. So as far as what you actually get out of this technique are these fairly confusing raw results where you get a score. It's that integer score I was talking about, how long the score is, and two offsets, where it basically matched in the both sets. So you get a sort of what's called an alignment, a scored alignment of two sections of code. And dominantly, the major alignments that you see right off the top are these huge sections of code in the beginning, which are responsible for resolving all of the external library dependencies. So this is something that it's very, very repetitive. It goes on and on and on about the same thing. So I'm sure most of you in the back can't read this, unfortunately. But basically, it starts off at the top. You have a typical entry point. And then after that, you have all of your symbol resolutions, which is this continuous repetition of 3 or in GCC 3.0, it was anywhere from a 3 to 5-code op-code sequence that was repeated over and over and over and over. So what can you do with this? Well, all right, we go through. And instead of considering the individual matches, let's group them into what coverage. So OK, I have file A, and I have some other file I'm going to compare it against. And instead of trying to figure out all of the possible matches, just say, well, how much of file A is included in matches to file B? So you can compute a similarity measure. And from this, you can compute a distance measure and use, again, a biology, a very, very well-established biology tool by the name of Philip, which is the phylogenetic inference package. So all of these graphs are directly generated using biology domain tools, which was very, very, very convenient. You'll note from this graph right off the top, you'll see that sendmail891 is very, very distant from everything else. In this particular graph, which is an unweighted pair group method with arithmetic mean, this graph, the horizontal distance, is significant. And the vertical distance is just to show association. So what this says is that sendmail891 is very distant from a common ancestor, where the other five programs are very close to some intermediate ancestor. So this is kind of an interesting graph. From the standpoint that in the biology domain, there is very, very, very hot debate over the graph on the left and the graph on the right. Now superficially, it might seem as though they're kind of conveying the same information. However, the graph on the left in the biology domain has been hotly contested because it is associated with what's called a molecular clock, where there's an assumption made that mutation rates happen at a constant interval. And in the biology domain, there's been increasing research to support that says this is not an assumption that you can make. And I think it would be safe to not make, rather, the same assumption in the computer science domain because the way malware is adapting and evolving, I pretty much think has no really deterministic sort of mutation rate. So the graph on the right is what's called the nearest neighbor method. So basically, it's a graph as opposed to the left, which is a tree. And it basically shows the current relative distance from everything. So what that graph says is that sendmail 813.4 and 813.5 are really close together, followed in a close second by sendmail 812.9. And then the negative control is slightly closer, or the positive control postfix is slightly closer than the negative control. Chromium. So again, this reflects kind of intuitively, well, duh, this is what we were expecting to see happen. But that's a good thing. I think it indicates this technique has a great strength. And this is something that I've applied against some other malware approaches. Have I quite gotten to the approach where I've considered 20, 30, 40, 50 pieces of malware and tried to put them in the same graph? No, not yet. And again, this comes from the ongoing development of production code to automate and produce these results with little interaction. So I'm going to talk now. OK, so there was one thing, version analysis, which is, again, very important if you're trying to receive and update your system and be able to keep up with those updates and say, OK, yeah, yeah, I've got this version of code that came in and oh, yeah, it's this new DLL. And oh, yeah, it looks pretty much like the last one. But it seems to have, well, it has something that looks like a root kit. Well, that shouldn't be in there. So that's the sort of thing that I'm hoping to address with version analysis.  So how does this work? Well, the step one, again, talking about the coverage of various programs, we start off with comparing the file, some malicious malware against other malicious malware against, that's pretty much your candidate generation set. So you're asking the question, what makes this particular program unique in a set of other programs? And after this point, you're going to get a collection of fragments that are included in the partial or fuzzy matches. And then after that, you can take the negation of that particular set and get the fragments that weren't included in any match. And at this point, the third line down, this is where you're actually working with the sections of code that make the file A unique.  In this way, you basically remove the candidates that match yourself and you end up with a selection of programs that, a selection of signatures that match this particular nasty or good thing or whatever as unique. So here's a quick example, and I'm going to do a really brief demo here. And so let's pose the question, what makes Borland Compiler Code unique? So the way we're going to go about doing this is first I'm going to use a very, very simple code program that will exercise a number of compiler constructs. And then after that, we're going to go ahead and compile this against a number of compilers, Borland, VisualC, GCC, to basically get some set to compare it against. What I'm not going to do is actually run that final candidate generation and negative selection. That is something that hasn't been quite reached yet. So we go over here, and we're cheating already. We have the answers. So we'll start again. So we have basically the output of the bin blast program after it's run through bin compare. So unfortunately, this is very tiny. We will go ahead this way, and that does not make it any less tiny. Oh, unfortunate. But basically, what this is showing is it's just showing this sort of foretuple of results and how they match up. So we're going to run this through a brief program that will run that candidate generation that I was talking about. Because that previous result set basically says these are the sections of code that were included in matches to other files. So we're going to run this against through the candidate generation program. And we're going to get out a bunch of possible candidates. So of the three compilers that I compared, the three executables that were generated, these are all of the difference according to this technique. These are all of the differences that were reported. And you can see this list is not very long at all, not very long at all. And by the way, if you were kind of curious as to what the code was, this was some example code that Chris Eagle had come up with, which basically it's just a short series of comparisons and just some boolean operations to exercise various, if-then-else constructs, switch constructs, very simple code. So let's go ahead and say, all right, so we've got this, all right, what's it here? It's DEC9DB, seems to be a unique code. So we're going to pop over here, and we're going to go ahead and look that up. DEC9, so that's just the start of it. So what does this actually look like? Well, and it looks like we're matching on a floating point multiply. Well, geez, that's kind of odd. I wonder why Boerlin's spitting out floating point code when working with just some simple integer operations. Kind of something interesting, unfortunately. As I said, the code is moving forward towards production code. So this hasn't gone through a very thorough analysis. And as I said, I was borrowing this example from some of Chris Eagle's examples, so I don't have access to a Boerlin compiler right now. So this is just kind of a quick overview of what sort of things you can do with this. So back to the beginning of the presentation, which is not quite where I wanted to be. So we were here, and so we were able to very quickly generate signature, as it were, for what makes or may make Boerlin code unique. So at this point in time, I have just flown through my presentation. So let's look at some additional information here. So I mentioned earlier that I'd done some phylogenetic analysis against a couple, anyways, malware codes. So I was looking at three versions here, My Dunes, A, L, and Q, and I had, for comparison, both the packed and unpacked versions. So again, running it through this technique, it refers to something that it creates something that infers the same sort of technique or what you would intuitively expect. So this is pretty much, all right, well, we know that MyDOOM, A, L, and Q are very closely related.  What's kind of interesting on the nearest neighbor graph on the right that MyDOOM, A, and the packed version of MyDOOM, A, are very close to each other. I still have yet to actually sit down and look at quite exactly why that is. It's a bit of an enigma. It may be that the packer was used a bit more judiciously later on. It could be that the MyDOOM, A code just didn't go through the UPX packer very well. So these are all questions that, who knows? So, kind of in summary, what I've talked about so far is that basically by making a simple analog, I was able to pull over a technique from the biology domain. And it seems to be working very well, at least in the test cases I've evaluated so far, that it seems to work well on binaries. And I'm developing an open source suite and it seems to be sensitive to compiler code generation. Well, there's some other benefits to this as well, because it is a very simple technique. It has some excellent runtime characteristics, which is something that I'm hoping to exploit in some of the future work. As I said, production is, I'm working right now on moving this to production code and the people at Offensive Computing are helping quite a bit with this movement. And moving towards things, helping out greatly with their automatic malware classification is the big project that I'm pursuing right now. However, I'm hoping to, in cooperation with their collaborative reverse engineering environment, start to use this to identify those particular motifs. As I'd said earlier, that when you run this code, if there's not randomness in the data, you end up with a lot of repetitions in the output. Well, one of the ways that in the biology domain, they have actually solved this is by identifying particular motifs, which is kind of a fun concept in that you can go through and say, all right, well, I've done some reverse engineering and I've come up with this. This is a ROT-13 decoder. All right, and I've looked at it. So I add it back into the reverse engineering database and I say, all right, this particular section of code here is a ROT-13 decoder. And then anytime that particular code sequence shows up again, you have a database of, this is the motif. So let's say you get something brand new, like you've never seen MyDoom, assume for a moment, you haven't seen MyDoomD before. So you run it through the algorithm and all of a sudden you get a match to this particular library you have of existing code motifs of stuff that you've spent a lot of time to develop and a lot of time to consider. And well, lo and behold, all of a sudden you're getting a large number of matches to this ROT-13 decoder. Well, what might that indicate? Well, perhaps this particular virus is using some sort of encoding scheme like that. So from the standpoint, I'm sort of approaching this as not only an automated tool, but an interactive tool that will allow you to database your previous reverse engineering experience and extend it to your new work. Because as I keep on saying over and over again, the time that you have for identifying patches to your system is going to go down to almost zero. And so you need to be able to have some way to defend yourself. And soon this will all be available at the offensivecomputing.net site. Unfortunately, as I said, it's kind of a tedious process of trying to find new functionality, refining the program analysis, and moving forward. So at this point in time, I'm running well ahead of schedule, but I'd like to open it up to any questions in the audience. Now, there is a microphone in the center, so if you have any questions, go ahead and go out and use that. Are there any questions right off the bat? I was just curious how your analysis would handle polymorphic code. Well, that is an excellent question. And there was very, very early on, there was a great consideration as to how might this technique be robust against such a problem? And one of the ways in which it does this is that it tries to make the assumption that, all right, so every architecture has some sort of move operation of some sort, some sort of memory management, and you have your ads and your subtracts and your multiplies, your divides, your pushes, your pops, well, depending upon your architecture. So instead of just strictly considering, all right, this is the instruction, I'm gonna do an exact string match, I'm gonna do a fuzzy string match. So if I match just the operator class, so I've grouped all the operators into a class, if I match just the operator, I'll add four. If I match the entire operator, not just the class, I'll assign that, I'll add five to the score. And if I match the entire operator and all of the operands, I'll add six to the score. And if there's no match at all, it subtracts four. And this was the result of the Karlin-Altscholl analysis mentioned here. So in this way, it has some resistance to polymorphic code in that it's looking not only at the specific operator's operands that are being issued, but kind of sort of the general gist of things is what it was going for. Additionally, because this is doing sub-alignment matches, it's resistant to code reordering. So if you take a block of code, split it in two and shift those around the file, it will say, oh, you have, it will match that first part and the second part. So in that way, it was designed to hopefully deal with polymorphic code in mind. Unfortunately, as I said, it's one of those exciting things, actually, to be able to have something that's just kind of at the start. And it's something I'm, there was part of the design that it would be resistant against that. But as far as how it actually does, well, that's a good question. I haven't quite gotten to that yet. Does that answer your question? Excellent. Do we have any other questions? You ever used or heard of a tool called Bendiff? Yes. Yes, this differs quite a bit from Bendiff in that Bendiff is looking at a sort of function block level. And basically it is looking and going through and cataloging the various function calls that are made. And basically sort of doing analysis on kind of sort of a basic block level. This is actually going one level lower and actually doing instruction sequence level analysis. So yes, yes, Halver's work is actually, I looked at it very, very closely in the development process. And it may actually have superior performance to this in terms of runtime analysis. This is a bit more heavyweight approach. This is, as I said, this has the potential to possibly have a better, better resistant to polymorphic code. Who knows? The long and short of it, does that, first of all, does that answer your question reasonably? The long and short of it was mentioned in Danny and Anthony, or Danny and Valsmith's speech earlier that everyone needs to collaborate. We all need to collaborate as far as trying to go against reverse engineering of malware analysis. So is there any one singular solution to all of the problems that we're facing now? I think not. It's trying to come up with a general solution. There may be some general solution to this approach. Who knows? But I think it's kind of interesting and important that everybody collaborate and say, oh, okay, well, we've got this tool. I've got it to a point where it's working. Well, how well does it work? How well does it work against Bindiff? And that's actually something that I've not really had a chance to get my hands on yet. I have an evaluation copy now, which I'm gonna to look at and play with and see how it does. So this is just kind of the result of a quick paper napkin idea, well, what can I do with this? And it's kind of going from there. So incidentally, he made reference to a program called Bindiff, which is the third from the bottom reference that I have here. He had a paper by the name of structural analysis, or it was a structural comparison of executable objects, which was one of his earlier papers. He's done a lot of work since then. I believe there's even a new version now. So yes, I'm very interested in looking at that. And again, does that answer your question? Yeah. Excellent, excellent. Do we have any more questions? How does it handle code that is designed to generate instruction offsets at runtime and then use indirect jumps or calls to obfuscicate the actual code locations? That's a good question. Let's see, do I even have an example of that here? No, I'm not gonna, that's gonna be probably a bad idea. As far as that, unfortunately, all of the work that you've seen up here on the screen today has been based off of an assembly generated by the ObjDump Util, which is a spanning search type disassembler where it basically starts at the beginning of the code section and starts to produce op codes. And incidentally, this particular approach does a very poor job of what you were describing, where basically it has code that will jump to some sort of offset fragment within the existing code. And as it stands now, using ObjDump, it does an incredibly poor job of that. However, I'm looking at actually making use of some better disassemblers, looking at linking into Ida Pro, which has kind of an interactive disassembly approach where you can walk through and say, okay, well, if I do a static disassembly, this straight up, this is what it's gonna look like. However, there's a lot of stuff in here that's intentionally fooling the disassembler. So if I step through and say, well, no, no, this is not quite the alignment you were expecting, let's go back and start that again. So that's one approach to doing it. Another approach to doing that I have considered is kind of related to another interesting way that this might go, which is actually looking at just straight dumps off the network, straight dumps from memory. And in much the same way that the encoding process with DNA works where basically you have to define a structure or a reading frame before you can actually begin this process, much the same way, consider all reading frames. So okay, I start a static disassembly at this byte, I generate some disassembly. Well, how to turn out, okay. And then just move one byte forward as opposed to trying to go through the instruction directives or the, rather, move one byte forward instead of moving two or three bytes forward as one might expect given the particular instruction that's being executed. So that's another way to do it. So yes, yes, unfortunately what you see up here does not do well with that, but I'm looking at some ways to try to be able to address that in the future. Does that answer your question? Excellent, excellent. Do we have any other questions? Do you see this is applying equally well to a semi-language from all different architectures or is this X-80 specs specific? It's an excellent question as I kind of was a little quiet. So your question was, is this cross-platform, is this applicable to other architectures? Yes, okay. As far as that, yes. The way the hashing algorithm was developed to do the code classes or do the operand classes, it's an automatic system that regardless of what your disassembler spits out, it will be able to do that sort of analysis and it will be able to match the moves, ads and what nots. Unfortunately, different architectures have some major differences in the way their code is actually generated. For example, or for example, whereas the X-86 architecture is a stack-based architecture, memory-to-memory instruction architectures, I don't know, something like maybe a PowerPC type architecture, the code that's gonna be generated is probably gonna look quite a bit different. However, the kind of corollary to that is that there are a number of systems out there now which are including virtual machines and trying to do cross-platform development. So by the very nature of trying to develop code that works on many different architectures, I'm hoping that this technique will have some, actually improve its detection of that type of stuff. Does that answer your question? Yeah. Excellent, excellent. Have you seen much striation in your output based on the breadth of outcodes used for different instruction sets or special-purpose opcodes for specific processors? So your question is basically looking... Does it separate out based on the instruction sets compiled with and if they're using anything that like, say, the C language won't represent an opcode? That's a good question. No, I haven't looked at that yet. I haven't quite looked at a broad spectrum consideration of a great variation. The dominant compiler that was used in this work was GCC because that's just what the distributions that I was using. How well does it hold up against other platforms? No clue yet. That is something that is most certainly on my to-do list and it kind of relates to not having the full up production code yet. So that's a direction I'd like to go. Does that answer your question? Oh, good, good. Well, the question was for those of you who couldn't hear, he asked, how is that helping to clear the tubes? Well, you must understand, it's not a truck. You can't just put anything on it. So this is gonna take a racehorse and put it through the tubes. Does that answer your question? Okay, all right. Any, oh, question back there. So the kind of graph you've shown, right? The phylogenetic tree. So you would get those, especially the one on the left, with any kind of a hierarchical clustering scheme, correct? Yes. Say with Huffman clustering, you would get that. Provided that you have the distance. Same thing applies to the nearest neighbor, key nearest neighbor. Again, provided that you have a distance, you will get that sort of a picture for any distance that makes sense. So now, I understand that you're using BLAST as a means of obtaining that distance between two stretches of code, between two passages of code, right? Yes. Transformed according to your bitwise, sorry, opcode compression classes, right? Yeah. So these being your features. But have you tried simpler distances, perhaps? Something like a naive Markov first order model, this opcode predicting the next opcode? That's a lot less sophisticated than BLAST, but how well would that do? Well, that's a good question. Wouldn't that produce the same kind of thing, or would that be all over the place? Honestly, I don't know. It's a way, actually in the number of presentations that I've given, kind of leading up to this black hat presentation, that has been something that has come up a number of times, and I have no answer. I've not actually pursued that particular sort of, not sidetracked, but sort of parallel to this research. Does a simpler model actually produce the same results? Well, what I'm proposing here is that we step back and take a wider view at this formalism. And what this formalism really means is that you are defining a distance between two stretches of code. BLAST does not have to be that distance. It can be something based on naive Markov, hidden Markov modeling, and so on and so forth. Okay, right? So it's not like BLAST is, so it would be really interesting to see whether code is like the genome, or maybe code is somewhat different from the genome, and a different distance would give you a better measure? Right? That is an excellent question. Actually, while you were presenting your question, I came up with kind of some related research that I'd gone over. I'm not the only one who has been considering trying to do this sort of nearest neighbor type analysis. And actually, there's two people out of, I think Italy, Ero Carrera, and I unfortunately can't say his colleague's name, just my language skills are not sufficient to be able to do all that. So Ero Carrera and others had a paper back in 2004 as Digital Genome Mapping, where they used a slightly different measure for determining the distance. And it showed, again, it showed even, it was not the same, but they were able to get the same sort of graphs. So you could get mutual information between bytes at different distances, right? Yes. The information theoretic. I think this is what they used. Yeah. I think this is the sort of thing that they used. You could use where we can take the self-line. Oh, okay, excellent. But yeah, it was a great idea to use blast in it. Well, it was kind of the underlying approach was, all right, well, we've got a similar problem. What tools work for that similar problem? Well, hey, here's sort of the Swiss Army knife. Does it work here? Yeah, it does. Well, how far can we extend that analogy? But you do bring up a good point. This sort of research would probably benefit from a sort of cross-analysis to other sorts of distance measures, because is this the only way to develop a distance measure? No, it's just the one that I've kind of been looking at for now. So thank you for your question. Thank you. Any other questions? All right, again, thank you. You've been a great audience. I appreciate your time, and thanks much.


So, flow control and error control in terms of asking me to resend are what we combine together and call part of protocols that support delivering the data across the link efficiently. And we give them a name data link control protocols, controlling the data communications across the link. Up until now we've mainly focused on signals. And now we're talking about messages, also called frames or packets, like our envelope contains some extra information and the data. And last week we ended up with a picture of a frame, data plus header and optionally trailer. We want to get these messages across our link efficiently and the different ways for doing that are classified as data link control protocols. There are many things that need to be done to make sure we can efficiently communicate across a link. Two of them, flow control and error control. That's what this topic will talk about. But there are some others. In my example we had a source address and a destination address. So again, what's the format of the addresses is part of these protocols. That is, a computer doesn't use a name like Steve, but usually we use some binary value to represent the computer. So the address formats and how to get addresses are also needed in data link control protocols. So addressing, where is it here? Sometimes in some systems before we send data we need to tell the other one that or check with the other ones ready to receive data. So there are some aspects of setting up a link or maintaining a link. And there are a few other things necessary to make sure that we can communicate across a link. We're going to focus just on flow and error control. We may see some more examples of addressing in later topics. And we talk about all these features as data link control protocols or in the layer of protocols called the data link layer. And I think the next topic, which you don't have lecture notes on, we'll talk about more generally what a layer is, not so important right now. Let's go direct to flow control. How do we make sure we don't overflow the receiver? And this tries to draw from a computing perspective what happens when we send data to it from transmitter to receiver. This rectangle is the transmitter, the source device, and this is the receiver. We start with some data, I call it a packet in this case, but we have some data to send from source through to destination. The source, if you notice what I was doing, I had a lot of data to send and I had it storing in my hand. I stored that data in my own buffer memory or queue. The memory is the implementation of what we sometimes call a queue or just a buffer. So I store that before I send it. And then I create this message, I attach the right on the source address, the destination, I check, calculate the parity bit, set the sequence number. So I create the message, this is this processing the frame, and then I transmit it. Now this is illustrating I have a bunch of data, I create an individual frame, in this case one envelope, and send that across our link. It's sent across the link as a sequence of bits and as the receiver received that message they put it into their queue or in their memory and they process one at a time. The processing in our example was they check the parity bit, check the sequence number, convert the binary data into an ASCII character. It depends upon what the protocol is doing, what the communication is doing, but generally we receive, put the data in a queue and then process one at a time. The problem is that we only have a limited amount of memory. The receiving device doesn't have an infinite amount of memory so that if the source sends faster than the receiver can process, you can think it's processing one but more arrive and put in the memory. So eventually the memory will fill up, what happens then? Let's say the memory can store five messages, currently it's full of five messages with processing at receiver and then a sixth message arrives, what happens? Memory is full, another message arrives, what happens, what does a receiver do? Okay, too far advanced. If we don't have flow control, what happens at the receiver? What happens in the first case? If we don't have flow control, you lose the data. Well, either the one that arrives is just discarded, we throw it away because we've got nowhere to put it or maybe another option is one of them in the queue is discarded. In either case the result is we lose some data. It was sent but was not received and that's bad for performance because we're sending data but we don't have the ability to successfully receive it and that's where we lead to flow control and the idea is that somehow the destination will tell the source to slow down. So that picture just tries to illustrate from a computing perspective, we have especially the receiver memory to receive the data, we process the data or a frame, eventually the memory may fill up and therefore we can receive no more data so we need to tell the source to slow down and that is described on those notes. If we don't slow down we'll have a buffer overflow, ignore that picture, let's go direct to, I'll come back to two of those slides, let's go direct to a simple way to do flow control and the name is called stop and wait and it's what we used to communicate, it's very simple. In this picture and I'll describe it after we go through the protocol, A has a lot of data to send to B, so stop and wait protocol defines the rules such that A can send one message, one data message, once they send that A will have to stop, they cannot send any more data, they must wait for an acknowledgement message coming back saying they're allowed to send more and that's, I've tried to illustrate here, A sends a data frame to B, after B has processed that message, B sends back a special message, a frame called an acknowledgement frame saying I acknowledge the data you received, you can now send me more and when I receive or A receives this act frame they can now send the next data frame, they send the next data frame, after sending that data frame they must stop and wait for the act to come back, this is a very simple flow control in that we can only send one message at a time, we cannot send the next message until the receiver says they're ready for it and they'll only send the act when they're actually ready for it and it's similar to what we did, I sent a message then I stop and waited until I received a response back saying I can send the next message, they're ready for the next one, let's stop and wait flow control, any questions how it works, very important one, send data, wait for an act, once you get the act you're allowed to send more data, if you have it, if you don't have data you don't send anything of course, but if you've got a lot of data to send you can only send one at a time before you have to wait for an act, let's now try and describe this picture in a bit more detail by just explaining explaining some parts of what the picture shows, because we'll see these types of diagrams I call, sometimes called message sequence diagrams or timing diagrams to illustrate examples of communications, the vertical lines represent the two devices communicating, A and B, so two computers and the space between them indicates there's a link between them and as we go down the vertical line time is increasing, that's how to visualise this and we use these diagrams to show the transmission of data or the transmission of frames and also the propagation, remember the delay of in a communication system, the delay had four components, transmission, propagation, processing and queuing, in these diagrams we can represent them by showing the space covered on a vertical axis, so delay is just the increase in time, so transmission I show as this rectangle here saying our data frame has some time to transmit, so if we start at this time, start transmitting and the time it takes means it would end at this time, so I draw a rectangle here to indicate this is the transmission time for our data frame, you could calculate that if you knew the data size and the data rate, you can calculate transmission time and put numbers to it, transmission time, as we transmit a signal representing each bit in that data that signal propagates across the link, so I transmit out of my computer a signal, that signal to get to computer B takes some time and that time is called the propagation time, so on this diagram that's illustrated by the difference between when that bit was transmitted at A until when it was received at B, so you see this is the propagation I think it's on the next slide, the time from here to here is the propagation time, we can think of it in detail, A starts transmitting the first bit of that frame here, the signal representing that bit propagates through the link and arrives at this time, so the first bit is received at this time by B, but B must receive the entire frame before it can make use of it, so the second bit would arrive a little bit later, the third bit and eventually the last bit is transmitted here and arrives here at this time B has received the entire frame and can do what they like with it, process, so we use these diagrams to illustrate the timing of sending messages, messages propagating and processing, in simple terms it can be summarized like this, this represents the transmission time and this is the propagation time, processing time we just show by some space here of not transmitting and we'll see some examples of that in a moment, so that's the type of diagram that we're going to use in this lecture and in other lectures, now the stop and wait flow control we describe the general approach, send data, stop and wait for an act to come back, we have two types of frames, the data frame will give each frame type a name, obvious one is the data frame that contains the data we want to get from A to B, so our message or a portion of the message, it also contains some other information, like our envelope was a data frame, inside was the data on the outside, the header contained the source and destination address, sequence number and parity bit, so the data is inside but we also have a header with extra information, we also have an acknowledgement frame which may not contain data, we didn't see that in our case but a message comes back saying you're ready to send more, I'm ready to receive more, so we call that an act frame in short and the rules with stop and wait flow control, the source sends a data frame then they must wait for an act before sending the next data frame, from the destinations perspective when they receive a data frame they can reply with an act if they are ready for more data, if they're still processing they don't send back the act but once they're finished processing and ready for more data they send back the act, so the destination controls how fast the source sends by controlling how fast it sends the act, if the destination is busy, takes a long time to process, they simply don't send the act back until they're ready, we've covered our first flow control protocol, we'll see later the same tech, a similar technique is used for error control as well, with flow control we assume there are no errors at this stage, let's say everything is perfect, the data always gets delivered, any questions about stop and wait, the rules for how it works, so this is just one example, a has data ready to send, when I say data one arrives it means a has some data to send, it creates a frame, transmits the frame, the frame propagates to b, b receives the frame, maybe it has to process, it takes some time to process and then it has some buffer space, some memory available, when it's ready it sends an act frame back to a, transmission of the act, propagation of the act and at this point in time a which has data two already to send, so I'm saying at this point in time data two is ready to send but we're not allowed to send it because we haven't received the act yet, once we receive the act we send data frame two, when it's delivered that is it's received by b, it's processed, send back an act saying you're ready for more and at this point note that during this time nothing is sent by a because a has no more data to send, it's only until here that a has data three to send then it sends data three and my diagram would keep going, so it's incomplete any questions on stop and wait flow control, then I'll give you five minutes to calculate the answer to this, the source a has three 1000 byte messages to send, think it has three frames to send, destination takes one microsecond to process each of the frame once it receives them the data frame has 1000 bytes of data plus a 20 byte header, that 20 bytes may include the addresses the sequence number and other information but we don't know the details we just care about the size in this case an act frame which comes back from b to a contains just 20 bytes no data just 20 bytes of header think of it the link between a and b is two kilometers long the data rate is one megabit per second and the speed of transmission we assume is two by ten to the eight meters per second before you answer what is the throughput what I ask you to do is to calculate that is to draw the diagram like on this slide but while you draw it out keep track of the time remember time increases as we go down so the best way to think about it is that at the start is time zero so if this is time zero what is this time well it depends upon the transmission time you calculate the transmission time all right so then what's this time at b again that depends upon the propagation time so you know that you know the time at b at this point and keep going and find the time for when the act is received and then we'll calculate the throughput once you find the timing so the way to solve this is to draw this diagram but as you draw it keep track of the time as we go think of it as a clock that starts at zero and increases a counter depending upon how long each step takes try and calculate for a few minutes and then we'll go through some steps to to solve that


Remember when I told you about never before seen Monster House deleted scenes? Well, there are more. I was at the park, swinging on one of the swings. At that moment, I saw a sealed package next to a fence. I jumped off of the swing to grab the sealed package, and wondered what it is. I waited for my mom to take me home so I can open it. When I got home, I opened up the package and it was a Monster House DVD in a CD case. It was labeled as, Monster House, for deleted scenes. There's more? I said to myself. There were more deleted scenes. I showed the DVD to my parents, and my mom approved me of a rare find, while my dad thought I could make money from discovering rare items. One afternoon, while I was home alone, I thought I should watch the deleted scenes on the newly discovered DVD. It then took me to the menu. There were four different deleted scenes. 1. DJ vs. Never Cracker, deleted version. 2. DJ's nightmare, second deleted version. 3. Jenny gets possessed. 4. Never Cracker's spirit. Whoa, I spoke. I hit play all and the first deleted scene played. It started with DJ stepping on Never Cracker's lawn, saying, Alright, I'll do it. Chowder then pushes DJ further. I'll never forget this. Hurry up. DJ then ran towards Chowder's basketball, but as once he got close enough to it, Never Cracker opened his door and spots DJ. Eww. Never Cracker shouted, but in a deep voice. DJ was shocked that he was caught. Never Cracker ran towards DJ, letting out a growled roar, but he quickly evaded him and accidentally grinded his foot into a clod of dirt. What? Never Cracker said, talking normally.  DJ gasped in horror. He thought the old man he spied on was possessed.  Never Cracker then said, with his voice now sounding demonic. You. Are. Dead. DJ screamed and ran for his life. However, Never Cracker then grabbed DJ by the herb, pulling him away from Chowder. Never Cracker looked more messed up, his skin was red and he was now sporting black, sharp horns. Never Cracker yelled, his voice still sounding distorted. DJ cried in fear. Never Cracker asked and really. No.  DJ answered in fear. My love is not a playground or a park. It is my property. Never Cracker said, still yelling in his face. I got it. I hear you. DJ replied. Never Cracker continued screaming. This is my house. Why can't you respect that?  As he was about to finish his sentence, Never Cracker started to suffer cardiac arrest like in the final movie. It showed an uncomfortably close up of Never Cracker's face from DJ's point of view. It was much worse with the red skin and black horns. He was even coughing up small patches of blood on DJ's face. As soon as Never Cracker died, he then returned to his normal state, collapsing onto DJ. DJ then began to shed a tear as Never Cracker's lifeless eyes stared into him. He was even sobbing quietly for a bit and there was a faint drop of blood near the corner of his nose. Then the deleted scene ended.  I asked myself. I never expected to see something dark like this. Just then, the second deleted scene started. It started with a scene from the film's completed production, with DJ walking into his room after being sent there by his babysitter Z. He put his telescope away, closed his blinds and went to sleep. His room started to glow red. Just then, a voice whispered. Hey, come to Never Cracker's lawn. DJ woke up, hearing the mysterious voice. He got out of bed and quietly snuck out of his house. The whisper was coming from, no other than, his best friend Chowder. Chowder, what are you doing here? DJ asked. I'm just looking after Never Cracker's house since he is dead. Chowder replied. Chowder, this is a very bad idea. You mustn't look after somebody else's house, even if they have died. Chowder rolled his eyes and said.  I'll dim down ditch the house and you'll see if we get caught. Chowder, no. DJ replied. Chowder then walked up towards the door and rang the doorbell. As seen in the final film, the house started coming to life, scaring Chowder. Just then, the house's carpet tongue snatched Chowder by the waist quickly. Chowder screamed as he was pulled in. No, Chowder. DJ shouted. The house then roared at DJ, preparing to eat him too. DJ had no other chance but to make a run for it. As he ran towards his house, the house then lashed its tongue onto DJ's ankle and pulled him in. DJ screamed the same way he did when the tongue yanked him in the air when he and his friends tried to escape. Then, it showed a shot of DJ and Chowder falling into a space of magma. As they were about to fall into the lava, it showed a final scene from the movie with DJ waking up in his room. This deleted scene soon ended. It wasn't too scary, but the fact of an unused scene of two miners falling into a sea of magma was just messed up. Just then, the third deleted scene started. The start was similar to the part where the trio found themselves in Nebber Cracker's basement. But this time, Chowder regained balance and accidentally sprayed DJ with his water gun. Chowder, it's me, DJ. DJ said irritated. Oh, sorry. Chowder apologized. Where's Jenny? DJ asked. I don't know. Jenny, where are you? Said Chowder. Jenny, are you in here? At that moment, the boys heard somebody crying quietly. They shone their torches everywhere, following the subs. Just then, the boys found Jenny, sitting and huddling, facing away. She was the one who was crying. Jenny cried realistically. DJ and Chowder exchanged glances, worrying for her. DJ asked. Jenny, what's wrong? Jenny spoke between her subs, not bothering to face them. She, she took control of me. And her subs started getting louder. Who? Who took control of you? Chowder asked. Still sobbing, pointed to a sign on a cage which read, Constance, the giantess. Chowder then stated. This woman must possess you. DJ approached Jenny to comfort her, reaching his hand out. Jenny, are... Are you? As soon as DJ put his hand on Jenny's shoulder, Jenny suddenly turned around and shouted in an adult woman's voice, similar to that of Constance's. Get out of my house. DJ and Chowder screamed. Jenny was possessed by Nebber Cracker's late wife. Jenny then talked normally, while under the control of Constance's spirit. Please. Jenny said, still crying, with realistic tears in her eyes. Spirit, yeah. Chowder shouted. He squirted his water gun at Jenny to try and save her from Constance. Jenny, under the control of Constance, then slowly approached towards the boys. DJ worried for Jenny, while Chowder continued squirting his water gun at Jenny until he shot it in her mouth. Just then, Constance's spirit then came out of Jenny's mouth.  Constance and really shouted. She then flew off into the shadows. Jenny fell to her knees and sobbed. DJ then embraced her to reassure her. Jenny, it's okay. She's gone now. We knew you didn't want to hurt us, you were under her control. DJ said, trying to give her comfort. Jenny was still crying, with more tears running down her face, as her face turned up in red, and her eyes became bloodshot. She choked between her sobs as she spoke again. I can't believe that that happened to me.  She then finally stopped crying and wiped her tears away. The three kids then examined a cage they hadn't investigated yet. Just then, the deleted scene ended. Why? Why would that happen to a minor? I asked myself again. I carried on with the last deleted scene, which is Never Cracker's spirit. It started with a shot from the final film, where the kids had found Constance's body covered in cement. Just then, DJ then lost balance and accidentally cracked the nose with his nose, causing the entire body to desecrate. The house woke up, but something was different. A spirit then emerged out of the skeleton, and it was Never Cracker. Chowder screamed. I'm gonna stick you free. Get out of my house. Never Cracker shouted in rage. DJ, Jenny and Chowder then ran out of the cage and made a run for the stairs that lead to the main corridor. As they were about to reach the door, Never Cracker's spirit grabbed DJ's arm, in a similar manner earlier in the film. No. Jenny cried. Chowder! Jenny! DJ screamed, as Never Cracker continued pulling him towards him. DJ! Chowder and Jenny calmed out. The two then ran towards DJ to save him, but then, they bumped into live inanimate objects each. Chowder was pulled into the air by coils. You're slinky! Chowder screamed, and Jenny was attacked by pipes and was sucked into a larger one. DJ, help! Jenny yelled. DJ worried for his friends. He then reached for his water gun and squirted it on Never Cracker's spirit. Never Cracker groaned in despair. I'll get your kids out of my house next time. You'll see. Never Cracker and really ranted. He then flew off into the shadows. DJ then ran to the stairs, whispering. Oh no. Just then, the deleted scene ended, and those were all the deleted scenes I watched. I was appalled by those deleted scenes, they were a lot worse than the first deleted scenes I saw.  And who made those deleted scenes in the first place? And I thought the concept art for Monster House had a darker tone. But now I see the true definition of scary.  Be careful what you find and make sure to think before either you bring it home or watch a lost DVD you discover.


I'll tell you a fiery horse with a speed of light a cloud of dust and a hearty high old silver the lone ranger. I'm going to tell you a fiery horse with a speed of light a cloud of dust and a hearty high old with his faithful Indian companion Tuttle the daring and resourceful masked writer of the plains led the fight for law and order in the early western United States nowhere in the pages of history can one find a greater champion of justice return with us now to those thrilling days of yesteryear out of the past on the fun ring who beats of a great horse silver the lone ranger rides again Dan Reed young nephew of the lone ranger was riding the overland trail stagecoach from the small town of Woodstock into frontier town the only other passenger was a stout pleasant-faced man who watched the passing scenery with great interest I noticed you got on at Woodstock you're going very far son I'm going to frontier town sir that show I am to him all the way from Dallas on the stage I'm enjoying every mile of it oh what's your name sir Dan Reed sir the mines melt Jim out the Dallas I'm going to frontier town to get to Union Pacific to California oh you're going to California I sure am Danny lots of people are going out of search for gold yep I know my daughter Millie went out there with a husband a year ago I got word they found gold they invited me to visit him let me open the suitcase a minute I got some to show you here they are look at these Danny silver spurs for my daughter had a maid in Dallas special family she loves to ride see all that fancy work on them you don't see spurs like that every day I can tell you that's right Mr. Melton I guess it be hard to ever find another pair like that Millie will be proud to have mine oh I think so sir I bet when she guns must be outlawed yes it is they all have their faces coming oh that's poor get out of that coach hey come on son go around that lockbox and be quick about it all right Mr. here he comes keep your hands up while I search your booty I haven't anything of value I'll find out for myself yeah pocket knife and a compass junk forget the unwoned sushi that they don't we got a nice fat wallet shining on the seat inside the coach jet even covered Anita do not worry about that I'm taking those as a gift to my daughter please don't take them you've got my money first to fit a woman's boot no bring him here just no they are here they're one you may present them to me in your instead of to your daughter and because of such a gift I will tell my men not to kill you cut kill me did you say well of course take this first give them to you oh that's a good one he gives them to you Anita and you the leader of the toughest outlaw gang in the area woman outlaw so now you have learned something new perhaps little boy get back in the coach now and tell them in frontier town that Anita Gomez laughs at the sheriff who cannot find her in her outlaw gang but Sheriff Taylor finds if you take that hat and neck at your bar so your hair and face when he finds out what you look like the tongue impudent one and get into the stage coach before I decide to change my mind come on son we better get in the I'm going to get out of there come on hey Mr. Melton you can't go on to see your daughter it took all your money nope not all Danny I got some more money hidden my trunk on top of the stage it didn't take time to go through that see I'm glad I'm sorry though about the silver spurs yep sure my Danny after all the trouble of having to meet special to oh well I guess we're lucky at that to come out of this line after the stage arrived in frontier town and the hold up was reported to Sheriff Taylor Dan bad goodbye to Mr. Melton and getting his horse Victor from the livery stable he rode to the Lone Ranger's camp in the Enchanted Hills Dan told the Lone Ranger in Toronto what had happened Gomez gang are ruthless outlaws Dan you and the other passenger were fortunate you weren't harmed that right them say woman who lead gang plenty mean did you get a good look at it then no sir she wore clothes like the men who were with her she had her hair and face covered she spoke with an accent yes I know they say she's from Mexico I'm surprised it didn't search the luggage well she seems so pleased to get the silver spurs that she decided to let us go on I guess they thought Mr. Melton had all his money in his wallet then get money from strong box maybe yes they did the express office Joe Mitchell said there was five thousand dollars in the strong box the outlaws took I see Sheriff Taylor was getting a posse together to go after the gang when I left frontier town hold up took place just beyond Rimrock Bridge right out that way and see if we can help track them down your silver comes out we'll be back by sundown Dan you wait for us here yes very big the search for the outlaws was unsuccessful it was three days later when Dan went into frontier town the outpost general store for supplies old Laramie Bates was talking to Dan as he fixed up the order there guess that's got everything down yes sir you sure had an experience of the day didn't just sound oh you must mean being in the stage hold up yeah tell me Daniel did you get any idea to all what that Gomez woman looks like no sir I didn't Mr. Bates I hear tell she's the sister of a famous Mexican outlaw who got killed by a posse during robbery she swore to take his place with the gang and get even colleague I could tell she's Mexican by the way she taught is she sure got sheriff to come Taylor in the lather he's fit to be tied because a woman is able to outsmart him now years ago when I was a sheriff down and oh look out front panel what is it I don't see you're too young to let the sight of a pretty girl bother your son see that golden-haired lady at the heat track out there she she is pretty who is she mr. Bates miss winners and her brothers got a place up on bloodstone quick beyond the lazy wife spread she's as nice as she is pretty too but even a riding clothes are pretty that fringe leather riding skirt and here she comes in good morning Mr. Bates howdy miss winners howdy ma'am well who is this night young boy my name is Dan Reed ma'am that's a nice name haven't we met before Dan your face seems familiar oh no miss winners I'd remember if we had my what a beautiful car dog gone Dan I wish I could think I'm up quick as you do what do you have miss whether we want bacon sugar and corn the usual amount of each mr.  Bates right now I have something I want to do goodbye sir Dan left the store and waited until the girl rode away and going to the hitch rack where Victor was waiting he mounted hurrying easy pick to steady boy I'm gonna follow miss winners and see just where she lives come on big time it was almost dusk when the lone ranger becoming worried about Dan spoke to hello down into frontier town earlier this morning should have come back long ago with the supplies map right I can't understand what's keeping him maybe him go see mother Willard at Roman house he intended to stop in town and would have told us isn't like him to stay so long without letting us know ahead of time map right I think we better ride the red skin trail into town maybe we'll meet him on the way let's get the horses hope nothing's happened to him on the trail Victor might have fallen we're not worried too much yet him let's go easy big club meantime Dan had followed the girl along the trail which led across the Powderhorn River and up Bloodstone Creek it was afternoon when he saw it turn in at the entrance to a small ranch Dan rode further along the trail and circled around until he was behind the ranch house he left Victor in a clump of trees then moved cautiously toward the house no one seemed to be around as he approached the window and looked in suddenly a boy startled him and he swung around quickly hello dad won't you come inside Collier I was quite flattered when I noticed you following me I didn't know I impressed you so much all right sit down Dan thank you ma'am now tell me why have you followed me out here well I noticed those spurs you're where oh my nice over spurs my brother brought them to me as a gift from St. Louis when a couple of weeks ago why Mr. Melton said there weren't any other spurs like them he had them specially made Mr. Melton I never heard of him he was a man on the stage who was robbed a few days ago the outlaws took the spurs too and this is all very interesting surely you don't think I have an outlaw or brother well I said gentlemen you spoke of could be mistaken in fact he is that these spurs are like the ones he lost or perhaps your mistake and Dan he might seem to look like the ones you saw I'm sure they're just the same as the ones I saw I look close at the fancy work on well it's quite a coincidence then that they should be the same I'll get you some time Melton you better start back or your folks will be worried golly I don't know what to say miss what is that wait just there's one of the outlaws I recognize his voice smoke button who was on the stage just you go to Anita the woman outlaw leader was named Anita to look this Maverick's too smart how to be spurs they're the ones you took from the man on the stage so he recognized the spurs I need a why did you hadn't thought it in here I could have handled this kid can't believe that that you are now perhaps you recognize my voice no the woman outlaw yes and it's just too bad for you that you found it out kid it'll be a long long time before your folks ever see you again the curtain falls on the first act of our lone ranger story before the next exciting scenes please permit us to pause for just a few moments and during tanto rode all the way to the edge of frontier town in search for Dan while alone Ranger waited tanto went on into town and stopped at the general store was gonna help that he never did come back for him why damn leave supplies here in store it's funny thing about that girl from out Budstone Creek way come in while the boy was here mighty pretty girl she is too me not savvy well Daniel dropped the flower spilling some of it on her boots yes he he knelt down and cleaned them off with his neck a chair funny thing though while he was cleaning him he kind of stopped just knelt there staring at them boots and spurs like you'll see in a rattlesnake or something Dan stared spurs girl when yeah then soon as she left tells me I'll be back later howdy goes I watched him mount up and go right in after Ms. Winters where winter's girl live well it's a Budstone Creek beyond yank Tarbury's place yep she sure is a mighty go now how do you hey wait earnation take it now he's gone left them supplies and folks around here is getting to act more peculiar every day seems like to me returning to the edge of frontier town Tonto told the Lone Ranger what he had learned from old Laramie Bates well what do you think of it Tonto or me think damn recognize silver spurs outlaws take them stage yes that's the way it seems to me I can't figure where that Miss Winters fits into the picture we soon find out I'll give you a note to Sheriff Taylor then I'll start on toward the winners place you and the sheriff follow you right now let me go to share meantime at the ranch Anita the outlaw woman who was posing as a Miss Winters was giving orders to her brother Jess now Jess someone may trail that boy out here especially if they should question the storekeeper better clear out then no at least I'm going to stay here as Miss Winters take the boy with you to the cave hideout in the sawtooth mountains tied up in the next room you'd better start right now what about you suppose someone does come out here I miss Winters remember the pretty girl with the golden hair and they think Anita the outlaw is Mexican because I've always used an accent when we did a job they'll be looking for a dark haired woman yeah but suppose that they can fool them don't worry now get going all right even come on out tomorrow you sure this is the winners place yep this is the winners place all right you see light and ranch house yes one home for the big full of funner come on sure wait here soon find out something better be ready with your guns yep I'm ready good evening won't you come ask me why it's all right Miss Winters I'm Sheriff Taylor from Frontier town this man's a friend of mine oh Sheriff Taylor I've heard a great deal about you won't you come in thanks you need you have those guns in your hands like that I don't understand why this is all kind of puzzling Miss Winters but we come here looking for a young boy who followed you out of town this morning followed me out of town yes the storekeeper so I'm leaving oh could it have been that nice boy Dan yes that's the boy did follow me he didn't come here I do hope nothing has happened to him so do I miss winners it would go very hard with anyone who might harm that boy I can vouch for that man I'm sure it would dear I do hope you find him soon we will don't worry I can't imagine why should have followed me perhaps miss winners it could have been because of the spurs you were wearing today I'm not wearing spurs no did I wear any today well I I guess we've bothered you enough ma'am we must have made a mistake coming here to find him yes yes perhaps we did sure pardon the intrusion miss winners we're leaving huh I do hope you find the boy I'm really worried about you thanks so am I adios sure as a nice girl pretty too sure if did you notice her boots her boots what do you mean the storekeeper told tanto about her spurs now her boots were well shined I noticed a slight ridge across the insteps there that girl lied she did wear spurs today must remove them shortly before we arrived well I'll be doggone I wonder how she'd get a hold of them spurs anyway maybe the Mexican outlaw woman I need I have my ideas about that sheriff you're not fine Dan no tanto but I have an idea he's a big fellow easy we're right away but we'll come back shortly not a sure of steady what are you planning to do I'll tell you when we get a good distance away from the house short time later I need a answer to knock on the door of the ranch house oh an Indian man on trail say me bring note give it to miss winter I miss me oh well here you know thank you wonder who sent this boy got away you'd better come to talk it over printed note that fool Jess must have let the kid get away I'll have to go to the cave right now well hidden in one of the many small passes up in the sawtooth mountains northwest of frontier town there was a natural cave the trail to the cave was almost indiscernible and the entrance to the cave itself was hidden by large boulders that made a natural screen this cave had been for some time the hideout of the notorious Gomez gang and because of its occlusion it escaped the notice of all who had tried to hunt down the game it was to this cave that just the outlaw had taken Dan Reed about an hour after tanto had delivered the note to Anita Jess who was resting on one of the makeshift beds in the cave looked up as one of the men entered hey Jess somebody's riding this way let's get to the entrance and be ready with guns in case they turn in toward the cave hey that's Anita moonlight bright enough for me to see her yeah it is Anita wonder why she's coming here tonight oh no no hey Anita no you fool why did you hang out to that kid the kids back in the cave right now tied up and wait a minute what no do you talking about this one didn't you give it to an Indian to bring to me no I didn't say there's something funny about that yes there is if you didn't send it then who did I said I miss what I call you Anita Gomez look a mess come break got us covered with them big guns it was a trick so he could follow me here came to the ranch to ask about the boy guess right Anita he's only one against all the way to anything hasty mister I'm standing right here watching for sure he and his men have the entrance covered that's right the notorious Gomez gang is about finished Anita but first I want to see the boy Dan of course Jess where is the boy right back there in the dark at the end of the cave he's bound and gagged horses are there too why did you gag him he's too young to be treated like that yes he is I told him to treat the boy gently I'll loosen his cords and gag hold on I'm coming along with you here he is here boy take away that gag thanks they've come for you then but you'll leave right now without him I have this gun at the boy's head and I'll shoot unless you and the others leave so you had a gun hidden in your shirt waist you tricked me into thinking you had a streak of kindness get out and take the sheriff and the others with you I give you one minute my gun is pointed at you Anita yeah so I see but if I get a bullet so will the boy think fast mister as Anita stood tensely holding a gun at Dan's head he didn't notice in the dim light of the cave that Dan's horse Victor was watching Victor knew the meaning of a pointed gun from long experience as he saw the girl point a gun at his young master his nostrils quivered in his eyes widened he threw his head up with a sudden snort of anger that startled Anita oh that horse feet doing before he don't need for that I'll take that gun if that horse hadn't attracted my attention you wouldn't have been able to do that fight shooting Victor didn't charge you it had been knocked down and trampled your off-law days are over Anita Sheriff round up the Gomez gang cut your cords Dan golly I'm sure glad to see you now your feet there you're in dangerous company Dan but thanks to you we've found out about Anita I'll take over here good hold on Dan I'll leave Victor out of the cave go along fella that mask man thinks he's smart if it hadn't been for that horse spoiling things by acting up now look miss don't you go belittling that mask man he's the one who taught that boy to be smart their horses to be smart too the boy found out the mask man tricked you into bringing us to the boy and the horse spoiled your little trick to get us out of here you can't beat that for teamwork who is that mask Andre anyway I guess it's about time you know he's the lone ranger bird is a copyrighted feature of the lone ranger incorporated