The Digital First Responder: Order of Volatility, Seizure and Imaging

The first responder is the bridge between a chaotic scene and a controlled lab. On a raid for a Section 66 IT Act offence in a Bengaluru flat, the responder is usually a constable trained at the state cyber cell, occasionally accompanied by an SFSL examiner if BNSS Section 176(3) is triggered. The responder does not run forensic tools to look for evidence. The responder runs a fixed sequence whose only goal is to freeze the state of every device on the scene long enough for the SFSL to produce a defensible image.

The first decision is whether each device is on, off, or in standby. A powered-off device is the easy case: do not turn it on, photograph the cables in place, label every port, bag the unit. A powered-on device is the hard case: the screen content, the running processes, the active network connections and the contents of RAM are all evidence that will be gone the second power is removed. Standby is the worst case because waking the device can trigger a screen lock or a re-encryption that destroys the live decryption keys held in RAM.

The responder kit is small and standardised, kept in a sealed case at the cyber cell. Faraday bags in three sizes (phone, tablet, laptop). Hardware write blockers (Tableau T35u or WiebeTech UltraBlock are the common ones in Indian SFSLs). A forensic laptop with FTK Imager and Magnet RAM Capture preloaded. Verified-clean target disks, sanitised before each job to NIST SP 800-88 Clear. Anti-static evidence bags, tamper-evident tape, labels, chain-of-custody forms (BNSS Form 16 series for search and seizure), a known-good USB power bank to keep laptops alive in transport, and a stills camera plus video camera for BNSS Section 105 compliance. The kit's contents map directly onto the hardware classes covered in Computer Hardware Fundamentals for Forensic Examiners; the IT Act sections that authorise the seizure itself are in Cyber Crime Taxonomy and the IT Act 2000.

RFC 3227 specifies the order in which evidence must be collected on a live system, from the most volatile to the least persistent. The ordering is built around how long each artefact survives once the system state changes.

1. CPU registers and cache
   Survive nanoseconds. Realistically not capturable on commodity hardware; treated as out of scope for field response.
2. Routing table, ARP cache, process list, kernel statistics, RAM
   Survive only while the system is powered. RAM capture is the first real action on a live machine.
3. Temporary file systems
   Tmpfs, /tmp on Linux, %TEMP% on Windows. Survive until reboot or scheduled cleanup.
4. Disk
   Persistent until written over. Imaging happens after volatile capture, with the system powered off and a write blocker in line.
5. Remote logging and monitoring data
   Logs forwarded to a SIEM or syslog server. Survive on the remote system; capture by formal request to the operator.
6. Physical configuration and network topology
   Survive on paper or in network diagrams; captured by photograph and notes.
7. Archival media
   Tapes, optical, cold storage. The least volatile; collected last.

The ordering matters because every step taken on a live machine writes to disk, modifies caches, and changes the very state being captured. The minimum-footprint principle says: use the smallest set of tools, run them from external media, write the output to external media, and document every command. On a Windows 10 box, a single typed command at an Administrator PowerShell prompt creates entries in Amcache.hve, the PowerShell operational event log, and the Prefetch directory. The responder accepts that footprint as the cost of the capture and documents it.

The classic field debate is whether to pull the plug, perform a graceful shutdown, or leave the machine running. The consensus in 2026 is: capture RAM first with a tool run from external USB, then for a desktop pull the plug (hard power-off avoids the disk writes that a graceful shutdown triggers, including paging and Windows hibernation), and for a laptop with a battery follow RAM capture with a graceful power-off only if the disk is encrypted and the keys are already extracted. The shutdown decision is documented in the seizure memo and survives appellate scrutiny only if the rationale is on paper.

RAM holds the most consequential volatile evidence on a live machine. A running BitLocker volume holds its full-volume encryption key in RAM. A live TrueCrypt or VeraCrypt container has the same exposure. A logged-in Telegram or Signal desktop client holds decrypted message buffers. A WhatsApp Web session holds the linked-device key. Browser tabs hold session cookies and OAuth tokens. Once the machine is powered off, all of this is gone.

The Indian SFSL toolkit converges on four RAM capture utilities, each with a known-good provenance:

The capture is written to an external USB drive that has been wiped, hash-verified empty, and labelled with the case number before the responder arrives. The size of the dump equals the size of installed RAM (16 GB on a typical seized laptop in 2026, sometimes 32 or 64 GB on a developer machine), so the USB has to be large enough and fast enough that the capture completes before the user, the network, or a watching attacker reacts. On Linux scenes, LiME (Linux Memory Extractor) is the standard, built as a kernel module against the target kernel version; on macOS, the practical option is AVML from Microsoft or osxpmem from Volatility, with the caveat that recent System Integrity Protection and Apple Silicon kernels make this much harder than on Windows.

The seizure step is where the technical workflow meets BNSS 2023. Section 105 mandates audiovisual recording of search and seizure. Section 185 governs search by a police officer. The IT Act 2000 Section 80 gives a police officer not below the rank of Inspector the power to enter and search public places for offences under the Act, while a magistrate's warrant is the cleaner route for private premises. BSA 2023 Section 63 governs the admissibility of electronic records as evidence, and a Section 63(4) certificate from the person in charge of the device or computer system is the document that gets the image into court.

The on-scene sequence:

• Photograph the device in place, front, rear, and every connected cable. The photographs go into the case file with EXIF timestamps that must agree with the seizure memo within 30 minutes. This same discipline applies to physical-evidence scenes; see Bharatiya Nagarik Suraksha Sanhita on investigation for the BNSS Section 105 videography baseline.
• Document the state: powered on or off, screen content (photograph the screen exactly as found, do not move the mouse), monitor brightness, attached USB devices with their make, model and serial, the network cable or Wi-Fi association if visible from the OS.
• Capture RAM if the device is live, by the method above.
• Power down: pull the plug for desktops, graceful shutdown for laptops with battery only after RAM capture and only if encryption keys are extracted.
• Disconnect peripherals, label each port with which cable came from where (small adhesive numbered labels are standard in CFSL Hyderabad kits).
• Place the device in an anti-static bag, then in a tamper-evident outer bag. Mobile phones go directly into a Faraday bag to prevent remote wipe by the suspect or by an MDM trigger.
• Seal the outer bag with tamper-evident tape signed across the seam, photograph the seal, log the seal number and the panch witnesses' names on the BNSS Form 16 seizure memo.

Transport in a padded, anti-static case kept upright. The chain of custody opens at the seizure timestamp and is logged at every handoff; the Chain of Custody topic walks the four reliable failure modes and the leading Indian appellate cases.

Once the bagged device reaches the lab, the imaging step begins. The non-negotiable rule is that the source disk is read but never written to. This is enforced by a write blocker, which sits between the source disk and the examination station.

The Windows registry trick of disabling autorun and mounting USB read-only via a registry value (HKLM\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies\WriteProtect = 1) is not a real write blocker. The OS can still write to non-USB interfaces, the registry value can be overridden by a service, and Windows is known to issue diagnostic writes to mounted volumes during indexing. A hardware blocker, tested for the case and listed in the SFSL equipment register, is what survives cross-examination.

Imaging formats split into raw and container:

• dd: the original raw format, a flat bit-by-bit copy. Universally readable. No metadata, no compression, no built-in integrity check.
• dcfldd and ddrescue: variants of dd. dcfldd adds on-the-fly hashing and per-chunk verification. ddrescue handles failing media by reading the easy blocks first and retrying bad blocks with shrinking block sizes; on a degraded disk it gets more data out than dd will.
• EnCase E01 (Expert Witness Format): container format with compression, internal CRC-32 per chunk, embedded metadata (case number, examiner, hash). Splittable into 2 GB segments by convention. Default in EnCase and FTK; widely accepted in Indian courts.
• AFF4: open container, modern, supports sparse and partial images, multi-stream and remote storage. Slowly gaining ground in cloud and SaaS forensics but not yet standard at Indian state SFSLs.

The choice of format follows from the disk. A 4 TB spinning disk with bad sectors goes to ddrescue. A working SSD goes to FTK Imager or dc3dd to E01 with compression. A cloud-mounted volume with sparse extents goes to AFF4. The format chosen is recorded on the analyst worksheet and in the BSA Sec 63 certificate.

The hash discipline is the dual-hash standard: MD5 and SHA-256 computed in parallel, on the source before imaging, on the image, and again on the image at any later access. MD5 alone is now considered weak because of demonstrated collisions, but it is computationally cheap and pairs well with SHA-256 for redundancy. SHA-1 is sometimes used as a third hash in legacy SFSL workflows. A matched-hash report in the BSA Sec 63 certificate reads: "MD5 of source <hex> matches MD5 of image <hex>; SHA-256 of source <hex> matches SHA-256 of image <hex>; verified bit-by-bit." That sentence, signed by the Section 79A examiner, is what carries the image into evidence.

Before any image is written, the destination disk is sanitised. A previously used target carries residual data that, if it surfaced in the image, would let the defence argue the image is contaminated. The two accepted sanitisation standards are DoD 5220.22-M (three-pass overwrite) and NIST SP 800-88 (which on modern self-encrypting drives prefers a cryptographic erase by rotating the internal encryption key, taking seconds rather than hours). The SFSL records the sanitisation method, the verification hash of the zeroed disk, the date, and the examiner ID.

Disk cloning and disk imaging are not the same operation. Cloning produces an exact functional copy on identical hardware: same partition layout, same boot record, the clone will boot as if it were the original. Imaging produces a container file that captures the bits but does not boot. Cloning is used when the workflow needs a working copy of the system (for example, a recovery exercise on the clone while the original is shelved); imaging is used for analysis, archive and court production. In Indian SFSL practice the standard is to image first, archive the image, then optionally clone from the image for working analysis.

Encrypted disks split into two cases. If RAM was captured while the volume was unlocked, the key is in the dump and the analyst extracts it with Volatility, Passware, or the Magnet AXIOM BitLocker module. The recovered key unlocks the image, which is then imaged a second time in plaintext form for analysis; both the encrypted image and the plaintext re-image are kept, with hashes for each. If RAM was not captured or the key is not in it, the BitLocker recovery key sources are: a printed sheet in the suspect's papers, an export from a Microsoft Account at account.microsoft.com/devices/recoverykey (which CERT-In or I4C can request via formal channels), an Active Directory escrow (msFVE-RecoveryInformation), or a key escrow held by an enterprise MDM. If none of those produce a key, the volume stays encrypted and the case proceeds on whatever artefacts can be recovered from outside the encrypted partition, including the EFI System Partition, the recovery partition, and any unencrypted swap space.

Quick format vs full format matters at the recovery edge. A Windows quick format rewrites only the file system metadata and leaves the data clusters intact; the file table is gone but most files are recoverable through file carving. A full format on Windows 10+ overwrites the volume with zeros and renders recovery practically impossible, except for clusters that were spared by SSD wear levelling. Fuller coverage of recovery from formatted, deleted, and hidden storage is in Data recovery, file carving and deleted or encrypted content; for the in-OS artefact view of the imaged disk, see Windows artifacts: ShellBags, ADS, LNK, hibernation, slack.