Thank you, mistress. So, yeah, that all just happened. Where do we even go from here, really? All right. Let's get started with the talk. Let's talk about some computer security and not wooden pedals. All right. What's that? Who asked that? I can't even see who's that? I'm in pain, but thank you. Oh, it's the girl that spanked me. Yeah, okay. Cool. Oh, no, I think you got me good. Thank you, though. Yeah. No, I'm good. Yeah. Thanks. Appreciate it. That was great. So, that's like a little hidden perk that they don't tell you about for the speakers package. You get a nice cool badge. You get access to the speakers room and a little bit of ass-touching. Anyway, let's go ahead and get started. So, welcome everyone. Thanks a lot for coming to my talk. I hope everyone's enjoyed the conference so far. This talks on massive attacks with open source distributed computing.  So, I hope you guys enjoy it. So, who am I? So, just so you guys know who's up here talking at you. I'm Alejandro Caceras. You can call me Alex. I'm the owner, founder, pretty much everything of Hyperion Gray. Hyperion Gray is just a small R&D and open source startup. We're completely focused on the nexus between distributed computing and offensive security. So, I think there's huge potential in the field. And, hopefully, after this talk, you guys agree with me. So, I studied physics back in college and most of my research was focused on kind of distributed computing with scientific experiments.  So, that's where I'm at. I'm also the founder of the punk spider project. Has anybody here heard of the punk spider project? Oh, sweet. More than like five people. It's more than I expected. Awesome. So, I won't say too much about it because we are going to get into it here in just a couple slides. So, don't worry about it. So, this little background came up with this talk after I presented punk spider at Shmucon. Word got back to the CEO of my company at the time that I was building a cyber weapon, which punk spider is like a community-focused web application security project.  So, after laughing about that for a minute, I kind of got to thinking, you know, what would it take to actually build a distributed attack platform, right? So, different examples that I'm going to show you here today are just kind of what came out with tinkering with that idea. So, there's also three demos in this talk. It's really highly demo focused, so definitely stick around. It's going to be a lot of fun.  Anyway. So, let's get into it. To start off, distributed computing is really big right now, right? You've heard a lot about it. There's all kinds of IBM commercials and stuff like that. You hear big data a lot.  So, big reason for that is that we've seen some really cool stuff come out that makes distributed processing of things really, really easy. The short of it is that pretty much all folks are doing with this is lots of powerful analytics. So, kind of cool, right? Analytics are cool. We all like that. But I'm not really into that kind of thing. It bores me a little bit. So, I've been kind of looking for more interesting use cases for distributed computing. A couple of technologies that have come out are Apache Hadoop, which is an implementation of the MapReduce parallel programming concept. We're going to get all up in MapReduce here in just a few minutes. I won't go too far into that right now. So, you might ask, you know, if analytics bores you what exactly is some fun stuff that we can do with distributed computing? The answer, of course, there is massive attacks with open source distributed computing, which you might notice is the title of my talk. So, what's the high-level idea behind distributed attacks? What exactly do I mean when I say something like massive attacks, right? So, what I'm talking about here is conducting really well-known, often effective attacks, stuff that has a relatively high rate of success and then doing that hundreds or, I'm sorry, hundreds of thousands or even millions of times even in a really coordinated and effective manner. So, what I found in my research into this so far is that, and hopefully this isn't too much of a spoiler, is that you're going to break into so many things that part of the problem is going to be dealing with, like, what do I do with all this broken shit? What do I do with all this information from the stuff that I've broken? So, we're actually not going to get too far into, you know, what we do with that information afterwards. We're going to be more interested in the breaking of things, if you will. So, everybody with me so far? Cool. Some head nods? That guy's nodding. Cool. All right. So, let's define what we mean by a distributed attack. By this, I mean an attack that uses various computing resources in an effective and coordinated manner. So, why do we want to do this really? Why is this going to be to our advantage? Once the time required to attack a massive amount of things, and again, remember I'm talking about hundreds of thousands or millions of things all at once, is that it could take a really long time to do this. So, you don't want to be waiting months, even potentially a year or years for an attack to finish. It's not just annoying and just impractical, but it also allows for response teams to the particular targets that you're talking about to respond in lots of different and complex ways.  So, just to give you an example, picture a target of, like, 250,000 web applications, for example, associated with a particular target, right? So, this could be, you know, every web application associated with a country, for example, which is... So, let's say you try to run just basic web app fuzzing followed by, like, an automated SQL injection kind of thing. So, with a really optimistic estimate doing this in a non-parallel way, it might take something like a minute per target, and again, that's pretty optimistic. That means you end up with something like 173 days, 174 days to actually finish that attack. We definitely don't want to wait that long for obvious reasons. So, if you think that target number is unrealistic, you've heard me mention punk spatter a couple of times already. We've done checks on about 1.3, 1.4 million sites so far, and our target is 250 million sites. So, it's a completely realistic target when you're talking about really, really large attacks. So, why else? Yeah, that's right. So, why else? So, sometimes you need a little bit of coordination between your computing resources. To illustrate this, again, picture a large-scale attack on a massive network, maybe like a fairly significant portion of the Internet, for example. And let's say that you realize that in order to conduct that attack on a large scale, you're going to need more computing power, right? So, like I said, we don't want this attack to take too long.  Maybe you have a little script that runs and executes a few shell commands on each machine, for example. So, you start running into a whole bunch of problems with that, right? If anybody's ever tried an attack like that, you know this. So, you might want to know, like, when an attack has actually finished on one of those nodes, right? So, once a node has finished its part in the attack, you've just freed up some computing resources. And in order to make your attack as efficient as possible, you're going to want to be able to run more stuff on that node. That's not really going to be possible in this way unless, you know, you could hack something out, but it's not going to be ideal. So, another issue that you run into is how do you actually make sure that your computing resources are kind of pushed to the limit? You might have lots of different types of servers. Maybe you're running this out of your basement somewhere on commodity hardware. So, how do you actually know that all of these resources are being pushed to the limit and that you're using everything that's available to you? You can hack out some kind of threading codes, something that monitors the resources on a particular machine and ensures that it's using all of them at once. But again, that's not going to be ideal or you're going to spend a significant amount of time on that. And we want to be able to do this relatively easily. So, if all of this just sounds kind of hard to you, there's been some really great advances in the field that make this actually not that hard to do, to basically solve every single problem associated with using large numbers of nodes to conduct a coordinated attack. I'm going to get into talking about some of these and then move right into the three examples and three demos that I talked about. So, for the most part, we're going to be talking about one of the best and most popular tools out there for distributed computing, which is Apache Hadoop. How many of you guys are familiar with Hadoop and know everything around it already? That's way more than I expected. All right. Cool. So, we do need to go over some background on what Hadoop is. So, just bear with me if you already know all of this. Coming from a scientific background myself, I've used a couple of different protocols for message passing, for distributed computing, like MPI, which mainly has support for Fortran and C.  It's even like Fortran 77, which is just ancient stuff. But if we get into how Hadoop works, which is through MapReduce, from what I'll show you if it's implemented right, which it is in Apache Hadoop, you get really, really easy to write code that can parallelize your tasks really quickly and you don't have to do that much work. So, I'm going to show you all about how you would do that. So, I've mentioned MapReduce a couple of times already, but what exactly is it, right? How many of you guys are familiar with MapReduce parallel programming concept? Cool. Awesome. Pretty good amount of people. Awesome. So, let's say you have a problem that you'd like to distribute across the node. This is how MapReduce works. What you would start out with is called a map function. So, I'm actually going to go very in-depth into what MapReduce is. It might appear a little bit confusing at first as to why we're doing things the way we are, but don't worry. There's a couple more slides on this that will illustrate all of that for you guys. And also a couple really good examples that make it simple. So, just bear with me if you don't get all of this all at once. So, first thing you do is you write a map function. Map function is really simple. It just takes in data as key value pairs and outputs a set of key value pairs as its result. So, map function is written in such that it's a single operation on a single key value pair for you. So, as the person writing it, you're just writing this for one input at a time. You don't have to worry about all that massive amount of data. You're writing it for one input record at a time only. This is automatically distributed across the cluster in Hadoop. This operation for each of your key value pairs. Each machine in the cluster has the map function and it has a set of key value pairs that it's responsible for, doing whatever operation it is that you'd like your map function to do. So, I like to think of the map step as a part that generates somewhat processed big data, if you will, in a distributed manner. It's usually not the solution to your problem, although sometimes it can be. So, it's pretty simple. All it is is input key value pairs, run a map function leveraging all the machines in the cluster, and then outputting key value pairs after that. So, pretty simple. After the map step is done, you move on to the reduced step. There can be some intermediate steps for some additional processing, but generally you would move to the reduced step. The input of the reduced step is really simply just the output of the previous map step. So, a partitioner is going to take the values from the map step with common keys and distribute them such that one node in the cluster is responsible for running the reducer function on all of the values with common keys. So, this is again distributed across the entire cluster. So, the reducer is usually the part that gives you the solution to the problem. And I know that was, like, a lot of words that I just said at you, and it might be a little bit confusing. There's a couple slides that might clarify this, if it's not completely clear to you yet.  I'm going to get a little water, and then I'm going to read through it myself. And hopefully this will make things a little bit clearer along with the example after it. All right, so hopefully that was long enough, maybe not. But here's all that's happening just in summary of what map reduce is. You have key sub one, value sub one, inputs to a map or function, right? The map function is distributed across the cluster, yields a list of results as a key. So that can be, you know, something like key sub two, value sub two, key sub two, value sub three, key sub two, value sub four, and so on and so forth for each key value pair. All the values with the same key, key sub two are logically grouped together, and a reducer function would then be applied to this group in parallel so that for each group and then yield something in return. So these would usually be what we would call our results. So a common question when you're kind of first dealing with map reduce is, well, why do we do it that way? What's the use of having the values with the same key grouped together? And I'm going to show you exactly why we do that here in just a minute, just in the next slide. So a few things to keep in mind. Once you write a map or in a reducer, how do it's going to distribute it to the remote nodes and slaves automatically? So you don't actually have to deal with anything that's actually distributing things and dealing with when things happen or where things happen or why things happen in those places that they do happen. So Hadoop takes care of a lot of really important parts of distributed computing. Things like, like I mentioned, automated partitioning to remote nodes, automated assurance that the job's going to get done. So if for example, you have a node that goes down, Hadoop just very seamlessly sends it to another node and it's able to detect that. It actually takes it a step further from dealing with nodes that go down to actually expecting that nodes will go down.  I do all the time and get really solid results from it. So what else? There's also a few configurations items that you can set in Hadoop that are really useful. So I mentioned before that you want to be able to push your resources to their absolute limit, right? You can do that very easily with Hadoop and just a couple of lines of configuration. You don't have to deal with going to each of your nodes and figuring out some kind of code to make sure your resources are all being pushed to their limit. Hadoop will actually do pretty much all of that for you with just a couple of computerization items. Really cool. All right, so let's get into a specific example. So first off, I have very few complaints about the distributed computing community in Apache Hadoop and all the really nice, useful community behind it. The one thing I could complain about is that if you look up MapReduce and just Google it, try to find some really simple examples of it, the only freaking thing you're ever going to find is a word count example. So that's really annoying because once you just start seeing the same example again, if you don't quite get it at first, you want to see another simple example that will kind of help you out with that. So it always seems to me like with Hadoop you're either reading a word count example or you have to pour through hundreds of lines of Java code to just figure out something really, really simple. Also, word counts are really, really boring. All it is is essentially it counts the instances of a word in a particular piece of text, so that's kind of lame. But I decided on a better example to give to you all. So this example is a tool called PunkScan. So PunkScan is a free open-source tool that HyperionGray released to distribute a web application fuzzer and it's what powers the PunkSpider project that I know I've mentioned a couple times and haven't said that much more about, but we'll get into it. So picture the situation where you have a list of URLs, you have a ton of URLs, potentially something like a few hundred thousand or even a million. So we want to be able to perform a MapReduce job in Hadoop to fuzz these URLs quickly and search for vulnerabilities on the pages. Another constraint that we're going to place on the job is that we want all the vulnerabilities associated with a particular domain to finish at the same time. So this is going to help you out with you don't want a bunch of disparate URLs being returned as your results, not really without any care to who they actually belong to. And this is where you're going to see that the way that MapReduce works by grouping the specific keys together during the Reduce step is going to help you a lot. So are we still good? Everybody's still good?  Cool. What's the job flow look like within something like PunkScan? So as I mentioned before, we start with the MapR step, inputting key value pairs. All we're doing here is we just care about a list of URLs in this case. So our input key is going to be none. So we don't really care about a key in this case. Our URL is going to be the value. So essentially what this does is it makes it just a dumb list, right? We're not associating any keys with the specific URLs that come in, not yet at least. So we're at a MapR which is going to be applied to each URL in parallel. Again, the MapR just essentially just fuzzes the URLs using a really simple fuzzing library that I wrote and then determines the domain of the URL. And that's it. That's all the MapR is going to do. So after that, it yields its output in which it's output which is going to be the domain of the URL fuzzed as the key and the list of vulnerabilities for that URL as the MapR, or I'm sorry, as the value. So any vulnerabilities that come out, add it to a list, you get the key being the domain, value being the list of vulnerabilities. So keep in mind that all of this is going to get distributed across the cluster for you. So the URLs that are going to be fuzzed in parallel, I'm sorry, the URLs are going to be fuzzed in parallel as much as possible. And all of that's handled completely in an automated way using Hadoop, so we don't really have to write any of that logic ourselves which is really, really useful. So now because the domain of the URLs fuzzed was the key of the MapR as well as the input of the reducer, right? So keep that in mind. Though the reducer function for each URL with a common domain is going to get sent to a single node for processing. So the reducer is going to run in parallel for each group of URLs with a common domain. And all of that, of course, is going to get distributed across the cluster as well. But what you're seeing already is that each domain is going to get handled by a particular node at a time in a specific reduced step. Now, why is that actually useful? The reducer function is just to combine, it just outputs a, so it does, sorry, all the reducer function does is combine the lists, I think that vodka is hitting me like right about now by the way.  All right. Anyway. So all the reducer function does is combine the list of vulnerable pages in the one big list for a specific domain. Then it's going to index them to a back-end search engine. In PunkSpider we're using Apache Solar as our back-end, which wasn't that tough a choice because we were writing a search engine, Apache Solar is a search engine back-end. Overall, that's pretty simple, right? But how easy is it to code, really? I keep mentioning coding up a mapper and a reducer, but it's still kind of abstract to you guys. Like, what does that look like? I keep mentioning it's easy, too, right? But what do I mean by easy? Do I mean like a hundred lines of code, 200 lines of code? What is it? I wanted to show you this. Don't worry about actually reading all of it and, you know, doing a thorough code review or anything like that. But just take a look at it. If you notice it's about 12 lines of actual code and it's written in Python. This one, this is our mapper right here, and up next is going to be our reducer, which our reducer is just like ridiculously simple. It's like six lines of code. You might have noticed a couple of things in the mapper and the reducer. First off, as I mentioned, they are written in Python. What we've done is use a function on Hadoop called Hadoop streaming that reads from standard in to standard out to partition and set up the job properly. I don't want to get too far into how exactly you would use that, but suffice to say it's just a bash one-liner to actually run a job in MapReduce after you've written your mapper and your reducer. So if you're the kind of person that really wants integrated details on how to run all this stuff, how to write mappers, reducers properly, specific to offensive security, follow me on Twitter.  So if you want all that, definitely keep in touch. Another thing I wanted to point out is that the mapper and the reducers that I showed you are really the only part of punk scan that's distributed computing focused, right? So in other words, if you were to actually download punk scan which you can off a bit bucket, you noticed that most of it is actually pretty standard stuff, right? We're not doing anything too crazy to distribute this code. Essentially it's a standard fuzzing library that I've written, some solar indexing stuff, some other fairly simple things, but then you see also a mapper and reducer, which again is the only part of it that's really distributed code. What I'm really trying to get at here is that there's nothing really too mysterious about writing your own distributed computing focused code. It's all, if you understand the base concepts, you're really going to be able to write distributed attack code relatively easily. This guy's falling asleep, by the way, and that's killing me. So hopefully that'll prevent that from happening. What's that? Drink me or him? Yeah, drinking will help keep him from falling asleep, right? Great idea. All right, so demo time. I keep mentioning that this talk has a bunch of demos, but all I've been doing is talking at you, so we need to stop that. All right, so first off, first demo I'm going to show you, this is punk spider. Obviously, first thing we want to do here is read the banner. So we're providing a lot of vulnerability information on a bunch of sites that we don't own. So this banner is really important, and I do take it pretty seriously. The goal is to provide free information to website users and owners regarding website security status. So that means if you go on the site and look for vulnerabilities, what I'm really hoping for it to be used with is if you're a site owner or a site user, you want to know the vulnerability state of that site, right? So if you're out there giving your credit card number or any kind of personal information, you want to make sure that that's not being leaked all over the place. So that's really important. So a couple things you can see here. Can everybody see that okay? Does that come out all right over there? Perfect. So a couple things we can do here. We can search by a particular URL or by the title of a site. So we're just going to go ahead and search by a URL. Down here is where you specify the specific vulnerabilities that you'd like the sites to have that you're searching for, right? So we're going to go ahead and do any site with the search term that I type in with any of these types of vulnerabilities. And these are bind SQL, SQL, and cross-site scripting vulnerabilities. Actually, I'm going to do you one better. We're going to search for every single site that has vulnerabilities in it. So you can, it supports wild card characters so you can just go in, type a little star and you get absolutely every site that's in the database and it's going to be pretty long. So if we scroll down, you start seeing sites that are essentially a mess, right? These are vulnerable sites that if you were a user giving your personal information to any of these sites, you'd be pretty pissed off, right? Scroll down to the bottom, we actually see the number of pages of vulnerable sites. It's 6,166. Just to be clear on this, a lot of articles on PunkSpider got this wrong after we presented it at Shmukan. But this is 6,166 pages of vulnerable domains. So within each domain, we can have several vulnerable websites and vulnerable pages. We have 10 domains per page, so that's 61,660 vulnerable domains. And within each domain, if we go ahead and expand it, searching for one with more than one, within each page for each domain, we have several vulnerabilities. Anyway, long story short, what I'm trying to get at is there's a lot more vulnerabilities in here than 6,166. It's right up at about 300,000 or so, so far. And this was all made possible by using PunkScan. So as I mentioned, PunkScan is what powers this on the back end. And making it distributed over actually a relatively small how-to cluster and pushing our resources really, really hard is what allowed us to do. The main issue that we've had with PunkSpider is usually terms of service stuff.  But I guess they have some kind of monitoring outbound a lot of the times.  It's really annoying. Does anybody work for a cloud provider here, by the way? Actually, I won't say too much more because we have cloud providers here, but anyway. One of the get down to actually showing you a specific record, you can actually sort of see, sort of picture the map-produced job running here if you look at one of these specific records, right? We're looking at ajaxa.cn. I have no idea what this idea is or what they do. Something with Ajax, maybe, I don't know. So you can actually see the parameters. You can actually see us attempting to do that. So here you see that this one's looking for, let me zoom in a little bit more, cut ID over here, and then we see it moving to the next parameter page over here, and then we just see it kind of moving down, right? So this is our map-step that I was talking about. We're essentially just taking a URL, iterating through the parameters, attempting a few basic, basic, really safe, by the way, injections, and reading the output. We're not doing anything used for good things and not bad things. Somebody's laughing over there for some reason. Anyway. So that's BunkSpider. And what made all of this possible, what allowed us to basically target the entire internet, is to distribute this job, right? This actually would not have been popular.  So that's BunkSpider. What do you guys think of BunkSpider? Thank you, guys. All right. So I've shown you some stuff, and now I want to get into specific use cases of that. That was just an example to kind of whet your appetite, right? The rest of what you're going to see is me showing you or explaining demos. So we're going to cover three areas and see tools for this really, really quickly. Essentially, you just want to greatly speed up repetitive tasks, right? A lot of network or application reconnaissance on targets is just repetitive tasks when you're dealing with massive targets. So we're not getting into really low-level complex attacks here. We're getting into common stuff that succeeds a lot is our goal. The only thing I really did want to say about distributed recon is to figure your problem, right? Are you in need of CPU, memory, bandwidth? What exactly is it that you're trying to solve? So with punk scan, we had the issue that we just needed faster fuzzing, right? And we had to figure out what will help us fuzz faster? Are we going to need bandwidth? Are we going to need CPU, memory? And we actually had to do a little bit of pre-research in order to figure out the video. It goes into a lot more detail. The short of it is that CPU and memory were far, far more important than any kind of bandwidth. So this actually turned out to be really useful for us because distributing the job we knew was really going to help us. And it turned out it did. It helped us a ton. So just always consider your problem and be really careful before you write these things. All right, the next one is the really fun one. So just don't misuse Punkspider and don't attack the sites on Punkspider. That's really not what it was built for. And I would be kind of pissed if I found out that people were actually using it for that. But now we're going to look at what we could do with that type of information. If we were complete dicks. Well, why do we want to distribute the actual exploitation phase? So mostly because it's fun and that's a fun thing to do and we want to speed up our attack and we want to help us coordinate our resources. So demo an example of what I'm going to show you is a distributed version of SQL map. How many of you are familiar with SQL map? Essentially an automated database takeover and stealing tool kind of thing. Really, really cool tool. It was presented at DefCon I think like four years ago, something like that. That's probably completely all this stuff is the source code is going to be available online immediately after the conference. So definitely take a look at it if you want to know more about it. It's in the proof of concept phase right now. Not what I would call a real tool just yet. But if you're coming to Derbycon, I am going to be presenting on a really refined version of this that you can actually use and has a lot more features than what it has currently. So by example, Mr. Injector. So the reason for this is MR equals MapReduce. So injector because it injects it obviously. So MR Injector in my head turned into Mr. Injector, which I think is kind of funny, literally nobody else has ever thought that that was a funny name for anything, but that's kind of just how I work. Also in my head, I picture it as a cross between things that that's entertaining in any way. So we're just going to move on. So let me set the stage for you here. This is the next demo. The screen you're seeing is divided into two parts. So the left-hand side is SQLMap owning targets in a nondistributed manner. This is written kind of just how you would expect it. You have a simple Python or shell script that runs SQLMap on targets in a row. So you right-hand side uses distributed computing through a cluster to conduct the attack. So this is a real attack running on a testbed of servers. So even though it's a testbed of servers, this is an actual attack that we conducted. And what you're going to see is a series of, you're going to see those shells run, but you don't have to read that too much. Under them, you're going to see little red squares pop up each time a target has been owned. By owned, you can take a look and what I really want you to pay attention to is the rate at which these things attack. It'll actually be pretty obvious what I want you to look for. But again, this is not a simulation. We didn't just, you know, do a bunch of calculations to see if this would work. We actually ran this attack and recorded it to show to you guys. We're also kind of jumping in in the middle of the attack. The whole thing was just this is actually real-time. This is not sped up in any way or anything like that. It's real-time targets being owned, and you see that obviously the right side is much, much, much faster. Even though when I look at the left side, I'm always kind of pulling for it, right? I'm always like, all right, come on, little buddy, let's go. Hey, hey, there's another one. How many mappers? I believe we were running something like 10 mappers per node, 10 nodes. Yeah, so that's what it's running in parallel. So already you see that just with a relatively small cluster with 10 nodes, greatly, greatly speed up the attack, right? So it greatly speeds up the attack. That was 61 targets in 45 seconds. So we have under a second limit. And what makes this really possible, it's not just the fact that you have more computing resources. It's the fact that you're able to push those resources to their absolute limit with really simple code. You don't have to get into really complex stuff in order for that to happen. So my goal with this, what I really wanted to show you is that these techniques actually work.  But next of all, it actually works.  This is an example of the mapper that I wrote. Actually, this is a really, really early version of the mapper that I wrote. It's really simple, right? It's Python code. All we're doing is we're running a simple like sub-process stop you open, which just runs a shell command and replacing the URL with whatever input that we have, right? Really, well, what we've done is we've gone back and refined it a little bit with the help of my friend, Mark, who's right there in the red shirt. We've refined that a good amount, but this code actually works and runs really, really well. So as you can see, this is like ten lines or something like that. Really, really simple. All right, so the output of the tool gets output distributed across all the nodes. It's fully accessible on absolutely any node that you have out there. So you don't have to worry about what nodes you're on in order to retrieve the output. You can actually be on any one of your distributed nodes and just grab it from anywhere and you have that information just right at your disposal for whatever it is that you're into with that information. So it's really, really convenient. So what do we end up with, so we just own a large amount of targets and what was really cool is if only we had a really fast distributed password cracker. So I'm going to tell you about a really fast distributed password cracker that I wrote.  We've exploited a massive number of targets and we've stolen a bunch of password hashes. So these hashes could take a long time to crack. Maybe we're using any kind of specialized hardware, right?  We just want to be able to click a few things and crack some hashes, right? So you might notice in the previous examples I made the assumption that you can build or have access to enough machines to actually run a how-to cluster. That's actually not that hard. For anybody who's running a couple hours. So it's really, really simple. Let's say that you're just really busy, you don't want to deal with all that. And what you want to do is you want to be able to click a few buttons and just have an instant cluster to use. So I'm going to show you how you can do that and then crack a password over the cluster by using HyperionGrey's custom-built tool which is called punk crack. So admittedly this wasn't an trivial. You actually have to worry about how exactly you're going to partition this stuff. To me when we started this it seemed really simple, right? Each operation you're hashing a string and then comparing it to another hash seems simple enough. It's easily parallelizable. I think that's the word. I don't know. And seems really easy to do. But what you run into is that Hadoop is expecting as any usable way, right? If we were to try to just like compute all the hashes and then input a list from a file that she would crash for any reasonable password, right? So it was a little bit complicated. We had to write our own little language that could represent a series of characters in order to distribute this job. I think I'm actually getting close to the end here, but what I'm going to show you is spinning up a powerful cluster over Amazon's Elastic Map cluster to run this job and get me on my way sort of thing. Really cool. Oh, and yeah, last thing. I know there's lots of ways to crack passwords. I'm not claiming this is the best way, the fastest way, the most efficient way, anything like that. Just saying it's an option and something that you can have in your tool belt, if you don't mind spending some money for convenience for a cracker, this is a really good technique. So let me see. It's actually a really long video. What's going on here? Let me go ahead and talk you through this. I start out... Okay. There we go. So I start out by showing a really screwed up screen. There we go. So I go here. I just... Can everybody see that okay by the way? Sort of. I'm going to walk you through it anyway. Don't worry about it. I'll walk you through it. It's okay. Full screen? How do you full screen in Windows Media Player? This little thing? Yeah, that didn't help it all the time. It didn't work for anything. So all I'm doing is I'm specifying a new what's called a job cell. This is essentially just setting your basic job configurations. I copy a few things. All I'm doing is I'm telling it the location of the jar and a few basic arguments on the jar. I wanted to skip forward. This is a really, really freaking cool screen. So what's going on here? I'm specifying my instance types and my instance numbers. So I'm telling it how large do I have a master node which is a pretty big machine on Amazon's EC2. You have for my one slave machine I set a cluster compute 8 extra large which is a 32 processor machine which is pretty big. And then at the bottom over here where you see the 17, I'm setting it to again really large. So I have about 19 nodes here. I really wanted to show you this demo with some extra zeroes. So that would be 170 or even 1700. And you could pretty much have a password like that. But that does get a little bit expensive and you have to be careful on how you use that because you need special permission from Amazon and they already kind of hated me. Is there anybody from Amazon here? No? Okay. Amazon. Yeah. They have some really powerful stuff and some really cool stuff but they hate me. So all we're doing here is we're configuring the node to what? Sorry. Got to skip around a little bit. Anyway, so what we're doing here, if you see down here where it says one bootstrap action created, what I did was specify one minute. Okay. What I did was specify one particular action to do on this across the cluster before your job actually starts. What I did there was I set the number of mapper tasks. So that's the number of parallel tasks that occur on each node and that's what I'm talking about where I say you can push your resources to their absolute limit with integration items. Long story short, because I'm running out of time, in case you can't predict what's going to happen, you crack the hash and it's done. And you did that in a completely distributed manner pretty quickly. And that's punk crack. Okay. All right. Anyway, hope you guys have enjoyed it. No, you can't finish yet. No. No. Give it up. Wait, you need my time as well. Yeah, I need your time as well. Just scan there. Oh, okay. Rebecca, are you a first time speaker at DEF CON? I am. You are? I am, but I presented earlier today. Oh, right. You were the guy with the thing. Right, okay.  However, we learned Rebecca. Rebecca, please come up. Did anybody see Rebecca's talk? Come on. Rebecca did not do a shot. Right. So we're going to fix that right now. Rebecca is going to start a new tradition. She is going to take Tylenol with her shot. That's awesome. I had a shot last night. It didn't go over so well this morning. No. No. Don't touch it. You're not done yet. All right. Thank you. All right. Here's to Rebecca. Thank you. Now you can finish. Thank you. Thank you. Now you can finish. Thank you. All right. Go. Sorry to interrupt. Oh, you're fine. And thanks for coming. It's like the fourth shot I've had to do today because of this whole thing. And we're out of time. God, you missed. I'll give you another minute. Thanks, man. We hazed you enough. Thanks. I appreciate it. Yeah, I was thinking it was worth at least a minute. Anyway, so I definitely enjoyed this whole thing. Short of extremely. God, I'm freaking hammered at this point. When, when, when you need to run massive attacks, one more shot. Can I do another one then take another minute? What do you got to do? Considering I'm not going to have time to go home and shower before I get on an airplane, the person, the people on both sides of me on the Southwest flight are going to love me. We're actually out of liquor. We're out of liquor. More booze. Somebody. No, he's not you again. I'm actually mixing the vodka with the with the rump. It's disgusting. And I'm doing this for you. You're welcome. All right, cheers. Cheers. So distributed computing. So where do you even go from here? I mean, what do I even do? Where am I? So to have to drink, somebody say something. So definitely enjoyed proving the concept to you here, but what exactly does this mean for you?  So really, really cool stuff. Imagine pentesting massive targets with this. We can't do this in country would be awesome. So if anybody wants to tire me to do that, definitely done for it. So I really think that the security implications of this are broad. So if we can feasibly simulate a massive attack scenario, we can better study it and better prepare for it and see what exactly that's going to mean for massive targets like an entire country. So follow me on Twitter, dot slash punk. I'll answer all your questions, anything, anything. And if you want to know more about us and check out some more details on the presentation at www.hyperiengrade.com, check out punk spider, check out our blog. I don't even know what that last one says. And thanks to everybody, Tomas, who's a dude, when I say we write this and we write that, it's usually Tomas. If it's not Tomas, it's Mark, which again is that guy right there. Thanks to Amanda, my girlfriend, thanks a lot.


Hello and welcome to the session. In this session we discuss the following question which says, Ram earns Rs. 15,000 per month. He spends 1 upon 3 of his income on food, 3 upon 10 of the remainder on house rent, and 3 upon 20 of the remainder on the education of the children. How much money is still left with him? Let's move on to the solution. In the question we are given that Ram's income is equal to Rs. 15,000 per month. Next we have that he spends 1 upon 3 of his income on food. So we say, income on food is equal to 1 upon 3 into Rs. 15,000. Now, 3 5,000 times is 15,000. So this would be equal to Rs. 5,000. That is, income spent on food is Rs. 5,000. So now remaining money would be equal to his income that is Rs. 15,000 minus income spent on food which is Rs. 5,000 and this is equal to Rs. 10,000. Then next we have he spends 3 upon 10 of the remainder on house rent. So next we have money spent on house rent is equal to 3 upon 10 into the remaining money that is Rs. 10,000. Now this 0 cancels with this 0 and this would be equal to Rs. 3,000. So he spends Rs. 3,000 on house rent. Now let's again calculate the remaining money with him. So remaining money with Ram would be equal to this money that is Rs. 10,000 minus money spent on house rent that is Rs. 3,000 and this is equal to Rs. 7,000. Now Ram has Rs. 7,000 left with him. Next in the question is given that he spends 3 upon 20 of the remainder on the education of the children. So money spent on education is equal to 3 upon 20 multiplied by the remaining money with Ram that is Rs. 7,000. Now this 0 cancels with this 0 and 352 times is 700. So this is equal to Rs. 3 into 350 which would be equal to 1,050. So money spent on education is Rs. 1,050. Now from the Rs. 7,000 left with him he has spent Rs. 1,050 on education. So next we say that money remaining with Ram is equal to Rs. 7,000 minus Rs. 1,050 which is for the equal to Rs. 5,950. So now money left with Ram is Rs. 5,950. Thus our final answer is money left with Ram is equal to Rs. 5,950. So this completes the session. Hope you have understood the solution for this question.


Dan, it's so nice to see you. Congratulations on your joint development agreement with YumaCore. How about you tell us a little about this news announcement. The market's responding very favorably to this announcement. Listen, YumaCore obviously is a very big player in the cathode space. Tremendous to have them as a partner, very validating for Nano1 and to have them in our ecosystem. We will be working with YumaCore jointly using their obviously their expertise in production and supply chain management and really cathode technology and our advanced technology to improve the throughput and the cost and the environmental footprint of cathode manufacturing. All of this with the goal of making YumaCore's cathode materials using Nano1's process. That's the core objective of what we're trying to do and create a long-term resilient secure supply chain in North America, in Europe, and around the world using this underlying technology. As usual, your news releases are so well written and you identify the three critical points that you plan on achieving in this agreement. If you don't mind them and have you go through all three with me, starting with parties to jointly leverage their technologies for high nickel, NMC, cathode active materials. What do you mean by that? Well, so YumaCore is a dominant player in lithium cobaloxide batteries and nickel rich cathode materials for consumer electronic applications and obviously the emerging electric vehicle market. They manufacture a tremendous amount of that material and have a lot of know-how in how to manufacture in volume. What we're really doing here is we're leveraging their know-how and we are bringing Nano1's nascent technological advancements to that. So we have our one pot process and our empty cam process which can reduce the number of steps and that improves the throughput of the underlying process. It drives down cost and because we're able to use alternative sources of lithium, nickel, mangas and cobalt, we can avoid some of the environmental footprint that's associated with the incumbent processes. So it's taking Nano1's process and making YumaCore formulations of cathode materials and all really with the gain of driving down cost complexity environmental footprint. So clearly you have a technology that's beneficial to YumaCore? Yes, very much so and we spent some time working with YumaCore over the last few years evaluating our technology and getting to the stage we're at right now. And of course YumaCore's proprietary process uses high nickel, manganese, cobalt combination, correct? That is correct, yes. So there are, there's kind of many different flavors of nickel rich or based NMC cathode materials and YumaCore has a series of formulations that are proprietary to them and that's what makes this really unique. Look our technology can be used to make any different type of cathode material and in this case we will be modifying and optimizing our technology to make their formulations. So it's not an exclusive relationship in the sense we can do the same thing for our other partners but it does allow us to create a customized version of our technology to be used with with YumaCore. Of course you have a lovely paragraph about how YumaCore does 2.1 billion in the first half of 2022 or the group generates revenues I'm just reading this here from your news release. When will nano one material shareholders anticipate seeing the impact of this news on your bottom line? Well listen the obviously in a joint development program your combining two technologies a lot of development work it starts at the really starts at the bench level in in in their labs in our labs and we build that up towards a towards commercial samples that we would we would trial with our mutual partners ultimately and with the hope of getting into a some kind of a piloting program to make again to make their materials with our underlying technology and I can't give specific dates on that it's a multi-phase process project with with a number of go-no-go milestones in there and but it's kind of measured in years until we kind of get through a number of those steps. Many of us deem this to be substantial news this morning I have received a volume of emails from top experts in the industry all kinds of companies who seek to decarbonize our economy were sending me did you see banana one news can you add anything to that and help us understand this just a little bit better? Well look you're hearing from those people because YumaCore's a big player I mean they've got a footprint all around the world in the space they've actually announced production facilities in Canada earlier this year and and of course they they have a footprint in Asia in Korea in China and in Europe as well they're they are joint venture partner with Volkswagen so they're not a name to be trifled with and and we're very proud to have them as a partner as a development partner and as I said earlier it really does bring a lot of credibility to what our team what our technical team has been able to build it's obviously we're building for the future we're building for the next generation catholic materials we can't get to terawatt hours and batteries and electric cars and everybody's driveways unless we solve some of the really kind of big problems and associated with the scale-up of this industry and that is nano one's intent that's in our DNA we're trying to remove you know prohibitive waste streams prohibitive cost structures prohibitive supply chains that that will get in the way of that and and having YumaCore on board really helps validate that that underlying premise and and and mission that we hold dear to heart at nano one well Dan as always what a pleasure and thank you so much for the update today thank you Tracy I always appreciate the opportunity to talk with you and your audience


The National Broadcasting Company and its affiliated stations present the Pacific story. In the mounting fury of world conflict, events in the Pacific are taking on ever greater importance. Here is the story of the Pacific and the millions of people who live around this greatest sea. The drama of the people's whose destiny is at stake in the Pacific war. Here, as another public service, is the tale of the war in the Pacific and its meaning to us and to the generations to come. The mighty Carolins, secret stronghold of the Japanese. One will ever know what happened to Hibbert. There are only a few men who ever penetrated the Japanese secrecy in the Carolin Islands. But Hibbert did. Hibbert is not his real name, but he was a real man, an American. He foresaw that the Japanese in the Carolin Islands could shut us off from the Philippines. That they could shut us off from the rubber and tin and oil of the Indies. He foresaw that the Japanese in the Carolins could not only keep us away from Asia and Indonesia but that from the Carolins they could strike us a crippling blow. And that's what happened. Hibbert came to me just after the Japanese went into Manchuria in 1931. Now this attack of the Japanese in Mukden, more than a local incident. Yes, it probably is. It's the first shot of the Japanese against us. Against us? Why, we have no quarrel with the Japan. Well, neither did Manchuria.  Yes, most of it. Well, look at Japan's movements and perspective. In 1894 she attacked China and took Formosa. And less than ten years later she attacked Russia and then Korea. And then, I know Hibbert, but what do these things have to do with us? With the United States directly, I mean. About the mandated islands, the Carolins, the Marianas and the Marshalls. What do you mean? Well, the Japanese agreed after the last war not to fortify them. But do you think they haven't? Well, they've wrapped a tight cloak of secrecy over them. That much we know. What could be the purpose of that secrecy if they were not fortifying them? Well, it would be dangerous to guess about it. It's more dangerous to us not to know about it. Well, you seem determined, Hibbert, to link the secrecy and the mandated islands with what's happening in Manchuria. What's happening in Manchuria is a straw in the wind. It's not just a coincidence that the Japanese have kept everyone out of the mandated islands all these years since the last war. Well, there is a possibility that the Japanese are fortifying those islands. Exactly. And if that's true, we ought to know why. And we've got to remember that Guam is within the Japanese mandate and that Wake Island is just outside of it. You think that Japan has designs on Guam and Wake? Well, don't you? That's why we should be so concerned about the Japanese having the mandated islands now. We had them once and we gave them away. We? The United States? Why, yes. At the time of the Spanish-American war. At that time, a great part of Micronesia, including the Carolan Islands, was held by Spain. When the war broke out, an American cruiser, the USS Charleston, steamed into the harbor of Guam and opened fire on the old Spanish fort. Lieutenant. Yes, sir? Is the fort replying to our fire? No, sir. That's strange. Do I continue firing, sir? No, hold your fire. A boat's coming out from the shore. Hold all fire! Hold all fire! He's firing! Well, the American officers stood on the bridge and watched the approaching boat through binoculars. Every gunner stood ready aboard the cruiser. As the boat neared, the American officers could see that it was bringing out a group of Spanish officials. The Spaniards were received aboard the warship with the greatest courtesy. We have to apologize that we did not return the salute of the United States, but we have no ammunition. Our fire was not intended as a salute. Not... not intended as... Well, what then? Doesn't the Governor know that the United States and Spain are at war? At war? Not the United States and Spain. It is impossible. Admiral Dewey has destroyed the Spanish fleet at Manila. Taken the city. What? I demand the immediate surrender of Guam. I must confer with my... my government. That'll not be possible. There is nothing else to do. I'm unable to defend Guam. We must capitulate. Very well. The United States will take immediate steps. All Spanish Micronesia and the Philippines fell into the hands of the United States. In those days, before the turn of the century, Americans were not yet conscious of the importance of the Pacific to them. I asked the senator, what does he propose that the United States do with these faraway islands in the Pacific? Does he propose to extend our borders to the shore of Asia itself? This was the attitude of many influential Americans in those days. Cries of American imperialism went up. The government was warned of America's historic foreign policy. Let us remember the principle of Thomas Jefferson, that nothing should ever be accepted, which will require the Navy to defend. I propose that we compromise, that the United States retain the Philippines and Guam, but turn the islands of Spanish Micronesia back to Spain by taking this course. So Micronesia went back to Spain. But at this same time, another European power was angling for strategic bases in the Pacific. And almost as soon as the United States gave the islands back to Spain, the world was astonished by a formal announcement. Spain has sold the islands of Spanish Micronesia to the Imperial Government of Germany. But Germany held these islands until the outbreak of the First World War. Yes, until the Japs moved in and took them in 1914. That's where the situation we have in the Carolans today stems from. You mean that the Japs got in and stayed there? I mean that Britain and France and Italy helped Japan stay there. You remember that the pretext for Japan seizing the Carolans and the other islands was that it had a treaty with Britain. Yes, the Anglo-Japanese alliance. But after Japan had taken the islands from Germany, then Germany had a sensational streak of success in Europe. Yes, I know. They almost knocked out the Allies. That was back in 1916. I was on the continent at that time. Presently we started hearing rumors that Japan was wavering in her allegiance to the Allies. We heard that the Japanese were convinced that Germany was invincible and that she could do better for herself by tying up with Germany instead of with England. Yes, that was great for the Allies when they were fighting with their backs to the war. Well, Japan played her cards well. She knew that this was an opportune time to make demands on the Allies and she proceeded to do so. And therefore, for our continuance as an ally, Japan demands the support of Allies at the peace table. Support of the Allies in what sense? Japan wishes the Allies to support its claims to possession of the islands north of the equator, which we took from Germany. What of the islands south of the equator? Japan will agree to support the claims of Britain to the islands south of the equator. Britain will support Japan in these claims.  One favor, return for another. But what of France? France will support the claims of Japan on one condition. What condition? That Japan will encourage China to come into the war on the side of the Allies. This Japan will readily agree to. In the interest of harmonious relations for the prosecution of the war. Japan wishes to be certain. With these conditions, England and France and also Italy entered into secret treaties with Japan. This was before the United States entered the war. The treaties were kept secret until the peace conference. And then, when they were brought out into the open, the Allies, including the United States, awarded the Japanese, the Micronesian Islands, under a League of Nations mandate. For all practical purposes, the islands were given to Japan. Well, that was not the intent. It was specifically set forth that the islands were merely to be under a Japanese mandate. But you remember that some distinguished Japanese said that a mandate is a temporary arrangement. That Japan would find a way to make it permanent. Japan agreed not to fortify the islands. Do you know what has happened now? Well, are you guessing or do you know? Japan is outflanked, both in Guam and the Philippines. Well, you assume that Japan and the United States must go to war. Well, here, look at this map. Now, with air bases and naval bases scattered throughout these islands, Japan can defend herself in Asia from any angle of attack. And, uh, look here. Using these islands as bases, Japan can move against Pearl Harbor up here, against French into China, against Singapore, Malaya, against the Dutch Indies down here, and even against Australia and New Zealand. And what are we going to do about it, eh? What are we going to do about it? We talk things over like this for days. I saw that Hibbert had a deep intuitive feeling that great danger was brewing for us down there. It was more than intuition. It was logic. He pumped me dry of all the facts I had on the Carolans. And then one day, not unexpectedly, he remarked that he was going to visit them. He insisted that I go with him. I myself, as a world observer, had long been interested in the Carolans. For a long time, I had been hankering to see them too. We knew that foreigners had been barred from the Carolans since 1934, but we determined to go anyway. We talked to informed people about arrangements. There's no way to get there. All ships but Japanese ships are barred from the islands, and you can't get accommodations on a Japanese ship. Then they tell you that the waters around the islands are dangerous, that the sea is filled with treacherous reefs and the well is bad. They say that aboard the Japanese ships, if you should ever manage to get on one, you have to live on fish and things like that. They say there's no place for visitors to live on the islands. No living accommodations whatsoever, except living in huts with natives who they say are savages and headhunters. They discourage you in every way. But through people who are friends of influential Japanese in Japan, we managed to get there. On the islands, we were permitted to walk around pretty much at will. That's beautiful out here. Utterly beautiful. Yes, there's probably no more beautiful place on earth. Look at that quiet lagoon. Yeah. And see the coral reef out there? See the white surf breaking over? If tourists were permitted here, they'd come by the thousands. There won't be any tourists here for good many years to come. Every one of the small islands is crowned with those tall cocoa palms. Yes, and notice up on the hills the tropical growth, mango trees, breadfruit, papaya, orange and banana, lime trees. Yes, this is the land of the lotus eaters that there ever was one. I, um, I haven't seen any military installation. No. No, only the same things you'd see on any South Pacific islands. Few stores, post office, few government buildings. But you notice there's a hospital. Good size one, too. And school. Yes, you don't put in hospitals. Especially good size ones and schools without a purpose. Let's walk down to where the reef broadens out. You know, I got an idea. Well, here comes our bodyguard. You can't turn around without one of those Jap policemen suddenly turning up and following every footstep. Good morning, gentlemen. Good morning. In any way... No, no, no, we were just looking at the scenery. It's beautiful. Very beautiful, yes. Yes, we were just about to stretch out a little, take a little walk. Good. I will be your guide. Oh, no, that isn't necessary. We're just strolling. Oh, no, trouborator. Which way do you wish to go? Well, we thought we'd walk down to the broader part of the reef down there. Very well. The view is very interesting from that point. This is the kind of place that most men only see in their dreams. Very beautiful, oh, yes. Those hills rising out of the sea, I suppose they're the tops of mountains, right? Yes, very high mountains standing on a floor of ocean. They're not really very high above the level of the sea. Or like a smaller mountain above the sea. They provide very good shelter for the lagoon inside the atoll, though, I imagine. Well, maybe they do. Yes, maybe. Yes, yes. Yes, you see how smooth the lagoon on the inside is. Almost glassy. Oh, yes. Have you ever seen such color in all your life as there is down there in the lagoon? Corals and sponges. Oh, yes. Some of sponges are red and some are yellow and some are green. And see many corals of fish swimming down there. Yes, and look at all the different colors and shapes of the sea plants down there. Do you ever see anything so brilliant? Oh, very gorgeous. Here is broad part of reef. Nice. Quite a development you have here. Docks, warehouses. Oh, for hindering the produce from irons. Mungose, breadfruit and other fruits. Yes, you have to have facilities for that. Yes, nice airfield and hangars. Do you fly out the fruits? No, oh, oh, maybe someday, airplanes only use for communication now. That's all. I can see that you have great possibilities here. Yes, great possibilities. We saw the Carolins. We saw their incredible beauty. But we were adroitly kept from seeing much more. By inference, we knew there was much more. Wherever we went, Japanese were present to help us, as they said. They never forbade us to see anything. They merely saw to it that we did not see it. When we wished to see certain atolls, there were always reasons why this could not be done. In all cases, the reasons were that they, the Japanese, were looking out for our safety. But from their unwillingness to let us see certain places, we knew which places were important. What I had seen opened my eyes. When we got back, Hibbert and I talked for days. You've been an observer in almost every part of the world. Have you ever seen anything like this? Well, there's probably no other place in the world like it. Well, there isn't. What's important isn't what we saw, but what we did not see. So far as I'm concerned, the most important thing was the most obvious. You mean the lagoons? They're miles deep, many of them. The waters are smooth and quiet. Perfect harbors for every kind of naval craft. That's exactly what I was thinking. They're sheltered by those mountainous islands. Japanese warships and those lagoons could never be attacked by other naval craft. No, particularly since the Japanese have probably mounted good-sized guns in those mountains. The only way ships in the lagoon could be attacked would be by airplanes, bombers. Yes, that's another thing. Those lagoons are perfect for seaplane bases. That's what I was getting around to. What do you mean?  Yes, I should think that would be true. At least in time to come, if not now. That means they've got hundreds of air bases, lagoons, I mean, in addition to the landing fields on the islands. Yes, quite likely. The only way you could find out how extensive this development is is by flying over the Carolines. Flying over the Carolines? Well, you're not thinking of that. Are you a hibbid? Yes, why not? Well, where could you get a plane these days? And who would fly it for you? Well, I... I believe that could be managed all right. A hibbid, you'd never get near the Carolines. The chaps would be on your neck as soon as you approached. Well, tell me, would you be willing to go? To fly over the Carolines? Yes. Oh, from where? Well, that's the detail. Would you go? Well, yes, yes, I'd go. That's all I wanted to know. All right, I'll take care of all the details. You can just leave everything to me. I had many misgivings after I had agreed, but there was something about hibbid's courage and clear thinking that reassured me. If we were forced down, we would probably never get back, particularly since the Japanese knew us from our visit. Hibbid made all the arrangements. We loaded the plane with everything we could think of, including some good camera equipment. We took off with a pilot, a copilot, and a navigator. Navigator? Yes, Mr. Hibbid? How soon should we be sighting Trook? Oh, I'd say in a matter of minutes. Minutes, huh? Good. Well, let me know once, will you? Yes, sir. Just look at the islands down there. Yes, you can get a good perspective on them from this altitude. That gives us some idea of the number of islands in Micronesia. Oh, there are thousands of them. And every island is an observation post. That means that the Japanese are able to keep a constant eye on about three million square miles of the Pacific. Oh, yes, at least that. Some of them are certainly going to spot us. Well, one thing, our altitude and speed are in our favor. If they should spot us, we'll just have to... We flew over hundreds of small islands. As we approached Trook, all of us could sense the tenseness among us. I went up forward to talk with the pilot, the copilot. Well, how's it looking, boys? Oh, looks all right from here. Once we don't have trouble from below. Great day for us. Weather's clear. Just a few clouds. Yes. Interesting down there, isn't it? Those atolls down there are like coral reef around a small island. Yes, except that the reef itself is made up of many small islands. There are many islands within the reef. If they use every one of those atolls down there as a seaplane base or a naval base, I don't see how anybody could get through them. They can't. All I want to do is get over them. Hey, there's Trook ahead of us. Isn't that our landfall? Yeah, that's it. See it up there? Yes, that's it. Inform Hibbert. Okay. Navigator? Navigator? Yes, this is the navigator. This is the navigator. We've just sighted Trook. Get ahead. Tell Mr. Hibbert.  Yes, I'll tell him right away. Yes, there it was. All right. Trook. I recognized it from what we had seen when we visited there. I went back into the cabin to see Hibbert. Ah, now, this is the view I wanted to get. Navigator? Yes, sir. You have your camera equipment ready? Yes, sir. It's all in order and ready for operation. Good. Take as many pictures as you can. Yes, sir. Look at that. A lagoon about 40 miles in diameter. Yes, big enough to hold the entire Japanese fleet. Battleships, cruisers, destroyers, submarines and all. That reef is made up of 245 mountains islands covered with trees. That's what I told you. The Japanese fleet in there would be sheltered from attack by any of the warships. Look at that opening down there in the south. A sort of passageway. Oh, yes, that's Autopass. It points toward Australia. And there's another to the northeast. You see it there? Yes, I see it. That one aims at Pearl Harbor. And there's one up on the west. That points to the Philippines. And that opening up on the north end points to Japan. Any ship that tried to get through those passageways without a chart would be gashed open on that sharp coral. That's right. Get some pictures of that, Navigator. I'm getting them. There are some good-sized islands down there. And every one of them has airfields on it. Yes, and notice the anchorages around them. Navigator, be sure to get good shots of the islands and close by the reef. I'm photographing each one as we pass it. Mr. Hibbert? That's the pilot, Hibbert. Yes, pilot? I've just spotted a plane about 4,000 feet below us to the right. Can you see it? Wait a minute. You see anything of a plane below us to the right? Oh, I can't see anything. I see it. I see it right down there. You see? Yes. It's climbing straight for us. It's after us, all right. Well, there are two more coming up behind it. Yes, I can see them. Now, three of them. Pilot, this is Hibbert. There are three planes out there. Full speed and head for those clouds. Okay. Hang on. Here we go. Not a bad way, Hibbert. We haven't got enough gas to continue at this speed very long. Oh, and the worst thing about it is that we have to clear out before we get what we came here for. We knew that the three Japanese planes would be swarming around us in no time. Our pilot cut in and out of the clouds, and suddenly the door swung open. The door swung open. Watch out! There goes the camera! And one of the cameras with all its pictures went sailing out. The navigator slammed the door and saved the other camera. Those were some of the most exciting moments of my life. But Hibbert sat there cool and undisturbed. In the light of what has happened since, I know he felt that he had failed. Ah, that's all the pictures we got. Well, they're good ones. But they don't tell enough. They don't tell the story. Well, you'll probably never get any more. No, I'm afraid not. Not that way. Not that way. Shall I tell you something? What? The Carolans are the very core of the Japanese strategy in the Pacific. You know, I have an idea that Truc is the most important base in the Carolans. It could be Ponape. We hardly know what's good at that. It's important for us to know which is the primary naval and air base, Truc or Ponape. Truc has military installations, ammunition dumps. Yes, but no white man has ever seen them. Well, the same could be said of Ponape. Well, yes. That's another reason why we must go back. Go back to the Carolans? You mean you and I? I want to bring back pictures, drawings, measurements. No, not I, Hibbert. Not I. We wouldn't fly over this time. We'd go by boat. Why, by this time, every Japanese official in Micronesia was informed about the plane that escaped their fighter planes. Every Japanese in the islands would be on guard, all right? But against that, we must weigh the fact that Micronesia controls the approaches to the Philippines, Southeast Asia, Malaya, the Dutch Indies, Australia. Well, Hibbert, you can't go back there again. You mean you won't go with me? Well, this is a time for sober consideration of all the factors.  Goodbye, then. Going back there alone, I'll see you when I return. Well, goodbye and thank you for all your help. There have been many stories about the Carolans since then. Many stories about Trucque, and Ponape, and Yap, and Cusay. Most of them have been conjectures, but Hibbert was right about many things. He was right about the Japanese, about the outbreak in Manchuria in 1931, being a straw in the wind, a foreshadowing of events to come. The story of Japanese aggression since then is history now. Today, the insignificant Carolans have become the mighty Carolans. Today, we know that this screen of hundreds of islands, each a fortress, shelters the Japanese Pearl Harbor. And this super fortress, with its nests of warships, its swarms of dive bombers and fighters, is a key toward victory in the Pacific. Today, the Carolans are the subject of sober discussion around war-planning tables. The Carolans are probably one of the most inaccessible military bases in the world. Yes, they're protected on all sides. Over here, 1200 miles to the east, toward Pearl Harbor, we're moving in on the marshals. Up to now, they've been a protection from a drive from that direction. Before Trucque and Ponape can be attacked, it'll be necessary for us to have bases in these outlying islands. That is a vital consideration. We might turn these islands against them as they use them for operations against us. Yes, just as the Japanese use them for bases for attacks on Pearl Harbor, Wake and Quorum and Philippines. So we might use them to advantage against Japan. That's why Japan calls Micronesia its lifeline to the south. In any operations we contemplate, we must keep that in mind. And we must recall also that Admiral Suitsugu said that the Micronesian islands were made to order for Japan and that the balance in the Pacific could only be maintained if Japan holds them. Look at this point. It is my opinion that we should move in this direction toward the side of... The action in the Pacific is moving in the general direction of the Carolans. As the operations and the marshals progress, most of us are becoming aware of the importance of the Carolans. We know that Trucque is not only a powerful fortress, but also the supply base for many of the outlying Japanese island strongholds. We know that sooner or later, Trucque must be stormed or bottled up on the road to Tokyo. And all this Hibbard foresaw. He foresaw what the Carolans would mean to the Japanese and to us. Hibbard went back to the Carolans that last time and no one has ever seen him since. You have been listening to the Pacific Story, presented by the National Broadcasting Company and its affiliated independent stations as a public service to clarify events in the Pacific and to make understandable the cross-currents of life in the Pacific Basin. A reprint of this Pacific Story program is available at the cost of 10 cents. Send 10 cents in stamps or coin to University of California Press, Berkeley, California. The Pacific Story is written and directed by Arnold Marquess. The original musical score was composed and conducted by Thomas Paluso. The principal voice was that of Edgar Barrier. This program came to you from Hollywood. This is the National Broadcasting Company.