Page 1 of 1
Firefox profile decryption
Posted: Wed Feb 10, 2021 12:22 pm
by Lunasole
Hi. This is some dirty example of decrypting Firefox profile data.
It requires dlls from Firefox package to work (
freebl3.dll, mozglue.dll, nss3.dll, softokn3.dll).
Also requires at least
cert9.db and
key4.db profile files (taken from profile folder), to perform decryption of profile databases.
Profile databases are files like "cookies.sqlite", "places.sqlite", storing different things like browsing history, etc.
The encrypted strings from databases can be obtained by reading them in any way (using soft like SQLlitedatabaseBrowser or in-code, or even by opening in notepad, if so much lazy).
So generally this code can decrypt those strings, if they are not additionaly protected with master-password.
If master-password was used, it will be required (and some different code here).
Should work with any actual Firefox version.
I don't know for what someone may need it, maybe for some recovery in some cases. But let it be at least for experimental purposes ^^
Code: Select all
EnableExplicit
;{ NSS3 }
Structure SECItem
type.i
*Data
len.i
EndStructure
Global nss3Lib
PrototypeC PK11SDR_Decrypt(inp, out, None): Global PK11SDR_Decrypt.PK11SDR_Decrypt
PrototypeC NSS_Init(ProfilePath.p-utf8): Global NSS_Init.NSS_Init
; Initiates all the stuff used for decryption
; RETURN: true if all loaded OK, false else
Procedure NSSInit()
Protected Ret = 1
; this one is not used directly, but must be loaded for nss to work
ret & Bool(OpenLibrary(#PB_Any, "softokn3.dll"))
; load NSS
nss3Lib = OpenLibrary(#PB_Any, "nss3.dll")
ret & Bool(nss3Lib)
; Get functions
If IsLibrary(nss3Lib)
PK11SDR_Decrypt = GetFunction(nss3Lib, "PK11SDR_Decrypt")
NSS_Init = GetFunction(nss3Lib, "NSS_Init")
EndIf
ret & Bool(PK11SDR_Decrypt)
ret & Bool(NSS_Init)
ProcedureReturn ret
EndProcedure
;}
If NSSInit()
Else
MessageRequester("Init failed", "Cannot init libraries." + #CRLF$ + " Check If there are correct nss3.dll and softokn3.dll files present.", #PB_MessageRequester_Error)
End
EndIf
; init FF decryption
Define FirefoxProfilePath$ = "full_path_to_firefox_profile_folder"
Debug NSS_Init(FirefoxProfilePath$)
; first, perform base-64 decode of given data
Define *TD = AllocateMemory(2048)
Define DecodedLen = Base64Decoder("some_base64_encoded_string_from_firefox_db", *Td, 2048)
; put decoded data and it's size into SECitem
Define A.SECItem
A\Data = *TD
A\len = DecodedLen
; allocate output buffer
Define OUT.SECItem
; decrypt
Debug PK11SDR_Decrypt(A, OUT, 0)
; results
Debug PeekS(OUT\Data, OUT\len, #PB_UTF8)
Re: Firefox profile decryption
Posted: Fri Feb 12, 2021 7:00 pm
by Kwai chang caine
Hello LUNASOLE
I have try your code without succes with FF portable version, the DLL cannot be open
This one can works in 32 bits ?
Re: Firefox profile decryption
Posted: Fri Feb 12, 2021 8:01 pm
by NicTheQuick
If your Firefox was installed as 64-bit version you also have to use the 64-bit Purebasic-Version.
Btw: Just use 64-Bit everywhere. Nobody needs 32-bit nowadays.
Re: Firefox profile decryption
Posted: Fri Feb 12, 2021 10:23 pm
by Shardik
NicTheQuick wrote:Nobody needs 32-bit nowadays.
This statement won't become true even if you have already stated it in at least one
different thread. It may be true for most of us but
Nobody is simply untrue! I don't think that I am the only one who still has to use several third party 32-bit DLLs (one even from Microsoft) in production code because there simply doesn't exist a 64-bit version of that DLL. And because of these 32-bit DLLs I am forced to compile 32-bit executables. Admittedly most of my programs I would be able to compile as 64-bit executables but as long as I have a few mission critical programs which still have to use a 32-bit DLL, I won't switch to 64-bit...
Re: Firefox profile decryption
Posted: Fri Feb 12, 2021 10:37 pm
by Saki
Nevertheless, Nick is right.
We will not find the future in the past.
Whenever possible, one should part with it.
There are great dangers in using 32 bits.
Hundreds of millions of expensive space missions have already failed due to overflows.
https://hownot2code.com/2016/09/02/a-sp ... -overflow/
Re: Firefox profile decryption
Posted: Fri Feb 12, 2021 11:56 pm
by Shardik
Saki wrote:Nevertheless, Nick is right.
Sorry, but Nick can't be right as long as he states "
Nobody needs 32-bit nowadays." I have explained why I still have to compile 32-bit executables. And as long as my third party DLLs are not compiled to 64-bit and Microsoft still supports 32-bit in Windows 10, I won't change this. And
Nobody is untrue even if I would be the only developer in the world still needing 32-bit in Windows 10...

Re: Firefox profile decryption
Posted: Sat Feb 13, 2021 12:24 am
by Lunasole
Kwai chang caine wrote:Hello LUNASOLE
I have try your code without succes with FF portable version, the DLL cannot be open
This one can works in 32 bits ?
That's strange if all did right. I guess you need to correct paths to DLL in code in some way (or place compiled executable to firefox folder), if just "can't find dll".
Yes, it should work fine for 32 bits (I was testing on 32-bit firefox version).
Saki wrote:Nevertheless, Nick is right.
We will not find the future in the past.
Whenever possible, one should part with it.
There are great dangers in using 32 bits.
Hundreds of millions of expensive space missions have already failed due to overflows.
I'm still like more 32-bits if possible
Just because of more optimized memory usage. Same game in x86 version will consume much less memory than if it's compiled to x64.
Of course it's applicable only if no need to intensively use 8-byte calculations and additional CPU instructions and registers for better performance. And only if 2GB of ram will be enough for process. Thus 32 bits are mostly applicable to some small or average programs.
Re: Firefox profile decryption
Posted: Sat Feb 13, 2021 2:14 am
by BarryG
I read the link. The mission didn't fail due to 32-bits, but due to the developers not coding sanity tests with their variables. They
assumed the variables would be safe, without implementing any If/Then or Try/Catch checks. In other words, they cut corners, and you can't blame 32-bit for this.
From the link:
"The protection of all 7 (including BH) variables wasn’t provided because the maximum workload for the IRS computer was declared as 80%. The developers had to look for ways to reduce unnecessary evaluation expenses, and they weakened the protection in that fragment where theoretically the accident could not happen." So they actively chose NOT to check the state of things and made assumptions instead, and this laziness led to the rocket's self-destruct routine to trigger. This is in no way 32-bit's fault.
Something else to ponder: space rockets in the 1960s used 8-bit technology with no problems. So, you don't "need" 64-bit for them to be safe; you just need to code properly and not cut corners and make assumptions.
Re: Firefox profile decryption
Posted: Sat Feb 13, 2021 2:37 am
by NicTheQuick
Well, if there is no other way because there are only 32 bit libraries, you are forced to also compile for 32 bit. But that's a Windows thing. On Linux you will not find that any more except you want to run antique software. And then you have to install some layers of basic 32-bit libraries to even be able to do so. Most distributions do not ship 32 bit packages any more.
But if you are writing a new piece of software you should use what's the current standard. On Windows you also have quite different security mechanisms between 32 and 64 bit applications you should know about.
Re: Firefox profile decryption
Posted: Sat Feb 13, 2021 10:08 am
by Saki
@BarryG
Well, I think that with such projects you can say goodbye to the idea that the programmers were too lazy to create a secure code.
These codes are probably checked several times by different people and tested how ever possible.
People make mistakes and they project them into what they do, no matter what it is.
I really don't think you want to be the one to be accused of laziness when such a project fails.
This laziness then means in reverse that they knowingly accepted the failure of the project through deliberate carelessness.
In the best case scenario, you'll never get another job like this and will probably have to learn how to use a broom.
Important in any system is a high fault tolerance and sufficient security reserves.
If you can't guarantee this, it quickly becomes dangerous.
Re: Firefox profile decryption
Posted: Sat Feb 13, 2021 3:40 pm
by Kwai chang caine
Lunasole wrote:That's strange if all did right. I guess you need to correct paths to DLL in code in some way (or place compiled executable to firefox folder), if just "can't find dll".
Yes, it should work fine for 32 bits (I was testing on 32-bit firefox version).
Thanks for your quick answer
I will try again, but I wanted to be sure not to suck for nothing with my PB version v5.73 X86 and W10 X64
I have another question, at your advice, the DLL FF you use in your code, is OOP or procedural like the PB DLL ?
Shardik wrote:even if I would be the only developer in the world still needing 32-bit in Windows 10
Not alone...we will be at least two
I'm nearly an old man, with old phone (Note 2), old car and and whatever the society will let me use old

I am faithful to what is useful to me every day, if I am satisfied, without always having to try to follow this galloping technology not always rightly.
So as long as the 32-bit meets my expectations, I will stay in 32-bit, and that way I can run the programs on all the old machines, which are even more numerous than we think.

Furthermore the 32 bits more than enough, to handle the little complexity that I can use in my poor programs

I leave for now the 64 bits for the MASTERS like you all

I still have trouble getting used to UNICODE in PB, so i don't want to add the complexity of 64 Bits for the moment

Re: Firefox profile decryption
Posted: Sat Feb 13, 2021 7:43 pm
by Kwai chang caine
I don't understand
Never i can open "softokn3.dll" in X86 or X64 in your code
And even if i move the DLL and test a simple OpenLib Softokn3 = 0
Code: Select all
Softokn3 = OpenLibrary(#PB_Any, "D:\Temp\softokn3.dll")
Re: Firefox profile decryption
Posted: Sat Feb 13, 2021 9:16 pm
by Lunasole
Kwai chang caine wrote:
I have another question, at your advice, the DLL FF you use in your code, is OOP or procedural like the PB DLL ?
Seems to be procedural. At least functions I used from it.
Can't say why it not works again, it surely should. I'm using it with all those DLLs copied to a program folder (and executable saved in the same folder).
Re: Firefox profile decryption
Posted: Sat Feb 13, 2021 9:46 pm
by Kwai chang caine
Incredible, here with this method apparently that not works
Perhaps it's because FF is portable ?
But the more surprising, it's i can't open directly the DLL, even with the full path
I have even testing again more simple
The DLL and the source code in the same folder and run
Code: Select all
Debug OpenLibrary(#PB_Any, GetPathPart(ProgramFilename()) + "softokn3.dll")
The debug return 0 In X86
And an error "GetModuleHandleW" in X64
Perhaps i have another idea tomorrow
So have a very good night and again thanks for all

Re: Firefox profile decryption
Posted: Tue Mar 21, 2023 5:18 pm
by Lunasole
Wished to update it (as I again looked a bit what is going on in Firefox profile and found few strange DB, looking crypted), but well two things:
- seems that some DB which were encrypted in past versions are no more (or I missed something)
- code here doesn't work, fails starting with NSS_Init return, and need additionally to adopt it for modern versions (probably changes around those crypto APis)
Too many undocumented trash in FF profile storages and activity anyway, but well no need to one more time blame it all^^Still it looks better of those browsers, except going to simplest of them.