injection on a modern multi-core system. It's going to be awesome, by the way. We've got some hardware here. So take it away, Sergei and Ronan. Oh, cool. Great. That's my mic work. Can you hear me? No? Great. Thank you very much. It is very nice to be here first times at MCH. It was a lot of fun. Thank you for coming on Sunday, hot night. We're going to talk about fault injection and we're going to talk about modern hardware, how fault injection works, and what is fault injection. So all that, we're going to talk in a minute who we are. We work at RISCure. My name is Sergei. I like software, hardware, playing with things. And yeah. And with me, Ronan, today. Work at RISCure for a number of years now.  Everything. Okay. So before we go into what is fault injection or what is modern SOC or does it work, we first talk about physical attacks a tiny bit. So what are physical attacks? Imagine you have a device, you have it in your hands, you can do whatever with it. You can take it to the lab, you can hook in any hardware, you can put a scope to it, you could do anything with it. And you want something from this device. So for example, there are some secret vendor keys and you want to get them. Maybe it's illegal, not talking about legality of things. Let's say you really have to get them. Or there are user keys.  And for these things, fault injection or physical attacks in general are quite useful. Another use case is getting firmware. These days, often maybe if you're networking, you can see that a lot of OTA updates, they're encrypted. You cannot easily just see what the update is or what kind of code is running on the device. So having the device in your hands and doing physical attacks can give you these secrets or giving you the firmware with the transfer device to other attacks you want to do in the future. So that's why physical attacks are quite relevant to a number of different devices. There are two main types of physical attacks when we talk about it. There is on the left, side channel analysis. This is passive attack. So we don't really affect the target that much. We try to avoid that. We want to make sure that the target operates normally and we observe all kind of side channels. So not the output the target produces, but the data you can get. Maybe you can see the power trace or you can see the scope data. You can see EM produced by the target and so on. So this is one type. We're not going to talk about it. We're going to talk about fault injection or also known as glitching. So that's the moment when you want to make sure that the target you have does not behave as it should. So you try to introduce a fault. And hopefully bypass some security features of the device. So yeah, what are the types of fault injection? When we talk about it, there are different types. There is quite a bit of literature on this. A number of presentations talking about different possible fault injection methods. For example, clog glitching. So you have, if you have external clog of your target, you can affect it in a way. You can affect the outputs of the target or voltage glitching. So you can disturb the voltage and observe the effects. Also another type is electromagnetic fault injection. So you introduce a pulse into the target and you try to affect it that way. Other types could be laser or even temperature in some cases. And what do we achieve by introducing glitches? So quite often what we see is that we can corrupt data. So instead of having you can think of like you have some code running on the target and there's a variable and it has some value. And instead of having that value, if we introduce the glitch in the very right moment, we can corrupt it to another value. For example, to zero or to FF or to dead beef, which would be quite rare, but nonetheless possible. So glitches are normally not fully random. We cannot just get any value when you glitch. It's often something quite specific. So for example, zeros are quite often. Another option we could corrupt an instruction. So instead of executing one instruction, we execute another one. Or as a subset, we can skip an instruction. So you have some code running. At some moment, maybe you have a new statement and if you skip this instruction, this check was not executed. And if it was security check, it might have very big effect on the security of the whole device. Just to give a bit of more intuition of why this is happening, for example, you have your device and you introduce voltage glitching. If you have your chip and you know that it's supposed to run at 1.8 volts, that's what your vendor tells you. In the data sheet, it will say it should be 1.8 volts, maybe 10% tolerance. But after that, device not supposed to operate in this range. So what happens if the attacker is changing the voltage provided to this chip for a split second? So if it happens for too long, the device likely resets. So you just disconnect and power cycle the device. But if you do it for a very short moment, you might affect the behavior of the chip. And the reason behind that is, of course, because in software, we think about binary things. We think about zero and one and nothing in between. In real life, there is a lot of different physics happening and we might misread a value, a signal which is supposed to be as 1, as zero, when we introduce a glitch or other way around. So these kind of effects are quite possible. So yeah, that kind of makes sense. It's easy to understand that, yeah, we can affect the way the chip behaves. But of course, we cannot just know what kind of code executes where. So for example, we're on our chip, this is power trace. We just measure with the scope the power consumed by the device. And we see something like that. But it's very difficult from that, map it back, even if you know the code, say, exactly there we have the if statement, which I want to skip. And this is the first problem. And the second problem, there is also quite a bit of jitter quite often on targets. So your clocks are not perfect. When it's eight megahertz, it's never exactly eight megahertz. It floats, temperature changes. So you will always fluctuate around. And for that reason, fault injection is never very rarely 100% successful. So sometimes you will be more successful sometimes less. And sometimes you need to search quite a bit of a parameter space to find this exact spot when you want to introduce the glitch. And you will have some probability. Sometimes it's very high. Sometimes it's not that high to be successful, introducing the glitch in this exact moment. So that's one of the problems you have always when you do a fault injection. That's something you have to figure out. And yeah, we're not always fully blind when we do this. So for example, this is another example. We have a power trace. We send the command. And then we introduce the glitch in the red. And then we see the power cycle. So likely what happened, the glitch was too hard and we caused the chip to reset. So and we can often see it on the scope. And we know that maybe this is too much. We need to try to be more careful to affect the chip, but not to reset the chip. And this kind of information is always useful for us. So hopefully all this makes sense. And you think, yeah, you can definitely do this in the lab when you control everything, when you know the code, when they have datasheets, when you have everything you want. But does it actually work in real life? And yeah, it definitely does. There are quite a few examples when it was used. So maybe one example of what we've done in the past is glitching Bitcoin hardware wallet. So it runs a simple microcontroller. It has a STM32 chip. And we used EM fault injection. So for this device, it was open source code. So we could look at the firmware, which is always very nice. Even when you do physical attacks with hardware, it's nice to know what software does. And the weakness was is that they have a single if statement checking is being correct. And if it's correct, allow access to the user. And for us, when we see it, we know if it can affect this if statement, we can bypass the main security feature of the device. And yeah, that was a successful attempt. You can look it up online if you're interested more in this research. So that's nice. But indeed, if you look into research, which is published like the one before, this is a STM32 simple microcontroller, which runs at 200 megahertz. There is more other research, for example, this is published at Cardis a few years ago, which started in depth a lot of different possible effects of laser fault injection on 80 mega 328p chip, which is 8 bit microcontroller from AVR, which is very simple. And this is a common situation because a lot of research focuses on simple chips, which are easy to get. So you don't want to focus on something you cannot put your hands on, you have to have it in your lap. And yeah, you rather have something simple to be able to understand what's happening. But that's why quite often, it happens that a lot of people raise a question, will it actually work on modern devices? If you have a smartphone, can you bleach that because it runs quite quickly, has lots of cores. It is quite different from microcontroller. And yeah, can we bleach when it's faster than one gigahertz? Is it even possible? Is it too fast for us to have meaningful effects on the device? And that's something we wanted to discuss in this presentation. So first of all, what's the difference between a simple microcontroller and a system on a chip like something, a main computing unit in your smartphone? Well, the difference is one of them is very simple. Another one is not so much. So there are a bunch of different features you could look at and pretty much everywhere, you can say microcontroller is just way too simple. So you have single core quite often. It is not rare to see 8-bit microcontroller. These days you can see 32-bit and more. Feature size on the silicon is also often quite much bigger than you would have on your latest smartphones. Microcontrollers are often quite generic, so you don't have a lot of specific acceleration. Sometimes you would have crypto operations implemented, but not always. And it has very simple packaging. So it's a small chip and everything is easy. With a system on chip, you often have a lot of cores. So it can be 4-8 cores. Sometimes you have clusters, you have big and little cores if you would talk about smartphone socks. And it's 64-bit most of the time. Feature size is very small. So the chips are huge. Manufacturers go a long way to make the silicon as small as possible. So it's quite different technology behind it as well. It has a lot of dedicated engines. So you have your crypto engine which does a lot of different crypto. You maybe have AI module which does a lot of AI acceleration and so on. So there's a lot of specialized hardware. And to make it even worse, often you have package on package. So you would have your chip, your CPU, and there is on top you have DDR. So you cannot easily access the chip. This is not the case in our example. But Ronan, we'll talk in a minute what exactly we've done our research on. Yeah, so Sergey has now introduced all the parts that we're interested in. Water sox, what system on chips, why are they interesting, what is fault injection, all of this sort of stuff. And can it be used in modern, fast processors and stuff? So that's what we decided to look at. And for this work, we decided to use this board that you see on the right, which is a Pine 64. It's a relatively modern system on chip. It's by a manufacturer called Allwinner. It's their A64 SOC. It runs above one gigahertz. It's multi-core. It's relatively recent. And this is basically just a single board computer. So as a Raspberry Pi, just a development board, quite cheap, quite easy to obtain. And we were able to talk publicly about this. So this fitted all the boxes for being a nice target to have a look at. So yeah, now we know what we want to glitch. How do we actually go about doing this? So this that you can see here is quite a generic EM, so electromagnetic fault injection setup. You can see the various parts here in the bottom left. This PCB with the wires coming and going is the target itself. The big yellow box that you can see above it is the EM probe, which is the thing that actually delivers the glitch. So it's just got a lot of capacitors and stuff inside it. It builds up a charge and then discharges it very quickly through a metal coil, which is situated right on top of the chip. You have this big table that it's all mounted on is basically just for moving the probe physically in space over the body of the chip. That's just very simple. It's just three motors in each of the three axes just so you can control where in space you are. On the right hand side, you can see at the bottom is an oscilloscope, which we use for debugging the setup, verifying that everything's working as expected. And the yellow thing on top of it is a spider is basically just for controlling the EMFI probe and reading data from the target itself underneath. So that basically just says, when do we want to glitch? And it controls the rest of the hardware, which is quite dumb. But yeah, so that's one of the major things with EM fault injection. It's about where specifically. So you have the chip underneath the probe. And of course, with a modern sock with any sock, different parts of it will be located in different areas on the silicon. So you might have different effects, whether you're above the CPU above the memory above what are there other components. So this allows us to yeah, control all those parameters, search through them, see where we're seeing interesting stuff. So okay, we have a target that we can control, we can run code on it, we have our setup, everything's good. The first thing we then will do is just implement a very simple piece of code. This is just something that's running on the device, which will just have two variables reading and writing from memory, one counting up one counting down to some number that we decide. And so we use very simple things like this as a very first step often to just get an idea for how powerful you need your glitch to be where in space. So where above the chip needs to be just a very core screen scan to reduce some of these parameter ranges that we're interested in. And so we run this initially for a while you can see on the left hand side, the ones highlighted in green, this just as you can see returns the up count and down count. The green ones are expected responses meaning the glitch did not affect the device at all. So you see the 50 and zero. The results you can see on the left highlighted in red are ones where we have successfully modified the code executing on the device without crashing it. So we've done a transient glitch on it. And so you can see, for example, the first one, the 51 is the up and the down. This is very likely caused by us skipping. As Sergey was talking about skipping this decrement, the decrement of the down counter. Similarly, with the 49 zero, it's skipping one of the increments of the up counter. And then you have other ones like if you know a bit of C programming, this big four billion number might seem familiar to you. It's the maximum value you can store in a 32 bit thing variable. So basically this is saying that we've modified one of the decrements to not decrement by one, but instead to decrement by three, I think it is in this case. So it just shows we can have all sorts of varied results for what we're doing. And this sort of very simple test is a nice easy way to just see where is good to glitch how powerful just to get an initial idea of the parameters that you want to use for your testing. So it might not be so easy to see here, but this is basically just a representation of the many glitching attempts we have done. The back, the darker part is just an image of the packaging of the dye itself. And we basically just divided that whole space into whatever grid size this is. And we can see all of the green spots are where we have had no effect on the device at all. So it's just returned exactly what it should return. We didn't modify anything. The pink spots, if you can see, are not so interesting. They're a different error with the setup itself rather than the device being modified. But what we're most interested in is the ones that we call a red here. So all of the ones that are red are we have changed the way the device is operating, but it is still operating in a normal way otherwise. So we've had a useful glitch without crashing the device. And yeah, generally what we're trying to do is change all of our parameters, be it where on the chip we are, how powerful we are, all the various things we ought to control to get the most reds because we generally think they're the most useful ones. The device still works, but it's done something it shouldn't have done. And all of this is just running at the default clock speed of the A64 sock we mentioned, which is 400 megahertz. Yeah, just to get an initial feeling for how the chip reacts. So then if we wanted to go into a bit more detail, which we did, to be able to see a bit more fine grained effects and just to understand things better. One of the things we did is implement what you can see on the left here is just a simple function in assembly, which will take a fixed known value that we can see up here the a five a five a five and just read it and write it to and from memory and do nothing else. So in the case where the device is operating normally, you have not done any fault injection, it will just give you back at the end that exact same a five a five, which is an arbitrary choice of constant. And then using the hardware setup we showed earlier, we will basically deliver our glitch at some point during this loop, which is just reading and writing that variable. So then what we want to see is can we affect and how can we affect the operation of the device in a way that's useful to us. Yes, so similarly to before we can see on the left, the results that we some of the results that we obtained, the normal response as I mentioned the green stuff on the top is just that a five a five a five constant. And then in the red part below we see some of the more interesting ones that we saw. So we said we were interested in seeing can we have precise single bit flips on the data that's being used or the instruction stream itself. These are sorted. This is a selection which is sorted on how often we saw the results. And all of these top five ones are single bit flips away from this a five a five constant. So you see they're all very similar, but they differ by one bit in the binary. So that is saying the data that was being read or written to memory, we have been able to modify it in only one bit. So one bit precision. But the device has not seen it. So it's still useful for us. Another result that we saw quite a bit was instead of this full a five repeated four times being returned, we would get just a single a five. And that is basically the way the arm 64 assembly is encoded. The instruction that loads the full 32 bit value versus the one that returns just a bite. They are also one single bit flip different from each other. So what we've seen there is that we can affect both the data and the instruction itself which loads the data. And then we see also on the bottom some other different results which are very hard to reason about because there's a lot of stuff going on on the chip. It could be that it's corrupted one of the addresses to somewhere random. It could be a data corruption. There's many possible explanations. And it's hard to say given the control that we have. So that shows some of the point the single bit flip stuff that we wanted to look at. And here what we're looking at is similar to the previous picture. It's just the results of each attempt overlaid on the chip body itself. I mentioned there's a number of different parameters we want to control time, space, power, etc. One of the things we are interested to look at is how the operating frequency of the underlying chip affects the ability to be able to have successful glitches on it. So what we're looking at is on the top left the current multiplier there's basically just there's an extra step in telling the chip how fast to run. So the top left is the slowest speed which is I think 140 megahertz roughly. And the bottom right is the fastest speed that we were looking at which was 1.2 gigahertz. And so we can see by the number of greens the number of reds and yellow which is not relevant for us. There is a very clear correlation between how fast the chip is running and how easy it is to have a noticeable effect on the chip without crashing it. So something that could be useful from a security point of view. Yeah, so that already shows two things we can have this nice single bit flips that we're interested in and actually possibly counterintuitively the faster it is the easier to glitch it is for some and then this just basically shows on a graph simply what we've just seen before. For each of the frequencies we were interested in there was roughly 90,000 attempts at each frequency here and you can see there's a clear correlation between the chip running faster and the chip being more susceptible to fault injection. So this just shows the same thing. So then one thing that you might think about is why why would it be that the faster you run the more easily glitched you are the more susceptible you are to fault injection. So this is one possible explanation if you see at the top is a representation of a power trace or a trace of the device when it's running at a slow speed 600 megahertz and the same operation when it's running at a faster speed 1.2 gigahertz. Obviously you can see in time and the x-axis is time in time the same operations are clearly much more compressed. So the way the hardware that we're using works is the amount of time it takes for the coil to discharge fully so to deliver the glitch that is fixed that's a constant. So and that's this 52 nanoseconds you see at the bottom. So you can see that as the amount of operations in that time is way higher there's way more potential chance to affect one of them because you're inducing the current while all this is happening. The more things that are happening the more chance there is something can go wrong. This is a very hand wavy explanation but it's one that's quite easy to understand. So that's one of the explanations. And yeah so we've seen for fault injection we can do it. We can affect all sorts of codes sometimes security sensitive code. So naturally you might ask how can you defend against this because even with perfectly programmed software you can still introduce faults which can introduce bugs. So yeah there's some stuff that you can do in the hardware itself so bake into the silicon of the sock. So these hardware sensors you can do things like detect when you're operating outside of your normal voltage range that you expect and if you see that you're outside of that reset the chip or stop executing so stuff like brownout detection as well. For laser fault injection that Sergei mentioned earlier you're shining a laser onto the chip. You can also have light sensors in the silicon itself which detect if I'm seeing too much too many photons like too much light at this point in time at this point in space then yeah reset do something like that. So this that's at a hardware level at a software level you can also follow various like programming practices patterns to defeat to make these sorts of attacks harder. Some of them for example this random delays as Sergei mentioned there's there can be jitter there can be all sorts of changes in the timing of the program which you as an attacker need to be able to precisely say I want to go here if you start introducing just random delay loops that changes where in time the interesting operations are. So that's one you can do redundant computations so do the same computation twice if you see a differing result and that means likely there's something has gone wrong be a fault injection be a whatever and then again early out. You can do stuff like control flow integrity checking so just making sure you are executing in the order you believe you should be executing in and you're getting functions called for example from the place that you think they should be called. And then there's also some other stuff about using certain whenever you need magic values true false using ones that are hard to flip using fault injection so hard to turn from one to the other. And yeah so everything we've shown so far is very in a controlled environment we have full code execution on the development board we have all this nice fancy equipment that's precise and expensive and everything. But then it comes to the question so how about when you want to do that on the cheap how about when you want to have some fun and not need expensive equipment can we still do this sort of stuff. And that's what Sergei is going to tell you about. Yeah so for the demo we thought about bringing our setup from the lab show you how it's done. Tiny problem with going to mch with the equipment from the lab there was 100% chance we're going to spill beer on it somewhere in our tent. So we didn't do that. But we still wanted to show how glitching could be done. So here's Nils our colleague he brought his equipment. This is hobbyist tool picker MP a similar idea. So you also have a coil you can see the bottom and you can introduce a glitch also you have glitch and we got this nice page from the organizers which can run a lot of different software and we thought and it has a lot of different chips if you looked at the schematics or at least at the back of the chip there's a lot of different stuff so we thought it might be fun to try it. And so what Nils did the first day he got it he wanted to try he looked at this picker chip and it controls a few things for example the backlight of the screen and that's a bit of a video if it works we can show you. Yeah it works. So yeah you can see the coil in the lab we use a nice XYZ station with a micrometer precision here Nils has a nanometer precision and he can put the coil exactly in the spots to be close enough to the picker chip and you can see the screen here he presses the button he introduces the glitch and the backlight so the chip likely resets and yeah it just the light is goes off and on. There are also some other effect you can see it shows restarting or some other things so yeah we can affect the chip it's not very nice glitch it unlikely as an attacker you really want it to come close to the user press the button and make sure he is backlight doesn't work but yeah it's it's a something we can do here we thought maybe there is something else and graphic we could show on the badge is nice target for us so we found this nice app great to have a lot of different ones it says it runs on FPGA so there's also a PGA chip on the target it's Mandelbrot it shows you these two nice sets you can with a button switch between those two so you click the button have that one you click the button again you go back to the original screen so these two screens you're supposed to have and nothing else should happen well you can zoom in and out but that's it so we started to glitch first of course FPGA chip is on top a nice target when we get close to it it resets we can see that the screen is just the graphics goes back to the original position so to the screen so if you zoom in and out or move around and glitch the chip it will just reset back to this so we glitched around what often also happens with fault injection instead of targeting the chip itself you often can for example introduce a glitch in a capacitor next to it and affected through the voltage introducing first EM and then causing voltage change in the capacitor so we found that if we target this area marked in red we can really affect the chip and get different outputs then Nils looked it up in the schematics it was very nice from organizers also to our open source everything on github so we could see that this is voltage regulator which produces a 1.2 volts which eventually goes into the FPGA board so that's plausible we hit the voltage regulator and something happens with the FPGA with the graphics so what did we get this one was one of the first glitches this is totally not what you're supposed to see so what you're supposed to see you remember those two and that's the output and the interesting thing is we could affect the chip we get totally different graphics on the output the chip still runs perfectly and these features of switching the graphics the Mandelbrot set and zooming in and out still works so the chip operates perfectly we can do operations on this and get different graphics and there are a few others which are totally different but also very different from what you expected to see on the screen so you see this is zoomed in zoomed out and this is zooming in big back and it works we could also once get this glitch which is totally what you not expect from a recursive Mandelbrot set just covered the whole screen with some ASCII graphics and finally an interesting glitch we got this morning is this this is totally not what you expect we don't press any buttons we glitched it once and it just started to alternate between these two pictures back and forth again and again so that's more or less what we've done being here some takeaways so first of all physical attacks if you write software it is quite often overpowered you can do so many things it's so difficult to protect attacker can often put much more effort into trying to break your device another thing which you learned modern socks they are not much less vulnerable the hardware itself there is still hardware attacks which apply to it and even if you run very fast and as we showed sometimes it can be even easier affected so you have smaller feature size you have tiny transistors you have huge frequencies which are crazy and yeah we can corrupt a lot of things running the device and the very important the last point official mch page is susceptible to fault injection so maybe something for the next time to improve if that's the attacker model thank you very much we still have some time so we can try to fail miserably and trying to show one of those glitches you can see we have it here on stage thank you thank you very much if it actually works though okay it still runs I can maybe show you how it's supposed to work if I'm careful enough so you have these buttons you can zoom in zoom out if you can try this app so you can see something like this on the device so if we try to glitch it first I will target it's on the back then yeah so I can show you for example the backlight if I'm successful yeah oh no so normally it doesn't happen this time we turned off the so I glitched the Pikachu and it's supposed to reset and we lose the backlight and go back on now it's persistent so if we're lucky yes so I reset now by disconnecting the wire and it goes back in and everything works and just to maybe quickly say something about the hardware this is very similar to what we described this is just a battery pack this Raspberry Pi is for controlling the logic this is the coil it just builds up a charge in here and just discharges it very quickly through that coil right beside the chip itself and that's how you're introducing the fault okay and so the first attempt was not an awesome demo we got the persistent glitch now we'll try maybe for lucky and find the spot I'm now focusing on the regulator trying to be very careful moving tiny bit at a time ideally it would be few micrometers yes and it's worth mentioning that in practice when we're doing projects and stuff we have all of this automated so that's why we have all this fancy XY stage and all these sorts of things if you maybe saw the glitch there is so that we can set it once and just forget it let it run collect hundreds of thousands of attempts where here we're clicking manually each time to do a glitch so slightly less optimized you could see tiny effects on the screen and this area is actually very sensitive so we can luckily if we're successful enough to get actually good glitch here but if it doesn't work in a second that's going to be it does it actually still operate it? yeah this area when it shows on the half of the screen that it blinks it's normally successful unfortunately this time we didn't get it if you want to try it out yourself when you come to us after the presentation you can see it that's why you should never do a demo it never works thank you very much and if you have any questions thank you so much we have a little bit of time for questions Q&A so if you want to ask a question there's I think it's two microphones so line up behind the microphones there so signal angels do we have any questions from the internet at all not seeing any so are there any kind of you know how these attacks can be used in the in the real world you know are there any I mean you mentioned about the Bitcoin wallet right is that you know are there other examples that you can kind of see yes it depends on the field that you're operating in but there's many examples so in the early 2000s for example when we used to have set-top boxes for getting our TV channels you would have a smart card that you'd put in and out one of the ways that if they detected a problem so if you were trying to do something malicious they would put it in a state that just sits in an infinite loop there was devices which were publicly available which you could basically just plug the smart card into it would do this sort of fault injection and it would recover the card so it would break it out of that loop so yeah you can recover a dead smart card which then you can use for piracy and other stuff there's other examples a lot of the attacks on more recent game consoles and stuff like for example Xbox 360 I think there's something with PlayStation utilize a lot of this fault injection stuff through various means thanks so we have a question yeah go ahead hello yes I was wondering how much something like ECC RAM could help prevent fault injection ECC yeah I mean it can be helpful it depends on the ECC algorithm and stuff you're using but yes if it's correcting single bit flips in RAM itself then yes it can be helpful but also some of the stuff we're talking about is in the CPU itself so in the like instruction decoding instruction fetching logic all of that so that might not be operating from DRAM itself so it wouldn't help against that but if you're trying to affect something in RAM then yes it could be helpful thank you Max is another question in the back there yeah go ahead so as we saw during the demo there is sometimes a persistent glitch is there anything you can tell about what the risk is of permanently damaging the device or corrupting data for example it is not that often if you know what you're doing and you don't short all the pins which is more mostly the reason why it gets permanent damage just with the fault injection when you introduce for example in this case emfi we've run the setup in the lab for millions of attempts and there was no permanent damage and that's quite often so you can repeat it again and again and everything works even here you see it's not really permanent just until the next reset it just ended up in a weird state so yeah it's quite rare to damage it with the em if you do voltage it's more often when you prepare the sample you're going to damage it or if you do laser you're more likely to cause the damage by the laser all right thanks thank you much so no more in the room anymore from the oh yeah is that a question no he's looking at me anymore from the internet I can't really see I think I'll take it as a no okay so I think you know this this hardware is gonna be here for a little while yeah this is the last talk this evening so if you want to come up and have a look at this after the talk I'm sure you'll be more than welcome to do oh we have a question great there even more actually thanks a lot for your talk and do you have a favorite fault injection method like personal favorite yeah there are one the reasons why you the em is because it is quite easy so we don't really need to do anything with a target we just have it as it is we don't need to decap it so there is no chemicals involved no polishing we just get it as it is and we can start leaching so we don't need to modify power and so on and that's what we often use because it's the simplicity okay it also depends a little bit on your use case what you're trying to do so for example if you're doing laser you can affect very specific things more easily like in space with voltage for example it's generally more and all or nothing but yeah as Sergei mentioned EM is often a good one because it requires no modification where the others both do but yeah different types for different desired effects okay and have you ever tried laser glitching from the back side like with infrared lasers yeah so that's mostly what we do with lasers so as I guess you know you have your polysilicon layer you have your metal layers above we will usually always go through the silicon because to that wavelength of light it's essentially invisible whereas if you were to try and come through the metal layers the laser can easily penetrate them there's a lot of scattering so it's much harder to do it's possible in some circumstances but usually it's backside okay thank you thank you another question hello I have a practical question while you still have the badge on the screen what happens if you glitch the die on the LCD controller that's the raspberry pie right no no no the LCD controller glass die in the front on the LCD itself if we just try to reach the screen itself yes I'm pretty sure nothing will happen we can easily do it yeah this green not that easily affected but you might have some effect if you're on the ribbon cable though you're inducing yeah looks there's some so on this part okay let's see if we get a success here okay there are some things yeah indeed that's great yeah another question yeah yeah so I understand that you by mapping with this XY gantry you can map map out spatially where you can position the EMF pulse to affect instructions or data but how do you synchronize sorry to interrupt you that's fine to show for a second you see it still works it shows totally what you know to expect to see here for the rest it's maybe even the switching button works if I can yeah and see this weirdness here just a practical question how do you because the pulse itself is like 52 nanoseconds or something how do you synchronize that temporally with because I assume you want to affect a specific like if there's an if sentence you want to affect that one and not the preceding and subsequent instructions how do you synchronize yep so that's a good question so I thought the slides are out there so what we will usually do in this case where we had complete control over the target the code running on it yes this this here the line that says trigger high that basically just sets one of the many GPI opens it just drives it high so from when we saw the setup earlier there was a box on the right that was controlling all the rest of the hardware that will wait until it sees that trigger and then it knows to after a fixed amount of time then you deliver the glitch yeah so in this case we can just set a GPIO so that's easy and that's fine in more complex targets and targets where we don't have control we can use other signals to trigger on so to say from this point in time wait that can be reading from an EMMC it can be some EMMination from another component it can be many different things but yeah that's the basic we find some operation something that's fixed in relation to what we want to glitch and then we just wait a certain amount of time after that and would you also use a trial and error method just like gather lots of data like wait yeah so exactly yeah that's one of the many parameters we need to optimize so we have our trigger we know when to start and then we will start randomizing how long in time we wait before we glitch and then from there we'll see oh if we wait a long time we have the desired effect if we wait a short time we don't so we know that we want to optimize towards the longer times like the longer wait times alright yeah thanks thanks question I think so we're at time in terms of the official kind of end of the presentation so if there's additional questions I think maybe we can do the kind of after the talk but I think for now we'll give another round of applause because this is amazing and thank you


First off, I'd just like to thank everybody for being here. I appreciate the opportunity to talk about my research, and God knows my friends are tired of me talking about fish farms to them now, so I'd like to thank you for that. I'm from Ontario. Aquaculture has never been something that's been a large part of my life. It occurs to the periphery of most of our mines in rural coastal communities, largely in British Columbia. But the first thing that I looked at was that graph in the very middle of my slide. Total revenue from salmon farming in Canada. And you notice it makes a real plateau at around the year 2007. That's really where I started my research. I wanted to see what the role of Canadian public policy was in the aquaculture industry, how it could support the industry, and why it is where it is today. First off, it's important to understand that aquaculture is both an intersection and a metaphor. It's occurred in the past 20 years. Expansion of aquacultures occurred more than 1,000%. It's been absolutely amazing growth before the plateau around 2007. What caused this is very interesting to note. It was advancements in antibiotics and the ability to lessen the amount of salmon that are lost with each harvest. Loss rates used to be around 25% in the 90s. Now they're down to around 1%. So it's been great development from a scientific point of view for Canadian industry. My research really led me down to the direction how science plays a role, how NGOs and third party advocacy has really changed the way policy is formated in the modern era. There's no real instance in which a minister can look to their assistants and ask for the science, the cold hard facts on an issue anymore. It just doesn't exist like that. And I think aquaculture has really taught me that there's a lot of things at play here and that there's no really right way to understand science. The way that pro and against groups for aquaculture frame their arguments is really interesting. There's the taint versus natural argument where genetically modified salmon are presented as proposing a long-term health risk to Canadians, whereas people who are supportive of the industry say this is a natural development from man's long trek out of the hunter-gatherer society. So it's just no really way to understand how science plays a role in policy formation and of course the government has their own scientists, but it's a very long and ardent, expensive project to do research. And for the past 10 years, there's been very little growth from policy and the support of this industry. And I think it's really important to know that despite what we know or what we don't know about the future, there's a lot of opportunity for growth. The top right graph there is aquaculture growth in the past 50 years. More than 50% of seaford now is produced in a farmed environment and Canada has a huge opportunity to capitalize on this. We have very good relations with the US market in which demand for seaford imports have grown threefold in the past 15 years. So I'd like to thank everybody again. And that's it.


Live from Las Vegas, it's theCUBE, covering Boomi World 2018, brought to you by Dell Boomi. Good afternoon, welcome back to theCUBE's continuing coverage of Boomi World 2018 from Las Vegas. I'm Lisa Martin with John Furrier, and we're welcoming back to theCUBE one of our alumni, Nima Baby Head of Technology Ecosystems from Pivotal. Nima, welcome back. Thank you for having me back. So Pivotal, part of the Dell technologies, part of the companies, because IPO'd recently, and I did read that of the first half of 2018, eight of the 10 tech IPOs were powered by Boomi. Well, I don't know about that specific. I know that tech IPOs are making a big comeback. We did IPO on the 20th of April, so we've passed our six month anniversary, if you can say. But it's been a distinct privilege to be part of the overall Dell family of businesses. I think what you have in Michael is a leader who, he has a specific vision, but he's left the independent operating units to work on their own, to find their path to that journey, and to help each other as brethren, as like sisters and brothers. And the fact that Pivotal is here supporting Boomi, that Boomi is within our conference of supporting, our customers that we're working together really speaks volumes. I think if you take a look at it, there's a lot of things happened this week, right? So a couple of weeks ago, IBM's acquiring Red Hat this morning, VMware is acquiring Heptio. That's a solid signal that the enterprise transformation and adoption of cloud native model is really taking off. So the new middleware is really all about the cloud native multi-glot environment. And what's interesting, I want to get your thoughts on this because, first of all, congratulations on the IPF, so we're saying Pivotal's never going to go public, and they did, you guys were spectacular, great success. But what's going on now is interesting. We're hearing here at this show, as other shows, is cloud scale and data are really at the center of this horizontally scalable cloud value proposition. Okay, great, you mentioned Kubernetes and Heptio and VMware, that's all great. The question that is, how do you compete when ecosystems become the most important thing? So you work at VMware, you're at Pivotal, down those ecosystems, Boomi's got an ecosystem. Partners, which is also suppliers and integrators. They integrate and also developers. This is a key competitive advantage. What's your take on that? So I think you touched on my point. You compete because of your ecosystem, not despite your ecosystem. We can't be a completely hegemonic like Microsoft or Cisco or Amazon can afford to be. And I don't think customers really want that. Customers actually want choice. They want the best options, but from a variety of sources. And that's why one of the reasons that we not only invest in the Dell ecosystem, but also in Pivotal's own ecosystem, is to cultivate the right technologies that will help our customers on that journey. And our philosophies always find the leaders in the quadrant, the Cadillac vendors, the Lexus vendors, onboard them. And the most important thing you can do is to ensure a pristine customer experience. We're not measuring whether feature A from one partner is better than feature B from another partner. We really don't care. What we care about is we can hand wire an automate what would have been a very manual process for customers so that let's say Bumi with Cloud Foundry works perfectly out of the box. So the customer doesn't have to go through and hire consultants and additional external resources just to figure out how two pieces of software should work together. They just should. So when they make that buying decision, they know that the day after that buying decision, everything can be installed and their developers and their app dev teams and their ops teams can be productive. So that's the power of the ecosystem. We need to talk about the relationship between Pivotal and Bumi because Bumi's been born in the cloud as a startup. Acquired eight years ago. You're part of the Dell Technologies family. VMware is VMware. We know about VMware. Doing great. You guys are doing great. Now Bumi's out there. So how do they factor into and what's the relationship you have with them? And how does that work? And how do you guys work together? Perfect question. So in my primary role at Pivotal is to manage all of our partner ecosystems specifically the technology partners. And what I look for are any force multipliers, any essentially ISVs who can help us accomplish more together than we could on our own. Bumi's a classic example of that. What do they enable? So take care of classic customer. Classic customer has let's say 100 applications in Inventory that they have built, managed and purchased, procured off from a shelf to shelf components. And roughly 20, 30% of them are newish, green field applications, perfect for the cloud native transformation. Most 80% of them or 70% are going to be older, brown field applications that will have to be refactors. But there's always going to be that 15% towards the end. It's legacy, mainframe. It can't be changed. You cannot afford to modernize it, to restructure it, to refactor it. You're going to have to leave it alone. But you'd need it. Your inventory systems are there. You're working. These are critical systems. Most people think legacy is outdated, but they're actually just valued. They're critically valuable. They just cannot be modernized. So a partner like Bumi will allow you to access the full breadth of those resources without having to change them. So I could potentially put Bumi in front of any number of older business applications and effectively modernize them by bridging those older legacy systems with the new systems that I want to build. So let's do an example. I am the Gap and I want to build a new version of our in-store procurement system that runs on my iPhone that I can just point to a garment and it will automatically put it in my checkout box. How do I do that? Well, I can build all the intelligence and I can use AI and functions and I can build everything inside of containers. That's great, but I still have to connect to the inventory system. The inventory system. Which is a database. All these systems are out there. Somewhere or something. And my developers don't know enough about that old legacy database to be able to use it. But if I put a restful interface using Bumi in front of it, and a business connector that's not older XML or kind of inflexible, whatever, solo gateways, then I have enabled my developer to actually build something that is real. That is customer focus. That is appropriate for that market. Without being hamstrung by my existing legacy infrastructure. And now my legacy infrastructure is not an anchor that's holding me back. You mentioned force multiple, Lisa. We talk about this all the time on theCUBE where that scenario is totally legit and relevant because in the old version of IT, you'd have to essentially build inventory management into the new app. You'd have to essentially kill the old to bring in the new. I think what containers and cloud native has shown is you can keep the old and sunset it if you want on your own timetable. Or keep it there and make it productive and make the data disposable. But you can bring the cool, relevant new stuff in. And I think that is what I see and we see from customers like, okay, cool, I don't have to kill the old. I've got to take care of it on my own timetable versus a complete switching cost analysis. Take down a production six times. Exactly. Build something new, will it work? You crush your fingers, okay. Again, this is a key IT different dynamic. It is. And it's a realization that there are things you can move and those are immutable. They're simply just monolithic that will never move. And you're going to work within that, those confines. You can have the best of both worlds. You can maintain your legacy applications. They're still fine. They run most of your business and still invent the new and explore new markets and new industries and new verticals and just new capabilities all through and through without having to touch in your backend systems, without having to bring the older vendors in and say, can you please modernize your stuff? Because my business is dependent and I am going to lose that. I'm going to become the new Sears. I'm going to become the new Woolworth or whoever blockbuster that has missed an opportunity to vector into a new way of delivering their services. When you're having customer conversations, I'm curious, talking with enterprise organizations who have tons of data, all the systems, including the legacy, which I'm glad that you brought up that that's not just old systems. There's a lot of business critical, mission critical applications running on them. Where do you start that conversation with a large enterprise who doesn't want to become a blockbuster to your point and going, this is the suite of applications we have. Where do we start? Talk to us about that customer journey that you help enable. Well that's great because in most cases the customers already know exactly what they want. It's not the what that you have to have the conversation on. It's the how do I get there? I know what I want. I know what I want to be. I know what I want to design. And it's how do I transform my business, fundamentally do an app transformation, enterprise transformation, digital transformation. Where do I begin? And so our perspective at Pivotal is we're die hard adopters of agile methodology. We truly, truly believe that you can be an agile development organization. We truly believe in Mark Andreessen's vision of software eating the world, which let's unpack what that means. It just means that if you're going to survive the next 10 years, you have to fundamentally become a software company, right? So look at all the companies we work with. Are you an insurance company or are you delivering an insurance product through software?  Well one's the last time you talk to a bank teller. Or the ATM, most of your banking's on online. Your computer or your mobile device. Even my check cashing. I don't have to talk to anyone, it's wonderful. Ford Motor Company. Do they bend sheet metal and put wheels on it? Or are they software company? We'll consider that your modern pickup truck has. They're an IoT company now. Yeah. All those sensors on those manufacturing lines. That's what's crazy. You have 150 million lines of code in your pickup truck.  But also data's key, I want to get your thoughts on this, this is super important. Michael Dell brought up on the keynote today here at the Boomi World was, okay, the data's going to stay in the car. I don't need to have a latency issue of, hey, I need a nanosecond results. With data, cloud has become a great use case. With multi-cloud on the horizon, some people are going to throw data in multiple clouds. And that's clear use case. Everyone kind of see the benefits of that. How do you guys look at this? Because now data needs to be addressable across horizontal systems. You mentioned the gap and gap example. That's great. So one of the biggest trends we see in data is really event string. Is the idea that the ability to generate data far out exceeds the ability to consume it. So what if we treated data as just a river?  And this is where Kafka and companies like Solace and any event-driven networks and Spring Cloud functions and Spring Cloud data are really coming into play. Is the acknowledgement that yes, we are not in a world where we can store all of the data all the time and figure out what to do with it after the fact. We need timely, and timely is within milliseconds, if not seconds, action taken on an event or a data event coming through. So why don't we modernize around that type of data structure and data event and data horizon? So that's one of the trends we see. The second is that there is no one database to rule them all anymore.  I now have MySQL and SQL and Mongo and Cassandra and Redis and any number of other databases that are form, fit and function specific for a utility and they're perfect for that. I see graph databases. I see key value stores. I see distributed data warehouses. So my options as a developer and as a user is really expanding, which means the total types of data components that I can use are also expanding exponentially. And that gives me a lot more flexibility on the types of products that I can build and the services that I can ultimately deliver the income. And that highlights microservices trend because you have now a multitude of databases, not the one database rules them all. There'll be literally thousands of database on sensors. So microservice has become the key element to connect all these systems. All of it together and microservice is really a higher level of abstraction, right? So we started with virtual machines and we went to containers and we went to functions and microservices. It's not an upward trend necessarily as it is an expansion into different ways of being able to do work. So some of my work products are going to be very, very small. They can afford to be ephemeral, but there may be many of them. How do I manage a cluster of millions of these potential workloads? Back it up, I can have ephemeral applications that run inside of containers or I can have rigid fixed applications that have to run inside of virtual machines. I'm going to have all of them. What I need is a platform that delivers all of this for me without me having to figure out how to hand wire these bits and pieces from various different, either proprietary or open source kits just to make it work. Now I'm going to need a 60 to 100 to 200 person team just to maintain this very bespoke thing that I have developed. I'll just pull it off the shelf because this is a solved problem, right? Pivotal has already solved this problem. Other companies have already solved this problem. Let me start there. And so now I'm here. I don't have to worry about all this leftover plumbing. Now I can actually build on top of my business. The analogy I'd use is you don't bring furniture with you every time you check into a hotel. And we're telling customers, no, every time you want to move to a different city just for a business meeting or for a work trip, we're going to build you a house and you need to furnish it. Well, that's ridiculous. I'm going to check into a hotel and my expectation is I can check out if any other room and they're all be the same and it really doesn't matter what floor I'm on or what room I'm in, but they'll have the same facilities, the same bed, the same, you know, restaurant facilities. That's what I want. That's what containers are. Eventually all the services surrounding that hotel room experience will be microservices. And we are the workload. The people. And we are the workload. And we are the most important thing. We are the application, you're right. I love that. That's probably the best analogy I've heard of containers. Nima, thanks so much for stopping by the Cube, joining John and me today and talking to us about what's going on with Pivotal and how you guys are really helping as part of Dell businesses dramatically transform. My pleasure. Thank you both. Thank you. Thank you for watching theCUBE. I'm Lisa Martin with John Furrier. We are in Las Vegas at Boomi World 18. Stick around, John and I will be right back with our next guest.


Right, thank you for joining the average golfer. I am here at Gull and Golf Club But I'm taking shelter in the starters also And that's before we even got to the first tee because if I do any kind of recording out there You won't hear a word I say it is I've got Alan alongside me as a starter. It's it's a bit rough, isn't it? It's breezy. It's breezy. It's a light breezy calling up here But for us, I tell you it's it's knocking you off your feet So what I'm gonna do I'll record as much footage as I can out there on the course They'll be very little talking because like I said, you just wouldn't hear a single word I say so Wish us luck Great shot from Louis to start it all off Oh, that's not a sign of things to come a lads determine today It's taking it serious today light breeze here at Gullin 278 yard par for probably gonna be about a drive in a three-wood today 40 mile an hour winds Little heavy, maybe It should have really. Yeah, it's alright for you that Right, it's a tremendous start from Louis today. This is a absolute banging drive right down the middle I don't know. We can't have a lot left Great shot pin I well done Louis is definitely concentrating on today. He's looking for revenge a Lot of focus on that face right now. He adopts the claw grip He eyes up the birdie To take a one-up lead It's swinging around By the way, so for a par of the first and a one-up lead I never in doubt good for a great start right stunning golf hole This is this is where the Scottish Open started from a bit further back than we are mine, but this hole is tough Why is it? I don't know what stroke and it's stroke and it's for I think it is but it's a tough hole Green is very long and narrow as is the fairway Louis got the honor didn't have it all day yesterday and already is keeping it and not giving it away said drifting off to the right Poor tee shot from Lewis to be fair worse. He's hitting the two days and but he landed on the Well on the green keepers pathway really He's give that a rip. I can't pick it up, but there's a green On top of that brow. That's where we're trying to get to I doubt you can hear me Just look at that view. This is a third tee and this when the course really opens up right out in front here Stunning if a little bit windy Right Louie avoided the mind you the g you are stunning piece of I just love the way these revetted bunkers are put together It's an art form. It's just going to leak out Right winds coming off that left now And it's down that right hand side It's playing it nice again. I think that's going to drift towards my ball. They're almost identical Well, Louie went big just carry through that wind So tough today so tough a little low one Least out nice Yeah, that's good. Take it away Interesting shot from Louie playing a little bit of a bump with a three wood. Maybe it is I think But the slope in front of him Is severe Go in go in I just run on him he nearly hit the flag and went in Right, so Louie for a win best I could manage was a bogey four Tough to read them and then the wind is having an effect on this honestly I can't tell you how difficult this is Right just took shelter for a minute or two and hopefully you can hear us a bit clearer We're through four holes is it level All square I can't even keep a count because honestly, it's so hard to keep your game going any kind of game because even putting Is difficult to keep everything stable as you know when you're playing these high winds It's gusty. It's gusty. He's effecting but the ball's moving I think he said 35 to 45 mile an hour gust of winds and you're so exposed out here What I want to stop and say which is about the condition of this course Gullin is absolutely it's immaculate with december Seventh seventh. It's absolutely stunning Absolutely stunning. You're talking the definition on a lynx course is not often seen But you've got sort of you know, you've got three cuts from the fairway to the first cuts into the rough greens Running pure Yeah, trust us to let them down. Well, it doesn't know whether it is hard So right back out onto the tee and we'll carry on all square It's a night perfect line perfect shot from Lou great tee shot Be interested to see this one because where we're playing it pays 436 yards. It's a par four. I told a lie there Uh stroking next one. This is going to be one heck of a long second for me The mayor's office Makes a change from yesterday I couldn't hit a barn door. I stroked next one. I think judging by the line I took them where I've now seen the green I'm probably right Uh, I was the line was wrong basically. Um, that's where you get from a errant tee shot down the left Chance for Louie. Let's turn that one over down the left Lou on it 64 There you go. Just short not bad safe play What is a tee shot? That's a tee shot This is a battle It's a battle to speak I tell you Wedge here for Lou See my ball there from left Nice shot. This is I'm going to be able to pick it up That's decent ball once again the winds turned it right over to the right hand side Well, I can't believe I had a put for par on this hole The wind is absolutely right into you Louie still got a chance to make this would be a hell of a four I might be protecting the mic a bit from the wind. It's right in my back It ain't happening this I keep saying the same thing. Let's turn it there for a little bit You might be able to hear me. I do not know tough tough tough conditions. I don't even know the match score. What's the score? I am still one up The golf is well, it's okay considering that's all I can say Right just taking shelter in the same little hut that we last spoke We just played through seven the wind off that last hole was honestly, I don't think I've ever played in conditions like it We've both had put for par which is I'm not too sure. I wouldn't make them unfortunately the game is I'm still one up somehow the golf scrappy, but To be fair, it's about as good as I would expect because it's hard to even stand up and get a swing going in Yeah, let alone a bit of a game chipping important is very tough It is isn't it? Yeah, very tough. Stunning that's up. It's still the sun is out and you see a bit of blue sky It's very nice, but I'm not too sure Maybe they'll cut this short after maybe 9 12 holes. I don't know because it is just that little bit too difficult today I'm afraid. I hope you get some enjoyment from it. I'm not sure I'll piece this one together because Not a lot of talking in between shots. I'm afraid Great shot That's in the first of fourth for a five


I don't think the challenges in Denmark are so different from the challenges that are other places in the world but I think one of the first steps is to understand what open science is. I think many people have a perception of open science as being open access to publications but it's so much more than that and trying to get to grips with that really demands some more education and I think that the way to go about it in Denmark as in other places would be to allocate enough resources to educate the researchers especially the young researchers who are on the verge of career maybe. So that would be one of the first steps and open air is a step in that direction because it allows us to reach out to researchers and to also publishers and funders to try and get them to talk about open science.


So today is project day. We have had problems with squirrels that have figured out that they can get in there. And we don't want them to get in there. We don't want them to make nests in there. We've had big problems with this. So the project for today is to close this up. We've already gone and gotten our supplies. Let's see what we can do. So we've got our primer and our paint. All our supplies in there. We've got a table here to do our painting on and the least windy area of the yard right now. And all of our supplies. So this is what we're going to be closing it off with. This is 516th underlay. I'm going to paint it first and seal it. I'm going to paint these and seal that. It's nice and treated wood. We have 10 of these. I have two on the house over there already. And we've got a wife to paint. And we've got a wife to paint. Absolutely. We're going to paint these last though because we're going to put these on last. So while we're putting these up. These can dry. We need these dry first. Or what I'll do is the primer on these, let these dry while I paint these and then get to the painting. Depends how quick things dry. So how are you getting to? What's in there? What's in there? Go check it out. Go check it out. Did we get the good stuff? Let me see. Let me see. It feels very good. Very solid. Very solid. Very nice. High quality? I think so. I think it's the best man. Pretty good. So yeah, now we just got to prime it, paint it, put it up. So hopefully we can get this done today yet. If not, finish it up tomorrow before the afternoon because I might have to leave tomorrow evening on a trip yet. And I'm hoping not. So we'll see. I don't have any load scheduled yet. So I don't know. I just made myself available tomorrow evening, but it might be that they don't have anything for me for another day. What do you think, Diesel? Let me check one more time. Double check. Double check. Smells nice actually. Very nice. Fresh. Fresh. Very nice. Where'd you get this stuff, man? It's very nice.  Oh, it's just, how does it sit here? Oh, she's Instagramming. You stay there, Diesel. It's the Project Weasel. Stay there, Diesel. Don't forget to go follow BritsBeat on Instagram. Well, this piece is just an extra one, so we didn't do that one, but we primed all of these. Took us about two hours. Now we're getting ready to put the paint on. This is just a, yeah, that's French. I don't know what that says. All right, premium, exterior, exterior. Exterior. Exterior. Excellent durability. He can English most days. Most days. Let's open one of these bad boys. All right. Just got a fresh coat of paint on it. We've got what, one, two, three, four, five, six, seven, eight more to do over there. Diesel's over here. I'll have their first coat of paint. Probably just do one coat of paint, and if we need to do another one, we'll worry about it afterwards. Oh, there she is.  Almost there. We only have eight more to do. Almost. I hear a weasel over there. Oh, I just let the bigs out for Diesel. He's upset that you can't help. You don't have thumbs, man. We went over this. He's in the screen room right there. He's just upset that he can't be near you. Are you okay? Are you okay? I can't see you. You okay? He needs to be the foreman. He's a foreman. Supervising from over there in his luxurious shelter. Exactly. That's where the boss sits. That's the boss's house, Diesel. He's yours for the boss. See? Now he feels better about himself. Absolutely. We got everything primed and painted and underneath our veranda to keep safe overnight. Now it's time to watch a movie. What movie are we watching? Fantasy Island. We're renting it from the Cineplex store because we're special. We got all my tools charged up for tomorrow. We're going to need this because we're going to have to screw those up. You can probably see them from right here. Oh, you can't quite see them. We've got them leaned up against there. Then movies. Great end of the day.


Welcome back MechanicalEI! Did you know that Laplace transformations were bought into popularity after its use during World War II? This makes us wonder, what are Laplace transformations? Before we jump in, check out the previous part of this series to learn about what Euler's column theory is. Now, the Laplace transform of a function f of t defined for all real numbers t is the function f of s, which is a unilateral transformation defined by f of s equals integral of f of t into e power minus st with respect to dt from 0 to infinity, where s is a complex number frequency parameter and is equal to sigma plus iota omega with real numbers sigma and omega. An alternate notation for the Laplace transformation is l of f instead of f of t. The meaning of the integral depends on types of functions of interest. A necessary condition for existence of the integral is that f must be locally integrable on closed interval of 0 to open interval of infinity. While studying Laplace transforms, it is also important to know the definition of bounded variables. In mathematical analysis, a function of bounded variation also known as bv function is a real valued function whose total variation is bounded, finite. For a continuous function of a single variable, being of bounded variation means that the distance along the direction of y-axis neglecting the contribution of motion along x-axis traveled by a point moving along the graph has a finite value. Hence, we first saw what Laplace transforms are and then went on to see what functions of bounded variation are. So like, subscribe and comment with your feedback to help us make better videos. Thanks for watching. Also, thanks a lot for those constructive comments. You helped the channel grow. So, here are the top mechanical EIs of our last videos. In the next episode of Mechanical EI, find out what linearity property is.