Hi everyone, I'm Rob Horlacher from Project Sandbox, a University of Lethbridge Library Initiative. In this video, we're going to look at the Insta360 ONE X camera.  So the Insta360 ONE X, let's just call it the 360 camera from now on, is controlled by either the camera itself or you can control it via an app on your mobile phone or tablet. If you would like a link to all the different software that you might want for the Insta360, also the 360 camera, you can look at it in the description, I'll leave a little link there for you to click on. But for the moment, let's look at just how to control the 360 camera with just the camera itself. To use the Insta360 ONE X camera without the app, we first need to turn it on. When you turn on the camera, you'll notice that there's a little camera icon. If you press the big button when it has that icon, it'll take a picture. If you want to take a video, you just need to press the little button until it has the video. You'll notice there's different settings, press the big button once. That'll start the video and you'll see the timer increase, press the big button again, and you're done taking a video. The next thing to notice is if you actually want to change anything to do that, you go into the gear, which is the settings, and then you can scroll through the different lists just with the little button and select with the big button. This is the one for camera, video. What we want to look at is Wi-Fi. If you want to connect to this thing over Wi-Fi, you need to first find out what the Wi-Fi network name and password is. To do that, you scroll down to Wi-Fi password, you hit the big button, and then that'll take you to a menu that will have the network name and the password. You would just need to sign on to that like you would any Wi-Fi network and that'll connect you to this camera. Of course, you'll need the app as well, but I will go over the app later on in this tutorial. So that's how you connect Wi-Fi. There's a couple other things to note though. First is say you just took that video and picture and now you want to move it onto your computer. To do that, what you need to do is grab the USB to micro USB cable and plug that into the Insta360. I like to use the tripod just as a nice little base station. After that, what you want to do is you want to hook up this to your computer obviously. So let's just do that. So you heard it plugged in and you'll notice that the USB drive appeared. When you double click on that, go into DCIM, camera one, you'll see all the content that I just took and you can just click and drag it to wherever you might want it to go. Once you're done clicking and dragging that content and you have it saved to a safe place, we can go back to the camera. What you'll want to do with the camera at this point, because you're 200% sure you got all of your footage off the camera, now what you want to do before you return it to the service desk is you want to remove it. To do that, we go back into the settings.  In this about area, you want to scroll down until you see format. When you click the big button and go into format, you'll see a checkbox. What will happen when you hit the checkbox is it's going to totally remove all the files you just took from the camera and they will not be retrievable. If you'll notice you didn't really see any kind of like signs that it actually was getting removed, it'll just look like the screen froze for a moment. If that's what happens, it means it's working properly and all of your files are getting removed from this. Just remember, do not do this until you are 200% sure that all of your files are off of this. At this point, you can turn it off by holding the little button and then you can return it back to the service desk. So as you can see from controlling the Insta360 ONE X from just using the camera, it's a little hard to tell what your images might look like. In order to do that, we need to use an Android or Apple device. So let's take a look at that now. To control the Insta360 ONE X with the app, we first need to turn on the camera by holding the big button. Once it's on, we can go into our phone and click on the app. Once the app is turned on, you just need to click on the camera button and then go to connect now. This will bring up some information on how to actually connect via Wi-Fi. So I've already connected and I've gotten all the information off of the camera so I can just go to the ONE X Wi-Fi signal directly. Once it says that I'm connected to it and my internet is not available, it means that it should be good to go. So now you can see me and this is roughly what the camera is taking a picture of. We can scroll around to get a better look of everything now, unlike when you just use the camera where you can't see everything. As you can see we're also in the camera mode. What you can do though is you can click on the little magic wand and change filters. You can click on the sliding bars and change some of your exposure settings, whether it's in raw, white balancing, stuff like that. You can click on video. Once again you can look around and you can go through the same menu systems there as well. As you can see it does have some different options for video though. The other two things I want to bring your attention to is the live 360 and the live shooting modes. These are ways that you can actually send things to Facebook and stuff like that right away and actually live stream from the Insta360 camera. If you're not interested in that though, you can just use take normal pictures or take video. One thing I'll mention about live streaming is this is why you need the concophony of cables that come with this kit. Depending on your phone or tablet or whatever you're connecting it with, you will have to connect directly from that device to the Insta360 camera because as you can see this does not have internet right now which means that it has nothing to connect to. So keep that in mind if you do want a live stream. But the next thing I want to bring your attention to is this settings button. When you go into settings this is what allows you to format the card over your phone. Make sure you don't do this unless you're 200% sure that you have all of the content off of the camera. So if you do want to format the camera and you've gotten all of your stuff off you should just go to microSD card management and then you hit that format button. I'm not going to do that yet because I haven't took any of the content off but you'll want to make sure you do do this before you return it to the service desk. If you actually want to get content off you'll want to click on your little album option and you'll see a couple different things that I've actually taken already. To export these to usable files you can just click on whichever one you want as you can see it's my beautiful face and then you can click the three dots. The three dots will give you some different options like if you want to view it in VR if you want the logo and just anything else. What you'll want to do if you want to export it is hit that square with the arrow pointing to the top right it's just at the top of the screen right now.  We want a local file though because this will just give us a JPEG or an MP4 so to do that you just click the local button and then it'll give you some different options like spin view 360 sky you can do a lot of different stuff with this. Say I want tiny planet because I like my head to look really large I just hit export and then it'll begin exporting the photo. This will go into whichever folder you have set to your device. Once that's done we can see that we actually have it somewhere and it's good to go that's pretty much all I actually have to show you for the app. If you do want to learn a little bit more about suggestions they have you can click on the tutorials link and then they have tons of different things that you can watch to give you a more in-depth look at how to use the camera. Finally if you dragged and dropped all of your files to your desktop you'll need to download the Insta360 Studio software. This software will convert all of those weird file types into things like MP4s and JPEGs which everything can use. The added benefit of the Insta360 Studio software is if you do download it it'll allow Premiere to now edit these different file types. If you don't want to download it on your computers you can go to the Project Sandbox computers just on level 10 of the library and we have that software installed on those where you can export the videos from there as well. So the last thing I wanted to show you is what you do with your files if you actually did drag and drop them to your desktop. What you do with them is you can either open the program right away or you can just double click on whichever video or image you would like to edit and export out to something that's a little more useful. As you can see this is what opened up for me it just opened up in my alternative window so don't worry too much why you didn't see this actually appear. So as you can see there's a couple different options if this is an image you'll still have the exact same things that you can change. So on the right hand side you can use flow state stabilization. If you had a case you could change it as you can see different lines and stuff appear depending on the case you chose. But we don't have a case so you would generally just click normal unless for some reason you bought one on your own. So the main thing that you'll want to know how to do with this application is how to export this as either an mp4 or a jpeg depending on if you have a video or an image. To do that you go up to this top option and click it. This one says I've done changes do you want to save it I don't really care but I will hit okay just so you can see what you should do. Then this little option box will pop up with all the information so the resolution of this the file name and where the file path is going and the bit rate you can probably just leave it as is and just hit okay. After you hit okay it will begin exporting it your document to wherever you said it might be going. You can see there's a little percentage bar at the top and it will increase pretty much as fast as the your computer will allow. Once the file says 100% and finished the file is obviously done and now you'll have a file type which you'll be able to actually edit comparatively to this insv file type which is a very specific file type. So like always that's what I have for you remember to just be creative with the camera and try different things out. Thank you very much for watching this video and if you would like to subscribe to the UofL library YouTube page you can click on the link on the page right now or you can continue watching Project Sandbox videos by clicking the one of the two video links that is on the page right now. Once again thank you very much for watching and I hope to see you at either some of our workshops or you can see me in just some more of our videos. Thank you very much and I'll see you all later.


that T satisfies the weak bond in this property and T of one and T star of one belong to BMO. So for now, once again, the convention T star is just a transpose. It's not Hermitian adjoint. There's no complex conjugation at this point, okay? And the second thing is that T is bounded on L2. All right? So a couple of remarks are in order. So let's try to put a little perspective on this theorem. Remember that we have this theorem of Petri, Span, and Stein. I don't remember the numerology of it now, but there was only one theorem with those three guys. All right, which said that if T is bounded on L2, then T maps L infinity into BMO. And in fact, of course, just by basic Hilbert space theory, if T is bounded on L2, so is T star, and therefore also T star maps L infinity into BMO, okay? On the other hand, suppose that you don't necessarily know a priori that T is bounded on L2, but you do know for some reason that T and T star map L infinity into BMO. Well, dualizing the estimate for T star, then you also get that T maps Hardy space H1 into L1. And then interpolating, there's a version of interpolation due to Phefermann and Stein where BMO can substitute for L infinity as an endpoint and H1 can substitute for L1, and you pick up all the LPs in between. In particular, you pick up L2. So then you get that T maps L2 to L2. Okay? So what's the T of one theorem saying? It's saying that you don't have to test T and T star on all of L infinity. You only have to test them on a very, very special function, which is the constant function of one, okay? All right. Well, except with one additional, but as we've seen sort of mild hypothesis, which is the weak-boundness property, right? Remember, we saw that weak-boundness automatically holds if you're looking at the principal value operator associated to an anti-symmetric kernel, which our examples often happen to be. In fact, for the examples that we've discussed, Cauchy-Energy operator and the Color-owned commutators, they are anti-symmetric. Okay? All right. So the second remark is that the direction two implies one, right? That the L2-boundness implies the first thing. We already know this, okay? Because Petrie-Spanstein tells us that T and T star map L and 30 to BMO. So in particular, they map one into BMO because one is an L and 30. And we've also seen that L2-boundness trivially gives you weak-boundness property just by Cauchy-Schwarz, okay? Okay? So the real content of the theorem is to prove that one implies two, all right? So last comment before we go to the proof. There's an issue. If you don't already know boundness from L infinity to BMO, then what do we mean by T of one? Well, this is one of the exercises, but I'll just say a brief word now, that you define T of one as an element of the distribution's modular constants, which means, in other words, that it's in the dual space of what I'll call D zero. D zero is gonna be the set of psi and C zero infinity with mean value zero, okay? And you can make sense then by sort of mimicking when you test T of one against such a psi, that means because psi has mean value zero, you're gonna be able to subtract an appropriate constant, okay? And then you sort of mimic the proof of the Petrie-Spanstein theorem, all right? And that's how you prove it. And there's just a little bit of work, but not much to verify that the thing is actually well-defined, right? The idea with Petrie-Spanstein was to split your function F into a local part plus a far away part. And somehow you need to get well-defined in this, you need to verify that really what the thing that you're defining is independent of the particular splitting that you make, but that's not hard, okay? And that's the exercise, all right? So let's proceed to the proof, all right? So, we're gonna use Littlewood-Paley theory, all right? So we're gonna introduce our usual sort of nice Littlewood-Paley operators that give us a color on reproducing formula. So let QSF equals Zeta S star F, Zeta S as usual as to the minus N Zeta of X over S. I'm not sure why I'm using S. I'm gonna be switching to T in a moment, but I hope that's not confusing. We wanna have Zeta in C0 infinity of, well, just for a slight amount of convenience, I'll choose it to be sporting the ball of radius a half rather than one that doesn't really matter. And with mean value zero, and we're gonna choose Zeta to be real and radial. And non-trivial, of course. And then as we've seen in those circumstances after a normalization, we get the color on reproducing formula, all right? Okay, for that family of QSs, okay? All right, so now I'm gonna define an operator PT, which is gonna be this guy, all right? And it turns out, well, first of all, notice that as T goes to zero, this guy is approximating the identity, at least in L2, because that's the meaning of this statement, okay? But one can actually say more. I'm gonna omit the proof here. It's in the notes. It's just a sort of elementary real variable argument with a, based on some changes of variables, and using the fact that you're dealing with a radial guy, okay? What you can show is that PT, in fact, is a standard modifier, a nice approximate identity, okay? So in fact, PTf is Ft star f, Ft defined in the usual way, with phi in C0 infinity, real, radial, supported in the unit ball. That's why I made this support a half, because then this was in the unit ball, all right? If we made that one in the unit ball, this would be the ball radius two. Doesn't really matter. And the integral of phi is one, okay? So you get a very nice standard modifier, nice approximate identity, okay? And as I say, I'll omit the proof here to save time, but you can find it in the notes and it's not hard, okay? So a couple of further sort of easy remarks about this PT. Of course, we can see because PT is a standard modifier, we know that it converges to the identity in strong operator topology on B of L2, okay? We also have that PTf converges to F point-wise that PTf converges to F point-wise almost everywhere for F in L2, say. And in fact, everywhere for F continuous. But moreover, we also, and again, this is as T goes to zero, but also that PT of F converges to F in D for F in C0 infinity. That's routine to check. And one more thing, which is that the limit as R goes to infinity of T of PR of F, PR of F, PR of G, I should say, is zero for F and G in C0 infinity. And this is a consequence of the weak boundaries property and the fact that PR, this operator PR, is mapping L1 to L infinity with norm R to the minus N, okay? You can buy that fact with the weak minus property in. Yeah, you get it, okay? Again, the details, well, I don't know. Maybe I didn't put the details in the notes, but it's not hard. I guess it's an informal exercise. It's not on the official exercise list, okay? So if we combine these facts together, what does that say? It says that, okay. So let F and G be in C0 infinity. And our goal is to show that if we make this pairing, initially defined in the sense of distributions, that there's some uniform constant depending on the dimension and the color and Ziegman's estimates for the kernel and the BLMO norm of T1 and T star of one and the constant of the weak minus property, you know, all that usual stuff, then they should be bounded by the L2 norm of F times the L2 norm of G. Because if you can do that for all F and G in this dense subspace of L2, then you would just make an extension by continuity and that T extends to a bounded operator in L2, okay? So let's look at this. Because of what we've said here, we can obtain this thing as a limit as epsilon goes to zero of the integral from epsilon to one over epsilon of, let me say it this way, d by dt of pt t pt f g dt, right? Because you just integrate out and use these facts. Oh, and one other fact that the conditions on pt make it self-adjoint. So putting the pt here is no different than putting the pt here, okay? Right? Oh, I think I'm missing a minus sign, right? There should be a minus sign. Because we get the identity on this end and zero on this end. So now we take this derivative and notice what we get from differentiating this integral here. We get that this equals, limit as epsilon goes to zero, integral from epsilon to one over epsilon of qt squared t pt f g dt. Dt over t plus the same thing, let's see, the same thing with a pt here, t qt squared f g. And again, the measure is dt over t, okay? All right? Now I claim that these two terms are essentially of the same form. Okay, so let's give these a name. Let's call it one epsilon of f and g plus two epsilon of f and g, okay? So for example, let's look at two epsilon of f and g. All right, as we said, the pt is self-adjoint. So you can bring it over here. You can bring t over, it becomes t star, and you can bring one of the qt's over. The qt's are also self-adjoint, they're real and radial, okay? And so this becomes integral epsilon to one over epsilon qt f qt of t star of pt of g dt over t. But notice that if we brought the qt over here, this is the same, exactly of the same form as this term, only interchanging the roles of f and g and the roles of t and t star. But everything is symmetric here. So if you can handle one, you can handle the other, okay? All right, yep, yeah, yeah, it's not hard. Yeah, it's because, yeah, it's in the distribution sense because the pt is also given by a C0 infinity thing, right? And so you're still, and whether you have pt or the derivative of pt, everything that you have here is always of the form t applied to a thing in d, paired with a thing in d, and it's easy to justify using that, okay? So therefore it's enough to treat the term one, okay? All right, so it's enough to treat the term one epsilon, and in fact, it's enough to show the bound that we're after for one epsilon as long as it's independent of epsilon, okay? So our goal now at this point is to show that the sup over epsilon bigger than zero of one epsilon of fg is less than or equal to some permitted constant times the L2 norm of f times the L2 norm of g, okay? So then let's look at that guy. Again, we're gonna move one of the qt's over onto the g and then notice that this pairing is no longer merely a distributional pairing. It's actually, it can actually be understood as an integral, okay? So that's because right when you modify a distribution, you actually have a function, okay? So one epsilon of fg is equal to integral from epsilon to one over epsilon integral on rn of qt, pt of f of x integrated against qt g of x, dx dt over t. And we're gonna bring absolute values all the way in at this point and then use Cauchy-Schwarz. And when we use Cauchy-Schwarz, we might as well, once we bring the absolute values in, we might as well integrate from zero to infinity. So for sure, any bounds we get will be independent of epsilon. And here we have qt t ptf squared dx dt over t to the one half times the same thing with qt g of x squared. And let's give these a name, let's call them a times b, okay? And so notice that term b by the basic Littlewood-Paley theorem for very nice convolution type qt's. I guess that was what? Proposition 2.6, that will check me on the numerology, but I think that's right. We get that b is bounded by the L2 norm of g, okay? Right, that's immediate. So what we've boiled things down to is that a is less than or equal to the L2 norm of f. So notice what we've got here. What we've got is a square function. And if I call this thing qt t pt, if I call this thing theta t, it is sort of a familiar appearance to what we've been working with. All right, so in other words, we need to show this where theta t is qt t pt, just the composition of those three operators. So at this point, you can probably guess where this is going. We're gonna prove this by using the t of one theorem for square functions. All right, maybe I should give this a name, let me call this thing star, okay? So to prove star by the t of one theorem for square functions, this was, I think, again, not super confident about the numerology, but I think it was 3.1. What we need to show are two things. First, that this guy has a kernel, which satisfies the standard little wood Paley kernel conditions, okay? So it's enough to show that, one, theta t has a kernel, psi t of x, y, in the little wood Paley class, all right? So we have a little wood Paley family, I mean, all right? And second, that the measure d mu of xt, given by theta t of one of x, squared dx dt over t is a Carlson measure, right? Those were the two hypotheses of that t of one theorem for square functions. Once we have these two things, we're done. All right, now the second one is essentially immediate, because recall that pt of one equals one, again, because the kernel pt had integral one, okay? And also, t of one is in BMO, all right? So therefore, qt of t of pt, so let me write it this way, theta t of one is qt t pt of one, pt of one is one, so this is qt of t of one, but this is in BMO, okay? So therefore, the Carlson measure estimate is immediate now from the Pfeffermin-Stein lemma that you proved as an exercise, okay? And I think, if I remember the numerology, there's 222 maybe in the notes, okay? So that part's easy. Part one is longer and more complicated, I think because time is short, I won't go through the details of that, but they are in the notes, but let me just make a couple of comments, okay? So what you want to do, okay, maybe I should tell you what the kernel looks like, all right? So you split into two cases. First, where the distance between x and y is say at least 100 times t. And second, where the distance from x to y is less than 100 times t, okay? Now in this case, we have separation and we can write out explicitly what the kernel looks like as an absolute conversion integral, okay? So this kernel is gonna be, well, it's a convolution of qt with t of pt, all right? So this will be zeta t of x minus z, say. Then integral of k of let's say z and v, the kernel for the singular integral, and then the kernel for pt, which is ft of v minus y, and then we have dv and then dz, okay? Right, because if you apply this to a function f integrating in y, this will give you pt of v, applying this gives you t of pt of, sorry, pt of f. Applying this, integrating here gives you t of pt of f and integrating here gives you qt of t of pt of f. And this is legitimate because notice that if x minus y is bigger than or equal to 100t, then z minus v is bigger than or equal to, let's say 98t, right? By the triangle inequality since each of these guys, zeta t and vt in particular support in a ball of radius one, or ball of radius t, okay? All right, and so we have separation here and this is an absolute conversion integral, right? The kernel is away from its singularity. Okay, and then what do you do? Okay, you do a thing that we've done a few times now, use the cancellation here, which allows you to subtract off so we can replace k of zv by k of zv minus k of xv, all right? And then use the Kolder-Ohn-Zigman condition and you go through. The smoothest condition in the little, that'll give you the little wibbilly size condition. The smoothest condition, you need to only verify it in the y variable and so then you just work with the gradient of phi t instead of phi, and then, and again, you get things rather easily. Okay, again, the details are in the notes, but that's the idea. For case two, the idea is somehow to use the weak-bounderness property, right? You're not, in case two, you don't get to write this out as an absolutely conversion integral, right? Because you don't have separation, you're not away from the diagonal there, okay? So I'll just say briefly that in case two, use weak-bounderness, okay? And again, the details here are in the notes, all right? And that's the proof of the theorem, okay? So except for this kind of, you know, not deep and difficult but technically messy business of verifying the kernel conditions, it actually turned out to be a f-


Item Number- SCP-4148 Object Class- Euclid Special Containment Procedures- The area surrounding SCP-4148 has been cordoned off under the cover story of a dangerous spider infestation. SCP-4148-1 instances have not been seen leaving SCP-4148, and further containment procedures are not necessary. An agent at Lunar Area 32 will contain SCP-4148-2 once it reaches their location. Description- SCP-4148 is a 1-240 scale reconstruction of the Kennedy Space Center in Osiala Forest, Florida. SCP-4148 is made primarily up of wood, rocks, sap, and mechanical components of unknown origin. SCP-4148-1 refers to any specimen of the family coxinellidae. Introduced to SCP-4148, SCP-4148-1 once within a 5-meter radius of SCP-4148 will begin constructing its components. There are approximately 400 instances of SCP-4148-1 within SCP-4148. Even if brought outside of SCP-4148, SCP-4148-1 instances will eventually return there of their own volition. Despite limitations in resources, SCP-4148 has successfully launched several manned rockets, propelled upwards through some anomalous force. Most of these launches have ended in the rocket either crashing or exploding. Incident 1 On October 13, 2018, SCP-4148 successfully launched a rocket made entirely of a plastic bottle and several sticks. The rocket propelled itself 15 meters into the air. All instances of SCP-4148-1 ceased their activity and watched the rocket. After 10 minutes, the rocket exploded, scattering its parts over the clearing SCP-4148 was situated in. For a period of three days following this incident, no work was seen from SCP-4148-1. Further investigation revealed that they all appeared to stay indoors within SCP-4148. However, SCP-4148-1 then collected the remains of the rocket and began repairs. Incident 2 On November 19, 2018, after repairs were finished on the rocket, it was launched again by SCP-4148. Despite previous launches ending in failure, the rocket managed to consistently accelerate upwards without failure. This was met within a erratic period of activity from SCP-4148-1, presumed to be celebration. The rocket, now designated SCP-4148-2, has escaped Earth's atmosphere as of November 23, 2018. It is estimated that SCP-4148-2 will reach the Moon on December 4, 2018. A clear plexiglass dome is being constructed around SCP-4148 to prevent further launches of dangerous projectiles from SCP-4148 from causing damage or arousing suspicion. SCP-4148-2 is able to continue broadcasting and move up to making live-action SCP adaptations thanks to support from our viewers, subscribers, and especially our patrons. Special shout out to our Level 5 researcher-level patron, Andre Beichert.


Hi there, here's another edition of Drunk with Nintendo Power, this time we're going back to the first issue I ever owned, Volume 22, March 1991, with the game Metal Storm on the cover. I wonder if anyone out there still has this action figure mech thing they used for the cover model. This month's mailbag features a Nintendo Wrap written by four kids, and yeah, it's about as painful as you might expect. Anybody out there with kids, if you ever want to show them what the 90s were like, read them this letter. This month's comic is Howard and Nester, back when Howard Phillips was still around as the president of the Nintendo fan club. Here we see Howard working on the subsea from Star Tropics, but he can't get it to dive properly. Nester tries his hand at it, and he gets it to sink the old fashioned way. Next there's classified information, and here's the reason this is my first issue of Nintendo Power. I didn't even own an NES, but my best friend down the road did, and he showed me this chart from Mega Man 3 that demonstrates the number of hits it takes for every boss weapon to defeat each boss. I was so blown away by this as a kid that I just had to own it for myself. It's weird to say, but it's this little chart that really got me into video games because it proved to me that there was a real science behind the game. You weren't just running to the right and shooting stuff, there was real strategy and planning and forethought. So as a result, Mega Man 3 became my first favorite game ever, and I'd bug my friend to rent it all the time. So yeah, I made my dad go to Sears and buy the specific issue for me, but that wasn't enough. In the meantime, I had to copy the chart down in my notebook. There's also a tip here to have Mega Man avoid death after falling into a pit by holding right on the second controller and pressing jump on the first controller as soon as your life bar goes black. Or as I say in my notebook here, take a mega leap super jump out of pits. There's also passwords for Silver Surfer, extra lives for Turtles 2 the arcade game, a continue code for Nark, and hidden items in Shadow of the Ninja. There's also a classic code section here for older games, which is a nice touch. This month's poster is for Battletoads. I covered the issue that goes over that game a few months back. Now playing goes over Bandit Kings of Ancient China, Times of Lore, Indiana Jones and the Last Crusade, War on Wheels, Kicks, and WWF WrestleMania Challenge. Strategy action puzzles, wrestling and roller skating, you can't get much more variety than that. NES achievers features one poor soul who finished Kid Cool. I wonder if there's any residual damage that dude still feels today. There's no contest this month, instead it's the 1990 Nintendo Power Awards for best graphics and sound, theme and fun, challenge, play control, best hero, best bad guy, most innovative, best co-op games, and the best overall games for Game Boy and NES. I'm not going to read through the nominees on each of these because it'll take too long, but you can pause the video on each spot so you can see them for yourself. I will say it's funny to see NES play action football in the same category as all time great stuff like Castlevania III, Super C, and Mario 3. Counselor's Corner has some questions about Mega Man 3, like how to defeat the infamous Rock Monster, some questions about Maniac Mansion, like how to get out of the dungeon, some more questions about Dragon Warrior 2, and one for Shadow of the Ninja. Here's a shot at this month's counselors, including this dude, who says he beat Ninja Gaiden and Ninja Gaiden 2 in two hours. This month's top 30 has Mario 3 at the top, of course, but rounding out the top three are Final Fantasy and Crystallis, which is a bit of a surprise. We've also got all three Mega Man games on here as well, it's quite a prestigious honor. The celebrity profile is Rain Pryor, otherwise known as TJ on the old sitcom Head of the Class.  Pac-Watch talks about Powerblade, which ends up on the cover of Next Month's Issue, Euphoria, Tailspin, and Star Wars. We also have a quick feature on Howard Phillips visiting the Consumer Electronics Show, where he got to see the Ultimate Warrior without face paint, and among other things that are on the way like this thing called the Super Famicom. Hmm, in fact on the next page we get our first look at stuff like Actraiser, Gradius III, Bombuzal, or what later became known as Kablui, Ultraman, and Street Fighter, with the screenshot clearly being Final Fight. Another interesting bit here in the coming soon section is that they mention Earthbound. I know they were planning on localizing Mother for NES, but I didn't realize they were planning on calling it Earthbound. Alright, let's move on to the main features. We've got 12 pages here on Metal Storm going over each special weapon, and the M308 Gravity Control Device so you can flip upside down. It's all pretty straightforward stuff here, no read between the lines comments or anything like that, but it's all really well done. If you like this game you gotta get this issue. Next in kind of an odd twist is a gigantic 20 page feature on Star Tropics, which is weird because that's the game that was on the cover of the last issue. I guess they only cover the first two areas in that issue and save the rest of the game for this one, but yeah the maps here are really useful and help make some of the dungeons less painful to get through. There's also rundowns of Adventure Island 2, GI Joe, and Princess Tomato in the Salad Kingdom. Dang, put those three with Metal Storm and Star Tropics and that's a really good group of games right there. The Game Boy section covers Operation C, the third Contra game that's one of the best games you can find for the original Game Boy. I did a video on that one a long time ago, and there's also a Boy in His Blob. I didn't even know this one got a Game Boy release. The Game Boy's classified info section goes over Power Mission, Fortress of Fear, Boomer's Adventure in Asthmik World, Castlevania the Adventure, and an Infinite Livestrick in DuckTales which is pretty cool. It works the same way as the NES game. Now playing for the Game Boy covers Solomon's Club, a follow up to Solomon's Key, and Roland's Curse, a pretty cool looking top down adventure title. For the Game Boy Top 10, Super Mario Land takes the top spot, and there's not much else notable here. Last but not least we have a really interesting feature looking inside the guts of both the NES and the Game Boy. When I was a kid I would just flip past this because it was way over my head, but reading it now they did a really nice job explaining all this stuff in layman's terms. They go over the function of the 72 pin connector and the RF modulator, explaining how the ladder translates the composite video signal to the TV. They even talk about the shift register and the controller and how it communicates with the Control Deck's CPU. They have a nice analogy here to explain how the CPU works too, saying that the game cartridge is basically a cookbook and the CPU is the cook who follows the recipe, although in this case it's making every single recipe in that cookbook at once. They continue to talk about how the Mario sprite is made up of 8 different characters and that every screen has 960 different characters at once. It also briefly goes over how a game can scroll and RF transmission versus an RGB signal. Finally we take a look at the guts of the Game Boy and they keep it pretty simple here talking about how the LCD screen works by reflected light. The darker the area on the screen the more electrical current is flowing through that area so less light can be reflected creating a darker image. Whew man that is a lot crammed into one issue and that's how great Nintendo Power was back in the day, but yeah I want to thank you for watching and have a good rest of your day.


You're in the wrong room, but we're happy to see you anyway I'm Brad geesterman my pronouns are he him and I'm a staff security engineer at ghost security And I enjoy hacking cloud and kubernetes with my friends here. I'm Ian cold water pronouns. They them I'm an independent security researcher a long-time community organizer and SIG security co-chair I love hacking weird machines and bringing people together and I'm looking for work if you're hiring Hi, everyone. My name is Rory McCune my pronouns are he him I'm a senior security advocate with data dog and I like to learn about security and write blogs Hey, everybody. I'm Duffy Cooley. I'm the field CTO at ice availing where I get to work on things like zilliam and tetragon and EBPF I'm excited to be here with all of you in person and I'm especially excited that we are all here finally all those all together on the same stage I'm gonna go drive this over here So SIGHawk isn't an official kubernetes SIG We're a hacker crew who have been poking at kubernetes for years And we work together to share attacker perspectives and help the whole community level up. So, why are we here today? We have a question for all of you real quick Who here has ever heard of containers? Of it we had a feeling By another show of hands who here has ever used a container vulnerability scanner before Wow, okay, great. Perfect So one thing you might have noticed is that governments auditors and your security teams are asking you to scan all of your container images for vulnerabilities so that you're more secure But we don't hear as much about the details and as it turns out the details are important So what do containers scanners actually do and what problems do they solve and how do container scanners work? Are they all the same? Can you always trust the results? Let's find out In this talk we'll be mainly for covering four widely used container scanners We chose trivy gripe docker scan and docker scout to test But what we'll be covering here isn't necessarily limited to those four as of april 13th of this year Docker scan has been deprecated to be replaced by docker scout Docker scan is powered by sneak on the back end which we thought was interesting and a lot of people still use it So we figured we'd still include it here today So to start let's use all four of these scanners to scan a vulnerable container image we created and see what results we get So let's show the versions Of each of the scanners that we're using today just for posterity So we have trivy gripe docker scan and docker scout So let's cap our base docker file As you can see we're using a slightly old base image. It's a composer 1.72 So it's got a couple of vulnerabilities. We know that that are in there and it's based on alpine 3.7 The next thing we're going to do is install no j s Then we're going to copy in some runtime dependency files So things like gem file lock package json yarn dot lock, etc And lastly at the bottom you'll see we copy in cube control. It's relatively recent, but it's not quite up to date and that's a go binary So let's quickly build the base image And scan that scan the image with trivy gripe docker scan and docker scout Let's check check the results in the summary format There we got some findings But let's see that on a graphical display So this is our baseline set of results and immediately we can see that the four different scanners trained on the same image Produced wildly different numbers of results. Why is that? Well, it turns out they don't always work the same way. Let's break it down a little bit So how do you can container vulnerability scanners work? Is it magic pixie dust? Now they work on a combination of several techniques that we'll have a look through now So files that hold operating system version metadata and release information like etsy os release etsy lsb release And etsy alpine release are typically one of the first things scanners look to to help inform them For their approach to scanning the rest of the base image From there container scanners also flag up outdated versions of packages provided by your linux distribution This is based on the scanner using the package database that's installed by the distribution And the security database that contains vulnerability information One thing that's worth being aware of is that in some cases there are os package vulnerabilities for which there is no available patch And the scanner can be told to either report them or not depending on your risk appetite And another thing to think about here is this means the scanner needs to understand the package database for your distribution So if you use a new or a niche distribution, it might not be supported Some of these scanners also lift for software language dependency files such as package dot json requirements dot text or cargo dot lock This use of the word cargo has not been endorsed by the rust foundation These files contain information related to libraries and metadata, which the scanners use to find vulnerabilities in software dependencies Another thing that some scanners look for is any metadata embedded in binaries Go lang since 117 embeds dependency data inside of the go binary and rush binaries can be scanned in the same way So now that we've talked about how these tools come up with findings Let's go back and look a little bit closer at our base image one more time the results So looking at the results again, you can see that we've broken them up into three different classes of finding os package dependency file and binary metadata And you can see that the numbers found per category for each individual scanner are wildly different as well as the total numbers of results I mean, that's a lot of findings There's at least 90 or more results that that we have to go through and fixing all of them is going to take a really long time To be fair some of these specific findings could likely be resolved by updating our base image Since we used an older one on purpose for the purposes of demonstration, but it's not always that simple Many of these findings are related to dependencies in the software itself And this can create compounding issues updating dependencies can change the software Can change the software's behavior and it may need to be modified to handle the change in dependencies And it's not just the one time fix we have to deal with this every time we have to update dependencies every time There's a new base image every time new cvs are learned about There's just a ton of things that can actually trigger having to go back through this And if this base image is actually from a vendor fixing it may not even be an option Okay, so let's say that we're the team who's responsible for this image And it's currently deployed as a core component in our production environment right now The security team just sent us these scan results And now we can't ship again until they're fixed Fixing all the findings that were raised means updating several components and maybe retesting our entire application So we're taking a risk of breaking production just by trying to do the right thing and actually fix them And that brings us to a choice What do we do about this? If we fix all of these findings to be compliant, we'll miss our deadline If we ship on time without fixing them, we'll get into trouble with the auditors None of those options are very good. There's got to be a better way So we need to address these scan results to be compliant, but That sounds like a lot of work Is there something we can do to just make the findings go away? I have an idea Now that we know what the scanners are looking for let's use a systematic approach To see if we can hide or bypass detection for every single finding for all of the scanners with no breaking changes to our containerized application If we can do that The next scan results will be compliant. Our app will still work and we can still ship it and make our deadline So remember when we said that the scanners can use the os release information to figure out which operating system version the image Is based on and that can how that can guide their approach to scanning the image What if we remain at report that it was an operating system the inversion the scanners had never seen before By changing the name and just deleting that information entirely Let's see what would happen So we're going to take that same original docker file We're going to change a couple things First thing we're going to do is make it look like it's our own custom distribution of linux and overwriting at the os release Then we're going to delete at the lsb release and at the alpine release just to make sure it doesn't get confused Okay, so let's rescan the image First we have to build it. Sorry so we can incorporate all those changes We're going to rescan the image Trivy right docker scan and docker scout Let's take a look at the results Interesting some things have changed here All right, let's go back to the graph. So it's a little bit easier to see We can now see that docker scan and docker scout Immediately stopped reporting operating system package issues. I mean that's pretty wild, right? All from just changing or removing a couple of files All right, that's pretty sweet clearly things have been improved, but I think we can do better That one took care of those findings from docker scan and docker scout But can we get the other scanners to no longer see findings from os packages either? So if changing or deleting the os release metadata work before We should also try to get rid of the os packaging metadata for the installed operating system packages That shouldn't have any effect on our application working, but it will prevent the scanners from seeing that information So What we're going to do is we're going to go back into our docker file and we're going to make another change We're going to delete the alpine os package metadata So down the bottom What you can see here is we've got a couple of lines that just do an rm minus rf on etc apk and lib apk Which is where that data lives Then what we'll do is we'll rebuild our image again because we need to make sure we're getting the latest version And that'll go away and do it and then what we've done now is we can now recap run our scanners so We'll scan the image with trivia with gripe with docker scan and with docker scout Let's see what kind of effect that change had Wow, if you look at that left column there, which is os packages. That's fantastic. We don't have any vulnerabilities anymore So that's a great change Let's look at them in graphical format So this is how many we started out with to remind everybody and this is how many we've got now So now all four scanners no longer show any os package vulnerability findings, but let's be clear The results are gone, but we didn't actually uninstall any packages. They're still in the image It looks to me like we're still seeing results from some of the scanners relating to software dependency files Like gem locks and those sorts of things. So our next stop should probably be to try and get rid of those So we know the scanners are looking for specific files with specific file names that hold software dependencies Used by languages like javascript python ruby and others So how are the scanners going about looking for those? Are they just looking for the file names because if so I wonder if they would try to follow a sim link In order for our application in this image to still work We can't change the names of files like package dot json and gem file dot lock But what if we renamed the files themselves to something else and then made sim links to them with the original names? Let's try it So we're going to take that original docker file But this time we're going to copy in all of those files with a different name Then we're going to make sim links to link them to the original file name So that when the application tries to look for a file like package dot json It just follows the sim link to the renamed file and the app will still work We also went ahead and deleted some python egg info metadata files because we don't really need them. So why not? So let's build that modified image now. Let's scan it with all four scanners again Let's take a look at the results. So to reiterate, we haven't actually deleted anything We've just made the scanners not see it anymore But let's take a look at these results again in graphical form That's all right. It's fine. It's all fine. Okay Again reminder, this is how many we started out with in the first place and this is how many we've got now It's clear that the scanners do not always follow the sim links And that made them find not not find any issues in the software dependency files And you know, this kind of makes sense Sim links have a rich history of being tricky to get right For a good example of that you can actually see our previous talk about kubelet vulnerabilities A slightly peculiar volume configuration from kubekan na 2021 All right, so it looks like we still have a few findings left and they're all related issues with binaries Ah, remember that in some in binaries the metadata can be embedded inside of it So I wonder how we can get the scanner to not see that stuff. What can we do about all of these binaries? Have you ever heard about upx packing? It's a way of compressing binaries and it also happens to obfuscate the internal structure of the binary itself This makes it very useful for things like making binaries smaller and Avoiding malware detection So let's see what happens if we upx pack all of the binaries So let's modify the docker file again We're installing upx as a package so we can pack some of these binaries and apply that same sim link and rename technique against one of the python shared libraries And we're going to pack both kubectl and busybox To see if that gets rid of all the binary issues So let's build that modified image again Now we're going to rescan the image with all four scanners And then let's check out the results. That was very effective Mostly, but we still have a few findings left. Let's take a look at that graph again Again, this is the original amount that we had And this is how many we have now There's still more to unpack here Three of them are still finding issues with the golang binary kubectl That's interesting though because that should have gotten rid of all the findings, right? Well, one thing we do know is the container images are built of layers. Perhaps we're looking in the layers Right, but is there some way to make it so the scanners can't see all the layers? I mean we are shooting for a hundred percent compliance, right? I mean we could try a multi-stage build. Let's try that So we're going to edit our docker file one more time And we can see that this docker file is a bit of a mess There's lots and lots of things that we're doing here lots and lots of layers that we're adding And lots of layers also that we're inheriting from the composer image as well So he'll be here at the top. I've just decided to call all of this work as builder And here down at the bottom. I've got my from scratch and copy two lines So we're going to go ahead and separate those build and the obfuscation steps and the final packaging steps And we are also going to copy in an icar sample test file into the image overriding bin bash And we'll talk a little bit more about that later. Where is that line? Here we go So that's where we're copying it in We're going to talk about that here a little bit later. So All of when we do this when we do this step of actually A multi-stage build we end up with a single layer image. That is the artifact that we're going to ship And this will result in a couple of interesting things When we build this new modified image and we compare the size against the previous one We can see that the old one was 306 meg And this new one Is 166 meg so big win right easier to distribute all that stuff. It's good stuff Our image is a bit smaller and any image that uses this one might also make make get benefit from some of the modifications that we've made So let's go ahead and re-scan these things And see what we see here view the results So let's put that back in the graph for him. That's where we started How it started How it's going And we did it. We are completely 100 compliant. I mean we haven't changed anything about this image I mean other than like how we build it and that sort of stuff So all of those findings in the first graph are all still in there. They're just not alerting anymore Okay, so this is exciting. We've managed to get to zero findings on this old image just by taking things out But how about adding stuff in could we sneak anything malicious in there and still be compliant? Well, we already did None of these scanners picked up the addition of icar because none of these scanners are going to look for malware or file changes If we want something that might pick back on the thing up, we might need to use a different approach What about something that generated an inventory of all software and dependencies in the image? Like an sbomb The white house and other governments have said that we all need to use sbombs to know everything that's in our software So sbomb stands for software bill of materials Which at a high level is a document often json formatted with a goal of telling users What's in their software or in our case a container image? So surely an sbomb would have to show us if there was something malicious that had been added to our container, right? Well, let's find out We can use trivia and sift to generate some sbombs for our images And then use trivia and gripe to scan those sbomb documents for vulnerability results Sbombs have a couple of different formats, but in this demo, we're going to be using these tools to output them in spdx json So let's go ahead And generate sbombs for the original base image our starting image and our multi-stage build image We're going to use trivy And sift and sift and gripe work together. They're both made by encor So sift generates the sbomb and gripe scans that sbomb But trivy scans trivy So let's look at our sbomb results And right away you can see something's up because in our base images the file sizes are quite large And in our multi-stage build images those files are kind of tiny So let's dive into those So if we look at the sift sbomb for the original base image We can see this is the spdx format by the way. It's just a lot of json. So if you love json You can see it captures all the packages, right? They're all there And captures some of the files Including bin bash, but you remember we copied icar on top of bin bash But what do we see for the shahash all zeros? That's interesting, right? So let's look at trivy's sbomb for the original base image And as you can see similar format spdx, but There's only one file shown and all of that metadata is in the packages So right away you can tell that they're not quite exactly right and not quite uh compatible And lastly we'll look at trivy's sbomb for that multi-stage build image the one that we had zero findings for And this is how long that document is That's it. That's the final sbomb So if we look at a trivy sbomb generated for the multi-stage build you can see that's pretty light And there aren't a lot of results there which is incredibly interesting But did it pick up anything malicious of ours? As it turns out All the same obfuscation techniques still work to hide the findings from being reported from the sbombs So all that work worked And again, we still haven't changed anything about the software in our image And this really calls out how important it is to understand how these tools work This sbomb records that there are no vulnerabilities in the image and we've shown you that that's not true Which doesn't stop this image and the associated sbomb for being considered compliant A few of these techniques are legitimate things that probably some of you have used during to manage the life cycle of your images in the past I mean who hasn't built a multi-stage build at this point? You probably you perhaps did not know that you were being maliciously compliant at the time and this stuff is hard And even it is compliant. It's definitely not secure The demo gods are not smiling upon us today. So we're going to go backwards one slide So what interesting thing we found is that the results are not always consistent Between when some of these scanners scan images directly and when they scan sbombs generated from the same images Let's demonstrate So here are the results of trivys original scan of the original base image again And now we're going to scan the sbomb documents. We generated before with trivy So let's scan the sbombs trivy generated for the original base image And our multi-stage build which had no issues Okay, fair enough The trivy stands are consistent with the prior results when we scan not only directly with trivy but with the sbomb document The original image has the same number of findings and the sbomb is still being fooled by the multi-stage image We built which of course has no vulnerabilities at all Let's look at the original gripe scan results From when gripe scanned our original images directly Okay And then let's scan them again with the sbomb results that were generated by gripe's partner tool sift These two tools are designed to work together. They're made by the same vendor. This is a feature that's advertised So we're going to scan the sip generated sbomb for both our original base and our multi-stage build images with gripe As you can see, they're not at all the same not even a little bit That's weird, right? You would think they would be consistent, but they're not The number of findings gripe finds from the sbomb generated by sift is totally different from when it scanned the original base image By itself directly that said the whole thing is still fooled by our zero finding multi-stage build image Because as you can see this image has no vulnerabilities at all So looking at the results of the sbomb scans, we obviously got some surprises there for a few reasons We would expect it to get the same number of vulnerability results from scanning an image directly or scanning an sbomb of that image But that wasn't always the case But also if I expected to have some indication that a file had been overwritten We expected that the sbomb would include metadata for every single file perhaps in the form of a hash But when we were but when reviewing different sbombs, we found that not all of them do that Another surprising thing we found is that although these tools allegedly produce an sbomb in the same format Like spdx there is no defined standard for how that format gets implemented So these tools and documents aren't interoperable If you use one of these tools to generate an sbomb document and feed it into another one of these tools For example, generate an sbomb with trivy and have gripe scan it or the other way around with sift It leads to unexpected results or frankly no results at all It's even inconsistent when they come from the same vendor which was surprising too So we've shown that sbombs don't capture everything in the image And we've seen enough interesting behaviors here to suggest that there's more to dig into Sbombs clearly need more research We don't have time to cover it all in this talk today, but we have a lot to say So stay tuned coming soon to a kubecon near you So what can we learn from all this? We've shown that image scanning and sbomb generation tools are quite sensitive to the changes where the metadata from where they get their results The quality of those results is also directly related to the quality of all of the steps involved in how the image is built And you can't always determine just by looking at the output that something is off It's one of these tools generally tend to fail in a way that is pretty opaque So if you can manipulate the results of these findings, this has potentially significant downstream effects And it doesn't even have to be done on purpose Inconsistent results from these tools or their lack of interoperability can cause problems for organizations Where different groups use different tools for vulnerability assessment Many organizations, perhaps maybe even yours have siloed teams that use different tools and maybe don't communicate very well with each other If you can't always count on consistent results It's really hard to know who or what to rely on Yeah, for example Many organizations use vulnerability scanning results when determining which workloads to admit to their production environments So if the results can't be trusted that could be a big problem So here are some things that we think these tools could do better to prevent against attacks like this One of them is to provide a more restrictive mode where detection coverage is the focus and at the expense perhaps of performance Following things like sim links throwing warnings and errors for clearly anomalous configurations Like you found a bunch of files that you can't associate with packages or a particular copy step A scan that returns no results can be a false negative And it causes these tools to fail successfully as we've shown you in this case Defining a consistent standard for using the same fields in generated espom document formats across tooling could help these tools become more Interoperable and could help their results become more consistent While we realize that many vendors might not have a lot of incentives to collaborate with their competition It would make it easier for everybody's users of these tools to trust their results Also, we've only scratched the surface of potentially malicious techniques So over time it would help if the tool makers adopt a more adversarial approach thinking about how people like us are going to try and bypass them So you're watching this and you're like, okay. Well, that was all cool, but I'm not involved in the development of these tools So what can I do about this? One recommendation check for unusual behavior What are you expecting to see in your environment?  Everyone's going to have different answers to this because everyone's environment is different. Do you know your environment? If you don't starting to do that would be a good first step If you do know what to look for are you expecting to have zero cvs as a result? Are you expecting to have upx packing or sim links in your build process? If not, that's weird and you should probably go check out what's going on You can and should validate all of the inputs and processes for how you build container images to ensure that they are following your policies for what a well formed artifact might look like So that they can be observed correctly by these tools And compliance teams who use these results to assess the security of third party software That they should be using should pay attention to what's in the image not necessarily just the output of the tools Yeah So when implementing these scanning tools and ci pipelines to enforce policies that block image builds or gate deployments just based on the results It's important to consider what is being asked of the folks who build and maintain these images As the number of images grows the number of scans and results needing resolution increases exponentially So this directly translates to extra work and development friction for those image builders Which can cause an adversarial relationship to develop with those security teams And that might be enough motivation to make it so that they choose the approach of malicious compliance like we did today We're all in this together And ideally teams are working with one another to achieve larger goals So let's talk about that. What are those goals? What problem are you trying to solve? A lot of toil can be reduced by considering your threat model and how these tools fit into it If you can make policy decisions strategically based on that your work will be much more effective This will look a little bit different for everybody because everyone's threat model is different But if you can place the results of these tools into that context, whatever that context may be That will help In some cases it might be helpful to consider whether or not the problem you're trying to solve can be solved by these tools at all And I think it's really important to understand what these tools do And what they don't do and how they work They're not magic boxes. They're pieces of software and they work in relatively predictable ways When you understand more about how they work, it helps a lot when you try and understand where and why they fail And how you can best use them Another thing that I think all of this shows is the importance of trust in the supply chain You know what quote I like about trust is a trusted person is someone who has the power to betray you Tools like scanners and s bombs assume that you can trust the entity that generated them And they really can't help you if the people that generated them turn out to be malicious or if they just didn't do things right I spent a ton of effort lately in the tooling To define and improve the security of your infrastructure and supply chains But it seems like there's still quite a lot of work left for the adopters to figure out how to get all of these things to work for themselves We are often incentivized to be compliant, but not necessarily secure And these maligned incentives can make it easier to choose the path of malicious compliance When what we really need to do is choose the path of security Security might be the harder path, but it's the right one and it's one that we can all walk together The effort to improve the security of images and artifacts in our environments is something that each of us has a hand in So let's go make things more secure together Oh and uh one more thing Thank you all so much for coming everybody Here are some links for the repo and base image for our demos if you want to play along at home As well as some references that we think might be of interest If you scan this goosey qr code in the corner that goes to giving us feedback on this talk We'd love to hear from you and if you're in this room Don't leave because immediately after ours is b corbsis talk on pod security admission And I know for a fact that one is going to be a great time So thank you all so much for coming come find us if you want stickers because we have them. Thank you Thank you everybody appreciate it