Hello,
I am writing to report a critical flaw in the new Firefox Local Backup mechanism (HTML-based container). After formatting my PC and installing a fresh copy of Wind… (read more)
Hello,
I am writing to report a critical flaw in the new Firefox Local Backup mechanism (HTML-based container). After formatting my PC and installing a fresh copy of Windows 10/11, I attempted to restore my 10 years of browser history using a valid backup file (.html, ~102 MB) created by Firefox 153.0.4.
Although the password was correct (the UI immediately rejected incorrect ones), the restore process completely failed and entered a destructive loop. Instead of extracting the data, Firefox started infinitely creating hundreds of empty profile folders in %AppData%\Roaming\Mozilla\Firefox\Profiles without throwing a visible error to the user, completely messing up the profiles.ini file.
What had to be done to recover the data:
Since standard unarchivers (7-Zip) and tools like Windows certutil couldn’t parse the hybrid HTML/Base64 container, we had to reverse-engineer the recovery process using the internal Firefox source modules (PreferencesBackupResource.sys.mjs and SessionStoreBackupResource.sys.mjs from omni.ja).
We had to write a custom Node.js script to:
- 1 Parse the specific block-by-block Base64 encoding used by Mozilla inside the HTML wrapper.
- 2 Manually decrypt the raw binary data using the backup password.
- 3 Extract places.sqlite, logins.json, key4.db, and sessionstore.jsonlz4 manually.
- 4 Manually inject these files into a freshly registered profile.
The Bug Core:
The built-in extractor in Firefox fails on fresh OS/browser installations due to path/profile synchronization errors, causing a crash loop that generates endless ghost profiles.
Please review the block-by-block extraction logic and add strict exception handling to the Local Backup UI so it doesn't break the profile directory when a routine error occurs.
Thank you.