blocks|key|3384012|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

There are many ways to compromise a running computer if you have physical access. How likely it is that you will be able to obtain the level of access you need depends on several factors, including your resources, the level of skill of the defender, and the amount of time you have available. You haven't provided much information about your target, so this answer will be fairly general but will assume they are fairly sophisticated and have a good understanding of the x86 architecture and hardware security. Specifically, it would be helpful if you provided more information on the following:
<ul>
<li>Is the target using <a href="https://en.wikipedia.org/wiki/Commercial_off-the-shelf" rel="nofollow noreferrer">COTS</a> (Commercial Off-The-Shelf) hardware, or is it custom?</li>
<li>Are there physical security measures in place, like chassis intrusion detection?</li>
<li>What is your budget? Can you pay for custom attack hardware?</li>
<li>Are you willing to sign an NDA with Intel to use their <a href="https://software.intel.com/content/www/us/en/develop/tools/documentation-library.html?query=&amp;currentPage=1&amp;externalFilter=guid:etm-62675be73f10450282aa56e3c230cab1;" rel="nofollow noreferrer">JTAG SDK</a>?</li>
<li>Is the memory acquisition done on-scene, or in a dedicated laboratory?</li>
<li>Do you prefer higher risk of detection, or higher risk of data corruption?</li>
</ul>
All of these points, especially the ones about the target's particular choice of hardware, can help narrow down exactly what the optimal strategy is. Otherwise the answer will be broad. The worst-case scenario is that the target has a deep understanding of the x86 architecture and has developed a sophisticated solution similar to <a href="https://privatecore.com/vcage/" rel="nofollow noreferrer">vCage</a>, reducing the TCB to that of the CPU itself and mitigating virtually all physical attacks. This would require novel acquisition methods to be created.
<hr />
Below are some general classes of memory acquisition attacks against x86 hardware.
<h2>IEEE 1149.1</h2>
The &quot;best&quot; course of action would be to use the IEEE 1149.1 protocol, aka <a href="https://www.xjtag.com/about-jtag/what-is-jtag/" rel="nofollow noreferrer">JTAG</a>. This is a debugging protocol which puts a processor into probe mode. From there it can be halted, registers can be read or modified (including the instruction pointer), addresses in memory can be read or modified, etc. There is generally no defense from a JTAG attack short of destruction of the physical <a href="https://software.intel.com/content/dam/develop/external/us/en/images/xdp-onboard.png" rel="nofollow noreferrer">JTAG header</a> (XDP) on the motherboard. A JTAG attack for Intel motherboards requires an expensive probe. Newer systems support <a href="https://www2.lauterbach.com/pdf/dci_intel_user.pdf" rel="nofollow noreferrer">DCI</a>, which allows JTAG debugging to be performed over USB. Many BIOSes will disable DCI support, requiring a fallback to the expensive alternative.
<h2>Bus mastering</h2>
PCIe devices natively support hotplugging and have in their configuration space a two-byte <a href="https://wiki.osdev.org/PCI#PCI_Device_Structure" rel="nofollow noreferrer">command register</a>. Bit 2 is bus master enable which, when set, allows the device to perform DMA requests to read and write to generally arbitrary locations in memory. While the PCIe device may be able to set this bit on its own, the PCI bridge also needs the bit set in order to forward the DMA request. All the PCIe device has to do is convince the operating system that it requires a driver which does grant it DMA abilities. At that point you can read or write to arbitrary locations in memory. Note that some systems will use <a href="https://software.intel.com/content/www/us/en/develop/articles/intel-virtualization-technology-for-directed-io-vt-d-enhancing-intel-platforms-for-efficient-virtualization-of-io-devices.html" rel="nofollow noreferrer">DMA Remapping</a>, or DMAR, which can restrict the locations of memory you can access (though this <a href="https://security.stackexchange.com/q/176503/106285">might not be enough</a> to mitigate such attacks, and some older systems <a href="https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf" rel="nofollow noreferrer">have a broken IOMMU</a>). If this is the case, or if you expect the system is further hardened to detect the insertion of new DMA-capable devices, then it may not be fruitful to attempt to use a PCIe device for DMA. DMA is among the most commonly used for memory acquisition.
<h2>Cold boot attacks</h2>
There are two types of cold boot attacks. You can either reboot the system into another bootloader which then reads memory, or you can physically remove (and optionally freeze) the memory modules and transfer them to a system under your control. This cannot generally be detected unless you attempt to freeze the memory while it is still under control of the target computer, but it risks large amounts of data loss if done improperly. Modern memory (DDR3 and DDR4) also uses a feature called memory scrambling to reduce excessive electrical interference. The scrambling seed is very weak as it uses an <a href="https://en.wikipedia.org/wiki/Linear-feedback_shift_register" rel="nofollow noreferrer">LFSR</a>, but it still requires at least basic <a href="https://doc.lagout.org/security/DFRWS-EU-2016-7.pdf" rel="nofollow noreferrer">cryptanalysis to break</a>. There is an additional benefit to the cold boot attack, though, which is that the memory acquisition is atomic, leaving no <a href="https://sci-hub.se/10.1016/j.diin.2016.01.003" rel="nofollow noreferrer">memory smear</a>. I wrote more about this <a href="https://security.stackexchange.com/a/180809/106285">in another answer</a>.
<h2>Attacking TRESOR</h2>
<a href="https://www.cs1.tf.fau.de/research/system-security-group/tresor-trevisor-armored/" rel="nofollow noreferrer">TRESOR</a> is a kernel patch for Linux which does encryption entirely outside of memory, mitigating cold boot attacks and passive DMA. The keys are kept only in the CPU's x86 debug registers, and key material never enters memory (except during an NMI or SMI). Defeating TRESOR requires the ability to write to memory. The most effective way to do this is to modify the <a href="https://wiki.osdev.org/Interrupt_Descriptor_Table" rel="nofollow noreferrer">IDT</a>, triggering the execution of custom code in supervisor mode at the next interrupt. This code can be used to read the debug registers. This attack is described in more detail in <a href="https://sci-hub.se/10.1145/2420950.2420961" rel="nofollow noreferrer">another paper</a>. Your target may not use this particular mitigation, or they may have developed their own using <a href="https://www.blackhat.com/presentations/bh-usa-08/McGregor/BH_US_08_McGregor_Cold_Boot_Attacks.pdf" rel="nofollow noreferrer">any number of innovative techniques</a>. You should know as much as possible about your target before interacting with their machine.
<hr />
Let's assume five different skill levels of the defender in order to approximate what attack vector would be ideal. These will be simplifications and the proper course of action should be to learn more about the target before attempting any risky procedures.
<ol>
<li>No skills at all. The target knows effectively nothing about hardware security. They may run antivirus software and lock their computer when they leave, but that's about it. Any of the above techniques are liable to work. The average person may fit into this category.
</li>
<li>Low skill-level. The target has a very limited understanding of hardware security. They are capable of finding and running pre-written defensive software. They are using unmodified consumer hardware and likely do not check if DMAR is enabled. In this case, a DMA attack would easily be the most effective. Plugging in a PCIe device could make it possible to read memory. A security-conscious power user may fall into this category.
</li>
<li>Moderate skill-level. The target has a good understanding of hardware security. Their computer may have some basic modifications made to it, such as epoxy resin blocking sensitive ports. They may be able to write basic defensive software for a variety of attacks. DMAR is likely supported and correctly enforced, making DMA attacks impractical. The system may or may not react defensively when a new PCIe device is attached. In this case, a JTAG attack would be most effective. If TRESOR is not in use, a cold boot attack may do. A particularly clever amateur security researcher may fall into this category.
</li>
<li>High skill-level. The target has a deep understanding of hardware security and may have access to unreleased or confidential documents from their hardware manufacturer. Their system is either heavily modified, or completely customized. Intrusion detection may include cameras inside or near the chassis. Individual sensitive chips, traces, and buses may be encased in anti-tamper epoxy. JTAG headers could be physically destroyed or wired to alert the system to an attack. Attacking a system operated in this way requires in-depth knowledge of the target, a fair amount of custom hardware, and novel attacks. An employee for a large security contractor for a government working on sensitive data may fall into this category.
</li>
<li>Nation-state skill-level. The target has resources on par with a nation-state. The chipset itself is likely designed in-house and manufactured in a secure, on-site fab by a contractor. Every component is part of this target's own supply chain. Custom defense mechanisms are likely enforced, all the way down to the microscopic level (e.g. sophisticated chip-off protection mechanisms). Physical destruction (and black bagging) may occur if tampering is detected. The device is completely shielded from RFI/EMI leakage. Cryptographic modules may be certified with at minimum FIPS 140-2 level 4, and software running on the machine is likely to be at least partially formally verified and tested up to EAL7+. A highly-sensitive and well-funded branch of an FVEY or SSEUR member may fall into this category.
</li>
</ol>

Let's say I have a computer with full disk encryption which is logged and running, but I suspect it has anti-forensics software (eg. usbkill), which means that I risk compromising the integrity of the data with one of the following actions:

<ul>
<li>inserting a USB/SD card</li>
<li>downloading/uploading from internet </li>
<li>not executing a specific action each X hours (a dead man's switch)</li>
</ul>

What do you think is the best course of action in order to perform forensic analysis on it? If there is no good way to perform it, what do you think is the best approximation?

How can a user defeat anti-live forensics software?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

假设我有一台具有全磁盘加密的计算机，它是记录并运行的，但我怀疑它有反取证软件(例如。)，这意味着我有可能通过以下操作之一损害数据的完整性：插入USB/SD卡网上下载/上载没有每隔X小时执行一次特定的动作(一个死人的开关)你认为对其进行法医分析的最佳行动路线是什么？如果没有好的方法来执行它，你认为什么是最好的近似？

用户如何打败反现场取证软件？-腾讯云开发者社区-腾讯云

问用户如何打败反现场取证软件？
EN

回答 1

Security用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用户如何打败反现场取证软件？EN