moonD4rk/HackBrowserData · error

seek to start: %w

Error message

seek to start: %w

What it means

readFileContent wraps a failure of windows.Seek(handle, 0, 0) with the message "seek to start: %w". This happens in the fallback path of copyLocked: after FileMapping failed, the tool seeks the duplicated Chrome file handle back to offset 0 before using ReadFile. The seek itself failing means the duplicated handle does not support pointer repositioning (e.g. it was opened without appropriate access, or the handle state changed between duplication and read), so the file cannot be read via this handle.

Source

Thrown at filemanager/copy_windows.go:131

	if err != nil {
		return nil, err
	}
	if fileSize == 0 {
		return nil, fmt.Errorf("file is empty")
	}

	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
//

View on GitHub (pinned to 0503d04d7a)

Solutions

1. Re-run the extraction after checking that the target browser process is still alive and stable; a race with browser exit often breaks the duplicated handle.
2. Verify the tool runs as the same user as the browser process; duplicated handles with restricted access masks can reject seeks.
3. Retry the whole extraction — the normal copyFile path may succeed if Chrome releases the lock after a checkpoint or restart.
4. Update the library; if seeks consistently fail on this handle type the fallback path itself needs to open a fresh handle (FILE_READ_DATA) instead of reusing the duplicated one.

Example fix

// before
if _, err := windows.Seek(handle, 0, 0); err != nil {
    return nil, fmt.Errorf("seek to start: %w", err)
}
// after
if _, err := windows.Seek(handle, 0, io.SeekStart); err != nil {
    return nil, fmt.Errorf("seek to start: %w", err)
} // caller should also consider reopening src with os.Open when seek fails

// before extraction
if runtime.GOOS != "windows" {
    return errors.New("copyLocked fallback only exists on windows")
}
if _, err := os.Stat(src); err != nil {
    return fmt.Errorf("source unavailable: %w", err)
}

// Go: inspect the wrapped error and retry once
if err := s.Acquire(src, dst, false); err != nil {
    if strings.Contains(err.Error(), "seek to start") {
        time.Sleep(500 * time.Millisecond)
        err = s.Acquire(src, dst, false)
    }
    return err
}

When it happens

Trigger: Windows-only. Occurs in Session.Acquire(src, dst, false) when the normal copyFile fails because Chrome holds an exclusive lock, the code falls back to copyLocked, a matching handle is duplicated via findFileHandle, but winapi.MapFile fails and the subsequent windows.Seek on the duplicated handle returns an error (invalid handle state, insufficient access rights on the duplicated handle, or the handle refers to something not seekable).

Common situations: Chrome/Edge holds the Cookies DB open with PRAGMA locking_mode=EXCLUSIVE; the handle was duplicated with DUPLICATE_SAME_ACCESS but the owning process's access mask doesn't permit file-pointer operations; handle-table races where Chrome closes the handle between DuplicateHandle and Seek; security software interfering with duplicated handles.

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

• ReadFile: %w
• locked copy: %w
• abe: read Local State: %w
• DPAPI not supported on this platform
• abe: Local State has no app_bound_encrypted_key

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