35C3 - First Sednit UEFI Rootkit Unveiled

35C3 preroll music

Herald angel: OK so our next talk is given
by Frederic Vachon, so please give him a

warm round of applause.
Applause

Vachon: Okay so hello everyone. Thank you
for having me today. I'm really happy to

be to be here. So today I'm going to talk
about a research that a colleague of mine,

Jean-Ian Boutin and I did earlier this
year and which led us to the discovery of

a UEFI rootkit. So very quickly. My name
is Frederic Vachon, I'm a malware

researcher at ESET and I've been working
there for the last two years and for the

last year or so I've been really focusing
on boot level threats and UEFI firmware

reverse engineering. So let's look at the
agenda for this talk. So the first thing I

want to talk about is what is Sednit very
quickly. Then I'll talk about LoJack,

which is an anti-theft software and past
research related to this software and the

reason for that is that the UEFI rootkit
that I'll talk about really mimics the

architecture of this legitimate software.
Then we'll move on and I'll talk a little

bit about compromised LoJack agents that
were found in the wild, and finally I'll

jump into the UEFI rootkit, well, where
I'll talk about the tools around the

rootkit and the UEFI rootkit itself. So,
Sednit. Sednit is an espionage group

active since the early 2000s and it is
also known as Fancy Bear, APT28 and

STRONTIUM, so maybe you know this group by
one of these alternative names. And Sednit

is the name basically that we use at ESET.
So this group was very visible in the past

few years as being allegedly behind some
pretty mysterious hacks like the hack

against the Democratic National Committee,
the DNC, where some emails were leaked

online. The hack against the World Anti-
Doping Agency as well as the hack against

the French broadcasting network TV5 Monde.
But at ESET when we're talking about

Sednit, we're really talking about the
tools and the different campaigns that

were led using these tools, and we're not
talking about the people who are operating

this malware because we don't have the
information necessary to draw such

conclusions. However, in July 2018 the
U.S. Department of Justice named the group

as being responsible for the Democratic
National Committee hack in this specific

indictment. And what's interesting is that
the tools that we analyzed were... are

named in this specific indictment and they
also mention who's the authors of these

malware. And also early, not earlier, but
closer from from now, in October 2018, the

Department of Justice issued another
indictment naming pretty much the same

people are related to the World Anti-
Doping Agency hack. And the way that

Sednit will usually infect their targets
is by sending phishing emails, so

sometimes they will contain malicious
links and some of the time malicious

attachments. OK. So now let's talk a
little bit about LoJack. So Lojack is an

anti-theft software as I mentioned, and it
was previously known as Computrace. So

maybe you know the solution by this name
instead. And it is made by Absolute

Software. So, yeah, and this solution is
built in many laptops. But an anti-theft

software needs to be as persistent as
possible if you want it to be reliable. It

needs to be... to survive an operating
system re-install or a hard disk

replacement. So to achieve this what
Absolute Software did is that they added a

module in the UEFI BIOS itself. Yeah and
the solution needs to be activated in the

BIOS setup. So with a persistence
mechanism like that coming from the

firmware, it's really attracted the
attention of security researchers, who

looked into this to find vulnerabilities
basically. And at BlackHat in 2009 there

was a talk there where the architecture of
the solution was described and several

design vulnerabilities in the agent were
also described there. So let's look at the

architecture of LoJack back then. So the
first thing that we have here is a module

in the UEFI BIOS, and this module will
write a file to the Windows partition. So

this file is called autochk.exe, which
replaces the legitimate autochk.exe, whose

job is to perform filesystem integrity
check during early Windows boot. So by

replacing this agent during early Windows
boot it will be executed. And from there

it will drop rpcnetp.exe, which is the
small agent, and will install a service

and when Windows will run it will run this
service, and rpcnetp will be launched at

this point. And it will inject itself into
svchost , and then from there it will

inject itself into Internet Explorer which
is pretty interesting because it's very

shady and that's something that we see
pretty much all the time in malware but

not often in legitimate software. And from
Internet Explorer it will then communicate

with the command and control server and it
will download the full recovery agent. So

now let's look at some of the issues that
the researchers found with this... in this

solution. So one of the vulnerabilities
they found is very interesting for us and

in fact that's really the only one that
matters for this talk. And this is a

configuration file vulnerability. So the
configuration is embedded into rpcnetp.exe

and it is encrypted but it is encrypted
with a very weak algorithm. So it is in

single byte XOR key, and it is not
authenticated whatsoever. And what's in

this configuration file? Well, that's
where you can find the server, the command

and control server. So an attacker can
just change this configuration to point to

its own attacker-controlled server. So we
knew that this vulnerability existed for a

while, it was back in 2009, but we had no
evidence of it being used in the wild.

Until earlier this year, when Arbor
Networks published a blog post where they

described some modified small agent with
modified configuration where the domains

that were embedded in this configuration
were linked to old Sednit domains. So

let's go back to LoJack architecture and
look at where this attack took place. So

it took place at this level here. So from
there we did some detection for this

malware and it was... and we hunted to
gather as much samples as as we could. And

it was fairly simple because they always
modified the same exact version of the

agent and they modified, so that's what we
can see here, so they modified the command

and control server. And here we see the
encrypted version of course. So by looking

at this we will look at ESET's telemetry
and found out that there was a few

organizations that were hit mostly in the
Balkans, in Central Europe as well as in

Eastern Europe. These were military and
diplomatic organizations. And what's

interesting is that we also found other
Sednit tools in the same organization. So

at this point we wondered how this malware
got there, but since there was other

backdoors of Sednit in the organization we
thought it might be the infection vector,

but by digging a little bit deeper we
found another interesting component. And

if we go back to the LoJack architecture,
the component that we found is at this

step here. So at this step in the LoJack
architecture it's autochk.exe that lives

there. But what we found is another file
called autoche.exe instead of autochk. And

it does pretty much the same thing. So it
also installs a service and it also drops

rpcnetp.exe. But it is the rpcnetp version
that has a modified server in it. So

Sednit domain basically. And we continue
to look at what we can find in this

organization and we found another tool
which is called info_efi.exe, and that

allows to drop... to dump a lot of
information about very low level settings

of the machine. And this tool uses Read
Write Everything's driver. And

Read Write Everything is a software that allows you
to manipulate very low level setting of

your machine. So using this tool you can
read and write to PCI configuration

register, to memory-mapped IOs, to IO port
space and you can also access physical

memory and this tool uses a kernel driver
of course - if you want to do those things

you need a kernel driver. And this kernel
driver is properly signed so that you can

push it on even a recent version of
Windows. And so yeah, that's the driver

that was used by info_efi here. And by
Googling a little bit around what we found

out is that this specific driver was used
in the past by security researchers to

exploit vulnerabilities at the firmware
level. So, yeah, the last thing that was

missing here to mimic the whole LoJack
solution was a UEFI BIOS module. So at

this point we wondered, did they get
there. So, because of the tool dumping

information about the BIOS that I just
spoke about, we were pretty confident that

something more was happening there. And by
digging a little bit deeper, we found

other tools that strengthen our
suspicions. So the first tool is called

ReWriter_read. And it is a tool used to
dump the content of the SPI flash memory,

and it also uses Read Write Everything's driver and
it uses these specific IO control codes.

So it allows it to read and write to
memory-mapped IO space as well as read and

write to PCI configuration registers.
What's interesting for us as reverse

engineer is that this tool contains a lot
of debug strings which really made our job

easier. And it consists of the following
operations. So the first thing it will do

is that it will log information on the
BIOS_CNTL register and we'll talk a lot of

detail about this register just a little bit later
in this talk. Then it locates the BIOS

region base address. And finally it reads
the UEFI firmware content and dump it to a

file. So another tool that we found is
really complementary to the tool to

ReWriter_read and it is called
ReWriter_binary. So it also contains a lot

of debug strings. It also uses
RWEverything's driver. And now the UEFI

firmware is dumped into memory, the next
step is to add the rootkit to the firmware

and to write it back to the SPI flash
memory and that's exactly what this tool

does. Okay. So now let's talk about the
patching of the UEFI firmware. But before

we dig into the subjects there are a
couple things that I wanted to introduce

here just to make sure that we're on the
same page. So the first thing I want to

talk about is UEFI and UEFI stands for
Unified Extensible Firmware Interface and

it is a standardized specification that
defines the interface that exists between

the operating system and the firmware. And
it's kind of a replacement for the legacy

BIOS. So, a UEFI compliant firmware will
provide a set of services to UEFI

applications and here read the operating
system loader. There are other UEFI

applications, but usually it's the
operating system loader that runs. So the

first set of services is called the boot
services and these are services that are

available during the firmware lifetime but
once the operating system is loaded, these

services are not available anymore and
there are the runtime services that are

also available during firmware lifetime.
But once the operating system is loaded

they are still available, so that a kernel
driver for instance can make call in these

services. An example of these services
allows the operating system to read and

write to UEFI variables. And what's
interesting with UEFI is that there is no

more master boot record and volume boot
record involved in the boot process

meaning that there is no easy way to
hijack the early boot control flow. So the

second thing I want to introduce here are
the driver execution environment drivers -

so the DXE drivers. So DXE drivers are
PE/COFF images meaning that they are

basically Windows executables, and they
are kind of the core of UEFI firmware so

that they can do many things, some of them
will be used to abstract the hardware.

Some of them will be used to produce the
UEFI standard interface, so the boot

services and the runtime services, and
they can also be used by firmware vendors

or OEMs to extend the firmware by
registering new services - the so-called

protocols in the UEFI specification. And,
the DXE drivers are loaded during the DXE

phase of the platform initialization and
they are loaded by the DXE dispatcher that

will also be referred to as the DXE Core.
The last thing that I'm going to do: I

want to introduce for now is the UEFI
firmware layout - so the UEFI firmware

is located in the BIOS region of the SPI
flash memory. And this region will contain

multiple volume. But let's look at it with
a little bit more detail in this tool here

which is UEFI tool, that is an open source
software that allows you to manipulate

UEFI firmware images. So here I loaded the
typical content of SPI flash memory dump

in this tool and let's look at what we
have. So, the first thing that we see here

is the descriptor region, so it contains...
this region contains metadata about how

the remaining data in the SPI flash memory
is laid out. The second region that we

find here is the ME region which contains
the Intel Management Engine firmware. And

finally we have the BIOS region which is
really the main interest... the main thing

that we want to look at today. So the BIOS
region contains multiple volumes. So let's

look at one volume in a little bit more
detail. So here we have a volume of type

firmware filesystem version 2 and this
volume contains multiple files and these

files are identified by GUIDs. So that's
what we can see under the name column

here. And a file doesn't contain directly
the UEFI executable, but it is composed of

multiple sections and one of these section
is the actual UEFI executable, but there

are other section and in this case we see
a DXE dependency section that allows to

define dependencies for this specific UEFI
image and we also see a version section

and a user interface section which allows
to give us a human readable name for this

file instead of the GUID which is very
pretty difficult to remember for humans.

OK, so now that we have all this in mind
let's go back to ReWriter_binary. So what

ReWriter_binary will do is that it will
parse all of the firmware volumes that it

can find looking for 4 specific files. So
it looks for Ip4Dxe, NtfsDxe, SmiFlash,

and the DXE Core. So why does it look for
Ip4Dxe and the DXE Core? Well these files

are looked for to find the firmware volume
where to install the UEFI rootkit. So

usually in UEFI firmwares all of the DXE
drivers all in the same volume, so when

the tool will parse... will find in fact
Ip4Dxe, it will know it is currently

parsing the volume with all of the DXE
drivers in it and it will keep it as a

candidate for the UEFI rootkit
installation. And it looks for the DXE

Core basically for the same reason, but
sometimes the DXE Core is in a different

volume, so when it will find it, it will
keep the volume as another candidate for

the UEFI rootkit installation and the
chosen volume will be the one with enough

free space available in it. Now, NtfsDxe.
So NtfsDxe is the American Megatron Inc.

NTFS driver and if the tool finds it, it
will remove it, and the reason for that is

that the UEFI rootkit embeds its own NTFS
driver, so to avoid any conflict with

another NTFS driver it just removes it.
And now SmiFlash, so, SmiFlash is looked

for... and, you know, the tool will... if
the tool finds it, it will keep some

metadata about it in the structure, but in
the version of the tool that we analyzed

it's not used anywhere. But interestingly,
SmiFlash is a known vulnerable DXE driver.

So what we believe is that Sednit might
have been fiddling in another version of

the tool with some exploit for this driver
in order to be able to bypass write

protection mechanisms to the BIOS region
of the SPI flash memory. So now that it

has found the volume where to install the
rootkit, it will add the rootkit, right.

So the first thing it does, it will create
a firmware file system file header, then

it will append the rootkit file, which is
a compressed section that contains two

other sections, one of one of these is the
actual UEFI rootkit image and the other

one is a user interface section defining
the name for this rootkit which is SecDXE,

as in security DXE. And then it will take
this blob of data and write it at the end

of the firmware volume that was chosen.

So now that the UEFI rootkit is inside the

firmware into memory, the next step is to
write it back to the SPI flash memory. And

once again there's a couple of things that
I want to introduce here. So I want to

talk about BIOS write protection
mechanisms. So the chipset exposes write

protection mechanisms that need to be
properly configured by the firmware. So

there are no such thing as, you know, BIOS
write particular mechanism enabled by

default. It's really the job of the
firmware to do that. And today will only

cover relevant protections to our
research. So only the protection mechanism

that are looked for by
REWriter_binary. And yeah the protection

we'll talk about are exposed via the BIOS
control register that we've seen a little

bit earlier in this talk. So, if you're a
kernel driver and you want to write to be

BIOS region of the SPI flash memory, what
you need to do first is you need to set

the BIOS Write Enable field of the BIOS
control register to 1 and then you're able

to write to the SPI flash memory. But of
course you don't want any kernel driver to

be able to modify your UEFI firmware and
potentially brick your machine. So there's

a protection mechanism there which is
another field in the BIOS control register

and this field is called BIOS lock enable
and it allows to lock BIOS Writer Enable to

0. And this field is readable in WLO. WLO
means write lock once. And what it means

is that once the firmware has set this bit
there's no other way to set it back to 0

than performing a full platform reset.

But there's a problem here, and it lies in the

fact that BIOS lock enable implementation
is vulnerable. So how it works is that

when BIOS write enable is set to 1, it's
value will actually change in the BIOS

control register for a small amount of
time. And then the platform will issue a

system management interrupt and the SMI
handler will set BIOS write enable back to

0. But, yeah, the firmware must implement
this SMI, otherwise this mechanism is

totally useless. But maybe you've guessed
it. But what happens if we write to the

SPI flash memory before the SMI handler
sets BIOS write enable back to 0? So there

is a race condition vulnerability here.
And there is a paper about it which is

called "speed racer". And to exploit this
what you need to do is, you need one

thread that continuously sets BIOS write
enable to 1, while another thread tries to

write the data to the SPI flash memory.
And according to this paper it works on

multicore processors as well as on single
core processors with hyper-threading

enabled. So Intel came up with a fix for
this issue and was introduced in the

platform controller hub family of Intel
chipsets around 2008. And what they did

is, that they added a field in the BIOS
control register. And this field is called

SMM BIOS write protect disable. And the
name is a little bit misleading, but if

you remove disable, that's actually what
it does. And if this mechanism is

activated, there will be no other way to
write to the SPI, to the BIOS region of

the SPI flash memory, than if you don't
have all of the cores of your processor

running into SMM, meaning that the job of
writing to the SPI flash memory is now only

available to system management mode. And
once again the firmware must set this bit.

Otherwise this mechanism is not activated,
right. Okay so let's go back to

ReWriter_Binary. So of course if I talk
about all of these mechanisms it's because

ReWriter_Binary checks for them. So it
will check if the platform is properly

configured and it implements the exploit
for the race condition that I just spoke

about. So let's look at the writing
process decision tree. So the first thing

that it will look for is if BIOS write
enable is set, and if BIOS write enable is

set there, then there's nothing stopping
it from writing the UEFI image. But if it

is not set, then it will check "Oh, is
BIOS lock enable activated?". And this, if

this mechanism is not activated then it
will just flip BIOS write enable to 1, and

then it will write the UEFI image. But if
it is activated, the last thing it will

check for is "Is SMM BIOS write protect
set?". And if it is not set, then it will

exploit the race condition that we spoke
about. And if it is set, then the tool

will just fail. So the tool only works if
the platform is misconfigured. And we

spoke about SmiFlash, the vulnerable DXE
driver. So yeah, what we think is that by

being able to exploit this vulnerability,
they would have been able to have a tool

that works even when the platform is
properly configured. So it's a very good

example of; I mean if firmware vendors
would have done their job correctly here,

this tool would have failed at flashing
the UEFI firmware, so that's a great

example of how, you know, firmware
security is. So here let's just take a

step back and look at what we have. So
what we have is a software implementation

to flash the firmware remotely post
exploitation, meaning that as an attacker

I can, you know, infect my target the way
I usually do - let's say by sending a

phishing email. And once I have a foothold
in the machine, I can use this tool to

deploy the UEFI rootkit. And one we knew
about in the past was Hacking Team's UEFI

rootkit and it needed physical access to
be deployed. So it's so much more

convenient to be able to do it remotely.
And let's note here that there is no proof

of Hacking Team's rootkit being used in an
actual cyber attack. It has never been

found on a victim's machine or at least if
it had, it hasn't been publicly disclosed.

So what we did at this point is that we
extracted the UEFI rootkit from the tool

and we looked at ESET's UEFI scanner
telemetry to see if we can find something.

Turns out that we found the UEFI rootkit
in the SPI flash memory of a victim's

machine, making it the first publicly
known UEFI rootkit to be used in an actual

cyber attack. Okay.

So now let's look at the UEFI
rootkit itself. So the UEFI

rootkit is a DXE driver. So it is loaded
by the DXE dispatcher every time that the

machine will boot. Its file name is SecDxe
as we've seen earlier and here's the file

GUID for future reference. So let's look
at the UEFI rootkit workflow. So UEFI

firmware we'll go through multiple phases
when it boots. The first phase is the

security phase, the second one is the pre
EFI initialization phase, and then there

is the driver execution environment phase
and that's where it begins to be

interesting for this rootkit. So that's
where the DXE dispatcher lives. So that's

when all of the DXE drivers will be
loaded. So at some point the UEFI rootkit

will be loaded. And what will happen is
that the rootkit will create an event

attached to EFI GROUP_READY_TO_BOOT. And
it will bind a notify function to this

event. So in the next phase, when the boot
manager will run, at some point it will

signal this event and the notify function
will be called. So, the notify function

does 3 things. The first thing is that it
will install an NTFS driver. Then it will

drop autoche.exe and rpcnetp.exe using
this NTFS driver. And finally it will

patch a value in the Windows Registry. So,
the NTFS driver is needed to get file

based access to Windows partition and
Sednit's operator did not write their own

NTFS driver. What did it is that they use
Hacking Team's NTFS driver from Hacking

Team's leak. And, yeah, so here's the code
responsible for dropping the files. So as

we can see here, it is dropping
rpcnetp.exe and here it is dropping

autoche.exe. And the last step is to patch
the Windows Registry. So how it does that

is that it will open the file backing the
HKLM\SYSTEM Registry hive and it doesn't

have all the logic to parse Windows
Registry structures, so it will only look

for a textual pattern and the textual
pattern it will look for is "autocheck

autochk " and it will change it to
"autocheck autoche " and it happens to be

modifying the BootExecute key. So, the
BootExecute key is the key responsible for

launching autochk.exe during Windows early
boot. So by modifying it to autoche

instead of autochk that's autoche.exe that
will be executed instead of autochk. And,

so here if we go back to the UEFI rootkit
workflow, when the operating system will

run, then it will execute autoche.exe.
Then autoche.exe will drop the small

agent, the rpcnetp.exe, and so on. But
what's interesting here is that it will

revert back the modification in the
Windows Registry from autoche to autochk.

So that as a Windows user, for instance,
if I look in the Windows Registry, I won't

find that anything, any modification
occurred there. So that's a pretty

interesting sealth technique that is
enabled by the fact that the malware is

coming from the firmware. Okay. So, the
last thing that I want to talk about now

is prevention and remediation, so what can
you do to protect yourself against this

kind of attack? And if ever you were...
you find out that you had a UEFI rootkit in

your machine, what can you do? So,
prevention. So the first thing and the

most important thing, which is also the
most accessible thing, thankfully, is that

you should keep your UEFI firmware up to
date to make sure that if, you know,

security researchers found some issues
with your firmware and they disclosed it

and the firmware vendor fixed them, you
want to make sure that you have the latest

patches available on your machine. Then
the second thing is that you should really

enable Secure Boot. But let's note here
that Secure Boot itself would not

effectively you against this specific
attack. And the reason for that is that

Secure Boot takes the content of the SPI
flash memory as its root of trust, meaning

that what's inside the SPI flash memory is
not subject for validation. So what does

it validates then, right? Well, Secure
Boot will check what's coming from outside

of the SPI flash memory meanings the PCI
option ROMs and probably the most

important thing, the operating system
loader. So it's really a mechanism that

checks that the operating system loader
hasn't been tampered with. So what can we

do then, right? Well, what we need is a
hardware root of trust. So we need to move

the root of trust from the SPI flash
memory to some piece of hardware. So it

must be in a, you know, one time
programmable chip that is programmed

during manufacturing time and that cannot
be written to ever after. An example of

this exists - technology like Intel
BootGuard implements this. And also Apple

T2 security chip has a hardware root of
trust. And then you kind of need to hope

that your firmware configures the security
mechanisms properly and there's not much

you can do about it if your firmware is
up-to-date. But thankfully there are

firmware security assessment tool
available out there and an example of that

is Intel CHIPSEC. So, with Intel CHIPSEC
which is an open source software tool, so

you can just download this tool, put it in
an USB key, boot from it and then this

tool will check for all of the security
mechanism that we spoke about today, it

will check if they are properly configured
and also it checks for a bunch more stuff.

And now also CHIPSEC checks if your
firmware has this LoJax rootkit. So if you

want to know if your firmware properly
configures these security mechanism that's

really the way to go. Now about
remediation. So, this slide is kind of

short. And the reason for that is that if
you find out that you have a UEFI rootkit

in your SPI flash, there's not pretty much
you can do. You really need to re-flash

your UEFI firmware and that's definitely
not something that is easy to do for

anybody. And well, if it's not an option
for you, then you kind of need to get rid

of your motherboard or your laptop and get
a new one basically. So that's how serious

this kind of attack is. Now, conclusion.
So, our research shows that UEFI rootkits

are not only toys for researchers to play
with, but they are real world threats used

in actual cyber attacks. So it might be
something that you want to keep in mind

when you'll be defining your threat model.
Also we won't stress this enough: firmware

must be built with security in mind from
the bottom up, and things are getting

better because there are more and more
security researchers looking into this,

but there's still work to do. And
hopefully, our research help share

knowledge about how to prevent and
mitigate UEFI-based threats. So that is

pretty much it for me today. So thank you
for having me and if ever you're

interested to know more details about this
research, the white paper is available at

welivesecurity.com and you can grab a copy
there. So, thanks.

Applause
Herald: Alright, you know the drill. We

have 5 minutes for Q&A. So please, quick
and short questions. Number 1 please.

Question: (incomprehensible) attacking
other operating systems (incomprehensible)

Answer: In this case, well, that's kind of
the... pretty much the only one we're aware

of, apart from Hacking Team's UEFI
rootkit, and this one only works on

Windows, so we have no; we don't know
about any other that target's Linux or Mac

OS for instance.

Herald: Please refrain from walking in
front of the cameras when you're leaving.

Thank you.
Could we get microphone number

2 please.
Q: Hello, thanks for the talk. On your

slides you mentioned a tool, open source,
for checking out the layout. What was the

name of the tool?
A: It's called UEFI tool. Laughter

Q: Nice.
A: So you can find it on GitHub.

Q: Thanks.
Herald: The internet please.

Q: Thank you. Does the rootkit also work
when the UEFI is in BIOS legacy mode?

A: Uhm... That is a pretty good question.
I think it should, but I am not sure about

it. That's a good question, I'd have to
look into this, to have a... laughing an

answer I'm 100 percent sure about. Sorry
for that.

Herald: Microphone number 3 please. It's
you in the back, are you? No that's 4,

I'm sorry.
Q: OK. So, does the UEFI dropper still

work with BitLocker enabled?

A: I know. Oh yeah. Yeah. We test that.

No, it doesn't work if BitLocker is
enabled, so it doesn't wait for the... for

BitLocker to have decrypted all of the
data. So no, it doesn't work if

BitLocker is enabled.

Herald: Number 1 please.

Q: Would it be possible to work within
full disk encryption. (incomprehensible)

the file system was decrypted and then
installed the dropper.

A: I'm not sure I heard all of the
question, but if it works if there's full

disk encryption? Is it the question right?
Q: Would it be possible to make it work

with full disk encryption?
A: I think it should be because the LoJack

software is a legitimate one, the anti-
theft solution. They are able to make it

work even if BitLocker is enabled or full
disk encryption. So yeah, it should be

possible to do so.

Herald: One more internet question please.

Q: Thank you. What if a rootkit doesn't
fit in the SPI flash. Is filling up the

SPI flash space completely a valid
prevention?

A: No I don't know... we could really call
it a prevention mechanism. But yeah, if

there is not enough free space available
on the firmware volumes the tool will just fail.

Herald: Number two please.

Q: Hi. You said that there is no real
possibility to secure everything, but what

are your daily choices that you use like,
on your personal computer, to be fully

secret?
A: Well... laughing I could say an

alternative platform, but... laughter
but yeah, if you have

a modern Intel CPU and you have

Secure Boot enabled and you have, you
know, all of the latest UEFI firmware

updates, that's kind of the best you can
do to be safe for... against that kind of

attack.
Q: I have... I have my like this...

Herald: Number 1 please.
Q: So, going back to the LoJack

configuration file vulnerability. Is the
configuration file on the operating system

file system?
A: No no no, the... In fact it's... there is

not a separate configuration file, the
configuration is embedded inside the

executable. So it is embedded into
rpcnetp.exe.

Herald: Unfortunately, we are already out
of time. So please thank our speaker

again.

applause

postroll music

subtitles created by c3subtitles.de
in the year 2019. Join, and help us!