1
00:00:00,099 --> 00:00:14,800
Music
2
00:00:14,800 --> 00:00:18,760
Herald: And give a great round of applause
to Sebastian Eschweiler!
3
00:00:18,760 --> 00:00:24,290
Applause
4
00:00:24,290 --> 00:00:32,360
Sebastian: So hi everyone. So I want to
talk about how I defeated not (Not)Petya's
5
00:00:32,360 --> 00:00:42,800
cryptography. Some I'd say that (Not)Petya
would be Ukraine's scourge, and for those
6
00:00:42,800 --> 00:00:48,190
of you who don't know what the word
scourge means: this guy right here doesn't
7
00:00:48,190 --> 00:00:57,249
know either. And quick trivia quiz - does
anyone know what this movie is? What's the
8
00:00:57,249 --> 00:01:08,940
name of the movie? So, in the next scene
Johnny Depp enters. Does ring a bell? Jim,
9
00:01:08,940 --> 00:01:17,140
a movie by Jim Jarmusch. Soundtrack by
Neil Young? Dead Man, right! Great! It's a
10
00:01:17,140 --> 00:01:24,310
great movie. So if you want to know what a
scourge is then you could watch the movie.
11
00:01:24,310 --> 00:01:31,640
So let's begin with my with my talk. So
this is what actually the official Ukraine
12
00:01:31,640 --> 00:01:39,930
Twitter account tweeted some time ago in
at the end of June 2017. And there was an
13
00:01:39,930 --> 00:01:47,210
outbreak of a ransomware attack which was
noticed mostly in Ukraine but also all
14
00:01:47,210 --> 00:01:51,999
over the world. So millions of users and
also companies large companies were
15
00:01:51,999 --> 00:02:02,969
affected, and the damage went into the
billions of dollars. So, the problem there
16
00:02:02,969 --> 00:02:09,889
is, I mean, this is this is not the
everyday ransomware outbreak you have
17
00:02:09,889 --> 00:02:17,220
there. And I want to give you a short
glimpse into the the (Not)Petya universe.
18
00:02:17,220 --> 00:02:24,130
And also how I could decrypt all these
stuff that, yeah, actually was encrypted
19
00:02:24,130 --> 00:02:31,330
by the this ransomware outbreak. So first
I want to begin my talk with a
20
00:02:31,330 --> 00:02:35,880
differentiation. I want to draw a
demarcation line because all this
21
00:02:35,880 --> 00:02:41,560
(Not)Petya universe - there's much sub-
summarised under under this whole label.
22
00:02:41,560 --> 00:02:49,660
And I really, I'm just talking about a
small fraction of this whole universe. So
23
00:02:49,660 --> 00:02:55,430
I will first distinguish between what my
talk will be in what my talk will not be
24
00:02:55,430 --> 00:03:02,630
about. Next I will describe (Not)Petya's
cryptography, and especially (Not)Petya's
25
00:03:02,630 --> 00:03:08,310
cryptographic failures. Which I then will
be exploiting in the remainder of the talk
26
00:03:08,310 --> 00:03:22,360
and see how can the users get their, yeah,
vacation photos back. So what was this
27
00:03:22,360 --> 00:03:34,700
whole thing? The outbreak started, as I
said, in June 2017, and it started as fake
28
00:03:34,700 --> 00:03:40,990
update or as malicious update from a
software called Madoc
29
00:03:40,990 --> 00:03:48,400
- this is a tax software, one of the two
official tax softwares in the Ukraine. So
30
00:03:48,400 --> 00:03:55,730
almost every company has it installed on
tax accounts on their computers many
31
00:03:55,730 --> 00:04:02,960
private persons have it installed. It was
pushed and then site loaded this file
32
00:04:02,960 --> 00:04:14,380
perfc that was then downloaded to the
computers and it comprises several parts.
33
00:04:14,380 --> 00:04:22,870
And some parts are more interesting than
then as others, so one component ever like
34
00:04:22,870 --> 00:04:28,880
half an hour time it would start
encrypting the files depending on the
35
00:04:28,880 --> 00:04:37,250
access level. So, if there wasn't any
access to infect the computer with well
36
00:04:37,250 --> 00:04:44,080
this MBR infector. then it would just
based on the current user level encrypt
37
00:04:44,080 --> 00:04:53,480
the files based on that current user. In
lack of a better name I would call this
38
00:04:53,480 --> 00:05:00,810
"Mischa" component I know it's usually
somewhat different, something different.
39
00:05:00,810 --> 00:05:06,260
However, this was the best name I could
find there. So it's basically just a
40
00:05:06,260 --> 00:05:13,280
finite crypter with AES. My talk will not
go about this this part - this file
41
00:05:13,280 --> 00:05:22,190
infector. The next very interesting
component was the spreader part - it's
42
00:05:22,190 --> 00:05:27,389
basically based on the
EternalBlue/EternalRomance exploits that
43
00:05:27,389 --> 00:05:34,371
had been leaked by the Shadow Brokers. My
talk will not go about this as well. This
44
00:05:34,371 --> 00:05:41,260
is a whole different universe as well.
What my talk will be about is the actual
45
00:05:41,260 --> 00:05:49,260
(Not)Petya component and this is an MBR
encrypter and I will show you in the next
46
00:05:49,260 --> 00:05:58,049
slide what it's actually about. So, the
user will see something like this upon
47
00:05:58,049 --> 00:06:06,240
reboot. So if the access rights are
granted so if there is some local admin
48
00:06:06,240 --> 00:06:12,230
installed on the computer or the correct
password could be guessed by some attack
49
00:06:12,230 --> 00:06:18,610
and then this dropper, the perfc that
would infect the system by overwriting the
50
00:06:18,610 --> 00:06:26,110
Master Boot Record with a custom boot
loader. And it would reboot the system
51
00:06:26,110 --> 00:06:32,760
after a predefined time - usually being
about 10 minutes. And then the the actual
52
00:06:32,760 --> 00:06:39,500
(Not)Petya compound would kick into
action. This infected MBR, the bootloader
53
00:06:39,500 --> 00:06:46,760
shows this decoy CheckDisk screen, and in
the background would find and iterate the
54
00:06:46,760 --> 00:06:49,500
old files on the file system and
55
00:06:49,500 --> 00:06:56,060
encrypt all these files.
So the main takeaways of this slide are
56
00:06:56,060 --> 00:07:04,530
that we are dealing with 16-bit code here.
So we're we're in 16-bit real mode - so
57
00:07:04,530 --> 00:07:10,740
this means no proper file system it means
no 32-bit or 64-bit code. There are no
58
00:07:10,740 --> 00:07:20,449
windows APIs-- so debugging all this and
analyzing this is a tedious work. However,
59
00:07:20,449 --> 00:07:26,290
we have something on the plus side which
is a BIOS, you know, the basic
60
00:07:26,290 --> 00:07:33,910
input/output system and with that comes a
range of interrupts that are very well
61
00:07:33,910 --> 00:07:43,020
described and a really nice thing is
having Bochs and being able to debug all
62
00:07:43,020 --> 00:07:50,130
this in in IDA. So this was a really neat
plugin that had been developed by the
63
00:07:50,130 --> 00:08:00,680
authors. So let's analyze a bit and check
the cryptography and why implementing
64
00:08:00,680 --> 00:08:09,510
crypto is really hard. So I will start
this part with describing in short words
65
00:08:09,510 --> 00:08:16,510
the theory of Salsa20 and then check that
compare that against the (Not)Petya
66
00:08:16,510 --> 00:08:28,000
implementation of this cipher. So Salsa20
is a stream cipher. So basically you will
67
00:08:28,000 --> 00:08:35,568
have a plaintext, it's it's about here and
then you will have some kind of random
68
00:08:35,568 --> 00:08:41,089
number generator or pseudo-random number
generator and then apply some operations
69
00:08:41,089 --> 00:08:49,240
on the plaintext and out comes the
ciphertext. And what you put in there are
70
00:08:49,240 --> 00:08:54,649
four different variables, or four
different inputs, because there's the
71
00:08:54,649 --> 00:08:59,570
constant part which is obviously not
variable. But we'll see about that in a
72
00:08:59,570 --> 00:09:09,069
bit. So you have these key and the nonce,
and then there's this really nifty thing
73
00:09:09,069 --> 00:09:17,610
called counter. What's so nifty about that
is if you were choose to stream a Salsa 20
74
00:09:17,610 --> 00:09:24,540
encrypted stream and you would lose some
frames then you could adjust this counter
75
00:09:24,540 --> 00:09:33,709
variable which would de-mark the offset of
the current stream in the current stream
76
00:09:33,709 --> 00:09:39,190
and then could continue needlessly with
with the decryption of the stream. So this
77
00:09:39,190 --> 00:09:48,230
is a very nice feature. The size of the
counter is 64-bits and the hash size here,
78
00:09:48,230 --> 00:09:57,730
so what salsa does is create a 64-byte
hash for every different of these inputs
79
00:09:57,730 --> 00:10:06,429
and with that then apply to the input. If
you want any more details about this salsa
80
00:10:06,429 --> 00:10:13,330
cipher, the inventor of salsa should be in
this room, and should be in at the
81
00:10:13,330 --> 00:10:17,429
convention. He is at the convention: I
just rode the train with him, so I guess
82
00:10:17,429 --> 00:10:24,399
you can ask him the the gory details of
salsa 20. So it's a really nice crypto
83
00:10:24,399 --> 00:10:31,070
cipher and you should hit him up and ask
him. I shouldn't have said that, right?
84
00:10:31,070 --> 00:10:37,940
Sorry. So basically what a very important
thing is to note is for every invocation
85
00:10:37,940 --> 00:10:46,499
of this this or for every instance of this
(Not)Petya encryption and you would have
86
00:10:46,499 --> 00:10:54,220
these three variables or these three
inputs be constant so (Not)Petya would
87
00:10:54,220 --> 00:11:00,139
would patch during the infection process
the key, the nonce, and the constants into
88
00:11:00,139 --> 00:11:08,089
a configuration sector. The constants, not
these are somewhat different. And then the
89
00:11:08,089 --> 00:11:15,079
counter would only change throughout every
iteration. So the interesting thing or the
90
00:11:15,079 --> 00:11:22,540
interesting question was first - what is
the length of the key stream? So, the key
91
00:11:22,540 --> 00:11:27,839
stream, you know the the number of
different outputs that that would come out
92
00:11:27,839 --> 00:11:34,579
of this hashing function. And I mean for
this implementation for the theory this
93
00:11:34,579 --> 00:11:42,629
is quite clear it's 64-bits here eight
bytes times the 64 bytes of output so it
94
00:11:42,629 --> 00:11:53,769
would be about two to the seventy of a
periodicity. One different about the
95
00:11:53,769 --> 00:12:00,619
actual implementation in (Not)Petya on the
theory would be that this constants thing
96
00:12:00,619 --> 00:12:07,160
here had been changed to I string a
reading out invalid sect ID. So this would
97
00:12:07,160 --> 00:12:23,069
break the official implementation. So the
very first failure I saw in (Not)Petya was
98
00:12:23,069 --> 00:12:27,439
something like this. So I think I can slip
this slide because it's obvious for
99
00:12:27,439 --> 00:12:35,240
everyone that this is a fail right? So who
sees the fail? So, not many hands? Okay,
100
00:12:35,240 --> 00:12:43,189
then then I'll explain it. So I was just
kidding , I'm almost not not expecting for
101
00:12:43,189 --> 00:12:49,149
for you to grasp of that first. So
remember, we're in 16-bit code. We have
102
00:12:49,149 --> 00:12:57,380
here this shift left operation which would
shift a register by N-bytes. The register
103
00:12:57,380 --> 00:13:03,579
with here is 16 bits, so it only has 16
digits so to speak and you would shift it
104
00:13:03,579 --> 00:13:11,879
by 16 - by 10 hex - sixteen. And this
would effectively null the register, and
105
00:13:11,879 --> 00:13:14,910
even worse is here. So
106
00:13:14,910 --> 00:13:22,009
you would shift a an 8-bit register for
sixteen. So this is something you you
107
00:13:22,009 --> 00:13:28,919
wouldn't expect from my proper
cryptographic implementation. And I was
108
00:13:28,919 --> 00:13:32,680
was really intrigued why that is, because
it wouldn't make any sense in source code
109
00:13:32,680 --> 00:13:39,829
and and did the (Not)Petya or the Petya
authors really implement that on purpose,
110
00:13:39,829 --> 00:13:47,669
or what was the gist with it. And I looked
up the (Not)Petya, the salsa 20
111
00:13:47,669 --> 00:13:54,760
implementation um I just googled it and
funny a nice website that had a
112
00:13:54,760 --> 00:14:04,779
implementation of salsa 20. And there you
would see this code. So you see here it
113
00:14:04,779 --> 00:14:12,090
sits in the the endianness conversion. And
you see here these these shifting of bits
114
00:14:12,090 --> 00:14:19,810
of registers and you see here this this
uint fast 16 or 32 type. So it becomes
115
00:14:19,810 --> 00:14:23,480
quite clear that this is a broken
implementation right? So everyone can see
116
00:14:23,480 --> 00:14:32,730
that right? No, not right now because you
need to know some things more about this.
117
00:14:32,730 --> 00:14:38,829
There are two important facts that make
this implementation broken and the two
118
00:14:38,829 --> 00:14:46,210
facts are: you need to compile this code
for 16 bits, and you need to look up what
119
00:14:46,210 --> 00:14:52,259
Visual Studio makes of these these type
definitions here. And when you look that
120
00:14:52,259 --> 00:14:58,619
up, this is from Visual Studio and it's in
the standard int.h header file. And there
121
00:14:58,619 --> 00:15:04,209
you see it's interpreted or translated as
unsigned int, so this is the base type.
122
00:15:04,209 --> 00:15:08,629
And this base type, unsigned int, in
16-bit code is a 16-bit variable or a
123
00:15:08,629 --> 00:15:14,459
16-bit register. And then everything makes
sense. And this was somewhat of a a
124
00:15:14,459 --> 00:15:22,000
failure here - the authors didn't really
check if their code was actually working
125
00:15:22,000 --> 00:15:27,230
against the test vectors. And this guy who
wrote the code here on this salsa 20
126
00:15:27,230 --> 00:15:40,179
implementation made this mistake also. On
this slide you see two bugs off of the
127
00:15:40,179 --> 00:15:47,240
(Not)Petya implementation of salsa 20. And
I quickly want to to explain both to you
128
00:15:47,240 --> 00:15:52,059
because they are of some somewhat in
importance throughout the remainder of the
129
00:15:52,059 --> 00:16:02,380
talk. So, both revolve around the the
counter variable. Just remember - this
130
00:16:02,380 --> 00:16:06,950
counter variable is the only dynamic input
the only variable input throughout all
131
00:16:06,950 --> 00:16:09,920
these salsa 20 invocations.
132
00:16:09,920 --> 00:16:21,689
And the the first error is: so you read
a sector, a sector number into the memory.
133
00:16:21,689 --> 00:16:28,670
So a bit about the the low-level aspects
of a hard drive. A hard drive from the
134
00:16:28,670 --> 00:16:35,019
view of the BIOS would look somewhat like
a bunch of different sectors. So these are
135
00:16:35,019 --> 00:16:43,079
512 byte chunks of data, and they they
come one after another. So if you were to
136
00:16:43,079 --> 00:16:48,759
read a sector, you would actually read a
512 bytes about me a byte long portion of
137
00:16:48,759 --> 00:16:56,009
data. And this is obviously not the offset
in the stream, and this is somewhat of a
138
00:16:56,009 --> 00:17:03,790
problem there. So, you see here the same
variable is used to decrypt or encrypt the
139
00:17:03,790 --> 00:17:13,049
data. And, I mean, this this is it doesn't
it isn't really apparent to to the
140
00:17:13,049 --> 00:17:21,449
implementer of this cipher. However, if
you were to analyze it, it would look
141
00:17:21,449 --> 00:17:28,199
something like this. So you would have the
key stream of two different sectors, two
142
00:17:28,199 --> 00:17:33,080
different consecutive sectors here. So it
would start with with FF and then
143
00:17:33,080 --> 00:17:39,570
continues with D7 and so on. And the next
sector would have almost all of the bytes
144
00:17:39,570 --> 00:17:49,639
identical. And this is yeah a really big
failure because this really nice salsa 20
145
00:17:49,639 --> 00:17:57,770
implementation, this really nice salsa
algorithm will then be, from would then be
146
00:17:57,770 --> 00:18:03,140
converted from a one-time pad to a many
times pad. And this is the first fine I
147
00:18:03,140 --> 00:18:10,090
wanted to show you in this very few lines
of code. The second part is, the second
148
00:18:10,090 --> 00:18:17,740
bug is here this large keyword. Remember,
we are in 16-bit code so this large
149
00:18:17,740 --> 00:18:24,580
keyword here does not push a 64-bit
variable as we would suspect to do it, but
150
00:18:24,580 --> 00:18:31,450
a 32-bit variable. So only 32 bits of this
this nice counter variable are actually
151
00:18:31,450 --> 00:18:40,970
used in this case. So, these two failures
are somewhat of a problem for this salsa
152
00:18:40,970 --> 00:18:59,990
20 implementation. So, in this slide I
took two different hex dumps, and these
153
00:18:59,990 --> 00:19:09,399
hex times were are within this expand key
function. And they they are well basically
154
00:19:09,399 --> 00:19:16,970
two snapshots - one right before these
bugs become apparent: so before this this
155
00:19:16,970 --> 00:19:25,480
endianness conversion, and right after on
the lower half. So you very nicely see the
156
00:19:25,480 --> 00:19:32,140
different variables being put into all the
different key inputs being put into these
157
00:19:32,140 --> 00:19:34,140
this memory blocks. So here, it would
158
00:19:34,140 --> 00:19:39,331
spell out invalid sect ID, you know, the
constants (Not)Petya uses. Here you would
159
00:19:39,331 --> 00:19:46,309
see the key and here, so it's broken into
two halves. Additionally you would see the
160
00:19:46,309 --> 00:19:53,710
nonce here. And what really sticks out is
this bunch of zeros here. So this this
161
00:19:53,710 --> 00:20:01,380
higher part of this a 64-bit variable
isn't even used - is it's not even filled.
162
00:20:01,380 --> 00:20:07,170
So this is well the first problem here,
and after the endianness conversion you
163
00:20:07,170 --> 00:20:13,820
see that it's not really an endianness
conversion but it's more of a nulling of
164
00:20:13,820 --> 00:20:23,060
of bytes. So the result would be that this
initially 64 bit variable would be just
165
00:20:23,060 --> 00:20:32,600
16-bit in length. And, as I said earlier,
the original salsa implementation would be
166
00:20:32,600 --> 00:20:44,610
2^70s key lengths. And right now we have
16 bits times 64 bytes in in key lengths
167
00:20:44,610 --> 00:20:51,299
which would result an in 26 bits in key
lengths. Which would be a measly 4
168
00:20:51,299 --> 00:20:57,289
megabytes in key lengths. So this is the
this was a very interesting observation I
169
00:20:57,289 --> 00:21:08,730
made there and this would be possible then
to decrypt together with the many times
170
00:21:08,730 --> 00:21:17,720
pad properties of this cipher which make
it really easy to break. So to quickly
171
00:21:17,720 --> 00:21:24,980
summarize this part of the talk - so we
have a very very short key stream of just
172
00:21:24,980 --> 00:21:32,009
4 megabytes, it's highly repetitive
repetitive. So for each secretary progress
173
00:21:32,009 --> 00:21:41,620
you would only have a progress of one byte
at a time. So only 26 bits remain of the
174
00:21:41,620 --> 00:21:50,230
whole stream. And as I said, the many
times pad property's a very nice thing to
175
00:21:50,230 --> 00:22:00,190
to analyze. I could come around to
implement a small joke here, so this salsa
176
00:22:00,190 --> 00:22:08,690
implementation I would only call "LOLsa"
from now on. Sorry, is a bad joke sorry!
177
00:22:08,690 --> 00:22:16,630
So, the the main goal is to derive the
keystream, and as I'm not really a crypto
178
00:22:16,630 --> 00:22:22,029
expert, the basically the only attack I
know it would be a known plaintext attack
179
00:22:22,029 --> 00:22:28,470
so this was my goal there because it's so
straightforward to do that. And in the
180
00:22:28,470 --> 00:22:34,909
remainder of the talk I will tell you how
I did that. So without further ado, let's
181
00:22:34,909 --> 00:22:41,710
exploit these failures and see how much of
the plaintext we can actually get from a
182
00:22:41,710 --> 00:22:47,050
(Not)Petya infected drive.
So the modulus operandi
183
00:22:47,050 --> 00:22:53,299
of (Not)Petya would look
somewhat like that. This, so let's let's
184
00:22:53,299 --> 00:22:58,480
stop with the with the left hand side of
the of this slide, and concentrate on the
185
00:22:58,480 --> 00:23:03,860
right hand side. For those of you who you
are not really intimately familiar with
186
00:23:03,860 --> 00:23:10,890
NTFS - I wasn't before analyzing Petya or
(Not)Petya as well so no worries. It's
187
00:23:10,890 --> 00:23:17,659
quite simple - so every NTFS partition has
something called an master file table.
188
00:23:17,659 --> 00:23:24,940
MFT, abbreviated. And it would contain
some metadata about the file. For example,
189
00:23:24,940 --> 00:23:32,399
the file name, the file size, and if the
file is small enough, it would even fit
190
00:23:32,399 --> 00:23:42,320
the actual content of the file into this
record. So, as I said, MFT is just list of
191
00:23:42,320 --> 00:23:50,091
records. And if the file is larger it
would have a pointer, a so called data
192
00:23:50,091 --> 00:23:57,860
run, which would point to a cluster or
sector on the disk on the partition which
193
00:23:57,860 --> 00:24:06,020
would then actually be the the payload
data. One of these MFT records is one
194
00:24:06,020 --> 00:24:12,330
kilobyte in size. So now to the actual
implementation. So let's zoom out a bit
195
00:24:12,330 --> 00:24:19,370
and see how this LOLsa implementation is
used in (Not)Petya. So it would basically
196
00:24:19,370 --> 00:24:26,399
just iterate over over all of these MFT
records, and then check if this record
197
00:24:26,399 --> 00:24:33,230
would put into would point to a file. If
that is the case, it would encrypt the
198
00:24:33,230 --> 00:24:41,879
first kilobyte of the file, and then would
encrypt the record itself. This
199
00:24:41,879 --> 00:24:47,769
implementation is good for a bunch of
reasons - it's very fast: You would only
200
00:24:47,769 --> 00:24:52,259
need to encrypt the first kilobyte, and
this is this first kilobyte contains
201
00:24:52,259 --> 00:25:03,440
really really important information. For
example, headers, or especially compressed
202
00:25:03,440 --> 00:25:09,191
files have these really important header
structures there. Additionally, your file
203
00:25:09,191 --> 00:25:14,429
recovery tools wouldn't be able to work
anymore because most of them rely on this
204
00:25:14,429 --> 00:25:23,160
very header. And the second thing is this
MFT is can be considered as table of
205
00:25:23,160 --> 00:25:31,000
contents. So with no metadata, with with
no pointers to these to the files, you
206
00:25:31,000 --> 00:25:37,870
won't have anything there to work with to
recover from. And this is a I mean from
207
00:25:37,870 --> 00:25:44,320
from the implementation standpoint it's
very neat, because it's fast and it's a
208
00:25:44,320 --> 00:25:49,729
somewhat thorough. As the MFT is
209
00:25:49,729 --> 00:25:57,450
really important, my idea was to to
recover that first and then check what
210
00:25:57,450 --> 00:26:07,090
what comes out from there and see how I
can can further progress there with the
211
00:26:07,090 --> 00:26:14,180
decryption of the files. So the metadata
would would be of most importance there.
212
00:26:14,180 --> 00:26:27,419
I'm a visual person, and here I took two
disk dumps from a from one of my test
213
00:26:27,419 --> 00:26:33,339
disks. So I infected a clean system with
(Not)Petya and let it encrypt the hard
214
00:26:33,339 --> 00:26:38,270
drive. And on the left-hand side you see
the plaintext on and on the right-hand
215
00:26:38,270 --> 00:26:45,190
side you see the encrypted data. So to
just get a better picture about the
216
00:26:45,190 --> 00:26:54,220
encryption process. On the far left-hand
side fancy PowerPoint altered animation,
217
00:26:54,220 --> 00:27:01,059
you see some kind of indicator so which
which would tell you at which offset, how
218
00:27:01,059 --> 00:27:08,320
much of the of the data has actually been
different. And you see the whole disk is
219
00:27:08,320 --> 00:27:19,600
more or less being encrypted. However, you
see at the far bottom part here it's more
220
00:27:19,600 --> 00:27:27,199
dark red. And this is actually the MFT, so
the MFT is towards the end of the disk
221
00:27:27,199 --> 00:27:33,630
sometimes. But this might be a
misconception. So my my idea was something
222
00:27:33,630 --> 00:27:38,779
like this: we have two input sizes, right?
We have the the encrypted MFT, and we have
223
00:27:38,779 --> 00:27:47,330
encrypted files. And first i would analyze
the MFT, and then derive the key stream
224
00:27:47,330 --> 00:27:55,850
from that. After that analysis stage had
been finished I would put the key stream
225
00:27:55,850 --> 00:28:03,970
back into the this this little box here,
and actually decrypt that. And then out
226
00:28:03,970 --> 00:28:09,659
comes the decrypted MFT. And with that and
the key stream I would be able to find the
227
00:28:09,659 --> 00:28:16,899
encrypted files on the disk, and then be
able to decrypt them; then be ready with
228
00:28:16,899 --> 00:28:24,160
it right? So this was my initial idea
there and so let's start with the
229
00:28:24,160 --> 00:28:35,059
decryption of the MFT. Known plaintext
attack, right? So an MFT you looks for
230
00:28:35,059 --> 00:28:40,320
from from the viewpoint of the keystream,
somewhat like this. So you would have here
231
00:28:40,320 --> 00:28:46,800
the first, the second and so on MFT
records. And on the on the column you will
232
00:28:46,800 --> 00:28:54,510
have the actual byte that is used as key
to encrypt the key stream. Remember, the
233
00:28:54,510 --> 00:29:03,829
operation that that encrypts the you know
the the key stream and the the plaintext
234
00:29:03,829 --> 00:29:07,350
is just a mirror XOR operation.
So you have the the key
235
00:29:07,350 --> 00:29:15,769
stream and the plaintext, and it's plainly
- so you can switch forth and back between
236
00:29:15,769 --> 00:29:21,170
plaintext and ciphertext and even the key
stream with a with just applying an XOR
237
00:29:21,170 --> 00:29:29,850
operation. So what you see here is for the
very first records you only have very few
238
00:29:29,850 --> 00:29:36,680
key stream bytes or very few sample bytes.
However, as the progress as you make
239
00:29:36,680 --> 00:29:41,610
progress with the analysis and then you
will have more and more of these sample
240
00:29:41,610 --> 00:29:49,560
bytes to collect from and this this will
give you more confidence in the in the
241
00:29:49,560 --> 00:29:56,930
result, and the may be known key stream
then. The question is, does the MFT hold
242
00:29:56,930 --> 00:30:02,889
enough plaintext to do some some kind of
known plaintext attack? So let's look into
243
00:30:02,889 --> 00:30:13,399
the specification. The MFT record has
basically two fields. So there is this the
244
00:30:13,399 --> 00:30:19,570
standard information, which is a well-
defined structure and there's something
245
00:30:19,570 --> 00:30:25,840
else called attribute list, which is a
quite dynamic structure and this would be
246
00:30:25,840 --> 00:30:32,799
a somewhat more different, difficult to
clean plan text from. So I concentrate on
247
00:30:32,799 --> 00:30:38,200
this first part. And the first part
quickly turned out to be quite constant
248
00:30:38,200 --> 00:30:48,590
for many or most of the MFT records. And
you see it starts with FILE and then as
249
00:30:48,590 --> 00:30:55,210
some some hex digits after that. And
although on the far bottom part of the
250
00:30:55,210 --> 00:31:02,210
slide, I added my yeah certainty level. So
the the certainty level would be the
251
00:31:02,210 --> 00:31:08,749
number of different sample bytes I would
have multiplied by the confidence I would
252
00:31:08,749 --> 00:31:16,559
have in that sample byte being actually
this this plain text. So you see for the
253
00:31:16,559 --> 00:31:22,759
very first record, we would have a quite
low, of a low certainty. I mean, it's just
254
00:31:22,759 --> 00:31:30,580
one byte, right? Oh, the two byte skipping
is I mean quite a forward considering you
255
00:31:30,580 --> 00:31:37,370
would have usually 512 bytes per sector on
a disk, and the MFT record is one kilobyte
256
00:31:37,370 --> 00:31:47,919
in size, so the stream would progress two
bytes. And for record 100, so for if for
257
00:31:47,919 --> 00:31:54,820
the 100th record I would have a certainty
of four. You know, I would just assume
258
00:31:54,820 --> 00:32:02,730
these eight plaintext bytes here, divided
by 2, with an resulting 4. This wasn't
259
00:32:02,730 --> 00:32:06,320
really satisfactory.
The problem there was towards
260
00:32:06,320 --> 00:32:12,720
the end I would have many many unknown
records because I would was concentrating
261
00:32:12,720 --> 00:32:19,799
on on the very first parts of the header.
So the remainder of the key stream, the
262
00:32:19,799 --> 00:32:25,799
very end of the key stream wasn't be able
to being analyzed and eventually
263
00:32:25,799 --> 00:32:30,159
decrypted. So I thought of something
different. And there was something like a
264
00:32:30,159 --> 00:32:39,799
I would call a byte histogram. So for
every offset the MFT record, i would i
265
00:32:39,799 --> 00:32:48,860
will then calculate creatin and a
histogram and check how many different
266
00:32:48,860 --> 00:32:53,549
bytes are there actually for plaintext,
you know, it's a plaintext known plaintext
267
00:32:53,549 --> 00:32:58,560
attack so I would need some kind of
plaintext and would do that for every
268
00:32:58,560 --> 00:33:07,509
offset for every record. And so these the
questions there how to get many MFT
269
00:33:07,509 --> 00:33:12,039
records - it's quite easy if you have some
nice colleagues you just need to hang them
270
00:33:12,039 --> 00:33:16,999
all of the balcony and shake them a bit
then more or less voluntarily they will
271
00:33:16,999 --> 00:33:25,080
give you some MFT keys to work with. And
the result of that is quite nice: you, I
272
00:33:25,080 --> 00:33:30,640
mean for for the very first, there's
nothing much you can do the very first
273
00:33:30,640 --> 00:33:35,929
record will always have very few sample
bytes. But as the stream progresses and
274
00:33:35,929 --> 00:33:41,970
you will have a dramatic change there so
from this relatively low certainty of
275
00:33:41,970 --> 00:33:51,499
four, I could increase that to more than
thirty. So this is somewhat nice, and ever
276
00:33:51,499 --> 00:34:00,480
bit of doing science, this table drops out
from nowhere. So I compared these two
277
00:34:00,480 --> 00:34:08,230
attack types. So, let's read that from
from right to left. On the on the far
278
00:34:08,230 --> 00:34:16,270
right, I have for the first approach about
98% of the MFT records being successfully
279
00:34:16,270 --> 00:34:22,070
recovered. You know, with the good thing
with science and with all this academic
280
00:34:22,070 --> 00:34:29,659
approach is you have a ground truth. So I
have a plaintext an unencrypted hard drive
281
00:34:29,659 --> 00:34:36,920
which were virtually unordered from
something right after infection, and then
282
00:34:36,920 --> 00:34:43,370
you let execute the the whole infection
and encryption process. And then you can
283
00:34:43,370 --> 00:34:49,120
differentiate and take you knows several
snapshots throughout the infection, change
284
00:34:49,120 --> 00:34:54,539
different key values and all the stuff. So
this is a very nice thing about this
285
00:34:54,539 --> 00:35:02,830
academic approach I was taking the other
So I could I could exactly pinpoint how many
286
00:35:02,830 --> 00:35:14,280
of these records were perfectly recovered.
So for the byte histogram approach I could
287
00:35:14,280 --> 00:35:17,940
decrypt almost all of the records, which
is quite nice because then we have a high
288
00:35:17,940 --> 00:35:28,250
quality MFT to work with. What's also
quite nice is that we have zero wrong key
289
00:35:28,250 --> 00:35:34,210
stream bytes. What's not so nice, however,
is that I was only able to recover about
290
00:35:34,210 --> 00:35:43,130
1.3 percent of the overall key stream. And
remember - this this key stream is about 4
291
00:35:43,130 --> 00:35:47,840
megabytes in length and I was able to
recover only 50 kilobytes of that, so we
292
00:35:47,840 --> 00:35:55,540
can't recover all of the the files. Or is
that so? This is this was my next question
293
00:35:55,540 --> 00:36:05,370
there. And so I drew another nice diagram.
This is the key stream; in the this is the
294
00:36:05,370 --> 00:36:15,880
MFT, sorry, in the key stream. So the the
key stream is only filled and in sample
295
00:36:15,880 --> 00:36:24,310
bytes at this 2 megabytes mark. And the
question is, are there many files in this
296
00:36:24,310 --> 00:36:29,430
area being encrypted or is there some
other bug I could exploit. And I checked
297
00:36:29,430 --> 00:36:34,680
where the files would lie into this the
key stream. So I would check how many
298
00:36:34,680 --> 00:36:41,470
files are at which location in the key
stream being encrypted. And you see the
299
00:36:41,470 --> 00:36:47,550
key stream is used all over the place - so
I mean sometimes it's used more, sometimes
300
00:36:47,550 --> 00:36:56,110
it's used just the less, however, it's
basically used all over the place. And so
301
00:36:56,110 --> 00:37:00,611
this much of the key stream could in a
perfect scenario be, I mean, perfect
302
00:37:00,611 --> 00:37:09,340
scenario being a perfect known plaintext
oracle could theoretically be recovered.
303
00:37:09,340 --> 00:37:17,570
However, this is somewhat of a problem
here and in the next part of the talk I
304
00:37:17,570 --> 00:37:26,190
will present you how I was able to solve
this problem as well. So remember when the
305
00:37:26,190 --> 00:37:32,290
file system is actually encrypted by
(Not)Petya, the file system looks somewhat
306
00:37:32,290 --> 00:37:37,051
like this. So you would have the MFT which
is totally garbled so you won't have any
307
00:37:37,051 --> 00:37:42,250
of any nice file pointers or data runs
pointing through those files. You won't
308
00:37:42,250 --> 00:37:47,520
have any nice file names and all the
stuff. But with the first stage being
309
00:37:47,520 --> 00:37:53,320
finished, the MFT looks really nice - I
mean like almost a hundred percent
310
00:37:53,320 --> 00:37:57,530
of the records could be
recovered. So it looks
311
00:37:57,530 --> 00:38:04,430
somewhat like this. So you have a bunch of
metadata you can now use to analyze the
312
00:38:04,430 --> 00:38:08,960
the remainder of the files and the
remainder of the encryption. So all this
313
00:38:08,960 --> 00:38:17,090
MFT or almost always actually decrypted.
And for files you would have the very
314
00:38:17,090 --> 00:38:24,830
first kilobyte being encrypted. The
remainder of the file, the, I mean, most
315
00:38:24,830 --> 00:38:30,540
files are more than a kilobyte in size,
right? So all the rest is not encrypted.
316
00:38:30,540 --> 00:38:37,280
So you would have all this data and
metadata to collect information and to to
317
00:38:37,280 --> 00:38:45,520
use to exploit as-known plaintext as
indicators for known plaintext. So I
318
00:38:45,520 --> 00:38:56,060
thought of three different approaches to
you know to attack this problem. Basically
319
00:38:56,060 --> 00:39:01,620
I was thinking about: okay what different
files are there, and I was quickly
320
00:39:01,620 --> 00:39:08,100
thinking about different file types. And I
mean, there are I mean the file type can
321
00:39:08,100 --> 00:39:12,890
be easily gleaned from this, right?
Because you would have the file extension
322
00:39:12,890 --> 00:39:18,540
and it would be basically the file type.
And you would have two different types of
323
00:39:18,540 --> 00:39:22,990
files - you would have structured files
and unstructured files. So I thought of
324
00:39:22,990 --> 00:39:28,730
these and you would have something like,
yeah, source code, which I would consider
325
00:39:28,730 --> 00:39:34,610
as more or less unstructured. And I was
calculating the histogram, so this would
326
00:39:34,610 --> 00:39:39,980
give me some kind of prevalence towards
different bytes in the key stream. So it
327
00:39:39,980 --> 00:39:46,600
would be somewhat like a guest plaintext
attack or something like that. The next
328
00:39:46,600 --> 00:39:54,670
thing for structured files would be to do
the very same approach as with the MFT
329
00:39:54,670 --> 00:40:00,930
records. I would calculate the histogram
for every offset of the first kilobyte,
330
00:40:00,930 --> 00:40:07,690
and then quickly see how how many
different bytes are there per offset. And
331
00:40:07,690 --> 00:40:14,583
the last approach uses somewhat more data.
It uses some of the metadata, and also
332
00:40:14,583 --> 00:40:23,870
some of the file data. I will go into this
right now. So, what I basically have here
333
00:40:23,870 --> 00:40:29,410
as I said it's only this this little
portion of the files encrypted. The whole
334
00:40:29,410 --> 00:40:33,830
remainder of the file is not encrypted,
which is quite nice. And also the file
335
00:40:33,830 --> 00:40:40,490
name the file sizes not encrypted.
So what I use, what I would do here
336
00:40:40,490 --> 00:40:44,970
is create a database of
known files of known
337
00:40:44,970 --> 00:40:51,860
Windows system files, for example. Y'all
might remember these nice background
338
00:40:51,860 --> 00:40:59,310
images fonts all this stuff - plaintext
is flying around everywhere if you just
339
00:40:59,310 --> 00:41:07,220
look for it. And I would have basically
three different, yeah, three three
340
00:41:07,220 --> 00:41:17,300
different distinctors between those to
know which which is the correct plaintext.
341
00:41:17,300 --> 00:41:24,520
So there is this this key file name, the
file size, and then the hash of this whole
342
00:41:24,520 --> 00:41:32,180
remainder, of this whole tier. So if all
these 3-tuple would match, then I would
343
00:41:32,180 --> 00:41:38,640
consider this as a proper plaintext.
However, there are some collisions, so
344
00:41:38,640 --> 00:41:48,090
this is this is not really something that
is straightforward. So the initial idea of
345
00:41:48,090 --> 00:41:55,760
having of only needing to analyze the MFT
and then could just being being able to
346
00:41:55,760 --> 00:42:03,920
straightforward decrypt files needed to be
altered a bit. So I added this database of
347
00:42:03,920 --> 00:42:11,920
known files there, I added another another
analysis stage in this nice box here, and
348
00:42:11,920 --> 00:42:19,970
then I would be able to decrypt the files,
eventually. So let's do a bit of science
349
00:42:19,970 --> 00:42:26,430
and check if this approach would be
worthwhile pursuing on a real-world
350
00:42:26,430 --> 00:42:37,690
scenario. So let the science cat do its
science, let me have a drink. So whenever
351
00:42:37,690 --> 00:42:46,920
you did do here is to create a database of
known files - I collected a bunch of
352
00:42:46,920 --> 00:42:55,290
default Windows installations, which
resulted in about 340,000 unique files in
353
00:42:55,290 --> 00:43:00,090
it. Then I calculated, you know, the the
different file type histograms I talked
354
00:43:00,090 --> 00:43:08,910
about, I prepared my test setup, I added
there 1000 different files. And you should
355
00:43:08,910 --> 00:43:15,760
note that these files were not part of
this known files database - they were
356
00:43:15,760 --> 00:43:20,520
different from that because otherwise it
would have been easy to do. Then I would
357
00:43:20,520 --> 00:43:28,010
infect this machine and then let its
encrypt by (Not)Petya and then attempting
358
00:43:28,010 --> 00:43:40,170
recovery. And these are the results there.
So, I did this with 4 different runs, so I
359
00:43:40,170 --> 00:43:46,430
tried every approach separately, and then
combined the three approaches. And the
360
00:43:46,430 --> 00:43:52,240
outcome was something like this: So I
would have only two files by the general
361
00:43:52,240 --> 00:43:59,950
histogram approach being able to
be to decrypt. At least 8%
362
00:43:59,950 --> 00:44:06,510
where I will were yet decrypted by the
location histogram approach. And by the
363
00:44:06,510 --> 00:44:12,480
known files approach over 90% of the files
could be successfully recovered. And even
364
00:44:12,480 --> 00:44:22,280
better, the combined outcome would be
almost all files being able to decrypt.
365
00:44:22,280 --> 00:44:30,530
So, so much about academia. So the problem
there is if you apply this to the real
366
00:44:30,530 --> 00:44:37,350
world, you could get into more trouble
there. And there was lots and lots of more
367
00:44:37,350 --> 00:44:42,910
to think about so. There were, for
example, non default windows installations
368
00:44:42,910 --> 00:44:48,500
with the whole history of updates so this
might be really interesting from a
369
00:44:48,500 --> 00:44:56,010
forensics perspective. Moreover, there's
lots of installed programs to derive known
370
00:44:56,010 --> 00:45:04,610
plaintext from - for example, dotnet uses
a vast source of known plaintext or JDK
371
00:45:04,610 --> 00:45:11,560
installations. So, especially the JDK
would would result in about tens of
372
00:45:11,560 --> 00:45:17,051
thousands of different source code and
HTML files. So this is this really was
373
00:45:17,051 --> 00:45:27,940
really quite nice. The drawback there was,
so there was so much data to collect, the
374
00:45:27,940 --> 00:45:35,170
first attempts failed miserably because of
the sheer amount of RAM I was using. And
375
00:45:35,170 --> 00:45:43,960
this would would result in the admins
constantly giving me more more RAM in my
376
00:45:43,960 --> 00:45:52,900
VM so I would eventually end up with, I
think, 128 gigabytes of RAM and my my test
377
00:45:52,900 --> 00:46:00,080
VM. Also you have a much larger master
file table you know because of all these
378
00:46:00,080 --> 00:46:06,230
files that would need to be stored, so to
put them in in comparison. So this nice
379
00:46:06,230 --> 00:46:13,530
working prototype, so this nice test
setup, I mean, would have an MFT of about
380
00:46:13,530 --> 00:46:20,310
26 megabytes. And for real-world scenarios
you would have something like at least 500
381
00:46:20,310 --> 00:46:26,980
megabytes, and even MFT could be even like
a couple of gigabytes in size. So this
382
00:46:26,980 --> 00:46:33,060
means much more plaintext. So for through
these really large MFTs you could quickly
383
00:46:33,060 --> 00:46:40,180
recover the whole key stream, the whole
four megabytes just by looking at the MFT.
384
00:46:40,180 --> 00:46:46,600
And, in summary, this means that the
decryption of (Not)Petya encrypted drives
385
00:46:46,600 --> 00:46:57,301
is possible. So, for for the file systems
the drives, I have looked at it, was
386
00:46:57,301 --> 00:47:03,240
really I mean ever after having all these
these first bugs out of the way,
387
00:47:06,891 --> 00:47:10,410
I was able to decrypt and
recover all the files there. So
388
00:47:10,410 --> 00:47:17,550
there's a good chance the vacation photos
can be recovered as well. And this will
389
00:47:17,550 --> 00:47:24,010
conclude my talk, so quick summary -
(Not)Petya has some severe cryptographic
390
00:47:24,010 --> 00:47:33,020
failures and flaws, so I would only be
able to call this LOLsa and not salsa
391
00:47:33,020 --> 00:47:41,210
anymore. It might be possible to further
look into this, this you know this expand
392
00:47:41,210 --> 00:47:48,790
key and thing. It it has really really a
bunch of more cryptographic failures in
393
00:47:48,790 --> 00:47:56,310
it. I didn't look into that deeper but I
know some of you guys are professors and
394
00:47:56,310 --> 00:48:01,140
this might be a nice homework for your
students to look at this (Not)Petya
395
00:48:01,140 --> 00:48:07,510
implementation and check out some, you
know, more advanced crypto analysis
396
00:48:07,510 --> 00:48:15,690
methods. And you should note that this
hook this this whole (Not)Petya thing here
397
00:48:15,690 --> 00:48:22,050
I described the whole cryptographic flaws
there are not just in (Not)Petya. They are
398
00:48:22,050 --> 00:48:28,080
you see the brackets there: there they are
in every each and every version of Petya.
399
00:48:28,080 --> 00:48:38,251
So all of the drives that you potentially
have saved can be decrypted. And so my
400
00:48:38,251 --> 00:48:45,210
last point is if any of you or any of us
falls victim to ransomware you really
401
00:48:45,210 --> 00:48:51,850
should keep the drives. You keep them
untouched in a locker and wait for a talk
402
00:48:51,850 --> 00:48:59,090
like this basically. And then hope that
someone comes around and then be able to
403
00:48:59,090 --> 00:49:06,540
decrypt the drives and then, you will have
your vacation photos back. So that's all
404
00:49:06,540 --> 00:49:09,010
folks, thank you for your attention.
405
00:49:09,010 --> 00:49:13,210
Applause
406
00:49:13,210 --> 00:49:16,090
Herald: Thank you very much Sebastian. Now
407
00:49:16,090 --> 00:49:19,330
it's time for questions, please queue up
by the microphones.
408
00:49:26,270 --> 00:49:27,910
Mic 1: Hi, well thank you very much for
409
00:49:27,910 --> 00:49:33,550
sharing your findings with us. I'm from
Rotterdam the largest harbour in Europe,
410
00:49:33,550 --> 00:49:36,230
and as you might know, we were struck by
Petya
411
00:49:36,230 --> 00:49:39,420
Sebastian Yes
Mic 1: Two terminals went down for a
412
00:49:39,420 --> 00:49:44,260
couple of days, a couple of hundred
billion euros of damage. Your approach is
413
00:49:44,260 --> 00:49:48,930
quite theoretically, so now to practice -
if you were there in this summer with
414
00:49:48,930 --> 00:49:53,840
these findings, would you've been able to
help us and decrypt the files and get all
415
00:49:53,840 --> 00:49:58,000
the companies up and running again? Or is
this too academic?
416
00:49:58,000 --> 00:50:04,920
Sebastian: No, it's a practical approach I
mean, I work for CrowdStrike and we had
417
00:50:04,920 --> 00:50:13,640
some occasions where we were able to help
the customers. So it's a very practical
418
00:50:13,640 --> 00:50:21,030
thing to do so. And I was trying to
insinuate this with, you know, this slide
419
00:50:21,030 --> 00:50:26,350
here. So I was talking about the real
world in this scenario. So I looked at
420
00:50:26,350 --> 00:50:32,100
about 50 different encrypted hard drives
with (Not)Petya, and I was able to decrypt
421
00:50:32,100 --> 00:50:38,730
all of them, or most of them. Mostly the
the ones not being able to decrypt or to
422
00:50:38,730 --> 00:50:45,010
some, well, let's say, level 8 mistakes.
Mic 1: Awesome. Have you shared your
423
00:50:45,010 --> 00:50:48,930
findings with nomoreransoms.org?
Sebastian: No, I don't know about this
424
00:50:48,930 --> 00:50:50,910
site
Mic 1: They provide decryption tools for
425
00:50:50,910 --> 00:50:56,860
ransomware. Please do, thank you
Herald: Microphone six, please
426
00:50:56,860 --> 00:51:01,930
Mic 6: Thank you, in the beginning you
mentioned that basically the key was
427
00:51:01,930 --> 00:51:05,490
shortened to what was a 24-bit, something
like that?
428
00:51:05,490 --> 00:51:09,560
Sebastian: 26, yes
Mic 6: 26, yeah. From that point, wasn't a
429
00:51:09,560 --> 00:51:13,760
brute-force attack way faster and way more
reliable?
430
00:51:13,760 --> 00:51:20,820
Sebastian: Oh no no, don't get me wrong
there. So the keystream length was 2^26,
431
00:51:20,820 --> 00:51:27,660
so the keystream length was four
megabytes. So you wouldn't be able to
432
00:51:27,660 --> 00:51:34,650
brute-force that. So sorry, do you get
that? The number of bytes was four
433
00:51:34,650 --> 00:51:39,120
megabytes, and you couldn't be able to
brute-force that.
434
00:51:39,120 --> 00:51:43,740
Mic 6: Yeah but you already mention at the
beginning that you basically shortened it
435
00:51:43,740 --> 00:51:49,940
down to the possibility of at most two to
the power of 26, and it is calculable.
436
00:51:49,940 --> 00:51:56,870
Sebastian: Yes yes, I totally get the
question. But you're you're missing the
437
00:51:56,870 --> 00:52:03,230
point there. So it's not the key space,
2^26, but the key length is 2^26, which
438
00:52:03,230 --> 00:52:10,660
would be something - I I'm not good at
that converting this to decimal. Would be
439
00:52:10,660 --> 00:52:16,930
something like, let me check, two to
the... I mean, here, math guys, computer
440
00:52:16,930 --> 00:52:21,610
guys: how many bits is that?
[Inaudible audience answer]
441
00:52:21,610 --> 00:52:25,510
Sebastian: Say again?
Crowd: A lot?
442
00:52:25,510 --> 00:52:31,370
Sebastian: A lot! So it's, I mean, it's
it's four megabytes of keylength and you
443
00:52:31,370 --> 00:52:35,220
couldn't just brute force that because you
you would have each of these
444
00:52:35,220 --> 00:52:43,660
four megabytes you would have to brute
force. Got that? So the key is not 2^26
445
00:52:43,660 --> 00:52:52,290
but the key length, the keystream length,
is that long. Got that? So yeah, this is
446
00:52:52,290 --> 00:52:58,170
the key space would be longer than the
Bible. You know, and you couldn't just
447
00:52:58,170 --> 00:53:03,050
brute force the Bible, the text of the
Bible. I mean given enough time yes but
448
00:53:03,050 --> 00:53:08,990
you know we will all know the stories with
in monkeys and typewriters. I mean we can
449
00:53:08,990 --> 00:53:12,500
talk about that that offline but you're
you're mixing up two different numbers
450
00:53:12,500 --> 00:53:18,370
there.
Mic 6: Yeah I guess, thank you.
451
00:53:18,370 --> 00:53:20,350
Herald: Questions from the Internet,
please
452
00:53:20,350 --> 00:53:25,710
Signal Angel: Does the MFT encryption work
the same for Petya and (Not)Petya?
453
00:53:25,710 --> 00:53:34,400
Sebastian: Yes, the underlying mechanism
is the same. The cryptography differs in
454
00:53:34,400 --> 00:53:43,160
such a way that the constants number is
different. So, this little guy here - this
455
00:53:43,160 --> 00:53:50,110
is different. It would be usually like
expand key something-something. And here
456
00:53:50,110 --> 00:53:56,980
it's invalid sect ID. So it's somewhat
different, but the the MFT encryption; I
457
00:53:56,980 --> 00:54:03,170
mean the the bytecode the and the
algorithm is the very same.
458
00:54:03,170 --> 00:54:12,410
Signal Angel: Thanks
Herald: Any more questions? Then please
459
00:54:12,410 --> 00:54:14,820
give a great round of applause to
Sebastian
460
00:54:14,820 --> 00:54:18,320
Sebastian: Thank you
461
00:54:18,320 --> 00:54:24,130
Applause
462
00:54:24,130 --> 00:54:44,000
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!