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
- Retry the extraction — transient handle races with a running browser often resolve on a second attempt.
- Close the browser (or wait for it to flush/checkpoint) so the plain copyFile path succeeds without needing the locked-file fallback.
- Run under the same user account that launched the browser so DUPLICATE_SAME_ACCESS yields a readable handle.
- 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
- Add AV/EDR exclusions for the tool when doing authorized research
- Close the browser when possible so the normal copy path is used
- Run under the browser owner's account
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
- seek to start: %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/4df36f70ca6d9cbd.
Report an issue: GitHub.