By mistake I've sent my reply only to Rudolf Marek instead to the list, as I just saw, so here is what I wrote as a reply. Hi, well, I assumed that, since the compromise of a Windows system running on the same machine obviously takes place by the execution of the ACPI code, as one can see by looking at the malwr.com sandbox analysis. It's also interesting to find ACPI code resulting in the same Windows manipulations on four different systems being used by me. The ACPI code extracted from my Lenovo notebook can be downloaded from the malwr.com link, same for the ACPI code I extracted from my AMD desktop. In the latter case the disassembled code can also be downloaded from the GoogleDrive link I provided. Maybe one could observe similarities by comparing the two codes of those different systems. I also think that the technology tries a lot to prevent many things, since the Volatility plugins weren't able to display the loaded kernel modules, the netstat plugin didn't give any output etc. And I was able to perform some (!) of the tests on my AMD desktop system, while no test could be performed on my Lenovo notebook. It's very reasonable to assume that a highly sophisticated rootkit also includes various mechanisms for preventing its analysis, but that doesn't rule out the possibility that those mechanisms might fail, especially when considering that malware based on firmware manipulation must face many difficulties due to the specifics of various system's hardware components (and their according firmware). Now I really don't want to make the impression of being stubborn, but please consider the following facts: 1) Submitting the extracted firmware of different systems being used by me to malwr.com, where the ACPI code gets executed, leads to the EXACTLY same results regarding the files created (which turn out to be part of malware/trojan software as a quick search for their filenames shows) AND the same registry activity (a proxy server is being set up etc.). Those system activities can only have been caused by the submitted ACPI code, I didn't submit anything else. Submitting ACPI code extracted from non-compromised systems doesn't show any special activities. --> It's not an assumption, but an evident fact that those manipulations took place by the execution of ACPI code. 2) The Linux systems on those systems are compromised as well, as the Volatility tests obviously demonstrate (kernel hooks, modification of the network layers/structure so that the network traffic visible to the user is probably not the whole traffic being sent/received, etc.). Therefore, thinking logical: Why should a Windows OS on a machine get compromised by the execution of ACPI code, while a Linux OS on the same system should be safe in this regard/gets compromised by another way? There are enough papers out there proving that Linux can definitely be compromised by the execution of ACPI code. [By arguing this way I don't want to imply that a compromise could ONLY take place through the execution of ACPI code - I agree to everything what Rudolf wrote regarding this aspect. In fact I would assume that a sophisticated rootkit would operate in a multi-redundant way, e. g. taking precautions that the system will still get compromised for example by employing means like mentioned by Rudolf, in case that the user would find a way to flash the ACPI code (which is not possible by performing a simple BIOS flash, as I already verified - the ACPI code remains being unmodified). I merely want to state that the ACPI code's execution seems to be the starting point of the system getting compromised.] So I had the idea to find out whether my thoughts are correct or not by letting a Linux system run in a VM, one time without making them use my system's ACPI code, and one time with specifying those as arguments, which is basically possible both for VirtualBox and for QEMU/KVM, so that I could afterwards compare what took place on each VM guest. However, it was not possible for me to do so, because both VirtualBox and QEMU/KVM have the restriction that the size of the total ACPI code is allowed to have a maximum size of 64kb (I have no idea for which reason this is the case) - This issue is even addressed on bug reports/issue lists, but it seems like nobody was able to find a solution or explanation for this so far. Did anyone on this list test Linux systems' ACPI compatibility etc. by this VM approach? If so, I'd be really thankful if someone would be able to perform such a test using my system's ACPI code - Just checking for differences regarding the creation/modification of files might be instructive already. I guess it wouldn't be an easy task to check the whole source of VirtualBox or QEMU/KWM in order to find a way how to remove this size limitation, although I'd try doing so, if there shouldn't be any other way to test this. I dumped my ACPI tables using proc /sys/... this time and uploaded the .bin files to GoogleDrive: https://drive.google.com/open?id=0B62Y5Qk_rdbWTVpfVlgwWDFjYWc I've put the .dsl files disassembled by iasl (which reported quite many errors) into the folder as well. There was no RSDT table in the /sys/... directory, and by using acpidump plus acpixtract I wasn't able to obtain one neither. Thanks in advance and all the best to everyone David Kind regards David Am 31.07.2016 15:23 schrieb "Rudolf Marek" <r.marek(a)assembler.cz&gt;: Hi David, I checked the ACPI error messages and they are pretty harmless. I don't think attacker would use the ACPI subsystem to plant the rootkit. I think the rootkit might be hidden in the system management mode memory which is inaccessible by the operating system. Therefore I don't think this is good mailing list to discuss it but I hope no one will complain if I give you some hints to try: 1) physically exchange a BIOS chip - use some service which will send you a BIOS chip replacement - they can even pre-load it with a factory BIOS 2) If you can't do that, and if the BIOS is socketed then use some external programmer to read out the BIOS, then go to the ASUS pages and download the BIOS as a CAP file. The file usually has 2KB header which you can strip and then you will get the 8MiB image which you can directly flash. Do not expect that the backup image will match - BIOS contains some places with a variables/scratch space so this won't help. 3) Check your malware detection procedure. I don't have the dropbox account so I can't help much. All distributions have a way to check the integrity of installed packages, so you can use this mechanism to check if something has been changed or not. (maybe the binary changed because of the update?) 4) I personally think that if you wold be a victim of such sophisticated malware which can infect any Linux/BSD then I would also think think that the malware would for sure prevent you to see the modified files. Thanks all I can say to this, now go and try to find some other more appropriate mailing list (sorry no idea here), also I don't think I can personally help any further Thanks Rudolf