Chrome State Key Parsing Bugfix

[atticuss-sra]

This is a very minor bugfix to address how the statekeys are pulled from later versions of Chrome's local state file. The bug is a result of parsing the JSON file via an indexOf() against the encrypted_key substring. Many versions of Chrome I tested have two JSON keys with encrypted_key in the name. When the app_bound_encrypted_key JSON key comes before the encrypted_key key within the file, SharpChrome pulls the former and attempts to decrypt it as a state key.

This will cause SharpChrome to fail with the following error message:

[X] AES state key has unknown/non-DPAPI encoding.

The simple fix is to update the search term to be quote-wrapped, ensuring a perfect match on the expected key. Ideally, we would use JSON/Lync to parse this file, but I'm not sure if this introduces unwanted behavior under different conditions. In order to prevent this change from affecting other environments, the Chrome.GetBase64EncryptedKey() function will search for the quote-wrapped search term and if it fails to find the value, will fall back to the original non-quote-wrapped search term.

[beauknowstech]

This fixed the issue I was having with [X] AES state key has unknown/non-DPAPI encoding.
Thank you!

[leechristensen]

Great catch! Thanks for the contribution!