moonD4rk/HackBrowserData · error

ReadFile: %w

Error message

ReadFile: %w

What it means

readFileContent wraps a failure of windows.ReadFile with "ReadFile: %w". This is the last-resort read path in copyLocked: FileMapping already failed, so the tool falls back to reading the whole file (size bytes) from the duplicated Chrome handle via the Win32 ReadFile API. If ReadFile fails, the locked-file bypass cannot recover the database content and the extraction of that file fails.

Source

Thrown at filemanager/copy_windows.go:136

	}

	size := int(fileSize)

	// Try FileMapping first — reads from kernel file cache, includes WAL data
	if data, err := winapi.MapFile(handle, size); err == nil {
		return data, nil
	}

	// FileMapping failed, fall back to ReadFile.
	// Seek to beginning first — the handle's file pointer may be at an
	// arbitrary position.
	if _, err := windows.Seek(handle, 0, 0); err != nil {
		return nil, fmt.Errorf("seek to start: %w", err)
	}
	data := make([]byte, size)
	var bytesRead uint32
	if err := windows.ReadFile(handle, data, &bytesRead, nil); err != nil {
		return nil, fmt.Errorf("ReadFile: %w", err)
	}
	return data[:bytesRead], nil
}

// extractStableSuffix extracts a path suffix that is stable across short/long
// path name variations. It finds "AppData" in the path and returns everything
// after "AppData\Local\" or "AppData\Roaming\" in lowercase.
//
// Example:
//
//	C:\Users\RUNNER~1\AppData\Local\Google\Chrome\...\Cookies
//	→ google\chrome\...\cookies
//
// For paths without "AppData" (e.g., test temp dirs), it falls back to
// the last 3 path components to provide reasonable matching specificity.
func extractStableSuffix(path string) string {
	lower := strings.ToLower(path)
	// Try to find AppData\Local\ or AppData\Roaming\

View on GitHub (pinned to 0503d04d7a)

Solutions

  1. Retry the extraction — transient handle races with a running browser often resolve on a second attempt.
  2. Close the browser (or wait for it to flush/checkpoint) so the plain copyFile path succeeds without needing the locked-file fallback.
  3. Run under the same user account that launched the browser so DUPLICATE_SAME_ACCESS yields a readable handle.
  4. Check AV/EDR exclusion lists — security software frequently denies ReadFile on browser credential stores opened through unusual handle paths.

Example fix

// before
data := make([]byte, size)
var bytesRead uint32
if err := windows.ReadFile(handle, data, &bytesRead, nil); err != nil {
    return nil, fmt.Errorf("ReadFile: %w", err)
}
// after
data := make([]byte, size)
var bytesRead uint32
if err := windows.ReadFile(handle, data, &bytesRead, nil); err != nil {
    return nil, fmt.Errorf("ReadFile %d bytes: %w", size, err)
} // add error-context; caller surfaces it alongside the original copy error
Defensive patterns

Strategy: retry

Validate before calling

// check the target is a real, non-empty file before attempting locked copy
fi, err := os.Stat(src)
if err != nil || fi.IsDir() || fi.Size() == 0 {
    return fmt.Errorf("cannot locked-copy %s: %w", src, err)
}

Try / catch

// Go: treat ReadFile failures in the fallback as transient
if err := s.Acquire(src, dst, false); err != nil {
    if strings.Contains(err.Error(), "ReadFile:") {
        if retryErr := s.Acquire(src, dst, false); retryErr == nil {
            return nil
        }
    }
    return err
}

Prevention

When it happens

Trigger: Windows-only. Session.Acquire on a locked file where findFileHandle successfully duplicated Chrome's handle, winapi.MapFile failed (e.g. mapping size constraints, access rights), and the ReadFile call on the duplicated handle errors — handle lacks read access, buffer/size issues, I/O error on the underlying file, or the handle became invalid after duplication.

Common situations: Duplicated handle was opened GENERIC_WRITE-only or with no FILE_READ_DATA by the browser; antivirus blocking reads of the Cookies database; very large file where allocation of the size-byte buffer fails indirectly; Chrome exiting mid-copy invalidating the handle's backing file state.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors


AI-assisted analysis of moonD4rk/HackBrowserData@0503d04d7a (2026-09-06). Data as JSON: /api/errors/4df36f70ca6d9cbd. Report an issue: GitHub.