search

darkarp / chromepass

Chromepass - Hacking Chrome Saved Passwords
GNU Affero General Public License v3.0
777 stars 109 forks source link

Only cookies being caught #39

Closed Genus-learner closed 3 years ago

Genus-learner commented 3 years ago

Ok, I forgot in my last post. Part of why I thought the memory error was real was because the server console gives this error and I receive no data image

darkarp commented 3 years ago

Please download Chromepass again and try it out. I actually noticed that bug before. It appeared because the server tried to create a directory inside data but data didn't exist. It should be fixed :D

Genus-learner commented 3 years ago

Redownloaded it and even manually created a data folder image still get the same error

darkarp commented 3 years ago

Please check that the server has permission to write to the directory it's in. The server writes all of its data in the same directory and if it can't do so it will fail on the next writes.

There are 2 soutions:

  1. You simply change the location of the server to where it has permission to write (like Desktop)
  2. You run the server as Admin, which should give you write permissions pretty much anywhere.

I pushed a new version that adds a more descriptive message when that error happens.

Genus-learner commented 3 years ago

Ran as admin and that indeed did fix it. Unfortunately I am having the same problem's as I did with the old one: image

It is only getting cookies

The fact that its happening only on some computers and not others tells me there's some sort of variable I'm not accounting for but I can't think of it. Both chrome and its login file are at the default locations.

darkarp commented 3 years ago

Huh, that's weird! It's possible there's a variable I'm not accounting for as well. A couple suggestions:

  1. Do you have chrome open during this when running the client? (or anything else?). Maybe try closing everything, just in case (is something preventing access to that particular file?).
  2. Maybe turn off AVs/Defender, just to eliminate that possibility (maybe related to point 1).
  3. Run the client as administrator, in case perhaps there are some permission problems with accessing that file specifically?

If any of these work maybe we can narrow it down further. Thanks for your patience!

Genus-learner commented 3 years ago

Thank you for your quick responses! I'll try these out soon and let you know how it goes

darkarp commented 3 years ago

I remembered another potential problem that I had thought about before and ultimately forgot. Perhaps the login data file is located elsewhere and not in the Default folder. For those machines where it doesn't work, could you check the files in %LOCALAPPDATAA%/Google/Chrome/User Data/Default? There should be a Cookies and Login Data folder inside.

Genus-learner commented 3 years ago

@ C:\Users\Username\AppData\Local\Google\Chrome\User Data\Default There is login data

image

So in other word they match the computers that do work.

I downloaded a password viewer and it was able to pull the passwords image

I believe that supports the idea that all the files are in their default location

Genus-learner commented 3 years ago

Huh, that's weird! It's possible there's a variable I'm not accounting for as well. A couple suggestions:

  1. Do you have chrome open during this when running the client? (or anything else?). Maybe try closing everything, just in case (is something preventing access to that particular file?).
  2. Maybe turn off AVs/Defender, just to eliminate that possibility (maybe related to point 1).
  3. Run the client as administrator, in case perhaps there are some permission problems with accessing that file specifically?

If any of these work maybe we can narrow it down further. Thanks for your patience!

I tried your suggestions. No improvement.

darkarp commented 3 years ago

This is really strange. Would it be okay if I gave you a version of chromepass in form of an executable to test it out? I'm assuming you're testing it on a VM

darkarp commented 3 years ago

chromepass.zip It's just an executable that's pointing to 127.0.0.1:80. Could you test it out by running it with powershell/cmd? That way you can see what it prints out and helps us figure out where the problem is more exactly :D

Genus-learner commented 3 years ago

This is really strange. Would it be okay if I gave you a version of chromepass in form of an executable to test it out? I'm assuming you're testing it on a VM

Chromepass is installed on a VM, but the client I am testing on my actual computer.

chromepass.zip It's just an executable that's pointing to 127.0.0.1:80. Could you test it out by running it with powershell/cmd? That way you can see what it prints out and helps us figure out where the problem is more exactly :D Tested the file you sent on the VM image

darkarp commented 3 years ago

Was the server running at the time the client was executed?

darkarp commented 3 years ago

by the way, it's totally safe to test that even on your computer, it just does the same thing as a client generated with the default 127.0.0.1:80 configuration sending to the local server, but with a lot of different printing along the way :D

Genus-learner commented 3 years ago

This is the printing on the vm where it is able to get login and cookies image

This is the printing on my actual computer where it cant get login info but can get cookies image

Server was running this time in both scenarios, but server is running on virtual machine and not on the actual computer so idk if that would affect it?

darkarp commented 3 years ago

That's perfect, now we know it's failing at the decryption of the password in login. I think I might know why this is the case. I have just pushed an update to chromepass, could you try generating the client now to figure out if it's working?

Genus-learner commented 3 years ago

That's perfect, now we know it's failing at the decryption of the password in login. I think I might know why this is the case. I have just pushed an update to chromepass, could you try generating the client now to figure out if it's working? image

Latest build can't make a client for some reason Didnt happen with the previous ones It feels like I'm just doing something wrong at this point lol

darkarp commented 3 years ago

hmm sorry about that, it might be a problem on my end. Do you see any error message inside the logs.log folder? (maybe it would be best to delete that file and try to build the client again, to remove the old errors). Meanwhile, I pushed another update, which just makes the error messages a bit more descriptive so we can know what's wrong :)

Genus-learner commented 3 years ago

Here's the end of the log image

Genus-learner commented 3 years ago

Meanwhile, I pushed another update, which just makes the error messages a bit more descriptive so we can know what's wrong :)

I'll take a look

darkarp commented 3 years ago

My apologies. I just checked the error message. It was a line I added to the config file. I just fixed it. It should build.

Genus-learner commented 3 years ago

My apologies. I just checked the error message. It was a line I added to the config file. I just fixed it. It should build.

image

darkarp commented 3 years ago

Looking into it! Again, thanks for the patience!!

darkarp commented 3 years ago

Fortunately it seems that issue is related to a specific dependency which isn't used anymore in my project so I just removed it. Hopefully it works now :D (just updated it)

Genus-learner commented 3 years ago

I got a clean build, but now the server isn't receiving anything from the client? I ran an old version of the client and it seemed to work (but since its an old version of course it still doesn't get any login data)

lol hopefully all this troubleshooting will make everything go super smoothly for anyone else who wants to learn how this all works in the future

darkarp commented 3 years ago

Pushed another update. I noticed a few issues that might be causing your current problem, mainly the way that the program figures out where the local appdata program is, I realized not all systems will have the required environment variable so it now uses a different method. I was also checking whether the decryption key was correctly found or not, which also makes the script not work for earlier versions of Chromium-based browsers. (It would also not be able to decrypt passwords saved from when the browser was in its older version, even if updated afterwards).

It should work now, I hope :D

lol hopefully all this troubleshooting will make everything go super smoothly for anyone else who wants to learn how this all works in the future

Yeah hopefully :P

Genus-learner commented 3 years ago

I would like to congratulate you sir, as of right now, it is working on both the VM and the actual computer that it wasn't working on when this thread was created (and in #36 ). When I get the chance I'll test it on my other computers to make sure it still works in them after all these changes that have happened.

darkarp commented 3 years ago

Thank you! I'd like to thank you as well for helping track this issue down, it wouldn't have been possible without you! I'll wait until I close the issue to make sure it works on your other computers as well, but I'll mark it as complete meanwhile :D

Genus-learner commented 3 years ago

I'll wait until I close the issue to make sure it works on your other computers as well, but I'll mark it as complete meanwhile :D

Good news! it seems to be working with all my computers. I think you officially fixed it!

I noticed a few issues that might be causing your current problem, mainly the way that the program figures out where the local appdata program is, I realized not all systems will have the required environment variable so it now uses a different method

What has been changed in the decryption process since the beginning of the thread? What was the main issue causing it to not get login data?

darkarp commented 3 years ago

That's awesome!

So a couple of things got changed. Before, the decryption process went like this:

  1. Look in the Local State file for the AES256-gcm key used to decrypt passwords in Chrome 80+
  2. The key itself is encrypted with DPAPI so we decrypt the key.
  3. Then we look for the Login Data and Cookie directory and use the decrypted key to get the plaintext passwords.

Initially I thought the problem was only on step 3, and it partially was. Chrome version 80 and above store the passwords in this encryption format (encrypted by the aes256-gcm key in Local State and having that key encrypted with DPAPI). Before Chrome version 80, passwords were just all encrypted with DPAPI. Now the problem is that even if you update Chrome to the latest versions, all the passwords that were saved in the Chrome<80 format will remain in that format and they won't be able to de decrypted. So I changed the decryption to simple DPAPI if the AES256-GCM fails.

This wasn't enough however because it turns out I was also only decrypting passwords if a valid key was found in Local State, which there doesn't have to be one if the version < 80. This is more of a "making sure it works on all versions" even though most people will have updated by now.

The last problem was the method with which I retrieved the directories. I was using LOCALAPPDATA environment variable but that may not exist. Now, I directly build the correct path from the username.

So in summary, the main issue was that the decryption failed if there were any passwords stored from Chrome versions before 80 and the base directories were not always correct due to potentially nonexisting environment variables.

darkarp commented 3 years ago

Closing this issue now as it's solved. It took a while :P