7:25 a.m.
Hello,
I addressed this issue before on the ACPI developers' mailing list, where I
observed a strange/suspicious behavior of my system's ACPI code in the case
of a Lenovo G710 notebook. I concluded that this might be explained by the
fact that Lenovo employs ACPI code in order to install harmless crapware on
Windows, but finally I can definitely say that this conclusion can not be
true, since the ACPI code of four different systems I'm using, which I
extracted and submitted to malwr.com, led to the same results in each case.
E. g., this is the result for the ACPI I extracted from an AMD x64 desktop
PC:
https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
It shows what happens when the ACPI code gets executed on a Windows system,
and if you google some of files which get deployed or take a look at the
registry modifications being made, it should be obvious to everyone that it
compromises the system in order to gain full remote access over it and
forward its' network traffic (which I can also observe in Wireshark).
Recently someone from the Comodo support also confirmed me that my system
is compromised, but even the Comodo software itself seems to have been
gotten manipulated, so the Comodo firewall doesn't block the remote access
(they're investigating about this now).
However, this ACPI not only compromises Windows systems, but also every
Linux and BSD distro I've tested for the purpose of analysis so far. The
files in this Dropbox folder will give you only a first impression of this:
https://www.dropbox.com/sh/x6vf2fqsbqdx0k8/AACdgsdbN_UA4w2XDaob9Maia?dl=0
"modified_files.out" shows a list of files having been modified during the
first 10 minutes after the first boot of a freshly installed system,
dmesg.out shows various ACPI related errors and the netstat output shows
that the UDP and UDP6 ports 50988 and 47815 are open, which shouldn't be
the case normally. (Wireshark gives the same impression of traffic being
forwared like it does on Windows.)
The folder also contains the ACPI code extracted and disassembled using the
IASL code.
Would anyone be able to perform a debugging of this code in order to make
visible what its execution on a Linux system does in detail?
Thanks in advance and kind regards
David
5:44 p.m.
I loaded the extracted ACPI code with acpiexec, whose initial output was
this:
"ACPI: RSDP 0x00000000006854E0 000024 (v02 Intel )
ACPI: XSDT 0x0000000000BEAA80 00003C (v00 Intel AcpiExec 00001001 INTL
20160729)
ACPI: FACP 0x0000000000BE4E20 0000F4 (v03 061210 FACP1416 20100612 MSFT
00000097)
ACPI: DSDT 0x0000000000BDD420 0079CA (v01 A1556 A1556000 00000000 INTL
20060113)
ACPI: FACS 0x00000000006854A0 000040
ACPI: SSDT 0x0000000000BEBCC0 000DA4 (v01 A M I POWERNOW 00000001 AMD
00000001)
Initializing General Purpose Events (GPEs):
Initialized GPE 00 to 1F [_GPE] 4 regs on interrupt 0x9 (SCI)
Initialized GPE 20 to 5F [_GPE] 8 regs on interrupt 0x9 (SCI)
Initializing Namespace objects:
Table [DSDT: A1556000] (id 01) - 1088 Objects with 65 Devices, 23
Regions, 360 Methods (62/298/43 Serial/Non/Cvt)
ACPI: Executed 1 blocks of module-level executable AML code
Table [SSDT: POWERNOW] (id 02) - 36 Objects with 0 Devices, 0
Regions, 0 Methods (0/0/0 Serial/Non/Cvt)
ACPI: 2 ACPI AML tables successfully acquired and loaded
Completing Region/Field/Buffer/Package initialization:
Initialized 22/23 Regions 38/38 Fields 53/53 Buffers 117/117 Packages
(1133 nodes)
Initializing Device/Processor/Thermal objects and executing _INI/_STA
methods:
Executed 1 _INI methods requiring 1 _STA executions (examined 73
objects)
Unexpected AE_BAD_ADDRESS from AcpiWriteBitRegister (aeexec-609)
Unexpected AE_BAD_ADDRESS from AcpiReadBitRegister (aeexec-622)
Unexpected AE_BAD_PARAMETER from AcpiInstallGpeHandler (aeexec-898)
Unexpected AE_BAD_PARAMETER from AcpiEnableGpe (aeexec-901)
Unexpected AE_BAD_PARAMETER from AcpiDisableGpe (aeexec-904)"
The full output including the methods found by it can be seen in the file
acpiexec.out, which I uploaded on GoogleDrive:
https://drive.google.com/open?id=0B62Y5Qk_rdbWYzhPTHhHM1RxRTg
However, although I definitely don't know enough about the ACPI system, I
guess it would in fact not be realistic to understand how this ACPI code
compromises a Linux system using acpiexec. Probably there's no other way
than debugging the kernel with ACPI debug output enabled...
On Fri, Jul 29, 2016 at 5:25 PM, David Renz <sun.kisses.horizon(a)gmail.com>
wrote:
Hello,
I addressed this issue before on the ACPI developers' mailing list, where
I observed a strange/suspicious behavior of my system's ACPI code in the
case of a Lenovo G710 notebook. I concluded that this might be explained by
the fact that Lenovo employs ACPI code in order to install harmless
crapware on Windows, but finally I can definitely say that this conclusion
can not be true, since the ACPI code of four different systems I'm using,
which I extracted and submitted to malwr.com, led to the same results in
each case. E. g., this is the result for the ACPI I extracted from an AMD
x64 desktop PC:
https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
It shows what happens when the ACPI code gets executed on a Windows
system, and if you google some of files which get deployed or take a look
at the registry modifications being made, it should be obvious to everyone
that it compromises the system in order to gain full remote access over it
and forward its' network traffic (which I can also observe in Wireshark).
Recently someone from the Comodo support also confirmed me that my system
is compromised, but even the Comodo software itself seems to have been
gotten manipulated, so the Comodo firewall doesn't block the remote access
(they're investigating about this now).
However, this ACPI not only compromises Windows systems, but also every
Linux and BSD distro I've tested for the purpose of analysis so far. The
files in this Dropbox folder will give you only a first impression of this:
https://www.dropbox.com/sh/x6vf2fqsbqdx0k8/AACdgsdbN_UA4w2XDaob9Maia?dl=0
"modified_files.out" shows a list of files having been modified during the
first 10 minutes after the first boot of a freshly installed system,
dmesg.out shows various ACPI related errors and the netstat output shows
that the UDP and UDP6 ports 50988 and 47815 are open, which shouldn't be
the case normally. (Wireshark gives the same impression of traffic being
forwared like it does on Windows.)
The folder also contains the ACPI code extracted and disassembled using
the IASL code.
Would anyone be able to perform a debugging of this code in order to make
visible what its execution on a Linux system does in detail?
Thanks in advance and kind regards
David
4:55 p.m.
Hi,
I cannot reach the google driver.
Could you send me a private email with the acpidump output attached?
Also please let me know the options that you’ve passed to acpiexec.
Thanks and best regards
-Lv
From: Devel [mailto:[email protected]] On Behalf Of David Renz
Sent: Saturday, July 30, 2016 9:45 AM
To: devel(a)acpica.org
Subject: Re: [Devel] Strange behavior of ACPI code
I loaded the extracted ACPI code with acpiexec, whose initial output was this:
"ACPI: RSDP 0x00000000006854E0 000024 (v02 Intel )
ACPI: XSDT 0x0000000000BEAA80 00003C (v00 Intel AcpiExec 00001001 INTL 20160729)
ACPI: FACP 0x0000000000BE4E20 0000F4 (v03 061210 FACP1416 20100612 MSFT 00000097)
ACPI: DSDT 0x0000000000BDD420 0079CA (v01 A1556 A1556000 00000000 INTL 20060113)
ACPI: FACS 0x00000000006854A0 000040
ACPI: SSDT 0x0000000000BEBCC0 000DA4 (v01 A M I POWERNOW 00000001 AMD 00000001)
Initializing General Purpose Events (GPEs):
Initialized GPE 00 to 1F [_GPE] 4 regs on interrupt 0x9 (SCI)
Initialized GPE 20 to 5F [_GPE] 8 regs on interrupt 0x9 (SCI)
Initializing Namespace objects:
Table [DSDT: A1556000] (id 01) - 1088 Objects with 65 Devices, 23 Regions, 360 Methods
(62/298/43 Serial/Non/Cvt)
ACPI: Executed 1 blocks of module-level executable AML code
Table [SSDT: POWERNOW] (id 02) - 36 Objects with 0 Devices, 0 Regions, 0 Methods
(0/0/0 Serial/Non/Cvt)
ACPI: 2 ACPI AML tables successfully acquired and loaded
Completing Region/Field/Buffer/Package initialization:
Initialized 22/23 Regions 38/38 Fields 53/53 Buffers 117/117 Packages (1133 nodes)
Initializing Device/Processor/Thermal objects and executing _INI/_STA methods:
Executed 1 _INI methods requiring 1 _STA executions (examined 73 objects)
Unexpected AE_BAD_ADDRESS from AcpiWriteBitRegister (aeexec-609)
Unexpected AE_BAD_ADDRESS from AcpiReadBitRegister (aeexec-622)
Unexpected AE_BAD_PARAMETER from AcpiInstallGpeHandler (aeexec-898)
Unexpected AE_BAD_PARAMETER from AcpiEnableGpe (aeexec-901)
Unexpected AE_BAD_PARAMETER from AcpiDisableGpe (aeexec-904)"
The full output including the methods found by it can be seen in the file acpiexec.out,
which I uploaded on GoogleDrive:
https://drive.google.com/open?id=0B62Y5Qk_rdbWYzhPTHhHM1RxRTg
However, although I definitely don't know enough about the ACPI system, I guess it
would in fact not be realistic to understand how this ACPI code compromises a Linux system
using acpiexec. Probably there's no other way than debugging the kernel with ACPI
debug output enabled...
On Fri, Jul 29, 2016 at 5:25 PM, David Renz
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I addressed this issue before on the ACPI developers' mailing list, where I observed a
strange/suspicious behavior of my system's ACPI code in the case of a Lenovo G710
notebook. I concluded that this might be explained by the fact that Lenovo employs ACPI
code in order to install harmless crapware on Windows, but finally I can definitely say
that this conclusion can not be true, since the ACPI code of four different systems
I'm using, which I extracted and submitted to malwr.com<http://malwr.com>, led
to the same results in each case. E. g., this is the result for the ACPI I extracted from
an AMD x64 desktop PC:
https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
It shows what happens when the ACPI code gets executed on a Windows system, and if you
google some of files which get deployed or take a look at the registry modifications being
made, it should be obvious to everyone that it compromises the system in order to gain
full remote access over it and forward its' network traffic (which I can also observe
in Wireshark). Recently someone from the Comodo support also confirmed me that my system
is compromised, but even the Comodo software itself seems to have been gotten manipulated,
so the Comodo firewall doesn't block the remote access (they're investigating
about this now).
However, this ACPI not only compromises Windows systems, but also every Linux and BSD
distro I've tested for the purpose of analysis so far. The files in this Dropbox
folder will give you only a first impression of this:
https://www.dropbox.com/sh/x6vf2fqsbqdx0k8/AACdgsdbN_UA4w2XDaob9Maia?dl=0
"modified_files.out" shows a list of files having been modified during the first
10 minutes after the first boot of a freshly installed system, dmesg.out shows various
ACPI related errors and the netstat output shows that the UDP and UDP6 ports 50988 and
47815 are open, which shouldn't be the case normally. (Wireshark gives the same
impression of traffic being forwared like it does on Windows.)
The folder also contains the ACPI code extracted and disassembled using the IASL code.
Would anyone be able to perform a debugging of this code in order to make visible what its
execution on a Linux system does in detail?
Thanks in advance and kind regards
David
8:23 a.m.
Hi,
you can find all ACPI relevant files of the three systems I'm using in the
following shared folder:
https://mega.nz/#F!DEBARZzB
It also contains files showing the results of various other analysis
methods I used. E. g., I was able to find out a few details of how this
rootkit works by comparing the files contained in a Raspberry image with
the files which were written on the SD card. At least this analysis showed
how this technology manipulates the SSH configuration of a Linux system in
order to gain remote access:
["Nur in" means "Only exists at", while "sind verschieden"
means "are
different" (referring to the files which got compared]
Does nobody have an idea how one could test which effects the execution of
ACPI code on Linux system has in detail, which I wanted to find out by
making use of my VM approach? How do ACPI developers test this in order to
ensure ACPI code's compatibility with Linux systems? Please let me know, if
anyone has an idea about this.
Thanks in advance and kind regards
David
On Fri, Aug 5, 2016 at 2:55 AM, Zheng, Lv <lv.zheng(a)intel.com> wrote:
Hi,
I cannot reach the google driver.
Could you send me a private email with the acpidump output attached?
Also please let me know the options that you’ve passed to acpiexec.
Thanks and best regards
-Lv
*From:* Devel [mailto:[email protected]] *On Behalf Of *David Renz
*Sent:* Saturday, July 30, 2016 9:45 AM
*To:* devel(a)acpica.org
*Subject:* Re: [Devel] Strange behavior of ACPI code
I loaded the extracted ACPI code with acpiexec, whose initial output was
this:
"ACPI: RSDP 0x00000000006854E0 000024 (v02 Intel )
ACPI: XSDT 0x0000000000BEAA80 00003C (v00 Intel AcpiExec 00001001 INTL
20160729)
ACPI: FACP 0x0000000000BE4E20 0000F4 (v03 061210 FACP1416 20100612 MSFT
00000097)
ACPI: DSDT 0x0000000000BDD420 0079CA (v01 A1556 A1556000 00000000 INTL
20060113)
ACPI: FACS 0x00000000006854A0 000040
ACPI: SSDT 0x0000000000BEBCC0 000DA4 (v01 A M I POWERNOW 00000001 AMD
00000001)
Initializing General Purpose Events (GPEs):
Initialized GPE 00 to 1F [_GPE] 4 regs on interrupt 0x9 (SCI)
Initialized GPE 20 to 5F [_GPE] 8 regs on interrupt 0x9 (SCI)
Initializing Namespace objects:
Table [DSDT: A1556000] (id 01) - 1088 Objects with 65 Devices, 23
Regions, 360 Methods (62/298/43 Serial/Non/Cvt)
ACPI: Executed 1 blocks of module-level executable AML code
Table [SSDT: POWERNOW] (id 02) - 36 Objects with 0 Devices, 0
Regions, 0 Methods (0/0/0 Serial/Non/Cvt)
ACPI: 2 ACPI AML tables successfully acquired and loaded
Completing Region/Field/Buffer/Package initialization:
Initialized 22/23 Regions 38/38 Fields 53/53 Buffers 117/117 Packages
(1133 nodes)
Initializing Device/Processor/Thermal objects and executing _INI/_STA
methods:
Executed 1 _INI methods requiring 1 _STA executions (examined 73
objects)
Unexpected AE_BAD_ADDRESS from AcpiWriteBitRegister (aeexec-609)
Unexpected AE_BAD_ADDRESS from AcpiReadBitRegister (aeexec-622)
Unexpected AE_BAD_PARAMETER from AcpiInstallGpeHandler (aeexec-898)
Unexpected AE_BAD_PARAMETER from AcpiEnableGpe (aeexec-901)
Unexpected AE_BAD_PARAMETER from AcpiDisableGpe (aeexec-904)"
The full output including the methods found by it can be seen in the file
acpiexec.out, which I uploaded on GoogleDrive:
https://drive.google.com/open?id=0B62Y5Qk_rdbWYzhPTHhHM1RxRTg
However, although I definitely don't know enough about the ACPI system, I
guess it would in fact not be realistic to understand how this ACPI code
compromises a Linux system using acpiexec. Probably there's no other way
than debugging the kernel with ACPI debug output enabled...
On Fri, Jul 29, 2016 at 5:25 PM, David Renz <sun.kisses.horizon(a)gmail.com>
wrote:
Hello,
I addressed this issue before on the ACPI developers' mailing list, where
I observed a strange/suspicious behavior of my system's ACPI code in the
case of a Lenovo G710 notebook. I concluded that this might be explained by
the fact that Lenovo employs ACPI code in order to install harmless
crapware on Windows, but finally I can definitely say that this conclusion can
not be true, since the ACPI code of four different systems I'm using,
which I extracted and submitted to malwr.com, led to the same results in
each case. E. g., this is the result for the ACPI I extracted from an AMD
x64 desktop PC:
https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
It shows what happens when the ACPI code gets executed on a Windows
system, and if you google some of files which get deployed or take a look
at the registry modifications being made, it should be obvious to everyone
that it compromises the system in order to gain full remote access over it
and forward its' network traffic (which I can also observe in Wireshark).
Recently someone from the Comodo support also confirmed me that my system
is compromised, but even the Comodo software itself seems to have been
gotten manipulated, so the Comodo firewall doesn't block the remote
access (they're investigating about this now).
However, this ACPI not only compromises Windows systems, but also every
Linux and BSD distro I've tested for the purpose of analysis so far. The
files in this Dropbox folder will give you only a first impression of this:
https://www.dropbox.com/sh/x6vf2fqsbqdx0k8/AACdgsdbN_UA4w2XDaob9Maia?dl=0
"modified_files.out" shows a list of files having been modified during
the first 10 minutes after the first boot of a freshly installed system,
dmesg.out shows various ACPI related errors and the netstat output shows
that the UDP and UDP6 ports 50988 and 47815 are open, which shouldn't be
the case normally. (Wireshark gives the same impression of traffic being
forwared like it does on Windows.)
The folder also contains the ACPI code extracted and disassembled using
the IASL code.
Would anyone be able to perform a debugging of this code in order to make
visible what its execution on a Linux system does in detail?
Thanks in advance and kind regards
David
8:23 a.m.
Sorry, I forgot to paste the link related to the SSH configuration's
manipulation:
http://pastebin.com/X3jU0JA9
On Sat, Aug 6, 2016 at 6:23 PM, David Renz <sun.kisses.horizon(a)gmail.com>
wrote:
Hi,
you can find all ACPI relevant files of the three systems I'm using in the
following shared folder:
https://mega.nz/#F!DEBARZzB
It also contains files showing the results of various other analysis
methods I used. E. g., I was able to find out a few details of how this
rootkit works by comparing the files contained in a Raspberry image with
the files which were written on the SD card. At least this analysis showed
how this technology manipulates the SSH configuration of a Linux system in
order to gain remote access:
["Nur in" means "Only exists at", while "sind verschieden"
means "are
different" (referring to the files which got compared]
Does nobody have an idea how one could test which effects the execution of
ACPI code on Linux system has in detail, which I wanted to find out by
making use of my VM approach? How do ACPI developers test this in order to
ensure ACPI code's compatibility with Linux systems? Please let me know, if
anyone has an idea about this.
Thanks in advance and kind regards
David
On Fri, Aug 5, 2016 at 2:55 AM, Zheng, Lv <lv.zheng(a)intel.com> wrote:
> Hi,
>
>
>
> I cannot reach the google driver.
>
> Could you send me a private email with the acpidump output attached?
>
> Also please let me know the options that you’ve passed to acpiexec.
>
>
>
> Thanks and best regards
>
> -Lv
>
>
>
> *From:* Devel [mailto:[email protected]] *On Behalf Of *David Renz
> *Sent:* Saturday, July 30, 2016 9:45 AM
> *To:* devel(a)acpica.org
> *Subject:* Re: [Devel] Strange behavior of ACPI code
>
>
>
> I loaded the extracted ACPI code with acpiexec, whose initial output was
> this:
> "ACPI: RSDP 0x00000000006854E0 000024 (v02 Intel )
> ACPI: XSDT 0x0000000000BEAA80 00003C (v00 Intel AcpiExec 00001001 INTL
> 20160729)
> ACPI: FACP 0x0000000000BE4E20 0000F4 (v03 061210 FACP1416 20100612 MSFT
> 00000097)
> ACPI: DSDT 0x0000000000BDD420 0079CA (v01 A1556 A1556000 00000000 INTL
> 20060113)
> ACPI: FACS 0x00000000006854A0 000040
> ACPI: SSDT 0x0000000000BEBCC0 000DA4 (v01 A M I POWERNOW 00000001 AMD
> 00000001)
> Initializing General Purpose Events (GPEs):
> Initialized GPE 00 to 1F [_GPE] 4 regs on interrupt 0x9 (SCI)
> Initialized GPE 20 to 5F [_GPE] 8 regs on interrupt 0x9 (SCI)
>
> Initializing Namespace objects:
> Table [DSDT: A1556000] (id 01) - 1088 Objects with 65 Devices, 23
> Regions, 360 Methods (62/298/43 Serial/Non/Cvt)
> ACPI: Executed 1 blocks of module-level executable AML code
> Table [SSDT: POWERNOW] (id 02) - 36 Objects with 0 Devices, 0
> Regions, 0 Methods (0/0/0 Serial/Non/Cvt)
> ACPI: 2 ACPI AML tables successfully acquired and loaded
>
> Completing Region/Field/Buffer/Package initialization:
> Initialized 22/23 Regions 38/38 Fields 53/53 Buffers 117/117 Packages
> (1133 nodes)
> Initializing Device/Processor/Thermal objects and executing _INI/_STA
> methods:
> Executed 1 _INI methods requiring 1 _STA executions (examined 73
> objects)
> Unexpected AE_BAD_ADDRESS from AcpiWriteBitRegister (aeexec-609)
> Unexpected AE_BAD_ADDRESS from AcpiReadBitRegister (aeexec-622)
> Unexpected AE_BAD_PARAMETER from AcpiInstallGpeHandler (aeexec-898)
> Unexpected AE_BAD_PARAMETER from AcpiEnableGpe (aeexec-901)
> Unexpected AE_BAD_PARAMETER from AcpiDisableGpe (aeexec-904)"
>
> The full output including the methods found by it can be seen in the file
> acpiexec.out, which I uploaded on GoogleDrive:
> https://drive.google.com/open?id=0B62Y5Qk_rdbWYzhPTHhHM1RxRTg
>
> However, although I definitely don't know enough about the ACPI system, I
> guess it would in fact not be realistic to understand how this ACPI code
> compromises a Linux system using acpiexec. Probably there's no other way
> than debugging the kernel with ACPI debug output enabled...
>
>
>
> On Fri, Jul 29, 2016 at 5:25 PM, David Renz <sun.kisses.horizon(a)gmail.com>
> wrote:
>
> Hello,
>
> I addressed this issue before on the ACPI developers' mailing list, where
> I observed a strange/suspicious behavior of my system's ACPI code in the
> case of a Lenovo G710 notebook. I concluded that this might be explained by
> the fact that Lenovo employs ACPI code in order to install harmless
> crapware on Windows, but finally I can definitely say that this conclusion can
> not be true, since the ACPI code of four different systems I'm using,
> which I extracted and submitted to malwr.com, led to the same results in
> each case. E. g., this is the result for the ACPI I extracted from an AMD
> x64 desktop PC:
> https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
>
> It shows what happens when the ACPI code gets executed on a Windows
> system, and if you google some of files which get deployed or take a look
> at the registry modifications being made, it should be obvious to everyone
> that it compromises the system in order to gain full remote access over it
> and forward its' network traffic (which I can also observe in Wireshark).
> Recently someone from the Comodo support also confirmed me that my
> system is compromised, but even the Comodo software itself seems to have
> been gotten manipulated, so the Comodo firewall doesn't block the remote
> access (they're investigating about this now).
>
> However, this ACPI not only compromises Windows systems, but also every
> Linux and BSD distro I've tested for the purpose of analysis so far. The
> files in this Dropbox folder will give you only a first impression of this:
> https://www.dropbox.com/sh/x6vf2fqsbqdx0k8/AACdgsdbN_UA4w2XDaob9Maia?dl=0
>
> "modified_files.out" shows a list of files having been modified during
> the first 10 minutes after the first boot of a freshly installed system,
> dmesg.out shows various ACPI related errors and the netstat output shows
> that the UDP and UDP6 ports 50988 and 47815 are open, which shouldn't be
> the case normally. (Wireshark gives the same impression of traffic being
> forwared like it does on Windows.)
>
> The folder also contains the ACPI code extracted and disassembled using
> the IASL code.
>
> Would anyone be able to perform a debugging of this code in order to make
> visible what its execution on a Linux system does in detail?
>
> Thanks in advance and kind regards
>
> David
>
>
>
6:14 p.m.
Sorry once again, I just discovered that the link I provided doesn't work.
This one works:
https://mega.nz/#F!fNR2CQgb!_67PgSYA4tqHJfYDeZX1qg
Kind regards
David
On Sat, Aug 6, 2016 at 6:23 PM, David Renz <sun.kisses.horizon(a)gmail.com>
wrote:
Hi,
you can find all ACPI relevant files of the three systems I'm using in the
following shared folder:
https://mega.nz/#F!DEBARZzB
It also contains files showing the results of various other analysis
methods I used. E. g., I was able to find out a few details of how this
rootkit works by comparing the files contained in a Raspberry image with
the files which were written on the SD card. At least this analysis showed
how this technology manipulates the SSH configuration of a Linux system in
order to gain remote access:
["Nur in" means "Only exists at", while "sind verschieden"
means "are
different" (referring to the files which got compared]
Does nobody have an idea how one could test which effects the execution of
ACPI code on Linux system has in detail, which I wanted to find out by
making use of my VM approach? How do ACPI developers test this in order to
ensure ACPI code's compatibility with Linux systems? Please let me know, if
anyone has an idea about this.
Thanks in advance and kind regards
David
On Fri, Aug 5, 2016 at 2:55 AM, Zheng, Lv <lv.zheng(a)intel.com> wrote:
> Hi,
>
>
>
> I cannot reach the google driver.
>
> Could you send me a private email with the acpidump output attached?
>
> Also please let me know the options that you’ve passed to acpiexec.
>
>
>
> Thanks and best regards
>
> -Lv
>
>
>
> *From:* Devel [mailto:[email protected]] *On Behalf Of *David Renz
> *Sent:* Saturday, July 30, 2016 9:45 AM
> *To:* devel(a)acpica.org
> *Subject:* Re: [Devel] Strange behavior of ACPI code
>
>
>
> I loaded the extracted ACPI code with acpiexec, whose initial output was
> this:
> "ACPI: RSDP 0x00000000006854E0 000024 (v02 Intel )
> ACPI: XSDT 0x0000000000BEAA80 00003C (v00 Intel AcpiExec 00001001 INTL
> 20160729)
> ACPI: FACP 0x0000000000BE4E20 0000F4 (v03 061210 FACP1416 20100612 MSFT
> 00000097)
> ACPI: DSDT 0x0000000000BDD420 0079CA (v01 A1556 A1556000 00000000 INTL
> 20060113)
> ACPI: FACS 0x00000000006854A0 000040
> ACPI: SSDT 0x0000000000BEBCC0 000DA4 (v01 A M I POWERNOW 00000001 AMD
> 00000001)
> Initializing General Purpose Events (GPEs):
> Initialized GPE 00 to 1F [_GPE] 4 regs on interrupt 0x9 (SCI)
> Initialized GPE 20 to 5F [_GPE] 8 regs on interrupt 0x9 (SCI)
>
> Initializing Namespace objects:
> Table [DSDT: A1556000] (id 01) - 1088 Objects with 65 Devices, 23
> Regions, 360 Methods (62/298/43 Serial/Non/Cvt)
> ACPI: Executed 1 blocks of module-level executable AML code
> Table [SSDT: POWERNOW] (id 02) - 36 Objects with 0 Devices, 0
> Regions, 0 Methods (0/0/0 Serial/Non/Cvt)
> ACPI: 2 ACPI AML tables successfully acquired and loaded
>
> Completing Region/Field/Buffer/Package initialization:
> Initialized 22/23 Regions 38/38 Fields 53/53 Buffers 117/117 Packages
> (1133 nodes)
> Initializing Device/Processor/Thermal objects and executing _INI/_STA
> methods:
> Executed 1 _INI methods requiring 1 _STA executions (examined 73
> objects)
> Unexpected AE_BAD_ADDRESS from AcpiWriteBitRegister (aeexec-609)
> Unexpected AE_BAD_ADDRESS from AcpiReadBitRegister (aeexec-622)
> Unexpected AE_BAD_PARAMETER from AcpiInstallGpeHandler (aeexec-898)
> Unexpected AE_BAD_PARAMETER from AcpiEnableGpe (aeexec-901)
> Unexpected AE_BAD_PARAMETER from AcpiDisableGpe (aeexec-904)"
>
> The full output including the methods found by it can be seen in the file
> acpiexec.out, which I uploaded on GoogleDrive:
> https://drive.google.com/open?id=0B62Y5Qk_rdbWYzhPTHhHM1RxRTg
>
> However, although I definitely don't know enough about the ACPI system, I
> guess it would in fact not be realistic to understand how this ACPI code
> compromises a Linux system using acpiexec. Probably there's no other way
> than debugging the kernel with ACPI debug output enabled...
>
>
>
> On Fri, Jul 29, 2016 at 5:25 PM, David Renz <sun.kisses.horizon(a)gmail.com>
> wrote:
>
> Hello,
>
> I addressed this issue before on the ACPI developers' mailing list, where
> I observed a strange/suspicious behavior of my system's ACPI code in the
> case of a Lenovo G710 notebook. I concluded that this might be explained by
> the fact that Lenovo employs ACPI code in order to install harmless
> crapware on Windows, but finally I can definitely say that this conclusion can
> not be true, since the ACPI code of four different systems I'm using,
> which I extracted and submitted to malwr.com, led to the same results in
> each case. E. g., this is the result for the ACPI I extracted from an AMD
> x64 desktop PC:
> https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/
>
> It shows what happens when the ACPI code gets executed on a Windows
> system, and if you google some of files which get deployed or take a look
> at the registry modifications being made, it should be obvious to everyone
> that it compromises the system in order to gain full remote access over it
> and forward its' network traffic (which I can also observe in Wireshark).
> Recently someone from the Comodo support also confirmed me that my
> system is compromised, but even the Comodo software itself seems to have
> been gotten manipulated, so the Comodo firewall doesn't block the remote
> access (they're investigating about this now).
>
> However, this ACPI not only compromises Windows systems, but also every
> Linux and BSD distro I've tested for the purpose of analysis so far. The
> files in this Dropbox folder will give you only a first impression of this:
> https://www.dropbox.com/sh/x6vf2fqsbqdx0k8/AACdgsdbN_UA4w2XDaob9Maia?dl=0
>
> "modified_files.out" shows a list of files having been modified during
> the first 10 minutes after the first boot of a freshly installed system,
> dmesg.out shows various ACPI related errors and the netstat output shows
> that the UDP and UDP6 ports 50988 and 47815 are open, which shouldn't be
> the case normally. (Wireshark gives the same impression of traffic being
> forwared like it does on Windows.)
>
> The folder also contains the ACPI code extracted and disassembled using
> the IASL code.
>
> Would anyone be able to perform a debugging of this code in order to make
> visible what its execution on a Linux system does in detail?
>
> Thanks in advance and kind regards
>
> David
>
>
>
2191
days inactive
2200
days old
5 comments
2 participants
participants (2)
-
David Renz -
Zheng, Lv