*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!