Music Herald: And give a great round of applause to Sebastian Eschweiler! Applause Sebastian: So hi everyone. So I want to talk about how I defeated not (Not)Petya's cryptography. Some I'd say that (Not)Petya would be Ukraine's scourge, and for those of you who don't know what the word scourge means: this guy right here doesn't know either. And quick trivia quiz - does anyone know what this movie is? What's the name of the movie? So, in the next scene Johnny Depp enters. Does ring a bell? Jim, a movie by Jim Jarmusch. Soundtrack by Neil Young? Dead Man, right! Great! It's a great movie. So if you want to know what a scourge is then you could watch the movie. So let's begin with my with my talk. So this is what actually the official Ukraine Twitter account tweeted some time ago in at the end of June 2017. And there was an outbreak of a ransomware attack which was noticed mostly in Ukraine but also all over the world. So millions of users and also companies large companies were affected, and the damage went into the billions of dollars. So, the problem there is, I mean, this is this is not the everyday ransomware outbreak you have there. And I want to give you a short glimpse into the the (Not)Petya universe. And also how I could decrypt all these stuff that, yeah, actually was encrypted by the this ransomware outbreak. So first I want to begin my talk with a differentiation. I want to draw a demarcation line because all this (Not)Petya universe - there's much sub- summarised under under this whole label. And I really, I'm just talking about a small fraction of this whole universe. So I will first distinguish between what my talk will be in what my talk will not be about. Next I will describe (Not)Petya's cryptography, and especially (Not)Petya's cryptographic failures. Which I then will be exploiting in the remainder of the talk and see how can the users get their, yeah, vacation photos back. So what was this whole thing? The outbreak started, as I said, in June 2017, and it started as fake update or as malicious update from a software called Madoc - this is a tax software, one of the two official tax softwares in the Ukraine. So almost every company has it installed on tax accounts on their computers many private persons have it installed. It was pushed and then site loaded this file perfc that was then downloaded to the computers and it comprises several parts. And some parts are more interesting than then as others, so one component ever like half an hour time it would start encrypting the files depending on the access level. So, if there wasn't any access to infect the computer with well this MBR infector. then it would just based on the current user level encrypt the files based on that current user. In lack of a better name I would call this "Mischa" component I know it's usually somewhat different, something different. However, this was the best name I could find there. So it's basically just a finite crypter with AES. My talk will not go about this this part - this file infector. The next very interesting component was the spreader part - it's basically based on the EternalBlue/EternalRomance exploits that had been leaked by the Shadow Brokers. My talk will not go about this as well. This is a whole different universe as well. What my talk will be about is the actual (Not)Petya component and this is an MBR encrypter and I will show you in the next slide what it's actually about. So, the user will see something like this upon reboot. So if the access rights are granted so if there is some local admin installed on the computer or the correct password could be guessed by some attack and then this dropper, the perfc that would infect the system by overwriting the Master Boot Record with a custom boot loader. And it would reboot the system after a predefined time - usually being about 10 minutes. And then the the actual (Not)Petya compound would kick into action. This infected MBR, the bootloader shows this decoy CheckDisk screen, and in the background would find and iterate the old files on the file system and encrypt all these files. So the main takeaways of this slide are that we are dealing with 16-bit code here. So we're we're in 16-bit real mode - so this means no proper file system it means no 32-bit or 64-bit code. There are no windows APIs-- so debugging all this and analyzing this is a tedious work. However, we have something on the plus side which is a BIOS, you know, the basic input/output system and with that comes a range of interrupts that are very well described and a really nice thing is having Bochs and being able to debug all this in in IDA. So this was a really neat plugin that had been developed by the authors. So let's analyze a bit and check the cryptography and why implementing crypto is really hard. So I will start this part with describing in short words the theory of Salsa20 and then check that compare that against the (Not)Petya implementation of this cipher. So Salsa20 is a stream cipher. So basically you will have a plaintext, it's it's about here and then you will have some kind of random number generator or pseudo-random number generator and then apply some operations on the plaintext and out comes the ciphertext. And what you put in there are four different variables, or four different inputs, because there's the constant part which is obviously not variable. But we'll see about that in a bit. So you have these key and the nonce, and then there's this really nifty thing called counter. What's so nifty about that is if you were choose to stream a Salsa 20 encrypted stream and you would lose some frames then you could adjust this counter variable which would de-mark the offset of the current stream in the current stream and then could continue needlessly with with the decryption of the stream. So this is a very nice feature. The size of the counter is 64-bits and the hash size here, so what salsa does is create a 64-byte hash for every different of these inputs and with that then apply to the input. If you want any more details about this salsa cipher, the inventor of salsa should be in this room, and should be in at the convention. He is at the convention: I just rode the train with him, so I guess you can ask him the the gory details of salsa 20. So it's a really nice crypto cipher and you should hit him up and ask him. I shouldn't have said that, right? Sorry. So basically what a very important thing is to note is for every invocation of this this or for every instance of this (Not)Petya encryption and you would have these three variables or these three inputs be constant so (Not)Petya would would patch during the infection process the key, the nonce, and the constants into a configuration sector. The constants, not these are somewhat different. And then the counter would only change throughout every iteration. So the interesting thing or the interesting question was first - what is the length of the key stream? So, the key stream, you know the the number of different outputs that that would come out of this hashing function. And I mean for this implementation for the theory this is quite clear it's 64-bits here eight bytes times the 64 bytes of output so it would be about two to the seventy of a periodicity. One different about the actual implementation in (Not)Petya on the theory would be that this constants thing here had been changed to I string a reading out invalid sect ID. So this would break the official implementation. So the very first failure I saw in (Not)Petya was something like this. So I think I can slip this slide because it's obvious for everyone that this is a fail right? So who sees the fail? So, not many hands? Okay, then then I'll explain it. So I was just kidding , I'm almost not not expecting for for you to grasp of that first. So remember, we're in 16-bit code. We have here this shift left operation which would shift a register by N-bytes. The register with here is 16 bits, so it only has 16 digits so to speak and you would shift it by 16 - by 10 hex - sixteen. And this would effectively null the register, and even worse is here. So you would shift a an 8-bit register for sixteen. So this is something you you wouldn't expect from my proper cryptographic implementation. And I was was really intrigued why that is, because it wouldn't make any sense in source code and and did the (Not)Petya or the Petya authors really implement that on purpose, or what was the gist with it. And I looked up the (Not)Petya, the salsa 20 implementation um I just googled it and funny a nice website that had a implementation of salsa 20. And there you would see this code. So you see here it sits in the the endianness conversion. And you see here these these shifting of bits of registers and you see here this this uint fast 16 or 32 type. So it becomes quite clear that this is a broken implementation right? So everyone can see that right? No, not right now because you need to know some things more about this. There are two important facts that make this implementation broken and the two facts are: you need to compile this code for 16 bits, and you need to look up what Visual Studio makes of these these type definitions here. And when you look that up, this is from Visual Studio and it's in the standard int.h header file. And there you see it's interpreted or translated as unsigned int, so this is the base type. And this base type, unsigned int, in 16-bit code is a 16-bit variable or a 16-bit register. And then everything makes sense. And this was somewhat of a a failure here - the authors didn't really check if their code was actually working against the test vectors. And this guy who wrote the code here on this salsa 20 implementation made this mistake also. On this slide you see two bugs off of the (Not)Petya implementation of salsa 20. And I quickly want to to explain both to you because they are of some somewhat in importance throughout the remainder of the talk. So, both revolve around the the counter variable. Just remember - this counter variable is the only dynamic input the only variable input throughout all these salsa 20 invocations. And the the first error is: so you read a sector, a sector number into the memory. So a bit about the the low-level aspects of a hard drive. A hard drive from the view of the BIOS would look somewhat like a bunch of different sectors. So these are 512 byte chunks of data, and they they come one after another. So if you were to read a sector, you would actually read a 512 bytes about me a byte long portion of data. And this is obviously not the offset in the stream, and this is somewhat of a problem there. So, you see here the same variable is used to decrypt or encrypt the data. And, I mean, this this is it doesn't it isn't really apparent to to the implementer of this cipher. However, if you were to analyze it, it would look something like this. So you would have the key stream of two different sectors, two different consecutive sectors here. So it would start with with FF and then continues with D7 and so on. And the next sector would have almost all of the bytes identical. And this is yeah a really big failure because this really nice salsa 20 implementation, this really nice salsa algorithm will then be, from would then be converted from a one-time pad to a many times pad. And this is the first fine I wanted to show you in this very few lines of code. The second part is, the second bug is here this large keyword. Remember, we are in 16-bit code so this large keyword here does not push a 64-bit variable as we would suspect to do it, but a 32-bit variable. So only 32 bits of this this nice counter variable are actually used in this case. So, these two failures are somewhat of a problem for this salsa 20 implementation. So, in this slide I took two different hex dumps, and these hex times were are within this expand key function. And they they are well basically two snapshots - one right before these bugs become apparent: so before this this endianness conversion, and right after on the lower half. So you very nicely see the different variables being put into all the different key inputs being put into these this memory blocks. So here, it would spell out invalid sect ID, you know, the constants (Not)Petya uses. Here you would see the key and here, so it's broken into two halves. Additionally you would see the nonce here. And what really sticks out is this bunch of zeros here. So this this higher part of this a 64-bit variable isn't even used - is it's not even filled. So this is well the first problem here, and after the endianness conversion you see that it's not really an endianness conversion but it's more of a nulling of of bytes. So the result would be that this initially 64 bit variable would be just 16-bit in length. And, as I said earlier, the original salsa implementation would be 2^70s key lengths. And right now we have 16 bits times 64 bytes in in key lengths which would result an in 26 bits in key lengths. Which would be a measly 4 megabytes in key lengths. So this is the this was a very interesting observation I made there and this would be possible then to decrypt together with the many times pad properties of this cipher which make it really easy to break. So to quickly summarize this part of the talk - so we have a very very short key stream of just 4 megabytes, it's highly repetitive repetitive. So for each secretary progress you would only have a progress of one byte at a time. So only 26 bits remain of the whole stream. And as I said, the many times pad property's a very nice thing to to analyze. I could come around to implement a small joke here, so this salsa implementation I would only call "LOLsa" from now on. Sorry, is a bad joke sorry! So, the the main goal is to derive the keystream, and as I'm not really a crypto expert, the basically the only attack I know it would be a known plaintext attack so this was my goal there because it's so straightforward to do that. And in the remainder of the talk I will tell you how I did that. So without further ado, let's exploit these failures and see how much of the plaintext we can actually get from a (Not)Petya infected drive. So the modulus operandi of (Not)Petya would look somewhat like that. This, so let's let's stop with the with the left hand side of the of this slide, and concentrate on the right hand side. For those of you who you are not really intimately familiar with NTFS - I wasn't before analyzing Petya or (Not)Petya as well so no worries. It's quite simple - so every NTFS partition has something called an master file table. MFT, abbreviated. And it would contain some metadata about the file. For example, the file name, the file size, and if the file is small enough, it would even fit the actual content of the file into this record. So, as I said, MFT is just list of records. And if the file is larger it would have a pointer, a so called data run, which would point to a cluster or sector on the disk on the partition which would then actually be the the payload data. One of these MFT records is one kilobyte in size. So now to the actual implementation. So let's zoom out a bit and see how this LOLsa implementation is used in (Not)Petya. So it would basically just iterate over over all of these MFT records, and then check if this record would put into would point to a file. If that is the case, it would encrypt the first kilobyte of the file, and then would encrypt the record itself. This implementation is good for a bunch of reasons - it's very fast: You would only need to encrypt the first kilobyte, and this is this first kilobyte contains really really important information. For example, headers, or especially compressed files have these really important header structures there. Additionally, your file recovery tools wouldn't be able to work anymore because most of them rely on this very header. And the second thing is this MFT is can be considered as table of contents. So with no metadata, with with no pointers to these to the files, you won't have anything there to work with to recover from. And this is a I mean from from the implementation standpoint it's very neat, because it's fast and it's a somewhat thorough. As the MFT is really important, my idea was to to recover that first and then check what what comes out from there and see how I can can further progress there with the decryption of the files. So the metadata would would be of most importance there. I'm a visual person, and here I took two disk dumps from a from one of my test disks. So I infected a clean system with (Not)Petya and let it encrypt the hard drive. And on the left-hand side you see the plaintext on and on the right-hand side you see the encrypted data. So to just get a better picture about the encryption process. On the far left-hand side fancy PowerPoint altered animation, you see some kind of indicator so which which would tell you at which offset, how much of the of the data has actually been different. And you see the whole disk is more or less being encrypted. However, you see at the far bottom part here it's more dark red. And this is actually the MFT, so the MFT is towards the end of the disk sometimes. But this might be a misconception. So my my idea was something like this: we have two input sizes, right? We have the the encrypted MFT, and we have encrypted files. And first i would analyze the MFT, and then derive the key stream from that. After that analysis stage had been finished I would put the key stream back into the this this little box here, and actually decrypt that. And then out comes the decrypted MFT. And with that and the key stream I would be able to find the encrypted files on the disk, and then be able to decrypt them; then be ready with it right? So this was my initial idea there and so let's start with the decryption of the MFT. Known plaintext attack, right? So an MFT you looks for from from the viewpoint of the keystream, somewhat like this. So you would have here the first, the second and so on MFT records. And on the on the column you will have the actual byte that is used as key to encrypt the key stream. Remember, the operation that that encrypts the you know the the key stream and the the plaintext is just a mirror XOR operation. So you have the the key stream and the plaintext, and it's plainly - so you can switch forth and back between plaintext and ciphertext and even the key stream with a with just applying an XOR operation. So what you see here is for the very first records you only have very few key stream bytes or very few sample bytes. However, as the progress as you make progress with the analysis and then you will have more and more of these sample bytes to collect from and this this will give you more confidence in the in the result, and the may be known key stream then. The question is, does the MFT hold enough plaintext to do some some kind of known plaintext attack? So let's look into the specification. The MFT record has basically two fields. So there is this the standard information, which is a well- defined structure and there's something else called attribute list, which is a quite dynamic structure and this would be a somewhat more different, difficult to clean plan text from. So I concentrate on this first part. And the first part quickly turned out to be quite constant for many or most of the MFT records. And you see it starts with FILE and then as some some hex digits after that. And although on the far bottom part of the slide, I added my yeah certainty level. So the the certainty level would be the number of different sample bytes I would have multiplied by the confidence I would have in that sample byte being actually this this plain text. So you see for the very first record, we would have a quite low, of a low certainty. I mean, it's just one byte, right? Oh, the two byte skipping is I mean quite a forward considering you would have usually 512 bytes per sector on a disk, and the MFT record is one kilobyte in size, so the stream would progress two bytes. And for record 100, so for if for the 100th record I would have a certainty of four. You know, I would just assume these eight plaintext bytes here, divided by 2, with an resulting 4. This wasn't really satisfactory. The problem there was towards the end I would have many many unknown records because I would was concentrating on on the very first parts of the header. So the remainder of the key stream, the very end of the key stream wasn't be able to being analyzed and eventually decrypted. So I thought of something different. And there was something like a I would call a byte histogram. So for every offset the MFT record, i would i will then calculate creatin and a histogram and check how many different bytes are there actually for plaintext, you know, it's a plaintext known plaintext attack so I would need some kind of plaintext and would do that for every offset for every record. And so these the questions there how to get many MFT records - it's quite easy if you have some nice colleagues you just need to hang them all of the balcony and shake them a bit then more or less voluntarily they will give you some MFT keys to work with. And the result of that is quite nice: you, I mean for for the very first, there's nothing much you can do the very first record will always have very few sample bytes. But as the stream progresses and you will have a dramatic change there so from this relatively low certainty of four, I could increase that to more than thirty. So this is somewhat nice, and ever bit of doing science, this table drops out from nowhere. So I compared these two attack types. So, let's read that from from right to left. On the on the far right, I have for the first approach about 98% of the MFT records being successfully recovered. You know, with the good thing with science and with all this academic approach is you have a ground truth. So I have a plaintext an unencrypted hard drive which were virtually unordered from something right after infection, and then you let execute the the whole infection and encryption process. And then you can differentiate and take you knows several snapshots throughout the infection, change different key values and all the stuff. So this is a very nice thing about this academic approach I was taking the other So I could I could exactly pinpoint how many of these records were perfectly recovered. So for the byte histogram approach I could decrypt almost all of the records, which is quite nice because then we have a high quality MFT to work with. What's also quite nice is that we have zero wrong key stream bytes. What's not so nice, however, is that I was only able to recover about 1.3 percent of the overall key stream. And remember - this this key stream is about 4 megabytes in length and I was able to recover only 50 kilobytes of that, so we can't recover all of the the files. Or is that so? This is this was my next question there. And so I drew another nice diagram. This is the key stream; in the this is the MFT, sorry, in the key stream. So the the key stream is only filled and in sample bytes at this 2 megabytes mark. And the question is, are there many files in this area being encrypted or is there some other bug I could exploit. And I checked where the files would lie into this the key stream. So I would check how many files are at which location in the key stream being encrypted. And you see the key stream is used all over the place - so I mean sometimes it's used more, sometimes it's used just the less, however, it's basically used all over the place. And so this much of the key stream could in a perfect scenario be, I mean, perfect scenario being a perfect known plaintext oracle could theoretically be recovered. However, this is somewhat of a problem here and in the next part of the talk I will present you how I was able to solve this problem as well. So remember when the file system is actually encrypted by (Not)Petya, the file system looks somewhat like this. So you would have the MFT which is totally garbled so you won't have any of any nice file pointers or data runs pointing through those files. You won't have any nice file names and all the stuff. But with the first stage being finished, the MFT looks really nice - I mean like almost a hundred percent of the records could be recovered. So it looks somewhat like this. So you have a bunch of metadata you can now use to analyze the the remainder of the files and the remainder of the encryption. So all this MFT or almost always actually decrypted. And for files you would have the very first kilobyte being encrypted. The remainder of the file, the, I mean, most files are more than a kilobyte in size, right? So all the rest is not encrypted. So you would have all this data and metadata to collect information and to to use to exploit as-known plaintext as indicators for known plaintext. So I thought of three different approaches to you know to attack this problem. Basically I was thinking about: okay what different files are there, and I was quickly thinking about different file types. And I mean, there are I mean the file type can be easily gleaned from this, right? Because you would have the file extension and it would be basically the file type. And you would have two different types of files - you would have structured files and unstructured files. So I thought of these and you would have something like, yeah, source code, which I would consider as more or less unstructured. And I was calculating the histogram, so this would give me some kind of prevalence towards different bytes in the key stream. So it would be somewhat like a guest plaintext attack or something like that. The next thing for structured files would be to do the very same approach as with the MFT records. I would calculate the histogram for every offset of the first kilobyte, and then quickly see how how many different bytes are there per offset. And the last approach uses somewhat more data. It uses some of the metadata, and also some of the file data. I will go into this right now. So, what I basically have here as I said it's only this this little portion of the files encrypted. The whole remainder of the file is not encrypted, which is quite nice. And also the file name the file sizes not encrypted. So what I use, what I would do here is create a database of known files of known Windows system files, for example. Y'all might remember these nice background images fonts all this stuff - plaintext is flying around everywhere if you just look for it. And I would have basically three different, yeah, three three different distinctors between those to know which which is the correct plaintext. So there is this this key file name, the file size, and then the hash of this whole remainder, of this whole tier. So if all these 3-tuple would match, then I would consider this as a proper plaintext. However, there are some collisions, so this is this is not really something that is straightforward. So the initial idea of having of only needing to analyze the MFT and then could just being being able to straightforward decrypt files needed to be altered a bit. So I added this database of known files there, I added another another analysis stage in this nice box here, and then I would be able to decrypt the files, eventually. So let's do a bit of science and check if this approach would be worthwhile pursuing on a real-world scenario. So let the science cat do its science, let me have a drink. So whenever you did do here is to create a database of known files - I collected a bunch of default Windows installations, which resulted in about 340,000 unique files in it. Then I calculated, you know, the the different file type histograms I talked about, I prepared my test setup, I added there 1000 different files. And you should note that these files were not part of this known files database - they were different from that because otherwise it would have been easy to do. Then I would infect this machine and then let its encrypt by (Not)Petya and then attempting recovery. And these are the results there. So, I did this with 4 different runs, so I tried every approach separately, and then combined the three approaches. And the outcome was something like this: So I would have only two files by the general histogram approach being able to be to decrypt. At least 8% where I will were yet decrypted by the location histogram approach. And by the known files approach over 90% of the files could be successfully recovered. And even better, the combined outcome would be almost all files being able to decrypt. So, so much about academia. So the problem there is if you apply this to the real world, you could get into more trouble there. And there was lots and lots of more to think about so. There were, for example, non default windows installations with the whole history of updates so this might be really interesting from a forensics perspective. Moreover, there's lots of installed programs to derive known plaintext from - for example, dotnet uses a vast source of known plaintext or JDK installations. So, especially the JDK would would result in about tens of thousands of different source code and HTML files. So this is this really was really quite nice. The drawback there was, so there was so much data to collect, the first attempts failed miserably because of the sheer amount of RAM I was using. And this would would result in the admins constantly giving me more more RAM in my VM so I would eventually end up with, I think, 128 gigabytes of RAM and my my test VM. Also you have a much larger master file table you know because of all these files that would need to be stored, so to put them in in comparison. So this nice working prototype, so this nice test setup, I mean, would have an MFT of about 26 megabytes. And for real-world scenarios you would have something like at least 500 megabytes, and even MFT could be even like a couple of gigabytes in size. So this means much more plaintext. So for through these really large MFTs you could quickly recover the whole key stream, the whole four megabytes just by looking at the MFT. And, in summary, this means that the decryption of (Not)Petya encrypted drives is possible. So, for for the file systems the drives, I have looked at it, was really I mean ever after having all these these first bugs out of the way, I was able to decrypt and recover all the files there. So there's a good chance the vacation photos can be recovered as well. And this will conclude my talk, so quick summary - (Not)Petya has some severe cryptographic failures and flaws, so I would only be able to call this LOLsa and not salsa anymore. It might be possible to further look into this, this you know this expand key and thing. It it has really really a bunch of more cryptographic failures in it. I didn't look into that deeper but I know some of you guys are professors and this might be a nice homework for your students to look at this (Not)Petya implementation and check out some, you know, more advanced crypto analysis methods. And you should note that this hook this this whole (Not)Petya thing here I described the whole cryptographic flaws there are not just in (Not)Petya. They are you see the brackets there: there they are in every each and every version of Petya. So all of the drives that you potentially have saved can be decrypted. And so my last point is if any of you or any of us falls victim to ransomware you really should keep the drives. You keep them untouched in a locker and wait for a talk like this basically. And then hope that someone comes around and then be able to decrypt the drives and then, you will have your vacation photos back. So that's all folks, thank you for your attention. Applause Herald: Thank you very much Sebastian. Now it's time for questions, please queue up by the microphones. Mic 1: Hi, well thank you very much for sharing your findings with us. I'm from Rotterdam the largest harbour in Europe, and as you might know, we were struck by Petya Sebastian Yes Mic 1: Two terminals went down for a couple of days, a couple of hundred billion euros of damage. Your approach is quite theoretically, so now to practice - if you were there in this summer with these findings, would you've been able to help us and decrypt the files and get all the companies up and running again? Or is this too academic? Sebastian: No, it's a practical approach I mean, I work for CrowdStrike and we had some occasions where we were able to help the customers. So it's a very practical thing to do so. And I was trying to insinuate this with, you know, this slide here. So I was talking about the real world in this scenario. So I looked at about 50 different encrypted hard drives with (Not)Petya, and I was able to decrypt all of them, or most of them. Mostly the the ones not being able to decrypt or to some, well, let's say, level 8 mistakes. Mic 1: Awesome. Have you shared your findings with nomoreransoms.org? Sebastian: No, I don't know about this site Mic 1: They provide decryption tools for ransomware. Please do, thank you Herald: Microphone six, please Mic 6: Thank you, in the beginning you mentioned that basically the key was shortened to what was a 24-bit, something like that? Sebastian: 26, yes Mic 6: 26, yeah. From that point, wasn't a brute-force attack way faster and way more reliable? Sebastian: Oh no no, don't get me wrong there. So the keystream length was 2^26, so the keystream length was four megabytes. So you wouldn't be able to brute-force that. So sorry, do you get that? The number of bytes was four megabytes, and you couldn't be able to brute-force that. Mic 6: Yeah but you already mention at the beginning that you basically shortened it down to the possibility of at most two to the power of 26, and it is calculable. Sebastian: Yes yes, I totally get the question. But you're you're missing the point there. So it's not the key space, 2^26, but the key length is 2^26, which would be something - I I'm not good at that converting this to decimal. Would be something like, let me check, two to the... I mean, here, math guys, computer guys: how many bits is that? [Inaudible audience answer] Sebastian: Say again? Crowd: A lot? Sebastian: A lot! So it's, I mean, it's it's four megabytes of keylength and you couldn't just brute force that because you you would have each of these four megabytes you would have to brute force. Got that? So the key is not 2^26 but the key length, the keystream length, is that long. Got that? So yeah, this is the key space would be longer than the Bible. You know, and you couldn't just brute force the Bible, the text of the Bible. I mean given enough time yes but you know we will all know the stories with in monkeys and typewriters. I mean we can talk about that that offline but you're you're mixing up two different numbers there. Mic 6: Yeah I guess, thank you. Herald: Questions from the Internet, please Signal Angel: Does the MFT encryption work the same for Petya and (Not)Petya? Sebastian: Yes, the underlying mechanism is the same. The cryptography differs in such a way that the constants number is different. So, this little guy here - this is different. It would be usually like expand key something-something. And here it's invalid sect ID. So it's somewhat different, but the the MFT encryption; I mean the the bytecode the and the algorithm is the very same. Signal Angel: Thanks Herald: Any more questions? Then please give a great round of applause to Sebastian Sebastian: Thank you Applause subtitles created by c3subtitles.de in the year 2018. Join, and help us!