{{Header}} {{title|title= Deep Scan Ready }} {{#seo: |description=Deep scan ready means owners can inspect the full operating system and boot chain from a clean external system, offline or detached, so malware stays inactive while scanning. |image=Deep_scan_ready_icon.png }} [[File:Deep_Scan_Ready.png|thumb]] [[File:Deep_scan_ready_icon.png|thumb]] {{intro| Deep scan ready means the device owner can fully check their own device from the outside, while it is powered off, without needing permission from the vendor. }} = ELI5: What does "Deep Scan Ready" mean? = Bear with us, this section is ELI5. More technical explanations follow later. Imagine your computer is a locked box. There are two kinds of boxes. '''Box type A''' The company that made the box keeps the keys. You are told to trust their checker. If something bad can fool that checker, you may never know. This is '''Deep Scan Restricted'''. '''Box type B''' You keep the keys. You can turn the box off and safely look at everything inside. Nothing inside can run or hide while you are checking. This is '''Deep Scan Ready'''. = Introduction = '''More technically:''' Deep scan ready means the device owner can inspect the full operating system and boot chain while the device is powered off, using a separate clean external system. Security should not require blind trust in the platform vendor (the company that makes the device, firmware, or operating system). The {{os}} itself may be part of the threat model, meaning the operating system could be compromised. For this reason, users should be able to control keys (cryptographic keys used for verification), verification, and modification (the ability to inspect and change the system). To accomplish this goal, the operating system must be deep scan ready, meaning it supports being inspected from the outside, without running it. An important rule for deep virus scans is: do not boot a device suspected of being infected with [[malware]], because active malware can hide itself, fake "clean" results, or erase evidence. {{quotation |quote=Live analysis provides valuable, volatile information that may not be available during an offline analysis of a hard drive, e.g., dynamic data such as running processes and open ports, which are only available during system operation. However, when one of the processes on a machine includes a rootkit, the 90 ADVANCES IN DIGITAL FORENSICS III investigator must question if the results of a live analysis are tainted. When rootkits are running, the data and processes they have modified are still in use by the operating system, but this fact is not visible to the user. In fact, our experiments demonstrate that even if a live response cannot detect what is hidden, it can still provide an investigator with details about what was available to the user. This information can also help the investigator determine what the rootkit was hiding. |context=[https://opendl.ifip-tc6.org/db/conf/ifip11-9/df2007/ToddBPFSR07.pdf IFIP Open Digital Library: Todd et al. PDF] }} {{quotation |quote=If you suspect a rootkit virus, one way to detect the infection is to power down the computer and execute the scan from a known clean system. |context=[https://www.kaspersky.com/resource-center/definitions/what-is-rootkit Kaspersky Resource Center: What is a rootkit?] }} {{quotation |quote=Hidden malware: Rootkits can install and conceal other types of malware within your network, making detecting and removing them difficult. |context=[https://us.norton.com/blog/malware/rootkit Norton blog: Rootkit] }} {{quotation |quote=Use offline scanners: If the rootkit is particularly stubborn or your regular antivirus software fails to detect it, you can try offline scanners. These antivirus tools run from a bootable USB or CD/DVD, allowing them to scan your system without the rootkit being active. |context=[https://us.norton.com/blog/malware/rootkit Norton blog: Rootkit] }} {{quotation |quote=By analyzing memory dumps, examiners can ensure clean working environment and no active resistance from the rootkit. |context=[https://www.forensicfocus.com/articles/understanding-rootkits/ Forensic Focus: Understanding rootkits] }} See also [https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-offline Microsoft Defender Offline]. Instead, power the device off and inspect the storage from a clean external system by performing a read only inspection (so the suspect device cannot write changes back while you are checking it). To learn more, see [[Malware_and_Firmware_Trojans#Basics_of_Malware_Analysis_and_Backdoor_Hunting|Basics of Malware Analysis and Backdoor Hunting]]. Deep scans are usually possible with traditional Linux distributions but often not on most mobile devices such as stock Android, because you generally cannot easily boot a trusted external system or fully inspect storage without unlocking or modifying the device. = What does deep scan ready mean? = (Deep scan ready means you can safely and fully inspect a device for malware from outside, while it is powered off.) * Analyze everything: All files on the disk without exception. The file system must be inspectable, meaning the owner can independently check it, including a thorough integrity check of the system boot chain. * Not only apps: Deep scan ready means you can inspect the whole system, not just installed applications. * Include boot components: The scan includes the partition table (how the disk is divided), bootloader (the first program that starts the system), kernel (the core part of the OS), init (initial startup process), system files, etc. * Keep malware inactive while scanning: Malware must not be active in memory during the scan. This requires: ** Offline deep scan: Or at minimum an Offline Integrity Check; a different boot medium must be used, such as booting from USB (Live USB Checkup). ** Detached deep scan: Even better, remove the disk and scan it from a different, clean system, on a different computer. * Support both tools and experts: The system can be scanned in various ways. ** Automated checksum verification tools: Important system files can be compared by their cryptographic checksums (hash sums) with known clean versions. This is being elaborated in chapter [[#Deep_Scan_Tools|Deep Scan Tools]]. ** Manual analysis by malware analysts: A human expert can inspect suspicious changes, unusual files, and unexpected startup components. ** Automated by virus scanners: While [[Malware_and_Firmware_Trojans#The_Utility_of_Antivirus_Tools|The Utility of Antivirus Tools]] is debatable, it may also be an option. Antivirus is not required. Use of antivirus is fully optional. = What is the difference of a deep scan versus a normal antivirus scan? = * Normal antivirus scan: Users typically do an antivirus scan after booting the system that is suspected of being infected with malware. This kind of scan runs inside the system you do not trust, so malware may be able to hide, interfere, or show false results. * Deep scan: A deep scan aims to inspect the full storage and boot components from outside the suspect system, so malware is not running while you scan. = Why should I care about computer viruses? = Malware can secretly spy on you (screenshots, files, keystrokes, webcam/mic) and steal or destroy data, including by encrypting your drive for ransom. It can also plant fake evidence and turn your computer into a "zombie" used for crimes (spam, DDoS, hosting illicit / illegal material). Worst of all, some malware can install persistent [[Backdoor|backdoors]] (including hardware level) that can survive a full operating system reinstall, and if the host is compromised, every {{VM}} is compromised too. See also [[Malware_and_Firmware_Trojans#The_Importance_of_a_Malware_Free_System|The Importance of a Malware Free System]]. = Deep Scan Ready vs Restricted Devices = Which operating systems are typically deep scan ready? Most, if not all, traditional Linux distributions are deep scan ready. You can boot a clean system and inspect everything, even if the installed OS is compromised. Alternative terminology would be forensic readiness for the device owner. Which operating systems are typically not deep scan ready? For example, stock Android. This is being elaborated on the [[Android|Android Insecurity]] wiki page. = Technical Implementation = How can an operating system implement being deep scan ready? There is usually no special "deep scan feature" to add. Deep scan readiness is mostly about not blocking the owner from inspecting the device from the outside. In practice, this means the owner must be able to boot a known clean external system (for example from USB) and read the storage for inspection, without having to trust the installed OS. What to avoid are designs that prevent this, for example a locked bootloader (the first startup program) that refuses to boot anything except vendor-approved software. This is also known as [[Miscellaneous_Threats_to_User_Freedom#restricted_boot|restricted boot]]. Instead, owner-approved software should be permissible to boot such as for example with [[Sovereign Boot]]. = Threat Model Differences = This section explains a fundamental difference in how devices can be designed: who ultimately controls the device, and who must be trusted. At a high level, it is about '''owner capability vs platform restriction'''. In other words: whether the device primarily serves the owner, or whether the owner must rely on the platform vendor for permission, visibility, and verification. In security terms, these approaches are called different '''trust models'''. A trust model describes who holds power, who can verify what is happening, and who must be trusted without being able to independently check. Two contrasting trust models are described below. * Vendor rooted trust: Vendor lockdown and vendor lock in. ** In this model, the platform decides what is allowed, and the vendor controls the root of trust, for example which cryptographic keys are accepted and which software is permitted to run. ** This means that the user mainly receives protection against third party attackers, but must inherently trust the vendor. If the vendor makes a mistake, is compromised, pressured, or behaves maliciously, the user has limited ability to independently detect or override that behavior. * User verifiable trust: Trust minimization through independent verification. ** In this model, the platform itself may be included in the threat model. This means the system is not automatically trusted simply because it is running. ** Because of this assumption, the design focuses on giving the device owner ways to check, verify, and if necessary replace the platform from outside, without trusting it while it is being inspected. This leads to several important properties: * Vendor accountability: The vendor cannot quietly, knowingly or unknowingly, ship different software or updates to different people. Targeted malicious upgrades become detectable rather than invisible. * Independent auditability: The system is designed so that third parties can inspect and analyze it. Trust does not rely solely on the vendor's claims. * Vendor independent verification: The owner can verify the system without having to trust the provider. Verification does not require permission from the vendor. * Full Device Backup Access: The device owner has the ability to make a complete system backup, rather than being restricted to partial or vendor approved data access. * Verified Boot: This trust model is compatible with owner controlled [[Verified Boot]] (User Settable Root of Trust), where the owner decides which software keys are trusted. A sample implementation work in progress is [[Sovereign Boot]]. * Tamper Evident Boot: A related concept is Tamper Evident Boot, where unauthorized modifications can be detected not only by the vendor, but also by the device owner themselves. The central distinction is not about convenience, but about control. In one model, trust flows from the vendor to the user. In the other, trust can be independently established by the owner. {{quotation |quote=Computer users must not be required to seek external authorization to exercise their freedoms. |context=Free Software Foundation: [https://www.fsf.org/campaigns/campaigns/secure-boot-vs-restricted-boot/ Will your computer's "Secure Boot" turn out to be "Restricted Boot"?] }} This quote highlights the concern that a system which requires external approval to function places inherent limits on the user's autonomy. {{quotation |quote=“Treacherous computing” is a more appropriate name, because the plan is designed to make sure your computer will systematically disobey you. In fact, it is designed to stop your computer from functioning as a general-purpose computer. Every operation may require explicit permission. |context=The GNU Project: [https://www.gnu.org/philosophy/can-you-trust.en.html Can You Trust Your Computer?] }} This perspective reflects a long standing critique of systems where control is shifted away from the owner and into external entities. Similar concepts exist in practice. For example: * Kali Linux provides a [https://www.kali.org/docs/general-use/kali-linux-forensics-mode/ Forensic Mode], which is designed around the idea that a system should be inspectable without trusting the environment being inspected. This illustrates the broader principle of user verifiable trust. = Advantages of Deep Scan Readiness = Deep scan readiness discourages targeted malicious upgrades, because it is harder to hide changes when owners can verify the full system from outside. = Deep Scan Tools = Deep scan readiness is not the same thing as actually running a deep scan. Deep scan readiness means that the system is designed in a way that allows thorough inspection when needed. Performing a deep scan is a separate action that can be done later, using appropriate tools. Deep scanning itself is [[unspecific|unspecific to {{project_name_short}}]]. In practice, this means that the same methods and tools a security expert would use to deeply inspect any other Linux distribution, such as Debian, can also be used to deep scan {{project_name_short}}. There are instructions on how to [[Recovery#Boot_from_External_Drive|Boot from External Drive]]. Booting from a clean external system allows inspection of the internal system without relying on the potentially compromised operating system itself. In the future, more documentation and tools are planned to make deep scanning easier and more user friendly, so that it becomes accessible to a wider range of users. One common deep scan method is checksum comparison. A checksum is a mathematical fingerprint of a file. If even a single bit of a file changes, its checksum changes as well. The basic process works as follows: 1. Boot the device from a clean and trusted external system. 2. Calculate checksums of important components such as the bootloader, kernel, and core system files. These parts are critical because they control how the system starts and operates. 3. Compare the calculated checksums with known clean data. If differences are found, this does not automatically mean malware. The difference could be caused by a different software version, a custom build, or intentional modifications. If necessary, a technical expert can examine the differences to determine their cause. Tools such as debcheckroot (or debcheckroot alike tools) can help verify the root file system by checking whether installed files match what the software packages are supposed to contain. This works by comparing files on the system with trusted reference data. Verification does not have to rely only on locally stored checksum data. It can use different sources, such as online repositories, CD, or DVD media. Using independent sources can be more reliable than trusting data stored on the same system being inspected. debcheckroot or similar tools (existing or yet to be invented) could support multiple verification sources, offline operation, and reproducible comparison against known good data, such as data from an official vendor software repository. This enables deep inspection without relying on traditional antivirus software. For critical components like the bootloader and kernel, checksum verification is often much more reliable than malware scanning alone. = out-of-scope = [[Backdoor#Firmware_Trojan|Firmware Trojan]] such as a [[Backdoor#Hard_Drive_Firmware_Trojan|hard drive firmware trojan]] and [[Backdoor#Hardware_Trojan|Hardware Trojan]] are unfortunately out-of-scope because these are hardware issues that a software-only operating system project cannot solve. These kinds of threats require hardware replacement or forensic hardware inspection. = objections = {| class="wikitable" ! Objection ! Response |- | If someone can access system files from an external system, that can be a security downgrade compared to a deep scan restricted system, because it could create an extra access path that could be abused. | The key point is that deep scan readiness is about what the ''owner'' of the device can do, not about giving new powers to the vendor or to random outsiders. In simple terms, this means: you, as the owner, are allowed to inspect your own device from the outside if you choose to. It does not mean that others automatically gain access. If the disk is encrypted, outsiders still cannot read the data without the owner's decryption credentials. Without your password or cryptographic key, the stored data looks like meaningless random data, even if someone can physically access the storage. If the device uses owner-controlled [[Verified Boot]] and [[Sovereign Boot]], outsiders also cannot silently replace or modify boot components. The boot process actively checks what is being started and can warn the owner or refuse to boot if something was altered without authorization. The overall design goal of owned-controlled Verified Boot is that external inspection or modification is only possible with the owner's explicit cooperation. This can include actions such as providing decryption credentials, unlocking the device, or physically allowing access. Without that cooperation, external access does not provide meaningful control or visibility. |- | Some malware can try to erase itself when you shut down or restart the device (or when it receives a "self delete" command). For example, Pegasus is reported to have such features. [https://info.lookout.com/rs/051-ESQ-475/images/lookout-pegasus-android-technical-analysis.pdf Lookout Pegasus Android technical analysis (PDF)] If that happens, a deep scan could look clean even though the device was infected. | This situation can still be investigated, but it often requires more advanced forensic techniques and expert involvement. It becomes less like running a simple scan and more like detective work. Even if the malware deletes its own files, it usually leaves other evidence behind. This can include unexpected system changes, failed or partial persistence attempts, unusual or inconsistent logs, configuration changes, patterns of reinfection, or other indirect indicators. In other words, while malware may remove its main components, it often cannot perfectly undo every change it made to the system. In more advanced cases, a trusted technical expert (with the owner's permission) could deploy a [https://en.wikipedia.org/wiki/Blue_Pill_(software) Blue Pill] alike monitoring approach. This refers to a stealthy, low level monitoring mechanism or a kernel hook that runs earlier in the system startup process than the malware itself. Because it starts first and hides its presence, the malware cannot easily detect or evade it. The purpose of such a setup is to quietly observe the malware's behavior, including attempts to self delete, reinfect the system, or modify components, without alerting the malware that it is being monitored. This topic is discussed in more detail in the wiki chapter [[Android#Malware_Analysis_Capabilities:_Traditional_Linux_vs._Android|Malware Analysis Capabilities: Traditional Linux vs. Android]]. |- |} = Deep Scan Restricted = Deep Scan Restricted means that the device owner is not able to fully inspect the operating system and the boot process from a clean, independent external system. This happens because critical components such as the bootloader, access to storage, or verification keys are controlled by the vendor rather than the owner. As a result, any inspection must rely on the already running system, even though that system itself could be faulty, compromised, or untrusted. In simple terms, the owner cannot step outside the device to check it independently, and must trust the platform while trying to verify it. = Comparison of Deep Scan Ready versus Deep Scan Restricted = {| class="wikitable" ! Feature ! Deep Scan Ready ! Deep Scan Restricted |- | User-verifiable trust | {{yes}} | {{no}} |- | External inspection possible | {{yes}} | {{no}} |- | Owner controls keys | {{yes}} | {{no}} |- | Offline/detached scan possible | {{yes}} | {{no}} |} '''Figure:''' ''Deep Scan Ready versus Deep Scan Restricted'' [[File:Deep_Scan_Ready_versus_Deep_Scan_Restricted.png|600px]] = rationale for this page = Why does this page exist when most traditional Linux distributions are deep scan ready anyhow? Sometimes we do not know what we have until we lose it. This page raises awareness, resists calls to also follow the path of locking device owners out from their devices, and differentiates owner-controlled systems versus vendor-locked operating systems that hinder deep scanning. = Forum Discussions = * [https://forums.kicksecure.com/t/bootloader-lock-locked-bootloader/1190 locked bootloader] * [https://forums.kicksecure.com/t/boot-device-lockdown/1189 boot device lockdown] * [https://forums.kicksecure.com/t/no-rescue-mode/1171 hard rescue mode refusal] = See Also = https://www.youtube.com/watch?v=zcFg0ZJ2E_A {{mobile_mininav}} {{boot_firmware}} = Footnotes = {{Footer}} [[Category:Design]] [[Category:Development]]