Password decryption failed. Passwords protected by a Master Password! about firefox_decrypt HOT 19 CLOSED

Hi @kirsn,

In your case it seems the problem is that the script didn't find libnss.

Seeing that you have Firefox 64bits, can you tell me the full path where do you have Firefox installed (something like C:\Program Files\Firefox and also if you find a nss3.dll file on this folder?

from firefox_decrypt.

Hello @unode, thanks for your prompt response.

Yes, the nss3.dll is available in this path: C:\Program Files\Mozilla Firefox\nss3.dll . The log file has a line where it states Loading NSS library from C:\Program Files\Mozilla Firefox\nss3.dll . So am not sure why the log ends with this message PR_LOAD_LIBRARY_ERROR: Failure to load dynamic library.

from firefox_decrypt.

You are correct. I misread and was mislead by the final error message.

Having a second look it does seem to be similar to #3. From the sequence of events it seems the password you are introducing isn't correct, possibly due to encoding problems. Unfortunately this is something I haven't managed to reproduce on my system (not Windows).

If you can spare some time it would be great if you could try a few things.
Make a backup of your Firefox profile before performing any change - the whole 1m2zwcfb.default folder to be safe.

A few things to try:

1. Create a new Firefox profile and add some dummy passwords to the database (try to login to some website with dummy credentials). No master password yet. Does it work?
2. Add a master password to the new profile. Any changes?
3. Set the same master password you have on your main profile. Still works?
4. If 1, 2 and 3 succeed: removing the master password from your main profile and use firefox_decrypt without password. Does it still fail?
5. Re-add or replace the password with a simpler one (numbers only). Any change?
6. If all above are inconclusive, try removing or modifying some passwords from your main profile. If there is one or more problematic passwords, it should at some point start/stop working.

If 1 fails this is suspicious and might be due to some incompatibility on the system. Python or libnss, hard to say.

If 1 works but 2 or 3 fail, it would be great if you could make that Firefox profile available... It would certainly help in reproducing the problem.

from firefox_decrypt.

@unode, will give this a shot.
As an aside, am thinking of writing a simple testcase for this, using hypothesis. The idea (and that's basically what it is now), is to see if we can use hypothesis to generate various sample inputs (basically to address steps 1 through 6, stated above)
I'll need a means to create various samples of encrypted logins.json , and provide that as a sample profile. This is what the browser does anyway. I'll need to see if NSSInteraction or equivalent can help encrypt content.

If am not able to make progress with this, then I'll revert to the manual steps mentioned above.

from firefox_decrypt.

Sounds like a fun endeavour. I've never tried to create entries using NSSInteraction.
Take your time.

I've also been considering migrating the test suite to Python in order to automate testing Windows too so this will be in line with that.

from firefox_decrypt.

FYI: Some migration progress on pytests branch.

from firefox_decrypt.

@unode, thanks for the details.
I'll need some help with this work; especially around the API, and also to get some feedback on the direction am going in. Should I post my questions / comments here ... or is there an IRC / Gitter channel, or something equivalent that works for you?

from firefox_decrypt.

Here is fine. I also idle on some Freenode channels if you prefer something more interactive.

from firefox_decrypt.

As for API, you will likely need PK11SDR_Encrypt and NSS_InitReadWrite instead of NSS_Init which is what the current code uses.
Then to set a master password you probably need InitPW or ChangePW.

Finally to add new records, you'll have to create an interface to write logins.json yourself since this is Firefox/Thunderbird/... specific.

So far the code initializes a different interface depending on Firefox version (JSON, SQLite,...). You can skip SQLite and focus on JSON which covers most recent Firefox versions. Aiming at having QuickCheck/hypothesis tests for Firefox 59+ should be sufficient.

from firefox_decrypt.

@kirsn can you check if the commit above changed anything for you?

from firefox_decrypt.

@kirsn In the original log file you masked your username.
Can you say if you have non-ASCII characters in there or if the Windows version you are using is non-English?

Thanks

from firefox_decrypt.

@unode , apologies for the delayed reply.
The usernames are plain ASCII. And my locale is en_US.

Running: python -c "import sys; print sys.stdin.encoding" displays cp437

Also. took a look at the commit from above (didn't try it out, but just looked at the code), and it seems to address sqllite related changes.
I haven't made progress on the hypothesis related code - hope to get back to it this week.

from firefox_decrypt.

@kirsn #28 was fixed and reported success. I think that fix might also apply here. Would you mind giving it another try?

If this now works for you, would you mind renaming the issue to reflect the work on hypothesis testing. Thanks.

from firefox_decrypt.

@unode tried the following, but no luck.
First git clone the repo, and use code from trunk.

• Trial 1: run without specifying the profile path -- without-specific-profile-path.txt
• Trial 2: run with specifying the profile path -profile option -- with-specific-profile-path.txt
• Trial 3: cd to the profile path, and run the code from there -- run-from-inside-specific-profile-path.txt
• Trial 4: I took the latest commit, and tried. Result was the same as Trial 3 above.

A few other things:

• Am using Firefox Nightly.
• On line

  firefox_decrypt/firefox_decrypt.py

  Line 812 in d349dd1

  parser.add_argument("profile", nargs="?", default=profile_path,

  should be parser.add_argument("-profile" ... ?

In any case, I'll open a separate issue to track the hypothesis-tests?

from firefox_decrypt.

Thanks for the very comprehensive report!

I'm not familiar with how Firefox Nightly installs on Windows.
Checking online it seems it defaults to installing on C:\Program Files\Nightly (or Program Files (x86) if 32bits).
I've just pushed a commit that adds these paths to the search list. If you are using these locations Trial 1 and 2 should now at least find NSS. They may still fail if something else is amiss.

profile is supposed to be the place where you have your Firefox settings.
It was defined as parser.add_argument("profile"... so that you can launch with firefox_decrypt.py C:\Users\Admin\AppData\Roaming\Mozilla\Firefox instead of firefox_decrypt.py --profile C:\Users\Admin\AppData\Roaming\Mozilla\Firefox\. The profile path is a pretty crucial piece of information so it made sense to have it as a positional instead of --optional argument.
Strictly speaking it's not required so having it as --profile would be more consistent with convention but who wants to type --profile every time 😄 .

Since in your case it seems the script is failing to find (Trial 1 and 2) or failing to interact with nss3.dll (Trial 3 and 4).

1. Could you add a "Trial 5" where you do cd <where you installed Firefox>, check that nss3.dll exists in that location and launch firefox_decrypt.py from there?

If this works then it's clear that the problem is locating NSS or one of its dependencies.

It's curious that in Trial 3 and 4 it seems to find nss3.dll but doesn't in Trial 1 and 2.
I'm a little surprised by this since specifying a profile path shouldn't affect how nss3.dll is loaded but your tests seem to point otherwise. Not sure what to make of this.
From the logs I would assume that there is a nss3.dll in your profile folder but this would be unusual.

2. Could you run a system-wide search for nss3.dll and report all locations found?

Furthermore Trial 1 and 2 both fail on the hardcoded default installation paths which is consistent with your Firefox installation living elsewhere. If this is the only problem "Trial 5" described above should succeed (at least up to finding NSS).

from firefox_decrypt.

A copy of nss3.dll lives in C:\program files\Firefox Nightly.
I also see that there are several nss3.dlls in my system - installed folders of Mozilla Thunderbird folder, Pidgin, Tor Browser, and LibreOffice.

My trials 3 & 4 picked up the nss3.dll, in Nightly, because I ran the code from within the C:\program files\Firefox Nightly folder. I mistakenly called this the profile path, when I meant the installed path. Sorry, for the confusion. So Trial 5 is the same as Trials 3 & 4.

Noted the purpose of the profile option, and how to use it. Thanks for the description.

Is there anything else you would like me to try?

from firefox_decrypt.

@kirsn thanks for the tests once again.

If you tried running from the installed path and it didn' work I'm afraid I'm out of ideas.
Other than mixing different architectures (32bit and 64bit) of Python and nss3.dll and issues with library search path, all of which have been excluded here, only encoding remains. That or something entirely new...

The last option would be to try running it from the several locations where nss3.dll exists but any success here would be as puzzling as a failure.

Perhaps we can try to get a reproducible failure on AppVeyor and go from there.
Thanks for the patience and all the help debugging this.

from firefox_decrypt.

@unode no problem at all. I'll see if I can spend some more time to diagnose what could be wrong. Will update this issue, when I do.

Not sure if you saw this, but the default encoding on my Windows10 box is cp437. Got this from running python -c "import sys; print sys.stdin.encoding"

Also, will open a separate issue (more as a task), to address the hypothesis based testing.

from firefox_decrypt.

@kirsn It has been a couple of years but, if you are still using this, you may want to try the UTF-8 mode.

Feel free to reopen the issue if that doesn't solve it.

from firefox_decrypt.