Chrome 127+ on Windows uses App-Bound Encryption (ABE) for v10-era cookies and passwords. The decryption key is no longer a user-bound DPAPI blob but an app-bound blob that requires a call to the elevation_service COM RPC (IElevator::DecryptData).
Because the elevation_service only responds to legitimate browser binaries (e.g., chrome.exe, msedge.exe, brave.exe), HackBrowserData cannot decrypt these keys directly from a standard Go process. Instead, it uses a multi-stage injection architecture:
- Preparation: The Go process reads an embedded native payload (~75 KB) and patches function pointers into its DOS stub.
- Injection: A fresh browser process is spawned in a suspended state. The payload is written into the browser's memory via
VirtualAllocEx and WriteProcessMemory. - Execution: A remote thread is created to run a C-based reflective loader (
Bootstrap) inside the browser process. This loader maps the payload into memory and executes its DllMain. - Extraction: The payload (the
abe_extractor) performs the COM RPC call to the elevation_service to retrieve the 32-byte master key. - Retrieval: The Go process waits for the payload to write the key into a specific memory offset, reads it via
ReadProcessMemory, and then terminates the throwaway browser process.
This approach ensures the project remains cross-platform and pure Go by default, as the heavy lifting for Windows-specific ABE is handled by a transient, injected native component.
browser/chromium.Extract()
→ masterkey.Retrievers{V10: &DPAPIRetriever{}, V20: &ABERetriever{}}
→ ABERetriever.RetrieveKey():
reads Local State → extracts APPB-prefixed blob
resolves browser exe via registry App Paths
→ utils/injector.Reflective.Inject(exePath, payload, env)
