18.4 Browser Artifact Recovery, Private Browsing, USB Enumeration, Partition Recovery & Packer Unpacking Tools

18.4 Browser Artifact Recovery, Private Browsing, USB Enumeration, Partition Recovery & Packer Unpacking Tools

Quick Answer: Blueprint Domain 6 names tools to examine the cache, cookie, and history recorded in web browsers, private browsing and browser artifact recovery, USB device enumeration using Windows PowerShell, partition recovery tools, and program packers unpacking tools. Two facts anchor the section: Chromium timestamps are WebKit time — microseconds since 1601-01-01 UTC, while Firefox uses PRTime — microseconds since the Unix epoch; and private browsing is not private to a forensic examiner, because RAM, the pagefile, the hibernation file, the DNS cache, and NTFS journal records all retain traces.

---

Browser Artifact Locations and Schemas

Chromium Family (Chrome, Edge, Brave, Opera, Vivaldi)

Profile base: %LocalAppData%\Google\Chrome\User Data\Default\ (Edge substitutes Microsoft\Edge).

The typed_count column deserves attention. A URL with a non-zero typed_count was manually typed into the address bar, which distinguishes intentional navigation from a redirect or an embedded resource — a distinction that matters enormously in possession and intent cases. The visits.transition value carries the same information at per-visit granularity (LINK, TYPED, AUTO_BOOKMARK, RELOAD, FORM_SUBMIT).

Firefox

Profile: %AppData%\Mozilla\Firefox\Profiles\<random>.default-release\.

Legacy Internet Explorer / Edge Legacy

WebCacheV01.dat is an ESE (Extensible Storage Engine) database holding history, cache, cookies, and download records in container tables. Parse with esedbexport, ESEDatabaseView, or a dedicated parser; dirty databases may need esentutl /r recovery against a working copy only. Older systems use index.dat.

Timestamp Formats — the Recurring Trap

-- Chromium History: convert WebKit time to a readable UTC timestamp
SELECT url, title, visit_count, typed_count,
       datetime(last_visit_time/1000000 - 11644473600, 'unixepoch') AS last_visit_utc
FROM urls ORDER BY last_visit_time DESC;

The constant 11,644,473,600 is the number of seconds between 1601-01-01 and 1970-01-01. Applying the Firefox conversion to a Chromium value — or omitting the offset — produces timestamps centuries adrift, and it is one of the most common avoidable errors in browser timeline work.

Tooling

[!IMPORTANT] Always collect the -wal and -shm files alongside every browser SQLite database. In WAL mode, recent transactions — including records the browser has "deleted" — live in the write-ahead log and have not yet been merged into the main database. Copying only History without History-wal silently discards the most recent and most relevant activity.

---

Private Browsing: What Actually Survives

Incognito and Private Browsing suppress disk writes of history, cookies, and cache for the session. They do not make the session invisible.

[!IMPORTANT] Private browsing changes only what the browser writes. It changes nothing about what the operating system, the network, or the memory subsystem retain. Where the private session is the crux of the case, memory acquisition is the priority action and hiberfil.sys is the fallback if the machine has already been powered down.

---

USB Device Enumeration with Windows PowerShell

The triangulation from three artifacts is the standard method:

# Live host: currently and previously enumerated USB storage devices
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR\*\*' |
    Select-Object FriendlyName, PSChildName, Service, ContainerID

# Present-state view including removed devices
Get-PnpDevice -Class USB -Status OK,Unknown |
    Select-Object FriendlyName, InstanceId, Status

# Mounted image: load the exported SYSTEM hive under a temporary key and query it offline
reg load HKLM\EvidenceSYSTEM E:\evidence\SYSTEM
Get-ChildItem 'HKLM:\EvidenceSYSTEM\ControlSet001\Enum\USBSTOR' -Recurse |
    Select-Object Name
reg unload HKLM\EvidenceSYSTEM

# First-connection times straight out of setupapi.dev.log
Select-String -Path 'C:\Windows\INF\setupapi.dev.log' -Pattern 'Device Install \(Hardware initiated\).*USBSTOR' -Context 0,2

Serial-number caveat: the second character of a USBSTOR serial being & indicates the device did not report a hardware serial and Windows generated an instance identifier instead. Such an identifier is host-specific, so it cannot be used to prove the same device was connected to a different machine.

---

Partition Recovery Tools

When a partition table is wiped, corrupted, or overwritten, an entire volume appears as raw unallocated space. Partition recovery works by scanning the raw device for file system signatures — NTFS and FAT boot sectors, ext superblock backups, HFS+/APFS volume headers — and rebuilding the table from what it finds.

[!WARNING] Run recovery only against a working copy of the image, never the original evidence or the original media. TestDisk in write mode alters the partition table. The forensically sound sequence is: image → hash → duplicate the image → run recovery on the duplicate → document the change → re-verify the original's hash is unchanged.

GPT's built-in redundancy is the examiner's friend: a primary GPT header destroyed at LBA 1 has a backup copy in the final sector of the disk, so a "destroyed" GPT disk is often recoverable in a single step.

---

Program Packers and Unpacking Tools

A packer compresses and/or encrypts an executable and prepends a stub that reconstructs the original in memory at run time. The blueprint lists program packers among anti-forensics techniques and lists program packers unpacking tools in the tool domain.

Identifying a Packed Binary

Detection tools: Detect It Easy (DiE), PEiD (legacy signatures), PEStudio, ExeinfoPE, pefile plus an entropy script in Python.

Unpacking Approaches

1. Native unpacker — UPX ships upx -d, which cleanly restores a genuinely UPX-packed file. Attackers often modify UPX headers specifically to break this.
2. Dynamic unpacking (the general method) — run the sample in an isolated, instrumented VM and dump the process from memory once the stub has reconstructed the payload at the original entry point (OEP), then rebuild the import table. Tools: x64dbg with the Scylla import reconstructor, OllyDumpEx, PE-sieve and HollowsHunter (which detect and dump implanted or hollowed modules automatically).
3. Emulation / sandbox unpacking — unipacker, Qiling, and sandbox platforms that snapshot memory after unpacking.
4. Memory-image extraction — where only a RAM image exists, Volatility's malfind and VAD dumping recover the unpacked image in exactly the same way described for reflective .NET loading in Section 12.5.

Commercial protectors (Themida, VMProtect, Enigma) go beyond packing into code virtualization, translating the original instructions into a custom bytecode interpreted by an embedded VM. These are not "unpacked" in any straightforward sense; analysis proceeds by behavioral observation and by targeted devirtualization, which is expert-level work and should be scoped accordingly.

Detecting Data Hiding in File System Structures with OSForensics

The blueprint names one product for this task specifically: OSForensics from PassMark Software. It matters here because concealment rarely uses one technique in isolation — a single case may combine a renamed executable, a payload parked in an alternate data stream, and a deleted staging file — and OSForensics puts the corresponding searches in one workflow over a mounted image.

Two practical cautions carry into the exam. First, an ADS or mismatch hit is a lead, not a finding — the examiner opens the stream or the header and reads what is actually there, because legitimate software writes both benign streams (the Zone.Identifier mark-of-the-web discussed in Section 6.2) and files whose extensions are genuinely unconventional. Second, the tool-validation rule from Section 16.3 applies with full force to concealment claims: a hiding allegation that rests on a single automated scan is corroborated with a second, independently validated tool before it reaches a report, which is also the defense against the anti-forensic technique of feeding a parser malformed structures.

Detecting overwritten data and metadata is the same problem viewed from the other end. Where a file has been overwritten in place, the surviving proof is circumstantial and lives in the structures around it: $LogFile and $UsnJrnl transaction entries naming the file, an $MFT record whose $STANDARD_INFORMATION and $FILE_NAME timestamps disagree, a Volume Shadow Copy or APFS snapshot predating the overwrite, and Prefetch or Amcache evidence that a wiping utility ran at all.